Milton Campanhã

Opa, boa tarde. Exato Juliomar, este foi justamente o motivo do tópico, pra saber se alguma outra pessoa que já integrou com GovDigital teria o manual e se passaram por este problema. De toda forma, solicitei ao cliente entrar em contato com a prefeitura e solicitar o manual para nos passar. At.

Olá, boa tarde. Estamos implantando NFSe para GovDigital em Guaxupé e estou com o seguinte retorno de erro. Código : GOV11 Mensagem: A data de prestação deve ser posterior à da última nota emitida. A tag <DataEmissao> é gerada pelo valor da DataEmissaoRps que seria data informada pelo usuário no cadastro de sua nota. E usamos assim em outros clientes com padrão ABRASF, sempre informando uma data "retroativa" como emissão, que seria a data real da prestação do serviço, sem problemas, mas nesta implantação da GovDigital retorna este erro de validação. Outros que já implementaram o GovDigital poderiam me orientar? Seria esta é uma regra apenas da GovDigital que não permite emissão retroativa? Obrigado. At. Milton

me desculpem, mas o fonte está realmente correto, e eu que não estava fazendo os devidos tratamentos do meu lado. Peço desculpas, mas podem encerrar este tópico!

Olá, boa noite. Estamos implementando NFSe com Belem/PA para provedor Siat e está com problemas na ConsultaLote logo após a emissão com sucesso. Verificando os fontes do svn notei esta correção, onde atribuiu a propriedade Protocolo o valor retornado no campo NumeroLote. E, em seguida, é montado o xml de consulta utilizando este Resume.Protocolo, que está com o valor do NumeroLote. Meu xml de retorno trouxe os seguintes valores: Numero do Lote: 660805 Numero do Prot: 25242654407 E o problema que vejo é que o NumeroLote é gerado pelo meu sistema, enquanto o Protocolo seria o "Lote" lá na prefeitura e seria por este Protocolo que eu deveria consultar. Penso que o problema está na linha 599, pois deveria capturar o Protocolo retornado e não o NumeroLote. Milton

Olá, boa noite. Estamos implantando emissão de NFSe para provedor GovDigital para município de Guaxupé/MG, e estava dando erro de Aliquota inválida. Notei que mesmo eu passando 2,5 o xml foi gerado com 0,0250 pois aplicou a regra do DivAliq100. function TNFSeW_ABRASFv2.GerarValores: TACBrXmlNode; var Aliquota: Double; begin Result := CreateElement('Valores'); [...] Aliquota := NormatizarAliquota(NFSe.Servico.Valores.Aliquota, DivAliq100); -> no caso está True mas o correto seria DivAliq100=False Para corrigir em minha implantação fiz o seguinte ajuste. [3128709] Nome=Guaxupe UF=MG Provedor=GovDigital Versao=2.00 Params=NaoDividir100: ProRecepcionar=https://ws.nfe-cidades.com.br/ws/guax HomRecepcionar=https://ws.homolog.nfe-cidades.com.br/ws/guax Mas deixo aberto o tópico para outros possam se manifestar, pois não tenho certeza se é algo específico de Guaxupé ou realmente o padrão do GovDigital. At.

Bom dia. Estou enviando correção para NFSeX do provedor Siat. Tive situações onde retornou o Sucesso=N mas não capturou o motivo do erro, pois não estava no padrão esperado de Codigo/Descricao. Segue exemplo: <RetornoConsultaLote xmlns:ns1="http://localhost:8080/WsNFe2/lote" xmlns:tipos="http://localhost:8080/WsNFe2/tp" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://localhost:8080/WsNFe2/lote http://localhost:8080/WsNFe2/xsd/RetornoErro.xsd "><Cabecalho><CodCidade>427</CodCidade><Sucesso>N</Sucesso><Versao>1</Versao><Erros><Erro>RPS_001_002: Sistema temporariamente bloqueado para novas requisições, aguarde pelo menos cinco minutos antes da próxima consulta/envio.</Erro></Erros></Cabecalho></RetornoConsultaLote> Segue alteração que eu fiz para contornar o problema. procedure TACBrNFSeProviderISSDSF.ProcessarMensagemErros( [..] ANodeArray := ANode.Childrens.FindAllAnyNs(AMessageTag); for I := Low(ANodeArray) to High(ANodeArray) do begin Codigo := ObterConteudoTag(ANodeArray[I].Childrens.FindAnyNs('Codigo'), tcStr); Descricao := ObterConteudoTag(ANodeArray[I].Childrens.FindAnyNs('Descricao'), tcStr); if Descricao = '' then begin Descricao := ANodeArray[I].AsString; end; Obrigado. ISSDSF.Provider.pas

Realmente seria bom anteciparmos algo, pois 2026 é logo alí.

