--- title: Fluxo de Processamento url: https://docs.vehub.com.br/VAN/%F0%9F%94%84%20Fluxo%20de%20Processamento/ --- # 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 ```mermaid flowchart TD A["📥 Recepção\nArquivo CNAB via SFTP / Tela"] B{"🔍 Identificação\ndo Layout"} C["📖 Leitura e\nMapeamento de Campos"] D["🔗 Enriquecimento\nde Ocorrências"] E["💾 Persistência\nno Banco de Dados"] F{"⚙️ Tipo de\nAdministrador"} G1["Processamento\nindividual por título"] G2["Processamento\npor arquivo"] H["⏳ Aguarda\nProcessamento"] I["📄 Geração do\nArquivo de Retorno"] J["📤 Envio do Retorno\nvia SFTP"] A --> B B -->|"CNABS 400"| C B -->|"CNAB 240 · BB Pagamentos"| C C --> D D --> E E --> F F -->|"Bankly"| G1 F -->|"BV"| G2 G1 --> H G2 --> H H --> I I --> J ``` --- ## 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: ```mermaid flowchart LR A["Primeira linha\ndo arquivo"] A -->|"400 caracteres\nPos. 78-80 = 001"| B1["CNAB 400\nBanco do Brasil"] A -->|"400 caracteres\nPos. 78-80 = 237"| B2["CNAB 400\nBradesco"] A -->|"400 caracteres\nPos. 78-80 = 655"| B3["CNAB 400\nBV"] A -->|"240 caracteres\nPos. 1-3 = 001"| B4["CNAB 240\nBB Pagamentos"] ``` | 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 | !!! tip "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**. ```mermaid flowchart LR A["Comando CNAB\n(ex: código '01')"] B[("Mapa de\nOcorrências\n(banco de dados)")] C["Ocorrência Interna\n(ex: RegistroDeTitulos)"] A -->|"Layout + Código"| B B --> C ``` 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. ```mermaid flowchart LR A["Títulos\nprocessados"] B["Mapa de\nOcorrências"] C["Arquivo de\nRetorno CNAB"] D["📤 SFTP / Tela\n(disponível para download)"] A -->|"Ocorrência interna\n→ Código CNAB"| B B --> C C --> D ``` 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. !!! info "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](📄 Geração de Retornos.md). --- ## 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 | !!! info "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.