Arquivos remessa (CNAB) - Introdução
O arquivo transmitido nesta chamada deve seguir o padrão de Layout de Arquivo de Cobrança com 400 posições da QI Tech. Segue link para download do manual: Layout de Cobrança - QI Tech versão 2.1.
Os arquivos remessa (CNAB) oferecem a possibilidade de enviar várias instruções de registros de boleto, juntamente com outros tipos de instrução (extensão, abatimento, baixa etc.), para diferentes boletos, em um único arquivo. Ao enviar instruções como as mencionadas (extensão, abatimento etc.), para boletos já existentes, o boleto é identificado pelo código da carteira (requester_profile_code) e pelo nosso número (our_number).
Ao fazer o upload de um arquivo CNAB, caso a requisição tenha sucesso (código de resposta 202), será criado um arquivo CNAB temporário (TemporaryCNABFile). É possível consultar o status de processamento do arquivo --- bem como possíveis erros, tanto no próprio arquivo quanto em suas ocorrências ---, utilizando os endpoints de consulta de arquivo CNAB temporário e suas ocorrências.
O arquivo será rejeitado caso seja encontrado qualquer erro sintático. No entanto, ele é lido integralmente, ou até que sejam encontrados um limite de 100 erros, para que todos os erros possam ser retornados e corrigidos de maneira mais prática e eficiente.
Enquanto o arquivo é lido, são criadas ocorrências temporárias, que só serão processadas caso ele seja aceito. Ou seja, se o arquivo for rejeitado (status rejected), todas as suas ocorrências também serão. Ademais, se o arquivo for rejeitado, não são mais criadas ocorrências temporárias para o mesmo. Portanto, é comum que as entradas de arquivos rejeitados possuam menos ocorrências do que a quantidade de ocorrências enviada no arquivo.
Por outro lado, no momento em que o arquivo é totalmente lido e aceito (status read), inicia-se a criação das ocorrências definitivas, que serão as instruções que valerão de fato. Se uma ocorrência temporária apresenta o status rejected (rejeitada), significa que foi encontrado algum erro semântico na mesma --- ou seja, algum erro no seu conteúdo. Nesse caso, haverá um objeto error_data junto a mesma, que fornece detalhes acerca do motivo de rejeição. Em contrapartida, se apresentar o status processed, significa que a ocorrência definitiva já foi criada e enviada para a CIP/Nuclea. Maiores detalhes a respeito de cada uma dessas entidades são fornecidos nas páginas subsequentes, de consulta de arquivos e ocorrências temporárias.
Para informar rateio de crédito (split de pagamento) em arquivos CNAB:
- QI SCD (CNAB400 - layout QI Tech v2.1): registro de detalhe com
identificacao_registro = 3. Detalhes completos no Layout de Cobrança - QI Tech v2.1. - Bradesco (CNAB400 e CNAB240): registro de detalhe tipo
3. - Itaú (CNAB400 e CNAB240): registro de detalhe tipo
4. - Santander: não suporta rateio de crédito via CNAB. Use o endpoint REST Atualização de Rateio de Crédito ou inclua
split_payment_datana emissão via API.
Como mapear N rateados: Cada registro de rateio comporta até 3 contas adicionais (número da conta + dígito + percentual). Para mais de 3 rateados, adicione múltiplos registros de rateio em sequência após o registro principal do boleto — eles são acumulados na mesma ocorrência. Exemplo: 7 contas = 3 registros (3 + 3 + 1).
Restrições (todos os bancos):
- Apenas o cálculo por percentual é suportado (
código de cálculo = 2). - A soma dos percentuais (beneficiário + rateios) deve ser exatamente 100.
- Limite total de rateados respeita o mesmo da API REST (até 10 contas adicionais).
- O campo
beneficiary_max_amount(rateio com valor máximo do beneficiário e excedente para a primeira regra) é exclusivo da API REST. Não é suportado via CNAB. Para esse cenário, use o endpoint REST de emissão ou de atualização de rateio de crédito.