PC Toledo

Pessoal td bem...

Aos q já emitem NFCe ou estão adaptando ou pretendem fazer levanto uma questão...

NFCe no dia a dia com mais de 1 micro ou q seja 1 micro gerando...
Como vcs lidam com as questões/problemas iniciais? vou citar abaixo...

Imaginemos o seguinte cenário/situações...

Questão 01:
O cliente vai emitir uma NFCe q até ontem esta tudo ok...
Mas todos os dias ou dia ou outro chegam produtos, são cadastrados, alterados, etc...
Ai o cliente foi emitir e tem problema com NCM ou faltou CEST ou algum problema com algum item da venda...
Suponhamos q vc finalize a venda, baixe estoque etc etc... ok ai na hora de gerar a NFCe ao enviar a SEFAZ retornou problema A ou B ou C (NCM inválido, faltando CEST, etc etc etc)
Como resolver?

Em conversas com alguns colegas e analisando alguns fóruns/ideias... tem de tudo...
Tem gente q finaliza a venda se deu problema na NFCe dos citados acima da seguinte forma:
gera um pedido de venda não fiscal
ai a venda fica marcada para gerar NFCe depois, isso resolveria a dinâmica pra não parar o PDV/Micro q esta vendendo pq a fila ta grande... Ok... mas isso pode? alguém faz ou sugere algo diferente?
A questão maior seria (partindo do principio q pode fazer assim) como resolver/garantir q sejam resolvidos as questões com problema...
Muitas vezes os retornos do SEFAZ não indicam qual item tem problema...
Se for muitos itens a venda uma ideia seriam a cada item inserido na venda confrontar o NCM com a tabela MDIC (vamos pensar q não mudaram... kkk) ai ok teriamos NCMs validos e invalidos... mas a Venda não pode parar... antes da NFCe a venda seria concluida... então vamos pensar em concluir a venda pra fila andar e como resolver os problemas ok...
Se temos NCMs validos podemos consultar se o item tem ou não CEST, se tem se é válido confrontando com a tabela CEST se não tem e deveria ter tb esta errado... e assim por diante...
Ok vamos tendo ferramentas pra auxiliar na correção... mas tudo posterior a venda pq não tem como um PDV com fila parar pra resolver isto... temos q pensar em alternativas dinamicas...

Questão 02
Ah... se tem problema na internet gero em Contingência... Ok depois tem q enviar os xmls em contingência... Ok (não vamos falar de prazo pra envio q é outra questão a se pensar... vamos falar o seguinte) voltou a conexão SEFAZ e estou enviando XML... ai deu problema em algum dos XMLs dos tipos exemplificados na questão 01... como resolver? pq se vc construiu uma rotina q analisa e envia automatico as contingencias ao entrar ou sair do caixa ou a cada X minutos... eventualmente vai ter um problema desses e como resolver? Pq sabemos se deixarmos pro usuário de uma maneira não muito amarrada corremos o risco de não fazerem, então o q for possível automatizar melhor..



E ai pessoal vamos conversar a respeito?

Bom dia...

Boa discussão Fladimir...

Na minha limitação, creio eu que boa parte do problema é preventivo... Como assim? Na entrada da mercadoria você já mata quase tudo importando pelo XML, porque se o fornecedor conseguiu emitir a nota dele é porque está tudo em ordem. Eu não deixo o xml estático... Tipo, deu erro não conseguiu enviar a nfce, vai aparecer a mensagem então gera novamente buscando dados das tabelas, tipo, não informo na tabela de itens da nfce, nem ncm, nem cest, nem ean, nem nome, somente os itens que são gerados pela venda, qtde e valor. Daí toda vez que gera o xml ele busca estes dados de novo do produto.
Tem tabelas que não tem como você automatizar. Em janeiro quando MT começou a validar NCM´s foi um deus nos acuda... Existiam produtos que estavam nas tabelas da SEFAZ mas não validavam, não tinham integridade tabela sefaz/tabelas do ambiente. Daí só na unha para resolver... Isso vale para IBPT, CEST, então o jeito foi importar estas tabelas a cada período de tempo. O CEST mesmo usei o que foi disponibilizado aqui no fórum, e criei uma rotina de importação no sistema. Se o NCM está relacionado no CEST o CEST é atualizado não importa a situação...
Daí tem o problema de dados mais antigos nas tabelas, Tive que criar rotinas de critica na hora de venda do produto, se não tiver ncm não passa, vai ser da mesma forma com o CEST.
Tive que adotar um ncm padrão, na hora da venda caso o ncm não seja encontrado na tabela do IBPT o programa assume um ncm padrão, dessa forma não para o PDV.
Tem uma nova regra agora acho que na última NT que melhora as informações de rejeição, e uma delas foi para mostrar o item que deu erro. Não implementei aqui não mas vai ser o próximo passo...
Mas de qualquer forma é bom sabermos mesmo os que os outros programadores estão fazendo, vai ajudar e muito...

