Painel de líderes

Olá Pessoal, Foi publicado hoje (12/04/2024) a NT 2024/001 que trata sobre o CRT para quem é MEI (Micro Empreendedor Individual) e o fim da Denegação. Alterações relacionadas ao MEI 1. O campo CRT do grupo Emitente agora vai poder conter o valor 4 que indica que se trata de um MEi. 2. Abaixo temos uma lista de CFOP que o MEI (CRT=4) deverá utilizar nas operações internas e interestaduais: • 1.202 - Devolução de venda de mercadoria adquirida ou recebida de terceiros, ou qualquer devolução de mercadoria efetuada pelo MEI com exceção das classificadas nos códigos 1.503, 1.504, 1.505 e 1.506. • 5.102 - Venda de mercadoria adquirida ou recebida de terceiros, ou qualquer venda de mercadoria efetuada pelo MEI com exceção das saídas classificadas nos códigos 5.501, 5.502, 5.504 e 5.505. • 1.904 - Retorno de remessa para venda fora do estabelecimento, ou qualquer entrada e retorno de remessa efetuada pelo MEI com exceção dos classificados nos códigos 1.202, 1.503, 1.504, 1.505 e 1.506. • 2.202 - Devolução de venda de mercadoria adquirida ou recebida de terceiros, ou qualquer devolução de mercadoria efetuada pelo MEI com exceção das classificadas nos códigos 2.503, 2.504, 2.505 e 2.506. • 2.904 - Retorno de remessa para venda fora do estabelecimento, ou qualquer entrada e retorno de remessa efetuada pelo MEI com exceção dos classificados nos códigos 2.202, 2.503, 2.504, 2.505 e 2.506. • 5.102 - Venda de mercadoria adquirida ou recebida de terceiros, ou qualquer venda de mercadoria efetuada pelo MEI com exceção das saídas classificadas nos códigos 5.501, 5.502, 5.504 e 5.505. • 5.202 - Devolução de compra para comercialização, ou qualquer devolução de mercadorias efetuada pelo MEI com exceção das classificadas no código 5.503. • 5.904 - Remessa para venda fora do estabelecimento, ou qualquer remessa efetuada pelo MEI com exceção das classificadas nos códigos 5.502 e 5.505. • 6.102 - Venda de mercadoria adquirida ou recebida de terceiros, ou qualquer venda de mercadoria efetuada pelo MEI com exceção das saídas classificadas nos códigos 6.501, 6.502, 6.504 e 6.505. • 6.202 - Devolução de compra para comercialização, ou qualquer devolução de mercadoria efetuada pelo MEI com exceção das classificadas no código 6.503. • 6.904 - Remessa para venda fora do estabelecimento, ou qualquer remessa efetuada pelo MEI com exceção das classificadas nos códigos 6.502 e 6.505. Quando se tratar de operações de comércio exterior, ativo imobilizado e ISSQN, o MEI que informar CRT=4 poderá utilizar os seguintes CFOP: 1501, 1503, 1504, 1505, 1506, 1553, 2501, 2503, 2504, 2505, 2506, 2553, 5501, 5502, 5504, 5505, 5551, 5933, 6501, 6502, 6504, 6505, 6551 e 6933. Sobre o Fim da Denegação 3. Nessa mesma NT trata sobre a eliminação do processo de denegação na NF-e (modelo 55) que vai passar a ser apenas um processo de rejeição conforme ajuste SINIEF 43/2023. Antes quando o Emitente possuía alguma situação irregular perante ao Fisco a nota era Denegada, agora ela vai passar a ser rejeitada através da Rejeição 781 com a seguinte mensagem: Emissor não habilitado para emissão da NF-e/NFC-e. Mudanças nas Regras de Validação 4. Por fim a NT também traz as alterações e exclusões de algumas Regras de Validação: Alteração nas Regras de Validação I03-30 e I12-60 Alteradas as regras I03-30 e I12-60 para tornar o GTIN e o GTIN da unidade tributável facultativos quando o CRT for igual a “4=Simples Nacional – Microempreendedor Individual – MEI”. Alteração na Regra de Validação I05-10 Alterada a regra I05-10 para não exigir o NCM completo para CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI” em operações internas. Portanto, quando o emitente da NF-e for MEI e a operação for interna poderá informar NCM 00000000. Porém, em operações interestaduais e de comércio exterior é necessário informar o NCM correto e completo. Alteração das Regras de Validação N12-20 e N12a-10 Alterada as regras N12-20 e N12a-10 para exigir o preenchimento correto do CSOSN quando CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI”, e não permitir CST para este CRT. Alteração da Regra de Validação NA01-20 Alterada a regra NA01-20 para não exigir o grupo de ICMS para a UF de destino quando CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI”. Alteração da Regra de Validação 7C21-10 Alterada a regra 7C21-10 para verificar se CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI” é realmente utilizado por contribuinte enquadrado como MEI. Alteração das Regras de Validação N12a-40, N12a-44, N12-40 e N12-44 Alteradas as regras para incluir o CFOP - Inclusão de utilização na NFC-e do CFOP 5910 - Remessa em bonificação, doação ou brinde, na NFC-e para tratamento de cortesias. Regras de Validação 1C17-38 Alterada a RV 1C17-38 que amplia a rejeição por não autorização de emissão ou irregularidade fiscal do emitente também para o modelo 55, visto que a denegação também deixa de existir para a NF-e. Regras de Validação 5E17-40 e 5E17-60 Alteradas as RV 5E17-40 e 5E17-60, transformando as respectivas denegações em rejeições para os destinatários do modelo 55. Exclusão da Regra de Validação N17c-30 Regra N17c-30 foi excluída a pedido do Estado do Ceará. Exclusão da Regra de Validação 1C17-40 Excluída a RV 1C17-40, eliminando a denegação também para o modelo 55. Regra de Validação N11-10 Criada a regra de validação N11-10 para exigir o preenchimento da origem da mercadoria quando o emitente não for CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI” Regra de Validação N12a-80 e N12a-81 Incluídas as regras N12a-80 e N12a-81 que verifica o correto preenchimento do CSOSN quando CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI”, nas operações internas e interestaduais. Regra de Validação N12a-90 Incluída a regra N12a-90 que verifica o correto preenchimento dos CFOPs quando CRT igual a “4=Simples Nacional – Microempreendedor Individual – MEI”, nas operações internas e interestaduais. Essa Nova NT se encontra disponível em nossa biblioteca, clique aqui para ter acesso a ela. Sobre os Prazos Essa NT esta prevista para ser implantada em homologação em 03/06/2024 e em produção em 02/09/2024. Sobre as Mudanças no ACBr e/ou na sua Aplicação A SEFAZ ainda não publicou os novos schemas, portanto vamos aguardar a publicação para podermos realizar as alterações no componente ACBrNFe, na lib ACBrLibNFe e no ACBrMonitor Plus.

