Painel de líderes

Versão parece correta, esta utilizando versão Pro.. Esta utilizando o programa exemplo ? O seu certificado esta habilitado tanto para homologação quanto produção ? Olhando o log esta setado = 1 09/11/22 17:46:41:986 - TLibNFeConfig.AjustarValor(tfLer,NFe,Ambiente,1) Para usar ele em produção deve informar 0 https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca16.html

Olá Pessoal, Mais uma notícia "boa" para o início do próximo ano.. E quais são as novidades? Não poderia ser diferente, e claro, são Alterações no Layout e regras de validação da NF-e/NFCe e também alguns novos códigos de rejeição. Quanto aos novos campos Inclusão de campo destinado a informar NF-e referenciada em sigilo Aumento do número de documentos referenciados. Quanto as regras de validação Removidas regras relativas as restrições para emissão de NFe por pessoa física Corrigida validação do CNPJ do Resp. Técnico para ser aplicada somente se existir informação par a tag no XML Alterada para ser a critério da UF a aplicação da regra de validação do Regime Tributário informado bate com cadastro na SEFAZ, inclusive com novos códigos de rejeição Inclusão de regras garantido a consistência da NFe Referenciada Inclusão de restrições quanto a referencia de NFCe Inclusão de restrições relativas as operações permitidas para NFe emitida por não contribuintes do ICMS Inclusão de validação quando o FCP for obrigatoriamente 0 conforme tipo de operação (adoção a critério da UF) Quanto aos Código de Rejeição 951 - Rejeição: Chave de Acesso referenciada com código numérico zerado não permitida para finalidade diferente de normal. 952 - Rejeição: Chave de Acesso referenciada com a mesma Chave Natural da Nota Fiscal atual 953 - Rejeição: Informado ECF referenciado para CFOP 5.929 em UF que não permite essa referência 475 - Rejeição: Operação não permitida para não contribuinte 474 - Rejeição: FCP não deve ser destacado na NF-e conforme legislação estadual Sobre a aplicação na NFe e NFCe Em relação as regras de validação, somente a regra relativa a validação do CNPJ do Responsável Técnico(ZD02-10) e a regra relativa ao Código do Regime Tributário-CRT (7C21-10) se aplicam a ambos os documentos, as demais são exclusivas para NFe. Sobre as regras a critério da UF Este tipo de regra sempre causa dúvidas, afinal tira o padrão nacional daquela informação, nesta NT tivemos a inclusão dos campos que permitirão a informação de documento referenciado, porém sem informar a chave do mesmo, no caso, a tag refNFeSig, que somente poderá ser adotada após as UFs publicarem sua regulamentações internas. Mas para esclarecer a motivação da inclusão desta tag, conversamos com a AFRAC e fomos informados de que se deve ao fato de que em alguns setores acontece venda triangular, e dado a haver a chave do documento recebida pelo cliente, ele acaba tendo informações sobre o valor pago anteriormente pelo seu fornecedor, gerando desconforto entre as partes. Quanto a vigência da NT Ambiente de Homologação: 07/02/2023 Ambiente de Produção: 03/04/2023 Sobre as mudanças nas soluções ACBr Por se tratar de inclusão de novos campos e alteração na quantidade máxima de documentos referenciados, será necessário adequações no Componente, assim como no ACBrMonitorPlus e a ACBrLib, tais alterações serão enviadas ao SVN a tempo da SEFAZ liberar o ambiente de homologação com estas mudanças. Naturalmente que havendo a inclusão de novas informações, também se fará necessário algum grau de adequação da aplicação, conforme o segmento na qual a mesma é utilizada. Até aqui tivemos um breve resumo dos pontos trazidos por esta NT, mas para se aprofundar melhor, recomendamos que continue a leitura até o final do artigo. 1. Alterações do layout Inclusão do Referenciamento de NF-e por Chave com código numérico zerado (Campo: refNFeSig). Criação de campo específico no grupo de Documento Fiscal Referenciado (NFref) para permitir ao contribuinte referenciar Nota Fiscal Eletrônica, modelo 55, informando a Chave da NF-e com o código numérico zerado. Essa alteração visa garantir a manutenção do Sigilo Fiscal da NF-e referenciada. Importante A utilização deste campo fica restrita a situações previstas em legislação específica de cada UF. A referência pela chave de acesso completa (campo: refNFe) continua obrigatória nos casos de NF-e de devolução, complementar e quando a legislação exigir. Cuidados quanto as tags refNFe e refNfeSig Os campos refNFe e refNFeSig não podem constar ao mesmo tempo no XML, ou seja, ou ele contém o campo refNFe ou o campo refNFeSig. Alteração do número máximo de ocorrências do grupo de Documentos Fiscais Referenciados (tag: NFref) O grupo de Documentos Fiscais Referenciados (tag: NFref) passou de um máximo de 500 para 999 ocorrências, para atender situações em que era necessário referenciar mais que 500 documentos numa mesma NF-e. 2. Alterações de Regras de Validação Criação das Regras de Validação garantindo a consistência da Chave Referenciada BA02a-10, BA02a-20, BA02a-30, BA02a-40, BA02a-50, BA02a-60, BA02a-70, BA02a-80, BA02a-90, BA02a-100 Essas regras visam garantir a consistência da Chave Referenciada com código numérico zerado (tag: refNFeSig) além de evitar que esse referenciamento aconteça em uma NF-e com finalidade diferente de normal. Remoção das Regras de Validação quanto a emissão de NF-e por Pessoa Física C02a-04, C02a-08, C02a-14 Atualmente existe um controle das SEFAZ no credenciamento individual para emissão da Nota Fiscal pelos Contribuintes Pessoa Física (CPF). Eliminadas as Regras de Validação que controlam a opção da UF em aceitar ou não a emissão de Nota Fiscal para os Contribuintes emitentes Pessoa Física. Criação da Regra de Validação destinada a rejeitas referenciamento de NFC-e na NF-e I08-186 O objetivo desta regra é impedir o referenciamento de ECF em uma NF-e com CFOP 5929 ou 6929, uma vez que em algumas unidades federadas o ECF já foi completamente substituído por NFC-e e não existe mais a possibilidade de seu referenciamento para estas operações. Alteração das Regras de Validação quanto as operações permitidas para Não Contribuintes do ICMS I08-194 e I08-198 Algumas SEFAZ concedem IE para não Contribuinte do ICMS, mas limitam a emissão de NF-e de venda unicamente pelo Emissor de Nota Fiscal Avulsa disponibilizado pela própria SEFAZ. Alteração da Regra de Validação quanto a forma de informar os valores de FCP N17c-30 Conforme a legislação estadual, algumas SEFAZ controlam a informação dos valores vinculados ao Fundo de Combate à Pobreza (FCP) no processo de apuração do imposto, impedindo essa informação individualizada em cada NF-e. Alteração da Regra de Validação quanto ao CNPJ do Responsável Técnico somente se houver a informação ZD02-10 Melhorada a documentação da RV, efetuando a validação unicamente se a informação do CNPJ do Responsável Técnico for informada. Criação da Regra de Validação para validar a existência na base de dados da UF emitente do documento relativo a chave referenciada 3BA02a-10 Regra de validação para verificar a existência da Chave Referenciada com código numérico zerado na base de dados de NF-e da UF emitente do documento. Alteração da Regra de Validação quanto a informação do Código de Regime Tributário informado no XML 7C21-10 A RV 7C21-10 controla a informação na Nota Fiscal do CRT ou CSOSN, conforme o cadastro do Contribuinte na SEFAZ. Alterada esta Regra de Validação para ser opcional por UF.

