Painel de líderes

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.

Para saber mais como tratar a contingência, na NFCe, vejam essas dicas abaixo... Nessas palestras que fizemos em conjunto com a Elgin, existe uma apresentação, com Download Livre... (baixe o arquivo Apresentação - ACBr - Elgin - ACBrNFe.pdf) Na 2a Edicao do Dia do ACBr, nosso Consultor @José M. S. Junior, ministrou uma excelente palestra sobre o assunto... Veja o vídeo no nosso Canal do YouTube No Curso Completo do ACBrMonitPlus, @José M. S. Junior, também tem aulas específicas sobre a Contingência Off-line https://www.projetoacbr.com.br/forum/video/browse/39-aula-26-contingencia-da-nfe-e-nfce/ Se você é usuário do SAC do ACBr, creio que esse vídeo de um Webinar, ministrado por @André Ferreira de Moraes, responderá todas as suas dúvidas...

Correção já enviada ao SVN.

Boa Tarde, não sei se é o local correto para informar, se estiver errado me desculpem. mas questionei o sefaz RS e responderam que não será exigido Abaixo o E-mail: As alterações previstas na Nota Técnica 2018.005 ainda não foram implementadas. Elas deverão ser implementadas no ambiente de testes (homologação) no dia 25/02/2019, e no ambiente de produção no dia 29/04/2019. O grupo de informações do responsável técnico é opcional por estado. Isso significa que cada estado pode decidir se exige ou não essas informações. Inicialmente, essa informação somente poderá ser exigida por estados que possuam cadastro de desenvolvedor (Ex.: PR e PA). Os demais estados somente poderão exigir essa informação posteriormente, quando tiver sido implementado o Cadastro Nacional de Responsável Técnico. O RS não possui cadastro de desenvolvedor, e não vai exigir essa informação, pelo menos até a implementação do Cadastro Nacional.

Você utiliza o FastMM no seu projeto? Em caso negativo, passe a utilizar.

Vou conferir aqui. Obrigado.

Veja:

Olá Rafael, certinho, agradeço e obrigado, Leão

O gmail pode estar identificando o XML como corpo do e-mail. Se você usa o componente ACBrMail diretamente para envio veja se está informando o parâmetro Disposition, ele por padrão é adInline o que pode confundir o cliente de email. Caso use o método EnviarEmail do ACBrNFe ele já deve ir dessa forma.

A Secretaria da Fazenda do Estado do Ceará anunciou no dia 15/02/2019 a disponibilização de uma nova versão do Driver MFE que permite a comunicação direta entre o Aplicativo Comercial e o MFE sem o Integrador Fiscal. Esta alteração visa agilizar o processo de venda, diminuindo o tempo necessário para autorização do CF-e. Para quem utiliza o componente ACBrSAT, o uso da nova versão do Driver MFE sem o Integrador Fiscal acontece quase que de forma transparente. Atualize o Driver MFE para versão 01.05.01 ou superior e configure as seguintes propriedades no ACBrSAT ACBrSAT1.Modelo := satDinamico_stdcall; ACBrSAT1.NomeDLL := 'C:\Arquivos de Programas (x86)\SEFAZ-CE\Driver MFE\Biblioteca de funções\mfe.dll'; //Pasta de Instalação do Driver MFE. Lembrando que a SEFAZ ainda exige que o Integrador deve permanecer instalado na máquina. Para mais informações sobre como usar o MFE sem o Integrador Fiscal, veja https://www.djpdv.com.br/como-usar-o-mfe-sem-o-integrador-fiscal/

Pessoal consegui resolve o problema, estava enviando código = 31 mas deveria enviar a sigla MG na tag Emit.EnderEmit.UF,

" Sugerimos que procure as demais UFs autorizadas para saber a posição destas. " Dá pra ver claramente, que até eles estão meio perdidos quanto a isso. rs Pessoal, não sei vocês, mas, não vejo isso com bons olhos. Assim como o PAF-ECF era burocrático e "fechado", estou especulando aqui que, em algum momento veremos uma movimentação semelhante para o rumo das DF-e's. Além disso, a Receita e Sefaz dos estados, depois de tentar fechar o cerco pra cima dos clientes, agora estão começando voltar seus olhos pra nós, pobres mortais. Não acredito que a finalidade será "inicialmente identificar consumo indevido". Tem coisa "preta" vindo por aí.

Boa tarde! Creio que a resposta do post anterior responde a sua pergunta.

baixou do GitHub?

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

Olá, simplesmente deletei o pcnRetConsReciNFe, do formulário, de deu certo. obrigado Leão

Você está com as Dlls atualizadas?

