lesf

Encontramos o problema. Fui fazer um teste com o exemplo do AcBr e funcionou corretamente. Na comparação entre os dois projetos, encontramos o problema: Essa configuração (Record Field Aligment) estava como Byte (padrão em nossos projetos desde sempre). Ao alterarmos para Quad Word tudo funcionou corretamente. Fica a dica caso alguém tenha esse mesmo problema. Abraço a todos, fiquem a vontade para fechar esse topico.

Boa tarde a todos, Após atualizar nossos fonte para a versão mais recente do AcBr nos deparamos com a seguinte situação: Sempre utilizamos essa configuração, no Delphi Tokyo 10.2. // Configuração do Certificado e SSL NFeV4.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; NFeV4.Configuracoes.Geral.SSLLib := libWinCrypt; NFeV4.Configuracoes.Geral.SSLHttpLib := httpWinHttp; NFeV4.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Utilizamos sempre a versão da libxml compilada com MinGW, sempre funcionou sem qualquer erro. Após atualizarmos os fontes, estamos com erro sempre que utilizamos a libxml2 para carregar XML, como no anexo acbr.png A variável aDoc fica com um conteúdo inválido ocasionando um Access violation nos passos seguintes. Perceba que ela não fica nula. Estamos com somente uma versao do aquivo libxml2-2.xml no disco e esta no mesmo diretório do executável. Em anexo segue também o arquivo gerado pelo //DEBUG anterior que nós tiramos o comentário, o log de instalação e o arquivo ACBR.inc que estamos utilizando. Testamos também a versão sem MinGW e ocorre o mesmo problema. Alguém já passou por isso ou tem alguma idéia ? Pesquisamos em outros tópicos semelhantes e não chegamos a nenhuma conclusão. Grande abraço a todos e agradeço antecipadamente a atenção. XmlOriginal.xml log_Delphi_10.2_Tokyo_Win32.txt ACBr.inc

Quando for emitida uma NF-e e PELO MENOS UMA das situações abaixo estiverem descritas na Operação da NF-e e FOR INFORMADO o Grupo de ICMS para a UF de Destino (ICMSUFDest), será retornado a rejeição "695 - Informado indevidamente o grupo de ICMS para a UF de destino": Operação Estadual (idDest = 1) ou com Exterior (idDest = 3); Operação com Consumidor Normal (indFinal = 0); Operação com Contribuinte (indIEDest = 1) ou com Contribuinte Isento (indIEDest = 2); Operação de prestação de serviços (ISSQN); Operação com combustível (comb) derivado de petróleo. Código ANP diferente de: 820101001, 820101010, 810102001, 810102004, 810102002, 810102003, 810101002, 810101001, 810101003, 220101003, 220101004, 220101002, 220101001, 220101005, 220101006, 560101001; Data de Emissão anterior a 01/01/2016, em Produção. Será que o item 5 não seria o seu problema Eduardo ? Tem um item (1) na sua NF que é derivado de petróleo.

Conseguimos enviar. O problema estava no ID, tem que ser um novo ID para cada alteração no R-1000.

Bom dia a todos, Enviamos ano passado um registro R1000 sem a validade final informada. Como precisamos alterar algumas informações, estou tentando enviar uma alteração desse registro R1000 informando a validade final para que eu possa posteriormente enviar um novo R1000 de inclusão no novo período com as novas informações. O que acontece é que estamos recebendo a rejeição " MS0037 - Já existe na base de dados do Ambiente Nacional um evento com mesma identificação". Alguém passou por isso ? Em anexo a solicitação e o retorno. Agradeço a atenção, Leandro 20190212111205-env-lot.xml ID1002780160000002019021210241757514-R5001.xml

Não tinha pensado nessa abordagem. Estava imaginando buscar por um documento específico. Vou tentar esse método. Obrigado pela atenção.

Boa tarde a todos, Um cliente solicitou uma solução para buscar as informações do evento de averbação vinculado a uma determinada NFe emitida POR ELE MESMO. Pelo webservice de consulta essas informações não estão disponíveis. Pela função DistribuicaoDFePorChaveNFe retorna a mensagem: Rejeicao: NF-e indisponível para o emitente Até onde eu sei o documento fica disponível somente após a Manifestação do Destinatário, mas tem uma outra empresa que jura para o meu cliente que consegue essa informação via webservice. Alguém teria alguma informação se existe uma maneira de trazer o xml desse evento de averbação ? Agradeço desde já a atenção de todos.

Voltou ao normal aqui (SP).

Mesmo problema aqui. Enviando grupo Fatura corretamente e a SEFAZ rejeitando.

Venda para Consumidor Final deve calcular o FCP constante no grupo <ICMSUFDest>. Não tem ST para consumidor final pois ele não é contribuinte. Acredito que seja isso.

Inacreditável! Aqui o mesmo erro com um cliente para uma NF do Paraná. Não aceita vencimento da duplicata para o dia 21/10/2018.

Aqui por enquanto a única solução foi prorrogar o vencimento em 1 dia para poder autorizar. A SEFAZ SP estava indisponível momentos atrás, pode ser que estejam atualizando as regras.

Aqui também está rejeitando, com data de vencimento igual a 02/07/2018.

Esse erro de SSL ocorreu em alguns clientes nossos no Windows 7. Para resolver, têm que estar instalado o Service Pack 1 além da atualização de segurança KB2992611.

Boa tarde a todos, Me deparei com a seguinte situação na NFe 4.0 que não me lembro de ter passado na versão anterior. Quando a nota fiscal é DENEGADA com status 302, a SEFAZ retorna a seguinte mensagem : <cStat>302</cStat><xMotivo>Uso Denegado: Irregularidade fiscal do destinatário</xMotivo> Percebam que a frase possui um acento na palavra 'destinatário'. O que acontece é que quando o ACBr vai concatenar o protocolo no final do XML ele não está tratando isso e o XML acaba ficando incorreto devido a codificação UTF-8. Alguém mais está passando por isso ? Abraço a todos! Leandro