> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apexx.work/llms.txt
> Use this file to discover all available pages before exploring further.

# Como o Apex pensa

> Quatro regras que explicam o comportamento de todas as telas do sistema.

Quase toda dúvida sobre "por que o Apex não me deixou fazer isso?" se resolve
com uma destas quatro regras. Elas não são configuráveis: são a razão de o
sistema existir.

## 1. Documento não é efeito operacional

Criar um pedido de venda não tira nada do estoque. Criar uma nota de entrada
não coloca nada. O documento registra uma **intenção**; o efeito operacional
acontece quando alguém executa um **comando** sobre ele.

Isso parece burocracia até o dia em que um pedido é cancelado antes de sair.
Se o documento já tivesse baixado o estoque, você teria que lembrar de
desfazer — e o saldo dependeria da memória de quem estava lá.

> [card] O documento
>
> Pedido de venda, pedido de compra, nota de entrada. Guardam o que foi
> combinado: itens, quantidades, valores.

> [card] O comando
>
> Aprovar, despachar, cancelar, lançar estoque. Cada um mexe no estoque, no
> status e no histórico de uma vez só.

## 2. O extrato explica o saldo

Todo movimento de estoque deixa uma linha no extrato (o *kardex*): o que
entrou ou saiu, de qual depósito, por qual documento, a que custo e por quem.
O saldo que você vê na tela é a soma dessas linhas — nunca um número digitado
à mão.

Quando o saldo parecer errado, a resposta está no extrato. Abra o item em
**Suprimentos → Estoque** e veja a aba **Movimentações**.

> [!TIP]
>
> O extrato é somente leitura e não pode ser apagado, nem quando o documento
> de origem vai para a lixeira. É o que permite auditar o estoque meses depois.

## 3. Status é consequência de comando, nunca um campo

Você não escolhe "Atendido" num menu suspenso. O pedido fica atendido
**porque** passou pelos comandos, e cada comando mexeu no estoque na mesma
operação.

É por isso que o formulário do pedido não tem campo de status, e por isso o
menu da linha oferece **Aprovar**, **Enviar para a expedição** e **Cancelar
pedido** em vez de um seletor. O pedido mostra um de quatro status: **Em
aberto**, **Aprovado**, **Atendido** ou **Cancelado**.

| O que você faz | O que acontece junto |
| - | - |
| Aprovar | Reserva o estoque de todas as linhas e grava o histórico |
| Despachar, na Expedição | Consome a reserva e baixa o físico |
| Cancelar pedido | Libera a reserva e marca o pedido como cancelado |

Se qualquer parte falhar, nada acontece — cada comando é uma operação só. Um
pedido nunca fica "aprovado mas sem reserva".

## 4. Tudo é por variação, e por depósito

O saldo não é do produto: é da **variação** dentro de um **depósito**. Um
produto sem grade tem uma variação padrão, invisível para você, mas o estoque
está nela.

Isso importa quando você vende a mesma camiseta em P, M e G: três saldos
distintos, três reservas distintas, e um anúncio de marketplace apontando
para a variação certa.

> [accordion] Por que não posso alterar os itens de um pedido aprovado?
>
> Porque a reserva já foi feita contra aquelas linhas. Use **Reabrir pedido**:
> ele volta para Em aberto e libera a reserva. Ajuste os itens e aprove de
> novo. O pedido que já tem NF-e ou já foi despachado não reabre.

> [accordion] Por que não consigo mover um pedido aprovado para a lixeira?
>
> Porque a mercadoria ficaria presa: indisponível para outra venda, sem
> nenhum documento na tela explicando o motivo. Cancele o pedido primeiro.

> [accordion] Por que cancelar um pedido já despachado é recusado?
>
> A mercadoria saiu. Devolver o saldo aqui inventaria estoque que não está na
> prateleira. O caminho é registrar uma [devolução](https://docs.apexx.work/vendas/devolucoes.md).

> [accordion] Por que um produto com saldo não vai para a lixeira?
>
> Excluir o cadastro esconderia um saldo que continua existindo no extrato.
> Zere o estoque antes, ou marque o produto como inativo.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.