@Italo Giurizzato Juniorme desculpe, somente hoje vi sua pergunta. Então, eu não sei te responder sobre o ambiente de homologação, pois a pressa foi tanta aqui que fizemos os testes em produção mesmo. Primeiros problemas (este deu trabalho descobrir) : Estava dando erro no envio e retornando except, e depois de debugar campo a campo descobrimos que o problema estava ao preencher/enviar a tag CNAE. Então parei de preencher este campo no xml. E ontem tivemos 2 problemas: 1) Tivemos notas rejeitas por conta de de validação do valor do ISS devido ao arredondamento. Estão usando o arredondamento para cima. 2) E um outro ponto foi que a prefeitura possui alíquotas de ISS com 4 casas decimais (Ex: 2,6135 ) mas o valor do ISS com apenas 2 ( e arredondando pra cima ). Abraços.

Recebemos esta orientação da Fiorilli. Embora eles sigam o padrão 2.01 eu consegui fazer a emissão normalmente usando o padrão 2.00 mas a única diferença foi realmente a questão do NaoAssinar. @Italo Giurizzato Junior por favor, poderia atualizar novamente o arquivo .ini ( e .res )? [3507506] ; Atualizado em 28/05/2024 Nome=Botucatu UF=SP Provedor=Fiorilli Versao=2.00 Params=Assinar:NaoAssinar ProRecepcionar=http://143.137.254.12:8089/IssWeb-ejb/IssWebWS/IssWebWS ProLinkURL=http://143.137.254.12:8089/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% -> Boa Tarde, segue o manual .. O ISSWeb, sistema de emissão de Notas Fiscais Eletrônicas de Prestação de Serviço (NFS-e), foi desenvolvido pela Fiorilli Software tendo como base o padrão de NFS-e da ABRASF (versão 2.01 e superiores). Esse sistema disponibiliza todos os serviços necessários para integração de outros sistemas com a Prefeitura Municipal através de web service e por meio do protocolo SOAP. Antes de colocar qualquer sistema em produção integrada com o ISSWeb utilizado pela Prefeitura Municipal, é necessário homologar essa integração com o ambiente de testes disponibilizado pela Fiorilli Software. Ou seja, o processo de homologação nunca poderá ser realizado diretamente no portal da Prefeitura. Para realizar esse teste de homologação, sempre será necessário realizar a assinatura digital de alguns métodos previstos na versão 2.01 do padrão ABRASF para NFS-e. Após adequar seu sistema com os padrões acima, solicitamos que entre em contato com suporte da empresa Amendola & Amendola Software, para informar alguns dados do proprietário do certificado digital que será utilizado na emissão das NFS-e para que possamos autorizar a realização dos testes no ambiente de homologação. É necessário informar os seguintes dados: 1. Razão Social do prestador de serviço; 2. CNPJ do prestador de serviço; 3. Endereço completo do prestador de serviço; 4. E-mail de contato do prestador se serviço. Quando receber a autorização para o uso do ambiente de teste para homologação, acesse os seguintes links: WebService: http://fi1.fiorilli.com.br:5663/IssWeb-ejb/IssWebWS/IssWebWS?wsdl Aplicação: http://fi1.fiorilli.com.br:5663/issweb/home.jsf Na realização dos testes para homologação, sempre devem ser informados os seguintes dados: 1. Usuário: 01001001000113 2. Senha: 123456 3. CNPJ do prestador: 01001001000113 4. Inscrição municipal do prestador: 15000 Observe que esses dados (usuário, senha, CNPJ e inscrição municipal do prestador) devem ser usados apenas para este momento de homologação. Para o momento posterior, de produção integrada desse sistema com o ISSWeb, é necessário utilizar os dados reais do próprio contribuinte que já foi autorizado pela Prefeitura Municipal a acessar o ISSWeb. A utilização errada dessas informações pode acarretar os seguintes erros: 1. Se forem utilizados os dados do próprio contribuinte (usuário, senha, CNPJ e inscrição municipal) no ambiente de teste para homologação, não será possível realizar os testes, pois os dados de nenhum contribuinte real estão cadastrados nesse ambiente; 2. Se forem utilizados os dados padrão para testes (usuário 01001001000113, senha 123456, CNPJ 01001001000113 e inscrição municipal 1.000.10) no ambiente de produção, as notas fiscais não serão geradas para o prestador de serviço correto e não serão armazenadas no site da Prefeitura Municipal. Faixa para Lote e RPS 18701 a 18800 Outras orientações importantes que devem ser observadas: 1. Utilizar Id, não id; 2. Tags devem ser assinadas de acordo com o serviço escolhido; 3. Os valores sempre devem ser informados com o padrão 0.00; 4. As alíquotas não precisam ser divididas por 100 (/100). Ou seja, devem ser informadas em números inteiros, como, por exemplo, 2.79 (e não 0,0279); 5. Utilize ponto ao invés de virgula como separador de casas decimais; 6. Utilize sempre duas (2) casas decimais; 7. Utilize “\s\n” para indicar quebra de linha; 8. Utilize lotes de, no máximo, 50 RPS (Recibos Provisórios de Serviços); 9. No caso de tomadores de serviços estrangeiros (localizados no exterior), deve ser utilizada a mesma estrutura. A única diferença é que deve ser informado, no campo CPF, um número de documento com 11 posições para que o sistema possa validar essa informação. Indicamos, ainda, alguns links úteis para o desenvolvimento da homologação e da produção: 1. Para fazer o download de toda a documentação disponibilizada pela ABRASF em relação ao padrão de NFS-e utilizado no ISSWeb: http://www.abrasf.org.br/pagina_simples.php?titulo=ARQUIVOS%20P%C3%9ABLICOS&pagina=arquivos_publicos 2. Utilitário disponibilizado pela Receita Federal do Brasil para validar a assinatura digital de documentos: https://www.receita.fazenda.gov.br/Aplicacoes/SSL/ATBHE/assinadoc/ValidadorAssinaturas.app/valida.aspx 2.1. Observe que, se o XML gerado pelo sistema não for considerado como válido por esse utilitário disponibiliza pela Receita Federal, esse mesmo arquivo também não será considerado válido no ISSWeb; 2.2. Não se esqueça de confrontar o xsd com o xml antes do envio para o ISSWeb. Caso o prestador de serviço não tenha a necessidade de envio em lote, aconselhamos que seja utilizado o serviço gerarNfse, que é o service mais rápido e possui o xml com menor tamanho. Enviamos, em anexo, algumas instruções, documentação e exemplos de xml assinados para integração com a Prefeitura Municipal. João Vitor Gonçalves Sistema Intregrado de Arrecadação – SIA Amendola & Amendola Sofware e-mail: [email protected]

