Painel de líderes

Ajustamos os fontes do ACBr, para que eles fiquem compatíveis com o OpenSSL 3.x... Os ajustes já estão no SVN Como essas mudanças são feitas no núcleo de comunicação segura do ACBr, agradecemos a ajuda nos testes, e por favor reportem se notarem algo estranho, mesmo no uso de versões mais antigas, como o OpenSSL 1.1.1 O que é o OpenSSL ? O OpenSSL é uma famosa biblioteca usada para comunicação segura e criptografia... no ACBr, usamos ela para vários de nossos componentes que usam HTTPS, como por exemplo, o ACBrPIXCD... Página do OpenSSL https://www.openssl.org/ Você pode encontrar as DLLs do OpenSSL, em nosso SVN: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/ Porque fizemos essa mudança ? Recentemente o OpenSSL passou por um processo de refatoração, o que gerou a série 3.x... e as versões anteriores, estão sendo descontinuadas, e deixarão de receber correções de segurança e novas melhorias Suporte a protocolos mais Seguros, como TLS 1.3 Em ambientes Linux, o OpenSSL 3.x já é instalado por padrão, e é difícil fazer o downgrade, para a versão 1.1.x O que muda nos meus fontes ? Esperamos que nenhuma modificação seja necessária nos seus fontes. Nossa implementação é compatível com OpenSSL 0.9.x a 3.x, ou seja, os fontes do ACBr, tentam detectar a DLL mais nova do OpenSSL de forma automática.... Geralmente a biblioteca será procurada primeiro, na mesma pasta da Aplicação ou no Path do Sistema Operacional, dando sempre preferência as DLLs das versões mais novas... Ou seja, ele primeiro procurará pela DLL da versão 3.x, e depois da versão 1.1.x, 1.0.x, 0.9.x e assim por diante Como posso saber, qual DLL do OpenSSL o ACBr carregou ? Use as linhas abaixo, para ver a Versão e o Path completo, das DLLs carregadas na memória mResp.Lines.Add('Versão OpenSSL'); mResp.Lines.Add( OpenSSLExt.OpenSSLVersion(0) ); mResp.Lines.Add( ACBrOpenSSLUtils.OpenSSLFullVersion ); mResp.Lines.Add( OpenSSLExt.SSLUtilFile ); mResp.Lines.Add( OpenSSLExt.SSLLibFile ); mResp.Lines.Add('------------------------------'); Como atualizo a DLL para a versão 3.x ? Basta copiar as novas DLLs, para a mesma pasta do seu .exe... Se você compila seu sistema em 32 bits, aqui estão as DLLs: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/3.1.3/x86/ Nota: mesmo que o Windows seja 64 bits, a DLL precisa acompanhar a arquitetura em que seu .EXE é compilado Eu preciso atualizar ? Não necessariamente, mas recomendamos que você use no mínimo a versão 1.1.x, por motivos de segurança Não creio que a atualização, gere mais performance, no uso da biblioteca...

