leotelles

Bom dia, pessoal. Aqui a rejeição é a seguinte: Porém, a chave de acesso existe no QR-Code, conforme pode-se observar na url abaixo: https://www.homologacao.nfce.fazenda.sp.gov.br/qrcode?p=35180744495554000182650130000003291783665505|2|2|1|0B96E676FFE82AC1BF14D04D915756D602D82A76 Alguém enfrentou esse problema e conseguiu resolver?

@Bruna Pimenta, aqui nos deparamos com esse erro uma vez. No nosso caso, o problema era com CSC. O correto era 62f50ea5-13b3-4337-aceb-867dc9c31174, mas na hora de cadastrar no sistema, o usuário retirou os traços, ficando assim: 62f50ea513b34337aceb867dc9c31174. O CSC passado para o componente do ACBr era diferente do gerado no site da fazenda.

Apesar de não ser notado visivelmente, realmente tinha algum caractere especial no endereço. Notei que o problema acontecia apenas com um cliente específico. Então, setei null para o campo do endereço no banco de dados e digitei o endereço novamente. Fazendo isso, os caracteres #$D não foram gerados e não houve quebra de linha. Parece que essa "limpeza" resolveu. Obrigado pela ajuda, @Luciano Rodrigues Pereira

Acredito não ser esse o problema. Nosso sistema não permite acentuação ou caracteres especiais no endereço. No caso, o endereço de todos os títulos era "R RIO TIETE", sem acento.

Bom dia. Um de nossos clientes que emite boletos pelo Itaú (layout 400) teve um arquivo de remessa rejeitado pelo banco. Analisando o arquivo, vi que em todos os títulos estava quebrando a linha logo após o endereço do sacado. Essa quebra de linha acontecia porque estavam sendo inseridos os caracteres #$D logo após o Logradouro, quebrando a linha entre o Sacado.Logradouro e o Sacado.Numero. Resolvi temporariamente fazendo um StringReplace para remover os caracteres #$D. Fazendo isso, o arquivo de remessa foi gerado sem a quebra de linha. Sei que essa não é uma solução ideal, mas, como não consegui entender como os caracteres #$D apareceram, não consegui pensar em outra solução além de remover eles. Se alguém conseguir entender a origem do problema e sugerir uma solução melhor, eu agradeço. Obs: em anexo estão a unit alterada e o arquivo de remessa com quebra de linha para análise. ACBrBancoItau.pas cb120602.rem

Eu não tinha me atentado a isso. Deu certo. Muito obrigado pela ajuda @BigWings

O erro persiste mesmo com os Schemas atualizados.

Boa tarde. Na NT 2016.002 v1.50 foi acrescentada a opção 90 (Solicitado pelo fisco) no campo Motivo da Desoneração do ICMS (motDesICMS). Ao enviar uma NF-e com essa opção 90, recebo o erro mostrado na imagem. Suspeito que o webserive da SEFAZ SP (estou testando em homologação) ainda não esteja preparado para essa mudança, mas gostaria de saber se alguém fez esse teste e se conseguiu enviar com essa opção, para sanar a dúvida. Desde já agradeço. Obs: XML em anexo para análise. 35180520745660000109550130000000241867346741-nfe.xml

Bom dia. Um de nossos clientes que emitem boleto pela Caixa Econômica Federal (layout 240) recebeu a seguinte mensagem do suporte do banco, apontando problemas no arquivo de remessa: Header de Arquivo: 20.0 No da Versão do Layout do Arquivo 164 166 9(003) Conteúdo atual:050 Conteúdo esperado:101 Header de Lote: 07.1 Nº da Versão do Layout do Lote 14 16 9(003) Conteúdo atual:030 Conteúdo esperado:060 Segmento Q: 20.3Q Banco Correspondente Cód. Bco. Corresp. na Compensação 210 212 9(003) Conteúdo atual:Brancos Conteúdo esperado:000 Analisando o manual mais recente disponibilizado pela Caixa, verifiquei que as informações enviadas pelo suporte do banco estão de acordo com o manual. Fiz alterações na unit do ACBr para corrigir o problema. Segue em anexo a unit alterada e o manual mais recente com os campos alterados destacados (para consulta). Aproveitando o assunto, faço um questionamento aos moderadores: O Número da versão do layout do arquivo (posição 164 a 166 do Header de Arquivo) e o Número da versão do layout do lote (posição 14 a 16 do Header de Lote) são alimentados com valores fixos no código fonte. Seria viável transformar isso numa propriedade do componente para possibilitar a alimentação dinâmica? Digo isso porque a tal versão muda vez ou outra e penso que um valor fixo no fonte para esse caso não é uma boa solução. ACBrBancoCaixa.pas Manual_Leiaute_CNAB240_SIGCB.pdf

Ao enviar em modo síncrono o erro persistiu, mas quando eu passei ipNenhum para a tag pag.indPag a NFC-e foi enviada e autorizada corretamente. Aparentemente, essa tag está funcionando no webservice da NF-e mas ainda não foi implementada no webservice da NFC-e em SP. Muito obrigado @André Ferreira de Moraes e @BigWings pela ajuda!

Segue os arquivos -soap*.xml anexados: 1-env-lot-soap.xml 1-rec-soap.xml 351000010080487-ped-rec-soap.xml 351000010080487-pro-rec-soap.xml

