Fluxo de Processamento¶

Ao receber um arquivo CNAB, o sistema executa um pipeline sequencial composto por seis etapas. Cada etapa é responsável por uma parte do processamento, do arquivo bruto até o retorno entregue ao cedente.

Diagrama Geral¶

Etapas do Processo¶

1. Recepção¶

O arquivo CNAB chega ao sistema por um dos canais disponíveis:

SFTP — O cliente deposita o arquivo na pasta CNAB do seu diretório no servidor SFTP. Um worker monitora continuamente o servidor e faz o download automaticamente.
Tela — Upload manual pela interface web da plataforma, permitindo envio direto e acompanhamento em tempo real do processamento.

Ao ser recebido, o arquivo é armazenado no Azure Blob Storage e um registro de Arquivo é criado no banco de dados com o status inicial de processamento.

2. Identificação do Layout¶

O sistema inspeciona as primeiras posições do arquivo para determinar o tipo de layout sem necessidade de configuração manual:

Critério	CNAB 400	CNAB 240
Tamanho da linha	400 caracteres	240 caracteres
Indicador no header	Posição 2 = `1` (remessa)	Posição 8 = `0` (header arquivo)
Código do banco	Posições 78–80	Posições 1–3

Banco não identificado

Caso o banco ou o formato não seja reconhecido, o arquivo é rejeitado e o erro é registrado no log de integração. O cedente é notificado para verificar o layout enviado.

3. Leitura e Mapeamento de Campos¶

Com o layout identificado, um leitor especializado por banco realiza o parse do arquivo linha a linha, convertendo cada posição fixa em propriedades tipadas:

Linha CNAB (texto fixo, 400 chars)
    ↓
DetalheRemessa400BB (objeto C# com propriedades tipadas)
    ↓
Titulo (entidade de domínio do sistema)

O mapeamento entre o objeto de layout e a entidade de domínio é feito via AutoMapper, com perfis individuais por banco. Cada perfil define exatamente como cada campo do CNAB se traduz para os campos internos do sistema.

4. Enriquecimento de Ocorrências¶

O campo Comando do detalhe (ex: 01 = Registro, 02 = Baixa) é um código numérico que varia por banco. O sistema traduz esse código para uma ocorrência interna padronizada consultando o Mapa de Ocorrências.

Esse mapeamento é parametrizável: cada combinação de Layout + Código pode ser mapeada para uma ocorrência diferente, sem necessidade de alteração no código.

5. Persistência¶

Após o mapeamento, o header e todos os títulos são gravados em lote no banco de dados (bulk insert), garantindo performance mesmo para arquivos com centenas de registros.

Em seguida, o sistema valida:

A conta corrente existe e está ativa no cadastro
O convênio de cobrança está vinculado à operação correta
Não há duplicidade de títulos (verificação por Nosso Número + Data de Emissão)

6. Processamento pelo Administrador¶

Após a persistência, jobs em background são agendados no Hangfire para enviar os títulos ao administrador financeiro configurado na operação:

Administrador	Estratégia	Descrição
Bankly	Por título	Cada título é enviado individualmente via API
BV	Por arquivo	O arquivo completo é enviado de uma vez

O status de cada título é atualizado conforme o retorno do administrador (via webhooks ou polling), registrando ocorrências como: entrada confirmada, liquidação, baixa, rejeição, etc.

7. Geração e Envio do Retorno¶

Quando todos os títulos de um arquivo estiverem processados, o sistema gera automaticamente o arquivo de retorno CNAB no formato configurado para a operação.

O retorno segue a mesma lógica do mapeamento de entrada, mas no sentido inverso: a ocorrência interna é convertida de volta para o código numérico esperado pelo banco/cedente. O arquivo é então disponibilizado ao cliente via SFTP (pasta RETORNO) ou pela interface web.

Saiba mais

Para entender em detalhes como funcionam os retornos de pagamentos e cobranças, tipos de ocorrências, estrutura dos arquivos e exemplos práticos, consulte a página 📄 Geração de Retornos.

Rastreabilidade¶

Cada etapa gera registros de log no banco de dados:

Entidade	O que registra
`LogIntegracao`	Status geral do arquivo (recebido, processado, erro)
`LogIntegracaoTitulo`	Status individual de cada título
`Arquivo`	Referência ao blob no Azure Storage

Reprocessamento

Em caso de falha em qualquer etapa, o sistema registra o erro e pode reprocessar o arquivo ou título específico sem impacto nos demais.