Olá @Italo Giurizzato Junior Adicionei as seguintes validações em ACBrNFeNotasFiscais.pas linha 1051, unit em anexo, se puder avaliar e se tiver de acordo adicionar aos fontes if (NFe.Ide.modelo = 65) then begin GravaLog('Validar: 383-NFCe Item com CSOSN indevido [nItem: '+IntToStr(Prod.nItem)+']'); if Imposto.ICMS.CSOSN in [csosn101, csosn201, csosn202, csosn203] then AdicionaErro('383-Rejeição: NFC-e Item com CSOSN indevido [nItem: '+IntToStr(Prod.nItem)+']'); GravaLog('Validar: 766-NFCe Item com CST indevido [nItem: '+IntToStr(Prod.nItem)+']'); if Imposto.ICMS.CST in [cst10, cst30, cst50, cst51, cst70] then AdicionaErro('766-Rejeição: NFC-e Item com CST indevido [nItem: '+IntToStr(Prod.nItem)+']'); Quando for emitida uma NFC-e com Código de Situação da Operação – Simples Nacional (CSOSN) diferente da lista abaixo, será retornado a rejeição "383 - Item com CSOSN indevido": 102 - Tributada pelo Simples Nacional sem permissão de crédito; 103 - Isenção do ICMS no Simples Nacional para faixa de receita bruta; 300 - Imune; 400 - Não tributada pelo Simples Nacional; 500 - ICMS cobrado anteriormente por substituição tributária (substituído) ou por antecipação; 900 - Outros (a critério da UF); Quando for emitido uma NFC-e e com CST de ICMS diferente da lista abaixo será retornado a rejeição "766 - Rejeição: Item com CST indevido": 00 - Tributada integramente; 20 - Com redução da Base de Cálculo; 40 - Isenta; 41 - Não tributada; 60 - ICMS cobrado anteriormente por substituição tributária; 90 - Outros (a critério da UF). Removi a validação abaixo já que já é contemplada pela validação acima GravaLog('Validar: 766-NFCe CST 50 [nItem: '+IntToStr(Prod.nItem)+']'); if (Imposto.ICMS.CST = cst50) then AdicionaErro('766-Rejeição: NFC-e com CST 50-Suspensão [nItem: '+IntToStr(Prod.nItem)+']'); ACBrNFeNotasFiscais.pas

Boa tarde Alan, Já esta no SVN.

O XML está OK. Fiz a abertura do chamado junto à SEFAZ. Vou aguardar uma posição.

Boa tarde, Essa é uma forma arriscada de operar, pois a sefaz pode considerar o consumo indevido em excesso e bloquear o IP / CNPJ neste serviço, pois todas as vezes que você chamar a rotina vai processar novamente todos os registros disponíveis, dos últimos 90 dias. O correto é identificar quem está utilizando em paralelo e buscar uma forma de trabalhar a menor quantidade de concorrência possível. Ex: Se for a contabilidade, muito provável, instruí-la a criar uma rotina para só executar a noite e durante o dia seu sistema processa normalmente, mas mesmo assim, no começo do dia irá fazer a consulta com NSU 0 para seguir de sua própria sequência. Outra opção é você ou a contabilidade criar uma rotina para importar direto dos xmls de distribuição( veja no programa de exemplo que mostra como importar do XML no próprio botão de distribuição) e quem seguir utilizando o serviço da Sefaz, disponibiliza os xmls para o outro sistema importar..

Por favor atualize seus fontes, pelo SVN do ACBr... Contribuição enviada na Rev-31130 Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

With Produto.Prod.comb.origComb.Add do Begin indImport := iiNacional; //iiImportado cUFOrig := UFToCUF('SP'); pOrig := 0.000; End;

Bom dia, Já esta no SVN.

Olá @Pegasus Aut e Desenv, Não havia sido implementado o cancelamento de cobrança pra esse PSP. A partir do seu comentário, analisei melhor a documentação da API do Mercado Pago e verifiquei que realmente era possível cancelar uma cobrança. Fiz as alterações necessárias e implementei esse endpoint no PSP. Também implementei a consulta de Pagamento(GET /pix). Essas alterações estão disponíveis no SVN, rev: 31121. Muito obrigado por reportar!

Nota Técnica 2016.003 Versão 3.62 A Resolução Gecex nº 529, de 19 de outubro de 2023, alterou a vigência da Resolução anterior Gecex nº 499/2023, modificando, consequentemente, a tabela de NCM divulgada na NT 2016.003 v. 3.60 conforme a seguir: • manteve a inclusão do NCM 30049098 a partir de 01/11/2023 • alterou a data de criação de 3(três) códigos de NCM (19012010, 19012020 e 19012090) para 01/01/2024 • alterou o término da vigência do código NCM 19012000 para 31/12/2023. Ambiente Data de Vigencia Homologação até 01/11/2023 Produção 01/11/2023 ou 01/01/2024* conforme código de NCM Essa NT pode ser encontrada na íntegra AQUI.

