Problema Status NFe (retorno lote SEFAZ)


#1

Olá colegas!

Sou de Criciúma - SC, estou há algum tempo estudando o Adempiere e acompanhando o desenvolvimento da comunidade.

Observando a atualização recente da branch Development (merge com Kenos), resolvi testar a “versão”.

Fiz toda a configuração inicial, efetuei todo o procedimento desde o pedido de venda até a geração do XML e envio do lote. No entanto, ao tentar receber a resposta do lote, recebí o seguinte erro:

===========> MLBRNFeLot.consultaNFe: lbr_NFeStatus Invalid value - 610 - Reference_ID=1100004 - 100 - 101 - 112 - 111 - 102 - 105 - 106 - 104 - 103 - 224 - 252 - 454 - 453 - 297 - 298 - 242 - 239 - 238 - 240 - 291 - 295 - 293 - 296 - 290 - 294 - 292 - 281 - 285 - 283 - 286 - 280 - 284 - 282 - 236 - 216 - 219 - 213 - 258 - 259 - 246 - 244 - 208 - 207 - 223 - 269 - 245 - 226 - 289 - 406 - 405 - 275 - 274 - 273 - 272 - 271 - 270 - 287 - 288 - 279 - 278 - 277 - 276 - 221 - 263 - 264 - 237 - 401 - 228 - 212 - 253 - 204 - 203 - 227 - 999 - 202 - 215 - 225 - 260 - 261 - 210 - 233 - 232 - 234 - 209 - 230 - 229 - 231 - 211 - 235 - 478 - 267 - 268 - 220 - 254 - 255 - 205 - 218 - 206 - 217 - 407 - 403 - 201 - 222 - 266 - 265 - 247 - 257 - 214 - 249 - 250 - 248 - 251 - 262 - 256 - 241 - 404 - 299 - 402 - 243 - 107 - 108 - 109 - 110 - 302 - 301 [21] java.lang.IllegalArgumentException: lbr_NFeStatus Invalid value - 610 - Reference_ID=1100004 - 100 - 101 - 112 - 111 - 102 - 105 - 106 - 104 - 103 - 224 - 252 - 454 - 453 - 297 - 298 - 242 - 239 - 238 - 240 - 291 - 295 - 293 - 296 - 290 - 294 - 292 - 281 - 285 - 283 - 286 - 280 - 284 - 282 - 236 - 216 - 219 - 213 - 258 - 259 - 246 - 244 - 208 - 207 - 223 - 269 - 245 - 226 - 289 - 406 - 405 - 275 - 274 - 273 - 272 - 271 - 270 - 287 - 288 - 279 - 278 - 277 - 276 - 221 - 263 - 264 - 237 - 401 - 228 - 212 - 253 - 204 - 203 - 227 - 999 - 202 - 215 - 225 - 260 - 261 - 210 - 233 - 232 - 234 - 209 - 230 - 229 - 231 - 211 - 235 - 478 - 267 - 268 - 220 - 254 - 255 - 205 - 218 - 206 - 217 - 407 - 403 - 201 - 222 - 266 - 265 - 247 - 257 - 214 - 249 - 250 - 248 - 251 - 262 - 256 - 241 - 404 - 299 - 402 - 243 - 107 - 108 - 109 - 110 - 302 - 301 at org.compiere.model.PO.set_Value(PO.java:815) at org.compiere.model.PO.set_Value(PO.java:689) at org.adempierelbr.model.X_LBR_NotaFiscal.setlbr_NFeStatus(X_LBR_NotaFiscal.java:2380) at org.adempierelbr.model.MLBRNotaFiscal.authorizeNFe(MLBRNotaFiscal.java:736) at org.adempierelbr.model.MLBRNFeLot.consultaNFe(MLBRNFeLot.java:316) at org.adempierelbr.process.ProcLotReturn.doIt(ProcLotReturn.java:70) at org.compiere.process.SvrProcess.process(SvrProcess.java:147) at org.compiere.process.SvrProcess.startProcess(SvrProcess.java:105) at org.adempiere.util.ProcessUtil.startJavaProcess(ProcessUtil.java:160) at org.adempiere.util.ProcessUtil.startJavaProcess(ProcessUtil.java:105) at org.compiere.apps.ProcessCtl.startProcess(ProcessCtl.java:649) at org.compiere.apps.ProcessCtl.run(ProcessCtl.java:394) at java.lang.Thread.run(Thread.java:679)

Pelo que entendí, não há na tabela ADEMPIERE.AD_REF_LIST um registro para o Status da NF com o valor 610 (campo VALUE). Percebí que os registros desta tabela com o campo AD_REFERENCE_ID = 1100004 correspondem aos códigos de mensagens de Status do Sefaz para NFe. No entanto, por algum motivo, os códigos de mensagens a partir do 478 não estão na tabela (por isso o erro de código 610 não existente).

Fiz uma rápida busca (grep) nos scripts do LBR (até mesmo no diretório trunk-lbrk), e realmente não encontrei os inserts para tais códigos.
O seguinte pdf contém todos os códigos existentes, inclusive o 610, referente ao erro (verificar do 748 para baixo):
receita.pb.gov.br/Servicos/n … sorNfe.pdf