Bom dia, Itamar Bornatto. Veja o tópico abaixo:

Um possível POG, seria comentar as linhas no ACBrECFBematech.pas, que fazem a checagem do ACK... procedure AnalisaACK ; begin if fsACK = 0 then raise EACBrECFSemResposta.create( ACBrStr( 'Impressora '+fpModeloStr+' não responde (ACK = 0)')) else if fsACK = 21 then { retorno em caracter 21d=15h=NAK } raise EACBrECFSemResposta.create( ACBrStr( 'Impressora '+fpModeloStr+' não reconheceu o Comando'+ sLineBreak+' (ACK = 21)')) else if not ACKValido(fsACK) then raise EACBrECFSemResposta.create( ACBrStr( 'Erro. Resposta da Impressora '+fpModeloStr+' inválida'+ sLineBreak+' (ACK = '+IntToStr(fsACK)+')')) ; end ; ECF está com os dias contados... em todo o Brasil...

Tem a UF do endereço do emitente. Se tiver alguma NFe adicionada no componente sem essa informação preenchida vai ter esse erro. Como disse no post que citei, isso ocorre geralmente quando por engano você inclui uma segunda nota no componente com uma chamada extra a NotasFiscais.Add preenchendo outro dado qualquer apenas nessa segunda nota. Use o debug e veja quantas notas estão sendo enviadas no momento de chamar o método ACBrNFe.Enviar.

Bom dia. Qual o valor passado a propriedade NossoNumero? Considerado que você te parametrizado o convenio e a carteira desta forma, seria impossível que o nosso número seja setado com 17 posições... Observe a validação feita no SetNossoNumero(), note como a quantidade de caracteres informada no NossoNumero é considerada wNossoNumero:= OnlyNumber(AValue); with ACBrBoleto.Banco do begin wTamNossoNumero:= CalcularTamMaximoNossoNumero(Carteira, wNossoNumero, ACBrBoleto.Cedente.Convenio); if Length(trim(wNossoNumero)) > wTamNossoNumero then raise Exception.Create( ACBrStr('Tamanho Máximo do Nosso Número é: '+ IntToStr(wTamNossoNumero) )); fNossoNumero := PadLeft(wNossoNumero,wTamNossoNumero,'0'); end; Att.

Bom dia! Não estou participando do evento. Caso obtenha novas informações compartilho com vocês.

Bom dia. Você está usando qual IDE? Att.

Estou utilizando o ACBrInstall e esta apresentand o o seguinte erro C:\ACBr\Fontes\ACBrDFe\ACBrNFe\PCNNFe\pcnNFeW.pas(2157) Error: Missing operator or semicolon C:\ACBr\Fontes\ACBrDFe\ACBrNFe\ACBrNFeNotasFiscais.pas(57) Fatal: Could not compile used unit '..\..\..\..\Fontes\ACBrDFe\ACBrNFe\PCNNFe\pcnNFeW.pas' Compilation failure Erro ao compilar o pacote "ACBr_NFe.dpk". Abortando... Ocorreram erros na compilação dos pacotes. Nao consegui identificar esse erro. Agradeço a ajuda desde ja

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

A mensagem parece ser um erro de comunicação da DLL com o SAT... Entre em contato com o suporte do fabricante... Você também.pode testar usar o SATTeste.exe para realizar essa tarefa

Comente tambem qual eh a sua IDE... ? Lazarus ou Delphi ? Att Ricardo

Boa tarde. Enviei o ajuste para o svn, queira por favor testar. Att.

Boa tarde, Vocês conseguiram resolver o problema O Documento XML deve ter um elemento de nivel superior. Line:0 Estou tentando problema mesmo fazendo a recomendação do loop de 5. Caso alguém tenha uma dica, me ajudaria muito. Entrei em contato com suporte e eles responderam. PREZADO(A), INFORMAMOS QUE ATÉ O MOMENTO NÃO TEMOS NENHUMA INSTABILIDADE E NÃO ENCONTRADO NENHUMA ANORMALIDADE EM NOSSOS SERVIDORES. DE ACORDO COM ALGUMAS REDES QUE ESTAMOS EM CONTATO PARA AJUDAR A MONITORAR QUALQUER ESTABILIDADE QUE POSSA VIR, ESTÃO CONSEGUINDO AUTORIZAR AS VENDAS NORMALMENTE. SOLICITAMOS QUE VERIFIQUE OS PROTOCOLO DE COMUNICAÇÃO NO SITE DO PORTAL PARA AUXILIAR NA SOLUÇÃO DO ERRO APRESENTADO. https://farmaciapopular-portal.saude.gov.br/farmaciapopular-portal/login.jsf

