Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)

Mensagem por **JoséQuintas** » 06 Abr 2018 16:41

Use a chave de acesso.
Pra NFE, a chave normal
Pra eventos, a chave normal + tipo de evento + ordem
Pode usar o CNPJ da chave pra identificar emitido/recebido, mas como são chaves diferentes, poderia deixar na mesma pasta

Já nota de serviços complica, porque não tem formato padrão, e teria que pegar as informações do xml.

Mensagem por **JoséQuintas** » 06 Abr 2018 19:23

Complemento:

1) Pra salvar em MySQL pode ser usado o mesmo esquema.

2) No meu servidor eu também organizava por CNPJ, pra separar os clientes, mas atualmente é só no MySQL mesmo

- CNPJ
-- ano/mes

Mensagem por **JoséQuintas** » 08 Abr 2018 10:14

A chave de acesso é composta, dentre outras coisas, de:
ano
mês
CNPJ emitente
Tipo de documento

Portanto:

- NF 1 vai ter chave diferente de CT 1
- NF 1 de um emitente vai ter chave diferente da NF 1 de outro emitente
- Nota emitida sempre vai ter o CNPJ do emitente na chave, e nota recebida não

E eventos: cancelamento, carta de correção, etc. bastaria acrescentar isso na chave de acesso.
Cada evento tem um código, e um número sequencial, que ficam dentro do XML.

Mas.. Nota de serviço não segue a mesma regra dos demais, a não ser que invente uma.

Mensagem por **JoséQuintas** » 08 Abr 2018 10:17

Código: Selecionar todos

   mChaveDigital := ;
      "35" + ; // UF Ibge
   SubStr( DToS( jpnota->nfDatEmi ), 3, 4 ) + ; // AnoMes
   SoNumeros( jpempre->emCnpj ) + ;             // Cnpj
   "55" + ;                                     // Modelo de Docto Fiscal
   "001" + ;                                    // Serie Docto Fiscal
   jpnota->nfNotFis + ;                         // NF 9 digitos

Mensagem por **JoséQuintas** » 08 Abr 2018 10:21

Alguns códigos

Modelos de Documentos Fiscais:

01 - Nota Fiscal
1B - Nota Fiscal Avulsa
02 - Nota Fiscal de Venda a Consumidor
2D - Cupom Fiscal emitido por ECF
2E - Bilhete de Passagem emitido por ECF
04 - Nota Fiscal de Produtor
06 - Nota Fiscal/Conta de Energia Elétrica
07 - Nota Fiscal de Serviço de Transporte
08 - Conhecimento de Transporte Rodoviário de Cargas
8B - Conhecimento de Transporte de Cargas Avulso
09 - Conhecimento de Transporte Aquaviário de Cargas
10 - Conhecimento Aéreo
11 - Conhecimento de Transporte Ferroviário de Cargas
13 - Bilhete de Passagem Rodoviário
14 - Bilhete de Passagem Aquaviário
15 - Bilhete de Passagem e Nota de Bagagem
17 - Despacho de Transporte
16 - Bilhete de Passagem Ferroviário
18 - Resumo de Movimento Diário
20 - Ordem de Coleta de Cargas
21 - Nota Fiscal de Serviço de Comunicação
22 - Nota Fiscal de Serviço de Telecomunicação
23 - GNRE
24 - Autorização de Carregamento e Transporte
25 - Manifesto de Carga
26 - Conhecimento de Transporte Multimodal de Cargas
27 - Nota Fiscal de Transporte Ferroviário de Cargas
28 - Nota Fiscal/Conta de Fornecimento de Gás Canalizado
29 - Nota Fiscal/Conta de Fornecimento de Água Canalizada
30 - Bilhete/Recibo do Passageiro
55 - Nota Fiscal Eletrônica
57 - Conhecimento de Transporte Eletrônico – CT-e

Mensagem por **JoséQuintas** » 08 Abr 2018 22:09

