fix(rtc): adiciona switch-cases dos 7 eventos NT 2025.002-RTC em ServicosNFe#78
Open
fix(rtc): adiciona switch-cases dos 7 eventos NT 2025.002-RTC em ServicosNFe#78
Conversation
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.
b780d7a to
f9c3937
Compare
…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.
620cc61 to
9f734e7
Compare
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.
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:
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
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