Painel de líderes

Olá pessoal, Quem se utiliza do componente ACBrNFSe fiquem atentos com as alterações realizadas em alguns arquivos INIs dos provedores. Ao atualizar os fontes do ACBr a partir de hoje (13/05/2019), por conta de melhorias realizadas nas Units responsáveis pela assinatura digital se faz necessário enviar para os seus clientes os novos arquivos INIs bem como o novo executável. Caso esse procedimento não seja feito vai ocorrer erros ao tentar realizar a assinatura no pedido de cancelamento de uma NFS-e.

Só pra deixar documentado a experiência obtida com a balança. Esta funcionando perfeitamente com o ACBrMonitor e também com o ACBrFramework. Muito obrigado pelo comentário @Daniel Simoes.

Experimente desativar o anti-vírus. Por estar baixando um binário executável, pode ser que o ele esteja interferindo no processo e bloqueando a operação.

Tente um CleanUp... se não resolver, talvez você tenha que baixar novamente o ACBr, em outra pasta...

As mudanças efetuadas na ACBrDFeSSL são -- ACBrDFeSSL -- [-] Correção no método: TDFeSSLXmlSignClass.AdicionarSignatureElement, que não removia o final do XML, ao adicionar o Grupo de Assinatura... -- ACBrDFeXsLibXml2 -- [-] Método "TDFeSSLXmlSignLibXml2.AdicionarNode", corrigido para adicionar Grupo de Assinatura, dentro do Grupo "docElement" (por: DSA) By dopi on 05/13/2019 14:34 View Changes

Para NFe de emissão própria, pode-se obter apenas os eventos de Cancelamento, Carta de Correção e EPEC, pelo método ACBrNFe.Consultar. É facultado à UF, entretanto, retornar a lista completa de eventos, coisa que nenhuma UF faz, até onde sei.

Deu certo fazendo o "Clear up and Build". Obrigado.

Desculpem meu erro, mas corrigi o problema liberando o Firewall, as portas da minha rede e atualizando as DLLs na pasta do integrador, a minha confusão foi porque eu estava copiando apenas a IntegradorNFCE.dll e tem que copiar todas as DLLs do arquivo que esse link descreve: https://www.djpdv.com.br/como-emitir-nfc-e-usando-o-integrador-fiscal/ Obrigado.

@JonasBollis Obrigado! Consegui resolver o problema, era apenas as aspas duplas no inicio e no fim depois de convertido em base64. Descobri pela postagem abaixo. Agradeço a informação!

OK como estou fazendo teste na BA em homologação vou alterar a configuração para somente homologação para testar novamente. Já foi feito o teste e foi aprovado agora vou esperar para ver se em modo de produção agora esta obrigando a ForcarGerarTagRejeicao938 para a BA. Até o momento só era MG que tive q acionar esta flag.

Boa tarde. No Exemplo do ACBr eu informo o componente do integrador no ACBrNFe, com o Integrador instalado e atualizado, a dll IntegradorNFCE.dll está na pasta "%APPDATA%\Integrador" e os dados no integrador estão corretos e está dando o mesmo problema. Poderia me explicar como proceder pra corrigir? Obrigado.

Obrigado me ajudou muito. E também tive o norte para outras coisas. Agora estou atrás de fazer a função, todo dia primeiro em fazer a função de enviar o arquivos fiscais para e-mail dos contadores. Grato.

Boa tarde, Obrigada pela análise, adicionada para validação. Att.

Flavio, Você tem certeza que não tem nenhuma cidade no arquivo Cidades.ini que esteja usando o provedor RLZ? Veja: [5107958] Nome=Tangara da Serra UF=MT Provedor=RLZ NomeURL_H=mt/tangaradaserra NomeURL_P=tangaradaserra.mt.gov.br De onde você esta baixando os fontes dos componentes?

Obrigado Daniel, coisa de louco mesmo, exclui a pasta e criei outra com o nome ACBR2 e ai não deu erro. Obrigado BingWings, a resposta do Daniel resolveu.

Creio que você possa usar o método abaixo: function ValidarHash( const AStringList : TStringList; const Digest: TSSLDgst; const Hash: AnsiString; const Assinado: Boolean = False): Boolean; overload; Exemplo: if ValidarHash( StringOriginal, dgstSHA256, HashCalculado, True) then ShowMessage('Hash OK');

Acabo de receber, o comunicado oficial da Bematech Caso não esteja visualizando, acesse o preview aqui.