Alguém já passou pelo mesmo problema? Saberiam me informar se realmente está faltando parte dos códigos de status, ou o problema é outro?

Dica: para reproduzirem o erro, se verificarem o pdf com os códigos, o erro 610 significa:
Rejeição: Total da NF difere do somatório dos Valores compõe o valor Total da NF.

Por enquanto é isso, caso seja necessário mais informações, estarei monitorando o tópico.

Obrigado desde já.
Leandro.


#2

Olá Leandro,

Realmente está faltando um script para atualização destes códigos. Vou subir na branch da Kenos e te informo.

Att.


#3

Bom dia Ricardo!

Verifiquei que a Priscila Pinheiro fez um “commit” na branch da Kenos, adicionando um novo script contendo os Status da dos códigos.

Os status estão de acordo com as últimas atualizações do SeFaz? De onde foram tirados? Das Normas Técnicas disponíveis em nfe.fazenda.gov.br/portal/li … +YMyk/50s= ?

Obs.: Pergunto pois notei a ausência de alguns códigos no script… apesar de não ter certeza das razões.

Grato pela atenção.

Leandro Natal Coral.


#4

Leandro,

Caso esteja faltando algum código de status, verifique se todos os scripts foram aplicados e caso o erro persista abra um ticket em: adempiere.atlassian.net/browse/LBR

Att.


#5

code.google.com/p/oseb/source/br … ssue16.sql - PostgreSQL

code.google.com/p/oseb/source/br … ssue16.sql - Oracle

Fonte: nfe.fazenda.gov.br/portal/l … ol5hhSYZk=
Arquivo: Manual_de_Orientacao_Contribuinte_v_5.00.pdf
Tabela: 5.1.1 Tabela de Códigos de Erros e Descrições de Mensagens de Erros


#6

Eu não recomendo o uso dos scripts acima, pois não seguem os requisitos de qualidade para desenvolvimento de um software de gestão, já que apagar todos os registros de uma tabela e recriar não é algo aceitável para os padrões que tentamos seguir no LBR.

O script que foi disponibilizado no LBR cria os novos códigos e atualiza os códigos já existentes, é uma atualização não-intrusiva.

Sobre a versão, este prevê até a NT 2012.002.


#7

Ricardo, acho que você deve ter conhecimento da estrutura do adempiere, e sabe que o script que eu postei não é intrusivo, e muito menos afeta a qualidade do software… na verdade ele é até mais limpo que disponibilizado por vocês que ao executa-lo irá apresentar vários erros, o que para um usuário sem conhecimento, pode sim causar confusão, visto que ele tenta fazer o insert de registros que já existem de scripts anteriores

o adempiere, não usa o id da ad_ref_list como fk em nenhuma tabela, ele salva o value, então ao apagar os registros e criar novamente não irá causar qualquer problema de integridade.


#8

Mario, exatamente porque eu tenho conhecimento nas práticas de desenvolvimento de software e do Adempiere que eu não recomendo o uso desta forma. Qualquer sistema com qualidade o bastante não necessita apagar uma tabela e recriar, é inviável. Imagine um cenário em que o usuário precisou adicionar um status fornecido numa NT manualmente, caso rode este script a atualização feita pela usuário será apagada e não há maneira de recuperar. Isto seria uma falha de integridade no meu ponto de vista.

Por favor faça testes ou leia com atenção os scripts antes de falar que o script gera erros, o cenário que você citou não existe, pois todos os scripts tem um WHERE.

Isto é apenas uma sugestão, cada um trabalha da maneira que acha certa.

Att.


#9

Bom dia amigos!

Acredito que, em casos de registros que não identificam quem os mantém (desculpa se estiver falando bobagem, sou novo no Adempiere, mas acredito que o Adempiere trata isso como Entidade), ou seja, desenvolvidos colaborativamente, deve-se utilizar transação de UPDATE (com as devidas consistências, assim como foi feito pela Priscila). Se o novo script não previsse algum registro existente (código de status, nesse caso), um DELETE/INSERT poderia apagar informações indevidamente.

Ricardo, há intenção de incluir a Nota Técnica 2012.003 na sua branch?

Mário, o seu script está de acordo com todas as Notas Técnicas?

Amigos, observo que atualmente há um “retrabalho” na comunidade (já entendi a questão das versões). Enfim, já se pensa em encontrar um ponto de desenvolvimento em comum na comunidade Adempiere?


#10

Olá Leandro, Bom Dia,
Os scripts foram criados com base nas notas técnicas eu adicionei dois scripts,
no nome contêm a data da última nota técnica utilizada, caso haja notas posteriores
com mudanças no Status da NF-e iremos realizar outro script.


#11

A meu ver é sempre bastante complicado tentar agradar a todos, o HG Mercurial ajudou bastante neste ponto onde é possível criar branches e dividir os trabalhos, neste caso somente aqueles trabalhos que atendam as convenções do software entram como oficial.

Mesmo assim é preciso ter espírito de trabalho em equipe para entender que algumas coisas podem ter efeito negativo no sistema em alguns cenários, o foco hoje é a qualidade e não a quantidade. Atualmente temos bastante contribuições e eu fico feliz de saber que as novas funções que desenvolvemos e as metodologias que usamos estão sendo copiadas para outros forks.


#12

Ok, obrigado pelos esclarecimentos.