Jump to content
marcolopes

AT - questões legais

Recommended Posts

pmiguelmartins

Então, mas foi isso que disse o Julio e eu...

A hash é calculada em função dos dados do documento que se está a criar (na serie manual), e não em função do documento manual em si (ou documento recuperado).

Peço desculpa ... Percebi mal ....

Mas para tirar as dúvidas :

Eu estou a assinar deste modo

<DocumentoTipo> < > <serie (utilizo o a serie onde esta a ser lançado o documento na aplicação)> </> <Número ((utilizo o número automático onde esta a ser lançado o documento na aplicação)>

Exemplo :

Documento Manual

FT ABC/35

Lançamento na aplicação

FT MMM/3

Assino

FT MMM/3

e coloco na HasControl a indicação do documento manual

Penso ser isto

Share this post


Link to post
Share on other sites
marcolopes

Os oducmen

Uma vez que, por Lei, um documento certificado apenas pode ser assinalado uma única vez - no momento em que é originalmente emitido, não é possível verificar assinatura de documentos registados, mas previamente emitidos em software certificado. Neste caso, a validação apenas permitir saber que um documento previamente registado/recuperado não sofreu alterações desde que foi registado na série manual. Para mais, tal como o Marco refere, a componente da assinatura SystemEntryDate, combinada com a assinatura do documento anterior na mesma série, serve precisamente para garantir a autenticidade da assinatura original. Quanto aos documentos tipográficos, a questão da autenticidade não se coloca, desde que as respectivas vias se encontrem legíveis dentro dos termos da Lei.

De facto, o registo em série manuais, previsto pela certificação, tem várias implicações que não são imediatamente óbvias.

Fui claro?

A questão aqui é que, para a HASH ser reconstruída vão ser usados os dados do documento CRIADO no programa, e não do documento MANUAL (tanto mais que estes não são exportados via SAFT)

Assinar o documento registado através dos campos "DATA e NUMERO do DOCUMENTO MANUAL" não é viável (aliás, os pontos 2.3, 2.4 e 2.5 do O.C. são omissos no que toca à questão das assinaturas, e frisam apenas a criação da HashControl)

Edited by marcolopes

The simplest explanation is usually the correct one

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

Share this post


Link to post
Share on other sites
nunopicado

Marco:

A hash não vai ser reconstruida... Não pode sequer.

A hash que vai haver será uma nova, para o documento criado na serie manual.

A hash do documento original, que se perdeu, fica irremediavelmente perdida. Parou, morreu, acabou.


"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.

Share this post


Link to post
Share on other sites
JulioNobre

O Julio não deixa de ter razão...

As séries de documentos manuais são:

- Documentos em si mesmos, pelo que são assinados como qualquer outro documento.

A HASH é criada para ele proprio, pois não é permitido criar novamente uma HASH para outro documento (neste caso, o original)

- Obrigam à indicação do documento original

- Obrigam à inserção destes valores no campo HashControl.

Logo, a Hash é criada e se tiver de ser verificada é face aos dados do documento que as originou, ou seja, o documento da serie manual

Ao estar no HashControl (estupidez da AT) o documento original, está "provado" que não houve fuga, apenas houve um "acidente" que foi corrigido por esse método

Só não percebo porque não um campo só para isso... Para quê usar o HashControl, se este é, ou deveria ser, a versão da hash?

Creio que a confusão até pode vir daqui, mas o raciocinio do Julio parece-me correcto.

Parece-me haver necessidade de uma clarificação importante na forma como Hash e HashControl devem ser preenchidos no registo de documentos em série manuais.

Nota: Não pretendo aborrecer ninguém com a seguinte explicação. Apenas esclarecer o que parecer ser necessário.

Como obter o Hash e HashControl de um documento cuja emissão se encontra a ser finalizada

- Hash - Valor obtido pela assinatura da concatenação de "DataEmissão;DataHoraRegistoNoSistema;TipoDoc Série/NrSequênciaAutomaticamenteAtribuidoPelaAplicacao;NetTotal;[HashAtríbuidaAoDocAnteriormenteEmitidoNaMesmaSérie])

- HashControl - Versão da chave privada. Salvo razões de forças maior, é assumido o valor 1, por se tratar a primeira chave pública comunicada à AT no processo de certificação.

Como obter o Hash e HashControl de um documento que se encontra a ser registado, mas cujo original foi previamente emitido

- Hash - Valor obtido pela assinatura da concatenação de "DataRegisto;DataHoraRegistoNoSistema;TipoDoc SérieManual/NrSequênciaDeRegistoNaSérieManual;NetTotal;[HashAtríbuidaAoAnteriorRegistadoNaSérieManual]

- HashControl - Valor obtido a partir da concatenação da VersãoDaChave-TipoDocM SérieOriginal/NrSequênciaAtribuídoNaSérieOriginal

As cores atrás escolhidas permitem ver (a verde) o que acontece quando um documento originalmente emitido é, mais tarde, registado manualmente na aplicação.

Espero que esta explicação ajude a clarificar as formalidades a respeitar consoante os casos.

Concordo plenamente com o que o Nuno acabou de dizer :)

