# Legado PIX — Multiliquidação (liquidação em lote / negócio)

Mapa do sistema legado CRK/Corner de **Multiliquidação PIX** a partir do código decompilado
(`.scratch/legado-pix-decompiled/Multiliquidacao.*`) e do banco SQL Server `crk_multtiliquidacao`
(restaurado, 492.076 operações históricas). Read-only. Esta é a maior lacuna da nossa cabine
(não temos multiliquidação de negócio).

## 0. Visão geral: o que é a "Multiliquidação"

A Multiliquidação é um **motor de pagamentos PIX de saída (PIX-out) orientado a lote e a
integração com contas de terceiros (participantes controlados/indiretos)**. Ela não é apenas
"importar arquivo e mandar"; é um subsistema completo com:

- **Motor de pagamento unitário** (`PagaOperacaoDTOUseCase.TratarPix`) que trata cada pagamento
  como uma `Operacao`, valida chave DICT, resolve pagador/recebedor, chama o SPI (pacs.008),
  faz débito/bloqueio na conta do cliente via provedor de conta corrente (CC), e reconcilia.
- **Vários canais de entrada** para o mesmo motor:
  1. **Arquivo de pagamento em lote** (CNAB-like, `;`-delimitado, tipos 01/02/03/99) — o foco de "lote".
  2. **API unitária** (`/api/Entrada/TratarPix`, `SolicitarPagamento`, `DevolvePix`, etc.).
  3. **Agendamento** (por data + janelas de retentativa) e **agendamento recorrente**.
  4. **QR Code** estático, dinâmico (imediato e cobrança/CobV) e **composto (Saque/Troco)**.
- **Modalidades PIX**: transferência (`IPAY`), **PIX Saque** (`OTHR`, VLDN), **PIX Troco**
  (`GSCB`, VLDN+VLCP), devolução (pacs.004), infração/MED (bloqueio de conta).
- **Workers** dedicados (serviços Windows) para importação, processamento, agendamento,
  bloqueio, tratamento de "em aberto", exportação, retorno MQ e expurgo.

**Modelo mental para replicar na nossa cabine:** cada linha do lote vira **um PIX-out
individual** enviado ao SPI como uma `pacs.008` separada (`IdSystem=4`, `AddPagto`). O "lote" é
uma agregação de controle/importação/reconciliação por cima do fluxo unitário de PIX-out, não
uma mensagem única ao BACEN. A liquidação continua sendo transação-a-transação no SPI.

**Volumetria real no backup** (contexto de escala): `TB_ARQUIVO_PAGTO`=179 arquivos,
`TB_ARQUIVO_PAGTO_DETALHE`=115 detalhes, `TB_OPERACAO`=492.076 operações,
`TB_INICPAGTO`=324, `TB_INICPAGTODINAMICORECEBEDOR`=230 (QR dinâmicos), `TB_SOLICITACAO_PAGAMENTO`=29.
Distribuição por status atual das operações: 70 `ConfPagtoRecebto_Ok`=195.125, 75 `CancPagto_Ok`=181.799,
32 `LiqOpeRec_ConfirmaOk`=61.971, 71 `ConfPagtoRecebto_Erro`=22.586, 98 `TrataPIX_FinalizadoERRO`=16.258,
60 `ComplemPIX_ChamouSPI`=14.055, 99 `TrataPIX_FinalizadoOk`=195. O grosso é PIX recebido/confirmado e
cancelamento; a operação é bidirecional (pagamento e recebimento).

### Assemblies / serviços

| Assembly (decompilado) | Papel |
|---|---|
| `Multiliquidacao.Core.Domain` | Entidades + EF configs (mapeamento tabela↔classe) |
| `Multiliquidacao.Core.General` | Enums (state machine), DTOs, utils |
| `Multiliquidacao.Core.Application` | Use cases (motor `TratarPix`, importação, agendamento, bloqueio, QR, expurgo, APIX) |
| `Multiliquidacao.Core.Infrastructure` | Repositórios EF, serviços HTTP (SPI/DICT/CC), MQ |
| `SPI.Core.Multiliquidacao.Application` | Use cases de validação (crédito, recorrência, solicitação, cancelamento) e `RetornoLegado` |
| `Multiliquidacao.Web.Api` | API principal (Entrada, Consulta, Bloqueio, Geral, EMV) |
| `Multiliquidacao.Web.Api.QrCodeDinamico` | Endpoints públicos de payload de QR (JWS) |
| `Multiliquidacao.ValidacaoCredito.*` | Tratamento de **crédito recebido** (PIX-in) via provedores de CC |
| `Multiliquidacao.RetornoMQ.*` | Consumo da fila IBM MQ do CAMPS/SFN (retorno do legado) |
| Workers: `.Worker.{ImportacaoArquivos, Agendamento, Bloqueio, EmAberto, ExportacaoArquivos, RetornoMQ, ValidacaoCredito, Expurgo}` | Serviços Windows de background |

---

## 1. Modelo de dados

### 1.1 `Operacao` (`TB_OPERACAO`) — a unidade transacional (492k linhas)

Cada pagamento/recebimento/devolução/estorno é uma `Operacao`. Campos-chave
(`Multiliquidacao.Core.Domain.decompiled.cs:361`):

- `IdOperacao` (PK, bigint), `idRecorrencia`, `IdInicPagto` (FK QR/EMV), `nrParcela`.
- **Valor**: `VlOperacao` (valor liquidado), `VlDocumento` (valor do documento/nominal).
- **Datas**: `DtPagto` (data de liquidação/agendamento), `DhOperacao`, `DhLiquidacao`,
  `DtHrAceite`, `DhInicioContingencia` (marca janela de contingência/reconciliação).
- **Pagador**: `NmPessoaPagador`, `IdTipoPessoaPagador`, `NrCpfCnpjPessoaPagador`,
  `NrSpbPagador`, `NrAgenciaPagador`, `IdTipoContaPagador`, `NrContaPagador`.
- **Recebedor**: `NmPessoaRecebedor`, `IdTipoPessoaRecebedor`, `NrCpfCnpjPessoaRecebedor`,
  `NrSpbRecebedor`, `NrAgenciaRecebedor`, `IdTipoContaRecebedor`, `NrContaRecebedor`.
