Painel de líderes

Bom dia! Conforme foi amplamente noticiado em tópicos e edições do papo PRO, hoje dia 01 de Setembro de 2023, é o dia em que os prestadores de serviço que são MEI, passam a obrigatoriamente precisar emitir NFS-e usando o Padrão Nacional. O componente ACBrNFSeX, o ACBrMonitorPLUS e a LibNFSe estão preparados para emitir no Padrão Nacional via API. Recebemos relatos de que ao tentar fazer esta emissão usando essas soluções, membros de nossa comunidade estão recebendo o retorno "The Service Unavailable" e até mesmo o portal da NFS-e Nacional tem retornado está mensagem em tentativas de acesso. Em contato com membros responsáveis, um de nossos consultores recebeu o seguinte retorno: Vamos acompanhando a situação e atualizando este tópico a medida que consigamos novas informações.

Bom dia Max, O componente ACBrNFSeX, a DLL ACBrLibNFSe e o ACBrMonitor Plus já estão aptos a emitir NFS-e segundo o Padrão Nacional. No caso do Padrão Nacional não temos um WebService Soap e sim uma API Rest. Independente da forma como é recepcionado o XML do Rps ou DPS (no caso do Padrão Nacional) as 3 soluções do ACBr estão preparadas para se conectar com um WebService ou API Rest.

Pessoal na realidade tentei resolver mas sem sucesso. Acabamos comprando o A1, e rodou na hora. Agradeço o apoio de todos Abraços

Boa tarde, Atualize todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Já efetuei os testes e está funcionando em produção em um cliente. Show! Valeu!

Obrigado!

Boa tarde Tiago, Já esta no SVN.

Olá Italo, Desenvolvedor responsável não se encontra na empresa hoje. Faremos os testes na segunda e te devolvo a resposta. Atenciosamente, Dinael Silva

Bom dia, recentemente tive um problema atipico em um cliente, após uma atualização do sistema. Venho sugerir uma melhoria na tratativa dos retornos de erro do ACBrPIXPSPSicredi ( banco em questão ). Atualmente a mensagem de erro retornado pela excessão gerada é a seguinte: "Erro HTTP: 400, Metodo: POST, URL: https://api-pix.sicredi.com.br/oauth/token" no entanto, esta "vaga" a mensagem real do erro. Com uma pequena alteração adicinei a Real mensagem do erro ficando assim: "Erro HTTP: 400, Metodo: POST, URL: https://api-pix.sicredi.com.br/oauth/token" Escopo negado ( o Usuário não tem acesso ao escopo solicitado): cobv.read Porém só cheguei a esta mensagem final.. após ir depurando o fonte em ambiente de produção. Minha sugestão então seria esta. desde já Obrigado pelo excelencia dos componentes. Alterções na Unit Adicionado as linhas 169 até a 175. alterado a Linha 176 Abraços Pablo Cerbaro ACBrPIXPSPSicredi.pas

Ok. Obrigado por hora. e grato pelo retorno e pelo serviço de toda comunidade ACBr. Abraços e bom final de semana.

Boa tarde.

Boa tarde! O provedor SoftPlan faz uso de informações de autenticação para que as requisições possam ser feitas com sucesso. Por causa disso, ao emitir NFS-e para as cidades atendidas por este provedor, o primeiro método a ser usado é o GerarToken, para conseguir um Token de acesso que deve ser fornecido nos métodos posteriores. Para a correta geração do Token, as seguintes informações devem ser fornecidas: Um membro de nossa comunidade, em contato com o provedor conseguiu a seguinte correlação: client_id e client_secret são fornecidos por desenvolvedor pelo provedor. username é a inscrição municipal do prestador. password é o MD5 da senha usada para acessar o portal em maísculo.

Criada a TK-4389 para avaliar. Obrigado pela contribuição.

Boa tarde, não tem um local pra pesquisar a versão, mas quando vai transmitir na versão 1, se não me engano falava q estava desativada ou para transferir na versão 2.02, não lembro exatamento o erro por que fiz este acerto local pra mim faz un 5 ou 6 meses. Agora quando atualizei o ACBr semana passada voltou a dar erro na transmissão, eu tinha esquecido de avisar vocês desta atualização. Eu fiz este acerto para as cidades de Ouro Branco/MG e Conselheiro Lafayete/MG. Veja um XML de Jun/2023 do cliente(ocultei alguns dados q possam identificar ele)

Refiz todo o processo que você disse Italo. Não obtive sucesso ainda. Fizemos teste em produção e funcionou a principio. Vou continuar de olho para ver se descubro algo a mais.

