cezar.sakugawa

que nada tentando atravez de email, em homologacão até consegui, o problema agora é em prod.

mas o xsd que esta na acbr não está em conformidade com o que esta no manual, vai precisar atualizar. Aqui esta o link que peguei no manual atualizado. https://www.notacontrol.com.br/download/nfse/schema_v101.xsd

Estou com mesmo problema em produção.

Precisa atualizar isso na proxima versao porque na minha que baixei a ACBrLibNFSe 2.1.0.274 está diferente

Estou com mesmo problema para o provedor Pronim para o município de Alegrete. P9021 - Erro ao desserializar: Erro de validação de instância: '3' não é um valor válido para TSTipoRetPISCofins. P9020 - Erro de validação do XML: O elemento 'http://www.sped.fazenda.gov.br/nfse:tpRetPisCofins' é inválido - O valor '3' é inválido dependendo do tipo de dados 'http://www.sped.fazenda.gov.br/nfse:TSTipoRetPISCofins' - Falha na restrição Enumeration.

Pessoal, mesmo problema por aqui.... alguma novidade? Atualizei a lib faz uns 30 min.

Está sendo preenchido o número mas mesmo assim continua nao montando no XML. [Tomador] CNPJCPF=***************** RazaoSocial=******************* Logradouro=Rua Dona Primitiva Vianco Numero=145 Complemento=nd Bairro=Centro CodigoMunicipio=3534401 xMunicipio=Osasco UF=SP CEP=06016004 Email=**********************

Em contato com a prefeitura de Osasco foi nos informado isso.

Osasco estamos com dois problemas um consegui resolver, 1. No tomador na tag Pais está tendo que enviar o nome pais quando nacional maisculo, caso contrario monta a tag TomadorEstrangeiro como true, e a nota rejeitada por a prefeitura tratar como tomador estrangeiro, e informacoes incoerentes enviadas. 2. Mesmo preenchendo todas as informacoes do tomador e prestador do serviço, no prestador nao esta enviando numero da residencia, nem complemento mesmo que opcional, quando informado nao monta a tag. 323426.xml xml_retorno.xml ACBRNFSe_132007563.ini

Estou com esse mesmo problema usando a LIB com Node.

Olá, Alguem vendo essa prefeitura/provedor?

Amigo usa o webservice antigo que funciona. No arquivo ACBrNFSeXServicosRTC.ini está apontando para o novo: [ISSNet] Params=APIPropria: Versao=1.01 [3543402] Nome=Ribeirao Preto UF=SP Provedor=ISSNet ProRecepcionar= HomRecepcionar= só usar o antigo ACBrNFSeXServicos.ini: [ISSNet] HomRecepcionar=https://abrasf.issnetonline.com.br/webserviceabrasf/homologacao/servicos.asmx [3543402] ; Atualizado em 27/02/2023 Nome=Ribeirao Preto UF=SP Provedor=ISSNet Versao=2.04 ProRecepcionar=https://nfse.issnetonline.com.br/abrasf204/ribeiraopreto/nfse.asmx HomRecepcionar=https://www.issnetonline.com.br/homologaabrasf/webservicenfse204/nfse.asmx

Alterei o INI de serviços para ficar dessa forma: [2609600] Nome=Olinda UF=PE Provedor=Tinus Versao=2.03 ProRecepcionar=https://www.tinus.com.br:443/csp/OLINDA/WSNFSE203.Service2.nfseSOAP.cls HomRecepcionar=https://www2.tinus.com.br/csp/TESTEOLI/WSNFSE203.Service2.nfseSOAP.cls Porém estou recebendo o erro: Erro1: { Codigo: 'X800', Correcao: '', Descricao: "Erro de Validação: Erro: Schema inválido --> 3064 - Element '{http://www.w3.org/2001/XMLSchema}import': The value of the attribute 'namespace' must not match the target namespace 'http://www.abrasf.org.br/nfse.xsd' of the importing schema." }, Atualizei a o acbrlib com a versão gerada nessa terça.

O municipio de OLINDA não aderiu ao padrão nacional, continua usando TINUS, porém o provedor desenvolveu um novo webservice baseado no padrão ABRASF 2.03 acrescentando as tags da RTC, segue URL: https://www.tinus.com.br:443/csp/OLINDA//WSNFSE203.Service2.nfseSOAP.cls @Daniel InfoCotidiano TINUS-NFS-e_Guia_Rapido_WS_RPSv3.pdf

Olá, Mesmo erro pra cidade de Olinda: Competência Inválida, a partir do dia 22 Dezembro de 2025, só é permitido a emissão de NFS-e Nacional Algum retorno?

Sim, pra voce ver faz o que comentei na minha primeira resposta. Acessa o site do ginfes como Prestador e vai no menu de emitir NFSe, tem um campo que lista os códigos possíveis, ai vc escolhe um de lá.

Enviei sem as tags do IBS/CBS, tá igual os XMLs de 2025, só alterando o conteudo do CodigoTributacaoMunicipio

O XML é de produção, contem dados sensiveis, vou precisar mascarar, mas como vc tá mandando o CodigoTributacaoMunicipio?

Pessoal, Consegui autorizar nota do GINFES em produção pra cidade de DIADEMA. O GINFES mudou o formato do campo CodigoTributacaoMunicipio, antes era XX.XX, agora passou a ser XX.XX.XX, precisa entrar no sitema do ginfes e logar como prestador e tentar emitir uma nota por lá, tem um campo que vai listar os códigos possíveis.

Olá, estou com o mesmo problema, essa tarefa já foi atendida?

Olá, A tarefa ACBr-8597 já foi concluída? Nao tenho solução de contorno por aqui, precisamos emitir NFSe pra Santos e Jundiai que são GISS também.

Sim @Diego Foliene, exatamente! Gostaria do retorno completo da API do padrão Nacional, assim como vocês já fazem na emissão. Eu não entendi o motivo do cancelamento ser diferente. Além disso, na emissão vocês tem um atributo no JSON de resposta do ACBR muito util que é o "Sucesso (true/false)", poderia ter também no cancelamento.

Bom dia @Italo Giurizzato Junior, Sim, mas não é esse exatamente o problema. o Problema é que além desse XML, a API do ambiente nacional retorna um json com outras informações, e o ACBR não está retornando a resposta completa, assim como já é feito no processo de emissão.

Olá bom dia! Poderiam me atualizar sobre essa questão por gentileza? Está em analise?

Bom dia Daniel, sim extamente o que comentei com vc. O bug inicial foi resolvido, mas o XmlRetorno está vindo apenas com o XML decodificado, quando o certo é a resposta completa da API do ambiente nacional, assim como ocorre no processo de emissão.