Skip to content

fix(rtc): adiciona switch-cases dos 7 eventos NT 2025.002-RTC em ServicosNFe#78

Open
john182 wants to merge 7 commits intomasterfrom
fix/rtc-events-soap-client-and-version-switch
Open

fix(rtc): adiciona switch-cases dos 7 eventos NT 2025.002-RTC em ServicosNFe#78
john182 wants to merge 7 commits intomasterfrom
fix/rtc-events-soap-client-and-version-switch

Conversation

@john182
Copy link
Copy Markdown

@john182 john182 commented May 1, 2026

Problema

Os 7 métodos públicos da NT 2025.002-RTC foram adicionados em PRs anteriores (#76 e relacionados) à classe `NFe.Servicos.ServicosNFe` mas dois switches internos nunca foram atualizados, deixando todos os 7 serviços efetivamente quebrados em runtime.

# Método Estado pré-fix
110001 `RecepcaoEventoCancelamentoDeEvento` ❌ Throw
112110 `RecepcaoEventoInformacaoDeEfetivoPagamentoIntegralParaLiberarCreditoPresumidoDoAdquirente` ❌ Throw
112120 `RecepcaoEventoImportacaoEmAlcZfmNaoConvertidaEmIsencao` ❌ Throw
112130 `RecepcaoEventoPerecimentoPerdaRouboOuFurtoDuranteOTransporteContratadoPeloFornecedor` ❌ Throw
112140 `RecepcaoEventoFornecimentoNaoRealizadoComPagamentoAntecipado` ❌ Throw
112150 `RecepcaoEventoAtualizacaoDaDataDePrevisaoDeEntrega` ❌ Throw
211120 `RecepcaoEventoDestinacaoDeItemParaConsumoPessoal` ❌ Throw

Reprodução

```csharp
var config = new ConfiguracaoServico {
cUF = Estado.SP,
VersaoRecepcaoEventosDeApuracaoDoIbsECbs = VersaoServico.Versao100,
// resto padrão
};
var svc = new ServicosNFe(config, certificate);

await svc.RecepcaoEventoAtualizacaoDaDataDePrevisaoDeEntrega(
idLote: 1, sequenciaEvento: 1, cpfCnpj: "...",
chaveNFe: "...", dataPrevistaEntrega: DateTime.UtcNow.AddDays(7));
```

→ `System.ArgumentOutOfRangeException: ... (Parameter 'servicoEvento')` (ou `NullReferenceException` em `ws.nfeCabecMsg` para outros métodos do conjunto).

Causa raiz

Dois switches em `NFe.Servicos/ServicosNFe.cs` só conhecem os 4 eventos antigos (CC-e, Cancelmento, EPEC, Manifestação Destinatário). Os 7 NT-RTC caem em `default`:

1. `CriarServico(ServicoNFe servico)` (~linha 173) — retorna `null` no `default`, causando NRE em `ws.nfeCabecMsg` no caller.

2. `EnviarEObterRetornoRecepcaoEvento` switch versaoEvento (~linha 706) — lança `ArgumentOutOfRangeException` no `default`.

A property `VersaoRecepcaoEventosDeApuracaoDoIbsECbs` já existe em `ConfiguracaoServico` (linha 547) — só não estava sendo consultada por nenhum switch.

Fix

Adiciona os 7 cases agrupados nos 2 switches:

  • `CriarServico` retorna `new RecepcaoEvento4(...)` (SVRS reusa o mesmo SOAP endpoint do CC-e v4 — muda apenas a URL, já provida por `obterUrl(_cFgServico, servico)`, e o payload via XSDs novos).
  • Switch `versaoEvento` mapeia para `_cFgServico.VersaoRecepcaoEventosDeApuracaoDoIbsECbs`.

Impacto

Bloqueador para qualquer emitente NT 2025.002-RTC. Sem este fix, nenhum dos 7 serviços funciona — explode antes de chegar ao SVRS.

Validação

  • `dotnet build NFe.Servicos/NFe.Servicos.csproj` → 0 erros
  • Testado end-to-end no consumer (dfetech-product-invoice-api) usando esta branch via submódulo: chamada `RecepcaoEventoAtualizacaoDaDataDePrevisaoDeEntrega` chega ao SVRS sem exception. Resultado real (cStat) depende do certificado/ambiente do tenant.

Observação

`nfe/DFe.NET` tem issues desabilitadas, então não há issue vinculada. Reviewer pode tratar este PR como o registro completo do bug + fix.

Test plan

  • Build verde
  • Smoke test no consumer (chamada agora chega ao SVRS sem exception)
  • Validação contra SVRS homologação real depende do reviewer ter ambiente

JohnVanderson added 3 commits April 30, 2026 22:29
…icosNFe

Os métodos públicos `RecepcaoEventoCancelamentoDeEvento`,
`RecepcaoEventoImportacaoEmAlcZfmNaoConvertidaEmIsencao`,
`RecepcaoEventoPerecimentoPerdaRouboOuFurtoDuranteOTransporteContratadoPeloFornecedor`,
`RecepcaoEventoFornecimentoNaoRealizadoComPagamentoAntecipado`,
`RecepcaoEventoAtualizacaoDaDataDePrevisaoDeEntrega`,
`RecepcaoEventoDestinacaoDeItemParaConsumoPessoal` e
`RecepcaoEventoInformacaoDeEfetivoPagamentoIntegralParaLiberarCreditoPresumidoDoAdquirente`
foram adicionados em PRs anteriores e a property
`VersaoRecepcaoEventosDeApuracaoDoIbsECbs` em `ConfiguracaoServico`
existe — mas dois switches internos não foram atualizados, deixando
os 7 serviços efetivamente quebrados:

1. `CriarServico(ServicoNFe)`: cai no `default => return null`,
   causando NullReferenceException em `ws.nfeCabecMsg`.
2. `EnviarEObterRetornoRecepcaoEvento` (switch versaoEvento):
   cai no `default => throw new ArgumentOutOfRangeException`.

Este commit adiciona os 7 cases nos dois switches:
- `CriarServico` retorna `RecepcaoEvento4` (mesmo SOAP client do
  CC-e v4 — SVRS reusa o endpoint, muda apenas a URL e o payload).
- Switch versaoEvento mapeia para
  `_cFgServico.VersaoRecepcaoEventosDeApuracaoDoIbsECbs`.

Sem esses cases, qualquer chamada aos 7 métodos públicos lança
exception antes de chegar ao SVRS — bug crítico para qualquer
emitente que precisa registrar eventos da NT 2025.002-RTC.

Build: 0 erros.
… com upstream)

