apfsantos

Estou com dúvida sobre a diferença entre os modos de emissão de NFS-e utilizando Provedor->ProprioNacional e Provedor->ApiProprio, principalmente em relação à estrutura do XML, assinatura e envio. Pelo que entendi até agora: ApiProprio A comunicação é feita diretamente com o provedor da prefeitura (API própria). Nesse modelo, normalmente é enviado: infNFSe (nota já consolidada) e/ou infDPS (declaração prévia de serviços) O XML é: Montado Assinado digitalmente Enviado para o provedor municipal O provedor então processa e, quando aplicável, integra com a Receita. ProprioNacional Segue o padrão nacional da NFS-e (layout nacional unificado). Pelo que observei, nesse caso o envio parece focar mais no infDPS (Declaração de Prestação de Serviços). A dúvida principal está aqui: O XML a ser assinado é apenas o DPS? Existe envio de infNFSe nesse modelo ou a NFS-e é gerada posteriormente pela plataforma nacional? Como é feito o processo de: assinatura digital geração do XML final conversão para Base64 (quando necessário) Dúvidas principais Qual a diferença prática entre enviar infNFSe e infDPS em cada modelo? No ProprioNacional, o fluxo correto é: gerar DPS → assinar → enviar → receber NFS-e? A assinatura no padrão nacional é feita sobre qual estrutura exatamente (DPS completo ou outro grupo)? Em quais casos é necessário gerar o XML em Base64? Existe diferença no padrão de assinatura entre ApiProprio e ProprioNacional? Objetivo Entender corretamente: Qual XML deve ser gerado em cada modo O que deve ser assinado E como deve ser feito o fluxo correto de envio Se alguém tiver um exemplo prático (principalmente no padrão nacional), ajudaria bastante. Obrigado!

Tem como enviar modelo do xml que você envia assinado para Provedor=PadraoNacional? Porque tem diferença do modelo ApiProprio para PadraoNacional

Boa Tarde, Tem como mostrar ini que você configurou?

Bom dia, Tudo bem? Você conseguiu resolver?

Boa tarde, Pessoal enviei para Sil esse email abaixo com copia para Michel Abrão: O XML está conforme o schema da NFSe Nacional. O erro ocorre porque o atributo Id do elemento infNFSe não está sendo registrado como ID no DOM antes da validação da assinatura. Conforme o padrão XML-DSig, é necessário executar: element.setIdAttribute("Id", true); antes de validar a assinatura, pois o XSD da NFSe define o atributo Id como xs:string, e não xs:ID. Após análise técnica do XML enviado, verificou-se que a assinatura digital está corretamente formada e referencia o elemento: <Reference URI="#NFS3506003..."/> O elemento correspondente está presente no XML: <infNFSe Id="NFS3506003..."> Ocorre que, conforme o schema oficial da NFSe Nacional, o atributo Id do elemento infNFSe é definido como xs:string, e não como xs:ID. Dessa forma, para que a assinatura XML-DSig seja validada corretamente, o sistema validador deve registrar explicitamente esse atributo como ID no DOM, antes de validar a assinatura, conforme o padrão XML Digital Signature. Exemplo obrigatório em Java: Element infNFSe = (Element) doc .getElementsByTagNameNS("*", "infNFSe") .item(0); infNFSe.setIdAttribute("Id", true); Na ausência desse registro, o validador não consegue resolver o URI informado na assinatura, resultando no erro: Cannot resolve element with ID ... Portanto, o erro não está no XML assinado, mas sim na implementação do validador da assinatura digital no ambiente receptor. ->OK Esse texto é tecnicamente irrefutável -> OK Já resolve casos em várias prefeituras pode utilizar o validador da receita : https://validar.iti.gov.br/index.html Arquivo xml validado com sucesso no site da receita referente assinatura. segue xml em anexo para teste. 1.xml

[3530607] ; Atualizado em 05/07/2022 Nome=Mogi das Cruzes UF=SP Provedor=SilTecnologia ;Versao=2.03 ;ProRecepcionar=https://servicos.mogidascruzes.sp.gov.br/tbw/services/Abrasf23 ;HomRecepcionar=https://servicos.mogidascruzes.sp.gov.br/tbwhomologacao/services/Abrasf23 ; Descomentar as linhas abaixo para usar a API própria Versao=1.00 Params=APIPropria: ProRecepcionar=https://servicos.mogidascruzes.sp.gov.br/tbw/services/NotaFiscalNacional HomRecepcionar=https://servicos.mogidascruzes.sp.gov.br/tbwhomologacao/services/NotaFiscalNacional