Boa tarde Italo, Então .. ainda desconheço o padrão para emissão.. mas parece que temos novidades Esta sendo realizado um Evento hoje em BH explicando e fazendo realização de testes Segue o link http://www.pbh.gov.br/bhissdigital/portal/index.php?content=avisos/index.php&data=20190204anexo

Para dúvidas sobre esse assunto, favor criar um Novo Tópico em: https://www.projetoacbr.com.br/forum/forum/66-mfe-módulo-fiscal-eletrônico/

Me parece que a geração do CNAB400 para esse banco ainda não foi validada. No tópico onde foi anexada a contribuição que foi enviada ao repositório não menciona a implementação do CNAB400, e comparando os códigos fontes está quase idêntico ao CNAB400 do Banco do Brasil. Se você quiser fazer as modificações necessárias de acordo com o manual do banco, basta abrir o arquivo ACBrBancoCredisis.pas e implementar/corrigir os métodos GerarRegistroHeader400 (header), GerarRegistroTransacao400 (detalhe e opcional) e GerarRegistroTrailler400 (trailler). Ou usar CNAB240 para a geração que aparentemente foi validada.

Não me parece o melhor lugar pra essa configuração. Enviei uma correção para o repositório, rev. 16584. Experimente testar novamente com o arquivo do repositório.

Foi alterada no refactoring para ACBrNFeDANFEFR.MostraSetup.

RESOLVIDO! Verifiquei os fontes do método e nele tem o parâmetro aDisposition : TMailAttachmentDisposition. Por padrão ele está setado para "adInline". Pelo que entendi, ele tenta incorporar no Body o conteúdo. Mudei para adAttachment e resolveu o problema. FMail.AddAttachment(ArquivoXML, '', adAttachment);

Ola boa tarde, estou com o mesmo problema, ja alterei o timeout para 30, 60, 120 e o erro se mantem nada mudou, Ja atualizei o windows e nada... Por gentileza, se alguem tiver uma ideia do que seja por favor nos de uma direçao, agradeço desde ja!

Vou relacionar algumas que considero muito importantes. 1. Procure ter no banco de dados todas as informações do documento, pois se o seu cliente vir a perder o XML, será possível gerar e assinar ele novamente com as mesmas informações e por fim executar o método Consultar para obter o protocolo de autorização e com isso deixar o XML completo, ou seja, assinado e protocolado, tornando-o desta forma um documento com validade jurídica. 2. Jamais informe o numero do documento como sendo o código do documento, a titulo de exemplo a NF-e: muitos atribuem o valor de nNF (numero da nota fiscal) a cNF (código da nota fiscal). Essas duas informações fazem parte da chave, logo não faz nenhum sentido serem iguais. Por recomendação da SEFAZ o valor de cNF tem que ser um numero aleatório. Logo devemos gerar esse numero e armazena-lo no banco de dados junto com os demais dados da nota. Outro detalhe importante o tamanho de nNF é de 9 dígitos, já o tamanho de cNF é 8, portanto quando o numero do documento atingir a casa dos 9 dígitos, como você vai passar esse numero para o código que só aceita 8 dígitos? Todo o que foi dito acima referente a NF-e, devemos também levar em consideração aos demais Documentos Fiscais Eletrônicos. No CT-e temos nCT (numero do Conhecimento) e cCT (código do Conhecimento), sendo que este último deve ser um numero aleatório e diferente do nCT. No MDF-e temos nMDF (numero do Manifesto) e cMDF (código do Manifesto), mesma recomendação do CT-e. No BP-e temos nBP (numero do Bilhete) e cBP (código do Bilhete), mesma recomendação do CT-e. 3. Prefira armazenar os XMLs no banco de dados em vez no Disco, isso evita que algum usuário apague sem quer os XMLs. 4. Para quem utiliza o certificado A1, prefira armazenar o seu conteúdo no banco de dados, pois desta forma não se faz necessário instalar o mesmo na maquina.

Bom dia Só para complementar. O uso do FastMM4 não serve apenas para localizar possíveis vazamentos de memória. Na minha opinião o uso do FastMM4 otimiza em muito o gerenciamento de memória que não é muito satisfatório por parte do Delphi. No meu caso, por exemplo, não existia nenhum vazamento de memória, porém o crescimento da memória conforme o uso do aplicativo crescia sem parar. O simples fato de compilar o FastMM4 junto na minha aplicação ( com algumas configurações que não lembro agora) tornaram a otimização de memória muito mais eficaz.

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

Bom dia, cristiam2005. Tópico é antigo e por isso será fechado. Peço para que crie um novo.