Olá Pessoal, O nosso amigo @gabriel.hilbig, descobriu como resolver o erro E0536. Vamos a dica dele: Fazendo o DPS direto no PORTAL preenchimento automático <regApTribSN>1</regApTribSN> //-> 1 – Regime de apuração dos tributos federais e municipal pelo SN; Fazendo pelo Aplicativo , usando REST API é necessário preencher <regApTribSN>2</regApTribSN> //->2 – Regime de apuração dos tributos federais pelo SN e ISSQN por fora do SN conforme respectiva legislação municipal do tributo; Solução para PORTO ALEGRE , não sei outras cidades A mensagem de erro não ajuda nada para resolver o problema Não existe nenhuma documentação a respeito nem Federal e nem municipal O desenvolvedor precisa resolver na TENTATIVA E ERRO Esta solução acaba por criar um imposto pendente. Sugiro a todos os prestadores de serviços e desenvolvedores que protocolem na prefeitura uma reclamação sobre o problema. Não sei se é questão de configuração errada no ambiente de produção, pois tenho relatos que em ambiente de homologação (Produção Restrita com a RFB o chama) esta funcionando ou se o problema é na API desenvolvida pelo SERPRO. Quanto mais pessoas protocolarem o problema as chances de resolver mais rápido aumenta, pois a prefeitura talvez nem saiba que isso esta ocorrendo.

Boa tarde, hj recebemos erro ao emitir NFCe para venda de Gás (SIMPLES NACIONAL) usamos : CST 500 e aparece o erro: Erro na emissão de NF-e para combustível (NF-e não pode ter preenchimento de Grupo de Tributação do ICMS monofásica sobre combustíveis.) Corrigimos isso colocando CST 61, mesmo sendo simples nacional. O sistema validou certinho e preencheu com 0,00 os campos: adRemICMSRet = 0,00 vICMSMonoRet = 0,00 OBS: Atualizar o ACBR e também pegar os SCHEMAS na própria pasta do ACBR.

Fabiano, O problema é que o provedor esta retornando o XML no formato ANSI em vez de UTF-8.

Bom dia, Estou tentando emitir uma NF-e de Combustível passando o codigo ANP 620505001. Esse código não consta na tabela de Combustíveis Sujeitos a Tributação Monofásica que esta disponível no Portal da NF-e. Porém está ocorrendo o erro abaixo. Rejeição 959 Rejeição: NF-e não pode ter preenchimento de Grupo de Tributação do ICMS monofásica sobre combustíveis. De acordo com a NT 2023.001, pelo que entendi, se o codigo de ANP não estiver na tabela informada pelo Portal, é proibido o preenchimento do CST. Eu não estou informando o CST, e sim o CSOSN 500 - <comb> <cProdANP>620505001</cProdANP> <descANP>OUTROS OLEOS LUBRIFICANTES AUTOMOTIVOS</descANP> <UFCons>SP</UFCons> </comb> </prod> - <imposto> <vTotTrib>16.15</vTotTrib> - <ICMS> - <ICMSSN500> <orig>0</orig> <CSOSN>500</CSOSN> <vBCSTRet>0.00</vBCSTRet> <pST>0.0000</pST> <vICMSSubstituto>0.00</vICMSSubstituto> <vICMSSTRet>0.00</vICMSSTRet> </ICMSSN500> </ICMS> Se puderem me dar uma luz aqui pra poder resolver essa questão, eu agradeço. Obrigado.

@Alexandre de Paula Acabei esquecendo de colocar Produção => https://ws.nfe-cidades.com.br/ws/amparo Homologação => https://ws.homolog.nfe-cidades.com.br/ws/amparo Padrão Asbraf 2.01

A exibição do QRcode depende se a informação dele está presente no XML retornado pelo provedor/prefeitura. Provavelmente no caso dessa prefeitura a informação não vem no XML da NFSe.

Abri o exemplo em C# para NFe, coloquei um break-point na linha que indicou. Cliquei no botão Distribuição DFe por Ultimo NSU e a execução não parou no break-point. No entanto, se eu fecho o programa exemplo que é o momento em que ele executa o ACBrNFe.Dispose(); Ele cai no break-point e o call stack fica assim:

Lembrando: CSOSN 500 dá erro Tem que trocar para 61 No acbr preencher: Imposto.ICMS.CST = cst61 MESMO QUE SEJA SIMPLES NACIONAL

Obrigado Italo! Vou fazer os devidos testes e qualquer problema reporto aqui.

Boa tarde. A TK foi alocado no sprint desta semana e já está em avaliação por parte dos consultores. Assim que descobrimos algo, reportamos aqui.

Eu com certeza não chamei pois eu instancio o AcbrLib no início do módulo e fico num looping infinito chamando este método e tratando o retorno Mas confirmei. Fiz uma busca nos fontes (2 na vdd) e não existe chamada à este método. Mas tem como reinicializar o AcbrLib sem instanciar novamente ou tem que instanciar? Já descobri o problema. Estou passando o AcbrLib por parâmetro para uma classe e esta classe tem 2 construtores. Um deles sem paramêtros.

Bom dia Patrick Já esta no SVN.

Bom dia! Por favor, disponibilize o NFe.ini que foi utilizado nesta última tentativa, o XML gerado e o Log do Monitor. Se julgar que contenham informações sensíveis e não possam ser disponibilizados direto aqui, envie para [email protected] com o link do tópico do fórum no corpo do e-mail para posterior identificação.

Bom dia a todos, não sei se aqui é o lugar correto. Mas vamos lá. Configurei o ACBRPIX para o Mercado Pago, funcionou 100%, muito simples por sinal, dentre os que configurei, claramente foi o mais simples. O problema está no cancelamento do PIX, caso o lojista deseje cancelar o PIX por qualquer motivo, desistência do consumidor ou outra coisa, utilizo o método : CobRevisada.status := stcREMOVIDA_PELO_USUARIO_RECEBEDOR ao revisar a cobrança RevisarCobrancaImediata(OrderID) Tenho a seguinte mensagem de erro: TransmitirHttp(AMethod, AURL, ResultCode, RespostaHttp); Exception message : Expected "{" but found invalid symbol (1, 2) aMethod = PATCH aURL = https://api.mercadopago.com/v1/payments/65939763923 resultCode = 405 RespostaHTTP = <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">'#$D#$A'<html> <head><title>405 Method Not Allowed</title></head> <body bgcolor="white"> <h1>405 Method Not Allowed</h1> <p>The requested method is not allowed for the URL.</body> </html> Pela documentação do Mercado Pago, eles utilizam PUT em vez de PATCH, seria esse o problema? curl -X PUT \ 'https://api.mercadopago.com/v1/payments/{payment_id}' \ -H 'Authorization: Bearer YOUR_ACCESS_TOKEN' \ -H 'Content-Type: application/json' \ -d '{ "status": "cancelled" }'

Bom dia, Uma opção é criar uma function seguindo a ideia da procedure "TArquivoR_CNAB240.GerarAvisos", onde passaria ocorrência, Segmento e SeuNumero, aí é só varrer a lista de avisos e retornar a descrição.

Bom dia Diogo, Existem provedores que requerem um cadastro para emitir as notas via site e um outro cadastro para emitir via webservice. Pode sim ser este o seu problema, falta cadastrar para emitir via webservice.

Veja essa resposta, do @Victor H. Gonzales - Panda, sugerindo outros WebServices, não oficiais...

@Jamil Araujo Obrigado por reportar Criado a TK-4656-1 para análise do time.

Bom dia, Criada a TK-4678 para avaliação. Obrigado pela contribuição.

Boa noite Diego e Italo, Funcionou. Detalhe: na configuração iniServicos estava apenas o path, mudei para o caminho completo e funcionou. Obrigado a todos.

Boa tarde Bruno, Já esta no SVN.

Respondido no Discord. Em um resumo, tudo indica ser um problema do lado da API do Padrão Nacional. Neste tópico: É sugerido orientar aos seus clientes que protocolem uma reclamação na prefeitura. Pois quanto mais pessoas alertarem que está com erro, mais rápido a prefeitura se dá conta do problema e toma alguma providência.

Aqueles que relataram estarem recebendo consumo indevido reportaram normalização.

