Atraso de quatorze dias na emissão de faturas eliminado e alterações de engenharia faturadas em um fabricante industrial

O problema

A fábrica era moderna; o back office não. Os equipamentos saíam do chão de fábrica com uma ficha de papel, e depois um auxiliar contábil abria cada item fulfillment, conferia os números de rastreamento nos sites das transportadoras, confirmava as condições de pagamento e digitava uma fatura, em média doze a quatorze dias úteis depois de o caminhão ter saído. Enquanto isso, os contratados alteravam dimensões de dutos e especificações de motores no meio da obra, a engenharia revisava os desenhos por e-mail e Excel, e o pedido de venda nunca era atualizado; assim, a empresa fabricava componentes revisados e absorvia o custo.

1. O atraso de faturamento de quatorze dias

   Cada pedido expedido aguardava em uma fila de faturamento manual. Milhões em contas a receber envelheciam duas semanas antes de o cliente sequer receber uma fatura para pagar.

2. A armadilha da engenharia em planilhas

   Uma solicitação de alteração de projeto é um evento comercial. Roteada por planilhas, virava customização não faturada em cada obra comercial e, ocasionalmente, um erro na linha de produção.

O que fizemos

Dois trechos de código funcional em um sprint de duas semanas. Um Suitelet nativo em SuiteScript 2.1 assumiu as solicitações de alteração de projeto: uma alteração registrada bloqueia a ordem de produção seguinte, reprecifica com base no custo da matéria-prima, aguarda a aprovação eletrônica do gerente de projeto e então atualiza as linhas do pedido de venda e as ordens de trabalho em uma única transação. Um motor automatizado de transações pareadas assumiu o faturamento: a leitura da transportadora no ShipStation dispara um webhook no NetSuite, um job Map/Reduce verifica o fulfillment, as aprovações e as condições, cria a fatura, a lança e a envia por e-mail com o link de rastreamento e o conhecimento de embarque enquanto o pallet ainda está na doca da transportadora.

Este diagrama é um dos desenhos de fluxo de trabalho, com seus pontos de controle e a evidência relacionada.

Como o mecanismo funciona

1. Solicitações de alteração de projeto dentro do livro razão

   Quando um engenheiro registra uma alteração de especificação no Suitelet, a ordem de produção é bloqueada, o preço é recalculado com base no custo atual do material e o gerente de projeto aprova a variação antes de a produção ser retomada. As linhas do pedido de venda e as ordens de trabalho são atualizadas de forma atômica, de modo que o que é expedido é o que é faturado.

2. Faturamento como evento

   A leitura da transportadora é o gatilho. Um job Map/Reduce valida a conclusão do fulfillment, verifica as condições (net 30, faturamento por etapas ou cartão), cria a fatura nativa e gera o PDF com rastreamento, conhecimento de embarque e ficha de especificações incorporados. O contato de contas a pagar a recebe antes de o caminhão sair do pátio.

Resultados

O que levar disso

1. O faturamento deve ser um evento, não uma tarefa braçal

   Se uma empilhadeira carregou o pallet e a transportadora leu o conhecimento de embarque, o software já tem todos os dados de que uma fatura precisa. O tempo administrativo humano entre os dois passos é puro atrito.

2. Nunca deixe alterações de engenharia fora do ERP

   Uma revisão de engenharia é um evento contratual. Quando as aprovações ficam desconectadas do pedido de venda, a empresa perde margem em cada fabricação sob medida.

3. As transações pareadas são a trilha de auditoria

   Vínculos programáticos do pedido de venda à ordem de produção, à expedição e à fatura permitem que um auditor externo rastreie cada linha sem precisar de uma planilha para explicá-la.

Retrospectiva de caso composto; o cliente é apresentado como arquétipo e os números ilustram o mecanismo. Relacionado: Consolidação de impressão, leitura e pesagem em um portfólio