[vision-digital]

Adiciona suporte à Declaração de Conteúdo eletrônica (DC-e, modelo 99), instituída pelo Ajuste SINIEF 05/2021, e à sua representação impressa (DACE). É o documento que acompanha o trânsito de bens quando o remetente não é contribuinte do ICMS — pessoa física, marketplace, transportadora ou ECT emitindo em nome do cliente — e que o CT-e passou a referenciar no grupo infDCe (NT 2025.001, já incorporado pelo #188).

A estrutura segue a das famílias MDFe/CTe:

• DCe.Classes — modelo XML serializável ([XmlRoot]/[XmlElement]), enums em Flags/ com [XmlEnum], datas como DateTimeOffset com propriedades Proxy* que preservam o deslocamento informado, retornos tipados (retDCe, retConsSitDCe, retConsStatServDCe, retEventoDCe, procDCe, procEventoDCe) e os 22 XSDs oficiais v1.00 embutidos.
• DCe.Utils — extensões ExtDCe (ObterXmlString, Assina, Valida, SalvarXmlEmDisco, CarregarDeArquivoXml), montagem da chave de acesso e validador. A assinatura usa AssinaturaDigital do DFe.Utils.
• DCe.Wsdl — cliente SOAP 1.2.
• DCe.Servicos — autorização, consulta por chave, status do serviço e evento de cancelamento (110111). Os retornos expõem EnvioStr, RetornoStr e RetornoCompletoStr, como RetornoBase do MDFe.
• DCe.Dace.QuestPdf — DACE completa e resumida em QuestPDF, a partir do procDCe.
• NuGet — Hercules.NET.DCe e Hercules.NET.Impressao.DCe.QuestPdf (este dependendo do primeiro), no mesmo formato dos pacotes atuais e já nos TFMs do Atualiza para .NET 10, remove warning de APIs obsoletas e corrige certificado A3 CNG #193 (net462, netstandard2.0, net8.0, net10.0; impressão em net8.0 e net10.0). Workflow e README atualizados.

Regras do leiaute que a biblioteca aplica, por serem as que mais induzem a erro:

• O cUF da chave é a UF do emitente (na emissão por transportadora, a UF de origem do frete), e não a do autorizador; o CNPJ da chave é o do signatário. Divergir devolve cStat 220.
• O AAMM da chave sai do dhEmi com o seu próprio deslocamento, nunca do UTC: de UTC, toda emissão entre 00:00 e 03:00 UTC do dia 1º cairia em cStat 502.
• No evento 110111, cOrgao é o cUF da chave e o usuário emitente vai em CPFUsEmit, com o CPF do emit (com CNPJUsEmit da transportadora a SEFAZ devolve cStat 299).
• Validações locais equivalentes às rejeições 220, 273, 275 e 509, antes do envio.

Três pontos diferem do padrão das outras famílias, de propósito:

1. Transporte próprio em DCe.Wsdl, em vez de DFe.Wsdl. O webservice da DC-e exige SOAP 1.2 com o action dentro do Content-Type (application/soap+xml; charset=utf-8; action=...), e não em cabeçalho separado. O cliente usa mTLS com o certificado carregado por CertificadoDigital do DFe.Utils e deixa a validação do certificado do servidor com a plataforma.
2. Autorizador único. A DC-e tem um autorizador nacional, hospedado na SEFAZ-PR, para todas as UFs; não há tabela de URLs por UF.
3. XSDs embutidos, com CaminhoSchemas opcional. Sem pasta configurada, a validação usa os XSDs do assembly; com pasta, usa os dela (respeitando as subpastas, que têm arquivos homônimos de conteúdo diferente), e pasta inexistente é erro explícito, como no Validador do MDFe.

Testes: DCe.Testes (168) e DCe.Dace.QuestPdf.Testes (28), MSTest, em net10.0, rodando no workflow. Cobrem ida e volta XML → objeto → XML idêntico, validação contra os XSDs, chave e DV, preservação do deslocamento em culturas e fusos distintos, assinatura, envelope SOAP e renderização da DACE.

Validado também contra a SEFAZ real, em homologação, a partir desta branch (Linux, .NET 10, certificado A1): status do serviço cStat 107, autorização cStat 100 e consulta pela chave cStat 100, com a DACE gerada do procDCe autorizado. A implementação de origem desta contribuição está em produção, e as regras acima foram apuradas contra a SEFAZ, em homologação, nas 27 UFs.

Fontes: Ajuste SINIEF 05/2021 e NT/esquemas da DC-e publicados pela SEFAZ-PR (https://www.fazenda.pr.gov.br/dce).

[danilobreda]

Top demais agradeço a contribuição, nessa vou precisar de ajuda @marcosgerene @robertorp @adrbarros