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.

MG gera somente o CSCid 000001 com o mesmo CSC para homologação e produção. Este erro mencionado ocorreu nos contribuintes que fizeram o cadastro através do Fale Conosco na mesma semana que liberaram o acesso ao Siare. Não sei informar o motivo, mas estes contribuintes não conseguem gerar nada em homologação. O que pode tentar (em 1 cliente meu funcionou) é entrar no Siare e gerar novamente o CSC. Como se fosse iniciar o processo. Primeiro gera em homologação e após 2 horas gera produção. Note que o CSC será o mesmo anterior, nada muda, acho que somente grava no servidor de homologação da Sefaz. Charles

Boa tarde! Certifique-se que está com o ACBr atualizado e siga as instruções do tópico abaixo.

Acabei de passar por esse problema, o instalador não preencheu o path library para 64 bits, tive que adicionar manualmente. Tools -> Options -> Language -> Delphi Options -> Library -> Selected Platform -> Windows 64-bit

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.

Olá pessoal, Com a NT 2018.005 foi introduzida uma nova rejeição para NFe: 938 - Rejeição: Não informada vBCSTRet, pST, vICMSSubstituto e vICMSSTRet. Os detalhes dessa rejeição foram alterados nas várias versões da NT, mas infelizmente isso já está causando algum problema (como podem ver nesse tópico aqui). Como é uma rejeição facultativa e cada UF tem uma legislação, tivemos que adicionar uma nova propriedade no componente ACBrNFe para lidar com a situação. A nova propriedade se chama ForcarGerarTagRejeicao938. Após atualizar os componentes, não esqueça de reinstalar. Vamos a uma explicação mais longa... O problema Como a descrição da rejeição explica, algumas UFs podem exigir a informação de algumas tags, como vICMSSubsituto, isso mesmo quando o valor da tag for zero. Por padrão o ACBrNFe não gera tags facultativas que são informadas com valor zero. E esse é o caso da tag vICMSSubstituto. Mas como essa é uma tag facultativa, não devia ser obrigatório para algumas UFs informá-la. E por isso, não podemos obrigar o ACBrNFe informar sempre. Assim a ideia é termos uma configuração que você possa alterar. Poderemos com essa propriedade forçar gerar a tag de acordo com a necessidade de seu cliente ou da UF dele. A solução A propriedade (ou configuração) criada ForcarGerarTagRejeicao938 foi adicionada no ACBrNFe de modo que pode ser acessada como no código abaixo: ACBrNFe1.Configuracoes.Geral.ForcarGerarTagRejeicao938:= fgtNunca; Ou talvez no Object Inspector como abaixo: Importante: Embora a propriedade esteja disponível para ser alterada no Object Inspector, você provavelmente vai querer parametrizar isso no seu aplicativo. Afinal, talvez você precise alterar essa propriedade de um cliente para outro, ou de uma data para outra. As opções são: fgtNunca -> Se o valor for zero, não vai forçar a geração da tag nunca; fgtSomenteProducao -> Força a tag ser gerada no ambiente de produção mesmo que o valor seja zero; fgtSomenteHomologacao -> Força a tag ser gerada no ambiente de homologação mesmo que o valor seja zero; fgtSempre -> mesmo que o valor seja zero, a tag será gerada sempre; A configuração padrão é fgtNunca conforme o comportamento do componente antes dessas alterações. Qual opção eu devo escolher? Como explicado, essa configuração foi necessária por causa de problemas em certas UFs. Então para escolher a melhor opção você precisa saber o que está sendo exigido no Webservice que você está acessando. Por exemplo, se você não está recebendo a rejeição, não há necessidade de alterar a configuração. Mas se está recebendo somente em homologação, quer dizer, a tag está sendo exigida somente em homologação, use a opção fgtSomenteHomologacao. E assim por diante.

Fantástico! Muito obrigado!

Ítalo, muito obrigado. Funcionou corretamente. Segue anexo a unit pcesS2299.pas corrigida. pcesS2299.pas

Muito Obrigado... já no SVN... rev: 16983

Obrigado deu certo. Troquei o provedor e a conexão de internet e funcionou.

Para conhecer mais o ACBrMonitor sugiro também o Video abaixo, acompanha o modelo do arquivo para NFe e o link do Manual:

E ae galera do "mau/mal" hehe... Liguei as 07h da manhã pra Receita do PR e informaram que os Schemas seriam atualizados nos servidores da SEFAZ somente depois das 10h e que todas as notas em contingência com a tag infresptecnico seriam aceitas, disseram que sempre fizeram isso, nunca fazem nada na virada do dia. Já passamos das 10h e o problema persiste, liguei lá novamente e informaram as 12h agora. Não reatualizei nenhum cliente meu, todos estão emitindo em contingência. Com relação ao ST não tenho nenhum relato ainda pra mencionar, só do infresptec.