Edited by JulioNobre
  • Vote 1

Share this post


Link to post
Share on other sites
marcolopes

- Hash - Valor obtido pela assinatura da concatenação de "DataRegisto;DataHoraRegistoNoSistema;TipoDoc SérieManual/NrSequênciaDeRegistoNaSérieManual;NetTotal;[HashAtríbuidaAoAnteriorRegistadoNaSérieManual]

- HashControl - Valor obtido a partir da concatenação da VersãoDaChave-TipoDocM SérieOriginal/NrSequênciaAtribuídoNaSérieOriginal

As cores atrás escolhidas permitem ver (a verde) o que acontece quando um documento originalmente emitido é, mais tarde, registado manualmente na aplicação.

Espero que esta explicação ajude a clarificar as formalidades a respeitar consoante os casos.

EDIT... mas é exactamente isto que tenho vindo a dizer... para não complicar... em ambos os casos a HASH é criada exactamente da MESMA FORMA! Campos InvoiceDate, SystemEntryDate, InvoiceNo, GrossTotal

Edited by marcolopes

The simplest explanation is usually the correct one

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

Share this post


Link to post
Share on other sites
pmiguelmartins

Como obter o Hash e HashControl de um documento que se encontra a ser registado, mas cujo original foi previamente emitido

- Hash - Valor obtido pela assinatura da concatenação de "DataRegisto;DataHoraRegistoNoSistema;TipoDoc SérieManual/NrSequênciaDeRegistoNaSérieManual;NetTotal;[HashAtríbuidaAoAnteriorRegistadoNaSérieManual]

- HashControl - Valor obtido a partir da concatenação da VersãoDaChave-TipoDocM SérieOriginal/NrSequênciaAtribuídoNaSérieOriginal

Só uma questão ... a indicação a azul é informação proviniente do software correcto ?

Share this post


Link to post
Share on other sites
nunopicado

Parece-me haver necessidade de uma clarificação importante na forma como Hash e HashControl devem ser preenchidos no registo de documentos em série manuais.

:) Embora não tão bem explicado, foi isso que eu disse... :)

A diferença da estrutura é só na Hash Control.

Na Hash, a estrutura é a mesma, embora no caso se use uma série só para documentos manuais.

Agora, a partir dos DADOS exportados no SAFT, quero (ou quer a AT) verificar a ASSINATURA dos documentos...

Sem problemas...

Eles vão lidar os documentos que repuseste, e não os originais que se perderam.

Convém só lembrar que o SourceBilling deverá ser ajustado de acordo:

I: se forem documentos integrados, mas que foram feitos por aplicação informática

M: se forem documentos manuais, tipográficos, integrados na aplicação


"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.

Share this post


Link to post
Share on other sites
marcolopes

Marco:

A hash não vai ser reconstruida... Não pode sequer.

A hash que vai haver será uma nova, para o documento criado na serie manual.

A hash do documento original, que se perdeu, fica irremediavelmente perdida. Parou, morreu, acabou.

Omessa! A hash TEM de ser calculada para as verificações... é a isso que me refiro! E para ser RECONSTRUÍDA, os campos de criação têm de estar no SAFT, logo, têm de ser exactamente os MESMOS em ambos os cenários!

:) Embora não tão bem explicado, foi isso que eu disse... :)

A diferença da estrutura é só na Hash Control.

Na Hash, a estrutura é a mesma, embora no caso se use uma série só para documentos manuais.

Sem problemas...

Eles vão lidar os documentos que repuseste, e não os originais que se perderam.