Foi publicado em 11/04/2024 o Informe Técnico 2024.002 onde cria novos códigos (21 e 22) para os meios de pagamentos dos documentos fiscais e altera a descrição do meio de pagamento (17). As alterações na tabela de meios de pagamentos são para 01/07/2024 no ambiente de produção. Tabela dos meios de pagamento tPag Descrição dIniVig dFimVig Observações 01 Dinheiro 01/01/2020 02 Cheque 01/01/2020 03 Cartão de Crédito 01/01/2020 04 Cartão de Débito 01/01/2020 05 Cartão da Loja (Private Label) 01/07/2024 Cartão da loja, na forma de crediário etc. Não usar para o cartão de loja "bandeirado". 10 Vale Alimentação 01/01/2020 11 Vale Refeição 01/01/2020 12 Vale Presente 01/01/2020 13 Vale Combustível 01/01/2020 14 Duplicata Mercantil 01/01/2020 Duplicata Mercantil é um título de crédito vinculado a uma operação de venda ou prestação de serviços, disciplinado pela Lei nº 5.474/68. 15 Boleto Bancário 01/01/2020 16 Depósito Bancário 01/01/2020 17 Pagamento Instantâneo (PIX) - Dinâmico 01/07/2024 PIX realizado com a geração do Qr-Code de forma dinâmica ou URL dinâmica. As UF podem exigir que o código de transação do pagamento desse tipo de PIX seja informado na NF-e/NFC-e. 18 Transferência bancária, Carteira Digital 01/01/2020 19 Programa de fidelidade, Cashback, Crédito Virtual 01/01/2020 20 Pagamento Instantâneo (PIX) - Estático 01/07/2024 PIX realizado com Qr-Code estático ou por meio de transferência. 21 Crédito em Loja 01/07/2024 Crédito em loja decorrente de valor pago anteriormente, de devolução de mercadoria etc. 22 Pagamento Eletrônico não Informado - falha de hardware do sistema emissor 01/07/2024 Usado para informar que o pagamento por meio eletrônico não foi integrado por falha no hardware do sistema emissor de documento fiscal eletrônico, exclusivamente quando, por tal falha, não for possível a emissão offline. É uma informação útil para as empresas que utilizam sistemas integrados, sobretudo para aquelas que são obrigadas à integração do pagamento eletrônico com o documento fiscal pela sua UF. 90 Sem Pagamento 01/01/2020 99 Outros 01/01/2020 Quando o pagamento não estiver no rol desta tabela, o contribuinte deverá preencher o tipo de pagamento com "Outros" e informar, em campo específico da Nota Fiscal, a descrição adequada do meio de pagamento utilizado na operação ou prestação. Sobre as Mudanças no ACBr e/ou na sua Aplicação Serão necessários ajustes os quais serão informados aqui assim que forem disponibilizados. Importante: Dado a regulamentação existente no RS e MT a qual estabelece a obrigatoriedade da integração da emissão do documento fiscal como pagamento eletrônico de forma sistêmica, este ajuste deverá ser regulamentado internamente pelas UFs em questão. Links Link do Informe : https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=1rS27BEDS6c= Link da Tabela de meios de pagamento : https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=v5k1Ww0z Sw=

