cefantacini

De ontem pra cá, alguns clientes estão recebendo este erro ao tentar emitir NFe por SP. Algumas informações. O erro só acontece com quem tem certificado A3, porém tem clientes que tem o A3 e estão conseguindo emitir. O erro só acontece na NFe, NFSe por exemplo está indo com o mesmo certificado... Abaixo como está a configuração do componente. Alguém passando pelo mesmo problema?

Boa noite, eu estou passando pelo mesmo erro e não estou sabendo como solucionar. No meu caso deu um erro no momento da emissão e eu não tenho a chave da nota. E se eu for tentar consultar pelo RPS recebo o erro "Identificador mal formado. O ID da DPS deve conter 42 números". Qual seria e melhor solução nesse caso? Como deu erro na transmissão (X203 Não retornado nenhuma NFSe) eu preciso fazer a consulta para saber se a nota foi emitida ou não.

No meu caso encontrei o erro, eu estava atribuindo .Titulo.Carteira depois de .Titulo.NossoNumero, foi só atribuir antes que resolveu.

No meu caso eu estava preenchendo as propriedades .Cedente.TipoCarteira := tctRegistrada; (1) .Banco.LayoutVersaoArquivo := 810; Porem, depurando, percebi que mesmo eu tendo preenchido a propriedade TipoCarteira com 1, quando chegava na procedure function TACBrBancoSicoob.CalcularTamMaximoNossoNumero(const Carteira: String; const NossoNumero : String = ''; const Convenio: String = ''): Integer; begin case StrToIntDef(Carteira,0) of 1 : begin if fpLayoutVersaoArquivo = 810 then Result := 8 else Result := 7 end; 9 : Result := 9; else Result := 7; end; fpTamanhoMaximoNossoNum := Result; end; O parâmetro Carteira chegava como 0 Se mudar a linha case StrToIntDef(Carteira,0) of para case StrToIntDef(Carteira,1) of Fica resolvido, porém optei por não mudar o fonte do ACBr para não correr risco de problema em futuras atualizações. Sendo assim a melhor solução que encontrei foi voltar a usar o nossonumero com 7 posições.

Acredito que ainda deva passar por revisão sim, inclusive encontrei outro erro nela....

No grupo de preenchimento das informatções da IBS Municipal, na nota técnica do CTe, o campo pAliqEfet, do grupo gRed, se refere as UF envolvidas, o correto seria os Municipios envolvidos? Será que a redação da nota técnica está errada ou são as UFs mesmo?

Eu atualizei o ACBr e segui as orientações do Ítalo. Eu estava pegando a chave e removendo o literal do documento (NFe, CTe, MDFe) do inicio ... Como a chave passou a vir sem o literal, eu estava usando apenas 41 (ou 40 no caso do MDFe) dos 44 caracteres numéricos da chave. Fazendo os ajustes o problema foi resolvido. Se quiser pode fechar o tópico.

Olhando a mensagem de erro, todos os caracteres da chave são numéricos ....

No meu caso, atualizei o ACBr, reconstrui o Lazarus, limprei e reconstrui o sistema e o problema persiste ...

Atualizei o ACBr hoje e ao tentar cancelar a NFe recebo o seguinte erro: Adcionalmente atualizei a pasta de schemas mais o problema persiste...

Estou sim eu fiz essa verificação....

Eu depurei e acredito que encontrei onde está o problema, mais não tenho certeza se a solução que encontrei pode dar algum "efeito colateral" No ACBr novo, dentro do arquivo: ....\Fontes\ACBrBoleto\ACBrBancoSicoob.pas tem uma procedure que não tem no mesmo arquivo do ACBr antigo: . . function TACBrBancoSicoob.CalcularTamMaximoNossoNumero(const Carteira: String; const NossoNumero : String = ''; const Convenio: String = ''): Integer; begin case StrToIntDef(Carteira,0) of 1 : begin if fpLayoutVersaoArquivo = 810 then Result := 8 else Result := 7 end; 9 : Result := 9; else Result := 7; end; fpTamanhoMaximoNossoNum := Result; end; Esse parametrro carteira vem nulo, dai ele assume o 0 e cai no else e assume 7; Se eu simplesmente tratar o else da mesma forma que o 1 o problema fica resolvido function TACBrBancoSicoob.CalcularTamMaximoNossoNumero(const Carteira: String; const NossoNumero : String = ''; const Convenio: String = ''): Integer; begin case StrToIntDef(Carteira,0) of 1 : begin if fpLayoutVersaoArquivo = 810 then Result := 8 else Result := 7 end; 9 : Result := 9; else begin if fpLayoutVersaoArquivo = 810 then Result := 8 else Result := 7 end; end; fpTamanhoMaximoNossoNum := Result; end;