Bom dia Valdir, Feita a alteração, veja o que mais eu acrescentei.

Olá a todos os membros da comunidade ACBr! Estamos empolgados em anunciar o lançamento de uma atualização incrível para o nosso componente ACBrPIXCD. Agora o componente suporta o mais PSP (Provedor de Serviços de Pagamento) Mercado Pago, trazendo ainda mais opções e flexibilidade para suas operações de pagamento eletrônico. Gostaríamos de agradecer ao usuário @RicardoCassioDev que deu o "ponta pé" inicial no desenvolvimento dessa integração e contribuiu seus fontes com a gente. Muito obrigado Ricardo, toda a comunidade só tem a ganhar com a ajuda de mais pessoas. Nosso demo do ACBrPIXCD já foi atualizado tanto para a IDE Delphi quanto para Lazarus e já está 100% funcional com o novo PSP. É importante destacar um detalhe sobre o Mercado Pago: Eles NÃO POSSUEM ambiente de homologação, porém é possível sim efetuar testes. Basta utilizar o próprio ambiente de produção com credenciais de teste, que pode ser gerada no portal de desenvolvedores. Criamos um passo-a-passo para a geração dessas credenciais no link a seguir:

Foi publicada a versão 23.2.E das tabelas de fornecidas pelo IBPT, as quais já se encontram também em nosso svn. As novas tabelas tem a vigência de 20/10/2023 até 30/11/2023 Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Sim, exatamente essa foi a intenção do post, informar para que a questão seja analisada e, se for o caso, aplicada a correção. Obrigado!

Bom dia @Valdir Dill A versão 3.0 foi recém disponibilizada e é muito importante que a comunidade utilize e reporte os problemas para podermos corrigir. Obrigado pela informação e assim que tivermos uma atualização a esse respeito informamos aqui. Criamos a TK-4659 para avaliar o caso. O procedimento no momento é exatamente o que você realizou, operar com a versão 1.1 até termos uma atualização. Obrigado mais uma vez.

Bom dia pessoal! Foi publicado no Diário Oficial da União no dia 09/10/2023 o Ajuste SINIEF Nº20 com o cuja redação é: Na prática a nova redação adiciona a possibilidade de substituir o impresso por consulta online em portal disponibilizado pela unidade federativa desde que atenda as condições impostas. Reforçando que se o consumidor optar pela não impressão, a empresa envia o cupom por meio eletrônico. As alterações se aplicam somente ao modo normal, em contingência continua a impressão em duas vias conforme orientação sobre contingência.

Bom dia pessoal! Consta no site da Sefaz do AM notícia informando que a partir das 00h01 do dia 02/11/2023 os serviços de TI da Sefaz do Amazonas passarão por uma parada programada. Para minimizar os impactos, os serviços de emissão de NF-e e NFC-e continuarão operando até ás 16h00, quando terão seu funcionamento interrompido com uma previsão inicial de indisponibilidade por 2 horas. Durante este período as emissões deverão ser feitas em contingência. Leia a notícia na íntegra AQUI. Para usar o ACBr em contingência durante este período siga as orientações deste tópico.

Bom dia pessoal! Como pode ser observado no tópico abaixo, o estado de Goiás prorrogou por bastante tempo a obrigatoriedade de informar o cBenef na NF-e. No entanto, recebemos relato de um membro em nossa comunidade do Discord de que ao enviar NF-e sem o cBenef o mesmo estava recebendo a rejeição Buscando mais informações sobre a questão, encontramos no site da Secretaria da Fazenda do Estado, notícia publicada no dia 17/10/2023 com o seguinte aviso.

Bom dia, Mais uma publicação relacionada ao REInf, nosso amigo @Sófolha que nos avisou, obrigado. Foi adiada para janeiro de 2024 (com data a ser definida) a revisão do conjunto de TLS aceito pelo Reinf. Estava programada para 21/10/2023 o encerramento do aceite nas versões de TLS 1 e 1.1, portanto estas devem continuar funcionando por mais um tempo. Veja a informação na íntegra nesse link > http://sped.rfb.gov.br/pagina/show/7281 Novamente é importante lembrar que não é necessária nenhuma alteração nos fontes do ACBr referente a este assunto e que sempre é importante manter os seus fontes atualizados.

