Skip to content

feat(protocol): ativar contrato NT009 somente com versão, XSD e ambiente oficiais comprovados #121

Open
Open
feat(protocol): ativar contrato NT009 somente com versão, XSD e ambiente oficiais comprovados#121
Labels
area:fiscal

Description

@vitormattos
vitormattos
opened on Oct 12, 2026

Contexto / problema

A issue #95 entregou fontes, matriz, tooling e um preview estrutural NT009, não um emissor fiscal compatível com ambiente ativo. src/Xml/Nt009DpsPreviewBuilder.php, src/Dto/Nt009DpsPreview.php e docs/nt009.md proíbem explicitamente transmissão. src/Xml/DpsSchemaValidator.php ainda representa a versão de produção atualmente suportada. A aprovação da NT009 v1.01 em outubro de 2026 não comprova implantação imediata em todos os ambientes.

Contrato de ativação (hard gate)

  1. Confirmar oficialmente, com fonte e data por produção/produção restrita, o XSD efetivamente disponibilizado, checksum, regras de negócio, leiaute, versão técnica e data de ativação. A numeração do schema isolada não é suficiente.
  2. Auditar o novo pacote XSD contra a matriz e as tabelas já versionadas de Implement version-aware NT009 v1.01 DPS/IBSCBS contract #95: Anexo VI v1.04.01, Anexo VII v1.03.00, atenção a CST, cClassTrib, cIndOp, finNFSe, indDest, gIBSCBS e condições de presença. Consultas/correlações não viram obrigatoriedade sem suporte oficial.
  3. Somente após confirmação, implementar seleção explícita de contrato e ambiente no emissor, sem mudar em silêncio o NfseClient::emit(DpsData) atual. Fazer novo DTO/adaptação versionada ou estratégia de serialização apenas se diferenças reais justificarem; não transformar preview em emissor por simples alteração do tipo.
  4. Biblioteca só valida/serializa/assina/transmite conforme contrato; não calcula tributação empresarial nem adivinha alíquotas/CST.
  5. Garantir que protocolo selecione XSD e catálogos corretos por versão; validação local offline e proteção contra XXE. Identificar compatibilidade/capacidade do consumidor akaunting-nfse sem atualizar seu pin ou alterá-lo neste PR.
  6. Preservar bytes e interpretação do fluxo anterior para competências históricas. Regra legal por competência/empresa pertence ao módulo e não equivale à versão transportada.

Testes de aceitação

  • Evidência documental/endpoint oficial por ambiente e data de implantação; sem evidência, não habilitar emissão e registrar o bloqueio.
  • Contratos antigo e novo testados com XMLs sintéticos e XSD oficial aplicável (sucesso, ausência legítima, campo condicional, ordem, valores extremos, desconhecido), assinatura sintética e fake SEFIN.
  • XML de preview permanece não transmissível; uso incorreto recebe erro claro; teste garante que versão antiga não se altera.
  • Artefato de diagnóstico de migração para módulo demonstra mapeamento de campos e versão sem vazar PII.
  • PHPUnit/integração, composer domains:check, composer domains:contract-matrix, composer cs:check, composer psalm e CI de versões PHP aplicáveis passam. Homologação real é opt-in e não substitui testes determinísticos.
  • PR explica fonte, revisão oficial, checksum, ambiente, riscos e limites. Nada de XSD baixado em runtime, ganchos temporários em workflows ou documentação transitória.

Dependências e fronteiras

Conceitual: #95 (concluída, preservar preview). Para cálculo/seleção legal e onboarding: https://github.com/LibreCodeCoop/akaunting-nfse/issues/427, https://github.com/LibreCodeCoop/akaunting-nfse/issues/361. DANFSe: #118 (separado). NT007 retenções: PR #116 (integrar sem regressão). Não alterar o akaunting-nfse neste trabalho; downstream abre seu PR após contrato revisado.

Referências

