Skip to content

[IMP] paulistana: suporte parametrizado ao schema v02 (Reforma Tributária)#101

Draft
mileo wants to merge 1 commit into
masterfrom
imp-paulistana-versao-schema-v03
Draft

[IMP] paulistana: suporte parametrizado ao schema v02 (Reforma Tributária)#101
mileo wants to merge 1 commit into
masterfrom
imp-paulistana-versao-schema-v03

Conversation

@mileo

@mileo mileo commented Jul 3, 2026

Copy link
Copy Markdown
Member

Contexto

Alternativa complementar ao #94 (@CristianoMafraJunior / @Escodoo — obrigado pelo trabalho de base!) para levar o provedor Paulistana ao schema da Reforma Tributária 2026, resolvendo dois pontos levantados na revisão daquele PR:

  1. Migração em bloco: o [IMP] paulistana: reforma tributaria #94 troca v02v03 para tudo, o que impede consultar/cancelar notas do regime antigo (fato gerador até 31/12/2025) — caso real durante todo o ano de 2026.
  2. Bug latente na assinatura: o [IMP] paulistana: reforma tributaria #94 remove o .encode("ascii") antes do sign_pkcs1v15_sha1(rps.Assinatura); a cryptography exige bytes e o consumidor (l10n-brazil) entrega str, o que quebraria o envio em runtime.

O que muda

  • Novo registro VERSOES_SCHEMA no provedor, selecionando por versão: módulos de binding, URL do WS, Versao do cabeçalho e formato do campo de assinatura.
    • v02 (default): schema *_v01.xsd legado, nfe.prefeitura.sp.gov.br/ws/lotenfe.asmx, Versao=1comportamento atual 100% preservado.
    • v03: schema *_v02.xsd (bindings nfselib.paulistana.v03), nfews.prefeitura.sp.gov.br/lotenfe.asmx (Manual v3.3.7, mesmo endpoint do [IMP] paulistana: reforma tributaria #94), Versao=2.
  • _assina_paulistana() normaliza a assinatura do RPS e do cancelamento: aceita str ou bytes na entrada; devolve str base64 no v02 (binding exporta o campo como string) e bytes crus no v03 (tpAssinatura virou xs:base64Binary — o generateDS aplica o base64 no export; setar base64 manualmente geraria dupla codificação).
  • NFSeFactory(..., **kwargs): repassa kwargs ao provedor (versao_schema="v03"), sem quebrar os demais municípios.
  • Import do v03 é guardado por try/except próprio: com uma nfselib.paulistana antiga, só o v02 fica disponível e pedir v03 levanta ValueError explícito (em vez de desativar tudo silenciosamente).

Validação (local)

  • Instanciação nas duas versões: URL/operação/Versao corretos por ambiente (produção e TesteEnvioLoteRPS).
  • Assinatura com certificado fake (create_fake_certificate_file): v02 → str base64 válido; v03 → bytes (256), com entrada str ou bytes.
  • versao_schema inválida → ValueError com as versões disponíveis.

Relacionados

Pendências (fora do escopo)

  • Operações do serviço assíncrono (*Async) e guias — dependem do nfselib.paulistana#7.
  • Homologação real do endpoint nfews (o host segue o [IMP] paulistana: reforma tributaria #94/manual; falta confirmar em homologação com certificado real).

…ária)

Introduz VERSOES_SCHEMA no provedor Paulistana selecionando bindings,
URL e Versao do cabeçalho por versão de schema:

- v02 (default): schema *_v01.xsd legado, WS nfe.prefeitura.sp.gov.br,
  Versao=1 — comportamento atual inalterado, segue atendendo consulta e
  cancelamento de notas com fato gerador até 31/12/2025.
- v03: schema *_v02.xsd da Reforma Tributária (nfselib.paulistana.v03),
  WS nfews.prefeitura.sp.gov.br (Manual v3.3.7), Versao=2.

A assinatura do RPS/cancelamento é normalizada em _assina_paulistana():
aceita str ou bytes na entrada e devolve no formato que o binding da
versão espera — str base64 no v02 (tpAssinatura exportado como string)
e bytes crus no v03 (tpAssinatura é xs:base64Binary e o generateDS
aplica o base64 no export). Isso evita a assinatura dupla/inválida ao
migrar de versão.

NFSeFactory ganha **kwargs repassados ao provedor, permitindo
NFSeFactory(..., versao_schema='v03') sem quebrar os demais provedores.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant