Rankings

Relativamente a este assunto, ontem tivemos uma reunião com DIgitalSign ( empresa emissora de Certificados Digitais ), pois a Faturação Eletrónica vai obrigar a um Certificado por cada utilizador ( 125 € por ano e por cliente ) Na reunião informaram-nos que também estão com reuniões agendadas com as grandes Softwares-Houses pois na verdade ainda ninguém tem o sistema a funcionar ( muito embora algumas publicitem que sim ) Também nos informaram que a informação que tinha chegado até eles é de que seria utilizado o UBL 2.1 e não o UBL 2.0 como se tem falado aqui no Forum, mas também não tinham certezas de nada Como tal, a situação é: A Portaria que vai regular ainda não saiu …... A data de inicio já vai em Abril de 2019 …... As Empresas do Estado ainda não tem Software preparado para recolha das Faturas Eletrónicas …. e por ai fora ….. Vamos aguardando e juntando toda a informação que vai saindo, mas com toda a certeza a menos fiável é a publicada pelos jornalista, e que devemos descartar pois tem objetivos sensacionalistas e não profissionais

No meu entendimento, e pelo que podemos ver pelo formato da Factura Electrónica da área da saúde, tem de haver uma assinatura do XML (seja ele enviado em envelope SOAP ou não).

A informação da DigitalSign é que muito embora seja a Software-House a pedir os Certificados, cada utilizador tem de ter um Certificado pessoal ( onde vão digitalmente os dados da sua Empresa ) para comunicar com os seus Fornecedores ( envio das Faturas assinadas pelo emissor das mesmas ) De qualquer das formas, também deixamos no ar a mesma dúvida ( se será possível o Certificado ser da Software-House e não do cliente utilizador do Software ), mas ainda existe muita falta de informação sobre o assunto

Terá de ser, porque a informação do XML terá de ser assinada para garantir autenticidade, seja qual for o canal utilizado (se for Webservice, haverá ainda outro certificado para autenticação, mas será da responsabilidade da empresa receptora) Eu começo a ver tudo isto como um AUMENTO de custo e não uma redução! (então se colocarmos "empresas intermediárias" no cenário...)

Podes ver aqui um simples crd.xml Só lhe retirei a tag Extension no inicio para não confundir mais. E está em UBL 2.0 mas as diferenças não são significativas para o caso. Esta factura não tem descritivos e na tag ITEM tem conteúdos específicos diferentes dos pedidos pela infraestruturas de portugal que diga-se de passagem também não é standard.

Tanto quanto sei, a ideia original do governo era que em vez de se dar uma factura em papel ao cliente, era enviada a fatura (com o nível de detalhe equivalente às actuais facturas em papel) directamente para as finanças (que depois tornaria a factura disponível ao cliente online, assumo). Por isso acho muito bem que a CNPD tenha metido um travão nisto (pessoalmente já me incomoda a informação que as finanças recebem actualmente, razão pela qual raramente dou o meu número de contribuinte).

Aí é que está... Quando enviadas por WS, não há detalhes das compras, apenas valores. Os campos das linhas de faturas enviadas por WS são: DebitAmount CreditAmount TaxType TaxCountryRegion TaxPercentage TaxExemptionReason Isto é menos que até o SAFT mensal, que leva por exemplo quantidades...

a CNPD é uma anedota nacional, então o RGPD... juntando os dois, dá uma coisa fabulastica!

Essa notícia tem mais a ver com a medida do Simplex+2018 que se prevê para o 2º trimestre de 2019 (e não 1 de Janeiro como alguns outlets estão a divulgar). É independente da situação da norma europeia de eInvoicing. Mas não deixa de ser divertido saber que a AT está a 'reformular' algo que ainda nem sequer foi formulado! E ainda gostaria de saber qual o problema da CNPD... Quê que vai a mais por WS que não vá já no SAF-T? Acho que até vai menos!

Vi agora a notícia no Observador: https://observador.pt/2018/12/05/faturas-em-papel-vao-acabar-ja-em-janeiro/ Bem, trabalho não nos vai faltar...

#include <stdio.h> #define MAX(a,b) ((a) > (b) ? (a) : (b)) int main() { int hit = 0; for (int i = 999; i > 0; i--) { int j = 999, mul, copy, rev; do { rev = 0; mul = copy = i * j; while (copy) { rev = rev * 10 + copy % 10; copy /= 10; } j--; } while (j > 0 && mul != rev && hit < mul); hit = MAX(mul, hit); } printf("maior numero capicua e: %d\n", hit); return 0; }

FONTE? Eu acredito que SIM, porque é essa a nomenclatura do eTaxFree... Retirado dos documentos técnicos:

O ATCUD entra em vigor em 2020 juntamente com um QR-Code impresso na Fatura

Obrigado pela resposta CrominhO. Realmente espero que, qualquer que seja a opção adoptada, não traga custos para os clientes, caso contrário vamos ter que ouvir reclamar muito. Penso que a ideia deveria ser simplificar processos, não aumentar os custos. Mas vamos ver a surpresa que o Pai Natal nos irá trazer... Também fiquei com essa ideia. Tal como dizes, quem estiver a comunicar as facturas por web service poderá, se quiser (e se o cliente não exigir a factura em papel), não imprimir. Também não vejo nenhuma obrigatoriedade nisto. Quanto ao prazo, pelo que se pode ver em https://www.simplex.gov.pt/medidas em Fatura sem Papel, esta medida tem o prazo de implementação previsto de "2.º Trimestre 2019". Quanto à descrição da medida diz: "Regulamentar a possibilidade de dispensa do impressão de faturas." Ou seja, fala-se em possibilidade de não ser preciso imprimir. Seja como for, só falta mesmo o tal regulamento.

Pois, os jornalistas pega na noticia de outro jornalista, adaptam à sua maneira e siga O que parece que está previsto para o dia 1 de Janeiro ao abrigo do Simplex-2018, é a possibilidade nas Vendas a Publico ( POS ), não se entregar a Fatura ( a não ser que seja pedida ), mas nestes casos o Software tem de enviar de imediato todas as Faturas para a AT via Webservice Como tal será uma opção e não uma obrigação para todos

Antes demais quero agradecer a todos a partilha, se isto já é um CAOS imaginem se cada um de nós ficasse com o bocadinho de informação que possui e não partilhássemos... Era a loucura total :-\ @chesser antigamente, back in 2012 se a memória não me falha, o certificado era para os teus Clientes e para os clientes deles, para que ninguém pudesse interferir nessa comunicação. E deveria ser emitido por uma terceira entidade independente e imparcial. Essa entidade garantia o recebimento e a entrega do documento, que na altura nos "levava" ~€0.70 por documento :-\ ... Ora isto num software Vertical, é facil de perceber que até poderá trazer vantagens, já num Horizontal é surreal, imagina a "loja da esquina" a pagar 70 centimos por documento... Não quer dizer, (e espero bem que não seja) que desta vez seja assim :-\

https://www.simplex.gov.pt/medidas Fatura sem papel Ministério responsável: M. das Finanças Descrição da medida: Regulamentar a possibilidade de dispensa do impressão de faturas. Prazo de implementação previsto: 2.º Trimestre 2019 Principais destinatários da medida: Cidadãos | Empresas Fonte da medida: Processo participativo interno à Administração Pública Etapa de vida: Empresa

Falei ontem com a ASSOFT (com o responsável por esta matéria, que está em contacto DIRECTO com o grupo de trabalho nomeado para portugal) Concretamente, o GRUPO de trabalho nomeado para analisar a transposição da directiva da U.E. está completamente isolado de qualquer departamento do governo responsável pela legislação, planificação, possível implementação do que quer que seja! Estão a ser feitas tentativas para agendamento de reuniões, mas até agora nada foi conseguido. Por outras palavras: uma completa descoordenação. Não se sabe quando, nem o que vai ser feito, à excepção que as empresas públicas serão obrigadas a aceitar, directamente ou através de intermediários, os formatos técnicos já estabelecidos pela U.E. como obrigatórios (isto a nível de CORE, porque depois cada país ou entidade pública? terá as suas extensões... e forma de comunicar!)

