Erro: O valor do campo 'numeroRecibo' está inválido - ACBrGNRe - Projeto ACBr
January 3 in ACBrGNRe
Go to solution Solved by José M. S. Junior, January 27
bsoft 106
Estamos recebendo o erro "O valor do campo 'numeroRecibo' está inválido. O valor deve possuir 10 caracteres numéricos!".
Isso acontece porque, durante a leitura do retorno, o ACBr interpreta o número do recibo como inteiro. Aparentemente nessa virada de ano o n° recibo ficou tão grande que não consegue ser mais interpretado como inteiro. Segue em anexo a correção.
Foi somente a troca de
Leitor.rCampo(tcInt, 'ns1:numero');
Leitor.rCampo(tcStr, 'ns1:numero');
pgnreRetEnvLoteGNRE.pas
Foi pro SVN, rev. 24124.
Também estamos com o mesmo problema para notas emitidas em 2022.
mesmo erro no ACBR Monitor
Esta sendo analisado se ficará desta forma a alteração e será gerado uma nova compilação
Download ja disponivel.
Márcio Antônio 12
Atualizei o meu svn, e fiz essa alteração no meu código, numeroLote := StrToInt64(FormatDateTime('yymmddhhmm', Now));
mas está me retornando essa mensagem de erro:
Falha na validação da Mensagem do Evento: '-2093926237' violates pattern constraint of '[0-9]{1,15}'
o que mais posso ajustar?
Mensagem de erro completa no anexo...
14 minutos atrás, Márcio Antônio disse:
Atualize novamente, foi subido um possível ajuste para o SVN.
Eu atualizei agora a pouco, mas vi aqui que o problema é o seguinte, eu fiz esse ajuste aqui,
numeroLote := StrToInt64(FormatDateTime('yymmddhhmm', Now));
para não dar o novo bug do milênio, sendo que essa minha variavel numeroLote é do tipo int64, e na function TACBrNFe.EnviarEvento(idLote: integer): Boolean;
, ela é integer, esse é o problema... o que posso fazer para contornar esse problema?
O ajuste foi enviado há pouco mesmo, atualize os fontes teste e reporte, se possível no Discord que é mais dinâmico.
newmaicon
newmaicon 0
Oi pessoal, desculpe a minha ignorância, meus fontes geram a chave conforme, então tive o mesmo problema.
Eu entrei nele e modifiquei yymmddhhmm (ano,mes,dia,hora,minuto) para (mes, ano, dia, hora, minuto) o mês sempre vai até 12, então nunca vai passar da chave máxima que é 21.
Resumindo a NFE emitiu normalmente e a chaves estão aleatórias como sempre foram.
Será uma solução? ou terei algum impacto?
Eu atualizei os fontes porem percebi que o mes de referencia que eu passava 01 ele gera o xml apenas com o '0'
Enviado a poucos minutos um novo comit, favor testar.
Acabei de atualizar (após esse ultimo commit) os fontes e está retornando o seguinte erro:
"cvc-enumeration-valid: Value '1' is not facet-valid with respect to enumeration '[01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12]'. It must be a value from the enumeration."
2 minutos atrás, xandebugmann disse:
Consegui resolver esse problema sempre enviando o mês com zero a esquerda.
Agora estou conseguindo gerar as guias normalmente novamente.
4 minutos atrás, xandebugmann disse:
tente informar 01 ao invés de 1 somente
Rafael Herrera 9
Olá, @Juliana Tamizou, tudo bem contigo?
Eu iria relatar esse erro referente à rejeição 503 da GNRe, mas eu vi que o pessoal da BSoft já relatou o problema. Estou usando a versão 0.1.0.89 do AcBrLibGnre, liberada ontem, 05/01/2021, mas mesmo assim está apresentando a rejeição 503. Saberia me informar se, além da atualização da lib, eu preciso configurar mais alguma coisa?
ACBrLib2.ini
2 horas atrás, Rafael Herrera disse:
Boa tarde, por favor verifique se sua aplicação esta realmente utilizando a versão atualizada, pois esse erro já foi corrigido na ultima versão.
Em 06/01/2022 at 14:33, José M. S. Junior disse:
Bom dia, @José M. S. Junior, tudo bem contigo?
Obrigado pelo retorno. Eu realizei as verificações de versão das DLL's que estão no meu ambiente, mas todas as versões estão corretas. Eu realizei mais testes com a versão "0.1.0.90" e consegui simular a situação novamente. Dessa vez o problema se deu quando foi enviado uma GNRe de FCP para o ambiente de homologação e o retorno do WS foi "[190] - Erro ao recepcionar o Lote". O problema é que o componente continuou o processo de consulta do recibo, mesmo não tendo número de recibo no retorno do envio do lote, e, dessa forma, a mensagem de retorno que o componente apresenta é "[503]-O valor do campo 'numeroRecibo' está inválido. O valor deve possuir 10 caracteres numéricos!". Em ambiente de produção, o envio da GNRe com valores de FCP funcionou, mas é provável que, caso o WS retorne alguma rejeição no processamento do lote, o componente continuará o processo de consulta de recibo da mesma forma e a rejeição 503 será apresentada novamente. Até a versão "0.1.0.84" este problema não acontecia.
Vou anexar as evidências aqui para vocês analisarem.
1. Data da versão da DLL "0.1.0.90"
2. Versão das DLL's em meu ambiente:
3. Versão da Lib no ACBrLib.ini
4. Retorno com o processamento do envio do lote
6. Retorno com o processamento da consulta de recibo
7. Resultado do envio na aplicação de demonstração:
guia.ini 20220111122307-env-lot.xml 20220111122307-rec.xml -ped-rec.xml -pro-rec.xml ACBrLib.ini Demo GNRe VB6.zip
5 horas atrás, Rafael Herrera disse:
Por favor anexe também o log.txt da lib para análise.
16 horas atrás, José M. S. Junior disse:
Bom dia, @José M. S. Junior.
José, eu não consegui simular exatamente o mesmo erro, porque a guia que estava tentando enviar ontem para Alagoas, e que estava apresentando a rejeição "[190] - Erro ao recepcionar o Lote" no retorno de processamento do lote, está sendo autorizada. Enfim, eu precisei tentar de outra forma aqui tentando enviar a GNRe para MS com os códigos de receita inválidos para registrar o log de eventos. A situação é semelhante a anterior, com rejeição no retorno do processamento do lote, mas agora o retorno é "[156] - cvc-pattern-valid: Value '100099' is not facet-valid with respect to pattern '[1-9]{1}[0-9]{0,3}' for type '#AnonType_produtoitemitensGNREdadosGnre_2.00_1'.". Segue novamente as evidências acrescidas do log de eventos na opção "4 - Log paranoico".
20220112105103-env-lot.xml 20220112105103-rec.xml guia_ms.ini -ped-rec.xml -pro-rec.xml ACBrLibGNRe-20220112.log ACBrLib.ini Demo GNRe VB6 bin.zip
3 horas atrás, Rafael Herrera disse:
Aparentemente esse problema já existia antes, parece não ter haver com o problema inicial gerado pela mudança de ano e pelo tipo de campo, mas vamos verificar...
araujojunior
Só compartilhando aqui para quem ainda estiver com dificuldades, mesmo realizando build all várias vezes após atualização o erro ainda permaneceu para mim. O meu jeito de resolver foi executando o instalador do ACBr. Talvez algo com a minha configuração de instalação inicial.