- **PIX**: `IdFimAFim` (E2E), `TxChave` (chave DICT), `IdConciliacaoRecebedor` (txid QR),
  `IdPayLoad`/`IdRevisaoPayLoad`, `tpQrCode` (MANU/DICT/INIC/QRDN/QRES/AUTO/APDN),
  `tpFinalidade` (IPAY/OTHR/GSCB), `tpPrioridade` (PAGPRI/PAGAGD/PAGFRD), `TxDescricao`.
- **Saque/Troco**: `lstTipoValor` (JSON `JS_TIPOVALOR`: [{tpPagto=VLDN/VLCP/VLTR, vlTipo}]),
  `ModalidadeAgente` (AGPSS/AGFSS/AGTEC/AGTOT), `PrestadorSaque` (ISPB).
- **Devolução**: `FlDevolucao`, `IdOperacaoOriginal`, `JsMotivoDevolucao` (JSON de `Reason`).
- **Controle**: `IdTipoSituacaoAtual` (state machine, default `RegOpe_Aberta`=1), `IdSpi`,
  `IdInstFinanc`, `IdFilialInst`, `NrSpbControlador` (ISPB do PSP controlador que liquida),
  `NrDocumentoOrigem`/`NrDocumentoComplemento`, `CnpjIniciadorPagamento` (iniciador INIC),
  `NrDoctosGeradoContaJson` (JSON dos lançamentos gerados na conta do cliente).
- `histSituacao` → `HistSituacaoOperacao` (`TB_HISTSITUACAOOPERACAO`): trilha de auditoria de
  cada transição (`IdTipoSituacao`, `DhAtualizacao`, `TxMensagem`).

Espelho histórico: `crk_multiliquidacao_hist` (mesma estrutura, para operações expurgadas).

### 1.2 Arquivo de pagamento em lote

- `ArquivoPagamento` (`TB_ARQUIVO_PAGTO`): cabeçalho lógico do arquivo importado.
  Campos: `IdArquivo`, `NmArquivo`, `DtInclusao`, `NrCpfCnpj` (do titular pagador),
  `NrConta`, `NmCliente`, `NrTipo` (1 char), `DtCriacao`, `HrCriacao`, `NrSequencial`,
  `NrPagamentosTransacoes`/`VlPagamentosTransacoes` (totais tipo 02),
  `NrPagamentosQRCode`/`VlPagamentosQRCode` (totais tipo 03), `IdSituacao`
  (`enumSituacaoArquivoPagamento`), + coleções `Detalhes` e `Erros`.
- `ArquivoPagamentoDetalhe` (`TB_ARQUIVO_PAGTO_DETALHE`, herda `PagtoImportacaoArquivoDTO`):
  uma linha de pagamento. Campos: `IdDetalhe`, `IdArquivo`, `IdSituacaoDetalhe`
  (`enumSituacaoArquivoPagamentoDetalhe`), `IdOperacao` (FK para a `Operacao` gerada),
  `UrlEMV` (para tipo 03 QR), + todos os campos de pagador/recebedor/valor/chave.
- `ArquivoPagamentoErro` (`TB_ARQUIVO_PAGTO_ERRO`): erros por arquivo/detalhe
  (`NrTipo` 1=arquivo, 2=detalhe; `Descricao`).

### 1.3 Início de pagamento (QR / EMV)

- `InicPagto` (`TB_INICPAGTO`): "início de pagamento" = um QR/EMV cadastrado no PSP recebedor.
  `IdTipoInicPagto` (`enumTipoInicPagto`: 1=InserçãoManual, 2=QRCodeEstatico,
  3=QRCodeDinamicoRecebedor, 4=QRCodeDinamicoPagador), `accessToken`, `TxPadraoEMV` (BR Code),
  `TxChave`, `IdTipoChave`, `VlDocumento`, dados do recebedor, `DhInativacao`, `PSS`.
- `InicPagtoDinamicoRecebedor` (`TB_INICPAGTODINAMICORECEBEDOR`): payload dinâmico/CobV.
  `IdPayLoad`/`IdRevisaoPayLoad`, `DhCriacao/DhApresentacao/DhExpiracao`, `DtVencimento`,
  `IcRecebivelAposVencimento`, `ValidadeAposVencimento`, juros/multa/desconto/abatimento
  (modalidade+valor), `Status` (`enumStatusPagtoDinamico`: Ativa/Concluida/RemovidaPelo{Usuario,PSP}),
  **Saque**: `VlSaque`, `IcPermiteAlteracaoValorSaque`, `NrSpbSaque`, `NmModalidadeSaque`;
  **Troco**: `VlTroco`, `IcPermiteAlteracaoValorTroco`, `NrSpbTroco`, `NmModalidadeTroco`,
  `IcPermiteAlteracaoValor`, `TxAssinatura`, `TxUrlUri`.
- Auxiliares: `InformacaoAdicional` (campos extras do QR), `DescontoDataFixa` (descontos por data).

### 1.4 Outras entidades

- `SolicitacaoPagamento` (`TB_SOLICITACAO_PAGAMENTO`): fluxo de solicitação de pagamento
  (PSP recebedor pede ao pagador — jornada 3/4), com `IdSpi`, aceite, assinatura do QR pagador.
- `AgendamentoRecorrente` (`TB_AGENDAMENTO_RECORRENTE`) + `Recorrencia` (`TB_RECORRENCIA`):
  PIX Automático/recorrência (`enumTipoSituacaoRecorrencia`), com `totalParcelas`.
- `ParticipanteControlado` (`TB_PARTICIPANTECONTROLADO`): **participantes/contas cujo saldo a
  Multiliquidação controla** (indiretos). Guarda o ISPB, ISPB direto, dados de integração com o
  **sistema de conta corrente (CC)**: `TpSistemaConta` (roteia para o provedor: Agibank, Crefisa,
  Sinqia, Topazio, Cobis, BNP), credenciais cifradas SPI/DICT/Conta (AES `MultiliquidacaoKey`).
- `ParticipanteSpb` (`TB_PARTICIPANTESPB`): diretório de participantes SFN (ISPB→banco/COMPE).
- `Bloqueio`/`SolicitacaoBloqueio` (`TB_BLOQUEIO`/`TB_SOLICITACAO_BLOQUEIO`): bloqueios de
  infração/MED na conta do recebedor (`enumSituacaoBloqueio`: Total/Parcial/Desbloqueado).