Convém só lembrar que o SourceBilling deverá ser ajustado de acordo:

I: se forem documentos integrados, mas que foram feitos por aplicação informática

M: se forem documentos manuais, tipográficos, integrados na aplicação

Que raio de confusão! Estamos todos a dizer o mesmo!

Só uma questão ... a indicação a azul é informação proviniente do software correcto ?

ALTO! Ainda há dúvidas! :-)


The simplest explanation is usually the correct one

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

Share this post


Link to post
Share on other sites
pmiguelmartins

Omessa! A hash TEM de ser calculada para as verificações... é a isso que me refiro! E para ser RECONSTRUÍDA, os campos de criação têm de estar no SAFT, logo, têm de ser exactamente os MESMOS em ambos os cenários!

Que raio de confusão! Estamos todos a dizer o mesmo!

ALTO! Ainda há dúvidas! :-)

Peço desculpa ... mas isto ao fim de tanta confusão

"Só sei que nada sei" e até da propria sombra ja duvido

Já percebi que o calcula da hash é sempre feito da mesma maneira só muda o hashcontrol

Share this post


Link to post
Share on other sites
nunopicado

Omessa! A hash TEM de ser calculada para as verificações... é a isso que me refiro! E para ser RECONSTRUÍDA, os campos de criação têm de estar no SAFT, logo, têm de ser exactamente os MESMOS em ambos os cenários!

E ele a dar-lhe com a reconstruida...

Não vais reconstruir... Vais construir uma hash para um documento que estás a criar na hora, que só por acaso refere um outro.

Imagina.

Tens a FT 2013/00501, que por um azar do caraças se perdeu e não há copias.

Crias uma serie nova, chamada por exemplo FTM

Crias um documento chamado FTM 2013/00001, com os dados que tinhas no FT 2013/00501 (cliente, artigos e preços)

Crias uma hash para o documento FTM 2013/00001 (esquece neste passo que é um documento de reposição).

Crias o hashcontrol indicando 1-FT 2013/00501

Vai no SAFT os dados do documento FTM 2013/00001, com a hash do documento FTM 2013/00001, apenas com uma "pequena" referencia que é um documento reposto, no SourceBilling e no HashControl.

Qual é a parte que te parece dar erro na validação do SAFT?


"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.

Share this post


Link to post
Share on other sites
marcolopes

Só não percebo porque não um campo só para isso... Para quê usar o HashControl, se este é, ou deveria ser, a versão da hash?

Quando vi as primeiras referencias a "adulterar" a hashControl para esse fim, tb fiz a mesma pergunta... e penso que a resposta é simples:

O SAFT não é "nosso". O SAFT é da OCDE. Alterações à sua estrutura devem ser propostas, por isso não podem ser feitas "da noite para o dia" e ao gosto de Portugal (corrijam-me se estiver errado).

Embora a introdução de um NOVO campo fizesse todo o sentido e esta alteração pudesse ser sugerida para o SAFT 1.02, esta "manobra" já existia, e assim ficou... MUITO MAL, a meu ver...

E ele a dar-lhe com a reconstruida...

Não vais reconstruir... Vais construir uma hash para um documento que estás a criar na hora, que só por acaso refere um outro.

Imagina.

Tens a FT 2013/00501, que por um azar do caraças se perdeu e não há copias...

Outra vez nuno? :-) Eu já disse que estou de acordo! Estavamos todos em sintonia... eu estava a levantar a questão da RECONSTRUÇÃO da HASH através do SAFT (por questões de VALIDAÇÃO!) porque entendi que haviam aqui pontos de vista diferentes na forma de construír a mesma no caso do registo de documentos manuais!

Á frente!

Edited by marcolopes
  • Vote 1

The simplest explanation is usually the correct one

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

Share this post


Link to post
Share on other sites
bugFree

Boas,

Na nossa aplicação usamos as GT como documentos não-valorizados, e não-facturáveis. Não se podem converter em FT, porque não têm valores, etc.

As GR sim são obrigatoriamente valorizadas e convertíveis em FT.

Alguém me dizia que as GT, agora com o novo regime (e talvez até antes, mas não é esse o ponto), também devem ser facturadas, nos casos em que se aplique.

No meu entendimento, as GT servem para acompanhar mercadoria / material que não é facturável, por exemplo Transferências de Armazém, material para reparação, etc..

