Jump to content

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


Recommended Posts

jcleite
12 horas atrás, JorgeRocha disse:

Boas 

Finalmente consegui assinar documentos xml via XAdES (https://www.w3.org/TR/XAdES/).

O Validador Online diz que esta correto, mas alguém sabe onde as tags tem de estar ? Eu não consigo encontrar info sobre isto.

Tou a falar da ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

Obrigado

 

Depende se estamos a utilizar uma assinatura enveloped ou enveloping. Para uma assinatura enveloped, o elemento signature é posicionado após o último elemento xml do documento, imediatamente anterior ao fecho do elemento root.

Algo como:

<ubl:Invoice>
    (...)
    </cac:InvoiceLine>
    
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-1663778174">
        (...)
    </ds:Signature>
</ubl:Invoice>
  • Vote 1
Link to post
Share on other sites
  • Replies 703
  • Created
  • Last Reply

Top Posters In This Topic

  • marcolopes

    116

  • CrominhO

    88

  • desconfiado

    45

  • Vitor Pereira

    37

Top Posters In This Topic

Popular Posts

Ao contrário do passado com as guias de transporte e faturas, quem precisar de exemplo e implementação da Fatura Eletrónica XML em UBL que diga. Com validador incluído.

OK malta, ainda pensei que isto ia lá depois de esfumarem um pouco, mas estou a ver que não... Daqui a tempos, alguém, quem sabe um de vocês, vai precisar pesquisar uma cena qualquer no tópico, e o q

Sabem o que vos digo,  já comuniquei com eles pela(s) Empresa(s), super simpáticos, mas nem um Sim nem um Não, foi um NIN. Por enquanto é grátis e depois logo se vê.  Já comuniquei a título

JorgeRocha
10 horas atrás, jcleite disse:

Depende se estamos a utilizar uma assinatura enveloped ou enveloping. Para uma assinatura enveloped, o elemento signature é posicionado após o último elemento xml do documento, imediatamente anterior ao fecho do elemento root.

Algo como:


<ubl:Invoice>
    (...)
    </cac:InvoiceLine>
    
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-1663778174">
        (...)
    </ds:Signature>
</ubl:Invoice>

Obrigado.

é isso mesmo que esta a acontecer.

Jorge Rocha

Link to post
Share on other sites

Já alguém consegui validar uma fatura aqui https://ppr-svc.feap.gov.pt/Doc.Client/public/CIUSvalidation/PT?language=pt

Estou a tentar validar este xml e não estou a consegui validar as taxas de IVA

<?xml version="1.0" encoding="utf-8"?>
<Invoice xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" 
xmlns:ebc="urn:oasis:names:specification:ubl:schema:xsd:BasicComponents-2" 
xmlns:eac="urn:oasis:names:specification:ubl:schema:xsd:AggregateComponents-2" 
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
  <cbc:CustomizationID>UBL-2.1-eSPap</cbc:CustomizationID>
  <cbc:ProfileID>urn:www:espap:pt:profiles:profile1:ver1.0</cbc:ProfileID>
  <cbc:ID>FT FT19/125</cbc:ID>
  <cbc:IssueDate>2021-02-03</cbc:IssueDate>
  <cbc:DueDate>2021-03-03</cbc:DueDate>
  <cbc:InvoiceTypeCode listID="UNCL1001">380</cbc:InvoiceTypeCode>
  <cbc:Note>Descrição sobre o documento</cbc:Note>
  <cbc:DocumentCurrencyCode listID="ISO4217">EUR</cbc:DocumentCurrencyCode>
  <cac:InvoicePeriod>
    <cbc:StartDate>2021-02-03</cbc:StartDate>
    <cbc:EndDate>2021-02-03</cbc:EndDate>
    <cbc:Description />
  </cac:InvoicePeriod>
  <cac:OrderReference>
    <cbc:ID />
  </cac:OrderReference>
  <cac:OriginatorDocumentReference>
    <cbc:ID>NANAN</cbc:ID>
  </cac:OriginatorDocumentReference>
  <cac:ContractDocumentReference>
    <cbc:ID>AAAAAA</cbc:ID>
  </cac:ContractDocumentReference>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cac:PartyName>
        <cbc:Name>Empresa LDA</cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Rua da empresa</cbc:StreetName>
        <cbc:AdditionalStreetName>3999-999 Coimbra</cbc:AdditionalStreetName>
        <cbc:CityName>Coimbra</cbc:CityName>
        <cbc:PostalZone>3999-999</cbc:PostalZone>
        <cbc:CountrySubentity>Coimbra</cbc:CountrySubentity>
        <cac:Country>
          <cbc:IdentificationCode listID="ISO3166-1:Alpha2">PT</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>PT999999990</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:CompanyID>Registo conservatória</cbc:CompanyID>
      </cac:PartyLegalEntity>
      <cac:Contact>
        <cbc:Telephone>231231231</cbc:Telephone>
        <cbc:ElectronicMail>suporte@solria.pt</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cac:PartyName>
        <cbc:Name>Nome do cliente</cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName />
        <cbc:AdditionalStreetName />
        <cbc:CityName>AVEIRO</cbc:CityName>
        <cbc:PostalZone>3040-399</cbc:PostalZone>
        <cbc:CountrySubentity>AVEIRO</cbc:CountrySubentity>
        <cac:Country>
          <cbc:IdentificationCode listID="ISO3166-1:Alpha2">PT</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>PT</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:Contact>
        <cbc:Telephone>231231231</cbc:Telephone>
        <cbc:ElectronicMail>suporte@solria.pt</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingCustomerParty>
  <cac:PayeeParty>
    <cac:PartyName>
      <cbc:Name>Nome entidade pagadora</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
      <cbc:StreetName />
      <cbc:AdditionalStreetName />
      <cbc:CityName>AVEIRO</cbc:CityName>
      <cbc:PostalZone>3040-399</cbc:PostalZone>
      <cbc:CountrySubentity />
      <cac:Country>
        <cbc:IdentificationCode listID="ISO3166-1:Alpha2">PT</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyTaxScheme>
      <cbc:CompanyID>PT654654654</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>
  </cac:PayeeParty>
  <cac:AllowanceCharge>
    <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
    <cbc:Amount currencyID="EUR">23.98</cbc:Amount>
    <cac:TaxCategory>
      <cbc:ID>NOR</cbc:ID>
      <cbc:Percent>23</cbc:Percent>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:TaxCategory>
  </cac:AllowanceCharge>
  <cac:PaymentTerms>
    <cbc:Note>Pagamento imediato s/desconto</cbc:Note>
  </cac:PaymentTerms>
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">5.52</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">23.98</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">5.52</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>NOR</cbc:ID>
        <cbc:Percent>23</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">23.98</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">23.98</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">29.5</cbc:TaxInclusiveAmount>
    <cbc:AllowanceTotalAmount currencyID="EUR">0</cbc:AllowanceTotalAmount>
    <cbc:ChargeTotalAmount currencyID="EUR">0</cbc:ChargeTotalAmount>
    <cbc:PrepaidAmount currencyID="EUR">0</cbc:PrepaidAmount>
    <cbc:PayableRoundingAmount currencyID="EUR">0</cbc:PayableRoundingAmount>
    <cbc:PayableAmount currencyID="EUR">29.5</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
  <cac:InvoiceLine>
    <cbc:ID>Id.DeviceId</cbc:ID>
    <cbc:Note>descrição do produto</cbc:Note>
    <cbc:InvoicedQuantity unitCode="">1</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">23.98</cbc:LineExtensionAmount>
    <cac:InvoicePeriod>
      <cbc:StartDate>2021-02-03</cbc:StartDate>
      <cbc:EndDate>2021-02-03</cbc:EndDate>
      <cbc:Description>2021/02/03 13:39:27</cbc:Description>
    </cac:InvoicePeriod>
    <cac:OrderLineReference>
      <cbc:LineID>Nota encomenda</cbc:LineID>
    </cac:OrderLineReference>
    <cac:Item>
      <cbc:Description>Descrição</cbc:Description>
      <cbc:Name>Nome</cbc:Name>
      <cac:BuyersItemIdentification>
        <cbc:ID />
      </cac:BuyersItemIdentification>
      <cac:SellersItemIdentification>
        <cbc:ID>Código produto</cbc:ID>
      </cac:SellersItemIdentification>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>NOR</cbc:ID>
        <cbc:Percent>23</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">23.98</cbc:PriceAmount>
      <cbc:BaseQuantity unitCode="">1</cbc:BaseQuantity>
    </cac:Price>
  </cac:InvoiceLine>
</Invoice>

 

Link to post
Share on other sites
CrominhO

Pessoal e o alojamento durante os 15 anos, alguém sabe alguma coisa? e a auditoria por terceiros? 

a eSPAP faz? ou temos sempre de recorrer a um broker?

 

As mentes humanas são realmente um local estranho!

Link to post
Share on other sites
jcleite
Em 04/02/2021 às 15:11, kalin disse:

Já alguém consegui validar uma fatura aqui https://ppr-svc.feap.gov.pt/Doc.Client/public/CIUSvalidation/PT?language=pt

Estou a tentar validar este xml e não estou a consegui validar as taxas de IVA

 

O ficheiro UBL anexo tem mais erros de schematron que os especificados. A razão para não serem apresentados é porque não está a ser reconhecida como ubl invoice. Falta-lhe o namespace para ubl invoice.

Para isso acontecer, no root element, substuir:

<Invoice xmlns:cbc=

Por:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cbc=

Esse validador, valida primeiro os erros de schema (XSD) e só depois os erros de schematron. Significa, isto, que após a correção do namespace, ao submeter o ficheiro, irá ser obtido um erro de XSD que tem a ver com o elemento <cac:PaymentTerms> estar mal posicionado em relação à definição ubl invoice.

Para funcionar, no exemplo especificado, colocar esse elemento a seguir a </cac:PayeeParty> .Algo como:

  </cac:PayeeParty>
   <cac:PaymentTerms>
    <cbc:Note>Pagamento imediato s/desconto</cbc:Note>
  </cac:PaymentTerms>
  <cac:AllowanceCharge>

Após esta correção relativa ao XSD, ao submeter, ir-se-á obter mais de 20 erros semânticos validados pelas definições schematron, sendo que a maior parte, têm a ver com o facto do xml ter elementos vazios, faltarem compos obrigatórios e os decimais têm de ter 2 ou mais casas decimais.

Relativamente a erros de calculos, vi que estava a ser usado um encargo global (<cac:AllowanceCharge>). O valor desse encargo tem de ser incluido nos totais e no elemento <cbc:ChargeTotalAmount>.

O excel no link abaixo, especifica todas estas regras, campos obrigatórios e formatos dos decimais.

https://www.espap.gov.pt/Documents/servicos/sp_fin/Representacao_Sintaxica_CIUS-PT_UBL2.1_V2.0.0.xlsx.zip

  • Vote 1
Link to post
Share on other sites
1 hora atrás, jcleite disse:

O ficheiro UBL anexo tem mais erros de schematron que os especificados. A razão para não serem apresentados é porque não está a ser reconhecida como ubl invoice. Falta-lhe o namespace para ubl invoice.

Para isso acontecer, no root element, substuir:

<Invoice xmlns:cbc=

Por:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:cbc=

Esse validador, valida primeiro os erros de schema (XSD) e só depois os erros de schematron. Significa, isto, que após a correção do namespace, ao submeter o ficheiro, irá ser obtido um erro de XSD que tem a ver com o elemento <cac:PaymentTerms> estar mal posicionado em relação à definição ubl invoice.

Para funcionar, no exemplo especificado, colocar esse elemento a seguir a </cac:PayeeParty> .Algo como:

  </cac:PayeeParty>
   <cac:PaymentTerms>
    <cbc:Note>Pagamento imediato s/desconto</cbc:Note>
  </cac:PaymentTerms>
  <cac:AllowanceCharge>

Após esta correção relativa ao XSD, ao submeter, ir-se-á obter mais de 20 erros semânticos validados pelas definições schematron, sendo que a maior parte, têm a ver com o facto do xml ter elementos vazios, faltarem compos obrigatórios e os decimais têm de ter 2 ou mais casas decimais.

Relativamente a erros de calculos, vi que estava a ser usado um encargo global (<cac:AllowanceCharge>). O valor desse encargo tem de ser incluido nos totais e no elemento <cbc:ChargeTotalAmount>.

O excel no link abaixo, especifica todas estas regras, campos obrigatórios e formatos dos decimais.

https://www.espap.gov.pt/Documents/servicos/sp_fin/Representacao_Sintaxica_CIUS-PT_UBL2.1_V2.0.0.xlsx.zip

 

 

Obrigado, realmente falhou-me esse namespace

Link to post
Share on other sites
Jose Silva

Estou a submeter o ficheiro xml no site espap e com a fatura não tenho problemas, mas com a NC, usando o codigo 381, este diz-me que não existe, dando o erro 

"[DT-CIUS-PT-003]-The BT-3 only allows the following values: 380, 383, 386, 389, FT, FS, FR, ND, RP, RE, CS, LD, RA."

Alguem já testou as notas de crédtio? 

E qual o código que utilizam?

Link to post
Share on other sites
58 minutos atrás, Jose Silva - Portugal disse:

Estou a submeter o ficheiro xml no site espap e com a fatura não tenho problemas, mas com a NC, usando o codigo 381, este diz-me que não existe, dando o erro 

"[DT-CIUS-PT-003]-The BT-3 only allows the following values: 380, 383, 386, 389, FT, FS, FR, ND, RP, RE, CS, LD, RA."

Alguem já testou as notas de crédtio? 

E qual o código que utilizam?

Estás a usar o validador? Alteras o tipo de documento para Nota de Crédito?

Link to post
Share on other sites
jcleite
2 hours ago, Jose Silva - Portugal said:

Estou a submeter o ficheiro xml no site espap e com a fatura não tenho problemas, mas com a NC, usando o codigo 381, este diz-me que não existe, dando o erro 

"[DT-CIUS-PT-003]-The BT-3 only allows the following values: 380, 383, 386, 389, FT, FS, FR, ND, RP, RE, CS, LD, RA."

Alguem já testou as notas de crédtio? 

E qual o código que utilizam?

Para as notas de crédito não se pode utilizar o elemento raíz Invoice.

Tem de ser usado o elemento raíz CreditNote. Algo como:

<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"

Só para lembrar que apesar de praticamente todos os elementos da Invoice se aplicarem à CreditNote, existem algumas diferenças. Por exemplo, o nome dos elementos das linhas é diferente.

Edited by jcleite
Link to post
Share on other sites
João Januário

Se me podem ajudar. 

Estive em várias reuniões com os brokers que me disseram que tenho de ter uma integração para cada um para poder comunicar com a AP. Porque cada entidade tem brokers diferentes. Isso é verdade? Custa acreditar. 

Outra questão. Se alguém tiver uma API implementada de integração com algum broker ou esteja disponível a fazer. Estamos disponíveis a falar e acertar um valor. 

Link to post
Share on other sites
Jose Silva
15 hours ago, João Januário said:

Se me podem ajudar. 

Estive em várias reuniões com os brokers que me disseram que tenho de ter uma integração para cada um para poder comunicar com a AP. Porque cada entidade tem brokers diferentes. Isso é verdade? Custa acreditar. 

Outra questão. Se alguém tiver uma API implementada de integração com algum broker ou esteja disponível a fazer. Estamos disponíveis a falar e acertar um valor. 

Boas,

Tambem me aconteceu isso, com a Saphety, Seres, etc. Depois contactei a EfaturaGov, do grupo compraspt, e conseguiram-me explicar melhor a situação.
Pelo que parece, não precisamos de ter a aplicação integrada com cada broker existente, mas selecionar um, e eles internamente fazem a comunicação com o broker do cliente.
Neste caso, nem existe integração, eles utilizam o XML do CIUS-PT, usado no ESPAP.
Assim torna mais fácil a implementação.

Link to post
Share on other sites
desconfiado
2 horas atrás, Jose Silva - Portugal disse:

Boas,

Tambem me aconteceu isso, com a Saphety, Seres, etc. Depois contactei a EfaturaGov, do grupo compraspt, e conseguiram-me explicar melhor a situação.
Pelo que parece, não precisamos de ter a aplicação integrada com cada broker existente, mas selecionar um, e eles internamente fazem a comunicação com o broker do cliente.
Neste caso, nem existe integração, eles utilizam o XML do CIUS-PT, usado no ESPAP.
Assim torna mais fácil a implementação.

Acho que não é bem assim. Pelo menos a Saphety não é assim. Eles comunicam os documentos que forem enviados para eles e cujo destinatário seja uma entidade da eSpap (algumas acho que nem é para todas). Mas não enviam para outros brokers.

Até porque para enviarem para outros brokers teriam que ter a informação de qual seria o broker destinatário. E eles não têm essa informação.

  • Vote 2
Link to post
Share on other sites
CrominhO
3 horas atrás, Jose Silva - Portugal disse:

Boas,

Tambem me aconteceu isso, com a Saphety, Seres, etc. Depois contactei a EfaturaGov, do grupo compraspt, e conseguiram-me explicar melhor a situação.
Pelo que parece, não precisamos de ter a aplicação integrada com cada broker existente, mas selecionar um, e eles internamente fazem a comunicação com o broker do cliente.
Neste caso, nem existe integração, eles utilizam o XML do CIUS-PT, usado no ESPAP.
Assim torna mais fácil a implementação.

Estou como o @desconfiado, acho que a Unica que comunica é a Saphety com a eSPAP, uma vez que a eSPAP alugou lá o espaço. De resto, já conto com 6 brokers diferentes... Mas volto a bater na mesma tecla, isto é de uma gravidade que nunca vi. Então se a eSPAP é gratuito para empresas publicas, se a FE-AP é para empresas publicas, porque é que cada empresa publica escolhe um broker PAGO??? :-\  Não fica centralizado, obriga a que os clientes que tenham clientes de vários brokers tenham que se registar nos mais diversos brokers, e pior ainda, roubam milhoes ao estado :! , diga-se, todos nós :-| ... ou eu estou a ver muito mal as coisas ou nao se percebe porque uma Empresa Publica, tendo o estado criado um "operador" publico gratuito opta por um "operador" privado gastando milhares 

  • Vote 1

As mentes humanas são realmente um local estranho!

Link to post
Share on other sites

Isto é a verdadeira palhaçada, a Saphety comunica com a eSPAP, a API dele vai ser lançada em breve, o problema e que temos clientes que trabalham com muitos municípios e universidades, ora se tiver de andar a fazer ligações a todos os brokers vai ser um trabalho medonho, já para não falar no custo que os clientes vão ter porque existem brokers que só a ligação custa 500€ e depois têm custo por documento. Isto a meu ver resolvia-se fácil, nos comunicávamos com a eSPAP, e depois os brokers dos organismos iam la buscar os documentos.... Mas não é isto que esta a acontecer, não existe interoperabilidade entre ninguém 

  • Vote 2
Link to post
Share on other sites
Jose Silva
4 hours ago, desconfiado said:

Acho que não é bem assim. Pelo menos a Saphety não é assim. Eles comunicam os documentos que forem enviados para eles e cujo destinatário seja uma entidade da eSpap (algumas acho que nem é para todas). Mas não enviam para outros brokers.

Até porque para enviarem para outros brokers teriam que ter a informação de qual seria o broker destinatário. E eles não têm essa informação.

Eu compreendo a questão, e é demasiado confuso. Mas a informação que tenho, é que aderem ao serviço, e independentemente do broker do destinatário (que é comunicado com base no cliente), eles fazem essa comunicação.
De todos os brokers que contactei, foi o único que transmitiu essa informação e, sendo assim, facilitava muito!!

Link to post
Share on other sites
marcolopes
59 minutes ago, CrominhO said:

Eu tenho sobre parte.  Não sobre tudo. 

Mas isto é uma coisa que nos ultrapassa, não se trata só, de resto como até agora, de umas pessoas que estão sentadas e decidem sem conhecimento de causa, e de com isso fazerem-nos andar à pesca e fazer os clientes andarem a registar-se e a pagar em cada Broker, o que é surreal. 

Aqui vai mais longe. A ser verdade o que falamos e o que penso sobre a situação, exijo enquanto cidadão Português, saber porque raio um Município paga meio milhão para implementação de  um sistema de um Broker, obrigando todos os fornecedores a trabalhar com esse broker, quando na eSPAP é gratuito. Just that...

Isto merecia uma participação ao Tribunal de contas. Pensava eu que o País era pobre, afinal sou só eu, o País é muita rico, para cada Municipio por exemplo, ter o seu Broker e gastar milhares quando há uma solução gratuita, só pode ser um País rico

 

EDIT: https://www.espap.gov.pt/spfin/Paginas/spfin.aspx#maintab5

"A eSPap coordena a implementação da Fatura Eletrónica na Administração Pública (FE-AP). Com o Decreto-Lei n.º 123/2018, de 28 de dezembro, (ver linguagem clara) foi atribuída à eSPap a competência para emitir requisitos técnicos e funcionais que suportem a implementação da faturação eletrónica, desenvolver instrumentos de apoio às entidades abrangidas e fornecer a solução para receção e processamento de faturas eletrónicas. O valor a pagar pela solução será aprovado por despacho do membro do Governo responsável pela área das finanças"

Tirado hoje.

Mais claro que isto é impossível. À eSPAP, além de coordenar a implementação, compete desenvolver instrumentos e fornecer a solução para a receção e processamento de facturas electronicas. O valor a pagar pela solução, será aprovado por despacho. 

E agora os Brokers? e as centenas de milhares e milhares que já foram gastos???  😐

Mais do que isso, merecia uma DECLARAÇÃO ESCRITA e TOTALMENTE esclarecedora por parte do ESTADO!!!

Este CAOS burocrático que se vive na FE-AP é inaceitável...

The simplest explanation is usually the correct one

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

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.