- `Feriado` (`TB_FERIADO`), `Parametro`/`GrupoParametro`/`ParametroWorker`,
  `JanelaRetentativa` (`TB_JANELA_RETENTATIVA`, janelas de agendamento por ISPB),
  `RetornoLegado` (`TB_RETORNO_LEGADO`), `ConfirmacaoRecebida` (`TB_CONFIRMACAO_RECEBIDA`),
  `SanctionScreening` (`TB_SANCTIONSCREENING`), `ErroCustomizado`, `LogController`/`LogWorker`/`WorkerAtivo`,
  `TB_ARQUIVO_APIX001` (relatório regulatório APIX001).
- De-para (schema `MultiLiqIntegConta`): `DeParaAgencia`, `DeParaDominio`, `DeParaIf` — tradução
  de agência/domínio/IF entre SFN e o legado de conta.

---

## 2. IMPORTAÇÃO de arquivos (lote) — layout e validações

### 2.1 Pipeline de importação (2 workers)

`Multiliquidacao.Core.Worker.ImportacaoArquivoPagamento` roda **três** hosted services:

1. **`WorkerImportacaoPagamento`** (loop ~60s, param `ImpArqPagtoWorkerMilissegImportacao`):
   varre o diretório `ImpArqPagtoDiretorio` (subpastas criadas por `enumImpArqPagtoSubdiretorios`:
   `Processando`, `Sucesso`, `Erro`). Para cada arquivo, move para `Processando`, **re-zipa** e
   POSTa em `/api/Entrada/ImportarArquivoPagamento` (multipart, `application/zip`). Se OK → `Sucesso`,
   senão → `Erro`. Paralelismo = `ImpArqPagtoThreadsImportacao`.
2. **`WorkerProcessamentoPagamento`** (loop): pega arquivos com situação `Processamento`
   (retomada) e `NaoIniciado`, e para cada detalhe chama `Paga(det)` → `sendService.TratarPix`.
   Paralelismo por arquivo (`ImpArqPagtoThreadsProcessamento`) e por detalhe (`ImpArqPagtoThreadsPagamento`).
3. **`WorkerLog`**: heartbeat do worker.

> Separação importante: **importar** (parse+persistência do arquivo) é síncrono no endpoint da API;
> **pagar** (executar cada linha) é assíncrono, feito pelo `WorkerProcessamentoPagamento` varrendo os
> detalhes `NaoIniciado`. A API só valida e grava; a execução do dinheiro é do worker.

### 2.2 Endpoint `POST /api/Entrada/ImportarArquivoPagamento`

`ArquivoPagamentoDTOUseCase` (`Multiliquidacao.Core.Application.decompiled.cs:2598+`):

1. **Assinatura ZIP** obrigatória: primeiros 4 bytes `50 4B 03 04` (`PK\x03\x04`). Senão erro.
2. **Descompacta** — o ZIP deve conter **exatamente 1** arquivo (`DescompactaArquivo`).
3. **Sem BOM UTF-8** (`EF BB BF`) → rejeita ("Converter para UTF-8 comum").
4. Parse por `TextFieldParser` **delimitador `;`** (CSV ponto-e-vírgula).
5. Tipos de registro permitidos na col[0]: **`01`** (Header), **`02`** (Detalhe transferência),
   **`03`** (Detalhe QR dinâmico), **`99`** (Trailler). Qualquer outro → erro.
6. `ValidaHeader` → `ValidaDetail` → `ValidaTrailler`, cada um curto-circuita em erro.
7. **Idempotência**: rejeita se já existe arquivo com mesmo (CPF/CNPJ, NrTipo, NrSequencial)
   (`FindArquivoPagto`). Também rejeita **`DtCriacao` anterior à data atual**.
8. Persiste `ArquivoPagamento` com `IdSituacao = NaoIniciado` (ou `Erro`).

### 2.3 Layout do arquivo (posicional por coluna, `;`-delimitado)

**Header `01` (8 colunas):**

| Col | Campo | Regra |
|---|---|---|
| 0 | Tipo registro | `"01"` |
| 1 | CPF/CNPJ titular | remove `.`/`-`/`/`; 11=CPF válido, 14=CNPJ válido, ≤14 |
| 2 | Nº conta | `TrimStart('0')`, ≤9 |
| 3 | Nome cliente | ≤30 |
| 4 | Tipo do arquivo (`NrTipo`) | 1 char |
| 5 | Data criação | `yyyy-MM-dd` (não pode ser < hoje) |
| 6 | Hora criação | `HH:mm:ss` |
| 7 | Nº sequencial | numérico, `TrimStart('0')`, ≤6 dígitos (≤999999) |

**Detalhe `02` — transferência/IPAY (22 colunas):**

| Col | Campo | Regra |
|---|---|---|
| 0 | Tipo | `"02"` |
| 1 | tpPrioridade | deve ser `PAGAGD` |
| 2 | VlPagto | numérico (en-US) |
| 3 | VlDocumento | numérico |
| 4 | tpFinalidade | deve ser `IPAY` |
| 5 | DtPagto | `yyyy-MM-dd` |
| 6 | ISPB pagador | 8 chars |
| 7 | Agência pagador | ≤5 (se 5, `Substring(1)`) |
| 8 | Tipo conta pagador | `CACC/SLRY/SCGS/TRAN/OTHR` |
| 9 | Conta pagador | `TrimStart('0')`, ≤9 |
| 10 | Nome pagador | ≤30 |
| 11 | Tipo pessoa pagador | `NATURAL_PERSON/LEGAL_PERSON` |
| 12 | CPF/CNPJ pagador | ≤14 |
| 13 | Descrição (comentário) | ≤117 |
| 14 | Chave recebedor (DICT) | ≤77 |
| 15 | ISPB recebedor | 8 chars |
| 16 | Agência recebedor | ≤5 (se 5, `Substring(1)`) |
| 17 | Tipo conta recebedor | `CACC/SLRY/SCGS/TRAN/OTHR` |
| 18 | Conta recebedor | `TrimStart('0')`, ≤12 |
| 19 | Nome recebedor | ≤140 |
| 20 | Tipo pessoa recebedor | `NATURAL_PERSON/LEGAL_PERSON` |
| 21 | CPF/CNPJ recebedor | ≤14 |

**Detalhe `03` — pagamento de QR dinâmico (19 colunas):**