Faz por partes. Primeiro: escrever código que faz a tal multiplicação de todos os números de 3 dígitos. Algo como: for(int i=0.......) for(int j =0........) produto = //multiplicação aqui usando o 100 e o i é o j dos loops for Não posso dizer muito mais senão faço tudo. É isto leva ao pequeno problema que falei. Vai acontecer que o loop exterior vai acabar por repetir valores do loop interior. Mas como para já não tenho outra solução, esta deve servir para tentares resolver o problema. Depois mais logo ou durante o dia, certamente alguém te encaminhará para uma solução mais optimizada e robusta.

Boas, Parece-me interessante: https://github.com/Gammern/ubllarsen

Obrigado pelo exemplo. No meu caso estou a construir e a validar num validador http://13.80.11.48:8000/invoice/upload , depois a ideia é ir retirando os erros .... Por exemplo ele obriga a ter dentro do TaxSubtotal um TaxCategory que indique depois o tipo de IVA, equivalente ao TN, RED, mas já encontrei uma equivalência (não muito equivalente) http://docs.peppol.eu/pracc/catalogue/1.0/codelist/UNCL5305/ , mas que depois a códigos que o validador não reconhece.. Mas no caso do exemplo não tem essa informação, agora não sei se foi adicionado ao 2.1 Mais uma vez Obrigado, dá para ter uma ideia.

Eu espero que sim, mas vamos com calma porque já não é a primeira vez nem será a ultima que lançam as coisas "em cima" do acontecimento lol... 2012/13, 2 semanas antes com a Venda a dinheiro para FS e depois mais 2 semanas para a FR lol... Espero que sim, que pelo menos nos seja dado algum tempo para debater e implementar 🙂

Bom dia Fabio, posso tentar ajudar nas tuas duvidas, mas convém consultares a documentação oficial da AT: http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/Pages/certificacao-de-software.aspx http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/SAFT_PT/Paginas/news-saf-t-pt.aspx 1. a) A melhor forma de teres a certeza do formato é analisares o ficheiro de validação do SAF-T para o campo DocumentNumber. Mas basicamente a série é uma forma de identificar unicamente a numeração. Por exemplo podes ter a série por posto e juntas o ano, ficando P12018 (ex: FR P12018/1). Não podes ter o caracter de espaço na série. b) O código hash é gerado com a chave privada, usando alguns campos do documento (dataemissão;datahorasistema;numero;total;hashdocanterior). No caso do primeiro documento, como não tens documento anterior, omites esse conteúdo. Essa parte de extrair 4 caracteres do hash será apenas na impressão do documento para entregar ao cliente. c) Não entendi a duvida mas os documentos fechados e assinados não podem ser alterados. d) Todos os documentos que possam ser entregues a clientes têm de ser assinados (faturas, contas, etc). O prazo de envio do SAF-T é atualmente até ao dia 20 do mês seguinte. e) Para cancelamento de algum produto, deve ser feita uma nota de crédito. A anulação julgo que só em casos extremos (por exemplo, engano no NIF) 2. Esse erro indica que estás a exportar um produto (com o código MO) na parte dos documentos, que não referenciaste no inicio do SAF-T, na parte dos produtos 3. Não tenho conhecimento se existe alguma API que facilite, mas tenta ver o tópico SAFT-PT: debate de dúvidas e ideias no forum, tem lá bastante informação que ajudou-me na altura que fiz. Espero que ajude, nelsonr

Pelo que percebi o absolute, coloca-te numa determinada linha do resultSet. Quando fazes o rs.next() faz algo parecido. Este ciclo faz com que percorra todas as linhas que obteve. Em vez de usares o absolute, utiliza o rs e vai buscar os valores utilizando o getInt(), getString(), ... em que passas por parâmetro o nome da coluna da tabela na base de dados ou então o indice onde está. Exemplo do link que dei: ResultSet rs = stmt.executeQuery(query); while (rs.next()) { String coffeeName = rs.getString(1); int supplierID = rs.getInt(2); float price = rs.getFloat(3); int sales = rs.getInt(4); int total = rs.getInt(5); System.out.println(coffeeName + "\t" + supplierID + "\t" + price + "\t" + sales + "\t" + total); } Caso não resolva, podes colocar aqui o troço do código de onde fazes o pedido à base de dados e utilizas o absolute?

Acho que isto te deve ajudar: https://docs.oracle.com/javase/tutorial/jdbc/basics/retrieving.html