Olá pessoal, Foi publicado a NT 2024/002 que trata sobre o CT-e Simplificado. O que vem a ser o CT-e Simplificado: O CT-e Simplificado poderá ser utilizado nas prestações de serviços de transporte intermunicipal ou interestadual de mercadorias, que envolvam diversos remetentes ou destinatários, e um único tomador de serviço. O transportador poderá emitir um único CT-e referente a todas as prestações realizadas para este tomador, por veículo e por viagem. A forma de processamento do serviço de recepção é síncrona sem a formação de lotes. O contribuinte deve transmitir o CT-e simplificado através do Web Service de recepção exclusivo que atenderá esse leiaute e receberá o resultado do processamento na mesma conexão. O Layout do XML do CT-e Simplificado é bem diferente do CT-e (modelo 57) que estamos acostumados a ver. Sendo assim não da para expor nesse tópico os novos campos ou campos com novos valores, pois trata-se de uma estrutura de XML totalmente nova para o CT-e Simplificado.. Sobre os Prazos A previsão para implementação no ambiente de homologação é para o dia 02/09/2024 e produção para 07/10/2024. Mudanças no ACBr e/ou na Sua Aplicação A alteração no componente vai ser realizada em Julho e Agosto para que fique tudo pronto para a data prevista de implementação em ambiente de homologação. Dica de sempre, mantenham todos os fontes de todas as pastas atualizados, já se encontra no SVN a atualização dos Schemas que contempla o CT-e Simplificado

A Secretaria Especial da Receita Federal do Brasil (RFB) está em processo de unificação dos ambientes autorizadores SVAN e SVC-AN UF que utilizam a SVAN - Sefaz Virtual do Ambiente Nacional: MA UF que utilizam a SVC-AN - Sefaz Virtual de Contingência Ambiente Nacional: AC, AL, AP, CE, DF, ES, MG, PA, PB, RJ, RN, RO, RR, RS, SC, SE, SP, TO Os ambientes de HOMOLOGAÇÃO da SVC-AN e SVAN já foram unificados e as novas URLs já foram atualizadas no Portal Nacional da NF-e de HOMOLOGAÇÃO e já consta na revisão do svn 33246 Para quem utiliza o componente, pode utilizar o ACBrNFeServicos.ini junto da aplicação ou atualizar o componente e recompilar a aplicação para que tenha efeito as mudanças. No momento o Ambiente de produção não foi unificado, essas mudanças aplica-se somente a Homologação p/acbr/code - Revision 33246: /trunk2/Fontes/ACBrDFe/ACBrNFe (sf.net) Portal da Nota Fiscal Eletrônica (fazenda.gov.br)

Olá pessoal! Foi adicionado na página Sobre o SAT, um aviso informando que nos próximos meses, a Sefaz de São Paulo vai deixar de aceitar a comunicação dos SATs que utilizam os protocolos SSL 3.0 ou TLS 1.0. Desde a versão 2.28.05 das Especificações Técnicas do SAT, divulgada em 2021, é exigido a compatibilidade dos modelos SAT e versões de software básico com o protocolo TLS1.2, que é o mais seguro atualmente no projeto SAT. A previsão para o desligamento do protocolo SSL 3.0 é a partir de 05/08/2024, enquanto que a o do protocolo TLS 1.0 será a partir de 01/10/2024. Abaixo segue a relação de modelos SAT afetados: A Sefaz orienta que os contribuintes realizem a atualização para versões mais seguras para os casos em que é possível indicados na coluna "Há atualização de SAT para versão mais segura" e para os que não forem, que busquem alternativas juntos aos fabricantes SAT ou considerem o uso da NFC-e que é o documento fiscal alternativo ao SAT.

A Receita Federal do Brasil - RFB informa que desativará a transmissão síncrona (versão 1.5.1) dos eventos R-1000, R-1070 e R-3010 e dos eventos da série R-2000 a partir de 22/07/2024. A partir dessa data, todos os eventos deverão ser enviados exclusivamente no modo assíncrono (versão 2.1.2). http://sped.rfb.gov.br/pagina/show/7400

Foi publicada a versão 24.1.C das tabelas fornecidas pelo IBPT, as quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/03/2024 até 30/04/2024. 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

Para quem estiver com problemas de acesso aos nossos manuais on-line, tanto do ACBrLib ou ACBrMonitorPlus, estamos disponibilizando em formato PDF. ACBrMonitorPlus: ACBrMonitor.pdf ACBrLib: ACBrLib.pdf

Salve comunidade do Projeto ACBr ! Agora com o nosso componente ACBrBoleto é possível emitir Boletos, gerar e receber CNAB 400 para o Banco 107 - Banco BoComBBM Home - Banco BOCOM BBM A atualização já está em nossos repositórios ! *Em breve as documentações sobre o novo banco serão atualizadas (ACBrLibBoleto, ACBrMonitorPlus)*