| Col | Campo | Regra |
|---|---|---|
| 0 | Tipo | `"03"` |
| 1 | tpPrioridade | `PAGAGD` |
| 2 | VlPagto | numérico |
| 3 | VlDocumento | numérico |
| 4 | tpFinalidade | `IPAY` |
| 5 | DtPagto | `yyyy-MM-dd` |
| 6..12 | (pagador: ISPB, agência, tipo conta, conta, nome, tipo pessoa, CPF/CNPJ) | idem 02 |
| 13 | Tipo conta recebedor | `CACC/...` |
| 14 | Nome recebedor | ≤140 |
| 15 | Tipo pessoa recebedor | `NATURAL_PERSON/LEGAL_PERSON` |
| 16 | CPF/CNPJ recebedor | ≤14 |
| 17 | **UrlEMV** (URL do QR dinâmico) | obrigatório, ≤79 |
| 18 | **ID do QR (txid/IdConciliacaoRecebedor)** | ≤35 |

> Diferença 02 vs 03: no 02 o recebedor é dado explicitamente (chave/conta); no 03 o recebedor é
> **resolvido a partir da URL do QR dinâmico** em tempo de pagamento (ver §2.4). Registros 03 têm o
> recebedor "aberto" — só validam conta/nome/tipo pessoa e trazem a URL.

**Trailler `99` (5 colunas):** `[0]="99"`, `[1]`=qtd tipo 02, `[2]`=valor total tipo 02,
`[3]`=qtd tipo 03, `[4]`=valor total tipo 03. **Batimento**: qtd/valor do trailler (para 02, i.e.
detalhes sem `UrlEMV`) devem casar exatamente com a soma dos detalhes; senão erro.

### 2.4 Execução de cada linha (`ProcessamentoPagamento.Paga`)