Pessoal, atualizei, reinstalei, e continuo com o mesmo problema, não está gerando a TAG, quando o valor está zero. alguem, aqui de São Paulo, conseguiu gerar sem problemas??? podem me passar qual é a UNIT que gera as TAGS do XML? vou dar uma olhada pra ver o que tem de errado.

Bom dia Celson, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Você deve conseguir obter os eventos de manifestação emitidos por terceiros, para as NFe de emissão própria. Os eventos de manifestação de emissão própria, para as NFe de terceiros destinadas, não são retornadas pelo método DistribuicaoDFe. O webservice também não retorna a situação atual da manifestação de uma NFe destinada.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado amigo, é isso mesmo, eu coloquei o CFOP errado de propósito que era para provocar o erro mesmo.. Esse método que vc informou retornou o texto mais bonito e amigável, era justamente isso que estava buscando! Vlw mesmo!

Sim, seria isto mesmo, muito obrigado Italo.

Pessoal, Sempre instalo o ACBr apagando os fontes antigos. vou tentar hoje de novo, fiz uma nova atualização. Estou usando DELPHI 7 mas como este campo NÃO É UNICODE não eh para dar problemas. Já instalei hoje de novo, com sucesso os pacotes. assim que fizer o teste junto ao cliente, posto o resultado.

no XML irá ficar assim <autXML> <CNPJ>12345678000191</CNPJ> </autXML> <autXML> <CNPJ>00000000000191</CNPJ> </autXML> <autXML> <CPF>12345678912</CPF> </autXML> usa o autXML.Add para adicionar 1, caso precise de mais de um... faça um loop

Bom dia Juliomar, Em outro post havia uma dica que resolveu meu problema.... Havia faltado incluir as seguintes linhas no meu código: ACBRNFSe.Configuracoes.Geral.PathIniCidades := PathINICidades; ACBRNFSe.Configuracoes.Geral.PathIniProvedor := PathINIProvedor; ACBRNFSe.Configuracoes.Geral.SetConfigMunicipio; Feito isso o problema foi resolvido... Muito obrigado..... Obs: Não sei marcar o tópico como resolvido..

Sugestão use para mexer com o seu arquivo sqlite o sqlitestudio é gratuito. acho que vai resolver

Obrigado Rofresi..

Esta feito obrighado deu certo.

Deu certo, obrigado.

vc preenche a propriedade fora dai, nao precisa mexer no codigo fonte. Assim: Cedente.Conta := ADataSetConfigServicoBanco.FieldByName('CONTA_CCR').AsString; Cedente.ContaDigito := ADataSetConfigServicoBanco.FieldByName('DV_CONTA_CCR').AsString; Cedente.Agencia := ADataSetConfigServicoBanco.FieldByName('AGENCIA_CCR').AsString; Cedente.AgenciaDigito := ADataSetConfigServicoBanco.FieldByName('DV_AGENCIA_CCR').AsString; Cedente.Modalidade := Trim(ADataSetConfigServicoBanco.FieldByName('MODALIDADE_SER').AsString); Cedente.DigitoVerificadorAgenciaConta := ADataSetConfigServicoBanco.FieldByName('DV_AGENCIA_CONTA_CCR').AsString; Sugestão: Cria o campo e deixa seu usuario preencher.