Atualizei e fiz o teste, porém na nova atualização o problema permanece...

Provavelmente o problema é nessa procedure CalcularTamMaximoNossoNumero, mais eu não consegui entender como ela é codificada

Eu fiz um teste de atualizar o ACBr novamente hoje e a mensagem de erro permaneceu. Dai voltei a versão anterior que eu tinha (backup) de antes da atualização de sábado passado e o problema foi resolvido. Pelo que percebi foi alguma alteração recente no ACBr que está gerando o problema ....

Conta bancária vc diz? Até antes da atualização dos ACBr estava funcionando normal com o leiaute 810 e 8 dígitos nessa conta.... Está mensagem aparece quando eu peço para gerar a remessa....

Depois das mudanças no campo Nosso Numero no sicoob no inicio do ano eu fiz os ajustes no programa para se adaptar as modificações do componente. Na ocasião fui orientado aqui no fórum a preencher o LayoutVersaoArquivo com 810 se fosse boleto do sicoob. Porém atualizei o ACBr semana passada e agora ao gerar uma remessa do Sicoob recebo a seguinte mensagem de erro: Teria alguma configuração adicional a fazer depois da atualização?

Estou fazendo uma consulta da NFSe por RPS. O parametro sucesso volta True, porém não volta mais nenhum dado da nota. Aparentemtente a nota não foi emitida. Qual seria a forma correta de eu saber se a nota foi emitida ou não nesta situação. Eu estava tratando o parametro "sucesso", mais aparentemente não é a forma correta...

Era isso mesmo, obrigado. Se quiser pode fechar o tópico.

Tem um cliente que vem do emissor gratuito do sebrae e segundo ele, lá tem a opção de não imprimir a data/hora da entrada/saida. Existe alguma configuração no ACBr para isso?

Finalizando aqui, liquidei o boleto e o crédito entrou na conta, portanto, pelos meus testes a parte de cnab está OK

Apenas complementando a mensagem anterior o problema da recusa se deu exatamente pelo numero 00000001, que provavelmente já foi utilizado, sendo assim: Colocando o preenchimento do componente na sequencia abaixo: DM.Boleto.Banco.TipoCobranca := cobBancoob; DM.Boleto.Banco.LayoutVersaoArquivo := 810; Gerei o boleto com 8 digitos, a impressão ficou OK, enviei para o banco, o banco aceitou, gerei uma segunda via do boleto no site do banco, a linha digitável ficou igual a linha digitável gerada pelo ACBr. Vou fazer o pagamento do mesmo e verificar se o crédito entra na conta, tendo essa informação informo aqui.

Eu achei um erro no meu código eu estava atribuindo: DM.Boleto.Banco.LayoutVersaoArquivo := 810; Antes de DM.Boleto.Banco.TipoCobranca := cobBancoob; Inverti a sequencia e parou de gerar o digito verificador Adcionalmente fiz como vc sugeriu, 00000001 para o nosso numero A impressão ficou OK Porem o banco está recusando a remessa: Eu não posso continuar dfazendo da forma anterior, usando 7 digitos e não preenchendo LayoutVersaoArquivo := 810 ? Desta forma estava funcionando com o unit que vc havia me passado ontem....

O meu DEMO esta estranho, os arquivos estão na pasta, mais ao abrir o projeto ele não mostra nem form e nem unit, já apaguei a pasta do DEMO e baixei de novo e não adiantou....

Eu atualizei o ACBr, reconstrui o Lazarus, e setei o valor 810 para a propriedade LayoutVersaoArquivo Gerei um boleto com o NossoNumero com 8 posições: 72500001 Porem, tanto na remessa, quanto no boleto impresso saiu o digito verificador: Sendo assim o banco recusou o arquivo cnab.