Para cada `ArquivoPagamentoDetalhe` `NaoIniciado`:
1. Marca `Processamento`, `IdPayLoad = "IPD{IdDetalhe}"`.
2. Se `UrlEMV` preenchida (tipo 03) → **`ValidaQRCode`**: consulta `ConsultarUrlQRCode(UrlEMV)`
   (resolve o payload do QR dinâmico), valida `status ATIVA`, vencimento/expiração,
   valor (bate `VlPagto` vs valor do QR conforme `modalidadeAlteracao`). **Rejeita explicitamente
   QR de Saque ou Troco na importação** ("Não é possível realizar pagamentos QR Codes de Saque ou
   Troco através da rotina de importação"). Se OK, seta `tpQrCode="QRDN"`, `TxChaveRecebedor` e
   `IdConciliacaoRecebedor` (txid) a partir do payload.
3. `pagtoDTO.Agendamento = DtPagto > hoje`.
4. Chama `sendService.TratarPix(pagtoDTO)` → a API executa o motor de pagamento (§10).
5. Se OK → grava `IdOperacao`/`IdTipoSituacaoAtual`, detalhe `Concluido`. Senão → `Erro` + grava
   cada erro em `TB_ARQUIVO_PAGTO_ERRO`.
6. `ContinuaProcessamentoPagamento` (retomada): re-lê status da `Operacao` de cada detalhe já com
   `IdOperacao` e reclassifica (Concluido se status ∈ {ComplemPIX_ChamouSPI, ConfPagtoRecebto_Ok,
   TrataPIX_FinalizadoOk}, senão Erro). Situação do arquivo = agregado dos detalhes.

**Situação do arquivo** (`enumSituacaoArquivoPagamento`): `NaoIniciado=1, Validacao, Processamento,
Erro, Concluido`. **Situação do detalhe** (`enumSituacaoArquivoPagamentoDetalhe`):
`NaoIniciado=1, Processamento, Erro, Concluido`.

---

## 3. VALIDAÇÃO DE CRÉDITO (dois sentidos)

Há **dois** conceitos de "crédito" no legado. Cuidado para não confundir:

### 3.1 Validação de débito na conta do cliente (PIX-out) — dentro do motor

Antes de mandar ao SPI, o motor precisa **garantir o débito na conta do pagador** (que pode ser
uma conta controlada de terceiro). Isso é feito por `EfetuarLiqOperacaoPagtoOutraInst` →
`ComplementarPix`, e a "reserva/bloqueio" de valor aparece nos estados `LiqOpePag_BloqValorOk`(40)/
`Erro`(41)/`DesbloqValorOk`(43). O débito real é lançado via provedor de CC
(`IGeraLancamentoCC` / `ISendService` do namespace `CC.*`) roteado por `ParticipanteControlado.TpSistemaConta`.
Se não há saldo/erro no legado de conta → operação vai a erro (não vai ao SPI). **Fail-closed**:
sem confirmação de débito, não liquida.

### 3.2 Tratamento de crédito recebido (PIX-in) — worker `ValidacaoCredito`

`Multiliquidacao.ValidacaoCredito` (`worker.validacaocredito` / `worker.sec.validacaocredito`) é
uma **API** (`POST /api/Entrada/TratarCreditoRecebido`) + healthcheck que:
- Recebe do SPI o crédito PIX-in (`PagtoDTO`), resolve a conta do recebedor (participante controlado)
  e **credita via provedor de CC** (Agibank/Crefisa/Sinqia/Topazio/Cobis/BNP —
  `services.AddHttpClient<IGeraLancamentoCC, ...SendService>`).
- Máquina de estados do recebimento: `LiqOpeRec_BloqValorOk`(30) → `ComplemPIX_ConfSPI`(62)/
  `LiqOpeRec_ConfirmaOk`(32) → `ConfPagtoRecebto_Ok`(70). Erros: 31/33/71.
- `PagaOperacaoDTOUseCase.TratarCreditoRecebido` (`ValidacaoCredito.Application:250`) faz a
  confirmação idempotente (não re-credita se `IdSpi` já confirmado, via `TB_CONFIRMACAO_RECEBIDA`).

> Nome enganoso: "ValidacaoCredito" aqui = **posting do crédito recebido na conta do cliente**, não
> "análise de crédito/limite". Não há motor de limite de crédito/scoring; a "validação" é
> saldo/conta no legado + regras DICT/valor.

---

## 4. AGENDAMENTO (débito diferido por data + janelas)

Dois mecanismos:

### 4.1 Agendamento simples (por data de pagamento)

- Na importação/API, `DtPagto > hoje` marca `Agendamento=true`. O motor `TratarPix` **registra a
  operação mas NÃO liquida**: seta `AgdOpe_Concluido`(20) e salva. Nenhum débito/hold é feito na
  data do registro (dinheiro fica livre; débito é **diferido** para a data agendada).
- **PIX Saque/Troco não permitem agendamento** (`tpFinalidade OTHR/GSCB` + `Agendamento` → erro).

### 4.2 Execução na janela (`Worker.Agendamento`)

- `TB_JANELA_RETENTATIVA` define por ISPB (`NR_SPB`) e tipo de pagamento (`A`=agendado/`N`=?):
  `DH_INICIO/FIM_AGENDAMENTO`, `DH_INICIO/FIM_RETENTATIVA`, `NR_TENTATIVAS`, `NR_MINUTOS_INTERVALO`.
- O worker roda em loop; quando `now` está dentro da janela de agendamento chama
  `ProcessaAgendamentoAutomatico(ispb, tipoJanela, retentativa=false, ...)`; dentro da janela de
  retentativa chama com `retentativa=true` (que atualiza contadores via `AtualizaRetentativa`).
- `ProcessaAgendamentoAutomatico` lista `ListByPagtoAgendado(ispb, tipo)` (operações
  `AgdOpe_Concluido` com `DtPagto` devida) e para cada uma chama `EnviaOperacaoAgendada`:
  1. Seta `AgdOpe_Iniciado`(22), registra retentativa (`TB_HISTORICO_RETENTATIVA`).
  2. Chama `TratarPix` de novo — agora **confere saldo, debita e envia ao SPI** (débito diferido
     acontece aqui, na abertura da janela).
  3. Se falhar e `EnviaCancelamentoAgendamento` ligado → finaliza como **Rejeitada** (gera
     `ConfirmacaoCreditoDTO` sintético `ED05`, status Rejeitada) — ou seja, sem saldo às 8h rejeita.
- Também há `WorkerAtualizaExpiracao` (roda diariamente à meia-noite) que expira cobranças
  (`SolicitacaoPagamento`/`Recorrencia`).
- **Agendamento manual**: `POST /api/Entrada/EnviaOperacaoAgendada?idOperacao=` →
  `ProcessaAgendamentoManual` (só executa se `AgdOpe_Erro`/`AgdOpe_Concluido`).

### 4.3 Recorrência (PIX Automático)

`AgendamentoRecorrente`/`Recorrencia` + `SolicitarAutorizacaoRecorrencia`/`AutorizarRecorrencia`/
`CancelarAutorizacaoRecorrencia`. `TratarPixApi` ramifica: se `Agendamento && agendamentoRecorrente
!= null` → `AgendamentoRecorrente(dtoPagto,...)` gera N parcelas (`totalParcelas`,
`enumTipoSituacaoRecorrencia`). Validações em `SPI.Core.Multiliquidacao.Application.ValidacaoRecorrenciaUseCase`.

---

## 5. BLOQUEIO (worker + use case) — infração/MED

`Worker.Bloqueio` roda `BloqueioUseCase.BloquearParciais()` em loop (param worker cd=8, `TempoPausa`).
`BloqueioUseCase` (`Application:8941+`):

- **`BloquearInfracao(BloqueioInfracaoDTO)`** (via `POST /api/Bloqueio/BloquearInfracao`): dado o
  `idFimaFim`, acha a `Operacao`, monta bloqueio na **conta do recebedor**, consulta saldo no
  provedor de CC (`sendCC.ConsultaSaldo`), e chama `sendCC.Bloquear`. Se saldo ≥ valor → bloqueio
  **Total**; senão bloqueia o que há → **Parcial**. Persiste `SolicitacaoBloqueio` + `Bloqueio`
  (`chaveBloqueio` retornada pelo legado). Guarda contra duplicidade por `idInfracaoBacen`.
- **`BloquearParciais()`** (worker): para cada bloqueio ainda **Parcial** (`ListParciais`), reconsulta
  saldo e tenta bloquear o valor remanescente conforme o saldo vai chegando (converge para Total).
- **`DesbloquearInfracao(DesbloqueioDTO)`** (via `POST /api/Bloqueio/DesbloquearInfracao` ou
  automaticamente no fluxo de devolução): desbloqueia todas as chaves não desbloqueadas via
  `sendCC.Desbloquear`, marca `Desbloqueado`. No `TratarPix`, se `idInfracaoBACEN` presente, faz
  desbloqueio antes de liquidar a devolução.

`enumSituacaoBloqueio`: `Total`, `Parcial`, `Desbloqueado`. Este é o mecanismo de MED/fraude
(bloqueio cautelar de valores na conta do recebedor a pedido do BACEN/DICT).

---

## 6. EM ABERTO (reconciliação de pendentes)

`Worker.EmAberto` → `PagaOperacaoDTOUseCase.ProcessarPagtoEmAberto` (`Application:4142`):

- Lista operações "em aberto" (`ListByPagtoEmAberto` — tipicamente `ComplemPIX_ChamouSPI`(60) sem
  confirmação, dentro/fora da janela de contingência).
- Para cada uma: `BuscaNoSPI(operacao)` (consulta status no SPI):
  - **Sem protocolo** e `DhOperacao` < 1h → gera **CAMT.060** (`EnviaConsultaOperacao`,
    `IdSystem=4`, `IdEventoPesquisa = IdFimAFim`) para o SPI atualizar o status.
  - **Sem protocolo** e > 1h e `PAGPRI` → **finaliza como Rejeitada** (protocolo sintético
    `IdOperacaoSPI = -IdOperacao`, `ConfirmarRecebimentoCredito`).
  - **Protocolo finalizado** → confirma idempotentemente (`FindIdConfirmacao` antes de
    `ConfirmarRecebimentoCredito`).
- Backoff adaptativo: se retornou >60 pendentes, dorme 1h; senão `Pausa * (n+1)`.

Este worker fecha o gap "chamei o SPI mas não recebi a confirmação/pacs.002" — mesma classe de
problema que na nossa cabine é resolvido por camt.060/reconciliação.

---

## 7. EXPORTAÇÃO (arquivos de saída)

Não há "arquivo de retorno" único do lote (o status é consultado pela API/UI por arquivo/detalhe).
As exportações existentes são regulatórias/compliance:

- **`Worker.ExportacaoArquivos`** → `BuscaOperacaoDTOUseCase.ExportarSanctionScreening` (`Application:302`):
  geração automática diária (param `SanctionScreeningHorarioGeracaoAutomat`) do arquivo de
  **Sanction Screening** (triagem de sanções/AML) sobre as operações do dia. Também exportável
  manualmente por `GET /api/consulta/ExportarSanctionScreening?dhInicial&dhFinal&exportacaoManual`.
  `SanctionScreening`/`SanctionScreeningErro` (`TB_SANCTIONSCREENING*`), situação
  `enumSituacaoSanctionScreening`.
- **APIX001** (`ArquivoApixUseCase`, `Application:2398`, `TB_ARQUIVO_APIX001`): relatório mensal
  regulatório de PIX ao BACEN (volumetria/consultas) — reporting, não retorno de lote.
- **Conciliação**: `GET /api/consulta/ListarConciliacao?dataPagto` e
  `ListarConciliacaoSpixMulti?dataPagto&ispb` — reconciliação SPI × Multi por dia/ISPB (consumido
  por relatório/tela, não é arquivo de retorno posicional).

> Para replicar: se o cliente espera um **arquivo de retorno do lote** (status por linha), ele não
> existe como arquivo no legado — o retorno é via API/tela por `IdArquivo`/`IdDetalhe`/`IdOperacao` e
> a trilha `HistSituacaoOperacao`. Um exportador de retorno seria feature nova.

---

## 8. RetornoMQ (retorno do legado/CAMPS via IBM MQ)

`Multiliquidacao.RetornoMQ` (`worker.retornomq`), infra `IBM.WMQ`:

- `Worker` roda em loop (`QtMiliSegundosRetornoMQ`), só se `Camps_QMReturnQueue` configurada.
- `ProcessaCamps.Executa()` (`RetornoMQ.Infrastructure:220`): conecta ao **IBM MQ** (`MQQueueManager`
  `Camps_QMName`, canal `Camps_QMChannel`, host/porta/user/pwd/cert `Camps_QM*`), abre a fila de
  retorno e drena `while (queue.CurrentDepth > 0)`. Reason 2033 (no message) é ignorado.
- `GravaMensagem(xml)` (`:162`): faz parse XML, extrai a tag **`TxRef`** (formato: 1 char de prefixo
  + `IdOperacao` + `-...`), deriva `IdOperacao` (`Substring(1).Split('-')[0]`), confere `CheckId`,
  grava a mensagem crua em `TB_RETORNO_LEGADO`. Se `EvtCd != "PA00"` (sucesso) →
  `UpdateErroRetorno(IdOperacao)` marca a operação `ErroRetornoLegado`(90).
- `SPI.Core.Multiliquidacao.Application.RetornoLegadoUseCase` consome esses retornos.
- Há também `Multiliquidacao.Simulador.LegadoMQ` (simulador do MQ do legado para teste).

Este é o **canal de retorno do sistema de conta corrente legado (CAMPS/C&M)** confirmando o
lançamento na conta — paralelo/complementar ao retorno do SPI.

---

## 9. QR Code Dinâmico em lote

O lote não "gera" QR; ele **paga QRs existentes** (registro tipo 03). A geração de QR é um fluxo
próprio (usado por PSP recebedor), reaproveitado:

### 9.1 Geração (API `/api/Entrada`)

- `GerarInicioPagtoEstatico` (`PagtoEstaticoDTO`) → QR estático (`TxPadraoEMV`/BR Code fixo).
- `GerarInicioPagtoDinamico` (`PagtoDinamicoIncDTO`) → QR dinâmico imediato/CobV
  (`InicPagtoDinamicoRecebedor`), com `accessToken`, payload assinado JWS, `DhExpiracao`/`DtVencimento`.
- **`GerarQRCodeComposto` (`QRCodeCompostoIncDTO`)** → **QR de Saque/Troco** (composto): cria o
  `InicPagtoDinamicoRecebedor` com `VlSaque`/`NrSpbSaque`/`NmModalidadeSaque` e/ou `VlTroco`/
  `NrSpbTroco`/`NmModalidadeTroco`, e flags de permissão de alteração. Alterar/cancelar:
  `AlterarQRCodeComposto`/`CancelarQRCodeComposto`. Alteração incrementa `IdRevisaoPayLoad`.
- Ciclo de vida do QR: `InativarInicPagto`, `UsuarioRemoveQRCode`, `IFRemoveQRCode`, `ConcluiQRCode`
  (status `enumStatusPagtoDinamico`).

### 9.2 Payload público (`Multiliquidacao.Web.Api.QrCodeDinamico`)

Endpoints de leitura do payload do QR (o que o app pagador acessa pela URL do BR Code):
- `GET /pix/v2/cob/{accessToken}` (imediato), `GET /pix/v2/cobv/{accessToken}?codMun&DPP`
  (cobrança/vencimento com cálculo de juros/multa/desconto por data), `GET /pix/v2/rec/{accessToken}`
  (recorrência).
- `GET /verpix/v2/get/{jws}` e `/getUrl/{base64Url}` (resolver JWS).
- `GET /Jwkset/keys` (JWKS público para verificação da assinatura).
- Assinatura JWS: `Multiliquidacao.Core.SignJWS.*` (chaves em `TB_JWKSETINTERNO`/`TB_JWKSETEXTERNO`;
  cadastro de cert por `POST /api/certQRCode/Add` e `/AddPfx`).

### 9.3 Associação QR↔operação no lote

No detalhe tipo 03, `UrlEMV`+`ID do QR (txid)` amarram a linha ao QR. Em tempo de pagamento
(`ValidaQRCode`), o payload é resolvido por `ConsultarUrlQRCode`, valida status/valor/validade, e
seta `tpQrCode="QRDN"`, `TxChaveRecebedor`, `IdConciliacaoRecebedor` na operação. Após pagamento OK,
se o QR não permite alteração de valor / tem vencimento, o status do QR vira `Concluida`
(`inicPagto.InicPagtoDinamicoRecebedor.Status = Concluida`) para não ser pago 2x.
**QRs de Saque/Troco (tipo composto) são barrados na importação** — só via API/canal interativo.

---

## 10. Máquina de estados e integração com o SPI

### 10.1 Motor `PagaOperacaoDTOUseCase.TratarPix` (`Application:4541`)

Entrada única para pagamento/devolução unitários. Fluxo:

1. Regras de guarda: Saque/Troco não agendam; alteração de agendamento
   (`IdAgendamentoAlterar`) só se `AgdOpe_Concluido`; gera `NrDocumentoOrigem` se ausente.
2. Validações: `ValidaDtPagto`, `ValidaPagador`, `ValidaIdFimAFim`, strings, aceite
   (`TempoRecusaDataAceite`, timeout do aceite para `PAGPRI`), `ValidaRecebedor`.
3. Regras por `tpFinalidade`:
   - `IPAY` (transferência): não pode ter `lstTipoValor`.
   - `OTHR` (**PIX Saque**): exatamente 1 `TipoValor` `VLDN` = valor total; exige
     `ModalidadeAgente` (AGPSS/AGFSS/AGTEC/AGTOT) e `PrestadorSaque` (ISPB).
   - `GSCB` (**PIX Troco**): exatamente 2 `TipoValor` `VLDN`+`VLCP`, soma = valor total; exige
     modalidade/prestador.
4. Ramo `Devolucao` vs `Pagamento`.

**`Pagamento`** (`:4939`): valida `tpPrioridade` (PAGPRI/PAGAGD/PAGFRD), valida `tpQrCode`/
`IdConciliacaoRecebedor` (INIC 1–25 chars + CNPJ iniciador; QRDN/AUTO/APDN 26–35 chars). Gera
`IdFimAFim` (E2E) via `GeradorMsgId.GetEndToEndId(ispb, data)` (agendado usa `DtPagto.AddHours(12)`).
Define `formaIniciacao` = `tpQrCode` senão `DICT` (se chave) senão `MANU`. Monta `InformacaoPixDTO`,
resolve visão pagador/recebedor (`TratarDireto`/`TratarVisaoPagador`/`TratarVisaoRecebedor`), e:
- Se **recebimento** (`IndicadorRegistroRecebimento`) → `RegistrarRecebimento` (+ regras de QR:
  já pago/inativo/expirado/valor).
- Se **pagamento** → `RegistrarPagamento` (valida chave DICT via `ValidarChave`; erro
  "Entry associated with given key does not exist" → `ErroConsultaChaveDICT`(100)).
5. Liquidação (não-agendado): 3 caminhos por conta débito/crédito:
   - **Mesma instituição** (`ContaDebito` e `ContaCredito`) → `EfetuarLiqOperacaoMesmaInstituicao`
     (book-transfer interno; não vai ao SPI). Sucesso → `TrataPIX_FinalizadoOk`(99).
   - **Pagamento outra inst** (só `ContaDebito`) → `EfetuarLiqOperacaoPagtoOutraInst` →
     `ComplementarPix` → **`_spiDTOUseCase.AddPagto(PaymentAPIDTO)`** (envia **pacs.008** ao SPI,
     `IdSystem=4`). Sucesso → `ComplemPIX_ChamouSPI`(60); erro do SPI → `ComplemPIX_CancSPI`(61).
   - **Recebimento outra inst** (só `ContaCredito`) → `EfetuarLiqOperacaoRecebtoOutraInst` →
     `LiqOpeRec_ConfirmaOk`(32).
6. Agendado → `AgdOpe_Concluido`(20), não liquida.

**Payload ao SPI** (`ComplementarPix`, `:5495`): `PaymentAPIDTO` com IdSystem=4, E2E, pagador/recebedor
(ISPB/agência/conta/tipo/CPF-CNPJ), valor, `IdPriority` (1=PAGPRI/2=demais), `TxId` (se QR),
`formaIniciacao`/`finalidadeTransacao`/`valorTipo` (saque/troco), `InitgPty` (iniciador), modalidade/
prestador de saque, docFiscal/tributos. Devolução → `DevPaymentAPIDTO` (RtrId, endToEndIdMsgDev,
`Reasons`) via `DevPagto`. A confirmação/liquidação final volta do SPI e vira `ConfPagtoRecebto_Ok`(70)
via `ConfirmarRecebimentoCredito`.

### 10.2 Estados (`enumTipoSituacao`, `TB_TIPOSITUACAO`; classificação 1=aberto/andamento,
2=finalizado-sucesso, 3=finalizado-erro, 4=cancelado)