Boa tarde! Verificamos em nosso sistema, e realmente não passamos o campo referente ao regime tributário. Vamos fazer alguns testes aqui e qualquer coisa retorno novamente. Muito obrigada!

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

Vou deixar aqui o fim da thread caso alguém mais tenha esta dúvida. Basta fazer um patch para a API mudando o status para REMOVIDA_PELO_USUARIO_RECEBEDOR. Endpoint: /cobv/{txid} Payload: { "status": "REMOVIDA_PELO_USUARIO_RECEBEDOR" } Muito obrigado

@Dev Telluria Testei em meu ambiente e tinha campo como regime tributário faltando. Veja se o layout bate com do seu sat . no seu esta 0,07 no meu 0,08 Vou anexar o seu ini que modifiquei para testes aqui. Vc tem q colocar seus dados cnpj, assinatura, etc p funcionar ai com no seu ambiente. CFe002.INI Acima, com as modificações, funcionou. Só confirme com o seu contador os valores ICMS.. etc.

Olá @Pablo Cerbaro Essa implementação pode falhar em casos onde o erro HTTP não possui uma resposta Json ou não contenha a tag 'detail'. Mas da maneira que está implementado atualmente, basta ativar o log do componente para ter acesso a todos os detalhes das requisições e das respostas recebidas.

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

@Dev Telluria Chegou a fazer o teste adicionando os campos que citei acima?

Deu certo, obrigada pela ajuda!

@Dev Telluria Pelo que vi no log, teste informando as tags abaixo. (so confirme o codigo do produto vendido se é o mesmo citado): [obsFiscoDet001001] xCampoDet=Cod. Produto ANP xTextoDet=320101001 Manual com INI Completo: https://acbr.sourceforge.io/ACBrLib/ModeloCFeINI.html

Olá @Vitória Garcia Obrigado por reportar. Acabei de subir uma correção ao SVN, rev: 30489. Por favor baixe os fontes novamente e faça um novo teste.

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

Bom dia! Conferindo nos fontes, o XML da NFSe é esperado e salvo no retorno do método NFSe_ConsultarNFSePorRPS ou nos métodos ConsultarNFSePorXXXX

Bom dia Italo. Ok, vou fazer e qq problema reporto. Obrigado!

Olá, Obrigado pela contribuição. A rotina foi reescrita para importação adequada dos dados e enviada ao SVN na Rev-30488. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema

Obrigado Rodaldo pela dica. mas o roundabnt do acbr funcionou certinho agora q o inclui em todos os calculos - Fiquem com DEUS

ate onde entendi a tabela é federal, nao tem nada de alíquota do municipio nao (exceto do iss) o calculo é o q o @rofresi postou mesmo... BC * % da tabela (segmento do orgao)

@gilsoftware, complicado... Me parece que a autorização para os órgãos efetuar a retenção é federal.. mas alem disso tem a lei municipal... Que no caso de nossos clientes foi de 1,20... Adicione um campo parametrizavel e deixe isso a cargo do contador do cliente...

Depois de olhar o retorno do log 01/08/23 12:23:11:241 - SetRetorno(-10, Wrong image format) observei que foi implementado no ESC/POS o <bmp> e que o mesmo estava buscando a imagem da LIBNFE, que Eu uso .png. por isso não imprimia NFC-e em ESC/POS, mais imprimia em FORTES A4 e FORTES 40 colunas com imagem. reescrevi minha rotina para não mais enviar imagem para lib quando a impressão for ESC/POS. pronto problema Resolvido está imprimindo usando RAW:bema (cups) resumindo.: a impressora em ESC/POS aceita só BMP de um determinado tamanho (ainda não sei qual). se enviar PNG ela não imprime. Obrigado @Daniel InfoCotidiano pela ajuda.

Veja no tópico a seguir, foi indicado o preenchimento da NaturezaOperacao também em problema semelhante. Se persistir o problema, veja o que diz o manual do provedor a respeito destas tags.

Bom dia! Para mim não funcionou com estas alterações, tive de alterar diretamente no Fast Report (frxZLib). Com a alteração que fiz não precisa desativar a compactação do PDF. Sem compactar estava inviável gerar PDF e enviar para o destinatário. Temos clientes que emitem centenas de notas por dia e sem compactar aumenta de 8 a 10x o tamanho do PDF. Pasta das notas do dia com pdf compactado beirava 1Gb e sem compactação quase chegou a 10Gb.... totalmente inviável. Vendo o fonte parece pouca alteração (faça um compare e verá) mas levei quase 7 horas para chegar no resultado esperado. EDIT: Só para afirmar, é um problema para quem usa o Delphi Alexandria (11 / 11.1) frxZLib.pas