Diego Foliene

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.

Apenas dando um retorno. Analisando as informações disponíveis, nos parece que de fato o https://ws-jundiai.giss.com.br/service-ws/nf/nfse-ws?wsdl se refere a um web service diferente. No entanto, ao fazer os devidos ajustes e realizar alguns testes, recebemos alguns retornos um tanto estranhos, como por exemplo, ao fazer uma consulta de lote, recebemos como retorno: Mas de acordo com os próprios schemas disponibilizados, a consulta de lote, não possui assinatura. Outros retornos comuns, foram o de "Assinatura inválida" mesmo a assinatura estando em ordem de acordo com o validador da receita e também de arquivo em desacordo com os schemas, mesmo o arquivo passando pela validação que compara o XML com o .xsd. Por favor, você consegue entrar em contato com o provedor e solicitar um arquivo de envio de exemplo, para que possamos comparar com o arquivo gerado em busca de erros e fazer os ajustes necessários. Criada a #TK-5831 para tratar do caso.

Bom dia! Estou analisando as informações junto a equipe de consultores. Assim que descobrir algo, reportamos aqui.

Olá pessoal! No dia 01/08/2024 foi publicada Nota Técnica Nº 001 que trata da adequação da Nota Fiscal de Serviços Eletrônica no layout do Padrão Nacional buscando atender o proposto no PLP 68/2024. Alterações A nota técnica traz a inclusão das informações do IBSCBS através da adição múltiplos campos agrupados em seus respectivos subgrupos tanto no layout da Declaração de Prestação de Serviço (DPS), quanto na Nota Fiscal de Serviço Eletrônica(NFS-e). Novos grupos adicionados no DPS: NFSe/infNFSe/DPS/infDPS/IBSCBSSEL/dest : Grupo de informações relativas ao destinatário. NFSe/infNFSe/DPS/infDPS/IBSCBSSEL/adq: Grupo de informações relativas ao adquirente. NFSe/infNFSe/DPS/infDPS/IBSCBSSEL: Grupo de informações relativas ao serviço prestado para IBS, CBS e IS. NFSe/infNFSe/DPS/infDPS/IBSCBSSEL/valores: Grupo de informações relativas aos valores do serviço prestado para IBS, CBS e IS. NFSe/infNFSe/DPS/infDPS/IBSCBSSEL/valores/trib/gIBSCBS/IBSUF: Grupo de informações específicas relativas ao IBS estadual. NFSe/infNFSe/DPS/infDPS/IBSCBSSEL/valores/trib/gIBSCBS/gIBSMun: Grupo de informações específicas relativas ao IBS municipal. NFSe/infNFSe/DPS/infDPS/IBSCBSSEL/valores/trib/gIBSCBS/gCBS: Grupo de informações específicas relativas à CBS. Novos grupos adicionados na NFSe: NFSe/infNFSe/IBSCBSSEL: Grupo de Informações Comuns relativas ao IBS e a CBS. NFSe/infNFSe/IBSCBSSEL/IBSCBS/valores: Grupo de informações de valores brutos relativos ao IBS e a CBS. NFSe/infNFSe/IBSCBSSEL/totCIBSel: Grupos totalizadores. NFSe/infNFSe/IBSCBSSEL/totCIBSel/gSel: Grupo de informações relativas às totalizações do imposto seletivo. NFSe/infNFSe/IBSCBSSEL/totCIBSel/gIBS: Grupo de informações relativas às totalizações do IBS. NFSe/infNFSe/IBSCBSSEL/totCIBSel/gCBS: Grupo de informações relativas às totalizações do CBS. Datas Conforme consta na nota técnica, os contribuintes deverão se familiarizar e se adequar ao novo padrão que deverá vigorar a partir de Janeiro de 2026. E como fica o ACBr? Como a nota técnica adiciona novos campos ao layout, serão necessárias modificações nos fontes do ACBr para adequação. Para aqueles que utilizem o ACBrMonitor ou a Lib, uma nova compilação será necessária. Foi criado em nosso backlog a #TK-5828 para implementação. Qualquer novidade será divulgada neste tópico. Leia a Nota Técnica na íntegra AQUI.

Boa tarde! Abra o arquivo ACBrNFSeXServicos.ini e procure pela seção de Jundiai/SP [3525904] ; Atualizado em 03/01/2024 Nome=Jundiai UF=SP Provedor=Ginfes Params=NaoFormatarItemServicoSemZeroEsquerda: ProLinkURL=http://jundiai.ginfes.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null HomLinkURL=http://jundiai.ginfesh.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null Altere a seção Params de forma que fique assim: [3525904] ; Atualizado em 03/01/2024 Nome=Jundiai UF=SP Provedor=Ginfes Params=FormatarItemServicoNaoSeAplica: ProLinkURL=http://jundiai.ginfes.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null HomLinkURL=http://jundiai.ginfesh.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null Coloque o arquivo alterado dentro da pasta do .EXE, defina caminho + nome completo na propriedade IniServicos na seção [NFSe] e faça um novo teste. Veja se ele vai manter o ponto que você colocou. Vale citar que isso é uma orientação para que faça um teste e valide se o problema é de fato a falta do ponto da ItemListaServico. Pois atualmente a configuração é a NaoFormatarItemServicoSemZeroESquerda e a mesma é utilizada por outros membros.