```
Registro/validação:
  1  RegOpe_Aberta (inicial)      5  ValidDICTErro       6  ValidCPFCNPJErro
  7  ValidDadosContaXDICT         8  ValidDICTOk        11  InicPagtoInativo
 12  InicPagtoJaPago             15  InicPagtoExpirado  19  RegOpe_Concluido
 100 ErroConsultaChaveDICT

Agendamento:
 20  AgdOpe_Concluido (agendado)  22 AgdOpe_Iniciado (executando)
 21  AgdOpe_Cancelado             23 AgdOpe_Erro

Liquidação recebimento:  30 BloqValorOk  31 BloqValorErro  32 ConfirmaOk  33 ConfirmaErro
Liquidação pagamento:    40 BloqValorOk  41 BloqValorErro  42 ConfirmaDebito  43 DesbloqValorOk
Transferência:           50 Ok  51 Erro  52 Confirmada  53 EstornoOk  54 EstornoErro

Complemento PIX (SPI):   60 ChamouSPI  61 CancSPI  62 ConfSPI  66 ConfMulti  67 CancMulti

Confirmação final:       70 ConfPagtoRecebto_Ok(*sucesso)  71 ConfPagtoRecebto_Erro
Cancelamento:            75 CancPagto_Ok  76 CancPagto_Erro  77 OperEfetivada_ErroLegado
Devolução:               80 DevParcial  81 DevTotal  82 DevErro
Retorno/legado:          90 ErroRetornoLegado  96 ErroDebitoLegado  97 ErroCreditoLegado
Finalização PIX:         98 TrataPIX_FinalizadoERRO  99 TrataPIX_FinalizadoOk (*sucesso)
```

