Perecimento, perda, roubo ou furto em FOB: Tutorial operacional

Introdução

Perecimento, perda, roubo ou furto em FOB é um tema do Manual Plataforma da CBS - Versão Maio/2026, analisado com base nas páginas 35-36. Este artigo usa o recorte tutorial operacional, com foco em mostrar o processo passo a passo.

O manual é explícito ao dizer que o ambiente de 2026 é Beta e sujeito a alterações. Por isso, a qualidade da implantação depende tanto da leitura correta quanto da capacidade de revisar decisões quando o sistema ou a regulamentação evoluírem.

O que o manual confirma

Quando o adquirente é responsável pelo transporte, o manual considera o fato gerador na saída; evento posterior de perda recai sobre o adquirente e referencia a nota.

Aplicação prática

Integrar regra de transporte, responsabilidade e apuração.

Concilie documento, ERP e contas da plataforma.

Método de trabalho

Para estudar Perecimento, perda, roubo ou furto em FOB, identifique o evento de negócio, o usuário, a entrada, a transformação, a saída e a evidência. Desenhe o fluxo atual e compare com o manual.

1. registre a página da fonte;
2. escolha um caso representativo;
3. defina o resultado esperado;
4. execute no Beta;
5. compare com o ERP;
6. documente diferenças;
7. classifique limitações;
8. repita depois de atualizações.

Conciliação em três camadas

Compare o documento de origem, o registro interno do ERP e a conta correspondente na Apuração Assistida. Classifique diferenças em: processamento ainda pendente, limitação declarada do Beta, dado incorreto no DF-e ou regra/processo ainda não implementado.

A reconciliação serve para descobrir a causa, não para forçar o ERP a reproduzir uma tela sem compreender o evento.

Como homologar

1. registre versão e páginas do manual;
2. defina responsável Fiscal/Contábil;
3. identifique dados e documentos de entrada;
4. defina o resultado esperado;
5. execute cenário normal;
6. execute ao menos uma exceção;
7. compare com o ERP;
8. guarde evidências;
9. marque limitações do Beta;
10. revalide após atualizações.

Dados e controles

Evite planilhas sem dono e regras “temporárias” sem data de expiração. Dados que influenciam classificação, apuração, pagamento ou integração precisam de proprietário, origem conhecida e trilha de alteração.

Quando houver documento eletrônico, use chave e período como elementos de conciliação. Quando houver API, use identificador de solicitação/tíquete. Quando houver acesso, registre representante e autorização. Quando houver cálculo, guarde entrada e memória.

Riscos operacionais

O primeiro risco é extrapolar o manual. O segundo é automatizar uma limitação temporária como se fosse regra definitiva. O terceiro é tratar uma simulação de 2026 como fato contábil ou financeiro.

Também é arriscado corrigir a consequência em vez da causa. Se a apuração diverge, investigue o DF-e e o processamento. Se a API falha, verifique credencial, token, limite e estado. Se o cálculo diverge, confirme versão, entrada e enquadramento.

Cuidados de interpretação

Aplicar ao cenário descrito.

Quando o manual remeter a Nota Técnica, Swagger, guia de integração, legislação ou outro canal, consulte a fonte específica antes de implementar detalhes que não estão descritos neste PDF.

Perguntas para a equipe

• Qual evento dispara o processo?
• Qual CNPJ e usuário são responsáveis?
• Que documento ou dado alimenta a plataforma?
• O comportamento é real, simulado ou futuro?
• Qual versão sustenta a decisão?
• Como a empresa prova o resultado?
• Que integração precisa ser testada?
• Qual é o plano se a próxima versão mudar o fluxo?

Conclusão

Perecimento, perda, roubo ou furto em FOB deve ser transformado em um processo reproduzível, não apenas em conhecimento de leitura. A empresa que registra premissas, testa o Beta e mantém evidências reduz o risco de chegar ao ambiente definitivo com integrações baseadas em interpretações antigas.

Este conteúdo é técnico e informativo; decisões tributárias concretas devem considerar a legislação e regulamentação aplicáveis.

Teste prático mínimo

Documente usuário, CNPJ, documento/serviço, data, entrada, saída esperada e resultado obtido. Se houver diferença, não mude o ERP antes de classificar a causa.

Controle de mudança

Toda alteração relacionada a Perecimento, perda, roubo ou furto em FOB deve ter responsável, data, versão, motivo e evidência de regressão. Integrações precisam ainda de rollback ou forma de desativação controlada.

Aplicação avançada na empresa

Para transformar Perecimento, perda, roubo ou furto em FOB em procedimento real, não basta reproduzir a tela do manual. A empresa precisa documentar o caminho completo entre evento de negócio, dado de origem, sistema, plataforma e evidência. Essa documentação deve permitir que uma pessoa que não participou da implantação consiga entender por que determinado resultado apareceu.

Crie uma ficha do processo com: CNPJ, área responsável, usuário ou procurador, documento ou serviço envolvido, data do teste, versão da documentação, entrada utilizada, resultado esperado, resultado obtido e conclusão. Quando houver integração, acrescente identificador de correlação, horário da chamada e arquivo retornado. Quando houver cálculo, acrescente memória de cálculo. Quando houver atendimento, inclua protocolo e anexos enviados.

Uma boa implantação também precisa de teste negativo. Não valide apenas o cenário que deve funcionar. Teste uma condição em que o processo não deveria produzir o mesmo resultado: outro documento, outro status, outro usuário, outro período ou uma entrada incompleta, conforme o tema. Isso ajuda a encontrar regras ou acessos amplos demais.

Auditoria periódica

Inclua este tema em uma revisão mensal enquanto a Plataforma CBS permanecer em evolução. A revisão pode responder a cinco perguntas:

1. houve nova versão da documentação ou do ambiente?
2. algum comportamento mudou desde a última homologação?
3. surgiram novas divergências entre ERP e plataforma?
4. existe processo manual criado apenas para contornar uma limitação Beta?
5. há evidência suficiente para explicar o resultado a auditoria, suporte ou gestão?

Se a resposta mostrar mudança relevante, reabra a homologação. O maior risco durante uma transição longa é manter uma solução temporária depois que a limitação que a originou deixou de existir.

Documentação para suporte e conhecimento interno

Mantenha uma página interna por tema com três blocos: o que o manual confirma, como a empresa implementou e o que ainda está pendente. Essa separação reduz a chance de uma recomendação interna ser confundida com regra da Receita Federal.

Anexe links, prints, arquivos exportados e exemplos somente quando ajudarem a reproduzir o cenário. Evite copiar grandes trechos do manual; prefira registrar a página e resumir o requisito.

Reconciliação de fechamento

No fechamento, compare totais por documento, tipo de operação e período. Separe itens processados de itens aguardando processamento. Para diferenças conhecidas do Beta, mantenha uma lista formal de exceções com página do manual e data da última revisão.

Evite fechar a análise apenas pelo total. Uma soma igual pode esconder documentos ausentes compensados por outro erro de valor semelhante.

Critério de encerramento

Considere o tema encerrado somente quando existe responsável, evidência, resultado reproduzível e data de próxima revisão. Se houver dependência futura da Receita, registre a pendência em vez de criar regra provisória sem controle.