Ir para o conteúdo
  • Revista PROGRAMAR: Já está disponível a edição #60 da revista programar. Faz já o download aqui!

desconfiado

Norma europeia de fatura eletrónica: eInvoicing - Diretiva 2014/55/EU

Mensagens Recomendadas

desconfiado

Nuno, o formato é o mesmo. Partindo do principio que é UBL 2.1... acho que podemos assumir que será esse o formato escolhido.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Aralmar
21 minutos atrás, desconfiado disse:

Nuno, o formato é o mesmo. Partindo do principio que é UBL 2.1... acho que podemos assumir que será esse o formato escolhido.

Não creio que tenhamos essa sorte.

A comunicação para AT deverá ter menos informação, deverá seguir o que já existe para a comunicação em tempo real.

Enquanto que a comunicação da Factura Electrónica irá ter muito mais campos, aliás o próprio modelo prevê extensões ao CORE para fazer face a necessidades específicas que possam existir entre os intervenientes.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
jrabasilio

Alguém que tenha implementado isto em java me pode dar uma luz, estou com duvidas como colocar a assinatura no documento,

Estou a colocar no UBLExtensions  -> UBLExtension -> ExtensionContent -> UBLDocumentSignatures

Mas quando vou passar pelo marshal ele queixa-se do UBLDocumentSignatures ,  por que não tenho os namespaces....

Alguém já passou por isto.

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
marcolopes
4 hours ago, desconfiado said:

 

Atenção que os namespaces nas tags são obrigatórios.

Existem vários schemas separados no UBL por isso cada tag tem que indicar a que namespace pertence senão torna-se impossível fazer a validação correcta do XML. Até porque existem tags com o mesmo nome em namespaces diferentes.

Se ignorarem os namespaces nas tags a validação do ficheiro vai dar erro.

Nem percebo porque estão preocupados com isto... no vossos sistema de "integração / programação" basta usarem ferramentas para compilar o XSD, o resto é com as ferramentas... se coloca tags ou não, nem me vou preocupar... tudo depende das definições do XSD, digo eu!

  • Voto 1

The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nunopicado
2 horas atrás, desconfiado disse:

Nuno, o formato é o mesmo. Partindo do principio que é UBL 2.1... acho que podemos assumir que será esse o formato escolhido.

E achas que eles iam alterar o WebService actual para manter a coerência entre serviços? :cheesygrin: Tá bem, tá!
Para a AT, manter a coerência é fazer as coisas sem pensar no todo, só para complicar!


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
marcolopes
1 hour ago, jrabasilio said:

Alguém que tenha implementado isto em java me pode dar uma luz, estou com duvidas como colocar a assinatura no documento,

Estou a colocar no UBLExtensions  -> UBLExtension -> ExtensionContent -> UBLDocumentSignatures

Mas quando vou passar pelo marshal ele queixa-se do UBLDocumentSignatures ,  por que não tenho os namespaces....

Alguém já passou por isto.

 

Já aí vais? Ainda ontem compilei o XSD utilizando XMLBeans. Que tecnologia usaste? JAX?


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nunopicado
1 minuto atrás, marcolopes disse:

Nem percebo porque estão preocupados com isto... no vossos sistema de "integração / programação" basta usarem ferramentas para compilar o XSD, o resto é com as ferramentas... se coloca tags ou não, nem me vou preocupar... tudo depende das definições do XSD, digo eu!

Quando li isso pensei cá para mim:
 

Citação

O @marcolopes a responder em 3... 2... 1...

:cheesygrin:

  • Voto 1

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
marcolopes
2 hours ago, desconfiado said:

Nuno, o formato é o mesmo. Partindo do principio que é UBL 2.1... acho que podemos assumir que será esse o formato escolhido.

Volto a dizer que não existe UM FORMATO, existem DOIS!!! Ainda não li nada oficial que OBRIGUE as entidades PT a usarem UBL 2.1 (aliás, as recomendações da U.E. é que sejam suportados ambos os formatos, ou seja, quem RECEBE tem de suportar ambos, quem envia pode escolher...)

https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Explaining+the+eInvoicing+standard

https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Required+syntaxes

http://ubl.xml.org/book/export/html/234

UBL invoice and credit note messages as defined in ISO/IEC 19845:2015