Boa Tarde,Tudo Bem? A questão de calcular DV pela função do ACBR da mesmo resultado conforme o manual da SIl tecnologia. <return>Erro: Erro no script NFENotaFiscalNacionalWSSILGerar: Erro no script NFENotaFiscalWSXMLAssinaturaValidar: javax.xml.crypto.URIReferenceException: com.sun.org.apache.xml.internal.security.utils.resolver.ResourceResolverException: Cannot resolve element with ID NFS35060031221321107000101000000000144125124061244214</return> "NFS" 3506003 -> Cód.Mun. 1 -> Amb.Ger. 2 -> Tipo de Inscrição Federal 21321107000101 ->CNPJ/CPF 14 0000000001441 -> nNFSe (13) 2512 -> AnoMes Emis. da DPS (4) 406124421 -> Cód.Num. (9) 4 -> DV (1) Link do manual: https://docs.google.com/document/d/13Of-_DSc2BwFDP2io746VVI2oEvwmaDGysh5rz9YnLw/edit?tab=t.0 Realizando teste "Modulo11" pela função Acbr utilizando exemplo da Sil Tecnologia -> Exemplo: 12345 -> Dígito verificador final: 5 Obs: Realizei o teste para outra prefeitura essa parte passou normal acredito que é algo no servidor da SiL em Bauru homologação.

e o seu xml?

Pelo que estou analisando seria na parte do excel na aba "RN NFS-e - ADN"

resposta do email Sil Tecnologia: Bom dia, Prezados, O município em questão optou por Emissor Próprio e assim, o fluxo de emissão será: 1. Contribuinte envia a nota para a sistema da prefeitura (link disponibilizado abaixo). 2. Prefeitura recepciona a nota e valida as condições municipais - exemplo: atividade pertence a empresa, dedução permitida para a atividade, questões de isenção e imunidade. Se tiver algo inconsistente, retorna com a rejeição municipal para o Contribuinte e a nota não é emitida. 3. Caso não haja rejeição municipal (atividade não permita, dedução indevida e etc - por exemplo), a prefeitura compartilha a nota com o Emissor Nacional. Se o Nacional rejeitar alguma informação, retorna a rejeição para o Contribuinte e a nota não é emitida. 4. Se a prefeitura e o Emissor Nacional aceitaram o XML enviado, a nota é gerada com sucesso e será retornado a chave de acesso gerada pela receita (código numérico de 50 posições). Em resumo, o XML a ser enviado no padrão nacional precisa ser aceito tanto pelo municipio emissor, quanto pela receita ou a nota não será gerada. Não será aceito envio via arquivo TXT, sendo disponível apenas via WebService. Não será aceito envio assíncrono, sendo aceito apenas envio síncrono - envia uma nota e aguarda a resposta, não pode enviar e consultar a situação depois. Não será aceito envio em lote, sendo aceito envio de nota a nota - envia uma nota, aguarda a resposta, envia a proxima. A documentação e orientações do novo modelo NF Nacional estão disponíveis no link: https://interface.siltecnologia.com.br/apidocs/bauru/#tag/Nota-Fiscal-Nacional reposta Prefeitura: BOM DIA! Foi definido que Bauru adotará a utilização de EMISSOR PRÓPRIO, compartilhando os documentos fiscais eletrônicos gerados via API, com leiaute padronizado, com o Ambiente de Dados Nacional da NFS-e (ADN e SEFIN Nacional), conforme Seção V, artigo 62, inciso II parágrafo 1º, inciso I, da Lei Complementar nº 214 de 2025. A preferência pelo uso do EMISSOR PRÓPRIO se dá por diversos fatores, como: - A legislação tributária de Bauru possui diversas especificidades, hoje já abarcadas pela Nota Fiscal Municipal, que NÃO conseguem ser atendidas pelo Sistema Nacional; - O uso do Emissor Próprio permite que o município faça os lançamentos tributários diretamente em seu sistema com base na emissão/escrituração da DPS, não necessitando de retorno do Ambiente Nacional para que sejam efetuados. - Não há interesse no momento de utilizar o MAN – Módulo de Apuração Nacional. Os contribuintes deverão continuar recolhendo o imposto por meio de guia municipal; A Nota Fiscal do município, hoje de padrão ABRASF, deverá atender o leiaute oficial da Nota Fiscal de Serviço eletrônica – NFS-e padrão nacional, definido por meio das notas técnicas da Secretaria-Executiva do Comitê Gestor da Nota Fiscal de Serviço Eletrônica de Padrão Nacional (SE/CGNFS-e). A previsão para uso do novo layout é a partir de 01/01/2026. AS INFORMAÇÕES QUE CONSTAM NESTE E-MAIL NÃO SÃO CONSIDERADAS COMO CONSULTA TRIBUTÁRIA, SÃO DE CARÁTER GERAL E NÃO DE SITUAÇÃO ESPECÍFICA. Obs.: Em caso de resposta, manter diálogo anterior para facilitar a comunicação. Atenciosas saudações, NATHALIA DENISE – SERVIÇO DE ATENDIMENTO AO CONTRIBUINTE Prefeitura Municipal de Bauru – Secretaria Municipal da Fazenda NÃO TEMOS ATENDIMENTO PRESENCIAL Atendimento de 2º a 6º feira, das 08:00 às 17:00 h TELEFÔNICO: (14) 3235–1000. Escolher a opção 2 e depois a opção 1 WHATSAPP: (14) 3223–1514 E–MAIL: [email protected]