Bom dia. Veja as orientações deste tópico para solucionar seu problema. https://www.projetoacbr.com.br/forum/topic/50787-nt-2018005-nfe-938-rejeição-não-informada-vbcstret-pst-vicmssubstituto-e-vicmsstret/ Att.

Bom dia. Verifique a parametrização criada recentemente no componente conforme o tópico a seguir, infelizmente estas tags ficaram uma confusão..recomendo testar e ver a forma que é aceito pela UF. A prorrogação foi somente para o grupo Responsável Técnico. Att.

Pessoal, consegui resolver, vou postar aqui o que era caso aconteça com alguém. Eu havia feito uma alteração no fonte do arquivo ACBrNFeDANFEFRDM.pas, e por esse motivo mesmo um SVN Update no Tortoise o ACBr não podei ser instalado pois o arquivo estava alterado, o que fiz para resolver foi ir na pasta do ACBr e dar um Revert no Tortoise e depois fazer o Update, como isso foi tudo normal.

Olá pessoal, A solução para este processo acabou sendo em outra plataforma e linguagem, devido a política de assinatura para API Serpro seguir o padrão CAdES. Já estou com o assinador implementado. Conhecer o projeto ACBR irá me auxiliar em futuros projetos aqui na empresa. Obrigado pela contribuição de todos. Por favor, pode encerrar o tópico.

Boa tarde. Os layouts estão na página da SEFAZ. Att.

Seguindo a dica Francisco Vieira modifiquei meu código para utilizar xsMsXML conforme abaixo e tudo voltou a funcionar corretamente. SSLXmlSignLib := xsMsXml; Francisco e Dercide, obrigado pela ajuda.

Obtive a resposta da receita sobre o cancelamento por substituição. A equipe da STI informou que esse evento ainda não está implementado em nosso sistema. Está previsto para ser implementado até dia 15 de maio.

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

É o ultimo campo do grupo [ICMS]: Acredito que esteja se referindo ao Layout TXT utilizado no Emissor Gratuito, esse layout realmente não esta atualizado com ultimas NTs. A SEFAZ não deu continuidade na atualização deste layout, sabe dizer se tem algum padrão deste layout para adição destes novos campos?

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

Certo, muito obrigado Italo, era isso mesmo.

pessoal deu certo colocando forcartag938 = sempre e as tags vICMSSubstituto, vICMSSret, vBCSTRet = zero obrigado, por equanto

Boa tarde Murilo, Tente passar o valor da alíquota dividida por 100, ou seja, em vez de 5 informar 0.05

Boa tarde Roberto, Muito obrigado pela colaboração, já enviei para o repositório.

na homologacao em SP funcionou normal , mas em producao em SP ainda nao funcionou, atualizei ACBR , atualizei schemas, coloquei para gerar sempre as tags , entao na homologacao passou beleza autorizando e tudo.... mas em producao, retorna da sefaz o erro de schema se peco para nao gerar a tag dai da a rejeicao 938, assim nao da.... alguem ja conseguiu manda em producao em SP?

Acho que você não pode simplesmente atribuir ao NodeValue (que é um OleVariant) uma string que é na verdade um arquivo binário. É provável que vão existir caracteres de controle não compatíveis e resultará em um xml malformado. Talvez por isso seja necessário converter para base64. Visto que está usando Delphi 7 espero que esse link te ajude: https://stackoverflow.com/q/32306960/460775

Atualizei os schemas e rodou ! Obrigado pelo apoio

Correto...Ou você pode assinar o SAC e contribuir com o projeto pelo menos uma vez...Assim você terá um vasto conteúdo e todas as atualizações disponíveis. Lembrando que não terá cobranças futuras. https://www.projetoacbr.com.br/forum/suporte-especializado-no-acbr/

Os schemas não atualizei mesmo, vou fazer e retorno. Mas é a mesma mensagem de erro

Boa tarde, Felipe Carmo da Paixao. Você realizou o cadastro tanto em homologação e produção. Lembrando que é gerado um CSC e IdCSC para homologação e outro para produção.

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

Bom dia Élviro, A unit pcnRetConsStatServBPe não tem nada haver com o CT-e, veja que ela se refere ao retorno da consulta ao status de serviço do BPe. Essa unit não existe mais, pois essa unit foi substituída pela pcnRetConsStatServ que se encontra na pasta: ...\Fontes\PCNComum Quanto ao erro apresentado na imagem, me diga uma coisa, você esta emitindo um CT-e Normal ou de Complemento de Valores? Veja que esta aparecendo na mensagem de erro de validação: <infCteComp> esse grupo possui uma tag chamada chCTe que deve conter a chave do CT-e a ser complementado. Se não se trata de um CT-e de Complemento de Valores o valor correto a ser informado em tpCTe é tcNormal.

