Página 1 de 2
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 06 Abr 2018 16:41
por JoséQuintas
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.
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 06 Abr 2018 19:23
por JoséQuintas
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
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 08 Abr 2018 10:14
por JoséQuintas
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.
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 08 Abr 2018 10:17
por JoséQuintas
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
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 08 Abr 2018 10:21
por JoséQuintas
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
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 08 Abr 2018 22:09
por JoséQuintas
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.
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 10 Abr 2018 11:05
por JoséQuintas
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.
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 10 Abr 2018 11:09
por JoséQuintas
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.
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 11 Abr 2018 11:23
por JoséQuintas
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.
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 11 Abr 2018 17:07
por Kiko Fernandes
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.)
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 12 Abr 2018 09:37
por Kiko Fernandes
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
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 12 Abr 2018 11:40
por Kiko Fernandes
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.
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 12 Abr 2018 13:51
por JoséQuintas
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
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 12 Abr 2018 19:00
por Kiko Fernandes
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)
Organizar os XML (NF-e, NFC-e, NFS-e, CT-e)
Enviado: 12 Abr 2018 20:28
por JoséQuintas
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).