Os 17 cases dos eventos RTC no Validador.ObterArquivoSchema retornavam
hardcoded o XSD interno (e.g. e112150_v1.00.xsd), que define apenas
<detEvento>. Quando o RecepcaoEventoAsync chama Validador.Valida com
loteNfe=true (default) para validar o XML <envEvento>, o XmlSchemaSet
falha com 'envEvento element is not declared' porque o schema interno
nao tem esse root.

Pattern corrigido (ja presente em ZeusAutomacao/DFe.NET master):
loteNfe ? envEvento_v1.00.xsd : eXXXXXX_v1.00.xsd

- envEvento_v1.00.xsd valida o envelope; detEvento interno e xs:any
  (validacao frouxa local — SEFAZ valida server-side).
- O schema especifico continua disponivel quando o caller passa
  loteNfe=false explicitamente.

Validacao: dotnet build NFe.Servicos verde.
O setter de detEvento.cOrgaoAutor sobrescrevia descEvento para 'EPEC'
toda vez que era atribuido, quebrando todos os eventos NT 2025.002-RTC
que tambem usam cOrgaoAutor mas precisam de descEvento especifico
(e.g. 'Atualizacao da Data de Previsao de Entrega' para tpEvento=112150).

SEFAZ rejeitava com cStat 493 (Evento nao atende o Schema XML
especifico do detEvento.descEvento) porque o XML chegava com
<descEvento>EPEC</descEvento> em vez do valor correto do enum.

Alinhamento com upstream ZeusAutomacao/DFe.NET master:
- detEvento.cOrgaoAutor vira auto-property simples (sem side-effect).
- ServicosNFe.RecepcaoEventoEpecAsync seta descEvento explicitamente
  via NFeTipoEvento.TeNfceEpec.Descricao() para preservar comportamento
  do EPEC original.

Os eventos NT-RTC ja setam descEvento via Descricao() em
ObterDetalhesEvento — esse valor agora e preservado.

Validacao: dotnet build NFe.Servicos verde.
@john182 john182 force-pushed the fix/rtc-events-soap-client-and-version-switch branch from b780d7a to f9c3937 Compare May 1, 2026 12:43
…nome correto