Activity

  1. vitormattos commented on Oct 12, 2026

    @vitormattos
    vitormattos
    on Oct 12, 2026 – with ChatGPT Codex Connector
    MemberAuthor

    Auditoria do hard gate NT009 v1.01 — 12/10/2026

    Decisão: BLOQUEADO para novo contrato de emissão. Não transformar o preview de #95 em payload transmissível. Esta é uma conclusão sobre evidência insuficiente de compatibilidade e ativação, não a alegação de que a SEFIN necessariamente deixou de implantar algum componente.

    Evidência normativa e de implantação, por ambiente

    1. O Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria Executiva nº 7/2026, publicado em 01/10 e divulgado pelo Portal NFS-e em 09/10, aprova a NT009 v1.01. A página RTC lista o Anexo VI v1.04.01 e o Anexo VII v1.03.00. A própria NT009 diferencia o leiaute publicado do futuro Anexo I a ser identificado quando entrar em produção. Aprovação/publicação não implica XSD ativo em qualquer endpoint.
    2. Cronograma divulgado pelo próprio portal em imagem ligada ao comunicado: produção restrita: pacote 1 em 01/10/2026 e pacote 2 em 15/10/2026; produção: ambos em 03/11/2026. Em 12/10 o pacote 2 restrito e a produção ainda são futuros. Para o pacote 1, uma data anunciada não comprova, isoladamente, quais bytes XSD e regras estão efetivamente aceitos.
    3. As últimas fontes XSD com bytes e SHA-256 efetivamente verificados pelo monitor deste repositório são distintas: produção NFSe-ESQUEMAS_XSD-v1.01-20260209 (e7935cbd9470527c6cc32984c1b2263e614183bf0139ce2733eaaed2de9a8072); produção restrita NFSe-ESQUEMAS_XSD-PRODREST-v1.01-20260727 (6c7e0510d3ecff4454f291f4e10b742d27a4818f23aab181494f96d0ea79f3dc). Não há comprovação de que esses pacotes sejam o XSD efetivo da NT009 v1.01. Versão numérica 1.01 compartilhada não prova equivalência de leiaute.
    4. Execução existente do monitor de fontes oficiais em 09/10/2026, 16:16 UTC: run #37957883390, job check-published-files, saída new_versions: [], oito fontes unchanged (inclusive ambos os XSD e anexos VI/VII). Esse resultado prova integridade/disponibilidade dos URLs monitorados na ocasião, não ausência universal de novo pacote ou implantação; o comunicado governamental veio depois naquele dia. Em 12/10, as páginas dos índices oficiais foram acessadas diretamente via consulta web: produção continua listando somente NFSe-ESQUEMAS_XSD-v1.01-20260209 (página atualizada em 15/08/2026) e produção restrita somente NFSe-ESQUEMAS_XSD-PRODREST-v1.01-20260727 (página atualizada em 28/07/2026). Essa inspeção de índices é independente do monitor de hashes de 09/10; não comprova, por si só, que não há pacote novo disponibilizado em outra URL ou implantado internamente.
    5. Há ainda divergência material a resolver antes de proclamar conformidade: a NT009 v1.01, seção 2.2, mostra gIBSCBSAjuste em .../IBSCBS/valores/trib/gIBSCBSAjuste; a matriz derivada do Anexo VI v1.04.01, linhas 428–430, coloca o grupo em .../trib/gIBSCBS/gIBSCBSAjuste. É preciso confrontar o XSD efetivo e eventual esclarecimento oficial, não escolher uma posição por preferência do código. A NT009 PDF ainda cita o Anexo VII v1.02.01, enquanto a página oficial RTC e o anúncio de 09/10 listam v1.03.00: registrar proveniência/data, não misturar versões.

    Fontes oficiais: publicação do ato + cronograma, NT009 v1.01 PDF, RTC, índice de produção, índice de produção restrita, cronograma de implantação.

    Código e fronteiras revisados

    • src/Http/NfseClient.php::emit(DpsData) chama somente XmlBuilder::buildDps, assinatura e POST legado; não aceita Nt009DpsPreview como parâmetro. src/Xml/XmlBuilder.php mantém DPS versao=1.01; src/Xml/DpsSchemaValidator.php reconhece apenas o pacote antigo, sem validação falsamente anunciada para NT009. A proteção existente é tipagem do método + API de preview separada, não um emissor NT009 pronto.
    • XmlBuilder::previewNt009Dps / Nt009DpsPreviewBuilder / Nt009DpsPreview permanecem review-only. 64 testes em Nt009DpsPreviewBuilderTest cobrem regras de presença, ordem, condicionais e dados extremos; testLegacyEmissionOutputIsNotModifiedByPreview preserva resultado anterior, e testValidDebitoAdjustmentEmitsConditionalNestedValues confirma que preview não valida no XSD de produção antigo. Nenhum desses testes comprova aceite SEFIN no esquema novo.
    • OfficialDomainCatalog mantém Anexo C antigo como padrão e Anexo VII v1.03.00 como escolha explícita; há matriz rastreável em resources/contracts/nt009-dps-v1.04.01-matrix.tsv, fontes/checksums em resources/domains/sources.json e política estável em docs/nt009.md. Não duplicar tooling de Implement version-aware NT009 v1.01 DPS/IBSCBS contract #95 nem adicionar diário de auditoria ao repositório.
    • Consumidor akaunting-nfse/3rdparty/composer.json fixa dev-main#60c4fad793c6562820e36085eeb8dab2c0f68b1f; nenhuma alteração de pin é necessária ou autorizada neste trabalho. Regime/operação/competência/obrigações fiscais seguem em akaunting-nfse#427/#361, DANFSe em #118/#119/#120 e NT007/retenções em PR #116. Nada foi modificado nesses escopos.

    Testes/CI e revisão de commits

    Condições objetivas para destravar

    1. Obter URL oficial, identificação do pacote, bytes XSD, SHA-256 observado, regras aplicáveis e confirmação para cada ambiente/pacote com data de ativação; confrontar índices, anúncios e endpoint/documentação oficial. Checar formalmente a divergência de gIBSCBSAjuste.
    2. Reproduzir matriz Anexos I/VI e VII com tooling versionado; aplicar XSD oficial efetivo offline em fixtures sintéticas, confrontando ausência legítima, zero real, ordem, condicionais, códigos inválidos e limites. Separar contrato transportado de competência/legalidade fiscal.
    3. Só então propor novo emissor explicitamente versionado e selecionado por ambiente, mantendo emit(DpsData) e seus bytes inalterados; provar assinatura sintética, fake SEFIN, erro claro para preview não transmissível e recuperação de resposta ambígua. Rodar verificações Composer e CI em branch revisável, revisão DCO/GPG e migração downstream sem alterar o consumidor aqui.

    Estado proposto: #121 permanece aberta, bloqueada por comprovação oficial do XSD/ativação, não por falta de implementação de um preview.

    Ampliação da pesquisa de fonte primária — verificação direta em 12/10/2026

    Cronograma oficial reproduzido: a notícia de 09/10 inclui imagem cronograma-nt-009.jpg com três marcos detalhados:

    Divergências de versionamento confirmadas visualmente entre documentos primários:

    Documento Anexo VI Anexo VII
    Ato Técnico Conjunto nº 7, art. 1º, I, 'a' 1.04 1.02
    NT009 v1.01 PDF, introdução 1.04.01 1.02.01
    Índice RTC (02/10) e notícia oficial (09/10) 1.04.01 1.03.00

    O ato tem efeitos jurídicos na data de publicação (art. 2º), não estabelece por si só a implantação de XSD/SEFIN. Não foi localizada retificação expressa que equipare as três numerações. Evitar tanto afirmar que a versão 1.03.00 é inválida quanto presumir aprovação formal de cada revisão; requer confirmação oficial se houver impacto na regra aplicada.
    Fontes: https://www.gov.br/receitafederal/pt-br/acesso-a-informacao/acoes-e-programas/programas-e-atividades/reforma-tributaria-do-consumo/legislacao/atos-tecnicos-conjuntos/ato-tecnico-conjunto-rfb-cgibs-no-7-de-28-de-setembro-de-2026 ; https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc/nota-tecnica-009-se-cgnfs-e-v-1-01.pdf ; https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc

    Condições fiscais documentadas que não podem virar validação global infundada: a NT009 §2.16 vincula gIBSCBS e cIndOp ao atributo oficial ind_gIBSCBS do CST/cClassTrib, com atenção aos CST 400/410/820; o Anexo VIII é expressamente consultivo. A NT009 §2.2 afirma que certas regras para notas de ajuste no workbook estão tachadas por ainda estarem em evolução. O caminho de gIBSCBSAjuste no PDF diverge da matriz do Anexo VI (linhas 428–430), portanto o preview segue sem homologação de hierarquia. Separar regras estruturais de obrigações fiscais por contribuinte/competência.
    Referência: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/rtc/nota-tecnica-009-se-cgnfs-e-v-1-01.pdf (páginas 4, 21–23).

    Limite da documentação do preview: no checkout 60c4fad793c6562820e36085eeb8dab2c0f68b1f, Nt009DpsPreviewData é deliberadamente incompleto em relação a todos os campos previstos pela NT009 (ex.: serv/comExt e novo serv/atvEvento/cMun não têm DTO/builder dedicated no preview), embora tenha outras estruturas NT009 para comparação. Uma suíte verde do preview, por si só, não demonstra aderência integral à NT009/Anexo VI. Verificar diferenças reais e escopo dos pacotes ao obter XSD efetivo, em vez de reaproveitar o preview como emissor.

    Verificação dos endpoints de documentação de SEFIN: a listagem oficial de APIs publica links Swagger específicos para produção restrita e produção, mas a tentativa de consulta pública GET das respectivas páginas .../docs/index retornou erro de gateway 502 na ferramenta web; não se usou certificado ou POST. O erro de consulta não é prova de indisponibilidade do serviço fiscal.
    Fonte: https://www.gov.br/nfse/pt-br/biblioteca/documentacao-tecnica/apis-prod-restrita-e-producao

    Comprovação complementar de homologação e canal oficial de esclarecimento — 12/10

    • O Comitê Gestor publicou em 09/10 que realizou testes e homologação presencial entre 05 e 09/10 no Serpro, envolvendo indDest/dest, regra 17.05, validações de endereço, atvEvento/cMun, Nota do Tomador, retenção ISS e APIs. Esta é evidência oficial de atividade de homologação técnica, não de resultado de aceite público para a biblioteca nem publicação de novo pacote XSD por ambiente. No comunicado não aparecem hash, contrato XSD efetivo, erros/aceitações da SEFIN ou autorização de emitir XML completo.
    • O portal publicou em 16/09 um Perguntas e Respostas, versão 1.00 datada de 08/09; por ser anterior à aprovação NT009 v1.01 de outubro, não constitui comprovação de ativação ou resolução de divergências específicas de outubro. O portal informa que esse documento foi elaborado com auxílio de IA, o que reforça a necessidade de priorizar atos, XSD e documentação oficial.
    • Canais de Atendimento, atualizado 16/09/2026, diz expressamente que atendimento.nfs-e@rfb.gov.br está desativado e orienta contribuintes a procurar a prefeitura; a prefeitura, caso necessário, consulta a RFB. Portanto, não recomendar enviar esclarecimento para o e-mail desativado, ainda que a página RTC antiga o mencione ao lado de municipios.nfs-e@rfb.gov.br para sugestões sobre o Anexo VIII. Para a ambiguidade de XSD/versão, encaminhar questionamento formal pelo canal municipal/institucional adequado, registrando pergunta, ambiente, pacote e data; não confundir sugestões do Anexo VIII com autorização de emissão.

    Conclusão mantida: evidência suficiente para localizar o ato, anexo, cronograma e os dois pacotes XSD anteriores; insuficiente para pacote XSD NT009 efetivo, regra de coexistência por pacote/ambiente, aceitação da SEFIN e resolução oficial das contradições. Permanecer com emissor antigo e preview não transmissível; nenhum novo contrato implementado.

  2. vitormattos commented on Oct 12, 2026

    @vitormattos
    vitormattos
    on Oct 12, 2026 – with ChatGPT Codex Connector
    MemberAuthor

    Complemento da auditoria normativa — 12/10/2026

    Informe Técnico 2025.002 e obrigatoriedade condicional de IBS/CBS

    A seção 2.16 da NT009 v1.01 referencia o Informe Técnico 2025.002 v1.60 para o indicador ind_gIBSCBS, que determina a presença condicional de cIndOp e gIBSCBS, especialmente nas hipóteses dos CST 400, 410 e 820.

    O Ato Técnico Conjunto RFB/CGIBS nº 8/2026 aprova o Informe Técnico 2025.002 v1.70 expressamente no conjunto documental de NF-e/NFC-e. Isso não comprova substituição automática do referencial da NFS-e.

    Antes de criar regras de emissão, confirmar a tabela efetivamente aplicável à NFS-e, sua vigência e a versão dos atributos de CST/cClassTrib. Não derivar ind_gIBSCBS de códigos, descrições ou correlações consultivas sem suporte oficial.

    Divergências documentais ainda não resolvidas

    • Anexo VII: Ato nº 7 menciona v1.02; PDF da NT009 menciona v1.02.01; índice RTC publica v1.03.00. A versão publicada pode ser usada como referência estrutural do preview, mas não determina, sozinha, o catálogo aceito pela SEFIN.
    • gIBSCBSAjuste: o PDF da NT009 apresenta o grupo diretamente em IBSCBS/valores/trib; o Anexo VI v1.04.01 o apresenta em IBSCBS/valores/trib/gIBSCBS. O preview existente segue o Anexo VI. A hierarquia definitiva precisa ser confrontada com o XSD efetivo.
    • A NT009 informa que algumas regras de notas de ajuste foram mantidas tachadas por ainda estarem em evolução. Não convertê-las em validações definitivas.

    Condição para retomar a implementação

    Os índices oficiais continuam listando o XSD de produção de 09/02/2026 e o de produção restrita de 27/07/2026. Nenhum novo XSD NT009 integral foi identificado nesses índices até esta verificação.

    Retomar a implementação somente após identificar, por ambiente e pacote, o XSD oficial efetivo, sua data de implantação, origem, integridade e regras aceitas. Confrontar os novos arquivos com a matriz da #95; depois executar testes sintéticos de serialização, validação XSD offline, assinatura, fake SEFIN e recuperação.

    Preservar NfseClient::emit(DpsData), o preview não transmissível, a emissão histórica e o pin atual do Akaunting até existir contrato verificável. Não reutilizar o XSD da NFS-e Via como substituto do contrato da NFS-e Nacional.

    Fontes primárias

    Estado: bloqueio externo documentado. Não há evidência suficiente para ativar o novo contrato. Nenhuma alteração de código ou emissão fiscal foi realizada.

  3. vitormattos
    added
    area:fiscal
    on Oct 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:fiscal

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions