search

assoft-portugal / SAF-T-AO

Official XSD from the Government of Angola for use in SAF-T AO
https://www.agt.minfin.gov.ao
MIT License
56 stars 63 forks source link

Validador falha com erro em TaxPayable #32

Closed batalhadematos closed 5 years ago

batalhadematos commented 5 years ago

Boas, Lamento repetir este issue, porque já vi que alguém reportou o mesmo problema, mas o issue está marcado como fechado e fiquei sem saber qual a solução.

Ao validar o xml com o xsd funciona bem. Ao testar o mesmo xml no validador da AGT, é gerado um erro "Falha na validação, porque o TaxPayable do AuditFile.SourceDocuments.SalesInvoices.XInvoice está mal calculado", onde X é o número que identifica a factura/documento.

Depois fazer vários testes, continuo sem entender a origem do problema.

Vejamos o exemplo de linhas validadas com sucesso:

  1. Factura com apenas uma linha de produto ao preço de 1000 com IVA a 14%. ... <TaxBase>1000.00</TaxBase> ... 
    <Tax>
<TaxType>IVA</TaxType>
<TaxCountryRegion>AO</TaxCountryRegion>
<TaxCode>NOR</TaxCode>
<TaxPercentage>14</TaxPercentage>
</Tax>

    ...

    <DocumentTotals>
<TaxPayable>140.0000</TaxPayable>
<NetTotal>1000.00</NetTotal>
<GrossTotal>1140.00</GrossTotal>
</DocumentTotals>

Aqui o sistema valida correctamente os valores:

  1. Factura com apenas uma linha de produto ao preço de 1000, com desconto de 10% e IVA a 14% ... <TaxBase>900.00</TaxBase> ... 
    <Tax>
<TaxType>IVA</TaxType>
<TaxCountryRegion>AO</TaxCountryRegion>
<TaxCode>NOR</TaxCode>
<TaxPercentage>14</TaxPercentage>
</Tax>

    ...

    <DocumentTotals>
<TaxPayable>126.0000</TaxPayable>
<NetTotal>900.00</NetTotal>
<GrossTotal>1026.00</GrossTotal>
</DocumentTotals>

Mais uma vez o sistema valida com sucesso esta factura assumindo como correctos os valores:

Para testar um exemplo incluído nos requisitos para validação de aplicações e que deve ser enviado à AGT, gerei o seguinte documento:

Factura com apenas uma linha de produto com as seguintes características:

Pelo meu entendimento e a julgar pelos exemplos acima, aqui deverei considerar:

E os dados no xml: ... <TaxBase>50.16</TaxBase> ...

<Tax>
    <TaxType>IVA</TaxType>
    <TaxCountryRegion>AO</TaxCountryRegion>
    <TaxCode>NOR</TaxCode>
    <TaxPercentage>14</TaxPercentage>
</Tax>

... <SettlementAmount>4.8400</SettlementAmount> ...

<DocumentTotals>
    <TaxPayable>7.0224</TaxPayable>
    <NetTotal>50.16</NetTotal>
    <GrossTotal>57.18</GrossTotal>
</DocumentTotals>

Anexo um xml onde constam os 3 documentos.

PS: No xml, para o campo TaxPayable alterei o número de casas decimais para 4. O XSD tem como schema de validação, 2 decimais.

Obrigado a todos

Paulo Matos sample_xml.txt

pcasqueiro commented 5 years ago