UN/CEFACT Cross Industry Invoice XML message as specified in XML Schemas 16B (SCRDM - CII)


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
JorgeRocha

Boas pessoal …

Alguém tem alguma coisa feita em .net?

Usar a versão 2.1…

Isto é uma confusão total...

O que acontece com as faturas enviadas pela EDP que dizem ser uma fatura eletrónica ? Aquelas que compras um certificado ali na loja da esquina e assinas um PDF?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
CrominhO
Em 10/12/2018 às 09:25, jrabasilio disse:

O UBL 2.1 não tem o campo hash mas tem o campo signature.

http://docs.oasis-open.org/ubl/prd2-UBL-2.1/doc/dsig/cd11-UBL-DSig-1.0.html

Não é a mesma coisa. Não é por acaso que nas Farmácias eles acrescentaram o campo HASH. Uma coisa é cumprir a Legislação da FE, como o @marcolopes diz em cima, outra bem diferente é cumprir a legislação dos campos necessários na emissão da Factura. A FE até pode ser um ficheiro de texto simples, assinado com RSA, cumprindo os requisitos todos, envio e entrega, etc... Outra é esse ficheiro ter os campos necessários à emissão da FT, se a memória não me falha 36º do CIVA. 

O @marcolopes disse mais uma vez, e muito bem, aquilo que já havíamos dito algumas vezes, a FE vs a Facturação para a Função Publica. Os sistemas de Facto são diferentes e não devem ser misturados, mas a questão principal (para mim), é, a Facturação para a Função Publica tem "cabimento" dentro da Legislação da FE?   e a meu ver tem, mas falta campos e desaparece o "intermediário" que garantia o envio e a entrega do documento. Porque na FE nunca é dito que tem de ser em PDF, XML, TXT, ou whatever, como tal pode ser em XML UBL 2.1, agora não tendo os campos necessários, deixa de ser válido. 

Hoje falou-se do ViaCTT, não quis falar porque achei que nao tinha muito a acrescentar. Mas no que toca à FE e à actual legislação, eles são o tal "intermediário" que a legislação fala. Daí o @americob ter referido e bem também, que pouco interessa se o cliente vai ver ou não, uma vez lá o Documento, é considerado entregue. Situação que também desaparece com a Facturação para a Função Publica. 

 

Resumo, e repetindo-me, a Facturação para a função Publica tem cabimento dentro da FE ??? a meu ver tem mas faltam campos... Provavelmente alguns acharão que não, e outros (que andam a dizer que têm os softwares prontos, acham que sim). De resto, só isto justifica que alguns digam que estão prontos. 

Mas a meu ver a AT deveria pronunciar-se sobre isto... eu nao vou meter o HASH no campo signature, porque a FT não é válida enquanto FT.

 

  • Voto 1

As mentes humanas são realmente um local estranho!

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
jrabasilio
11 horas atrás, marcolopes disse:

Já aí vais? Ainda ontem compilei o XSD utilizando XMLBeans. Que tecnologia usaste? JAX?

Utilizei o xjc do java /bin

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nunopicado
2 minutos atrás, jrabasilio disse:

Utilizei o xjc do java /bin

Ainda bem que criaste o ficheiro string a string, senão o @marcolopes ficava possesso! :D


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
jasb
Em 11/12/2018 às 06:47, marcolopes disse:

Discordo!!!! O VIA CTT é um serviço excelente e que nenhuma outra empresa implementou. Desde que foi lançado que uso para receber todos os documentos das empresas aderentes. Há que lembrar que o VIA CTT, sendo um serviço de recepção e ARQUIVO documental que requer AUTENTICAÇÃO através do CARTÃO do CIDADÃO (na adesão) substitui a OBSOLETO e desaconselhável serviço de REGISTO dos CTT... (isto de ter de ir À caixa do correio ou levantar cartas registadas nas estações do CTT, com dias de atraso, ou problemas na entrega, é coisa de doidos - quantas vezes tenho REGISTOS dos vizinhos na minha caixa de correio, que só abro UMA VEZ POR MES!!!)

Não é que seja bom ou mau, o estado nao tem que enviar essa informação dos contribuintes para la.
Todos sabemos, que isto serve para respionagem, ingenuo de quem não acreditar ou pensar que é impossivel.