Eu deixo junto.
Em ordem numérica, todas as emitidas vão estar juntas, por causa do CNPJ.
Isso permite selecionar manualmente ou via aplicativo.

Formatando pra ficar visível:

35-18/01-00.000.000/0000-00

35 = Notas de São Paulo
18/01 = janeiro/2018
00.000.000/0000-00 - CNPJ

Mesmo que junte filiais, cada filial vai ter suas notas juntas.

Mensagem por **JoséQuintas** » 10 Abr 2018 11:05

hazael escreveu:Agora surgiram novas questões... o que você faz com as cartas de correção e outros XML que não sejam os conhecidos modelos 55, 57 e 65?E os XML que tem algum problema (homologação, teste, inválido, não assinado, etc...)?

Carta de correção e outros, eu já disse.

Opção que uso:

Chave de Acesso - 110111 - 01.xml
Chave de acesso - 110112 - 01.xml

Cada evento tem um código, só colocar no nome, o documento completo vai ficar junto: emissão e eventos
ou chave de acesso - carta - 01.xml, chave de acesso - cancel.xml, etc.
Mas pra que inventar se já existe um código?
Uso isso pra salvar no MySQL.

Se misturar com os inválidos, de repente acrescentar xxx-ERRO.XML, ou ERRO-xxxx.xml

Mas talvez o ideal seja deixar uma pasta para as pendências: elas devem ser resolvidas e não ficar juntando tudo.

Mensagem por **JoséQuintas** » 10 Abr 2018 11:09

Acrescentando:
Com o código do evento é melhor, porque existem muitos eventos diferentes.

carta de correção, cancelamento, manifestação do destinatário, encerramento de manifesto, troca de motorista, posto de fiscalização, etc.
Usando o código do governo, tá pronto para o futuro, pra tudo que inventarem.

Mensagem por **JoséQuintas** » 11 Abr 2018 11:23

Carta de correção podem ser feitas várias, 01, 02, 03, 04, 05.....

Não precisa saber quais são os eventos, basta que salve.
Existem muuuuitos, e nem todos são nossos.
Exemplos: passagem por posto de fiscalização, emitido CTE pra NFE

Pense:
Vai pegar o código do evento do XML.... precisa de uma lista pra que?
Conforme forem aparecendo, anote os que interessam.

hazael escreveu:Outra dificuldade que encontrei é que existem padrões diferentes de XML dependendo da versão (1.00, 2.00, 3.00, 4.00, etc) - nem em manter o padrão o governo conseguiu acertar?

Nas primeiras notas fiscais existia o cancelamento, e só depois inventaram o evento de cancelamento.
É ir ajustando as rotinas com o tempo, conforme forem aparecendo padrões diferentes.
Pelo menos daqui pra frente tá mais padronizado.

Kiko Fernandes · Mensagem por **Kiko Fernandes** » 11 Abr 2018 17:07

Boa tarde!

Já tenho uma carta de correção registrada e preciso fazer uma nova carta de correção, como devo agir?
A carta de correção com data mais recente substitui as cartas de correções existentes, assim a nova carta de correção deve consolidar todas as correções.

Para carta de correção estará valendo sempre o último evento. Poderá existir no máximo 20 para a mesma carta.
Porém é obrigação a última emitida conter toda informação que continha as anteriores, portanto valerá apenas o último evento.
Não vejo necessidade de fazer a guarda dos eventos anteriores. (Considerando que você está desenvolvendo um um aplicativo para gerenciar a guarda ou então para envio da contabilidade. Valerá apenas a última carta.)

Kiko Fernandes · Mensagem por **Kiko Fernandes** » 12 Abr 2018 09:37

hazael escreveu:Mas de qualquer forma é prudente prever uma situação excepcional, não é mesmo?

Bom dia!
Quanto a isto não discuto. Se achar importante guarde.

hazael escreveu:Por exemplo, uma informação de aviso de passagem pode ter vários eventos, ou não? (código 310620)

