Wesley Oliveira

Acabei de achar o problema. Foi feito uma alteração no código do ACBr pra Assinar o XML no ato da Validação, porém o nosso sistema faz uma validação de dados antes de permitir o envio, o que fazia a assinatura do xml. Após essa validação é onde estava sendo definido o tipo de emissão para 7 - SVC e, ao validar novamente, por já ter sido assinado, não fazia de novo. Atualizei o fonte do ACBr e reverti essa alteração manual e o XML foi autorizado sem problemas. Agradeço demais a disposição em ajudar. Pode considerar resolvido. Após esse procedimento, pude identificar que o XML que estava sendo gerado pelo meu sistema e o que estava efetivamente sendo enviado para a SEFAZ estavam diferentes e assim consegui identificar o problema. Muito obrigado.

Aqui o XML solicitado. 0-env-lot.xml

Boa tarde, Estou com problema ao enviar NF-e para o ambiente SVC-RS a partir de clientes da Bahia. Os servidores da SEFAZ-BA foram desabilitados desde ontem devido a ataques, então direcionamos os clientes a utilizarem a emissão em contingência pelo ambiente SVC-RS. O problema que estou tendo é que TODAS AS NOTAS estão sendo rejeitadas com código 297 - Assinatura diferente do calculado, mas as notas enviadas com os mesmos parâmetros (exceto ambiente) para qualquer outra SEFAZ está autorizando normalmente. Inclusive, quando passo os XML gerados pelo meu sistema no validador da SEFAZ-RS ele é autorizado. Se alguém puder me ajudar a analisar a situação, agradeço, pois todos os nossos clientes da Bahia estão impossibilitados de emitir NF-e desde ontem por causa disso. Já até enviei mensagem para a SEFAZ do RS na esperança de ter alguma luz sobre isso... Em anexo um dos XML que estamos tentando autorizar e o print do validador de XML da SEFAZ-RS. Agradeço imensamente. 29210308841102000303550000000065841100065848-nfe.xml

Já entendi o que estava ocorrendo. Eu não havia atualizado a unit pcnSignature. Estou com outro erro agora, de rejeição 851. Vou continuar fazendo testes.

Boa noite. Após a mudança de obrigatoriedade do QRCode, estou recebendo a rejeição 297 quando tento enviar o xml. Seguem em anexo 2 XMLs referente ao mesmo CT-e (Montados ligeiramente diferentes) e ambos retornam essa rejeição. Já verifiquei os cadastros e não encontrei nada com caracteres especiais e/ou quebras de linha, espaços em branco no início ou no fim, nada disso. Aqui estão as configurações que estou usando no componente: fAcbrCte.Configuracoes.Geral.Salvar := True; fAcbrCte.Configuracoes.Geral.VersaoDF := ve300; fAcbrCte.Configuracoes.Geral.IdentarXML := False; fAcbrCte.Configuracoes.Geral.GerarInfCTeSupl := fgtSempre; fAcbrCte.Configuracoes.Geral.SSLLib := libWinCrypt; fAcbrCte.Configuracoes.Geral.SSLXmlSignLib := xsMsXml; fAcbrCte.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; fAcbrCte.Configuracoes.Geral.SSLHttpLib := httpIndy; Atualizei os arquivos do ACBr hoje mesmo. Obrigado. XML alterado sem CDATA.xml XML Original.xml

Obrigado, foi bastante detalhado e esclarecedor. Estou mostrando estes argumentos ao pessoal do suporte aqui para que entrem em contato com o cliente que solicitou a mudança no sistema. Diz o suporte que, segundo o cliente, algumas empresas já estariam adaptando os Danfe para acomodar as "novas" descrições, mas ainda não recebi nenhum material desse para que eu pudesse ao menos postar aqui para vocês. Eu, particularmente, compartilho da idéia que a única coisa obrigatória nesse campo é o código, que já está corretamente sendo enviado e exibido. Mais uma vez, obrigado pelas explicações.

Foi o que pensei. Até entrei em contato com uma consultoria fiscal que temos, mas o espaço para descrição é pouco e não permite anexos, não consegui dar todos os detalhes e tudo que recebi de resposta foi que "se a NT diz que é assim, tem que ser assim". Aguardemos as próximas opiniões. Obrigado!