Sim, eu estou gerando pelo ACBr. Eu identei o xml para melhor análise nos testes que eu estava fazendo. Não Sabia que a identação interferia no validador da SEFAZ RS. Ao enviar o arquivo linearizado que você anexou, o validador da SEFAZ RS retornou: 760 - [Simulacao] Rejeicao: NFC-e com dados de cobranca (Fatura,Duplicata Vi que eu estava alimentando o grupo de cobrança para NFC-e. Removi esse grupo e o site do validador da SEFAZ retornou conforme imagem. Sobre o erro "245 - [Simulacao] Rejeicao: CNPJ Emitente nao cadastrado", ele acontece porque o XML que estou validando é de SP e o validador verifica que o emitente não está cadastrado na SEFAZ do RS, certo? Então ele não tem muita importância... Ou estou enganado? Enfim, mesmo após a correção do grupo de cobrança, o demo do ACBr e meu sistema continuam retornando a mensagem de erro informada anteriormente. Em anexo está o novo XML que estou tentando enviar. 35180544495554000182650130000002831377585362-nfe.xml

Sim. Os fontes, os schemas e o arquivo ACBrNFeServicos.ini estão atualizados. ACBrNFe1.Configuracoes.Geral.VersaoQRCode := veqr100; Em anexo está o erro retornado pelo demo do ACBr

Informações adicionais: Ao passar pelo método ACBrNFe1.WebServices.StatusServico.Executar o cStat está 107 (Serviço em Operação); Ao entrar no método WebServices.Envia (dentro do ACBrNFe1.Enviar), após passar pelo Enviar.Executar o cStat passa para 103 (Lote recebido com sucesso); Quando passa pelo método FRetorno.Executar (dentro do WebServices.Envia), o cStat muda para 225 (Falha no Schema XML do lote de NFe).

Boa tarde. Após fazer as alterações da NT 2016.002 v1.50 não estou conseguindo enviar NFC-e em ambiente de homologação para SP. Validando o xml no site https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx, obtive o retorno conforme imagem em anexo. Alguém pode me ajudar a entender esse problema, por favor? XML em anexo para análise. Obs: NF-e consigo enviar normalmente. 35180544495554000182650130000002771534792834-nfe.xml

Pessoal, testei as alterações desta NT para a NF-e de SP e está tudo OK. Porém, estou tendo alguns problemas para enviar a NFC-e, mas ainda estou analisando para entender ao certo o que está acontecendo. Vocês conseguiram emitir NFC-e normalmente?

Com as mudanças da nova NT, agora aceita outras formas de pagamento.

Problema resolvido. Eu tinha duas pastas diferentes de schemas no meu computador e acabei atualizando a errada. De qualquer maneira, obrigado pela ajuda pessoal!

Fiz conforme o instruído, mas o problema persiste... Há mais alguma configuração que eu possa verificar?

Atualizei o aquivo ACBrNFeServicos.ini. Está na revisão 15144 e a última atualização foi dia 15/05/2018 às 15:39:33. Me confirme por favor se as informações abaixo (extraídas do arquivo) estão corretas: [NFCe_SP_H] NfeInutilizacao_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nfeinutilizacao2.asmx NfeConsultaProtocolo_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nfeconsulta2.asmx NfeStatusServico_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nfestatusservico2.asmx NfeConsultaCadastro_3.10=https://homologacao.nfe.fazenda.sp.gov.br/ws/cadconsultacadastro2.asmx RecepcaoEvento_1.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/recepcaoevento.asmx NfeAutorizacao_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nfeautorizacao.asmx NFeRetAutorizacao_3.10=https://homologacao.nfce.fazenda.sp.gov.br/ws/nferetautorizacao.asmx URL-QRCode=https://www.homologacao.nfce.fazenda.sp.gov.br/NFCeConsultaPublica/Paginas/ConsultaQRCode.aspx URL-ConsultaNFCe=https://www.homologacao.nfce.fazenda.sp.gov.br/NFCeConsultaPublica/Paginas/ConsultaPublica.aspx EventoEPEC_1.00=https://homologacao.nfce.epec.fazenda.sp.gov.br/EPECws/RecepcaoEPEC.asmx NFeAutorizacao_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeAutorizacao4.asmx NFeRetAutorizacao_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeRetAutorizacao4.asmx NFeInutilizacao_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeInutilizacao4.asmx NFeConsultaProtocolo_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeConsultaProtocolo4.asmx RecepcaoEvento_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeRecepcaoEvento4.asmx NfeStatusServico_4.00=https://homologacao.nfce.fazenda.sp.gov.br/ws/NFeStatusServico4.asmx URL-QRCode_2.00=https://www.homologacao.nfce.fazenda.sp.gov.br/consulta URL-ConsultaNFCe_2.00=https://www.homologacao.nfce.fazenda.sp.gov.br/consulta URL-QRCode_1.00=https://www.homologacao.nfce.fazenda.sp.gov.br/qrcode URL-ConsultaNFCe_1.00=https://www.homologacao.nfce.fazenda.sp.gov.br/consulta ACBrNFeServicos.ini

Obrigado pela resposta, @Italo Jurisato Junior! Segue XML em anexo para análise. 35180544495554000182650130000002471628082815-nfe.xml

Bom dia! Ao tentar enviar uma NFC-e em ambiente de homologação de SP na versão 4.0, estou recebendo o erro abaixo. Obs: ACBr e Schemas estão atualizados. De onde o componente do ACBr busca esse endereço que o erro aponta como grande demais?

Boa tarde. Aqui também tive esse problema. Resolvi removendo a linha do código e ignorando a mensagem do dfm.

Fiz assim também.