Tenho o mesmo problema mas em documentos que me parecem simples. Num XML com 10 Invoices tenho erro em 3 mas estão calculados exactamente da mesma maneira. Este exemplo está a aparecer como sendo mal calculado com o erro: Falha na validação, porque o TaxPayable do AuditFile.SourceDocuments.SalesInvoices.8Invoice está mal calculado

      <Invoice>
            <InvoiceNo>FR Z1.2019/8</InvoiceNo>
            <DocumentStatus>
                <InvoiceStatus>N</InvoiceStatus>
                <InvoiceStatusDate>2019-10-23T09:30:51</InvoiceStatusDate>
                <SourceID>pcasqueiro</SourceID>
                <SourceBilling>P</SourceBilling>
            </DocumentStatus>
            <Hash></Hash>
            <HashControl>1</HashControl>
            <Period>10</Period>
            <InvoiceDate>2019-10-23</InvoiceDate>
            <InvoiceType>FR</InvoiceType>
            <SpecialRegimes>
                <SelfBillingIndicator>0</SelfBillingIndicator>
                <CashVATSchemeIndicator>0</CashVATSchemeIndicator>
                <ThirdPartiesBillingIndicator>0</ThirdPartiesBillingIndicator>
            </SpecialRegimes>
            <SourceID>pcasqueiro</SourceID>
            <SystemEntryDate>2019-10-23T09:30:51</SystemEntryDate>
            <CustomerID>2</CustomerID>
            <ShipTo/>
            <Line>
                <LineNumber>1</LineNumber>
                <OrderReferences>
                    <OriginatingON>FR Z1.2019/8</OriginatingON>
                    <OrderDate>2019-10-23</OrderDate>
                </OrderReferences>
                <ProductCode>21</ProductCode>
                <ProductDescription>Cartões de Visita</ProductDescription>
                <Quantity>30</Quantity>
                <UnitOfMeasure>UN</UnitOfMeasure>
                <UnitPrice>0.55</UnitPrice>
                <TaxPointDate>2019-10-23</TaxPointDate>
                <Description/>
                <CreditAmount>16.5</CreditAmount>
                <Tax>
                    <TaxType>IVA</TaxType>
                    <TaxCountryRegion>AO</TaxCountryRegion>
                    <TaxCode>NOR</TaxCode>
                    <TaxPercentage>14</TaxPercentage>
                </Tax>
            </Line>
            <DocumentTotals>
                <TaxPayable>2.31</TaxPayable>
                <NetTotal>16.5</NetTotal>
                <GrossTotal>18.81</GrossTotal>
                <Payment>
                    <PaymentMechanism>CD</PaymentMechanism>
                    <PaymentAmount>18.81</PaymentAmount>
                    <PaymentDate>2019-10-23</PaymentDate>
                </Payment>
            </DocumentTotals>
            <WithholdingTax>
                <WithholdingTaxAmount>2.31</WithholdingTaxAmount>
            </WithholdingTax>
        </Invoice>
pcasqueiro commented 5 years ago

Com base neste erro (e nos outros) o TotalCredit também aparece como errado

cryptolopes commented 5 years ago

33

Boas, Lamento repetir este issue, porque já vi que alguém reportou o mesmo problema, mas o issue está marcado como fechado e fiquei sem saber qual a solução.

Ao validar o xml com o xsd funciona bem. Ao testar o mesmo xml no validador da AGT, é gerado um erro "Falha na validação, porque o TaxPayable do AuditFile.SourceDocuments.SalesInvoices.XInvoice está mal calculado", onde X é o número que identifica a factura/documento.

Depois fazer vários testes, continuo sem entender a origem do problema.

Vejamos o exemplo de linhas validadas com sucesso:

  1. Factura com apenas uma linha de produto ao preço de 1000 com IVA a 14%. ... <TaxBase>1000.00</TaxBase> ...
<Tax>
  <TaxType>IVA</TaxType>
  <TaxCountryRegion>AO</TaxCountryRegion>
  <TaxCode>NOR</TaxCode>
  <TaxPercentage>14</TaxPercentage>
</Tax>

...

<DocumentTotals>
  <TaxPayable>140.0000</TaxPayable>
  <NetTotal>1000.00</NetTotal>
  <GrossTotal>1140.00</GrossTotal>
</DocumentTotals>

Aqui o sistema valida correctamente os valores:

  • TaxPayable: 140,00
  • NetTotal: 1000,00
  • GrossTotal: 1140,00
  1. Factura com apenas uma linha de produto ao preço de 1000, com desconto de 10% e IVA a 14% ... <TaxBase>900.00</TaxBase> ...
<Tax>
  <TaxType>IVA</TaxType>
  <TaxCountryRegion>AO</TaxCountryRegion>
  <TaxCode>NOR</TaxCode>
  <TaxPercentage>14</TaxPercentage>
</Tax>

...

<DocumentTotals>
  <TaxPayable>126.0000</TaxPayable>
  <NetTotal>900.00</NetTotal>
  <GrossTotal>1026.00</GrossTotal>
</DocumentTotals>