@italogiurizzatojunior e @prog.marcosdario aqui ainda está com erro, mas agora o erro é este Erro de Conexão: soap:Server - javax.persistence.NonUniqueResultException: query did not return a unique result: 2 / Conforme o Gustavo já havia dito acima! Mas também estou considerando que possa ser algo lá na prefeitura. Estamos tentando contato com a prefeitura. Desculpa a demora em responder, mas eu estava em outra demanda pela manhã.

Aqui eu tive o mesmo erro quando enviando pelo modo Sincrono. Erro(s): Código : L4 Mensagem: Estrutura do xml recebido incorreta. javax.xml.bind.MarshalException - with linked exception:[org.xml.sax.SAXParseException; lineNumber: 0; columnNumber: 0; cvc-complex-type.2.4.d: Invalid content was found starting with element 'ns2:Signature'. No child element is expected at this point.]. Correção: Valide as tags do xml antes de enviar. Pelo que o Marcos Dário verificou a prefeitura não precisa que o xml seja assinado (Signature), mas eu não consegui configurar para que não seja assinado. Me desculpe, mas precisaria ajustar novamente para incluir o Params. Estou correto ou teria algum outro ajuste? [3507506] ; Atualizado em 23/05/2024 Nome=Botucatu UF=SP Provedor=Fiorilli Versao=2.00 Params=Assinar:NaoAssinar ProRecepcionar=http://143.137.254.12:8089/IssWeb-ejb/IssWebWS/IssWebWS ProLinkURL=http://143.137.254.12:8089/issweb/formGerarNF.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Obrigado.

Prefeitura de Botucatu - SP - Nº 24/2024 O município de Botucatu alterou o provedor para Fiorilli ( padrão Abrasf ) [3507506] ;Atualizado em 21/05/2024 Nome=Botucatu UF=SP Provedor=Fiorilli Versao=2.00 ProRecepcionar=http://143.137.254.12:8089/IssWeb-ejb/IssWebWS/IssWebWS HomRecepcionar=

Olá bom dia. Aqui estávamos com este problema, mas fizemos a atualização após a correção rev.32596 (22/02/24) e voltou a emitir normalmente. O erro ainda persistia na rev.32627?

Boa tarde. Por favor, poderia atualizar o componente ACBrNFSeX com o provedor para cidade de Macapá/AP, sendo: [1600303] ; Atualizado em 08/05/2023 ( testado por Wilson ) Nome=Macapa UF=AP Provedor=ISSNet Versao=2.04 ProRecepcionar=https://nfse.issnetonline.com.br/abrasf204/macapa/nfse.asmx HomRecepcionar=https://www.issnetonline.com.br/homologaabrasf/webservicenfse204/nfse.asmx Segue documentação da prefeitura: https://www.issnetonline.com.br/macapa/online/login/login.aspx?Getfile=14 Obrigado. Integração NFS-e Abrasf_Macapá.html

Boa tarde. Envio este para solicitar alteração no schema da Sigep para inclusão da tag "InscricaoEstadual" para Tomador. Fiz a alteração aqui e validei com meu cliente na prefeitura de Botucatu/SP, onde foi aceito a NFSe. https://botucatu.bsit-br.com.br/nfse/document-invoice-file.jsf -> Manual de Integração PDF ( pág. 3 ) Obrigado. Milton nfse.xsd IMPORTANTE.txt