5 hours ago, CFreitas said:
Atenção que a AT, nesta nova versão do SAF-T, passou a utilizar a versão 1.1. do schema XML (xsd `vc:minVersion="1.1"`). até aqui usava a versão 1.0.
A versão 1.1. tem novas funcionalidades, entre elas as ASSERTions.
O grande problema é que, tanto quanto sei, é uma versão que embora já exista há bastante tempo, tem pouco suporte.
O .NET não suporta. O Java acho que já suporta. Podem ainda tentar com o Xerces.
Bem visto! No entanto nem sequer o JAVA 8 suporta o Schema 1.1: http://stackoverflow.com/questions/20807066/how-to-validate-xml-against-xsd-1-1-in-java
E pelo que posso ler, vai haver muita gente com o mesmo problema. O uso da especificação 1.1 não foi muito feliz por parte da AT :\
Também não é grande drama: removem-se os ASSERT e corta-se o maxOccurs="unbounded"
Por um lado o e-faturas usa / obriga java que cada vez menos browsers (então os de 64bits...) suportam / usam.
Por outro vão para estas modernices.....
Tá lindo, tá.
9 minutes ago, paulo brito said:
Bem, o java faz parte do coração da AT... não estou a ver a AT a implementar um interface WEB sem correr applets java.
A jogada da Google em remover o suporte NPAPI deve ter a ver com questões de segurança, mas não afecta apenas o JAVA! https://www.java.com/en/download/faq/chrome.xml
Edited February 21, 2017 by marcolopes
A questão do NPAPI é mesmo nos browsers...
Estou convencido que estas entregas em breve passaram a ser feitas por app offline, em Java puro, como já há algumas.
Também não os vejo a abandonar o Java com tanta coisa já feita.
Em 07/12/2016 às 13:20, migueldealmeida disse:
Alguém já tem ideia de quando e como usar isto?
Mais uma coisa estranha no SAF-T 1.04, neste caso, na parte dos Working Documents:
4.3.4.14.10. Referências a documentos (References)
Referências a documentos nos documentos retificativos destes.
Existindo a necessidade de efetuar mais do que uma referência, esta estrutura poderá ser gerada tantas vezes quantas as necessárias.
4.3.4.14.10.1. Referência (Reference)
Referência a documento, através de identificação única do mesmo, nos sistemas em que exista. Deve ser utilizada a estrutura de numeração do campo de origem.
4.3.4.14.10.2. Motivo (Reason)
Deve ser preenchido com o motivo da emissão.
Isto é o que diz a portaria...
No entanto, o XSD tem ideias diferentes sobre isto:
<xs:element name="WorkingDocuments" minOccurs="0">
<xs:element name="WorkDocument" minOccurs="0" maxOccurs="unbounded">
<xs:element ref="ATCUD" />
<xs:element ref="Reason" minOccurs="0" />
<xs:element name="SourceBilling" type="SAFTPTSourceBilling" />
<xs:element ref="HashControl" />
<xs:element ref="Period" minOccurs="0" />
<xs:element ref="EACCode" minOccurs="0" />
<xs:element ref="TransactionID" minOccurs="0" />
<xs:element name="Line" maxOccurs="unbounded">
<xs:element name="OrderReferences" type="OrderReferences" minOccurs="0" maxOccurs="unbounded" />
<xs:element ref="TaxBase" minOccurs="0" />
<xs:element name="ProductSerialNumber" type="ProductSerialNumber" minOccurs="0" />
<xs:element name="Tax" type="Tax" minOccurs="0" />
<xs:element ref="TaxExemptionReason" minOccurs="0" />
<xs:element ref="TaxExemptionCode" minOccurs="0" />
<xs:element ref="SettlementAmount" minOccurs="0" />
<xs:element name="CustomsInformation" type="CustomsInformation" minOccurs="0" />
<xs:assert test="if ( not(ns:Tax/ns:TaxAmount) or ( (ns:Tax/ns:TaxAmount != 0 and not(ns:TaxExemptionReason) ) or (ns:Tax/ns:TaxAmount eq 0 and ns:TaxExemptionReason ) ) ) then true() else false()" />
<xs:assert test="if ( not(ns:Tax/ns:TaxPercentage) or ( (ns:Tax/ns:TaxPercentage != 0 and not(ns:TaxExemptionReason) ) or (ns:Tax/ns:TaxPercentage eq 0 and ns:TaxExemptionReason ) ) ) then true() else false()" />
<xs:assert test="if (( ns:TaxExemptionReason and not(ns:TaxExemptionCode) ) or  (ns:TaxExemptionCode and not(ns:TaxExemptionReason))) then false() else true()" />
<xs:assert test="if (( ns:TaxBase and ns:UnitPrice !=0)) then false() else true()" />
<xs:assert test="if (( ns:TaxBase and ns:DebitAmount !=0) or ( ns:TaxBase and ns:CreditAmount !=0)) then false() else true()" />
<xs:element name="Currency" type="Currency" minOccurs="0" />
Chamo a atenção para a seguinte linha:
Ou seja, o tipo que está a ser usado é o OrderReferences, que por sua vez se traduz nisto:
<xs:complexType name="OrderReferences">
<xs:element ref="OriginatingON" minOccurs="0" />
<xs:element ref="OrderDate" minOccurs="0" />
Ou seja, os campos OrderReferences, OriginatingON e OrderDate, em vez dos que estão na portaria References, Reference e Reason.
Eu estou maluco, ou isto está tudo trocado?
Quanto ao TaxBase, se for aquilo que eu penso, acho que é algo que fazia muita falta.
Na minha opinião, serve para fazeres uma Nota de Débito/Nota de Crédito a corrigir uma Fatura em que o único valor alterado é o IVA.
Por exemplo, fazes uma fatura sem IVA porque estaria isento ao abrigo de ...
Mais tarde, verificas que afinal as condições necessárias à isenção não se verificam, tens de Debitar só o IVA porque a Mercadoria já foi debitada na Fatura.
Esta situação é relativamente frequente em situações de Exportação (através de terceiros) em que depois se verifica que a mercadoria não saiu do país (ou não aparecem os documentos comprovativos de tal coisa).
Quanto ao References (não confundir com o OrderReferences) nos WorkingDocuments, por analogia com a sua aplicação às Invoices, servem para identificar os documentos retificados (por exemplo, FC - Fatura Consignação) nos documentos retificativos (por exemplo, CC - Crédito de Consignação).
Aparentemente o XSD está mesmo mal feito, esqueceram-se mesmo de acrescentar este campo.
Esqueceram-se de acrescentar o References, e colocaram o OrderReferences no seu lugar, que não consta na tabela 4.3 da portaria.