Baixa de títulos: pagamento parcial, crédito e estorno

Baixa de títulos é registrar que uma dívida foi paga, no todo ou em parte. Num sistema de cobrança, parece a parte simples: chegou o pagamento, o título sai da cobrança. Ao especificar o terceiro incremento deste CRM, a baixa exigiu decidir como reconhecer um pagamento que chega duas vezes, o que fazer com o pagamento menor que a dívida, com o dinheiro que não tem título para quitar e com o pagamento que é desfeito depois. Este artigo mostra cada decisão, inclusive uma que eu recomendei, foi aceita e estava errada.

Antes da baixa: o que não estava pronto#

O mapa do projeto previa, para este incremento, os acionamentos: o registro dos contatos com o devedor e a fila de trabalho do operador. Na primeira rodada de perguntas, a resposta foi direta: “Eu não estou preparado para especificar filas neste momento. O que mais temos?”. O mesmo para os limites de contato com o devedor.

Especificar algo para o qual o responsável não está preparado produz um documento cheio de premissas frágeis, que vão ser descobertas na implementação ou na operação. O mapa foi reorganizado, pagamentos e baixa passaram à frente e os acionamentos desceram. A única decisão sobre eles que já estava madura ficou registrada para quando chegarem: os resultados de um contato vêm de uma lista editável pelo gestor, e o operador pode acrescentar um texto livre.

O mesmo pagamento duas vezes#

O primeiro risco de uma baixa por arquivo é processar o mesmo pagamento duas vezes: alguém reenvia o arquivo, ou o arquivo do dia seguinte repete linhas do anterior. A solução óbvia é exigir um identificador único por pagamento. A pergunta foi onde esse identificador é único, e a resposta trouxe um conceito que nenhuma das opções tinha: um credor pode receber por mais de uma conta, mais de um convênio de cobrança, mais de um estabelecimento de cartão (no sentido da adquirente, não de uma filial), e o identificador só é único dentro do canal por onde o dinheiro entrou.

A especificação passou a ter canais de recebimento, cadastrados pelo gestor antes de qualquer importação. A unicidade ficou em credor, canal e identificador. O cadastro prévio tem um motivo: se um canal novo fosse criado automaticamente na importação, um código de canal digitado errado viraria um canal novo, e o mesmo pagamento poderia ser registrado de novo sob ele. Com o cadastro, essa linha é recusada. Reenviar o mesmo arquivo não muda nada: cada linha aparece na conferência como “pagamento já registrado, ignorado”.

O meio de pagamento (Pix, boleto, cartão de crédito, cartão de débito, transferência, dinheiro ou outro) é obrigatório e vem de uma lista fixa. Assim, o valor recuperado pode ser aberto por meio sem depender de como cada pessoa escreveu.

Pagamento menor que a dívida#

A decisão não estava entre as opções. Credores diferentes tratam o pagamento parcial de formas diferentes: uns abatem do título, outros mantêm o título íntegro e guardam o valor como crédito até a negociação. A especificação não escolhe por eles.

O dinheiro sem título#

Pagamentos chegam sem título informado, para um título que não existe ou com valor maior que o saldo. As alternativas eram recusar a linha, guardar o pagamento como pendente ou aplicar uma regra automática. A decisão combinou as duas primeiras de um jeito que nenhuma opção previa:

• Devedor identificado, sem título para baixar: o valor vira crédito do devedor, registrado com a origem (sem título, título inexistente, título já pago ou excedente).
• Devedor não identificado (documento fora da carteira): o pagamento fica pendente, sem efeito. A cada nova conferência de pagamentos, os pendentes cujo documento passou a existir na carteira voltam para decisão.

Neste incremento, o crédito só fica registrado. Usar o crédito para abater outro título, ou devolvê-lo, é uma regra financeira automática que alguém precisaria validar, e ficou para a especificação de acordos.

A recomendação aceita que estava errada#

O faturamento do credor pode demorar a registrar um pagamento. A próxima carga da carteira, então, traz de novo um título que o CRM já sabe estar pago. A primeira decisão foi que a conferência pergunta ao gestor o que fazer, com “manter pago” sugerido.

Ao detalhar o plano técnico, apareceu a pergunta seguinte: se o gestor escolher “voltar para cobrança”, o que acontece com o pagamento que tinha quitado o título? Recomendei que ele virasse crédito do devedor. A recomendação foi aceita e entrou na especificação como revisão. Logo depois, veio a correção:

Para um título voltar à cobrança, o pagamento tem que ter sido estornado antes.

A recomendação tirava o dinheiro do título sem nenhum evento financeiro que justificasse. Era um estorno disfarçado, decidido por um clique numa tela de conferência. Num projeto comum, isso passaria pelos testes, porque o sistema faria exatamente o que estava escrito. Só seria percebido quando o financeiro visse um título pago voltar a ser cobrado sem nenhum estorno no extrato.

A revisão foi desfeita. A carga da carteira passou a só informar: o título continua pago, listado como “pago neste sistema, mantido”. E os estornos, que tinham ficado fora deste incremento, entraram nele, porque sem eles não haveria caminho correto para devolver um título à cobrança.

Estornos#

A última decisão é um conflito clássico entre áreas. Descontar no mês do estorno preserva os números dos meses já fechados, o que interessa a quem já reportou outubro. Descontar no mês do pagamento deixa outubro “verdadeiro”, mas muda um número já apresentado. As duas leituras estão certas para alguém, e a especificação deixa a escolha com o credor.

Em números#

O que vem a seguir#

O plano técnico propõe um módulo de pagamentos ao lado da carteira, reaproveitando a mesma importação em duas etapas, conferência e confirmação. Depois de aprovado, cada um dos 20 critérios vira um teste no navegador, como nos incrementos anteriores.