Bom dia Italo, Acredito que esta nesse arqivo aqui -> Para os contribuintes que utilizam o Webservice serão realizadas alterações de tela (interface) e layout para possibilitar a integração com o padrão nacional, conforme a documentação técnica constante no link AnexoIV-LeiautesRN_ADN-SNNFSe_V1.00.02-Produção.xlsx — Portal da Nota Fiscal de Serviço eletrônica.

Colocando no Datasource ShowScrollBar(DBCtrlGrid3.Handle,SB_HORZ,False); //Remove barra Horizontal ShowScrollBar(DBCtrlGrid3.Handle,SB_VERT,False); //Remove barra Vertical FormResize você controla conforme tamanho da tela diminui colCount ou RowCount do DbCtrgrid

Problema na falha na assinatura o AcbrNfse não esta gerando corretamente as tag do Prestador errado: <Prestador> <Cnpj>0000000000000</Cnpj> <InscricaoMunicipal>0000000</InscricaoMunicipal> </Prestador> correto: XMLNFE:=XMLNFE+'<Prestador>'; XMLNFE:=XMLNFE+'<CpfCnpj>'; <-AQUI XMLNFE:=XMLNFE+'<Cnpj>'+Documentodoprestadorformatado+'</Cnpj>'; XMLNFE:=XMLNFE+'</CpfCnpj>';<-AQUI XMLNFE:=XMLNFE+'<InscricaoMunicipal>'+edtIMPrestador.Text+'</InscricaoMunicipal>';<-AQUI XMLNFE:=XMLNFE+'</Prestador>'; Nesse caso da erro de Assinatura no retorno do webservice att.

Problema na falha na assinatura o AcbrNfse não esta gerando corretamente as tag do Prestador errado: <Prestador> <Cnpj>0000000000000</Cnpj> <InscricaoMunicipal>0000000</InscricaoMunicipal> </Prestador> correto: XMLNFE:=XMLNFE+'<Prestador>'; XMLNFE:=XMLNFE+'<CpfCnpj>'; <-AQUI XMLNFE:=XMLNFE+'<Cnpj>'+Documentodoprestadorformatado+'</Cnpj>'; XMLNFE:=XMLNFE+'</CpfCnpj>';<-AQUI XMLNFE:=XMLNFE+'<InscricaoMunicipal>'+edtIMPrestador.Text+'</InscricaoMunicipal>';<-AQUI XMLNFE:=XMLNFE+'</Prestador>'; att,

o Meu sistema esta homologado no dia 14 de junho....precisa abrir um processo de homologação neste link: http://sigipm.bauru.sp.gov.br/

nao precisa de certificado....

Pessoal desenvolvi do zero para nfs-e Bauru e já foi homologado pela prefeitura esta funcionando emissão,consulta e cancelamento. Qualquer coisa esta no skype amiltonbolacha....

Descobri a forma correta para cancelar a NFS-e conforme o layout Schemas do provedor GINFES segue em anexo o novo arquivo para Cancelamento. Testei no ambiente de homologação e produção para prefeitura de Jaú com sucesso. Por Favor Fazer teste e me avisar se esta ok. Qualquer duvida me avise! ACBrNFSeWebServices.pas

Para cancelar a NFS-E segue o link : viewtopic.php?f=6&t=4244