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.

Estou tentando consultar o status de uma NF-e de MG (produção também) mas o XML de retorno vem vazio. O XML de pedido/url estão corretos. Ao consultar pelo site da SEFAZ/MG com a chave da NF, é possível identificar corretamente.

O propósito do que eu tentei fazer é justamente poder fazer a busca geral dos códigos, pra poder montar uma lista absolutamente completa com os NCMs válidos. Fazer isso usando a busca por descrição traria muita duplicidade de informações e mais consultas desnecessárias do que o site da receita já nos obriga a fazer. Quando falei de genérica, me referi à quantidade de parâmetros que eram obrigatórios passar, gerando apenas poucos registros como resultado. Hoje, finalmente consegui finalizar o programa e trazer todos os NCMs cadastrados automaticamente, apenas com a confirmação do captcha. A consulta toda levou aproximadamente 11 minutos e meio. Sei que é muito tempo, mas é uma rotina que não precisa ser executada a todo momento. Quem tiver real interesse em verificar a forma final como foi feito, é só entrar em contato comigo. Quem precisar somente da validação de um único NCM, a versão que disponibilizei na postagem anterior já te atende, basta adaptar à sua realidade. Obrigado a todos.

Boa tarde! Consegui chegar a algum lugar.. Rs fiz uma aplicação de teste pra poder comunicar com o site da Receita. Já consigo capturar o Captcha e realizar a consulta que retorna os NCMs, porém a consulta é MUITO específica, assim como acontece no site. Estou disponibilizando os fontes (feitos no Delphi 10.1 Berlin) somente com componentes padrão e Indy para comunicação. O problema agora é justamente como conduzir a consulta, uma vez que a consulta pelo "Capítulo" retorna apenas os dados da "Posição", que devem ser utilizados para retornar os dados de "Subposição 1" e assim por diante. No parâmetro "codigo" é preciso passar o "último código possível" a ser gerado com a combinação Capítulo + Posição + (...) Dúvidas, meus contatos estão disponíveis no fonte. Obrigado pela atenção e seguimos na luta... Consulta NCM.rar

Pessoal, consegui ter retorno com o que eu postei anteriormente! Estou fazendo mais testes aqui com os parâmetros e logo mais posto a estrutura correta pra consulta.

Baseado na url do amigo marcelo_sp, estou fazendo testes de requisição usando o Postman pra isso (pra quem não conhece, é free e serve justamente pra testes de http request). Estou enviando aqui o arquivo .json com as configurações do request que eu consegui encontrar na própria página. Atualmente não consigo ainda recuperar os registros, mas obtenho uma resposta do site (não é possível completar a requisição), que me parece então faltar apenas acertar na configuração dos parâmetros. Estou enviando também um txt dos parâmetros (headers) que encontrei.. Vai que estou deixando passar alguma coisa aqui. Acredito que esse é um caminho que podemos seguir. Se puderem, baixem o arquivo e testem as requisições que são possíveis de se fazer. Obrigado. Postman_ConsultarNCM.json ConsultarNCM_RequestHeaders.txt

Não é só a consulta individual, mas qualquer consulta... Como disse o amigo Marcelo (e eu, um pouco mais acima), a estrutura de consulta da receita foi alterada. Pela url padrão do ACBr não é mais possível fazer nenhum tipo de consulta dos NCM. Continuamos tentando identificar a melhor maneira de voltar a fazer isso funcionar, mas tá difícil..

Agora tem o Captcha que tem que validar antes de qualquer coisa. Mesmo depois de validar, fiz os testes no navegador, passando os dados na url como é feito pelo componente, pra todas as opções, mas não carrega nem no navegador. Parece que alteraram a forma de passagem dos parâmetros e estão analisando só direto dos componentes que estão na tela, ignorando o que é passado na url. Alguém teve algum progresso pra fazer a consulta de todos os NCM?

Senhores, Os arquivos abaixo foram alterados de acordo com o que eu identifiquei: Adição da opção 2 - Declaração Única de Exportação (DU-e) ao Enum TACBrTipoDocto. Como o conteúdo da property é definido pelo usuário, não encontrei em nenhum arquivo a necessidade de UTILIZAÇÃO da nova opção pelo próprio código, apenas na vivência do usuário, portanto a alteração é simples. Fiz o teste de geração do arquivo SPED Fiscal (meu caso) e não houve problemas nem incompatibilidades. Alteração realizada (nos dois arquivos): /// Informe o tipo de documento TACBrTipoDocto = (docDeclaracaoExportacao, // 0 - Declaração de Exportação; docDeclaracaoSimplesExportacao, // 1 - Declaração Simplificada de Exportação; //Adicionada opção abaixo docDeclaracaoUnicaExportacao // 2 - Declaração Única de Exportação. ); ACBrECFBlocos.pas ACBrEFDBlocos.pas

Obrigado. Estou alterando o arquivo aqui e vou fazer os testes necessários.

Prezados, a partir da versão 2.0.22 de 11/12/2017, foi adicionada a opção de Declaração de Exportação (Registro 1100 SPED Fiscal, campo IND_DOC): 2 - Declaração Única de Exportação Entretanto, atualizei os fontes do ACBr hoje e, na Unit ACBrEFDBlocos não existe o Enum correspondente a esta nova opção, conforme print abaixo. Isto ainda será implementado? Há previsão? Preciso efetivar alteração para um cliente que já faz uso das DU-Es. Agradeço a atenção.