Diego Foliene

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

Bom dia! Você utiliza componente nativo para Delphi/Lazarus, ACBrMonitor ou ACBrLib?

Bom dia! Que bom que deu certo! Muito obrigado pelo feedback! Só para confirmarmos então, você precisou usar a unit do PSP alterada que foi anexada no tópico ou deu certo usando a que está no SVN?

Boa tarde! Utilize UTF-8, por favor.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn #TK-5837

A chave CodificacaoResposta define qual é o encoding que será exibido as respostas da Lib.

Consegue realizar um teste no ambiente de produção para conferir se ele também apresenta o mesmo problema? Se em produção for recepcionado com sucesso, é um indicativo de que o problema possa estar no ambiente de homologação.

Bom dia! Sim! A princípio, a assinatura parece estar correta de acordo com as informações. Conversando com os demais consultores, parece que apesar das informações que indicam ser um novo provedor, ainda é o Ginfes que atende a este município. Por isso, vamos dividir sua situação em dois frontes. Na #TK-5831 vamos focar em deixar o Giss operacional*. * Com as modificações efetuadas, já é possível comunicar com o web service, mas estamos recebendo uma rejeição que indica um problema no arquivo. Nosso objetivo, como não temos dados válidos é receber um rejeição de CNPJ do prestador não autorizado ou algo do gênero, que indique que o problema está nos dados informados e não na estrutura do arquivo. EM PARALELO, vamos voltar ao problema inicial que é você estar recebendo a rejeição "Código de Tributação Inexistente". Nos arquivos que disponibilizou a tag <CodigoTributacaoMunicipio> está com o valor "465" apenas. Esta informação está correta? Buscando mais informações a respeito deste erro aqui no fórum, em outro tópicos as respostas dos colegas deram a entender que o essa informação é maior. Neste TÓPICO¹, um colega informa que usa um valor de até 17 casas decimais considerando espaços em branco e caracteres(14.01 / 331399900 neste exemplo). Já neste outro TÓPICO², um colega disse utilizar 1.07/1.07.00/1869. Por fim, neste TÓPICO³, um colega utiliza uma informação um pouco diferente, mas ainda assim com mais caracteres do que a que está utilizando. Por favor, confira no Acesso do Prestador no Portal se o valor 465 está correto. Se ele tiver zeros a esquerda ou caracteres especiais, faça um teste passando este valor. Mesmo que o XML que conseguiu no portal esteja com o valor 465, ele é o XML de uma NFS-e. Pode ser que o web service esteja esperando uma informação e faça um conversão interna na hora de converter o XML do RPS para um NFSe.

Você está recebendo Erro não catalogado tanto em sua aplicação quanto no programa exemplo? Esta enviando em homologação ou em produção?

Bom dia! Está em nosso backlog para ser analisado conforme a disponibilidade da equipe de consultores. Vou adicionar uma observação de que solicitou o status da tarefa.

Bom dia. Criada a #TK-5836 para análise do caso e parecer por parte da equipe de consultores.

Bom dia! Se a informação vem no XML de retorno, mas ao ler a propriedade do componente está vindo em branco, é possível que sejam as dlls de dependência. Tente adicionar as dlls da LIBXML2 (escolhendo de acordo com a arquitetura que compila sua aplicação e não a do SO) na mesma pasta do .EXE

Bom dia! Apenas fornecendo um retorno. Após uma análise aprofundada, foi constatado que o problema ocorre porque no momento de ler as notas do arquivo de retorno, para carregar elas na memória, é utilizado o numero do RPS primeiro e se não encontrar então usa o número da NFSe. No seu retorno, alguns arquivos vieram com o número do RPS vazio, por isso, na hora de carregar na memória, a lib entendia que essas notas eram uma mesma nota. Enviado ao SVN na Rev-34769 uma alteração visando corrigir este comportamento. Libs compiladas após o dia 07/08/2024 deverão englobar a alteração.

Você precisa buscar na sua rotina que alimenta o componente quantas vezes está usando o .New

Olá pessoal! No dia 07/08/2024, por volta das 08h35 começamos a receber em nosso Discord múltiplos relatos de membros com problemas ao tentar transmitir NF-e para a Sefaz de São Paulo. O erro que muitos relataram estar recebendo ao tentar realizar uma transmissão era: Conferindo no DownDetector, é possível observar que o volume de relatos de problema aumentou exponencialmente durante esse mesmo período: Alguns colegas relaram sucesso na emissão realizando um teste com um link de internet alternativo ou alterando o DNS. Uma dica que foi compartilhada é utilizar o comando: nslookup nfe.fazenda.sp.gov.br E ir testando qual DNS consegue comunicação.