Fluxo feliz de PIX-out lote: `1 RegOpe_Aberta` → `8 ValidDICTOk` → `40 LiqOpePag_BloqValorOk` →
`60 ComplemPIX_ChamouSPI` → (confirmação SPI) → `70 ConfPagtoRecebto_Ok` / `99 FinalizadoOk`.
Agendado: `1` → `20 AgdOpe_Concluido` → (janela) → `22 AgdOpe_Iniciado` → mesmo caminho.

`TipoSituacaoHelper` agrupa os estados em Aberta / FinalizadoSucesso / FinalizadoErro / Cancelada
(usado por telas/reprocessamento).

### 10.3 Endpoints da API principal (`Multiliquidacao.Web.Api`, `/api/Entrada`)

`ImportarArquivoPagamento`, `TratarPix`, `DevolvePix`, `SolicitarPagamento`,
`ConfirmarSolicitarPagamento`, `CancelarSolicitacaoPagamento`, `ConfirmarCancelamentoSolPagto`,
`SolicitarAutorizacaoRecorrencia`/`AutorizarRecorrencia`/`CancelarAutorizacaoRecorrencia`,
`CancelarPagto`, `ConfirmarRecebimentoCredito2`, `EnviaOperacaoAgendada`, `ConciliaOperacao`,
`GerarInicioPagto{Estatico,Dinamico}`, `GerarQRCodeComposto`/`Alterar`/`Cancelar`,
`Inativar/UsuarioRemove/IFRemove/ConcluiQRCode`. Consulta (`/api/consulta`): `ListarPix`,
`ListarPixAgendados`, `ListarPixSaquePixTroco`, `ListarConciliacao[SpixMulti]`, `ConsultaOperacao`,
`ListarDevolucoesPorOperacao`, `CalcularValoresPagtoDinamico`, `TraduzirQRCode`, `ConsultarUrlQRCode`,
`GerarDadosPagamentoDinamico`, `ConsultaAgendamentoRecorrente`, `ExportarSanctionScreening`.
Bloqueio (`/api/Bloqueio`): `BloquearInfracao`/`DesbloquearInfracao`. Geral (`/api/geral`): DePara,
parâmetros, erros customizados, `CriptografaBD`.