Serão agora excepção os casos das GT Globais, que darão origem a uma FT ou outro doc, quando entregues/vendidas ao cliente.

As GR devem ser usadas para acompanhar mercadoria que deve obrigatoriamente de ser facturada.

Qual a vossa opinião?

As GT também precisam de ser facturadas, mesmo não sendo valorizadas, ou não?

Obrigado.

Edited by bugFree

What's better: Coding solo or as part of a team?

A team means you have to fix someone else's bugs. Coding solo means you have to write all the bugs yourself.

Share this post


Link to post
Share on other sites
nunopicado

Não.

As GTs podem ser facturadas, mas não quer dizer que o sejam.

Imagina (caso de um técnico de informática):

Vais a um cliente ver uma impressora que segundo ele "tem aqui uma luzinha acesa e não imprime".

Ora, uma luzinha acesa pode ser muita coisa, geralmente bem especificada consoante a luz que é. Mas quem trabalha na área sabe que há clientes a quem nem vale a pena perguntar qual o símbolo que está marcado na luz em questão.

Tens de lá ir, e imaginas: "Pode ser toner."

Pegas num, levas para o cliente, mas com GT, pois não sabes se sim ou sopas.

Chegando lá, se não era do toner, amigos à mesma, não é preciso facturar, porque a GT a isso não obriga.

Mas se for do toner, mandas facturar, que também ninguém te impede.


"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.

Share this post


Link to post
Share on other sites
marcolopes

Não.

As GTs podem ser facturadas, mas não quer dizer que o sejam.

Imagina (caso de um técnico de informática):

Vais a um cliente ver uma impressora que segundo ele "tem aqui uma luzinha acesa e não imprime".

Ora, uma luzinha acesa pode ser muita coisa, geralmente bem especificada consoante a luz que é. Mas quem trabalha na área sabe que há clientes a quem nem vale a pena perguntar qual o símbolo que está marcado na luz em questão.

Tens de lá ir, e imaginas: "Pode ser toner."

Pegas num, levas para o cliente, mas com GT, pois não sabes se sim ou sopas.

Chegando lá, se não era do toner, amigos à mesma, não é preciso facturar, porque a GT a isso não obriga.

Mas se for do toner, mandas facturar, que também ninguém te impede.

Por estas e por outras é que eu quero ver como vai a AT efectuar a análise dos dados recolhidos...


The simplest explanation is usually the correct one

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

Share this post


Link to post
Share on other sites
pmiguelmartins

Mas alguém acredita que com a trapalhada toda que tem passado que vai fazer análise de dados ...

Acredito nisso mas lá para a frente

  • Vote 1

Share this post


Link to post
Share on other sites
nunopicado

Por estas e por outras é que eu quero ver como vai a AT efectuar a análise dos dados recolhidos...

Eu continuo a achar que todo este processo é anedótico... Adianta muito saberem que eu transportei, sei lá, 100 toners... Não sou obrigado a facturá-los!

Como eu costumo dizer: "Quem quer fugir, foge na mesma! Quem quer cumprir, está mais tramado ainda!"


"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.

Share this post


Link to post
Share on other sites
marcolopes

Eu continuo a achar que todo este processo é anedótico... Adianta muito saberem que eu transportei, sei lá, 100 toners... Não sou obrigado a facturá-los!

Como eu costumo dizer: "Quem quer fugir, foge na mesma! Quem quer cumprir, está mais tramado ainda!"

Vamos lá ser coerentes... A comunicação de documentos foi feita para controlar o que FOI facturado e o que DEVE SER facturado!

Portanto, presumo que os arquitectos deste sistema saibam exactamente o que estão a fazer, por forma a que, com a informação actual, saibam, inequivocamente, QUAIS são as mercadorias que devem ou não ser Facturadas... caso contrário tudo isto seria (como disseste) ANEDÓTICO!!!

Entre Guias de Remessa (globais ou não), Transporte (globais ou não), Devolução, sejam da empresa para Clientes, de Clientes para a empresa, da empresa para Fornecedores ou de Fornecedores para a Empresa (tudo MUITO simples!!!!!), presumo que haverá um RIGOROSO controle de tudo o que é transferido para cada empresa, se deve ser facturado e até quando o deve ser!!! (quase me apetece rir...)

Edited by marcolopes