Não é o número do DPS, é a quantidade de DPS adicionados. No seu código, antes de chamar o Emitir, veja qual é o valor de ACBrNFSeX.NotasFiscais.Count. O erro que recebeu, indica que está com um valor maior do que um e o máximo deve ser 1.

Bom dia! Muito obrigado! Realizando um teste com o componente, a rotina ValidarRegrasDeNegocio de fato acusou a rejeição 610, enquanto que o validador do RS aceitou a nota. Criada a #TK-5835 para análise do caso e parecer por parte da equipe de consultores.

Bom dia! Conforme mencionado anteriormente, estamos tendo dificuldades para reproduzir o problema nos exemplos que temos disponíveis. Por favor, se possível, disponibilize um produto mínimo víavel desenvolvido na sua linguagem para que possamos testar com ele. Nos e-mails, você disponibilizou os arquivos INI do cedente e do título, disponibilize também o seu arquivo ACBrLib.ini para que possamos realizar um teste usando as configurações exatas de impressão que está utilizando.

Bom dia! Este erro está relacionado a quantidade de DPS que você está enviando e não a quantidade de vezes que você faz o envio. Cada vez que você faz um ACBrNFSeX.NotasFiscais.New usando o componente nativo ou usa o comando CarregarINI do Monitor ou da Lib, é adicionado um novo DPS no lote. Para o Padrão Nacional, você deve enviar somente um DPS. Você pode deixar o modo de envio como meAutomatico também caso prefira, assim, você não precisa validar o provedor antes de fazer o envio, você só faz as devidas validações no momento de ler a resposta. O programa exemplo alimenta uma NFS-e com dados fictícios, se você está usando dados verídicos tanto na configuração do componente, quanto no momento de alimentar a NFSe, então precisamos de mais detalhes para entender melhor o problema.

Olá pessoal! No site da secretária do estado do Mato Grosso, consta uma NOTÍCIA informando que a Sefaz do Mato Grosso realizará no dia 10/08/2024 uma parada programada para atualização da versão do banco de dados utilizado. A manutenção está prevista para iniciar às 15h00 e ser concluída até às 22h00 do mesmo dia. Os ambientes autorizadores da NF-e, NFC-e e NF3-e já foram atualizados. A previsão é de que o ambiente autorizador do CT-e será afetado e durante este período a contingência SVC seja ativada. Para utilizar as soluções ACBr em contingência, siga as orientações deste tópico:

Olá pessoal. No dia 06/08, foi publicada uma notícia no portal do SPED orientando como deve ser feita a escrituração do PIS Cofins decorrente do Regime Especial da Industria Química (REIQ). Segue notícia na íntegra: Fonte original: http://sped.rfb.gov.br/pagina/show/7498 Lembrando que o preenchimento dos campos mencionados usando o ACBrSPEDPisCofins pode ser feito da seguinte forma: var RegF001: TRegistroF001; RegF010: TRegistroF010; RegF100: TRegistroF100; begin RegF001 := ACBrSPEDPisCofins.Bloco_F.RegistroF001New; //... RegF010 := RegF001.RegistroF010New; //... RegF100 := RegF010.RegistroF100New; RegF100.IND_OPER := RegF100.VL_OPER := RegF100.CST_PIS := RegF100.VL_BC_PIS := RegF100.ALIQ_PIS := RegF100.VL_PIS := RegF100.CST_COFINS := RegF100.VL_BC_COFINS := RegF100.ALIQ_COFINS := RegF100.VL_COFINS := RegF100.NAT_BC_CRED := end;

Boa tarde! Por favor, pode disponibilizar o XML que utilizou para análise? Se julgar que o mesmo tenha dados sensíveis e não possa ser disponibilizado direto aqui, envie para [email protected] com o link do tópico do fórum no corpo do e-mail para posterior identificação.

Boa tarde! Que bom que está conseguindo avançar. Acredito que você já esteja ciente disso, mas vale sempre reforçar: A rejeição de consumo indevido é um "castigo" com tempo definido de uma hora. Isso quer dizer que se você tiver tomado a rejeição de consumo indevido, por exemplo e consultar depois de 59 minutos. Mesmo que falte só 1 minuto para terminar o período de uma hora, por ter consultado antes, esse "castigo" vai renovar por mais uma hora. É importante que sua aplicação tenha um controle do ultNSU e do maxNSU. Quando você faz a consulta, ele sempre devolve o ultNSU que deve ser usado. Se você fez a consulta com o ultNSU do seu controle e recebeu uma rejeição de consumo indevido, é provável que haja consulta paralela.

Obrigado! Vamos analisar e reportamos assim que descobrirmos algo.