Boa Tarde, Segue uma pequena correção baseado no manual. procedure TACBrBancoC6.LerRetorno400(ARetorno: TStringList); Obg Jaisson ACBrBancoC6.pas

Verificando o portal nacional novamente a contingencia atual de MG foi encerrada, porém já temos um novo agendamento para amanhã: Obrigado @Joao Cardoso por nos avisar no servidor do Discord.

Buenas, Para quem quiser se aventurar no node.js, montei um ambiente de testes com os passos a seguir e funcionou corretamente com o ACBrLibCep, utilizando o demo dos fontes 1. Instalações seguindo o video a seguir: 1.1. Instalar o node: https://nodejs.org/en/download/ 1.2. Se não tiver o VSCode, instalar: https://code.visualstudio.com/download * Achei interessante usar o VSCode, conforme indicado no vídeo, pois e debug funcionou perfeitamente 2. Pacotes * Não instalar pelo terminal do VSCode, para mim apresentou erros, pelo prompt ou powershell funcionou corretamente 2.1. Para funcionar o ACBrLibCep, com o demo que consta nos fontes, instalar os pacotes a seguir npm install --save ffi npm install --save ffi-napi

Olá pessoal! No dia 29/09/2023, foi publica a versão 3.61 desta NT. A nova versão apenas trás uma correção nas datas do texto explicativo da própria NT, alterando de: Para:

Boa tarde, pessoal! Foi publicado no dia 27/09/2023, a versão 1.40 desta Nota Técnica. Esta nova versão altera a regra de validação N12-70, adicionando na exceção 8, a CST 02, permitindo agora que a critério da UF, a regra não seja aplicada quando CST=10, CST=02 e idDest=1. A nova versão também remove das regras LA17-20, LA18-10 e LA18-20 a validação que verifica as datas nas chaves referenciadas, fazendo com que não valide mais AnoMes da ChaveReferenciada para decidir se aplica ou não a regra. Sobre as datas Ambiente de Homologação: 16/10/2023 Ambiente de Produção: 30/10/2023 Regra N43a-10 em Produção: 01/04/2024 Sobre o ACBr Não serão necessárias alterações nos fontes do ACBr, visto que a nova versão apenas altera regras de validação. A NT na íntegra pode ser encontrada aqui. Um agradecimento ao membro @Felipe Mariano, por chamar atenção ao fato no canal #sefaz em nossa comunidade do Discord.

Pessoal fiz assim agora, igual lí em algumas mensagens aqui no forum //o jeito que era no 3.0 { sStat := IntToStr(CTe.WebServices.Retorno.cStat); sMotivo := CTe.WebServices.Retorno.xMotivo; sRecibo := CTe.WebServices.Retorno.Recibo; sProtocolo := CTe.WebServices.Retorno.Protocolo; sChaveCTE := CTE.WebServices.Retorno.ChaveCte; } // como estou fazendo agora no 4.0 e funciona sProtocolo := CTe.Conhecimentos.Items[0].CTe.procCTe.nProt; sStat := IntToStr(CTe.Conhecimentos.Items[0].CTe.procCTe.cStat); sMotivo := CTe.Conhecimentos.Items[0].CTe.procCTe.xMotivo; sChaveCTE := CTe.Conhecimentos.Items[0].CTe.procCTe.chCTe; sRecibo := ' '; // Detalhe que parece-me que a informação do Recibo não existe mais, pois nao encontrei esta propriedade, por favor me confirmem isso. Analisando bem, creio que o protocolo já é uma prova de recebimento, e pode muito bem substituir o recibo. Os especialistas por favor verifiquem se estou correto. Obrigado a todos do grupo.

Bom dia, saberiam informar se a Inclusão do Grupo indicador da origem do combustível (tag: origComb) e Inclusão do Grupo indicador da origem do combustível (tag: origComb) se aplica a NFC-e ou é somente para distribuidoras? at.te Edson.