E o que o estado paga aos CTT, paga o serviço na totalidade, os outros clientes são "pins" como diz um cliente meu.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
JorgeRocha

Agradeço a explicação marcolopes

Eu tinha percebido isso, a parte de fazer faturas eletrónicas é simples.

Eu não entendo como começo com esse coisa do UBL 2.1. Fala-se em ferramentas para fazer isso, mas se isto é baseado em xml. é só escrever xml.

Onde posso encontrar a estrutura para Portugal ? Não devia existir um formato tal como acontece no saft ? Relembro que o saft foi "desenhado" pela OCDE e que o tuga tem uma especificação, o saft-pt.

e a parte de envio como isso funciona (eu tenho saft mas não webservices)

(Pelo que percebo as minhas duvidas são transversais)

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nunopicado
41 minutos atrás, JorgeRocha disse:

Eu não entendo como começo com esse coisa do UBL 2.1. Fala-se em ferramentas para fazer isso, mas se isto é baseado em xml. é só escrever xml.

Sim, é só escrever o XML. Mas o que o @marcolopes defende (e bem, a meu ver) é que não se crie o XML "à unha", e sim se use o XSD correspondente junto com as ferramentas que cada linguagem de programação tem para que o XML seja criado automaticamente com base nas regras estipuladas pelo XSD.

 

41 minutos atrás, JorgeRocha disse:

Onde posso encontrar a estrutura para Portugal ? Não devia existir um formato tal como acontece no saft ? Relembro que o saft foi "desenhado" pela OCDE e que o tuga tem uma especificação, o saft-pt.

Tanto quanto se sabe à data, ainda não há nenhuma estrutura específica para Portugal do UBL 2.1
O que se espera é que saia entretanto uma portaria com indicação específica de uma adaptação do UBL 2.1 para a realidade portuguesa (por exemplo que inclua o campo HASH).

Dito isto, anda uma circular a... circular (:cheesygrin:) aqui nas minhas bandas, proveniente da autarquia, que dá a entender que o formato é o UBL 2.1 usado a nível europeu (seja ele qual for) e que deve incluir o campo "Número de Compromisso" (seja isso o que for), os restantes campos normais das facturas, e quaisquer outros campos que o fornecedor decidir que devem constar.

Diz esta circular ainda que a acompanhar o XML (que deve ser enviado por email para a autarquia - lá cai por terra a teoria do WS centralizado só para isto), deve seguir também um PDF assinado, de acordo com a outra lei portuguesa sobre facturação electrónica.

Se isto significar o que eu acho que significa, meus caros colegas, temos aqui algo tipo um Champô + Amaciador, vulgo 2 em 1. Uma dobradinha, e tal como a pescada, de rabo na boca...

O que vale é que é natal, e daqui a nada o ano novo trás-nos vida nova... 
Ou não!

 

Aliás...
Como independentemente disto, as facturas ainda têm de ser comunicadas à AT por WebService, temos aqui o belo do hat-trick!
Se o Ronaldo fosse programador, talvez não se incomodasse muito! ;)

Editado por nunopicado
  • Voto 1

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
JorgeRocha

Obrigado @nunopicado

Sobre o XML ok, eu por acaso para fazer o saft não uso esse conceito, mas escrevo direto...

Mas voltando ao UBL 2.1, percebo que se tenha de especificar, alem do compromisso também pode haver o numero de cabimento…, indicar a nota de encomenda etc etc.

Para quem viu o formato do UBL 2,1 é de fácil leitura ? Será que vale a pena esperar pela especificação ?

Agora essa de mandar um pdf assinado tb é que me parece altamente, mas mesmo muito la em cima, redundante, para que ? 

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nunopicado
1 hora atrás, JorgeRocha disse:

Sobre o XML ok, eu por acaso para fazer o saft não uso esse conceito, mas escrevo direto...
(...)
Para quem viu o formato do UBL 2,1 é de fácil leitura ? Será que vale a pena esperar pela especificação ?

Não sei se neste queres fazer directo...
Exemplo: A estrutura de classes criada em Delphi a partir do XSD apenas para o documento Invoice dá quase 30 mil linhas de código.
Se pensarmos que tens de preparar pelo menos Faturas, Notas de Crédito e Notas de Débito, estamos a falar de perto de 90 mil linha de código. Mesmo com as diferenças normais entre linguagens, não deverá ser substancialmente diferente disto.