A minha resposta foi especificamente aos eventos de carta de correção, levando em consideração a sua pergunta:

hazael escreveu:Por essa eu não contava... então pode haver casos com exatemente os mesmos dados de chave da NFe?
Por exemplo, uma NFe (modelo 55) emitida em São Paulo, em 03/2018, com 4 eventos de carta de correção

Kiko Fernandes · Mensagem por **Kiko Fernandes** » 12 Abr 2018 11:40

hazael escreveu:No caso, é possível ter mais de um evento do mesmo código e é possível que estes eventos não sejam consolidados

É possível. Porém uma coisa são regras, padrões. Outra é o que o povo faz e as vezes pensa que está certo.

Vou ver se consigo explicar o meu ponto de vista.
Interpretei como "consolidados" a união do conteúdo do evento anterior com o atual. Seria isto?
Se for o manual diz que o último evento da "carta de correção" deve trazer o conteúdo das anteriores, não adianta querer juntar (digo de forma fiscal e não para fim de saber o que ocorreu) o conteúdo de um evento anterior com um atual, pois para o fisco valerá apenas o último evento.

Segundo ponto, penso que o nome deveria ser regulamentado, seguindo a ID "identificação" do evento conforme a NT2011.003 que diz:
A regra de formação do Id é:

“ID” + tpEvento + chave da NF-e + nSeqEvento

//Pág. 10.

Com isto o nome ficaria algo parecido com isto
110110+chave+01.xml //Primeiro evento da carta de correção.
110110+chave+02.xml //Segundo evento da carta de correção.
110110+chave+03.xml //Terceiro evento da carta de correção.

Mas infelizmente não se tem este entendimento, então os nomes são variados.

Mensagem por **JoséQuintas** » 12 Abr 2018 13:51

Kiko Fernandes escreveu:É possível. Porém uma coisa são regras, padrões. Outra é o que o povo faz e as vezes pensa que está certo.

Manual do usuário 6.0 (ATUAL), página 170
E não é que copiaram o meu jeito de nomear arquivos kkkkkkk

No download do governo vém TODAS as cartas de correção, o governo salva TODAS e não apenas a última.

Sei lá... você mesmo já disse:

Kiko Fernandes escreveu:É possível. Porém uma coisa são regras, padrões. Outra é o que o povo faz e as vezes pensa que está certo.

No meu caso eu nem sabia que existia padrão, mas agora sei que estou certo.... rs

Kiko Fernandes · Mensagem por **Kiko Fernandes** » 12 Abr 2018 19:00

JoséQuintas escreveu:E não é que copiaram o meu jeito de nomear arquivos kkkkkkk

Legal José! É isto ai :{

A parte ruim é que colocam como "sugerido". Alguns não seguem isto.

No envio da nota eu controlo isto, portando gravo o evento no banco de dados. Tenho uma tabela só para xmls que está vinculado com o id da nota que é outra tabela.
Na entrada eu abro uma tela aonde é permitido escolher o arquivo para a nota informada. Verifico após abrir o XML se pertence aquela nota a informação e gravo também no banco. (Uso mysql)

Mensagem por **JoséQuintas** » 12 Abr 2018 20:28

hazael escreveu:José, quando você faz o download do governo e vem todas as cartas de correção, como é que são nomeados os arquivos que vem? Que quero saber é como é que o governo dá nome aos arquivos que vem.Obrigado

Não querendo ser chato, mas já sendo.... se você trabalha com NFE é só fazer o download e olhar como é.

Kiko Fernandes escreveu:Tenho uma tabela só para xmls que está vinculado com o id da nota que é outra tabela.

Lendo os dados do XML gravo emitente, destinatário, número do documento, tipo, etc. em uma tabela, e os XMLs em outra.
Desta forma, as tabelas não ficam presas ao aplicativo, e podem até ser de todos os clientes juntos (como é no meu servidor).