# Processo Voltrucks — Catálogo, Orçamento, Estoque por Filial e Compras > **Fonte:** reunião de mapeamento com a Voltrucks (23/06/2026) + definições do Lucas (24/06/2026) > + planilha de **Controle de Componentes Externos** trazida pelo Joel (25/06/2026 — origem da §4.4). > Insumos: 3 áudios (`Joel processo`, `Posto Tabocão 52_3`, `Posto Tabocão 52_2`) + 1 documento do > sistema atual (Orçamento de Compra / Reposição de Estoque) + `Controle_Saida_Colaboradores.xlsx`. > Transcrições e anexos em `transcricoes/`. > > **Objetivo deste documento:** desenhar o processo de forma inteligível para **validar com o cliente** > antes de implementar o módulo de catálogo/estoque/compras no sistema novo (Eloscope). > > **Legenda de confiança:** `[OK]` confirmado na fala/documento · `[DEF]` definido pelo Lucas (24/06, > a validar com o cliente) · `[INF]` inferido pelo contexto · `[?]` a confirmar com o cliente. > > **Decisões de direção (Lucas, 24/06) — a validar:** a **OS é o checklist evoluído** (peças orçadas > entram dentro do checklist); começar **só por Rio Preto** (modelo já por filial); **margem travada > por permissão de admin**; **reserva até cancelar/concluir a OS**; **não emite NF** (entrada por XML > no backlog); **pedido ao fornecedor** por e-mail/WhatsApp com **botão de mensagem clara**; **marcas > livres/dinâmicas**; **import da planilha de fornecedor (XLSX) já no v1, com de-para passo-a-passo**. > > **Sistemas de referência — não confundir:** > - **Sistema atual em uso (`[?]` nome a confirmar = ERP InfoTem):** é o "sistema legado/atual" > referido no AS-IS (§2), onde o Joel abre a OS e monta o orçamento. É o que a nova versão da > Eloscope substitui. > - **Ferrari GPM `[OK]` = apenas benchmark:** ERP de mercado que a Voltrucks **avaliou e NÃO > fechou**. Aparece neste doc só como **referência de features desejadas** (aba de cotação, > cadastro de item por marca — §6), **não** é o sistema em uso. --- ## 1. Atores e contexto | Ator | Papel | Confiança | |---|---|---| | **Cliente / Frota** | Dono dos caminhões (ex.: *Posto Tabocão*). Aprova orçamento. | `[OK]` | | **Mecânico** | Avalia o caminhão, fotografa, monta o que precisa (hoje vira laudo/checklist). | `[OK]` | | **Renato** | Leva a **requisição de peças** ao comprador. | `[OK]` | | **Joel** | Comprador / gestor de estoque: cotação, compra, entrada e saída de estoque, margem. | `[OK]` | | **Eliane** | Recebe a lista de reposição e toca a compra (financeiro/aprovação). | `[INF]` | | **Diretor / Gerente** (Samuel?) | Autonomia para alterar margem/porcentagem. | `[OK]` papel · `[?]` quem | | **Fornecedores** | Pacaembu Autopeças, Colombo, Volvo, Kainbu, Palmaster… (peças originais/paralelas). | `[OK]` | | **Terceiro de serviço** | Retífica, usinagem, motor (ex.: *Retífica São Paulo*, *Motor Samuel*): recebe a peça, executa o serviço e devolve. **Prende a OS** até retornar. | `[OK]` | **Filiais** `[OK]`: a gestão de estoque hoje é **só na matriz (São José do Rio Preto)**. O Joel **compra para Rio Preto e para Urânia** e quer **agregar o estoque de Urânia** num segundo momento ("primeiro engrenar aqui"). No banco do sistema novo já existem 3 filiais (Rio Preto, Catanduva, Urânia). `[?]` Catanduva entra no escopo de estoque? **Volume** `[OK]`: ~1.000 itens. Pretendem **começar com uma contagem de estoque do zero**. --- ## 2. Fluxo atual (AS-IS) — ponta a ponta Hoje o processo é manual e fragmentado ("muito janelinha pra fazer um serviço só"): planilha Excel para cotar, orçamento no sistema legado, compra "na raça", entrada de nota separada do fluxo da OS. > **Como o Joel monta o orçamento hoje `[OK]`:** o mecânico avalia + fotografa e **abre a OS** no > sistema atual; o Joel então **adiciona as peças ao orçamento**. Para saber o preço rápido, ele > consulta uma **planilha própria de catálogos de peças de fornecedores** (fornecedor → item → > preço). É essa planilha que queremos trazer para dentro do sistema (ver seção 4.2). ```mermaid flowchart TD A([Caminhão chega]) --> B[Mecânico avalia + fotografa
monta o que precisa = laudo/checklist] B --> C[Renato leva a requisição
de peças ao Joel] C --> D[Joel lança peças numa
planilha Excel - cotação] D --> E[Compara fornecedores,
marcas e valores] E --> F{Tem em estoque?} F -- Sim --> G[Reserva: separa fisicamente
as peças para a OS] F -- Não --> H[Monta orçamento
escolhe peças + ajusta margem] G --> H H --> I[Envia orçamento ao cliente] I --> J{Cliente aprova?} J -- Não --> X([Fim - não autorizado]) J -- Sim --> K[Autorização de serviços e peças] K --> L{Precisa comprar?} L -- Não --> R[Vira Ordem de Serviço
baixa peças do estoque] L -- Sim --> M[Reabre cotação, separa por fornecedor
gera pedido de compra por fornecedor] M --> N[Envia pedido ao fornecedor
e-mail / WhatsApp / grupo Eliane] N --> O[Recebe nota fiscal
em mãos ou e-mail] O --> P[Baixa o XML, importa no sistema
confere com o orçamento - cód. entrada] P --> Q[Dá ENTRADA no estoque
pagamento: cartão Banco do Brasil] Q --> R R --> S[Serviço executado] S --> T([Faturamento e margem da OS]) ``` ### Sub-fluxo: reposição de estoque (sem OS) `[OK]` Itens de **estoque base** (óleo, sensores, peças de giro) são repostos **sem abrir OS** — entrada direta. O documento fotografado é exatamente isso: um **Orçamento de Compra / Reposição de Estoque** (Orç. nº 000170, fornecedor Pacaembu Autopeças, total R$ 2.178,54, cartão Banco do Brasil). ```mermaid flowchart LR A([Estoque base atinge mínimo]) --> B[Joel monta reposição
separada por fornecedor A/B/C] B --> C[Salva em PDF e envia ao grupo
Eliane: comprar essas peças] C --> D[Pedido de compra por fornecedor] D --> E[Nota fiscal + XML anexado ao pedido] E --> F([Entrada direta no estoque
sem OS]) ``` --- ## 3. Dores atuais (AS-IS) — o que o sistema novo precisa resolver | # | Dor | Confiança | |---|---|---| | 1 | **Muitos passos/janelas manuais** para uma tarefa simples (planilha → orçamento → compra → nota). | `[OK]` | | 2 | **Peça chega antes de o cliente pagar** / às vezes "fura o fluxo" para terminar o serviço. | `[OK]` | | 3 | **3 marcas = 3 cadastros** do mesmo item. Quer **1 item com as marcas dentro**. | `[OK]` | | 4 | **Não há boa interface de estoque** nem **localização** da peça visível na tela. | `[OK]` | | 5 | **OS não roda no sistema** (só o laudo/checklist) — querem integrar. | `[OK]` | | 6 | **Margem confusa** nos relatórios — quer número realista por OS (gastei 30, vendi 60). | `[OK]` | | 7 | **Entrada de nota não é simultânea** — precisa largar a OS para dar entrada. | `[OK]` | | 8 | Cadastro do produto tem **9 abas**; quer **enxugar para ~2**. | `[OK]` | --- ## 4. Fluxo proposto (TO-BE v1) — sistema novo (Eloscope) O **checklist é a OS** `[DEF]`: o mecânico abre o checklist (avalia + fotografa) e o Joel **adiciona as peças orçadas dentro dele**, escolhendo fornecedor + item das **tabelas de preço** (a planilha do Joel, agora no sistema). O **orçamento não baixa estoque**; só a **conclusão da OS** baixa. Margem **travada por permissão de admin**. Pedido ao fornecedor por **botão** (e-mail/WhatsApp, mensagem clara). ```mermaid flowchart TD subgraph OS[Checklist = Ordem de Serviço] A([Caminhão chega]) --> B[Mecânico abre o checklist
avalia + fotografa] B --> C[Joel adiciona peças ao orçamento
dentro do checklist] C --> D[Escolhe item + marca + fornecedor
preço vem da tabela do fornecedor] D --> E{Tem no estoque da filial?} E -- Sim --> F[RESERVA na filial
fica reservado até cancelar/concluir] E -- Não --> G[Marca para compra] F --> H[Margem travada
só admin/gerente altera] G --> H H --> I[Envia orçamento ao cliente] I --> J{Cliente aprova?} end J -- Não --> X([Fim - não autorizado]) subgraph CMP[Compra - se faltar peça] J -- Sim, falta peça --> K[Botão: pedido por fornecedor
e-mail/WhatsApp - mensagem clara] K --> L[Recebe peça + nota
entrada no estoque da filial] end subgraph EXE[Execução e baixa] J -- Sim --> M[OS aprovada - em execução] L --> M M --> N[Conclui a OS
BAIXA as peças do estoque] N --> O([Margem realista da OS]) end ``` > **Fora do v1 (backlog):** entrada de nota por **XML automático**, **validação de nota por IA**, > **relatórios** (mais vendidos / parados / ponto de reposição), **cotação tipo portal** (estilo > Colombo) e **expansão de filiais** (Urânia, Catanduva). > > **Em estudo (pedido do Joel):** **consulta de XML de entrada direto na Receita/SEFAZ** — puxar > automaticamente as NF-e de compra emitidas contra o CNPJ da Voltrucks (ver nota técnica §4.3). ### 4.3 Consulta de XML direto na Receita/SEFAZ `[?]` (em estudo) O caso de uso é **puxar as NF-e de entrada (compras)** que os fornecedores emitem contra o CNPJ da Voltrucks — **não** é consultar XML arbitrário por chave (o portal público da SEFAZ exige captcha e não libera XML de terceiros). > **Nota técnica (interno) — o que é preciso:** > - **Certificado digital e-CNPJ A1** da Voltrucks (arquivo `.pfx`, automatizável no servidor). A3 > (token/cartão) **não** serve para automação. > - **Web service `NFeDistribuiçãoDFe`** (ambiente nacional), TLS mútuo com o certificado; entrega por > **NSU incremental** (guardar último NSU), lotes de ~50, **janela de ~3 min** entre chamadas → > **polling agendado**, não tempo real. > - **Manifestação do Destinatário (MDe)** — "Ciência" ou "Confirmação da Operação" — em geral > necessária para baixar o **XML completo** (não só o resumo). Documentos disponíveis por **~90 dias**. > - Retorno **gzip + base64** → descompactar e parsear. > - **Caminho rápido p/ v1:** **API de terceiros** (Arquivei, NFe.io, Focus NFe, Nuvem Fiscal) que já > integra a SEFAZ (REST + webhook) — menos dev/manutenção, custo de **mensalidade**; ainda exige o > **A1**. **In-house** (DistribuiçãoDFe direto) evita mensalidade mas custa mais dev + manutenção. > - **Pré-requisito do cliente:** fornecer o **certificado A1 do CNPJ** + autorizar manifestação automática. ### Ciclo de vida do item no estoque (reserva → baixa) `[DEF]` ```mermaid stateDiagram-v2 [*] --> Disponivel: entrada (compra/reposição) Disponivel --> Reservado: peça entra no orçamento da OS Reservado --> Disponivel: OS cancelada (libera) Reservado --> Baixado: OS concluída (baixa) Baixado --> [*] Disponivel --> Disponivel: abaixo do mínimo gera reposição ``` > Reserva **dura até cancelar ou concluir** a OS (definição do Lucas) — não há expiração por tempo. --- ## 4.1 Checklist vira Ordem de Serviço `[DEF]` Hoje o checklist (`ext-voltrucks`) registra inspeção de 24 itens, problemas e fotos, e gera PDF. A ideia é **evoluí-lo para a OS**: dentro do mesmo checklist passa a existir um **orçamento de peças** (linhas com item, marca, fornecedor, quantidade, custo, margem, preço de venda e subtotal), um **status de OS** (rascunho → orçamento → aprovado → em execução → concluído/cancelado) e a **baixa de estoque** ao concluir. O laudo/fotos do mecânico continuam sendo a base; o Joel só acrescenta as peças. ## 4.2 Tabelas de fornecedor + import da planilha (de-para) `[DEF]` A planilha de catálogos do Joel vira **tabelas de preço de fornecedor** no sistema (fornecedor → item → marca → **código do fornecedor** → preço). O grande ponto: ao **importar** uma planilha/nota, as linhas vêm como *"Sensor de pressão marca X"* + código do fornecedor, e o sistema precisa **casar** isso com o item+marca do nosso catálogo. Por isso o import tem um **passo de relacionamento (de-para)**: ```mermaid flowchart TD A([Upload da planilha do fornecedor
XLSX/CSV]) --> B[Sistema lê as linhas:
descrição, código fornecedor, preço] B --> C{Código do fornecedor
já mapeado?} C -- Sim --> D[Casa automático com
item + marca do catálogo] C -- Não --> E[Passo de relacionamento:
Joel liga a linha a um item+marca
existente OU cria novo] E --> F[Salva o mapeamento
código fornecedor → item+marca] D --> G[Atualiza a tabela de preço do fornecedor] F --> G G --> H([Próximas importações casam sozinhas]) ``` > **Por que isso importa:** evita recadastrar tudo a cada nota e garante que "Sensor marca X" do > fornecedor sempre vire a mesma peça no catálogo. O **código do fornecedor** é a chave que liga os > dois mundos (era o que o Joel já fazia "na mão" no sistema antigo). ## 4.4 Componentes externos — peça que sai para terceiro (retífica/serviço) `[INF]` Hoje o Joel mantém uma **planilha paralela** (`Controle de Componentes Externos`) para peças que **saem da oficina** e vão para um **terceiro executar um serviço** — retífica, usinagem, enchimento, reparo, fabricação, adaptação, teste — antes de voltar para a OS. Exemplo: chega um caminhão que precisa de **retífica de cabeçote**; a peça vai para a *Retífica São Paulo* e, **enquanto o terceiro não devolve, a OS não pode fechar**. É o **inverso da compra** (§4/CMP): na compra a peça **chega** de fora; aqui a peça **sai** (já está na OS) e precisa **voltar**. No sistema novo isso vira uma **central de componentes externos vinculada à OS**, que **bloqueia a conclusão** até o retorno. ```mermaid flowchart TD A[Mecânico/Joel identifica peça
que precisa de serviço de 3º] --> B[Cria requisição REQ.
componente + serviço + prioridade] B --> C[Escolhe terceiro
retífica/usinagem/motor] C --> D{Cliente autoriza?
orçamento do serviço} D -- Não --> X([Cancelado / não autorizado]) D -- Sim --> E[ENVIA a peça
registra coleta + data] E --> F[Acompanha status na central
aguardando → ag.chegada] F --> G[RETORNA a peça
data de retorno] G --> H[[Libera conclusão da OS]] F -. enquanto pendente .-> BLK[/OS NÃO fecha enquanto houver
componente externo em aberto/] ``` > **Visão da central (campos da planilha do Joel — vira tela, não tabela de dados por ora):** > data solicitação · REQ. · OS / OS do fornecedor · cliente · setor/filial · componente · serviço · > terceiro · **status** (aguardando → ag. orçamento → ag. autorização → autorizado → enviado → > ag. chegada → finalizado-entregue) · coletado? + período · data de retorno · valor R$ · forma de > pagamento · **prioridade** (urgente/alta/baixa) · garantia · observações. --- ## 5. Modelo de dados-chave — item único + marcas + estoque por filial Requisito central do Joel `[OK]`: **um cadastro de item** que mostra **as marcas dentro** (original, paralela, etc.), com **quantidade por marca**, e o **estoque separado por filial**. As marcas são **livres/dinâmicas** `[DEF]`. O **código do fornecedor** liga a peça ao fornecedor (chave do de-para). ```mermaid erDiagram CATALOG_ITEM ||--o{ ITEM_BRAND : "tem marcas (livres)" CATALOG_ITEM ||--o{ STOCK : "estoque por filial" ITEM_BRAND ||--o{ STOCK : "por marca" FILIAL ||--o{ STOCK : "possui" ITEM_BRAND ||--o{ SUPPLIER_PRICE : "preço por fornecedor" SUPPLIER ||--o{ SUPPLIER_PRICE : "fornece" CATALOG_ITEM { text tipo "peça/serviço/pacote" text nome text codigo_interno "código interno do cliente" text sku "id do sistema" text grupo numeric margem_padrao text localizacao "onde está no estoque" } ITEM_BRAND { text marca "livre: original/paralela/..." numeric preco_custo } STOCK { uuid filial_id numeric quantidade numeric quantidade_minima } SUPPLIER { text nome text contato } SUPPLIER_PRICE { text codigo_fornecedor "chave do de-para" numeric preco } ``` > **Três códigos, não confundir `[DEF]`:** **código interno** (do cliente, livre, vira **coluna** na > tela) × **SKU** (id gerado pelo sistema) × **código do fornecedor** (no `SUPPLIER_PRICE`, chave do > de-para da importação). O cliente pediu o **código interno** como coluna pesquisável. > **Nota técnica (interno):** tabela canônica `mod_catalog_items` (já com `filial_id` + RLS por filial > + RAG); `codigo_interno` é campo livre indexado, distinto do `sku`/`id`. Novas tabelas: > `mod_catalog_item_brands` (marcas livres), `mod_catalog_suppliers`, `mod_catalog_supplier_prices` > (com `supplier_code` = chave do de-para), `mod_catalog_stock` (item+marca+filial). O orçamento/linhas > e a baixa de estoque vivem no checklist→OS (`ext-voltrucks`). Detalhe no plano técnico (referência futura). ### 5.1 Visão de estoque com colunas configuráveis `[OK]` Resolve a **dor #4** (poluição visual / sem boa interface de estoque). O Joel quer alternar entre um **modo consulta rápida** (poucas colunas — ex.: código interno, nome, qtd, localização) e um **modo detalhado** (marcas, custo, margem, fornecedor, mínimo). Cada usuário **mostra/oculta os campos** que quer ver; a preferência fica salva. Mesma lista, menos ruído quando o objetivo é só conferir saldo. > **Nota técnica (interno):** preferência de colunas por usuário/filial (persistida em config do > usuário). Sem impacto no modelo de dados — é camada de apresentação na tela de estoque. --- ## 6. Capacidades desejadas no sistema novo (TO-BE) > Onde a origem cita **"Sistema Ferrari (GPM)"** / **"referência GPM"**, trata-se do ERP que a > Voltrucks **avaliou como benchmark e não contratou** — é referência de feature, não o sistema em > uso (ver nota no cabeçalho). O sistema atual deles é o ERP **InfoTem** (`[?]` a confirmar). | Capacidade | Origem | Confiança | |---|---|---| | Aba de **Cotação** como início; envio a fornecedores com prazo; respostas comparáveis; sugestão pela última compra. | Joel / portal Colombo / Sistema Ferrari (GPM) | `[OK]` | | **Importação automática** cotação → orçamento → OS. | Joel | `[OK]` | | **Cadastro único de item com marcas** + entrada pela marca + qtd por marca. | Joel (referência GPM) | `[OK]` | | **Estoque por filial** (Rio Preto 1º; Urânia/Catanduva depois) com visão agregada. | Joel | `[OK]` Rio Preto/Urânia · `[?]` Catanduva | | **Reserva** de estoque ao entrar no orçamento; **baixa** só na OS. | Joel | `[OK]` | | **Travar margem** (padrão 80%) por **permissão** (diretor/gerente) **ou** por **classe de cliente (A/B/C/D)**. | Joel | `[OK]` ideia · `[?]` qual regra adotar | | **Pedido de compra por fornecedor** + envio e-mail/WhatsApp + **anexar XML** → entrada automática. | Joel | `[OK]` | | **Código do fornecedor** vinculado ao item (casar nota). | Joel | `[OK]` | | **Validação da nota por IA** (conferir itens lançados vs nota). | Eloscope (proposta na reunião) | `[INF]` | | **Relatórios:** mais vendidos, parados, **ponto de reposição** (comprou dia 10 → repor dia 20). | Joel | `[OK]` | | **Localização** da peça no estoque visível na tela inicial. | Joel | `[OK]` | | **Código interno** do cliente como **coluna** pesquisável (além do SKU e do código do fornecedor). | Joel | `[OK]` | | **Visão de estoque com colunas configuráveis** (mostrar/ocultar campos: consulta rápida × detalhado) — reduz poluição visual. | Joel | `[OK]` | | **Consulta de XML de entrada direto na Receita/SEFAZ** (puxar NF-e de compra do CNPJ). | Joel | `[?]` em estudo | | **Margem realista por OS** (custo × venda × %). | Joel | `[OK]` | | **Central de componentes externos** (retífica/serviço de 3º) vinculada à OS, com status, prioridade, valor e **bloqueio de conclusão da OS** até o retorno da peça. | Joel (planilha 25/06) | `[OK]` | | **Estoque base** (óleo, sensores) reposto sem OS. | Joel | `[OK]` | | Integração **OS ↔ checklist/laudo** (mecânico fotografa e avalia). | Joel / Eloscope | `[OK]` | | **Contagem de estoque do zero** na largada (~1.000 itens). | Joel | `[OK]` | --- ## 7. Definições do Lucas (24/06) — a validar com o cliente | # | Pergunta | Definição | |---|---|---| | 1 | Filiais no escopo | Começar **só por Rio Preto**; testar e depois expandir (Urânia/Catanduva). Modelo **já por filial** desde o início. | | 2 | Regra de margem | **Travar por permissão de admin** — reusar o usuário administrador; gerentes com acesso adm alteram. (Sem tabela A/B/C/D por ora.) | | 3 | Reserva de estoque | Reserva ao orçar; **volta só ao cancelar ou concluir** a OS (sem expiração por tempo). | | 4 | Emissão de nota | **Não emite NF** pelo sistema (por ora). **Consulta de XML de entrada via SEFAZ em estudo** (requer certificado A1 do CNPJ — ver §4.3); entrada por XML automático no backlog. | | 5 | Pedido ao fornecedor | **Simples: e-mail e WhatsApp**, com **botão** de mensagem clara (sem disparo fora de contexto). Portal estilo Colombo no backlog. | | 6 | Marcas | **Livres e dinâmicas** (não lista fechada). | | 7 | OS no sistema novo | **Evoluir o checklist para virar a OS** (peças orçadas dentro dele). | | 8 | Validação de nota por IA | **Backlog.** | > **Ponto de atenção em aberto `[?]`:** import da planilha/nota traz *"Sensor marca X"* + código do > fornecedor — o **passo de de-para** (seção 4.2) precisa ser validado com o Joel: como ele prefere > casar/criar item+marca na importação (em lote, um a um, sugestões automáticas?). > > **Componentes externos (§4.4) `[?]`:** a central no sistema novo **substitui** a planilha atual de > Controle de Componentes Externos? Quem **controla o prazo de retorno e cobra o terceiro** — Joel, > Renato ou o mecânico? O **bloqueio de conclusão da OS** deve ser automático ou só um alerta? --- ## 8. Próximo passo 1. **Validar este mapa com a Voltrucks** (Joel + gestão) — principalmente o fluxo do checklist→OS (seção 4/4.1), o de-para da importação (4.2) e a **central de componentes externos** (4.4). 2. Ajustar conforme o retorno. 3. Só então retomar o **plano técnico de implementação** (já desenhado: `mod_catalog_items`, marcas, fornecedores + preços, `mod_catalog_stock`, import com de-para, checklist→OS com orçamento).