Corromperam o BD da receita, agora tão procurando o pen drive com o último backup kkkkkk

Olá pessoal! Seguem abaixo os passos que segui para configurar o ACBr via Maven para usar com Eclipse ou IntelliJ. Os passos foram relativamente simples Buildar o Ac Br Commons, exporar um jar (1.0.0) Pega esse Jar e instalar no seu Maven Repository mvn install:install-file -Dfile="C:\projetos\AcBr\boleto-service\src\main\resources\lib\ACBr Common.jar" -DgroupId="br.com.acbr" -DartifactId="acbr" -Dversion="1.0.0" -Dpackaging="jar" E adicionar no projeto as dependencias: <dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna</artifactId> <version>5.9.0</version></dependency> <dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna-platform</artifactId> <version>5.9.0</version> </dependency> <dependency> <groupId>br.com.acbr</groupId> <artifactId>acbr</artifactId> <version>1.0.0</version> </dependency> Trouxe para cá pois isso pode ajudar outra pessoa a fazer essa configuraçao, pois pouca gente usa o NetBeans.... maioria usar o Eclipse ou o IntelliJ... e com essa configuração via Maven, essa dependencida do Netbeans mostrada nos videos não é mais necessária, se torna opcional.

Boa tarde, hoje conseguimos registrar o boleto hibrido pix em produção e retornou o qrcode do pix....agora ficou 100%, mais o header precisa está desse jeito aqui... {*** MONTAGEM DO HEADER ***} FHTTP.Request.Clear; FHTTP.Request.CustomHeaders.Clear; FHTTP.Request.UserAgent := 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Acoo Browser; GTB5; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; Maxthon; InfoPath.1; .NET CLR 3.5.30729; .NET CLR 3.0.30618)'; FHTTP.Request.Accept := '*/*'; FHTTP.Request.AcceptCharSet := 'UTF-8, *;q=0.8'; FHTTP.Request.AcceptEncoding := 'gzip, deflate, br'; FHTTP.Request.BasicAuthentication := False; FHTTP.Request.Connection := 'keep-alive'; FHTTP.Request.CustomHeaders.FoldLines := False; FHTTP.Request.ContentType := 'application/json'; FHTTP.Request.CustomHeaders.Add('Authorization: Bearer ' + editToken.Text); //TOKEN OBTIDO. FHTTP.Request.CustomHeaders.Add('X-Brad-Signature: ' +vStrRequestAssinado); FHTTP.Request.CustomHeaders.Add('X-Brad-Nonce: ' + IntToStr(vIntMiliSegundos)); FHTTP.Request.CustomHeaders.Add('X-Brad-Timestamp: ' + vStrTimeStamp); FHTTP.Request.CustomHeaders.Add('X-Brad-Algorithm: SHA256'); FHTTP.Request.CustomHeaders.Add('access-token: ' + CLIENT_ID); FHTTP.Request.CustomHeaders.Add('cpf-cnpj: ' + 'AQUI VC COLOCA O CNPJ DA EMPRESA'); {*** FIM MONTAGEM DO HEADER ***} Parte do json de retorno, eu modiquei os dados baixo por segurança. "wqrcdPdraoMercd":"00020101021226910014BR.GOV.BCB.PIX2569qrpix.bradesco.com.br/qr/v2/cobv/950dfdf4e46-cdfdgdgdgfdfdfc91-9d21-3045adf0dfdfd052040000530395656563654045.155454502BR5919EMPRESA LTDA6008AADGPH62070503***63063F7F","validadeAposVencimento":60,"qFiller6":"","sfiller6":"","sfase":1}

Todas as modificações necessárias para essa NT já se encontram no SVN do ACBr, implementadas pelo nosso consultor @Italo Giurizzato Junior https://sourceforge.net/p/acbr/code/32800/

Esse link descreve bem o problema de incompatibilidade do OpenSSL 3.x com os antigos certificados https://www.practicalnetworking.net/practical-tls/openssl-3-and-legacy-providers/

Boa noite, Novos nugets enviados, versão 1.0.2.0.

Ajuste SINIEF Nº34/23 de Setembro de 2023 altera o Ajuste SINIEF Nº11/19 de 05 de Julho de 2019 Ficam revogados : I - os incisos I e III da cláusula primeira; II - o inciso II da cláusula segunda; III - o inciso I da cláusula quarta. Portanto, a Extinção da CSOSN como ficou conhecida ainda não ocorrerá, a criação dos novos códigos de CST ou remoção dos CSOSN dependerá de outro ajuste, possivelmente foi removido por conta da reforma tributária, assim, evitando vários rollouts e ajudando a todos. Não há alterações previstas para a SoftwareHouse no momento! Fonte : https://www.confaz.fazenda.gov.br/legislacao/ajustes/2019/AJ011_19

Boa tarde pessoal, Resolvi postar aqui um problema que temos há algum tempo aqui na empresa em relação as LIBs. Estamos rodando a LIB consumindo a AcbrLibNfe no Linux com PHP, mas meu receio é em produção porque existe esse problema de qualquer parâmetro inválido, mata o servidor e ocorre um problema de memória, já coloquei em uma máquina local linux, já coloquei na AWS, ocorre a mesma coisa. O erro que acontece no c++ é o seguinte: Em todos os lugares que pesquisei (incluindo gpt), é dito que isso é um problema de memória (ponteiro). Muitas pessoas tiveram o mesmo problema, o exato erro Segmentation Fault(11), no php, ele aparece da seguinte forma: Mesmo colocando o código dentro de um try {} catch {} o erro acontece. Alegam que o erro é o Xvfb não ter sido iniciado corretamente. Não é isso, se o Xvfb não for iniciado a extensão também não inicia. Só para lembrar, o Xvfb é o emulador da parte gráfica para versões do Linux que não possuem interface visual (como na aws). Com o comando abaixo eu verifico o status do serviço do Xvfb: Para contornar o problema da lib de não retornar o erro, o primeiro passo foi criar as classes da pasta Meta para que o php valide todas as informações que são passadas para extensão: Mas mesmo assim, em alguns casos ocorrem erros, acredito que seja pelo fato de parte da documentação estar errada ou desatualizada, um exemplo, é a Lib CRY_CAPICOM que está na documentação como opção válida, porém, ao definí-la na extensão, o erro Segmentation Fault acontece: Isso está extremamente lento, (descobrir as combinações válidas). Além do fato de que eu também preciso validar o tipo de dado (string, boolean, number etc) para passar para a extensão pois se o tipo de dado estiver errado, a extensão também para de funcionar. Na classe NFeConfig.php eu faço todas as validações iniciais (apenas as iniciais, pois todo o código precisa de validações para contornar o bug da extensão). Todos os caminhos de arquivos e diretórios tem que ser validados pois um caminho inexistente também gera o erro. O erro está no c++, corrigindo lá o erro no php deixará de acontecer. Se você quiser eu posso criar um zip aqui com os arquivos para que testem aí. Eu terei que criar um arquivo de instruções para que consigam fazer funcionar.

Desafio: executar a lib ACBrBoleto diretamente em um APP SERVICE LINUX no Azure, sem uso do Docker Backend em C#/.NET 6 Os comandos são executas via SSH em Development Tools/SSH A execução do start do app service pode ser acompanhada em Log Stream Comandos úteis: Verifica se o arquivo existe e em qual pasta está. No caso eu fiz o deploy para a pasta raiz da aplicação (usando Azure Devops). find / -name libacbrboleto64.so 2>/dev/null Lista as dependências da biblioteca e confirma se a lib pode ser "lida" ldd libacbrboleto64.so O arquivo de inicialização padrão /startup.sh deverá ser copiado para a pasta /home a fim de ser personalizado Copia o arquivo de inicialização do app service para a pasta /home. Qualquer arquivo fora de /home é apagado quando o serviço é reiniciado. cp /opt/startup/startup.sh /home Uma vez copiado o arquivo deverá ser editado (usar o VIM) e antes da execução da aplicação acrescer as linhas abaixo: echo *** Atualiza a lista de pacotes apt-get update echo *** Instala as dependências faltantes da lib ACBrBoleto (listadas no comando ldd libacbrboleto64.so) apt-get install -y libgdk-pixbuf2.0-0 libgtk2.0-0 libpango1.0-0 libatk1.0-0 libcairo2 libpangocairo-1.0-0 echo *** Instala emulador de interface gráfica. A lib precisa pra funcionar. apt-get install -y xvfb echo *** Remove lista de pacotes (opcional) rm -rf /var/lib/apt/lists/* echo *** Cria uma screen virtual identificada pelo nº 1 Xvfb :1 -screen 0 1024x768x24 & No app service em Settings/Enviroments variables inserir name e value: DISPLAY :1 Por último, em Settings/Configuration/Startup Command inserir /home/startup.sh Alguma coisa deu errado? basta remover o comando no Startup Command que será usado o arquivo de inicialização padrão (/opt/startup/startup.sh) Depois de alguns dias de dor de cabeça tudo testado e funcionando !!!!!!!!!!

Não compreendi.. Você não conseguiria ajustar a chamada do parâmetro, do seu lado da aplicação ? Parece ser uma alteração simples... enviando apenas um parâmetro Boleano... Lembro ainda que a SEFAZ que decidiu mudar para não aceitar mais o modo Assincrono.. não foi uma mudança no ACBrMonitor

ai pessoal obrigado pela ajuda . resolvi da segunda forma alterei o arquivo openssl.cnf que fica na pasta \usr\lib\ssl acrescentando esta linhas em negrito abaixo. segue o link se alguem precisar Openssl 3.x and Legacy Providers – Practical Networking .net

Boa tarde @nildglan, Eu já tinha dito acima que se mesmo informando o ultimo NSU na próxima execução ainda retorna consumo indevido é indicio de que outra pessoa/empresa esteja fazendo essa consulta. Isso acontece bastante, pois as empresas fornecem uma cópia do certificado para o escritório de contabilidade e este começa a fazer essas consultas. Agora se você esta usando o seu certificado para consultar as notas emitidas contra o seu CNPJ e mesmo assim esta tendo esse tipo de rejeição, tem alguma coisa errada. Dentro da sua empresa só você esta fazendo esse teste ou mais alguém esta fazendo em outra maquina? A cada tentativa usando o seu certificado o ultNSU muda?

Veja que agora o ultNSU é 1719, se você não entendeu o processo vai continuar patinando. Seu ultNSU era 1718, você deveria utilizar o método passando ultNSU 1718 até receber pelo menos um novo NSU. Você recebeu um novo NSU, agora irá passar a consultar o 1719 e aguardar pelo menos 1h. Quando você receber 1 ou mais novos NSUs, irá identificar qual o ultNSU para a próxima pesquisa, enquanto não receber nenhum novo NSU, seguirá utilizando o 1719. Veja o tópico a seguir e o curso no nutror Implementando o serviço Distribuição DFe.

Boa tarde a todos, Fazendo uma pesquisa no site --> https://legislacao.fazenda.rj.gov.br. Foi postada uma nova Resolução referente a Resolução 578. Segue abaixo o link da nova Resolução. RESOLUÇÃO SEFAZ Nº 636 DE 01 DE ABRIL DE 2024. https://legislacao.fazenda.rj.gov.br/resolucao-sefaz-no-636-de-01-de-abril-de-2024/ Na Resolução 636 informa que a data foi postergada novamente para o dia 01/05/2024 para a obrigatoriedade dos campos ICMS EFETIVO E RETIDO conforme os requisitos da Resolução 578.

Fizemos um ajuste, vou te enviar uma versão por mensagem privada para que você possa realizar um teste, combinado ?!

@rpaulogio No nosso projeto fizemos assim.... ' "nroCpfCnpjBenef":"'+Copy(SQL_busca_contaEmpresa_CNPJ.AsString, 1, 8)+'",' + ' "filCpfCnpjBenef":"'+Copy(SQL_busca_contaEmpresa_CNPJ.AsString, 9, 4)+'",' + ' "digCpfCnpjBenef":"'+Copy(SQL_busca_contaEmpresa_CNPJ.AsString, 13, 2)+'",' +

@_asseinfo os manuais está nesse link....Clique aqui ManualAPI

@Daniel InfoCotidiano bom dia, meu ambiente onde rodo o servidor, é debian (é um conteiner), ja a aplicação que consome essa api roda em windows e linux (multiplataforma), uso lazarus pra dev, aqui no meu ambiente para resolver e não alterar o componente orignal pra não precisar adaptar futuras alterações eu herdei e fiz os ajustes (no create e do destroy) dai ficou funcionando blz no meu ambiente.... Att.

Boa tarde... Na verdade é muito simples.. é só informar o CFOP 5949 e o CST de icms igual a 90 (Se não for simples nacional), ou CSOSN=900 (caso for simples nacional) com alíquota e base de cálculo zeradas... Isso fará com que esses documentos não debitem imposto na apuração do icms

Boa tarde @Lucio Bittes e @willian_delan hoje consegui registrar o boleto em produção, mais pra minha surpresa o qrcode do pix do veio no retorno do json, registrei 2 boletos e não veio retorno....é complicado....o mesmo problema que aconteci em homologação, aconteci em produção...eu informei tudo certo no json de envio. Para o qr code do pix tem marcar esse campo "cindcdCobrMisto":"S", e não deu certo...agora vou entrar em contato com suporte da API do Bradesco relatando o problema. Parte do retorno abaixo. "cindcdCobrMisto":"S","ialiasAdsaoCta":"06936134000195","iconcPgtoSpi":"20340904287093955007364400000000016","caliasAdsaoCta":"","ilinkGeracQrcd":"","wqrcdPdraoMercd":"","validadeAposVencimento":60,"qFiller6":"","sfiller6":"","sfase":1}

"[+] Adicionada propriedade AjustaAguardaConsultaRet onde quando for True, a propriedade AguardarConsultaRet será ajustada com o valor do campo tmed do retorno de consulta de status do serviço." Fonte: ACBrNFe-change-log.txt na pasta Fontes\ACBrDFe\ACBRNFe, lh. 4286.

só complementando. não é bom colocar em system32 ou syswow64 pois pode ser substituido por outro em algum momento e ocasaionar erros

Certo, vou fazer o download dos arquivos atualizados e refazer as alterações. Assim que concluir envio novamente os fontes.

Bom dia @BYTE INFO, Verifica também se na pasta que se encontra o ACBrMonitor não consta o arquivo ACBrCTeServicos.ini antigo, ou seja, sem as URLs da versão 4.

Boa noite! Só para comunicar aqui para vocês que deu certo, retirei tudo que tinha como application.onexception e applicationevents e hoje sistema hoje não fechou sozinho mais Muito obrigado @Renato Rubinho, @Juliomar Marchetti

Conferindo no arquivo ACBrNFSeXServicos.ini estas são as URLs temos para a cidade de Novo Hamburgo/RS [4313409] ; Atualizado em 12/12/2023 Nome=Novo Hamburgo UF=RS Provedor=IPM Versao=2.04 ProRecepcionar=https://nfse-novohamburgo.atende.net/?pg=services&service=WNENotaFiscalEletronicaNfe&cidade=padrao HomRecepcionar=https://homologacao.atende.net/?pg=services&service=WNENotaFiscalEletronicaNfe&cidade=integracoes Onde HomRecepcionar é homologação e ProRecepcionar é produção. Se você tentar abrir ela no navegador, ele vai mostrar uma telinha pedindo usuário e senha. Se informar as credências que está usando, ele acessa? Este frame define o ambiente para todos os DFes. Este campo Produção no INI é usado para definir informações no XML do RPS.

Boa tarde!! Até peço desculpa em não ter reportado aqui, pois como estou envolvido em outros projetos mais urgentes.. esta situação do email ficou para "depois". @Caue Segura, fiz um teste configurando desta forma que mencionou e funcionou !!!

Boa tarde! Tive o mesmo problema que o Enéias e não consegui resolver atualizando a versão, fiz alguns testes com o mesmo nome de anexo informado pelo Diego e parece que o problema está relacionado ao campo CodificacaoResposta da seção Principal, seguem os prints dos testes: CodificacaoResposta=0 CodificacaoResposta=1

Olá pessoal! Na data de 19/03/2024, por volta das 08h44 começamos a receber múltiplos relatos no canal #sefaz em nossa comunidade do Discord de membros com problemas para comunicar com os web services da Sefaz de São Paulo. Os relatos variam entre Falha no Schema e erro 500. Conferindo no DownDetector é possível observar que o volume de relatos de problema aumentou exponencialmente neste mesmo período: Não há contingência ativada até o momento da publicação deste tópico.

Bom dia, Já estamos verificando. caso precise da documentação veja este topico:

Sim, o fechamento do tópico anterior está correto @Juliomar Marchetti, se referia a apenas os prazos e disponibilidade dos atributos nas SEFAZ. Esse novo tópico, criei esse para indicar que tem nova versão e que os fontes sofrerão alterações para adequar a ela.

Deu certo. para resolver foi instalado o VCRedist 2013. Desse link https://github.com/abbodi1406/vcredist/releases

Creio que seja aqui: http://svn.code.sf.net/p/acbr/code/branches/ACBrBombas/

Bom dia, agradeço a atenção @Italo Giurizzato Junior, não conseguirei testar prontamente essa semana, possivelmente semana que vem já devo conseguir realizar o teste e comento aqui no fórum o resultado.

@Italo Giurizzato Junior e @Diego Foliene Analisando essa questão, notei que o problema ocorre nas Units que ainda usam o antigo PCN... A antiga versão da rotina "ParseTXT" tinha uma característica (bug), de sempre retornar um ANSI, mesmo quando o parâmetro de entrada, era um UTF8... Isso causava problemas, quando precisávamos gravar os XMLs em UTF8, ou carregar ele na LibXML2 Após a correção da ParseTXT, todos os métodos que chamam ela, precisam ser revisados O Delphi espera que os caracteres que ele irá manipular em Tela, estejam em ANSI (no windows) e UTF8 no Android e Linux... Então é necessário, tratar isso, antes de mover para as propriedades dos objetos... Exemplo de ajuste em ACBrCTeWebServices.pas, linha 1113 FCTeRetornoSincrono.Leitor.Arquivo := UTF8ToNativeString(ParseText(AXML)); FCTeRetornoSincrono.LerXml; O Problema não ocorre, nas classes que usam TACBrXmlDocument, como Reader, pois essa classe que faz uso da LibXML2, já espera os dados em UTF8

Olá Pessoal, Muitos desenvolvedores ainda utilizam o componente antigo (ACBrNFSe) para emitir as NFS-e e noto uma resistência em mudar para o novo (ACBrNFSeX). Resistência essa pelo desconhecido, pelo tempo, uma vez que já dissemos que muitas coisas mudaram do antigo para o novo. Ai vem a grande pergunta, devemos ou não migrar para o componente novo? A resposta é: Sim. Vou listar alguns motivos: 1. O código do novo componente ficou muito mais limpo, consequentemente a sua manutenção e correção se tornou muito mais fácil. 2. A implementação de novos provedores também ficou muito fácil, se o provedor segue a versão 1 ou 2 da ABRASF é possível implementar em apenas 1 hora, agora se ele tem um layout próprio pode levar 1 ou 2 dias. 3. O componente novo atende todos os provedores do antigo e vários provedores novos, tornando o componente novo mais completo. 4. No componente novo foi utilizado novas units (rotinas) para a leitura e escrita do XML, rotinas estas mais rápidas em relação as utilizadas pelo componente antigo, logo o componente novo é mais rápido que o antigo. 5. O novo componente foi disponibilizado em 24/05/2021, dessa data em diante não damos mais manutenção no antigo, diversas correções e melhorias vem sendo aplicadas somente no componente novo. 6. Por fim, mas não menos importante a emissão da NFS-e Padrão Nacional que só existe no componente novo. Acredito ser conhecimento de todos que desde de 01/09/2023 o prestador de serviço que é MEI (Micro Empreendedor Individual) é obrigado a emitir as suas notas segundo o layout da NFS-e Padrão Nacional. Caso você desenvolvedor venha amanhã conquistar um cliente novo que é MEI, será obrigado a usar o componente novo, uma vez que o antigo não tem essa possibilidade. Temos cidades que já estão aderindo ao projeto da NFS-e Padrão Nacional. Essa adesão pode se dar de duas formas: 1. Aderir somente ao compartilhamento das notas com a Receita Federal. 2. Além de aderir o compartilhamento, aderir também a emissão da NFS-e segundo o Padrão Nacional. Como funciona a emissão da NFS-e nessas duas situações? Na primeira situação quando a prefeitura adere somente o compartilhamento, o prestador de serviço que não é MEI continua emitindo as suas notas através do provedor contratado pela prefeitura e esta por sua vez compartilha a nota com a Receita Federal. Na segunda situação quando a prefeitura adere o compartilhamento e a emissão, o prestador de serviço que não é MEI passa a emitir suas notas através da API da Receita Federal. Algumas cidades estão migrando por etapas como é o caso de Porto Alegre/RS que até o momento somente os prestadores que são Simples Nacional foram migrados, ou seja, devem emitir suas notas segundo o Padrão Nacional, os que não são Simples Nacional devem aguardar mais um pouco portanto devem continuar a emitir as suas notas pelo provedor contratado pela prefeitura. A Receita Federal esta conversando com todas as prefeituras, mostrando as vantagens delas de pelo menos aderir o compartilhamento. Uma das cidades que vai aderir o compartilhamento é Uberlândia/MG e que esta mudando de um provedor com layout próprio para outro que segue a versão 2 do layout da ABRASF, segundo funcionários da prefeitura com o layout da ABRASF fica muito mais fácil realizar o compartilhamento. Detalhe, esse novo provedor de Uberlândia/MG não existe no componente antigo. Depois de tudo que foi exposto acima, você vai continuar com o componente antigo? Não deixe para amanhã o que você deve fazer agora.

Boa tarde! Por favor, tente limpar o cache do navegador que está utilizando e acessar novamente. Ambos os modelos S-2500 e S-2501 estão disponíveis. https://acbr.sourceforge.io/ACBrMonitor/ModeloEventoS2500INI1.html https://acbr.sourceforge.io/ACBrMonitor/ModeloEventoS2501INI1.html

Bom dia @shztec, Porque você esta consultando pela chave? A cidade de Canoas/RS se utiliza do provedor Infisc, mas para esta cidade o provedor se utiliza do webservice que trabalha com a versão 2.03 do layout da ABRASF, sendo assim os serviços disponibilizados são os mesmos da versão 2.01 TACBrNFSeXWebserviceInfisc201 = class(TACBrNFSeXWebserviceSoap11) public function Recepcionar(const ACabecalho, AMSG: String): string; override; function RecepcionarSincrono(const ACabecalho, AMSG: String): string; override; function GerarNFSe(const ACabecalho, AMSG: String): string; override; function ConsultarLote(const ACabecalho, AMSG: String): string; override; function ConsultarNFSePorRps(const ACabecalho, AMSG: String): string; override; function ConsultarNFSePorFaixa(const ACabecalho, AMSG: String): string; override; function ConsultarNFSeServicoPrestado(const ACabecalho, AMSG: String): string; override; function ConsultarNFSeServicoTomado(const ACabecalho, AMSG: String): string; override; function Cancelar(const ACabecalho, AMSG: String): string; override; function SubstituirNFSe(const ACabecalho, AMSG: String): string; override; function TratarXmlRetornado(const aXML: string): string; override; end; De posse do numero de protocolo retornado, você vai utiliza-lo no método ConsultarLote.

Pelo que vi no log vc mandou 2 comandos de uma vez só. Entao Primeiro vc vai envar o comando: EnT.TXT 18/03/2024 15:58:52 - NFE.SetModeloDF(65) 18/03/2024 15:58:55 - OK Depois outro ent.txt com a nota... 18/03/2024 15:59:20 NFE.CriarEnviarNFe( "[Identificacao] NaturezaOperacao=VENDA MERC. ADQ./RECEB. TERC. EM OP modelo=65

Olá, @MuriloS.A! Executei o patch que você disponibilizou no último anexo deste tópico. Ao efetuar uma venda, a transação é aprovada. No entanto, não imprime os comprovantes, pois a resposta, nos campos dos comprovantes, não possui nenhuma informação, embora os logs estejam todos gerados. Devo fazer algum ajuste naquele código? Att. José Filho