Mais uma vez o sistema valida com sucesso esta factura assumindo como correctos os valores:

  • TaxPayable: 126,00
  • NetTotal: 900,00
  • GrossTotal: 1026,00

Para testar um exemplo incluído nos requisitos para validação de aplicações e que deve ser enviado à AGT, gerei o seguinte documento:

Factura com apenas uma linha de produto com as seguintes características:

  • Preço Unitário: 0.55 (-8,8%) = 50.16
  • Quantidade: 100
  • Desconto: 8,8%
  • IVA: 14%

Pelo meu entendimento e a julgar pelos exemplos acima, aqui deverei considerar:

  • TaxBase deverá ser: 50.16 (0.55 * 100 - 8.8%)
  • TaxPayable: 7.0224 (TaxBase * percentagem do imposto)

E os dados no xml: ... <TaxBase>50.16</TaxBase> ...

<Tax>
  <TaxType>IVA</TaxType>
  <TaxCountryRegion>AO</TaxCountryRegion>
  <TaxCode>NOR</TaxCode>
  <TaxPercentage>14</TaxPercentage>
</Tax>

... <SettlementAmount>4.8400</SettlementAmount> ...

<DocumentTotals>
  <TaxPayable>7.0224</TaxPayable>
  <NetTotal>50.16</NetTotal>
  <GrossTotal>57.18</GrossTotal>
</DocumentTotals>

Anexo um xml onde constam os 3 documentos.

PS: No xml, para o campo TaxPayable alterei o número de casas decimais para 4. O XSD tem como schema de validação, 2 decimais.

Obrigado a todos

Paulo Matos sample_xml.txt

O ficheiro tem alguns erros de estrutura, que convém resolver primeiro. sample_xml-errors.xml.txt

cryptolopes commented 5 years ago

Com base neste erro (e nos outros) o TotalCredit também aparece como errado

Tudo indica que seja pelo arredondamento. Calcular valores de UnitPrice, CreditAmounte DebitAmountcom apenas duas casas decimais pode dar origem a ligeiras diferenças no apuramento do total do documento. Possivelmente o portal de validação da AGT considera essa diferença por mais pequena que seja.

cryptolopes commented 5 years ago

Duplicate of #17

pcasqueiro commented 5 years ago

Caro Nelson, Só estamos a arrendondar para a apresentação dos resultados, vamos colocar mais casas decimais. O tipo MONETARY são quantas casas decimais ? Em relação ao campo NUMBER of ENTRIES é contado o numero de Invoices ou o numero de Lines ? O decreto fala em “numero total de documentos”

Obrigado, Pedro

pcasqueiro commented 5 years ago

No caso de um documento “A”nulado, o seu valor também deve ir para o total ?

cryptolopes commented 5 years ago

Caro Nelson, Só estamos a arrendondar para a apresentação dos resultados, vamos colocar mais casas decimais. O tipo MONETARY são quantas casas decimais ? Em relação ao campo NUMBER of ENTRIES é contado o numero de Invoices ou o numero de Lines ? O decreto fala em “numero total de documentos”

Obrigado, Pedro

SAFmonetaryType não tem limite de casas decimais. GrossTotal, NetTotale TaxPayableforça sempre duas casas decimais.

  <xs:simpleType name="SAFmonetaryType">
    <xs:restriction base="xs:decimal">
      <xs:minInclusive value="0.00" />
    </xs:restriction>
  </xs:simpleType>
  <!-- Elementos com Duas Casas Decimais -->
  <xs:simpleType name="SAFMonetaryType2DecimalPlaces">
    <xs:restriction base="xs:decimal">
      <xs:pattern value="\d+(\.\d{2})" />
      <xs:minInclusive value="0.00" />
    </xs:restriction>
  </xs:simpleType>

Sobre o NumberOfEntries fechei em #34. Adicionei documentação ao schema.

cryptolopes commented 5 years ago

No caso de um documento “A”nulado, o seu valor também deve ir para o total ?

https://github.com/assoft-portugal/SAF-T-AO/commit/f90a176c69c4a45695e193e51df9340d41deaee9

batalhadematos commented 5 years ago

O ficheiro tem alguns erros de estrutura, que convém resolver primeiro. sample_xml-errors.xml.txt

Estimado @cryptolopes,