Logicamente que escrevendo à mão só irás incluir os campos obrigatórios (que a esta altura não sabemos quais são), mas ainda assim estamos a falar de muito código escrito. É uma estrutura não muito difícil, parece-me, mas extensa. Além de que está carregada de namespaces, cuja criação 'manual' dá uma trabalheira acrescida.

Com a criação de classes, ficas com os objectos já definidos com todo o código de infraestrutura criado automaticamente, e tu só lhe metes os valores.
Parece-me bem mais viável, além de que baixa e muito a possibilidade de erros.

 

1 hora atrás, JorgeRocha disse:

Agora essa de mandar um pdf assinado tb é que me parece altamente, mas mesmo muito la em cima, redundante, para que ? 

Espero que não se lembrem todos disto, mas a partir do momento que um se lembra (como neste caso), já está aberta a porta para dar barraca.

Editado por nunopicado
  • Voto 1

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Pedro Robalo

Alguém sabe onde posso consultar as tabelas auxiliares para preencher os vários id existentes?!?!

Não estou a  encontrar onde consultar esta informação.

Exemplo:

 InvoiceTypeCode = new CodeType
                {
                    listID = "UN/ECE 1001 Subset",
                    listAgencyID = "6",
                    Value = "380"
                },
  Note = new List<TextType>()
                {
                    new TextType
                    {
                        languageID = "en",
                        Value = "Ordered in our booth at the convention."
                    }
                },
 DocumentCurrencyCode = new CodeType
                {
                    listID = "ISO 4217 Alpha",
                    listAgencyID = "6",
                    Value = "EUR"
                },

 

 

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
chesser
2 horas atrás, JorgeRocha disse:

Agora essa de mandar um pdf assinado tb é que me parece altamente, mas mesmo muito la em cima, redundante, para que ? 

Para quê o pdf? Talvez porque o sistema deles (e se calhar de muitas outras empresas do estado) não está preparado para ler o tal xml. Se lhe enviássemos apenas o ubl, teríamos o clássico burro a olhar para o palácio, já que não iam conseguir fazer nada com ele. Assim, recebem o xml e ficam todos contentes porque estão a cumprir a norma europeia, e o pdf é o que provavelmente vão utilizar para fazerem as coisas como faziam até agora (isto é, lançar manualmente o documento no sistema deles). E, se calhar, para cúmulo, ainda imprimem o pdf, para arquivar nas tradicionais capas pretas. :)

  • Voto 1

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Charlie

De facto, o formato é UBL 2.1, e já está definido à mais de um ano (o manual é de Abril de 2017).

Manual fornecido pela eSPap sobre o formato.

Oficialmente, temos a data de 1 de Janeiro 2019 para o kick-off, mas a eSPap não está a dar resposta aos fornecedores que se querem registar e iniciar o envio dos ficheiros, quer em testes quer em produção.

Está tudo em alvoroço porque não sai nenhuma portaría ou informação oficial sobre o tema. Aparentemente, deveria ter saido comunicação a 28 de Novembro.

Alguém têm alguma inside information sobre o adiamento da data?

  • Voto 2

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nunopicado
20 minutos atrás, chesser disse:

Para quê o pdf? Talvez porque o sistema deles (e se calhar de muitas outras empresas do estado) não está preparado para ler o tal xml. Se lhe enviássemos apenas o ubl, teríamos o clássico burro a olhar para o palácio, já que não iam conseguir fazer nada com ele. Assim, recebem o xml e ficam todos contentes porque estão a cumprir a norma europeia, e o pdf é o que provavelmente vão utilizar para fazerem as coisas como faziam até agora (isto é, lançar manualmente o documento no sistema deles). E, se calhar, para cúmulo, ainda imprimem o pdf, para arquivar nas tradicionais capas pretas. :)

É muito triste realizar que realmente tens razão? :D
É que é bem capaz de ser isso! Aliás, agora que falaste, nem tenho dúvida nenhuma! :cheesygrin:

  • Voto 1

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
CrominhO
56 minutos atrás, chesser disse:

Para quê o pdf? Talvez porque o sistema deles (e se calhar de muitas outras empresas do estado) não está preparado para ler o tal xml. Se lhe enviássemos apenas o ubl, teríamos o clássico burro a olhar para o palácio, já que não iam conseguir fazer nada com ele. Assim, recebem o xml e ficam todos contentes porque estão a cumprir a norma europeia, e o pdf é o que provavelmente vão utilizar para fazerem as coisas como faziam até agora (isto é, lançar manualmente o documento no sistema deles). E, se calhar, para cúmulo, ainda imprimem o pdf, para arquivar nas tradicionais capas pretas. :)

LOL 😂 Os meus não permitem, a menos que 1 vá como 2ª via LOL  😂 ... Não havia a questão de contar o numero de impressões por causa da "dupla dedução"?? então agora vou enviar 2 Faturas iguais e assinadas para a Camara Municipal? Os meus não dão :D 


As mentes humanas são realmente um local estranho!

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
chesser
58 minutos atrás, Charlie disse:

De facto, o formato é UBL 2.1, e já está definido à mais de um ano (o manual é de Abril de 2017).

Manual fornecido pela eSPap sobre o formato.

Oficialmente, temos a data de 1 de Janeiro 2019 para o kick-off, mas a eSPap não está a dar resposta aos fornecedores que se querem registar e iniciar o envio dos ficheiros, quer em testes quer em produção.

Está tudo em alvoroço porque não sai nenhuma portaría ou informação oficial sobre o tema. Aparentemente, deveria ter saido comunicação a 28 de Novembro.

Alguém têm alguma inside information sobre o adiamento da data?

Muito obrigado pela partilha, Charlie. O manual, vendo assim muito rapidamente, parece-me bastante detalhado. A minha questão é: teremos nós de "dialogar" com a Saphety?

Por acaso não conhecia a tal eSPap. Então fui ao site deles procurar mais informação. Procurando por factura electrónica, cheguei a uma notícia deles, do dia 6-11-2018, em que podemos ler o seguinte:

"Incorporada no relatório do OE2019, no âmbito das Políticas de Estratégia de Crescimento Económico e Consolidação Orçamental, o projeto de implementação da fatura eletrónica é assumido como um programa de transformação digital assente numa nova abordagem baseada na normalização, otimização e automatização processual dos ciclos completos da despesa e da receita.

Lançado em 2015, com a transposição da Diretiva Europeia 2014/55/EU, o avanço deste projeto é uma realidade, à data com a solução de receção de faturas já em operação em ambiente produtivo nas três entidades que originalmente integraram o projeto como pilotos: Autoridade Tributária e Aduaneira, a Agência para a Modernização Administrativa, I.P. e o Camões I.P. Estas entidades foram escolhidas atendendo à dimensão e estrutura adequadas a teste e experimentação prévia à disseminação das soluções.
Este programa será executado gradualmente, garantindo a gestão da mudança para implementação efetiva dos seus objetivos, assim como a definição dos normativos legais adicionais necessários.
Serão ganhos imediatos com este projeto a possibilidade de agilizar e desmaterializar a interação existente entre as entidades públicas, e destas com os agentes económicos privados, a redução de custos processuais e a otimização da Gestão de Tesouraria preconizada pela nova Lei de Enquadramento Orçamental.
Numa fase seguinte do projeto é esperada a disponibilização da solução de receção e integração de faturas recebidas de fornecedores, de forma alargada às Administrações Públicas."

Editado por chesser

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
jasb
1 hora atrás, chesser disse:

Para quê o pdf? Talvez porque o sistema deles (e se calhar de muitas outras empresas do estado) não está preparado para ler o tal xml. Se lhe enviássemos apenas o ubl, teríamos o clássico burro a olhar para o palácio, já que não iam conseguir fazer nada com ele. Assim, recebem o xml e ficam todos contentes porque estão a cumprir a norma europeia, e o pdf é o que provavelmente vão utilizar para fazerem as coisas como faziam até agora (isto é, lançar manualmente o documento no sistema deles). E, se calhar, para cúmulo, ainda imprimem o pdf, para arquivar nas tradicionais capas pretas. :)

Mas é que não tenho qualquer duvida nisso!

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.