The simplest explanation is usually the correct one

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

Share this post


Link to post
Share on other sites
nunopicado

Pois claro...

Agora repara nisto:

A minha empresa presta serviços de assistência. Entre outros, fazemos contratos de assistência de hardware, em que num determinado periodo, o cliente paga-nos uma avença, e durante esse tempo, em caso de avaria de hardware, nós trocamos sem custos.

Agora imagina:

Num cliente com contrato, avaria, sei lá, uma gráfica. Pego na grafica, e levo com GT para o cliente, troco-a, e visto haver contrato, não há factura da grafica.

Depois avaria um monitor, troco-o. Não há factura.

Agora uma impressora, ali um computador, um disco, um dvd-rw.

Nada disto sai com factura, porque está tudo ao abrigo do contrato. Como tal, sai com GT.

E agora, como é que é? Vamos ser "perseguidos" pela AT porque saiu muito material que não foi facturado?


"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.

Share this post


Link to post
Share on other sites
marcolopes

Pois claro...

Agora repara nisto:

A minha empresa presta serviços de assistência. Entre outros, fazemos contratos de assistência de hardware, em que num determinado periodo, o cliente paga-nos uma avença, e durante esse tempo, em caso de avaria de hardware, nós trocamos sem custos.

Agora imagina:

Num cliente com contrato, avaria, sei lá, uma gráfica. Pego na grafica, e levo com GT para o cliente, troco-a, e visto haver contrato, não há factura da grafica.

Depois avaria um monitor, troco-o. Não há factura.

Agora uma impressora, ali um computador, um disco, um dvd-rw.

Nada disto sai com factura, porque está tudo ao abrigo do contrato. Como tal, sai com GT.

E agora, como é que é? Vamos ser "perseguidos" pela AT porque saiu muito material que não foi facturado?

Evidentemente! Caso não exista uma GUIA de DEVOLUÇÃO a provar a entrada do material "trocado"... !?

Agora pergunto: A AT vai fazer o rastreio pela DESCRIÇÃO do artigo? :-)

Sinceramente, a comunicação de FACTURAS tem um propósito bem definido... SIMPLES, eficaz. Na comunicação de Transportes nada faz sentido... é uma MISTELA onde ninguém se entende, onde os "esclarecimentos" aparecem depois da implementação. Foi elaborado de forma precipitada, por quem não pensou em todos os pormenores, e o seu propósito, nos moldes actuais, cai num buraco negro...

Edited by marcolopes
  • Vote 1

The simplest explanation is usually the correct one

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

Share this post


Link to post
Share on other sites
nunopicado

Qual material trocado? Nem todo o material tem direito a devolução.

Olha outro exemplo:

Temos clientes que têm contrato de usufruto, de impressoras/fotocopiadoras.

O toner gasta-se, está no contrato, levamos outro.

Vamos fazer o quê, trazer o toner velho, com devolução?

A guia de devolução pressupõe entrada em stock, e na maior parte dos casos, isto não acontece.

Claro que, quando trazemos o material velho para a loja, é costume (ou tem sido até agora) o cliente passar-nos uma GT do material, apenas para efeitos de trânsito.

Como é que a AT vai cruzar o que ele nos devolveu com uma guia que passámos há 3 ou 4 anos atrás?


"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.

Share this post


Link to post
Share on other sites
marcolopes

Qual material trocado? Nem todo o material tem direito a devolução.

Olha outro exemplo:

Temos clientes que têm contrato de usufruto, de impressoras/fotocopiadoras.

O toner gasta-se, está no contrato, levamos outro.

Vamos fazer o quê, trazer o toner velho, com devolução?

A guia de devolução pressupõe entrada em stock, e na maior parte dos casos, isto não acontece.

Claro que, quando trazemos o material velho para a loja, é costume (ou tem sido até agora) o cliente passar-nos uma GT do material, apenas para efeitos de trânsito.

Como é que a AT vai cruzar o que ele nos devolveu com uma guia que passámos há 3 ou 4 anos atrás?

Chegamos à mesma conclusão... sistema totalmente IRREAL e disfuncional. Sinceramente, não vou dar mais interesse ao envio de documentos de transporte. Os clientes que se entendam com o fisco.

Resta-me agora pensar na extensa lista de pontos do Oficio Circulado...

  • Vote 1

