leotelles
-
Total de ítens
172 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por leotelles
-
-
13 horas atrás, Bruna Pimenta disse:
Rejeicao: Codigo de Hash no QR-Code difere do calculado
@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.
-
-
30 minutos atrás, Luciano Rodrigues Pereira disse:
Talvez o sistema tenha transformado os caracteres especiais nesse #$D
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
-
8 minutos atrás, Luciano Rodrigues Pereira disse:
Não havia acentuação ou caracteres especiais no endereço?
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.
-
10 minutos atrás, BigWings disse:
O tipo 90 para a tag motDesICMS só pode ser usado junto aos CST 40, 41 e 50.
Eu não tinha me atentado a isso. Deu certo. Muito obrigado pela ajuda @BigWings
-
9 minutos atrás, BigWings disse:
Atualize a pasta de Schemas.
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:101Header de Lote:
07.1 Nº da Versão do Layout do Lote 14 16 9(003)
Conteúdo atual:030
Conteúdo esperado:060Segmento Q:
20.3Q Banco Correspondente Cód. Bco. Corresp. na Compensação 210 212 9(003)
Conteúdo atual:Brancos
Conteúdo esperado:000Analisando 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.
-
25 minutos atrás, BigWings disse:
Provavelmente a SEFAZ ainda não atualizou o webservice com as regras da NT 2016.002 v. 1.50.
Tente informar pag.indPag como ipNenhum.
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:
-
10 minutos atrás, André Ferreira de Moraes disse:
Vc está gerando o XML pelo ACBr?
Seu XML está identado, ao linearizar ele o mesmo é validado com sucesso no site da SEFAZ RS: https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx
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.
-
43 minutos atrás, André Ferreira de Moraes disse:
Vc está com os fontes atualizados?
Como está a propriedae ACBrNFe1.Configuracoes.Geral.VersaoQRCode ?
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.
-
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?
-
30 minutos atrás, rodrigoogioni disse:
Visto que no campo duplicatas, não vai aceitar mais outras formas de pagamento
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!
-
1 hora atrás, BigWings disse:
Faça o teste informando a configuração de versão do QR-Code no componente:
ACBrNFe.Configuracoes.Geral.VersaoQrCode := veqr100;
Veja também se não há um arquivo ACBrNFeServicos.ini desatualizado no diretório da aplicação.
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 -
Obrigado pela resposta, @Italo Jurisato Junior!
Segue XML em anexo para análise.
-
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.
-
Em 08/05/2018 at 16:58, Maiquel disse:
Mas, considerando a regra da última NT, que por sinal não teve alteração neta situação, o correto é fechar 100.
Se informado GLP (cProdANP=210203001) o somatório dos percentuais pGLP(id:LA03a) e pGNn(id:LA03b) e pGNi(id:LA03c) deve ser igual a 100.
Fiz assim também.
QRCode 2.0
em NFC-e - Nota Fiscal do Consumidor Eletrônica
Postado
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?