Desculpa peço eu pelo bomba que trouxe kkkkkkkk Mas realmente preciso de uma ajuda... Já está terminando a atualização aqui Cara... Pensei nisso também... Li uns tópicos aí sobre a dependência do Fortes Report em relação a impressora default instalada para desenhar os relatórios... Não sei se tinham embasamento técnico, mas fiz o seguinte teste depois que li eles: Eu instalei a impressora virtual CutePDF (https://www.cutepdf.com/Products/CutePDF/writer.asp) e setei ela como padrão... Continuou o mesmo problema... Tem alguma outra sugestão a ser feita nesse sentido? Instalar outra impressora virtual? Segue como esta lá nesse momento:

Bom dia! Na data de 08/11/2022, por volta das 10:00 começamos a receber relatos em nossa comunidade do Discord e em nosso fórum sobre problemas para emitir Nota Fiscal. Todos os relatos tem em comum o fato de que o emitente é um Produtor Rural, a UF ser Minas Gerais e a mensagem de erro ser a mesma. O erro é uma mensagem entranha com a seguinte descrição: Não houveram alterações recentes no ACBr relacionadas e o erro começou a ocorrer repentinamente, por isso, somos levados a acreditar que o problema é de fato na Sefaz. Até o momento não houve relatos de o problema ter sido solucionado. A orientação inicial é de entrar em contato com Sefaz através dos canais de atendimento disponíveis. Atualizaremos este tópico conforme obtivermos novas informações.

e se vc depurar ou dar um showmessage no botão, depois q vc carregar a nfe, ANTES de imprimir... mostrar o conteúdo da propriedade Logo? Veja tbm se não existe um arquivo .INI alimentando seu EXE [Geral] DANFE=0 FormaEmissao=0 Logomarca=

Boa tarde Ok, obrigado pelo retorno att Paulo Casagrande

ok, realmente confundi, pensei q o valor 1 era producao igual a tag tpAmb. Obrigado.

resolvido eram 2 certificados e um venceu ontem nao sei porque o acbr pegou o vencido obrigado

Bom dia, fiz o que falou e deu certo. Estranho que ao consultar o sintegra não informa esse 0 a mais. Mas o importante é que deu certo. Obrigado.

Bom dia amigos, o problema foi Resolvido.. O Erro era no provedor mesmo , entrei em contato com o programador deles e foi realizado vários testes até chegar a conclusão que o erro era lá.. Resolveram e tudo normalizou.. obg

Olhando o log não achei nada que fosse diferente. uma coisa. tu setou isso direto em ACBrTEFD.ArqLog ou ACBrTEFD.TEFCliSitef.ArqLog? consegue fazer um teste usando um dos exemplos do SVN?

Bom dia, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3261

Olá @brajan, Sim, No ambiente de homologação do Itaú, sempre que é criada uma cobrança imediata, ao consultá-la, ela já estará paga. Então talvez não esteja dando tempo nem de pintar o QRCode na tela. Efetuei um teste aqui na minha base e também está ocorrendo o mesmo erro, porém o problema é na resposta do PSP. Veja que a resposta não contém um valor válido: Em ambiente de produção o problema não ocorre! Talvez seja o caso de entrar em contato com o suporte do Itaú e relatar o problema.

Boa tarde, vamos ter que dar uma olhada, caso desejar analisar o caso e anexar uma proposta é sempre bem vindo.

Boa noite, Como o provedor está acusando que o token é inválido, veja se preencheu corretamente a propriedade a seguir... Geral.Emitente.WSChaveAutoriz ...que é utilizada conforme abaixo. ../trunk2/Fontes/ACBrDFe/ACBrNFSeX/Provedores/Bauhaus.Provider.pas

Boa noite, Verifique com a prefeitura qual é o novo provedor. O que está configurado no componente é o SmarAPD, conforme abaixo. Caso tenha mudado, verifique também com a prefeitura/provedor quais são as urls de produção e homologação. Seguem tópicos úteis. 1. Para configurar o novo provedor 2. Em novas oportunidades, para identificar se um município está implementado, qual provedor e versão

Boa noite, Esse segmento é gerado quando uma das propriedades a seguir estiverem preenchidas: Sacado.Email Sacado.SacadoAvalista.CNPJCPF No Títulos.ini envie a opção a seguir em branco ao invés do e-mail de teste que preencheu que deve resolver. Sacado.Email

Após contato, a Sefaz reconheceu que está passando por instabilidade, vide resposta recebida pela membra de nossa comunidade @diovanacargon.

Não sei se existe teoria para isso (se seguir sua busca e encontrar seria interessante saber), mas entendo que a variável neste cenário, antes de ter algo atribuído a ela possui um "lixo de memória" e o Assigned verifica se já foi atribuído algo à variável.

Por favor, você configurou a versão do documento fiscal? No programa exemplo ela fica na aba Geral e a configuração via property é ACBreSocial.Configuracoes.Geral.VersaoDF

Boa noite, Um pequeno complemento ao que o Italo disse. Você usa exatamente as configurações de SSL / TLS para todos os clientes? Se for, revise conforme a seguir e veja se resolve. A1: SSLLib := libOpenSSL SSLCryptLib := cryOpenSSL SSLHttpLib := httpOpenSSL Copie as dlls atuais na pasta do seu exe. trunk2/DLLs/OpenSSL/1.1.1.10/ A3 : Windows atualizado SSLCryplib = cryWinCrypt SSLHttpLib = httpWinHttp SSLLiB = libWinCrypt Para ambos SSLXMLSignLib = xsLibXml2 SSLType = LT_TLSv1_2 Copie as dlls atuais da LibXml2. trunk2/DLLs/LibXml2/ Lembrando, se a sua aplicação for x86, use as dlls x86, mesmo que o S.O. seja 64.

Boa tarde, O problema começou depois que você atualizou a aplicação dos seus clientes ou nem isso ocorreu? Simplesmente de um dia para o outro começou o problema? Se você não atualizou a sua aplicação nos seus clientes e todos eles estão enfrentando o mesmo problema, com certeza é problema no provedor. Como o provedor sempre vai tirar o dele da reta, a minha sugestão é pedir para todos os seus clientes irem até a prefeitura e protocolarem uma reclamação de problemas na emissão nas notas. Você vai ver como resolve rapidinho o problema.