Bom dia. Na descrição da lei, existem inúmeros campos que são opcionais (o que me parece lógico) mas acontece que no xsd esses campos aparecem como obrigatórios. Alguns desses são "telephone, fax, unnumber, contact... e por aí fora), para além de outros mais complexos de contornar porque em alguns casos a aplicação pode não manter registo dos mesmos.

Por este motivo e no meu caso pessoal, editei o xsd de formas a que esses campos fossem opcionais.

No caso do campo TaxPayable descrito no erro do xml que enviei, intencionalmente aumentei o número de casas decimais para 4, apenas e unicamente para efeitos de testes uma vez que o mesmo erro era gerado usando o padrão do xsd (2 decimais).

Os erros que encontrou no xml que enviei, devem-se ao facto de que alguns campos do tipo SAFAOtextTypeMandatoryMaxXXCar, passaram a ser opcionais e o validador AGT não reporta qualquer erro.

A estrutura base do xml está ok e não vejo qualquer erro ao testar o xml com o xsd. O único problema ocorre mesmo com a validação do xml no portal da AGT.

O que me parece é que o problema ocorre apenas quando o arredondamento tem que ser feito com maior precisão porque se gerar documentos sem descontos ou com descontos de números inteiros com ou sem impostos isso não acontece e o validador da AGT passa muito bem e não me parece sequer ser um problema do xsd mas sim do validador da AGT.

Aproveito para perguntar se esses campos "opcionais" se vão manter como obrigatórios no xsd ou se existe algum plano de se "separar" os campos obrigatórios dos opcionais?

Obrigado

Paulo Matos

cryptolopes commented 5 years ago

Na descrição da lei, existem inúmeros campos que são opcionais (o que me parece lógico) mas acontece que no xsd esses campos aparecem como obrigatórios. Alguns desses são "telephone, fax, unnumber, contact... e por aí fora), para além de outros mais complexos de contornar porque em alguns casos a aplicação pode não manter registo dos mesmos.

  1. Todos os elementos são obrigatórios.
  2. Existem elementos não obrigatórios por uma questão de estrutura. Se o sistema produzir informação capaz de os escrever, estes devem ser escritos (a título de exemplo o Telephone. caso o elemento não exista a validação do XML decorre sem problemas, mas se existir informação informação do sistema, este elemento deve ser preenchido.)
  3. Não podem existir elementos a vazio.

DP312.18

batalhadematos commented 5 years ago

Estimado @cryptolopes Obrigado pelo esclarecimento. Sendo assim, para estes valores pode ser usado o "espaço em branco" caso a informação não exista na aplicação. Obrigado mais uma vez Paulo Matos

cryptolopes commented 5 years ago

Sendo assim, para estes valores pode ser usado o "espaço em branco" caso a informação não exista na aplicação.

Não! Os elementos não obrigatórios só surgem se existir a obrigatoriedade de reporte (OrderReferences, References, SettlementAmount, etc) ou se existir informação para os preencher.

batalhadematos commented 5 years ago

Sendo assim, para estes valores pode ser usado o "espaço em branco" caso a informação não exista na aplicação.

Não! Os elementos não obrigatórios só surgem se existir a obrigatoriedade de reporte (OrderReferences, References, SettlementAmount, etc) ou se existir informação para os preencher.

@cryptolopes,

Desculpe. Eu é que me expressei mal quando referi, "usar o espaço em branco". O que queria dizer é que estes elementos não devem sequer ser apresentados no xml caso não haja obrigatoriedade de report e se não existir a informação na aplicação.

batalhadematos commented 5 years ago

@cryptolopes

Para o meu caso, este issue pode ser fechado (Falha no validador da AGT para o elemento TaxPayable) Continuo sem saber o porquê do problema no meu caso específico mas descobri que fazendo os cálculos com pelo menos 4 decimais e depois passar o resultado arrendondado para 2 decimais (por excesso ou por defeito) o validator da AGT aceita.

O estranho é que o cálculo feito com duas decimais resulta em um valor precisamente igual ao calculo feito com 4 decimais, tendo em conta o Unitprice.

Contudo, o melhor é que o meu problema ficou resolvido.

Mais uma vez os meus agradecimentos

Paulo Matos (https://github.com/batalhadematos)