Pular para o conteúdo
caua.tolentino
Todos os cases
InvestigaçãoIntegração

Frete cotado quase dez vezes abaixo do cobrado

Produtos grandes e leves eram cotados só pelo peso real, e o frete faturado chegava a quase dez vezes o cotado. Analisei os dois lados da integração, encontrei na plataforma uma comparação entre quilos e metros cúbicos e criei o cálculo do peso cubado que faltava.

Papel
Desenvolvedor responsável, do diagnóstico à entrega
Contexto
Plataforma de e-commerce multi-tenant
Stack
PHP, Symfony
Time
Solo
Período
2026

Case anonimizado: nomes de empresa, cliente e pessoas foram omitidos ou trocados.

01. Situação

O frete cotado era quase dez vezes menor que o cobrado

Uma loja reclamou de um pedido em que o frete cobrado pela transportadora foi cerca de 9,6 vezes o valor cotado no checkout. O produto era grande e leve: 2,8 kg, com 50 × 22 × 125 cm. A loja pagava a diferença.

A regra da transportadora é cobrar pelo maior valor entre o peso real e o peso cubado, que é o peso calculado a partir do volume. Para esse produto, o peso cubado é muito maior que o real. Assumi a análise e abri o chamado já com o diagnóstico.

frete cobrado sobre o cotado
~9,6×
peso enviado na cotação
2,8 kg

02. Investigação

O código comparava quilos com metros cúbicos

Comecei analisando os dois lados da integração, a API da transportadora e a plataforma, para saber qual deles estava errado. Montei um experimento em homologação com um produto igual ao do pedido. Com o peso aumentado artificialmente, o frete subiu. Com o peso real, voltou ao valor baixo do chamado. Li também a documentação da transportadora, que não pede dimensões. A API estava correta: cotava pelo peso que recebia. O problema estava no peso que a plataforma enviava.

Com isso, segui o peso enviado até a origem. Ela escolhia o maior entre o peso real e um campo chamado "peso cúbico". Esse campo, apesar do nome, guardava o volume em metros cúbicos. Um volume de 0,14 m³ sempre perdia para 2,8 kg, e o peso real era enviado.

A plataforma tinha o volume e os fatores de cubagem de cada modal, mas não havia nenhum cálculo que transformasse esse volume em peso cubado.

No meu teste, a cotação só reagia ao peso enviado, e a documentação não usa as dimensões. Descartada.

03. Solução

Criar o cálculo do peso cubado e usá-lo na comparação

Avaliei enviar as dimensões para a API e descartei, porque a transportadora não as usa: o cálculo precisava ficar na plataforma. Criei uma função que converte o volume em quilos pelo fator de cubagem do modal configurado, e fiz a comparação usar esse valor no lugar do volume.

Código da Comparação
// cubicWeight guarda o volume em m³
$weight = $package->weight > $package->cubicWeight
    ? $package->weight
    : $package->cubicWeight;

Para o produto do chamado, o peso enviado passa de 2,8 kg para algo entre 23 e 41 kg, conforme o modal. Validei refazendo a cotação em homologação com o mesmo produto.

04. Resultado

A cotação passou a seguir a regra da transportadora

O ganho aqui foi acabar com uma perda. No pedido do chamado, o cliente pagou no checkout cerca de um décimo do frete que a transportadora cobrou, e a loja cobria o resto. Com a correção, a cotação passou a usar o peso que a transportadora de fato cobra.

do frete do pedido que a loja pagava do próprio bolso
~90%
peso enviado na cotação do mesmo produto
2,8 → ~41 kg
diferença entre o peso cubado e o real desse produto
~15×

O checkout passou a enviar o maior valor entre peso real e peso cubado, como a transportadora cobra. A correção vale para toda loja que usa essa transportadora, não só para a que reclamou: cada produto grande e leve vendido deixou de gerar esse prejuízo silencioso.

A correção ficou pequena e localizada porque a análise apontou exatamente onde o peso era calculado errado.