Dois bugs descobertos no smoke-test do evento 211120 (Destinacao de
Item para Consumo Pessoal) — SEFAZ rejeitou com cStat 587 (namespace).

1. gConsumo.cs construtor: forcava
   _serializarValorIbsECbsComoAtributo = true para
   TeNfeDestinacaoDeItemParaConsumoPessoal. Mas o XSD e211120 declara
   <vIBS>/<vCBS> como ELEMENTOS, nao atributos. Idem e112120 (AlcZfm).
   Flag agora fica false sempre — XSD nunca espera atributo apesar do
   nome _serializarValorIbsECbsComoAtributo sugerir.

2. DFeReferenciado.cs: property nItemDFeRef serializava como
   <nItemDFeRef> mas XSD declara <nItem>. Adicionado
   [XmlElement("nItem")] para corrigir o XML output sem renomear o
   property C# (que conflitaria com nItem do gConsumo pai).

Smoke test: tpEvento=211120 chegou no SVRS com cStat 587. Apos fix,
deve aceitar com cStat 135.

Build: 0 erros.
@john182 john182 force-pushed the fix/rtc-events-soap-client-and-version-switch branch from 620cc61 to 9f734e7 Compare May 1, 2026 14:18
JohnVanderson added 3 commits May 1, 2026 11:43
XSD e110001_v1.00 declara apenas: descEvento, cOrgaoAutor, verAplic,
tpEventoAut, nProtEvento. Fork tinha dois bugs:

1. detEvento.cs nao expunha nProtEvento (so nProt). RecepcaoEventoCancelamento
   gravava o protocolo no campo errado, gerando XML com <nProt> em vez de
   <nProtEvento>.

2. RecepcaoEventoCancelamentoDeEvento usava o helper ObterDetalhesEvento
   que injeta tpAutor (1=Empresa Emitente) — campo nao declarado no XSD
   110001 — alem de tpAutor sair fora da ordem do schema.

Fix:
- detEvento.cs: adicionado nProtEvento (P22 do XSD).
- ServicosNFe.cs: cancel handler agora monta detEvento direto via
  new detEvento { ... } como upstream ZeusAutomacao/DFe.NET master,
  sem passar por ObterDetalhesEvento. Resultado e identico ao XSD.

Validado contra schemas/e110001_v1.00.xsd. Smoke test SVRS homologacao
passa de cStat=999 (erro nao catalogado) para cStat=135.
XmlSerializer respeita ordem de declaracao das properties. Quando
nProtEvento foi adicionado logo apos nProt/xJust (inicio da classe),
o XML gerava:
  descEvento -> nProtEvento -> cOrgaoAutor -> verAplic -> tpEventoAut
SVRS rejeitava com cStat=493 (Elemento detEvento/nProtEvento fora de
ordem segundo XSD e110001_v1.00).

XSD exige:
  descEvento -> cOrgaoAutor -> verAplic -> tpEventoAut -> nProtEvento

Alinhado com upstream ZeusAutomacao/DFe.NET master, que declara
nProtEvento logo apos tpEventoAut na #region Cancelamento Evento.
…erges futuros

Reescreve detEvento.cs usando upstream ZeusAutomacao/DFe.NET master como
base. Mantem mesmas #regions, mesma ordem de declaracao das properties,
mesmos atributos (incluindo [XmlRoot]/[XmlType] no namespace nfe).

Alinhar agora reduz drasticamente conflitos quando o fork puxar futuras
mudancas do upstream (ex: novos eventos pos-NT 2025.002-RTC).

Divergencias intencionais documentadas no header do arquivo:
1. `dest` property continua tipada como detEventoDest (upstream usa
   classe `dest`). ServicosNFe.cs handlers EPEC instanciam detEventoDest
   diretamente — trocar quebraria build sem refactor coordenado.
2. Region "Averbacao para Exportacao" omitida — classe itensAverbados
   nao existe neste fork.
3. Region "Conciliacao Financeira" omitida — classe detPagEvento nao
   existe neste fork.

Properties novas trazidas do upstream sao auto-properties dormentes
(nao serializam quando null/default), garantindo que nenhum fluxo
existente muda comportamento. Validado via:
- dotnet build NFe.Servicos -> 0 erros
- dotnet build DFeTech.ProductInvoice.sln -> 0 erros

XML serializado para os eventos ja validados (CC-e, EPEC, RTC 112110-150,
PersonalUseAllocation, AlcZfmImport) continua identico — ordem das
properties EPEC/Cancelamento/RTC nao mudou.
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