marcolopes

Muito estranho! Porque o tipo definido em todas as versões do XSD é: <xs:simpleType name="SAFdecimalType"> <xs:restriction base="xs:decimal"> <xs:minInclusive value="0.00"/> </xs:restriction> </xs:simpleType> Que é exactamente o mesmo tipo definido nas estruturas SAFT, e que permite mais do que duas casas decimais... Para controlar o total de decimais, deveria existir uma declaração do tipo <xs:fractionDigits value=?/>

A AT não tem "ignorado"... a AT sabe quem está em incumprimento, o já tinha dito que a qualquer momento poderia começar a aplicar COIMAS. Enquanto a AT não o fizer, haverão produtores de Software que deixam andar o barco ao sabor da maré...

1) "a partir de 1 de janeiro de 2025, a comunicação dos documentos de transporte à AT (Autoridade Tributária) sofrerá alterações." - O SOFTWARE sofrerá alterações, NÃO as exigências da AT! Isto tem a ver com o facto do Software ainda não estar preparado para comunicar o ATCUD nos documentos de transporte (o que já deveria estar pronto há muito muito tempo!) 2) "as séries dos documentos para o ano de 2025 devem ser comunicadas antes do final de 2024. O não cumprimento deste requisito poderá impedir a emissão de documentos." - Esta NÃO É uma exigência da AT, e é específica desse "software", que exige tal coisa, ou pelo menos tenta incutir "medo" nos clientes para comunicarem as SÉRIES em 2024! Tal NÃO FAZ qualquer sentido, pois em qualquer altura o cliente pode ter necessidade de criar séries... Parece-me apenas uma forma de pressionar os clientes a comunicarem tudo em 2024 por forma a não terem de lidar com "problemas" em 2025... Um sistema devidamente "automatizado" (ex: que comunique as séries no momento em que são utilizadas a PRIMEIRA vez) seria muito mais eficiente, mas cada um sabe de si!

Não vi a menção gratuito no teu post... Aliás, se o objectivo fosse ser gratuito, o estado teria de se responsabilizar pelo custo! Não é o caso... o estado colocou à disposição uma solução arcaica para dar um rebuçado a quem mais precisa. O cumprimento da lei não está dependente do serviço SAFE do estado...

O SAFE não é a única forma que existe para assinar documentos de facturação de acordo com a Lei actual... É normal existirem falhas... estamos dependentes de muitas infraestruturas, e basta uma falhar para o sistema colapsar parcialmente.

Desculpa, mas isso nunca aconteceu legalmente. Eu faco-o e sempre o defendi, mas nunca teve validade legal. Os PDF eram assinados com um certificado qualificado emitido em nome da EMPRESA, e assim podeiam continhar, não fosse a UE e as novas leis parvas terem introduzido a obrigação de apostar um SELO TEMPORAL. Daí a necessidade da assinatura ser feita por uma entidade credenciada e em TEMPO REAL. Isso é que esteagou a simplicidade e custo acessível do sistema!!! Anyway, para garantir a AUTENTICIDADE E NÃO ADULTERAÇÃO, volto a dizer, como sempre disse, a assinatura com o certificado do PRODUTOR do Software deveria ser obrigatória! Mas não!! Passamos de um sistema de assinatura com o certificado comprado pelas empresas, para um sistema em que qualquer PDF pode ser adulterado!!!! É uma palhaçada...

https://www.portugal-a-programar.pt/forums/topic/77364-at-questões-legais/page/337/#comment-633587

Mais do que um exemplo, convém LER a documentação, e entender as regras!! Mostrar um "resultado" sem entender as implicações, pode ser também receita para o desastre... Já vi muitas mensagens de referencias erradas ao que é o ATCUD, como é construido, ETC... Esta "dúvida" faz-me "suspeitar que o próprio ATCUD pode estar a ser incorrectamente gerado no próprio DOCUMENTO!!!

Mas porque é que vocês estão a discutir isto? Porque não consultam a informação / documentos técnicos da AT? Serviço de comunicação de DOCUMENTOS de TRANSPORTE! REGRAS do ATCUD! O ATCUD tem de ser do conhecimento do DOCUMENTO (uma vez que tem de ser "impresso"!) O serviço de DOCUMENTOS de TRANSPORTE requer que seja comunicado ESSE mesmo ATCUD! Nem vale a pena reinventar a roda... se a sua construção já está no "modelo" do documento (em código) basta aceder a esse "método" que estará definido algures! (a forma correcta, quanto a mim). Na pior das hipóteses, replicar esse código fonte (o que eu acho uma falha grave no desenvolvimento, porque no futuro é meio caminho andado para introduzir problemas)

INFORMAÇÃO ASSOFT A Autoridade Tributária é Aduaneira (AT) vai começar a notificar as entidades que procedem à emissão de documentos de faturação sobre a existência de erros relacionados com as séries, ATCUD e QRCode, nos casos em que isso efetivamente acontece. É, por conseguinte, razoável levar em consideração que alguns fabricantes de software venham a ser confrontados com este tipo de problemas, não obstante de poderem existir casos em que os erros tenham origem em software desatualizado ou a implementações deficientes por via dos seus parceiros. Não sabemos ainda se será executada em paralelo, mas a AT também tenciona notificar os emitentes de documentos de transporte para a existência de erros semelhantes aos descritos em cima, com destaque para a inexistência do elemento ATCUD no modelo de dados de comunicação por Webservice. Nesse sentido, somos em crer que é prudente aos fabricantes de software de faturação revisitarem o estado do desenvolvimento dos seus serviços, preparando-se, nos caos em que isso se justificar, para um aumento dos pedidos de suporte.

Estou a obter um "Received fatal alert: handshake_failure" (Java) em "todos" os webservices (séries documentais, documentos e documentos de transporte) Todos os certificados estão válidos... ChavePublicaAT.jks (234 days) TesteWebservices.pfx (96 days)

Se o orçamento já foi aprovado, sim... Mas é melhor consultar o documento "final" 😄

"Habemus" CIUS-PT & ESPAP 😄 (o resto são "tretas")

Até informação em contrário (e embora tenhamos implementada a versão 2_01), continuamos a exportar a versão 1_02 (que não contém o campo ClosingStockValue, como tal, o problema não se coloca...)

Como assim "PDFs com a estrutura que a AT determina"?