Bom dia. Essa propriedade foi criada não tem muito tempo...verifique se não existem conflitos nos seus fontes ou se não estão sendo usados arquivos antigos. Att.

No link abaixo eles explicam onde vc pega o vICMSSubstituto https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360022725593

Blz, meu cliente esta pra adquirir uma, qualquer duvida posto aqui novamente, muito obrigado.

A recomendação do manual é que quando há tentativa de transmissão no modo normal e há erro de comunicação de qualquer tipo, você deve emitir outra NFCe, com nova numeração, em contingência off-line, e marcar a primeira para cancelamento ou inutilização. Quando a conexão retornar, transmitir a NFCe emitida em contingência, e consultar a primeira, se autorizada fazer o cancelamento, se não existir a NFCe, fazer a inutilização da numeração. O manual não menciona o cancelamento por substituição que ainda não existia, mas esse deve ser necessário já que tem prazo de cancelamento de 168 horas enquanto o cancelamento normal foi reduzido para 30 minutos.

Porém, tenho receio quanto a não ser permitido postar desta forma, se for o caso, solicito remoção do tópico. ACBR_DEMO - 02.05.2019.rar

Carlos C. Murakami, obrigado por responder! Não resolvi ainda não, persiste o problema. Vou verificar esta opção que você mencionou, grato! Manoel Zancheta

Bom dia, Foi aceito dessa forma sim. Já geramos várias notas com essa alteração

Acho que ela usa o mesmo protocolo da Filizola

Bom dia. Nova atualização de contingência em SP no portal NFe: http://www.nfe.fazenda.gov.br/portal/principal.aspx

Meu caso o a aplicação de vez por outra na barra de tarefas fica vermelho.

Boa tarde. Sim amigo são dos emitentes! Onde você tiver cliente, (emitente) será necessário a implementação de tal tag. Veja o mapa https://www.projetoacbr.com.br/acbr-mapas-fiscais/#acbrmapa_responsavel_tecnico

resolvido era o unit dbutil

Bom primeiramente não achei um tópico melhor onde minha dúvida se enquadra. Segundo, o tópico que achei sobre ao assunto é de 2012 e foi fechado. O que me dizem, ou sabem sobre o desenvolvimento de um software que permita o usuário não emitir a nota na hora da venda, deixando esta em aberto como se fosse uma pré venda? Sabemos de situações onde é necessário uma pré venda onde debite de estoque as mercadorias ou outra situação que o usuario queira deixar para emitir a nota posteriormente. Pesquisei diversos softwares, alguns deles de grandes empresas de nome até internacional e todos eles permitem gerar a NFCE somente se o usuário assim o querer. Uns tem até um módulo chamado venda simples onde pode-se fazer vendas com desconto de estoque e etc sem emitir a nfce. Ao interrogar o suporte deste software me disseram que o usuário tem o direito de emitir sua nota depois e o sistema assim também serve para MEI´s de alguns estados que não precisam emitir a NFCE. Liguei também para um advogado especialista em direito digita e o mesmo me disse que a culpa nunca é da softhouse, caso o usuário tenha a opção de enviar esta nota depois (não em contingência). Enfim, o que de concreto se sabe ou alguns casos sobre a softhouse ter que engessar seu software ao envio da NFCE?

Boa tarde, Muito obrigado pela postagem. Já se encontra disponível no repositório tanto a atualização dos schemas bem como do componente que visa atender a Nota Técnica em questão. Favor atualizar todos os fontes de todas as pastas. Reinstalar a suíte ACBr usando o ACBrInstall_Trunk2 deixando marcado a opção para apagar os arquivos antigos.

Sempre acreditei que a informação deve ser algo democrático e acessível... Pensando nisso, tornei pública a nossa área de Base de Conhecimentos Nela você encontrará excelentes artigos, escritos pelos nossos experientes Consultores, e que tornarão o uso dos os componentes ACBr algo mais simples e funcional... Espero que gostem... e fiquem a vontade para sugerir novos artigos...

Bom dia colegas, Eu estou desenvolvendo um sistema para emissão de NFe para um cliente,(usando o ACBR Monitor Plus) porém tenho medo deste cliente tentar achar brechas no sistema para sonegar impostos. Posso ser responsabilizado judicialmente caso o usuário faça mal uso do sistema que estou desenvolvendo??