---

## 11. Expurgo

`Worker.Expurgo`: `WorkerExpurgoLog` (limpa logs) e `WorkerExpurgoOperacao`. Corte por
`QtdDiasManterDados` (default 90 dias). `ExpurgoDTOUseCase` (`Application:2135`) move operações
antigas para `crk_multiliquidacao_hist` e limpa `LogController`/logs (`LimparLogs(dtCorte, dtFim)`).

---

## 12. Avaliação de esforço para replicar na cabine Elixir

**Escopo real:** não é "importar CSV e enfileirar PIX". É um subsistema de PIX-out de negócio com
lote, agendamento por janela, débito diferido, QR composto (saque/troco), bloqueio de infração e
reconciliação. Peças e esforço (relativo à nossa cabine atual):

| Peça | Reuso da cabine hoje | Esforço |
|---|---|---|
| Motor PIX-out unitário (pacs.008, DICT lookup, E2E burn) | **Alto** — já temos (`TratarPix`≈nosso PixDebitValidator/pacs008 builder) | Baixo (adaptar) |
| Modelo de dados lote (Arquivo/Detalhe/Erro + Operacao) | Novo (não temos `Operacao` de negócio nem lote) | Médio |
| Parser do arquivo 01/02/03/99 (`;`, ZIP, sem BOM, batimento trailer, idempotência) | Novo, mas bem especificado (§2.3) | Médio |
| Worker de importação + processamento paralelo por linha | Parcial (temos Oban) — mapear para filas Oban | Médio |
| Agendamento por janela (`JanelaRetentativa`) + débito diferido + retentativa | Parcial (temos ScheduledPix/ScheduledTed) — falta o modelo de janela por ISPB | Médio-Alto |
| PIX Saque (OTHR/VLDN) e Troco (GSCB/VLDN+VLCP) com modalidade/prestador | Verificar se cabine já suporta saque/troco no pacs.008 | Médio (regras de validação) |
| QR composto (saque/troco) geração + pagamento no lote | Temos QR dinâmico/CobV; falta o composto e a resolução `UrlEMV`→pagamento | Médio |
| Bloqueio de infração/MED em conta (parcial→total) | Temos infração DICT; **este é bloqueio de saldo na conta CC**, diferente | Médio (integra com Core/ledger, não DICT) |
| Reconciliação "em aberto" (camt.060, rejeição PAGPRI) | **Alto** — já temos reconciliação/camt.060/PixInOrphanRecon | Baixo |
| Integração provedor de CC (débito/crédito/bloqueio) | Na nossa arquitetura isto é o **Core/ledger (TB)**, não provedor externo | Baixo-Médio (mapear para HoldRelease/Wallet) |
| RetornoMQ (IBM MQ CAMPS) | **Não portar** — é legado C&M; nosso equivalente é evento NATS do Core | N/A |
| Sanction Screening / APIX001 export | Parcial (temos APIX/Cadoc) | Baixo-Médio |
| Estados (36+ estados) | Podemos simplificar para a nossa máquina de PIX-out + status de lote | Baixo |

**Estimativa global:** MVP funcional de multiliquidação de negócio (importação de lote +
processamento por linha reusando o motor PIX-out + status por arquivo/linha + reconciliação) é
**médio** (o motor de PIX-out já existe; o novo é o modelo de lote, o parser e o painel). O
**completo** (agendamento por janela com débito diferido + retentativa, saque/troco, QR composto,
bloqueio de infração em conta) é **médio-alto**, principalmente por: (a) janelas de retentativa por
ISPB/participante controlado, (b) PIX Saque/Troco end-to-end, (c) mapear "provedor de CC" para o
nosso ledger (o legado debita conta de terceiro via API externa; na cabine o débito é no Core/TB).
Não portar o RetornoMQ nem a dependência de sistemas de conta externos (Agibank/Crefisa/etc.) — no
nosso desenho o débito/crédito é no ledger próprio.

**Decisões-chave de desenho a validar com o dono antes de implementar:**
1. Conta pagador é **sempre nossa** (cliente Monetarie) ou também de terceiro controlado? (o legado
   suporta ambos via `ParticipanteControlado`).
2. Débito **diferido** no agendamento (dinheiro livre até a janela) vs hold no registro — o legado
   usa diferido (espelha nosso `ScheduledTed`).
3. Precisamos de **arquivo de retorno** posicional? (o legado não tem; retorno é por API/status).
4. Saque/Troco e QR composto entram no MVP ou ficam para fase 2?

**Referências de código (arquivo:linha):** motor `Multiliquidacao.Core.Application.decompiled.cs:4541`
(TratarPix), `:4939` (Pagamento), `:5255` (RegistrarPagamento), `:5465` (ComplementarPix→SPI),
`:2598/2705/2769/2913/3278` (importação/parser), `:3987/4017` (agendamento), `:4142` (em aberto),
`:8962/9119` (bloqueio), `:302` (sanction export); estados `Multiliquidacao.Core.General.decompiled.cs:6593`;
entidades `Multiliquidacao.Core.Domain.decompiled.cs:361`; RetornoMQ
`Multiliquidacao.RetornoMQ.Infrastructure.decompiled.cs:162/220`; QR público
`Multiliquidacao.Web.Api.QrCodeDinamico.decompiled.cs:420`.