Aqui temos um verificador de updates rodando com o Windows em todas as máquinas e notificando caso encontre uma nova atualização. (não é necessário estar em todos os PC's. Mas como isso é instalado junto com o sistema e na prática não muda muita coisa. Deixamos assim) Quando o usuário clica para instalar a atualização em uma máquina qualquer, exibe uma janela com as melhorias, novidades, correções... Após o término do download do update, é gravado em um banco de dados especifico e temporário as informações do update, como: Nome, versão/build, data, novidades, MD5. Também gravamos o executável do InstallShield nesse banco (sim, gravamos um arquivo de mais de 700MB). Conforme print abaixo. Quando termina a instalação do update e o usuário inicia o sistema, os scripts necessários para o funcionamento da nova versão/build são rodados no SQL Server. (não precisa ser o servidor) Depois do banco de dados também estar atualizado, as demais máquinas "acusam" diferentes versões entre o executável e o banco de dados, possibilitando a atualização do sistema nesses outros computadores. Nesse momento ao invés de baixar o update novamente, acessamos o banco de dados temporário onde tem o arquivo já baixado e apenas instalamos. Quando o usuário abrir o sistema, os scripts não serão rodados pois já foram. Observação 01: Não importa se mais de um computador baixar a atualização ao mesmo tempo, antes de gravar o arquivo do InstallShield no banco, é verificado se ele já não existe. Observação 02: Os updates são controlados por CNPJ, UF... Já que as vezes é necessário uma correção imediata apenas no estado X. E ainda verificamos se o cliente está apto a receber o update já que o mesmo pode ter problemas financeiros, contrato de manutenção cancelado (não dando direitos a updates de versão, apenas build dentro da versão que o cliente adquiriu). Observação 03: Depois de todos os PC's atualizados, os dados da versão nova e o arquivo da versão são apagado desse banco de dados temporário. Observação 04: Existem atualizações criticas, nesse caso não fica a critério do usuário a instalação. O próprio atualizador, se encarrega de baixar e executar a instalação. Observação 05: Após o término da atualização no PC, solicitamos o registro da licença novamente para controlarmos qual é a versão que o cliente está utilizando. (de forma online e transparente já que as licenças são controladas por um HWID e não por um serial previamente cadastrado). Aqui controlamos por MD5. Ou seja, ao executar o sistema e algum arquivo (bpl, exe, dll..) não bater com o MD5 do executável. Não será possível executar o sistema.

Obrigado galera, já conseguiram me esclarecer um pouco mais. Vou tentar implementar e volto com o retorno.

Douglas, segue código, sofri alguns dias aqui fazendo funcionar, graças a grande documentação fornecida pelo estado. o problema que você deve estar passando é que o requestbody não pode ser um TStringStream, mudei para TStream e começou aceitar, também deixa as configurações como está abaixo, se tiver alguma coisa diferente vai voltar ao erro que esta aparecendo ai, coloca o componente no formulário (idhttp), não coloca nenhuma propriedade e apenas seta como no código abaixo, suave amigo, abraço. var: RequestBody: TStream; lResponse : TStringStream; ZipEncode : String; begin .... // Codifica o zip: ZipEncode := '"' + EncodeFile(NomeZIP) + '"'; // deixa o idhttp dessa forma: lResponse := TStringStream.Create(); RequestBody := TStringStream.Create(ZipEncode, TEncoding.UTF8); try idHttp1.Request.ContentType := 'application/json'; IdHTTP1.Request.CustomHeaders.Clear; IdHttp1.Request.CustomHeaders.AddValue('Accept', 'application/json'); IdHttp1.Request.CustomHeaders.AddValue('Host', 'https://tributario.sef.sc.gov.br'); IdHttp1.Request.CustomHeaders.AddValue('Cache-Control', 'no-cache'); IdHttp1.Request.CustomHeaders.AddValue('Content-Type', 'application/json'); idHttp1.Post('https://tributario.sef.sc.gov.br/api/drcSt/arquivo/ValidarEstrutura', RequestBody, lResponse); lResponse.Position := 0; // Trata o retorno em um richedit: reResp.Lines.LoadFromStream(lResponse); finally lResponse.Free(); end;

Veja os fontes da ACBrLIB http://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/

Eu obtive um resultado aqui com um contador .. mais sabe aquela situação que ele te fala mais não te passa certeza . aquela frase bem conhecida , "Eu lendo entendi isso !!!" ai vc fica naquela .. se é ou não é . rs Mais Obrigado pelo Retono Juliana .

Muito obrigado, cara, vou testar e aviso aqui, mas aparentemente é isso mesmo

Bom dia Thailor, Primeiramente, quero lhe informar que movi a sua postagem para o lugar correto. Você tinha postado em ACBrMDFe, sendo que esse é um componente para emitir o Manifesto de Documentos Fiscais Eletrônicos e não tem nada haver com Manifestação do Destinatário e muito menos baixar o XML da nota fiscal. 1. Podemos utilizar a função GetPathEvento: PathEvento := ACBrNFe.Configuracoes.Arquivos.GetPathEvento(xxxx, '', dDataEvento); onde xxxx é o tipo de manifestação e pode ser: teManifDestConfirmacao, teManifDestCiencia, teManifDestDesconhecimento ou teManifDestOperNaoRealizada. dDataEvento é uma variável do tipo TDateTime que contem a data do evento de manifestação do destinatário. É importante toda vez que for manifestar uma nota salvar no banco de dados a data da manifestação, o tipo de manifestação e a chave da nota que esta sendo manifestada. 2. Como dito acima ao manifestar se você salvar no banco o tipo de manifestação, você vai poder colocar no grid o tipo da mesma e não apenas Sim ou Não para indicar se já foi manifestada. 3. Se eu entendi você não esta em duvida qual o titulo escolher para a lista de notas, pois bem, na minha aplicação o titulo é: Documentos Localizados para o Destinatário. Define o que você achar mais claro para o usuário. 4. Por favor leia esse artigo: Como obter o XML do Fornecedor

@bilogyn Obrigado por compartilhar, mas evite colar trechos grandes de código no corpo da mensagem. Use a opção de anexar arquivos.

Boa noite. Eu consegui resolver fazendo um "miau". Depois de horas tentando fazer igual ao Fields Editor do Delphi eu percebi que não precisava de nada disso, o meu único problema era que, como eu crie uma propriedade que cria os Fields da minha classe e os configurava na query, ao abrir meu DM o componente é criado juntamente com suas propriedades, como eu coloquei no método "SET" da propriedade "ActiveFields" as funções que executavam a criação e as configurações dos Fields, dava o erro... Resolvi criando uma variável que eu inicializo no create da classe pra não deixar executar novamente a criação dos Fields existente ao passar pela propriedade... Mas nem tudo é perfeito, ao colocar uma classe no DM, eu só consigo criar os Fields na segunda tentativa, ou seja, tenho que ativa, desativar e ativar de novo pra que a propriedade funcione e crie os Fields, depois disso funciona 100%, porem não dá mais o erro na tela! Mais ainda aguardo sugestões, pois pra mim ainda não ficou bom... UTypeCode.pas

Olá pessoal, A pesar do titulo fazer referencia a NF-e, mas esse artigo é valido também para a NFC-e, CT-e, CT-e OS, MDF-e e BP-e. Alguns desenvolvedores preferem gerar através da sua aplicação o XML para depois ser lido pelo ACBrMonitor ou pelo componente que vão dar continuidade, ou seja, assinar, validar e enviar para SEFAZ. Vi relatos no fórum que o desenvolvedor gerou o XML com uma determinada chave e o Monitor ou o componente mudaram essa chave. Porque isso ocorre? Essa alteração é provocada porque o valor da tag cNF (se tratando da NF-e e NFC-e) esta com o valor zero ou possui um valor em cNF diferente do que foi usado para compor a chave. Se o valor for zero o componente que é usado pelo Monitor vai gerar um numero aleatório. Agora se o valor de cNF for diferente do que foi usado na chave o componente se encarrega de corrigir a chave. Como é composta a chave? Chave = <Código da UF(2)><Ano de Emissão(2)><Mês de Emissão(2)><CNPJ do Emitente(14)><Modelo(2)><Série da Nota(3)><Numero da Nota(9)><Tipo de Emissão(1)><Código da Nota(8)><Digito Verificador(1)> O <Numero da Nota> é o valor de nNF e o <Código da Nota> é o valor de cNF. Para os demais modelos de documentos fiscais eletrônicos temos: CT-e / CT-e OS <Numero do Conhecimento> = nCT <Código do Conhecimento> = cCT MDF-e <Numero do Manifesto> = nMDF <Código do Manifesto> = cMDF BP-e <Numero do Bilhete> = nBP <Código do Bilhete> = cBP

PERGUNTA: Eu uso o ACBr. Posso colocar o ACBr como Reponsável Técnico na emissão de algum documento fiscal eletrônico (ou DF-e, isto é, NF-e, NFC-e, CT-e, MDF-e, etc...) ? Mesmo que você use o ACBrMonitor Plus, a ACBrLib, os componente ACBr, algum programa exemplo que disponibilizamos, a resposta simples é NÃO. Não entenda mal. Reafirmamos nosso compromisso em ajudar os usuários do ACBr a resolver seus problemas no uso dos componentes, bibliotecas ou aplicativos que disponibilizamos na medida do possível. E claro, damos prioridades aos casos reportados por usuários que fazem uso do SAC ACBr. Mas não somos o responsável técnico pelo seu sistema, mesmo que ele use qualquer ferramenta que provemos. Talvez você queira entender um pouco mais, então vamos a uma resposta longa sobre isso. Vamos usar como exemplo a NF-e e NFC-e que são de longe os DF-es mais utilizados. Se você ler a nota técnica 2018.005 da NF-e/NFC-e vai encontrar o item "2 Sobre a Identificação do Responsável Técnico". Nesse item há a seguinte frase no parágrafo que explica o que é essa informação (grifo é meu): Veja que a primeira frase menciona que o "responsável técnico" pode não ser simplesmente um desenvolvedor, mas a empresa responsável tecnicamente pelo sistema de emissão. O que neste caso é vocês. Vocês respondem perante seu cliente e perante as autoridades pela emissão do documento fiscal. Os produtos do projeto ACBr (seja algum componente, o ACBrMonitor, ou uma ACBrLib) nesse processo é apenas uma ferramenta parte do seu software e não o sistema em si. Ou seja, é um framework/biblioteca/componente que ajuda seu sistema e sua empresa a emitir os documentos. Veja, não disponibilizamos sistemas para emissão, apenas ferramentas para ajudar na emissão. Isso fica mais claro quando lemos o restante do parágrafo, porque ele explica não só o que é o "responsável técnico", mas também o objetivo dessa informação ser necessária. Veja: A ideia é a SEFAZ poder entrar em contato com o responsável pelo emissor em caso de dúvidas ou problemas na emissão. Em caso de anomalias na emissão, com quem a SEFAZ teria que entrar em contato? Por exemplo: Em uma das reuniões do ENCAT, foi relatado que um sistema tentou retransmitir uma nota com erros no XML, por 70.000 vezes! Ou seja, mesmo recebendo o erro de rejeição por XML inválido, a aplicação ficou em algum Loop, tentando retransmitir o XML que já deveria saber que seria rejeitado. Isso é na verdade um ataque de DDOS, nos servidores do SEFAZ. Talvez um ataque sem intenção, mas não deixa de ser um... Mas nesse caso, quem a SEFAZ teria que contatar se essa empresa fosse seu cliente? É evidente que em caso de dúvidas ou problemas sobre o uso nas empresas que são seus clientes eles deverão entrar em contato com a sua empresa. Afinal de contas, nós do ACBr não sabemos como seu sistema funciona, muito menos conhecemos os seus clientes. Ainda mais, qualquer solução do ACBr, (quero dizer ACBrMonitor, ACBrLib, ou qualquer componente ou biblioteca que fornecemos), por si só nunca faz uso de um WebService. Qualquer WebService é acionado por sua aplicação. Ela, a sua aplicação, é responsável pela emissão. Chamar o ACBr de responsável seria basicamente o mesmo que colocar como responsável a Microsoft porque você usa o Windows nos seus clientes, ou a biblioteca OpenSSL porque você a usa pra assinar os documentos. Existe mais um detalhe que o item "2.1 Código de Segurança do Responsável Técnico - CSRT" nos ajuda a entender. Esse item fala do credenciamento do software emissor de DF-e na SEFAZ da UF e da empresa responsável. Se sua UF já tem esse cadastro, ou algum cadastro similar como era o caso do PAF-ECF, sem dúvida você entende que é sua empresa e seu software que deve ser cadastrado, independente de usar ou não alguma ferramenta de terceiros em seu sistema. Peraí! Tem mais! No terceiro parágrafo há a seguinte explicação sobre o CSRT, que pode ser exigido em formato de hash: Mais uma vez, se essa é uma informação conhecida somente entre a empresa desenvolvedora e Fisco, não teria como ser disponibilizada por nós. Senão, poderíamos nos passar por você. Seria como você dar seu RG ou Passaporte para outra pessoa se passar por você. Então para pra deixar isso claro pra qualquer pessoa com dúvida no futuro: O projeto ACBr não se responsabiliza por mal uso de nenhum dos programas, bibliotecas, componentes, ou códigos fontes disponibilizados. Usar qualquer um desses, incluindo o ACBrMonitor Plus, não dá direito a ninguém colocar o Projeto ACBr como responsável técnico, ou de qualquer outra forma responsável perante clientes ou autoridades. Se alguém pensar diferente, informamos que não tem licença para utilizar o que provemos. Pedimos o favor de ler com cuidado as licenças LGPL e GPL que usamos.

Ops, issoo e muito bom. Estava aguardando isso a tempos. Estava trocando todos os nossos clientes que são Cappta por SkyTef por esse motivo...Hj trabalhamos com a Cappta atraves de troca de TXT...

Boa tarde a todos, Conforme consta na Nota Técnica 2018/005 versão 1.30 (disponível na Biblioteca ACBr) as alterações referentes aos grupos de Retirada e Entrega que entrará em vigor no ambiente de produção agora dia 07/05/2019. Alterações no grupo Retirada As alterações se referem aos campos que estão destacados em amarelo, notem que todos eles são opcionais, isso significa que se eles não forem gerados não vai ocorrer nenhum problema, ou seja, a nota vai ser autorizada pela SEFAZ. Como é de costume no componente ACBrNFe esses novos campos estão com a mesma grafia apresentada na Nota Técnica. Observação importante, não devemos gerar o XML com esses novos campos e enviar para o ambiente de produção, pois este só estará apto a partir do dia 07/05/2019, mas nada impede de gerar e enviar para o ambiente de homologação, pois esse já esta aceitando o XML com os novos campos. Alterações no grupo Entrega Idem ao grupo de Retirada. Fragmento do XML com todos os campos de entrega informados: Para quem utiliza o ACBrMonitorPlus, abaixo as alterações em negrito na seções [Retirada] e [Entrega]: [Retirada] CNPJCPF= xNome= xLgr= nro= xCpl= xBairro= cMun= xMun= UF= CEP= PaisCod= Pais= Fone= Email= IE= [Entrega] CNPJCPF= xNome= xLgr= nro= xCpl= xBairro= cMun= xMun= UF= CEP= PaisCod= Pais= Fone= Email= IE= O ACBrMonitorPLUS SAC já esta preparado para gerar o XML com os novos campos, mas vale reforçar mais uma vez que a SEFAZ só vai aceitar esse novos campos no ambiente de produção a partir do dia 07/05/2019. Você pode baixar a versão atualizada do ACBrMonitorPLUS SAC em:

Boa tarde a todos, Já esta disponível em nossa biblioteca a Nota Técnica 2019/001 que trata sobre novas regras de validação. Resumo da NT: · Dificultar utilização de código de segurança fraco · Melhorar o controle de documentos referenciados e da identificação do destinatário · Descrever benefícios fiscais e informações da tributação do ICMS com mais precisão · Criação de valor máximo para a base de cálculo do ICMS, por unidade federada · Melhor gerenciamento de informações sobre o destinatário, tanto no serviço de autorização de NF-e quanto no serviço de registro de EPEC Datas previstas para entrada em vigor: 01/07/2019 - Ambiente de Homologação; 02/09/2019 - Ambiente de Produção. Alterações no componente: Nenhuma, visto que essa NT trata de novas regras de validação a serem implementadas pelas SEFAZ-Autorizadoras. Novas Regras de Validação: Criada a Regra de Validação B03-10, para dificultar a utilização de um código de segurança fraco, ou seja, o valor de cNF não vai poder ser igual ao valor de nNF e sim um numero aleatório. Criadas regras de validação a documentos referenciados:  Regra de Validação BA10-40 foi alterada, possibilitando a utilização do CNPJ 8 (somente os 8 primeiros dígitos) com o objetivo de identificar que a nota foi emitida pelo mesmo contribuinte, a critério da unidade federada. Criada a Regra de Validação BA10-50, exigindo que uma contranota de produtor rural somente possa referenciar uma nota emitida por outro produtor rural, a critério da unidade federada. Criada a Regra de Validação BA20-20, impedindo que seja referenciado um documento fiscal de uso exclusivo para operações internas em uma operação destinada a outra unidade federada ou para o exterior. Criada a Regra de Validação BA20-30, impedindo referência a um Cupom Fiscal, a critério da unidade federada. Criadas regras de identificação do destinatário: Criada a Regra de Validação E03a-30, impedindo o uso simultâneo de IE e de identificação de estrangeiro para o destinatário. Criada a Regra de Validação E14-30, impedindo informação de país de destino “Brasil” em operações destinadas ao estrangeiro. Criada a Regra de Validação E16a-40, exigindo a indicação de “operação com consumidor final” quando se indica que a operação é destinada a não contribuinte. Criadas regras de validação tornando obrigatória a informação do Motivo da Desoneração e do Valor do ICMS desonerado, caso seja informado o Código do Benefício Fiscal: Criada a Regra de Validação I05f-10, impedindo a informação de um código de benefício fiscal juntamente com um CST que não prevê benefício fiscal, a critério da unidade federada. Criada a Regra de Validação I05f-20, impedindo a informação de um código de benefício fiscal que não corresponda ao CST utilizado, a critério da unidade federada. Criada a Regra de Validação I05f-30, exigindo que seja informado o valor do ICMS desonerado ou o motivo de desoneração quando se utiliza um código de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N07-10, exigindo informações sobre o diferimento quando se utiliza um CST de diferimento, a critério da unidade federada. Criada a Regra de Validação N12-84, exigindo o código de benefício fiscal quando se utiliza um CST de benefício fiscal, a critério da unidade federada. Criada a Regra de Validação N12-88, exigindo que o CST corresponda ao tipo de código de benefício fiscal informado, a critério da unidade federada. Criada a Regra de Validação N12-90, exigindo valor do ICMS desonerado e o motivo da desoneração, a critério da unidade federada. Criada a Regra de Validação N18-10, exigindo a informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST seja MVA, a critério da unidade federada. Criada a Regra de Validação N18-20, não permitindo informação do percentual da margem de valor Adicionado do ICMS ST Informada caso a modalidade de determinação da BC da ST não for MVA, a critério da unidade federada. Criada a Regra de Validação W03-20, impedindo a informação de um valor de Base de Cálculo superior ao valor máximo estabelecido pela respectiva SEFAZ. Emitente: Criada a Regra de Validação 1C03-10, impedindo a informação de Razão Social do emitente diferente da existente no cadastro da SEFAZ. Destinatário: Criadas as Regras de Validação 5E17-10, 5E17-20, 5E1730, 5E17-40, 5E17-43, 5E17-46, 5E17-50, 5E17-60, 5E17-63, 5E17-70 e 5E17-80, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.  Serviço Autorização EPEC: Criadas as Regras de Validação 6P31-10, 6P31-20, 6P31-30, 6P31-40, 6P31-43, 6P31-46, 6P31-50, 6P31-60 e 6P31-63, para verificar se o destinatário está sendo informado corretamente ou se está em situação que o impeça de constar na NF-e como destinatário na operação com mercadoria ou prestação de serviços.

Obrigado @Italo Jurisato Junior... ficou um ótimo resumo

Bom dia. Este problema não está diretamente ligado à atualização da versão do ACBr mas sim porque a Sefaz está fazendo valer uma regra já existente a algum tempo na NT 2016.002. Essa regra começou a ser aplicada no ambiente de homologação no dia 22/04, e vai ser aplicada no ambiente de produção a partir do dia 20/05. Essa regra de validação é opcional por estado. Isso significa que cada estado pode decidir se aplica ou não essa regra de validação. Como já foi visto aqui no tópico a última compilação do ACBrMonitor PLUS já está correta de acordo com as regras, só teria que atualizar para esta última versão. Ou alterar o arquivo ACBrNFeServicos.ini com os endereços corretos.

Bom dia a todos, Muitos de nós já deve ter emitido uma Nota Fiscal ou Conhecimento de Transporte e o mesmo foi Denegado, não é verdade? Pois bem, o que vem a ser Uso Denegado, o que fazer quando isso ocorre e como prevenir? Status de um DF-e (NF-e, CT-e) Após enviar um DF-e para a SEFAZ, esta pode Autorizar o Uso, Denegar ou Rejeitar. Autorizar o Uso, é quando todas as informações estão corretas e o emitente e o destinatário não possuim nenhum problema com o Fisco, neste caso o DF-e é armazenado no banco de dados da SEFAZ e a venda ou o transporte por ser realizado. Rejeitado, é quanto alguma informação esta errada, neste caso o DF-e não é armazenado no banco de dados da SEFAZ e o procedimento a seguir é fazer as devidas correções e enviar novamente. Uso Denegado, é quanto todas as informações estão corretas, mas o emitente ou o destinatário possui algum problema junto ao Fisco, neste caso o DF-e é armazenado no banco de dados da SEFAZ, mas a empresa emitente do documento esta impedida de realizar a transação comercial ou prestar o serviço de transporte se este for o caso. O que fazer quando um DF-e é denegado? Inicialmente precisamos saber se o motivo da denegação tem haver com o emitente ou com o destinatário. Se o problema é com o emitente, este deve entrar em contato com a SEFAZ do seu estado e verificar qual é o problema, para que o mesmo seja sanado o mais breve possível. Se o problema é com o destinatário, o emitente deve entrar em contato com o destinatário e solicitar ao mesmo que resolva o problema junto ao fisco. Lembre-se, um DF-e denegado não pode ser cancelado. Como se prevenir? Antes de perder tempo em lançar uma nota / conhecimento e depois descobrir que o destinatário esta com problemas no fisco, será que podemos fazer algo antes? Sim, podemos nos prevenir, a maneira mais simples é, ao cadastrar um novo cliente, basta consultar o seu cadastro junto a SEFAZ. Essa consulta pode ser feita de forma automatizada, os componentes ACBrNFe e ACBrCTe possui um método chamado: ConsultaCadastro. Como usar? No programa exemplo do componente ACBrNFe temos um botão chamado Consulta Cadastro, para realizar a consulta precisamos da UF e do CNPJ/CPF da pessoa que desejamos consultar. Exemplo de código: Documento := Trim(OnlyNumber(Documento)); ACBrNFe1.WebServices.ConsultaCadastro.UF := UF; if Length(Documento) > 11 then ACBrNFe1.WebServices.ConsultaCadastro.CNPJ := Documento else ACBrNFe1.WebServices.ConsultaCadastro.CPF := Documento; ACBrNFe1.WebServices.ConsultaCadastro.Executar; for x := 0 to ACBrNFe1.WebServices.ConsultaCadastro.RetConsCad.InfCad.Count -1 do begin Situacao := IntToStr(ACBrNFe1.WebServices.ConsultaCadastro.RetConsCad.InfCad.Items[ x ].cSit); (...) end; Se o valor da variável Situação for zero significa que a empresa não esta habilitada, logo ela tem algum problema junto com o Fisco. Uma empresa cuja situação seja Não Habilitada as chances de um DF-e ser rejeitado é muito grande, logo devemos entrar em contato com essa empresa e solicitar que a mesma resolva o seu problema com o Fisco. Observação: De forma semelhante podemos usar a mesma rotina acima para o ACBrCTe, pois o retorno é exatamente igual. No Manual da NF-e paginas: 64 até 66, em especial os grupos <infCad> e <ender> temos varias informações que podem agilizar o processo de cadastro, vale a pena conferir. Espero ter ajudado.

tive esse erro: [21/03/2019 13:21:07][NfceTransporte][HNfeStatusServico2Soap12] O índice estava fora dos limites da matriz. , isso era problema com a geração dos dados da NFCe em base64, ou seja, os dados ficavam incompletos e o xml ia pela metade. da uma conferida nisso.

Atualizado em: 05/11/2019 - Revisado em: 11/11/2021 Documentos Aceitos Atualmente NFCe ECF 85 NF de Venda ao Consumidor(Mod. 2) Detalhamento da Situação por Tipo de Documento NF de Venda ao Consumidor (Mod. 2): Em vigor, com uso após adesão voluntária ou ou por obrigatoriedade terminando em 28/02/2020 quando utilizada exclusivamente para acobertar as operações fora do estabelecimento e 31/07/2021 para os demais contribuintes, considerando-se o último grupo de obrigatoriedade da NFCe. ECF 85: Em vigor (inclusive realizando lacração e autorização de uso). Uso após adesão voluntária ou por obrigatoriedade da NFCe é vedado. Veja abaixo sobre NFC-e. O uso de ECF deve terminando em 30/04/2022, considerando-se o último grupo de obrigatoriedade da NFCe (9 meses de uso após início da obrigatoriedade). ECF 09/09: Não aceito. NFCe: Calendário de obrigatoriedade se inicia em 01/03/2019 para novas empresas, com último grupo entrando em 01/08/2021. Adesão voluntária permitida a partir de 01/03/2019. Veja também: RESOLUÇÃO Nº 5.234 DE 5 DE FEVEREIRO DE 2019 SAT: Signatário, porém SEM legislação regulamento sua implantação. MFE: Não aceito Situação Responsável Técnico Conforme resposta obtida por meio do Fale Conosco da SEFAZ-MG e compartilhada conosco pelo usuário @pablozamba, a SEFAZ-MG não exigirá as informações relativas ao responsável técnico. Situação PAF-ECF: UF não exige laudo de homologação, porém determina que a solução seja compatível a legislação própria da UF, a qual gerou documentos de compatibilidade de requisitos entre as ERs do PAF-ECF e a legislação mineira (PORTARIA SRE Nº 132, DE 24 DE ABRIL DE 2014). Para uma visão geral dos documentos fiscais em todas as Unidades da Federação acesse nossos Mapas Fiscais. Para obter o guia de cadastro/credenciamento de sua Aplicação Fiscal junto ao SEFAZ, acesse nossa sessão de Downloads, os Requisitos Fiscais por UF.