The simplest explanation is usually the correct one

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

Share this post


Link to post
Share on other sites
JulioNobre

Olhando para o tema aqui em debate, parece-me apropriado transmitir-vos aquele que me parece ser o entendimento da AT sobre as circunstâncias que obrigam à emissão (e comunicação prévia) de DGT (Documentos Globais de Transporte).

Pois bem, de acordo com o Manual da OTOC - revisto e publicado com o aval da AT -, devem ser emitidos Documentos Globais de Transporte sempre que à altura da saída dos bens um ou vários dos seguintes factos não seja conhecido:

  • O destinatário do bem;
  • Dos bens transportados, quais serão aplicados ou entregues;
  • Quais as exactas de cada bem a aplicar ou a entregar ao destinatário.

Sempre que um bem (ou vários) seja entregue ou aplicado, deve haver lugar à emissão de um Documento Adicional de Transporte(*) (DAT) registando esse facto. Cada Documento Adicional de Transporte deve ainda fazer referência ao DGT que lhe deu origem e ser comunicado à AT no prazo de 5 dias úteis.

(*) Tanto quanto sei, um DAT pode ser numa Nota de Entrega (para faturar mais tarde), uma Fatura, entre outros.

Para mais informações, sugiro a leitura ponto 2.1 (pág.1) e ponto 2.7 (pág.5) do Manual da OTOC - O documento mais completo que conheço sobre esta matéria.

Este assunto é, a meu ver, uma das maiores falha da AT neste processo. A recente revisão do SAFT-T não permite distinguir de forma clara entre DT (Documentos de Transporte) e DGT. Por esta razão, agora surgem os "remendos" por parte da AT indicando que, nos DGT, o NIF (CustomerTaxID) não se deve preenchido - um claro conflito com as actuais regras impostas pela certificação de software.

Adivinho facilmente que, ou voltam a rever o SAFT-T e clarificam a distinção entre DT, DGT e DAT, ou este assunto ainda vai ser discutido durante muito tempo.

Neste momento, parecem existir, pelo menos, 4 ATs:

  • A AT que define os documentos de transporte;
  • A AT que define o SAFT-T;
  • A AT que define o eFatura; e
  • Uma AT que tem dificuldade em não deixar transparecer que o respeito que outrora existiu quer pelos seus direitos, quer pelos deveres (refiro-me ao indispensável esclarecimento prévio dos elementos responsáveis pelo apoio a quem para eles trabalha - os contribuintes) é chão que já deu uva.

Dava tanto jeito que a AT se entendesse com a AT e com a AT e... :(

Edited by JulioNobre

Share this post


Link to post
Share on other sites
marcolopes

Neste momento, parecem existir, pelo menos, 4 ATs:

  • A AT que define os documentos de transporte;
  • A AT que define o SAFT-T;
  • A AT que define o eFatura; e
  • Uma AT que tem dificuldade em não deixar transparecer que o respeito que outrora existiu quer pelos seus direitos, quer pelos deveres (refiro-me ao indispensável esclarecimento prévio dos elementos responsáveis pelo apoio a quem para eles trabalha - os contribuintes) é chão que já deu uva.

Dava tanto jeito que a AT se entendesse com a AT e com a AT e... :(

Concordo. Cheguei a sugerir à AT para colocar a equipa que desenvolveu o sistema de comunicação de Facturas a desenvolver a comunicação de documentos de Transporte... Claramente que, pelas graves falhas técnicas iniciais na estrutura, foram equipas diferentes.

De qualquer forma, as equipas de desenvolvimento não poderiam fazer grandes milagres, pois os "teóricos" não tiveram noção da complexidade do que estavam a pedir...


The simplest explanation is usually the correct one

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

Share this post


Link to post
Share on other sites
americob

Portanto, presumo que os arquitectos deste sistema saibam exactamente o que estão a fazer, por forma a que, com a informação actual, saibam, inequivocamente, QUAIS são as mercadorias que devem ou não ser Facturadas... caso contrário tudo isto seria (como disseste) ANEDÓTICO!!!

A ideia com que se fica é que estão a por à prova o ditado "o medo guarda a vinha", como o agricultor que coloca uns espantalhos no meio do campo para assustar os pardais.

Na prática o sistema não permite controlar grande coisa, mas em principio deve assustar muita gente.

  • Vote 2

Share this post


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.