Olá a todos. A NT 2018.005 trouxe uma alteração na descrição do campo de Modalidade de Frete para algumas descrições bem grandes, por sinal. Entretanto, o layout atual do DANFE que o ACBr disponibiliza tanto não cabe as novas descrições, quanto a função que converte o tipo de modalidade na descrição também não segue o que está ditado na NT (arquivos atualizados hoje, 16/09). Há alguma previsão de alteração ou esta alteração não é obrigatória, como parece ser? Abaixo, a função atualizada do ACBr que faz esta conversão, vs. as descrições da NT. Obrigado pela atenção. function modFreteToDesStr(const t: TpcnModalidadeFrete; versao: TpcnVersaoDF): string; begin case versao of ve200, ve300, ve310: case t of mfContaEmitente : result := '0 - EMITENTE'; mfContaDestinatario : result := '1 - DEST/REM'; mfContaTerceiros : result := '2 - TERCEIROS'; mfProprioRemetente : result := '3 - PROP/REMT'; mfProprioDestinatario : result := '4 - PROP/DEST'; mfSemFrete : result := '9 - SEM FRETE'; end; ve400: case t of mfContaEmitente : result := '0 - REMETENTE'; mfContaDestinatario : result := '1 - DESTINATARIO'; mfContaTerceiros : result := '2 - TERCEIROS'; mfProprioRemetente : result := '3 - PROP/REMT'; mfProprioDestinatario : result := '4 - PROP/DEST'; mfSemFrete : result := '9 - SEM FRETE'; end; end; end; Descrições da NT: 5. Alteração do DANFE 5.1 Quadro do Transportador O campo identificação da Modalidade do Frete (id: X02, tag:modFrete) deverá ser preenchido com um dos seguintes códigos (NT 2016/002): 0=Contratação do Frete por conta do Remetente (CIF); 1=Contratação do Frete por conta do Destinatário (FOB); 2=Contratação do Frete por conta de Terceiros; 3=Transporte Próprio por conta do Remetente; 4=Transporte Próprio por conta do Destinatário; 9=Sem Ocorrência de Transporte.

Bom dia! Tenho os fontes atualizados do DANFE e estou em dúvida sobre o layout: Tanto o manual versão 6.00, quanto a última NT de layout (Ajustes Sinief 04/2019) retiraram dos grupos F (Local de Retirada) e G (Local de Entrega) alguns dados, tais como: Razão Social; IE; CEP; Telefone; E-mail; País; Porém, o DANFE agora tem espaço para exibição da Razão Social, IE, CEP e Telefone. Não achei em lugar nenhum se houve alguma alteração mais recente no layout do DANFE para excluir estes campos ou se a SEFAZ realmente comeu mosca. Alguém sabe me dizer?

Vou conferir aqui. Obrigado.

Bom dia. Tentei aqui e continua com o mesmo erro..

Olá! Estou começando a implementação do Reinf no meu sistema e ao tentar gerar os XML (Assinatura) está dando o erro "Falha ao localizar o nó de Assinatura" Tentei comparar com o que está sendo feito na aplicação exemplo do Reinf, mas aqui pra mim o exemplo apresenta o mesmo erro. A configuração do ACBr feita no sistema é essa: { Configurações Gerais Reinf } fACBrReinf.Configuracoes.Geral.FormaEmissao := teNormal; fACBrReinf.Configuracoes.Geral.ExibirErroSchema := True; fACBrReinf.Configuracoes.Geral.SSLLib := libCapicom; fACBrReinf.Configuracoes.Geral.VersaoDF := v1_04_00; { Configuração SSL } fACBrReinf.SSL.DescarregarCertificado; fACBrReinf.SSL.SSLDgst := dgstSHA256; fACBrReinf.SSL.SSLType := LT_TLSv1_2; fACBrReinf.SSL.SSLCryptLib := cryWinCrypt; fACBrReinf.SSL.SSLXmlSignLib := xsXmlSec; Alguém tem idéia do que pode ser? Obrigado.

A quem interessar, precisei alterar manualmente a linha (pcnNFeW.pas): //Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 0, nfe.Cobr.Fat.vDesc, DSC_VDESC); Gerador.wCampo(tcDe2, 'Y05', 'vDesc ', 01, 15, 1, nfe.Cobr.Fat.vDesc, DSC_VDESC); Para "forçar" gerar a tag vDesc mesmo com o valor zerado. Assim parou de dar a rejeição 905 e também de criticar o layout do campo vDesc.

Boa tarde pessoal! Estou com problema com essa tag Fat também. Eu estou informando conforme a nota técnica pede: <cobr> <fat> <nFat>15951</nFat> <vOrig>2874.90</vOrig> <vLiq>2874.90</vLiq> </fat> <dup> ... </dup> </cobr> Mas continuo recebendo mensage 905 Rejeição: Campos do grupo Fatura não informados. Estou em ambiente de Homologação, Espírito Santo. Comparei com o XML que o amigo marcoprodata postou anteriormente e está com a estrutura correta. Tentei até forçar a criação da tag <vDesc> com valor 0.00, mas aí começou a dar erro de validação do valor.

No meu caso descobri que o arquivo ACBrNFeServicos.ini estava com um erro (não sei se é padrão ou se foi alterado aqui, usamos o Delphi 7). Nas linhas [WSDL_V4_MG] e [SOAP_V4_MG] a url estava faltando um "L" (portalfisca.inf.br). Apenas nessas linhas eu identifiquei esse problema.