Rubens

Bom dia,

Obrigado Rubens pelo retorno,

Rubens escreveu:Eu não deixo o xml estático... Tipo, deu erro não conseguiu enviar a nfce, vai aparecer a mensagem então gera novamente buscando dados das tabelas, tipo, não informo na tabela de itens da nfce, nem ncm, nem cest, nem ean, nem nome, somente os itens que são gerados pela venda, qtde e valor. Daí toda vez que gera o xml ele busca estes dados de novo do produto.

Acho q entendi... tb faço assim tipo pega da tabela produto e derivadas confrontando NCM CEST etc... Ok...
Mas aki q me refiro as vezes não conseguiu enviar pq estava errado/antigo o NCM (mudou) igual mudou em julhor alguns passaram a não existir, ou seja, o cara comprou a mercadoria em JUNHO deu entrada, atualizou o NCM (na entrada tb faço atualizar/amarrar os NCMs) mas ai o cliente não comprou este produto e em JULHO mudou como tivemos agora... ai começa a dar problema nesses itens..., tudo bem depois q arruma para, mas temos q pensar na hora do "FERVO" ta vendendo, ta com fila etc...

Ai esta venda foi concluida, mas a NFCe esta pendente por erro de NCM e ai? O cliente terá q arrumar pq não tem como Operador de caixa ficar arrumando.. se o segmento for um supermercado por exemplo...
É nesse ponto q me refiro pq dependendo o segmento podemos fazer de forma mais tranquilas, agora penso q temos q pensar nos "piores" cenários no sentido de resolver o problema (no caso aki deixar dinamico) pq ai os demais tb funcionarão.
Tem colegas q estão gerando um comprovante impresso tipo "COMPROVANTE NAO FISCAL..." ai o PDV continua passando compras e as NFCes q deram problema terão q ser tratadas... mas ressalto não sei se isso é permitido, imagino q não, mas como resolver? não tem como PDV ficar parando, Operador de Caixa ficar resolvendo??? Como isto???

Ok... ai as vendas q foram gerar NFCe e tiveram problema de NCM por exemplo estão pendentes... como garantir ou esquematizar q tem q ser gerado a NFCe??

Rubens escreveu:Daí tem o problema de dados mais antigos nas tabelas, Tive que criar rotinas de critica na hora de venda do produto, se não tiver ncm não passa, vai ser da mesma forma com o CEST.

Então pensei em fazer isso mas é complicado... tem muita gente com cadastros sem NCM tipo o cara era ECF e não gerava NFe (por incrivel q pareça... o contador q gerava, então a base do cliente ECF é 1 a de NFe esta no contador é outra)... ai o cara coloca NFCe e tem q vender... não tem como ficar criticando item a item na hora da venda pq para tudo ai... sei q o cliente tem q arrumar, tipo antes de implantar a NFCe fez um pente fino mas ficou coisa pra tras.. até deixar redondo vai dar esses tipos de problema e eu não queria fazer criticar item a item na venda e sim uma forma deixa a venda passar e a NFCe ficou pendente e o cara tem q arrumar e enviar a NFCe e o sistema ficar acusando q tem NFCe pendente ENTRE VENDAS e pedir senha pra liberar nova venda... ou algo do tipo, pq ai o cliente não trava mas afeta então assim q acalmar o cara TEORICAMENTE terá q resolver as NFCes pendente, e se não resolver no dia no outro dia o PDV amanhece travado por exemplo pra resolver as NFCes se não não vende... o q acham? alguma ideia melhor?

Rubens escreveu:Tive que adotar um ncm padrão, na hora da venda caso o ncm não seja encontrado na tabela do IBPT o programa assume um ncm padrão, dessa forma não para o PDV.

Então pensei nisso tb mas acho complicado pelo fato de assumir pra mim a responsabilidade, talvez seja prefirivel fazer como acabei de exemplificar acima.

Rubens escreveu:Tem uma nova regra agora acho que na última NT que melhora as informações de rejeição, e uma delas foi para mostrar o item que deu erro. Não implementei aqui não mas vai ser o próximo passo....

Sim com certeza a SEFAZ retornando os itens da mais segurança e podemos bolar algo mas acredito q acabe caindo no q falei acima o PDV não pode parar, digamos assim e temos q resolver as pendentes, mas tendo os itens q deram problema vindo da SEFAZ fica mais focado a resolução.

Achei interessante também o assunto.

A gente sempre valida pra não cadastrar coisa errada, mas a mudança de tabela do governo acabou por invalidar o código cadastrado.

A pior parte... o usuário pode não saber o que fazer.

Realmente, isso tudo tá uma doideira cada vez maior.... rs