# Kreative TMS - Roadmap Vivo Este arquivo guarda as ideias, decisoes e proximos passos do projeto Kreative TMS / Torre / Rotas. Ele deve ser atualizado sempre que surgir uma boa ideia para nao depender da memoria da conversa. Inicio oficial do projeto: 09/07/2026. ## Legenda - `[x]` Feito - `[~]` Parcial / em andamento - `[ ]` Pendente ## Controle de Status ### Arquitetura e Base SaaS - [x] Projeto Laravel/Filament criado e publicado em `tms.kreativesistemas.com.br`. - [x] Login por dominio/tenant. - [x] Banco central `tms_kreative`. - [x] Bancos operacionais dedicados por tenant. - [x] Modulos por tenant em `modules` e `tenant_modules`. - [x] Ordenacao inicial do menu por area. - [~] Ocultacao de menus conforme modulo contratado. - [ ] Subdominios comerciais futuros apontando para o mesmo Laravel. ### Operacao - [x] Importador XML NFe. - [x] Cadastro automatico de cliente/remetente pela importacao XML. - [x] Cadastro automatico de destinatario pela importacao XML. - [x] Tabela de notas fiscais. - [x] Tabela de itens da NFe. - [x] Coletas com numeracao automatica. - [x] Romaneios com numeracao automatica. - [x] Sequencias operacionais configuraveis por tenant para coleta, romaneio e cargas disponiveis. - [x] Vinculo de NFs ao romaneio. - [x] Bipagem/manual de NF em romaneio. - [x] Baixa rapida de coletas pela listagem. - [x] Ocorrencia rapida de coletas pela listagem. - [x] Alocacao de coleta para motorista e veiculo antes da baixa. - [~] Coleta Rapida com busca de remetente/destinatario por CNPJ e local de coleta por remetente, destinatario ou outro CEP. - [~] Coletas automaticas por cliente. - [~] Modulo de Cargas Disponiveis / Pre-romaneio. - [~] Interesses/negociacao de motoristas em cargas disponiveis. - [ ] API externa para receber documentos JSON. - [ ] Pesquisa/importacao de NFe pela chave de acesso quando o cliente nao enviar XML por email ou integracao. - [~] Roteirizacao assistida. ### Historico Operacional - [x] Tabela unica `eventos_operacionais`. - [x] Registro de NF importada/criada/editada. - [x] Registro de coleta criada/editada. - [x] Registro de NF romaneada/realocada/desvinculada. - [x] Registro de ocorrencia e ocorrencia tratada. - [x] Registro de comprovante. - [~] Tela de consulta do historico pelo SAC. - [ ] Eventos vindos do app motorista. - [ ] Eventos de localizacao lat/long em tempo real. ### Torre de Controle - [x] Modulo Torre separado no menu. - [x] Dashboard inicial com cards. - [x] Painel de controle pos-login com cards de NFs, coletas, ocorrencias e veiculos. - [x] Controle de Operacoes separado da dashboard. - [~] Linha operacional inspirada na torre atual. - [ ] Graficos avancados. - [ ] Mapa de calor. - [ ] Mapa com posicao dos veiculos. - [ ] Indicadores por transportador. ### SAC - [x] Modulo SAC no menu. - [x] Consulta de documentos por NF/chave/CT-e/coleta. - [x] Visualizacao de historico operacional. - [x] Exibicao de integracao do documento conforme agente do cliente e movimento operacional. - [x] Ocorrencias movidas para SAC. - [x] Comprovantes movidos para SAC. - [~] Pendencias abertas. - [ ] Tratativas mais completas por responsavel. - [~] Tratativa de ocorrencias em lote por placa/romaneio: - tornar o badge amarelo `OCORRÊNCIA` da Torre clicável e abrir a tratativa em modal, sem sair do Controle de Operações; - abrir movimentos de uma placa/romaneio; - listar no modal as NFs/coletas em ocorrência, com motivo, descrição, data/hora, destinatário e situação da tratativa; - selecionar varias NFs/coletas com ocorrencia; - permitir tratar cada ocorrência individualmente dentro do mesmo modal; - aplicar uma unica tratativa para todos os documentos selecionados; - replicar motivo de nao entrega, observacao, responsavel e status de ciencia/tratativa; - permitir marcar reentrega para os selecionados; - permitir realocar reentrega no mesmo veiculo/romaneio ou em novo veiculo/romaneio para data futura, geralmente dia seguinte. - [x] primeira etapa: modal no badge, selecao, tratativa individual/geral e reprogramacao preservando motorista, placa e numero do romaneio; - [ ] evoluir o modal para permitir troca opcional de motorista, veiculo e romaneio na reentrega. - [ ] Alertas de SLA e ocorrencias sem tratativa. ### Frota - [x] Modulo Frota no menu. - [x] Motoristas movidos para Frota. - [x] Veiculos movidos para Frota. - [~] Tela base de Checklist. - [ ] Checklist pelo app motorista. - [ ] Fotos por item do checklist. - [ ] Manutencao. - [ ] Pneus. - [ ] Multas. - [ ] Documentos da frota. ### Cadastros e Organizacao Comercial - [x] Clientes. - [x] Destinatarios. - [x] Filiais. - [x] Transportadores. - [x] Vendedores/Supervisores. - [~] Permissao por filial. - [ ] Perfil de usuario por tenant. - [ ] Permissao por acao/status. - [ ] Menu personalizado por perfil/usuario. ### Integracoes, Fiscal e Financeiro - [x] Campos principais de integracao nas NFs. - [x] Agente integrador por cliente. - [~] Dados da empresa/tenant com CNPJ, endereco, logos e certificado digital A1. - [ ] Logs detalhados de integracao por payload/resposta. - [ ] API externa com exportacao marcada. - [ ] Tabelas de frete. - [ ] Fechamento financeiro. - [ ] CT-e. - [ ] MDF-e. - [ ] CIOT. - [ ] Sequencias fiscais para CT-e/MDF-e por emitente, filial, serie e ambiente. ## Decisoes de Arquitetura - Manter um unico projeto Laravel/Filament para TMS, Torre, Rotas, SAC, Frota, API e demais modulos. - Usar `tms.kreativesistemas.com.br` como entrada principal neste momento. - Subdominios futuros como `torre.kreativesistemas.com.br`, `rotas.kreativesistemas.com.br` e `api.kreativesistemas.com.br` podem apontar para o mesmo Laravel, apenas mudando entrada visual/redirect. - Cada cliente/tenant deve ter banco operacional dedicado, seguindo padrao como `tms_cliente_x`. - Banco central `tms_kreative` controla tenants, usuarios, modulos, cPanel/configuracoes e identidade. - Login usa campo `dominio` para identificar o tenant e conectar no banco correto. - Modulos sao habilitados por tenant. A ordem visual atual do menu deve priorizar: 1. Torre de Controle 2. Operacao 3. SAC 4. Frota 5. Cadastros 6. Administracao - Torre de Controle deve aparecer primeiro quando o tenant tiver modulo `torre_controle`. - Se o cliente usar apenas TMS e nao contratar Torre, a Torre deve ficar oculta. ## Permissoes e Perfis - Criar perfis por tenant, por exemplo: - Admin do cliente - Operacao - SAC - Frota - Comercial/Vendedor - Supervisor/Gerente - Consulta - Vincular usuarios a perfis. - Permitir definir quais modulos/menu cada perfil visualiza. - Permitir pagina inicial padrao por perfil. - Permitir controlar acoes por perfil: consultar, criar, editar, excluir, alterar status, baixar, tratar ocorrencia. - Permitir controlar filiais por usuario. - Permitir vendedor ver apenas notas/clientes relacionados a ele. - Permitir supervisor ver grupo de vendedores supervisionados. - No futuro, permitir personalizacao individual da ordem do menu por usuario. ## Operacao - Operacao e a porta de entrada dos documentos e deve ficar logo apos Torre no menu. - Importador XML deve aceitar multiplos arquivos. - Processar lotes de XML com limite seguro para nao sobrecarregar servidor. - Importacao de XML deve: - criar/atualizar nota fiscal; - criar itens da NFe; - cadastrar remetente como cliente quando nao existir; - cadastrar destinatario quando nao existir; - registrar historico operacional. - Criar endpoint API para receber documentos via JSON para clientes que usam TMS proprio e contratam apenas Torre/Rotas. - Avaliar servico online ou integracao fiscal para consultar NFe/XML digitando apenas a chave NFe, para casos em que o cliente nao envia XML por email nem por API. - Esta consulta por chave NFe deve considerar viabilidade tecnica, certificado digital, permissao legal e custo do servico terceiro. - Notas fiscais devem ser registro unico, sem duplicar a mesma NF a cada tentativa de entrega. - Status e mudancas devem ir para historico operacional. - Coletas devem ter numeracao automatica. - Romaneios devem ter numeracao automatica. - Sequencias operacionais de coleta e romaneio devem permitir informar o ultimo numero usado no sistema anterior para continuar sem conflito. - Ao criar romaneio, selecionar motorista, veiculo e NFs. - Em romaneio manual, usuario pode bipar NF por leitor de codigo de barras. - Em roteirizacao futura, sistema sugere NFs por veiculo/motorista automaticamente. - [~] Validacao de enderecos no roteirizador: - validar somente documentos selecionados para rota; - gravar latitude/longitude em `destino_latlong`; - parametrizar fornecedor, endpoint, usuario e token por tenant; - evoluir para suporte a Google Maps, HERE Maps ou outro fornecedor quando necessario. - Validar capacidade por peso, volume, valor de NF/seguro, tipo de veiculo, regiao, jornada e disponibilidade. - [ ] Para clientes com perfil distribuidor, permitir limitar a quantidade de veiculos liberados por transportador na roteirizacao: - abrir modal de distribuicao por transportador; - informar quantos veiculos cada transportador pode disponibilizar na rota do dia; - exemplo: Transportador A com 5 veiculos, B com 3, C com 2; - enviar esta restricao para o motor de IA/roteirizacao junto com notas, veiculos e motoristas; - permitir ajuste manual antes de confirmar as rotas. - [ ] Criar regra futura de rodizio/equilibrio entre transportadores: - evitar que um transportador fique sempre com menos movimentos; - considerar perfil de atendimento, regiao, tipo de veiculo e historico operacional; - permitir que o usuario force excecoes quando a operacao exigir. - Coletas devem ter cliente como remetente/solicitante por padrao. - Criar coletas automaticas por cliente: - marcar cliente com coleta automatica; - definir dias da semana; - definir destino fixo ou "Diversos"; - gerar coletas do dia; - permitir desmarcar/excluir coleta automatica gerada quando nao for usar. ## Cargas Disponiveis / Pre-romaneio - [x] Criar modulo de cargas disponiveis como uma etapa anterior ao romaneio. - [x] A carga disponivel funciona como um pre-romaneio, contendo: - notas fiscais vinculadas; - origem; - destino; - peso; - volume; - tipo de veiculo necessario; - valor de frete; - valor de pagamento previsto para motorista/agregado; - observacoes e restricoes. - [x] Neste momento ainda nao existe motorista nem veiculo definido. - [x] Tela deve listar cargas disponiveis por status: - aberta; - divulgada; - em negociacao; - aceita; - convertida em romaneio; - cancelada. - [ ] Motoristas agregados podem receber notificacao de cargas disponiveis quando: - ja fizeram viagem para o transportador/distribuidor; - possuem cadastro liberado; - autorizaram receber notificacoes. - [ ] Divulgacao pode ser feita via WhatsApp, enviando: - origem; - destino; - peso; - tipo de veiculo; - valor proposto; - instrucoes para demonstrar interesse. - [ ] Quando o motorista responder algo como "quero esta viagem", o sistema registra interesse e inicia negociacao. - [ ] Negociacao pode ajustar: - valor de pagamento; - data/hora de coleta; - motorista; - veiculo; - observacoes. - [x] Ao aceitar a carga, o pre-romaneio deve virar romaneio operacional. - [ ] Depois, se aplicavel, o romaneio pode virar MDF-e. - [~] Historico operacional deve registrar: - carga criada; - carga divulgada; - motorista notificado; - motorista interessado; - proposta aceita/recusada; - carga convertida em romaneio. - [x] Criar tabela base para interesses de motoristas em cargas disponiveis. - [ ] Criar tela de negociacao dos interesses da carga. - [ ] Conectar respostas do WhatsApp aos interesses da carga. - Futuramente o modulo pode ajudar distribuidores e transportadores a acionar agregados com mais controle e menos conversa perdida no WhatsApp. ## Historico Operacional - Usar tabela unica `eventos_operacionais` para NF, coleta e demais eventos. - Registrar: - documento registrado/importado; - romaneado; - em rota; - entregue/coletado; - ocorrencia; - ocorrencia tratada; - realocada para novo romaneio/veiculo/dia; - desvinculada de romaneio; - finalizada/cancelada; - comprovante registrado; - posicoes vindas do app. - Cada evento deve guardar: - data/hora; - usuario do painel; - canal (`painel`, `xml`, `app`, `api`, `integracao`); - filial; - motorista; - veiculo/placa; - romaneio; - status anterior e novo; - latitude/longitude quando vier do app; - payload livre. - No app motorista, quando o evento vier do motorista, registrar motorista e canal `app`. ## Torre de Controle - Torre e a tela viva do sistema, focada em acompanhamento operacional. - Separar no menu: - Dashboard: indicadores, graficos, cards e mapa. - Controle de Operacoes: linhas por veiculo/romaneio. - Dashboard deve mostrar: - entregas agrupadas por endereco; - coletas agrupadas por endereco; - ocorrencias totais, tratadas e a tratar; - transferencias; - reentregas; - veiculos em rota; - filtros por data e filial. - [ ] Tornar os cards da dashboard clicaveis e abrir a listagem detalhada correspondente: - preservar o periodo e a filial selecionados na dashboard; - aplicar automaticamente a regra/filtro do card clicado; - listar as notas fiscais ou movimentos que formaram o indicador; - exibir os dados relevantes de cada assunto, incluindo NF, CT-e, cliente, destinatario, romaneio, motorista, veiculo, previsao, entrega, status e ocorrencia quando aplicavel; - nos cards de OTIF e entregas fora do prazo, demonstrar previsao, data efetiva da entrega e motivo da classificacao; - respeitar as permissoes de filial e acesso do usuario. - Controle de Operacoes deve seguir conceito da tela antiga: - placa; - icone de rodizio/SP; - icone de agendamento mudando cor conforme proximidade; - tipo proprio/agregado; - status de acesso do app/celular; - tipo de veiculo; - motorista e CPF; - peso total; - manifesto/romaneio e data de integracao/criacao; - icone de refrigerado/congelado; - status ligado/parado/em rota; - contadores de entregas, coletas, transferencias, reentregas e documentos; - percentual executado. - Criar configuracoes por tenant para a Torre: - prazo em minutos/horas para calendario de agendamento mudar de azul para amarelo; - regra para calendario ficar vermelho quando agendamento vencer sem chegada/entrega; - prazo maximo em status chegada antes do relogio mudar de azul para vermelho; - permitir o cliente ajustar esses parametros no menu de configuracoes. - [ ] Criar parametros de OTIF por tenant/cliente: - habilitar ou desabilitar a participacao do cliente no calculo de OTIF; - definir se uma entrega sem `previsao_entrega_at` deve permanecer fora do OTIF ou receber previsao automaticamente; - quando o preenchimento automatico estiver habilitado, permitir escolher como base a data de integracao ou a data de emissao; - previsao contendo somente a data (`00:00:00`) deve considerar todo o dia como prazo; - previsao contendo data e horario deve considerar o horario exato como limite e tambem caracterizar agendamento; - manter identificada a origem da previsao: recebida pela integracao ou gerada pela parametrizacao do cliente. - Criar mapa/heatmap futuro: - documentos por regiao; - veiculos por regiao; - veiculos em rota; - veiculos fora do estado; - ultimo ponto do app por lat/long; - atualizacao em tempo real ou quase real. - Criar indicadores por transportador para perfil distribuidor. ## SAC - Criar modulo SAC para consulta, acompanhamento e pendencias. - Central de consulta deve buscar: - NF; - chave NFe; - CT-e; - coleta. - Mostrar resumo do documento. - Mostrar linha do tempo do historico operacional. - Mostrar ocorrencias e comprovantes do documento. - Mostrar pendencias abertas. - Permitir lancar tratativa/ciencia de ocorrencia. - Ocorrencias devem ter controle tratada x a tratar. - SAC deve ser modulo visivel para perfis que precisam acompanhar clientes, ocorrencias e comprovantes. ## Frota - Criar modulo Frota para: - motoristas; - veiculos; - checklist; - manutencao; - pneus; - multas; - documentos da frota. - Checklist deve futuramente ser feito pelo app motorista. - Checklist deve permitir fotos dos itens apontados. - Se item reprovar, abrir pendencia automaticamente. - Criar tipos de checklist por tipo de veiculo. - Guardar historico de checklist por veiculo, motorista e rota. ## Roteirizacao / Rotas - Roteirizacao deve ficar ligada visualmente a Torre. - O usuario pode clicar em "Roteirizar" para sugerir agrupamento de NFs por veiculo. - O modulo deve ser desacoplado, trabalhando com multiplos provedores e demonstrando o ROI gerado ao cliente. - Considerar: - peso; - volume; - valor da NF e limite de seguro; - tipo de veiculo; - capital/interior/regiao; - janela de entrega/agendamento; - jornada de motorista; - disponibilidade do veiculo; - refrigerado/congelado; - transferencias. - Inicialmente fazer roteirizacao assistida, com sugestao do sistema e usuario confirmando. - Depois evoluir para roteirizacao mais automatizada. ### Roteirizador - Arquitetura - [ ] Criar interface `RouteProvider` para nao depender de um unico fornecedor. - [~] Usar ArcGIS como provedor principal na fase inicial. - [ ] Criar implementacao futura para Google Route Optimization. - [ ] Criar implementacao futura para HERE. - [ ] Preparar suporte para novos provedores sem reescrever a tela operacional. - [ ] Registrar todo consumo por provedor: - tenant/cliente; - usuario; - data/hora; - provedor; - quantidade de rotas; - quantidade de documentos; - veiculos utilizados; - custo estimado; - retorno bruto do provedor; - status do job. ### Roteirizador - Estrategia Comercial - [ ] Cobrar por rota otimizada, e nao por nota fiscal. - [ ] Registrar custo por rota, custo da API, margem e provedor utilizado. - [~] Criar pacotes mensais por quantidade de rotas. - [ ] Medir custo real por cliente para acompanhar margem. - [~] Criar CRUD administrativo central para planos de roteirizacao, com faixas de volume, preco por rota e historico de reajustes. - Tabela comercial inicial: - Rota Start: ate 500 rotas mensais, R$ 6,00 por rota. - Rota Essencial: 501 a 1.000 rotas mensais, R$ 5,50 por rota. - Rota Operacional: 1.001 a 1.500 rotas mensais, R$ 4,50 por rota. - Rota Performance: 1.501 a 2.000 rotas mensais, R$ 3,75 por rota. - Rota Scale: 2.001 a 3.000 rotas mensais, R$ 3,00 por rota. - Rota Enterprise: acima de 3.000 rotas mensais, R$ 2,50 por rota. - Exemplo discutido: - 3.300 NFs por mes; - media de 3 NFs por rota; - aproximadamente 1.100 rotas por mes; - ArcGIS Fleet Routes: US$100 por 1.000 rotas, cerca de US$0,10 por rota. ### Roteirizador - Dashboard Executivo - [ ] Exibir rotas utilizadas no periodo. - [ ] Exibir custo do modulo. - [ ] Exibir km economizados. - [ ] Exibir combustivel economizado. - [ ] Exibir horas extras evitadas. - [ ] Exibir veiculos evitados. - [ ] Exibir economia financeira estimada. - [ ] Exibir ROI. - [ ] Exibir CO2 evitado. ### Dashboard Executivo - KPIs Logisticos e Financeiros - [ ] Criar uma area de KPIs com filtros por periodo, filial, cliente, motorista, veiculo e tipo de movimento, respeitando as permissoes do usuario e do tenant. - [ ] Permitir comparacao automatica com o periodo anterior equivalente e exibir variacao absoluta e percentual. - [ ] Permitir configurar metas e faixas visuais por tenant, com sinalizacao verde, amarela e vermelha. - [ ] Permitir clicar em cada card para abrir a composicao do indicador e a listagem dos documentos, movimentos ou veiculos considerados. - [ ] Card `Entregas realizadas`: quantidade de entregas concluidas no periodo. - [ ] Card `Entregas no prazo (OTD)`: percentual de entregas concluidas ate a data/hora prometida. - [ ] Card `Entregas com sucesso`: percentual de entregas concluidas sem ocorrencia, devolucao ou insucesso. - [ ] Card `Entregas em atraso`: quantidade de entregas concluidas depois da previsao e entregas ainda abertas com previsao vencida. - [ ] Card `Taxa de insucesso`: percentual de entregas com ocorrencia impeditiva, devolucao ou tentativa sem sucesso. - [ ] Card `Km rodados`: distancia real percorrida no periodo, priorizando telemetria e utilizando distancia planejada apenas quando identificada como estimativa. - [ ] Card `Km por entrega`: km efetivamente rodados dividido pela quantidade de entregas realizadas. - [ ] Card `Custo por entrega`: custo operacional total do periodo dividido pela quantidade de entregas realizadas. - [ ] Card `Custo por km`: custo operacional total dividido pelos km efetivamente rodados. - [ ] Card `Ocupacao da frota`: peso e/ou volume carregado em relacao a capacidade cadastrada dos veiculos. - [ ] Card `Utilizacao da frota`: percentual da frota disponivel que realizou ao menos uma saida no periodo. - [ ] Card `Tempo medio de entrega`: tempo medio entre a saida efetiva e a conclusao da entrega. - [ ] Card diferencial `Economia gerada`: comparar o cenario original com o cenario roteirizado e demonstrar km, litros, horas de motorista, custo operacional evitado e economia financeira total. - [ ] Card diferencial `Eficiencia da roteirizacao`: exibir o percentual de reducao de km e os valores antes e depois da otimizacao. - [ ] Preservar os cenarios original, planejado e executado para permitir auditoria dos calculos de economia e eficiencia. - [ ] Parametrizar custo por km, consumo medio, preco do combustivel, custo/hora do motorista e demais componentes financeiros por tenant, vigencia e tipo de veiculo. - [ ] Nao apresentar valores estimados como realizados: todo KPI deve identificar a origem do dado e sinalizar quando o resultado for parcial ou estimado. - [ ] Definir previamente as ocorrencias que representam insucesso, pois ocorrencias apenas informativas nao devem necessariamente reduzir a taxa de sucesso. - [ ] Considerar no OTD somente documentos que tenham previsao valida; documentos sem data prometida devem ser separados e nao distorcer o indicador. ### Roteirizador - Centro de Performance Logistica - [ ] Transformar o modulo em ferramenta de gestao, mostrando economia e eficiencia em vez de apenas consumo de API. - [ ] Comparar rotas planejadas x rotas executadas. - [ ] Medir ocupacao dos veiculos. - [ ] Medir taxa de consolidacao de documentos por rota. - [ ] Medir custo por entrega. - [ ] Medir economia acumulada mensal e anual. - [ ] Medir tempo medio de planejamento. ### Roteirizador - Roadmap de Provedores - [~] Fase 1: ArcGIS. - [ ] Fase 2: Google. - [ ] Fase 3: HERE. - [ ] Fase 4: selecao dinamica do provedor. - [ ] Fase 5: KRoute Engine. ### KRoute Engine - [ ] Criar camada propria do Kreative TMS para roteirizacao. - [ ] O cliente nao escolhe APIs diretamente; ele usa o motor KRoute. - [ ] O KRoute seleciona o provedor conforme configuracao, custo, disponibilidade ou estrategia comercial. - [ ] Permitir troca de provedor sem mudar a experiencia do usuario final. ## App Motorista - App atual nao sera migrado agora. - Futuramente pode ser migrado para Flutter. - App deve enviar: - baixas de entrega; - baixas de coleta; - ocorrencias; - fotos/comprovantes; - localizacao lat/long; - checklist de frota; - status de acesso/log do motorista. - Eventos vindos do app devem alimentar `eventos_operacionais`. ## Distribuidor x Transportador - Tenant deve ter perfil de cliente: - Transportador - Distribuidor - Transportador normalmente controla frota propria/agregada e operacao de transporte. - Distribuidor pode contratar um ou mais transportadores. - Para perfil distribuidor, criar cadastro de transportadores com: - CNPJ; - nome; - sigla; - status. - Veiculo pode ser vinculado a transportador. - Manifesto/romaneio pode herdar transportador pelo veiculo. - Torre deve permitir indicadores por transportador: - tempo de entrega; - eficiencia; - ocorrencias; - atrasos; - produtividade. - Criar relatorio por periodo, com data inicial e final, para analise de transportadores: - quantidade de rotas por transportador; - quantidade de entregas por rota; - quantidade de entregas por placa; - quantidade de veiculos utilizados por transportador; - percentual de entregas realizadas; - ocorrencias por transportador, placa e motorista; - quebras de veiculo, quando houver ocorrencia/tipo especifico; - motoristas com documentos vencidos, como CNH; - veiculos antigos ou fora do perfil desejado; - comparativo de eficacia entre transportadores. ## Filiais - Criar cadastro de filiais com sigla e dados completos. - Exemplos: SPO, CPQ, BHZ. - Usuario pode acessar uma ou mais filiais. - Gerente/supervisor pode ver varias filiais. - Operacao, Torre, SAC e relatorios devem respeitar permissoes por filial. - Importacao e movimentos devem guardar `filial_id` quando possivel. ## Vendedores e Supervisores - Criar base de vendedores. - Cada vendedor pode ter supervisor. - Supervisor pode ter um grupo de vendedores. - Vendedor pode estar vinculado a cliente. - Notas importadas podem herdar vendedor do cliente. - Futuramente vendedor enxerga entregas dos clientes dele para acionar reposicao/tomada de decisao. ## Financeiro / Frete / Fechamento - [x] Cadastros financeiros estruturados: contas, centros de custo, categorias, tipos de servico e formas de pagamento. - [x] Contas a pagar/receber com baixa parcial, baixa em lote, historico e estorno auditado. - [x] Cancelamento financeiro preservando usuario, data, motivo e historico. - [x] Recorrencias agrupadas com numeracao e controle da parcela atual e futuras. - [x] Relatorio financeiro com filtros, indicadores, impressao e exportacao CSV. - [x] Despesas adicionais aprovadas integradas ao contas a pagar sem duplicidade. - [ ] Proximo ciclo: fechamento de pagamento de motoristas com diaria, saida, romaneio, coleta avulsa, despesas, adiantamentos e descontos. - [x] Estrutura de regras por tenant/motorista e memoria de calculo criada, incluindo entidade explicita de saida com multiplos romaneios. - [ ] Montar conferencia e geracao dos fechamentos a partir das regras cadastradas. - Cada cliente pode ter tabela de frete propria. - Tipos de frete futuros: - frete por peso; - frete por valor de NF; - peso + percentual do valor da NF; - valor da NF + taxa administrativa; - taxa por dificuldade de entrega; - servico dedicado; - diaria por veiculo; - regras por regiao/filial/transportador. ### Motor tarifario de fretes - [ ] Construir o calculo como motor tarifario versionado, e nao apenas como um campo de valor no cliente. - [ ] Permitir mais de uma tabela por cliente, distinguindo tabela padrao, filial, regiao, cidade, UF, faixa de CEP e destinatario especifico. - [ ] Manter natureza da tabela: frete de venda, frete de compra, transferencia interna ou contratado de terceiro/agregado. - [ ] Controlar vigencia inicial/final, versao, prioridade, moeda, status e historico de alteracoes. - [ ] Bases de calculo previstas: - faixa de peso; - percentual sobre o valor da NF; - faixa de peso mais percentual da NF; - valor fixo por entrega/coleta; - valor por volume; - quilo excedente; - frete minimo; - veiculo dedicado ou diaria; - peso cubado, utilizando o maior entre peso real e cubado quando configurado. - [ ] As faixas devem aceitar decimais, ultima faixa sem limite superior e bloquear sobreposicoes ou intervalos inconsistentes. - [ ] Componentes configuraveis do frete: - frete-peso; - ad valorem; - GRIS; - pedagio; - taxa de entrega/coleta; - agendamento; - restricao de circulacao; - area de risco ou dificil acesso; - TDA/TRT; - taxa administrativa; - ajudante, descarga e outras taxas personalizadas. - [ ] Cada componente podera calcular valor fixo, percentual da NF, percentual do frete-peso, valor por kg, volume, documento, romaneio ou veiculo. - [ ] Resolver abrangencia da regra do mais especifico para o mais geral: destinatario, CEP, cidade, regiao, UF e tabela padrao. - [ ] Criar simulador antes de ativar calculo automatico nas importacoes, exibindo memoria completa e avisos de faixa/regra nao encontrada. - [ ] Ao efetivar o frete, congelar memoria do calculo no documento: tabela, versao, vigencia, faixa, peso real/cubado, valor da mercadoria, componentes, total, data, origem e usuario. - [ ] Nunca recalcular documentos historicos silenciosamente quando a tabela for reajustada; recalculo deve exigir autorizacao, motivo e auditoria. - [ ] Usar a mesma estrutura para o transportador calcular frete vendido e para embarcador/distribuidor calcular frete comprado, permitindo margem entre receita, pagamento e despesas. - [ ] Integrar posteriormente com faturamento, CT-e, CIOT e MDF-e, preservando sequencia fiscal e regras regulatorias proprias de cada documento. #### Fases de entrega 1. [x] Cadastro da tabela, cliente, natureza, versao, vigencia e abrangencia. 2. [x] Faixas de peso, excedente, percentual da NF e componentes/taxas configuraveis. 3. [x] Simulador com memoria de calculo e selecao automatica por destinatario, CEP, cidade, regiao, UF ou regra geral, sem alterar notas reais. 4. Aplicacao da tabela homologada no fluxo operacional e gravacao da memoria congelada por documento. 5. Conferencia, ajuste manual auditado e fechamento de faturamento. 6. Consumo do frete homologado nos futuros modulos CT-e, CIOT e MDF-e. ### Modulo Comercial - [x] Criar grupo Comercial separado do Financeiro e dos Cadastros gerais. - [x] Posicionar Tabelas de Frete como primeira funcionalidade comercial. - [x] Reunir Vendedores / Supervisores no modulo Comercial, preservando o vinculo existente com clientes. - [ ] Criar politicas comerciais e condicoes negociadas por cliente, servico, regiao e vigencia. - [ ] Criar regras de comissao por vendedor e supervisor. - [ ] Permitir comissao por percentual do frete, percentual da margem, valor fixo, faixa de faturamento ou combinacao de regras. - [ ] Definir o momento gerador da comissao: emissao, entrega, faturamento, recebimento ou baixa financeira. - [ ] Tratar cancelamento, devolucao, inadimplencia, estorno e reentrega sem pagar comissao duplicada. - [ ] Manter carteira de clientes por vendedor e hierarquia vendedor/supervisor. - [ ] Criar metas comerciais por receita, margem, quantidade de clientes, documentos e peso transportado. - [ ] Criar memoria de calculo e fechamento de comissoes com estados rascunho, conferido, aprovado, pago e cancelado. - [ ] Integrar o fechamento aprovado de comissao ao Financeiro/contas a pagar. - [ ] Criar dashboard comercial com vendas, margem, metas, comissoes, novos clientes e desempenho por carteira. - Criar fechamento de pagamento para transportador/motorista/agregado. - [ ] Estruturar o fechamento de motoristas por configuracao do tenant: - pagamento por diaria, considerando uma diaria por motorista/data conforme a regra contratada; - pagamento por saida operacional, permitindo mais de um romaneio na mesma saida; - considerar uma nova saida quando o motorista finalizar a anterior, retornar a empresa e iniciar outra operacao; - manter motorista, CPF, placa, horario de inicio/fim e romaneios que compuseram cada saida; - incluir coletas vinculadas ao romaneio e coletas sem romaneio, identificadas por motorista, CPF, placa e periodo; - lancar despesas da operacao, como pedagio, combustivel, ajudante, alimentacao, estacionamento e outras despesas autorizadas; - permitir adiantamentos, descontos, acrescimos e observacoes com historico de usuario/data; - apresentar memoria de calculo antes do fechamento: diarias, saidas, romaneios, entregas, coletas, despesas, adiantamentos e total liquido; - impedir pagamento duplicado da mesma diaria, saida, romaneio ou coleta avulsa em fechamentos diferentes; - permitir fechamento em rascunho, conferido, aprovado, pago e cancelado, preservando auditoria. - Criar fechamento de faturamento para cliente. - Futuramente integrar com CT-e/MDF-e quando aplicavel. ## CT-e, MDF-e e CIOT - Emissao de CT-e e MDF-e fica para ciclo futuro. - MDF-e e documento espelho do romaneio registrado na SEFAZ. - Ao entrar em MDF-e, considerar CIOT. - CT-e e MDF-e devem usar sequencia fiscal propria, separada das sequencias operacionais, respeitando emitente, filial, serie, ambiente de homologacao/producao e ultimo numero ja utilizado. - Empresa/tenant deve gerenciar seus proprios dados fiscais e certificado digital A1. - Criar alertas de vencimento do certificado digital por email/notificacao interna. - Implementar com cuidado por ser fiscal e regulatorio. - Possivel ciclo futuro: ate novembro/dezembro, buscar fechar Torre robusta e iniciar estudos de CT-e/MDF-e. ## Vale-Pedagio Obrigatorio (VPO) ### Posicionamento e regra principal - [ ] Iniciar este modulo logo apos a homologacao da Tabela de Frete e da memoria de calculo comercial. - [ ] Manter o pedagio comercial separado do Vale-Pedagio Obrigatorio: - pedagio comercial e componente da formacao do preco negociado com o cliente; - VPO e antecipacao operacional/regulatoria vinculada a viagem e nao deve ser incorporada silenciosamente como receita de frete. - [ ] Exibir ao usuario frete, VPO e total financeiro da operacao de forma clara, preservando os valores separadamente no banco e nos documentos fiscais. - [ ] Considerar a regulamentacao vigente da ANTT, inclusive a necessidade de fornecedora habilitada, antecipacao antes do embarque e registro dos dados no MDF-e quando aplicavel. - [ ] Manter referencia atualizavel das fornecedoras habilitadas pela ANTT; nunca fixar no codigo uma lista tratada como definitiva. ### Cadastro de operadoras e credenciais - [ ] Criar `Administracao > Integracoes > Operadoras de Vale-Pedagio`. - [ ] Permitir cadastrar por tenant: - operadora/fornecedora; - ambiente de homologacao ou producao; - URL base, autenticacao e webhook; - Client ID, Client Secret, token, codigo do embarcador e CNPJ contratante; - certificado, quando exigido; - timeout, quantidade de tentativas e prioridade; - operadora padrao e situacao ativa/inativa; - data, status e mensagem da ultima comunicacao. - [ ] Criptografar todas as credenciais sensiveis e nunca reapresentar segredo completo na interface. - [ ] Permitir mais de uma operadora por tenant e estrategia de contingencia controlada, sem emitir duas compras para a mesma viagem. - [ ] Preparar inicialmente conectores para Sem Parar, Repom, Bradesco, Nstech/e-Frete, Veloe e ConectCar, condicionados a contrato, documentacao e homologacao disponibilizados por cada fornecedora. ### Arquitetura de provedores - [ ] Criar contrato unico de integracao, independente da operadora, com operacoes equivalentes a: - autenticar; - cotar; - adquirir/carregar VPO; - consultar; - cancelar; - consultar utilizacao, saldo e conciliacao, quando a API disponibilizar. - [ ] Implementar cada fornecedora em adaptador proprio, sem espalhar regras especificas pelo dominio do TMS. - [ ] Versionar payloads e respostas para suportar alteracoes de API sem perder auditoria de operacoes antigas. ### Dados da viagem - [ ] Consolidar antes da cotacao/aquisicao: - contratante, CNPJ e dados do embarcador; - transportador, CNPJ/CPF e RNTRC; - motorista e CPF; - placa do cavalo, implementos, reboques e semirreboques; - quantidade de eixos e categoria tarifaria; - origem, destino e codigos IBGE; - rota prevista, distancia, pracas e porticos Free Flow; - inicio e termino previstos da viagem; - romaneios, CT-es e documentos transportados; - CIOT e MDF-e, quando existentes/aplicaveis; - valor estimado, cotado, adquirido, utilizado e saldo. - [ ] Revisar o cadastro de veiculos para garantir eixos, composicao veicular, categoria tarifaria e identificacao correta dos implementos. ### Fluxo operacional - [ ] Calcular apenas estimativa durante a roteirizacao; nao comprar VPO enquanto a rota estiver em simulacao. - [ ] Depois da confirmacao do romaneio/viagem, conferir motorista, placas, eixos, transportador, origem e destino. - [ ] Solicitar cotacao a operadora e apresentar memoria com rota, pracas, tarifas, categoria do veiculo e valor total. - [ ] Exigir aprovacao do usuario autorizado antes da compra, salvo quando houver politica de emissao automatica explicitamente habilitada. - [ ] Adquirir o VPO e armazenar protocolo, codigo, comprovante, validade e dados exigidos pelo MDF-e. - [ ] Disponibilizar consulta, conciliacao e cancelamento conforme regras e capacidades da fornecedora. - [ ] Impedir saida/encerramento fiscal quando o VPO for obrigatorio e estiver pendente, rejeitado ou inconsistente, conforme configuracao do tenant. ### Estados, seguranca e auditoria - [ ] Estados previstos: rascunho, aguardando cotacao, cotado, aguardando aprovacao, processando, emitido, utilizado parcialmente, concluido, cancelado, com erro e exige conferencia. - [ ] Criar chave idempotente por tenant/viagem/operadora para impedir compra duplicada por duplo clique, timeout ou repeticao de job. - [ ] Registrar usuario, datas, request, response, protocolo externo, codigo HTTP, tentativas e mensagem de erro. - [ ] Separar erro temporario, rejeicao cadastral, saldo insuficiente, veiculo/tag invalido e indisponibilidade da operadora. - [ ] Criar retentativa segura somente para operacoes idempotentes ou depois de consulta do estado externo. - [ ] Receber webhooks com assinatura/token, protecao contra repeticao e historico imutavel. ### Integracao com Comercial, Financeiro e Fiscal - [ ] A Tabela de Frete podera estimar o pedagio comercial, mas a aquisicao real do VPO devera gerar registro separado. - [ ] Comparar pedagio previsto na rota/tabela com valor cotado, adquirido e efetivamente utilizado. - [ ] Apropriar VPO como valor operacional segregado, sem tratar automaticamente como receita tributavel de frete. - [ ] Disponibilizar dados homologados para CT-e, CIOT e MDF-e sem redigitacao. - [ ] Vincular CIOT ao MDF-e quando aplicavel e preservar historico de retificacao, cancelamento e encerramento. - [ ] Criar conciliacao por operadora, periodo, viagem, veiculo e protocolo, com exportacao Excel/PDF. ### Fases de entrega do VPO 1. [ ] Cadastro generico de operadoras, ambientes e credenciais criptografadas. 2. [ ] Entidade de viagem/solicitacao de VPO e validacao dos dados obrigatorios. 3. [ ] Fluxo manual com valor, protocolo, comprovante, aprovacao e auditoria, permitindo uso antes da primeira API. 4. [ ] Estimativa integrada ao roteirizador e comparacao entre previsto e realizado. 5. [ ] Implementacao e homologacao do primeiro adaptador de operadora. 6. [ ] Compra, consulta, cancelamento, webhook, idempotencia e conciliacao automatizados. 7. [ ] Integracao completa com CIOT, CT-e e MDF-e. ### Referencias regulatórias iniciais - ANTT - Vale-Pedagio Obrigatorio: https://www.gov.br/antt/pt-br/assuntos/cargas/vale-pedagio-obrigatorio - ANTT - Perguntas Frequentes VPO: https://www.gov.br/antt/pt-br/assuntos/cargas/vale-pedagio-obrigatorio/perguntas-frequentes-vpo - ANTT - Fornecedoras habilitadas: https://www.gov.br/antt/pt-br/assuntos/cargas/vale-pedagio-obrigatorio/fornecedores-de-vpo-habilitadas - ANTT - CIOT Para Todos: https://www.gov.br/antt/pt-br/assuntos/cargas/ciot-para-todos-1 ## Integracoes - Campos de integracao ja previstos em NF: - orion_integracao; - canhoto_facil_integracao; - comprovei_integracao; - comprovei_rota; - lupeon_integracao; - esl_integracao; - intemobile_integracao; - intemobile_protocolo; - intemobile_tracking; - exportacao; - exportacao_data. - Cliente deve ter agente integrador: - Intemobile; - Comprovei; - Lincros; - Lupeon; - OkEntregas; - Orion; - ESL; - Canhoto Facil; - Sistema proprio. - Na listagem de NFs, mostrar integracao relevante conforme agente do cliente. - API externa deve marcar `exportacao = 1` e `exportacao_data` quando cliente consultar via API. ## Rede / Historico Entre Filiais e Redespacho - Ideia futura: criar uma especie de "universo" ou trilha da NF entre filiais/transportadores. - Quando transportador/filial bipar entrada, romaneio ou manifestar a chave, registrar ponto da NF. - Permitir saber: - onde a NF nasceu; - por quais filiais passou; - qual transportador recebeu; - ultimo ponto conhecido; - onde pode ter ocorrido extravio. - Funciona melhor quando o cliente usa nosso TMS/app em todas as etapas. - Para clientes que usam apenas Torre, dependera de integracao/API enviada pelo TMS deles. ## WhatsApp / Consentimento e Governanca de Notificacoes - [ ] Criar modulo nativo de consentimento por tenant, sem reutilizar o codigo legado. - [ ] Relacionar o consentimento diretamente aos cadastros de remetente e destinatario. - [ ] Centralizar os telefones em formato normalizado e manter uma regra unica para comparacao. - [ ] Tratar numeros brasileiros com e sem o nono digito como o mesmo contato, sem gerar consentimentos duplicados. - [ ] Manter os estados de consentimento: - pendente; - ativo; - bloqueado. - [ ] Exibir badges e filtros de consentimento nas listagens de remetentes e destinatarios. - [ ] Criar webhook centralizado para receber comandos de ativacao e bloqueio. - [ ] Reconhecer variacoes seguras dos comandos `parar notificacao` e `receber notificacao`. - [ ] Confirmar ao destinatario somente depois de validar que a alteracao foi persistida no banco. - [ ] Registrar historico completo de consentimento: - mensagem recebida; - data e hora; - telefone recebido pelo provedor; - status anterior e novo; - origem e identificador do webhook; - erro de processamento, quando houver. - [ ] Bloquear qualquer envio quando o consentimento estiver bloqueado, independentemente dos alertas habilitados no cadastro. - [ ] Exigir numero de WhatsApp validado antes do primeiro envio, conforme parametro do tenant. - [ ] Separar claramente: - cadastro ativo/inativo; - numero WhatsApp valido/inexistente; - consentimento pendente/ativo/bloqueado; - tipos de alertas habilitados. - [ ] Processar notificacoes em filas com idempotencia, intervalo entre mensagens, limite de tentativas e protecao contra disparos acumulados. - [ ] Manter auditoria de envio, retorno do provedor, entrega, leitura, falha e bloqueio. - [ ] Permitir mensagens configuraveis por tenant, com variaveis documentadas e validacao antes de salvar. - [ ] Permitir resposta automatica opcional; campo vazio ou `0` nao deve responder conversas comuns. - [ ] Criar testes automatizados para normalizacao de telefone, comandos de consentimento, duplicidade, falha de banco e bloqueio de envio. - [ ] Preparar integracao com o aplicativo e com as notificacoes de rota, chegada, entrega, ocorrencia, coleta e comprovante. ### Regra principal de seguranca - A ordem das barreiras para envio deve ser: 1. servico do tenant ativo; 2. instancia WhatsApp conectada e validada; 3. telefone existente e validado; 4. consentimento nao bloqueado; 5. alerta do evento habilitado; 6. mensagem ainda nao enviada para o mesmo evento. - Nenhuma configuracao posterior pode ignorar um consentimento bloqueado. - O cadastro do remetente/destinatario pode continuar ativo mesmo quando apenas as notificacoes estiverem bloqueadas. ## App Motorista / Comprovantes / OCR - Criar aplicativo novo baseado na estrutura do TMS Kreative, em vez de depender da API antiga. - App deve nascer hibrido, com suporte a Android e iOS desde o inicio. - Usar Flutter como tecnologia principal do app, por atender Android e iOS com uma base de codigo. - Desenvolvimento e validacao inicial serao feitos em Android/APK, testando em aparelho fisico Motorola G52. - Testes/build iOS entram quando houver ambiente Mac/Xcode disponivel. - Manter o app em projeto separado do Laravel, consumindo APIs do TMS Kreative. - Primeiro prototipo: - splash; - login; - listagem de entregas e coletas do motorista; - movimentos em aberto; - navegacao inferior com 3 itens: - area esquerda reservada para checklist, despesas extras e futuros recursos; - item central para roteiro/listagem de entregas e coletas; - item direito para movimentos em aberto. - Backend do TMS deve expor APIs mobile proprias: - login do motorista por tenant/transportador; - consulta de movimentos por motorista/data; - envio futuro de chegada, entrega, coleta, ocorrencia, comprovante e localizacao. - App deve contemplar: - login por transportador/tenant; - leitura/bipagem de documentos; - baixa de entrega; - baixa de coleta; - ocorrencias; - comprovante por foto; - assinatura digital; - logs de localizacao; - dados do aparelho. - No momento da captura do comprovante, prever OCR/validacao da imagem. - Permitir configurar perfis/formatos de documento para orientar a captura e validacao: - canhoto de entrega, geralmente mais retangular; - nota fiscal, geralmente maior; - CT-e/minuta/documento mais quadrado ou com outro enquadramento. - OCR deve validar qualidade da imagem e leitura minima antes de aceitar/enviar: - imagem legivel; - documento dentro do enquadramento; - possivel leitura de numero/chave/NF/CT-e quando aplicavel; - status de aprovado, reprovado ou nao processado. - Integrar o resultado com os campos ja previstos, como `ia` e comprovantes do documento. ## UI / Layout - Filament continua para cadastros/admin. - Telas ricas da Torre, dashboard, roteirizador e mapas podem ter visual customizado "Metronic-like". - Nao comprar/adaptar Metronic agora. - AdminLTE/Metronic servem como inspiracao visual. - Primeiro finalizar nucleo funcional. - Depois padronizar layout operacional com visual mais refinado. - Sistema deve usar largura full em monitores grandes. ## SLA Operacional / Relatorio de Cutoff - [ ] Criar parametros de cutoff por tenant, filial, cliente e tipo de operacao. - [ ] Permitir configurar horarios-limite distintos para: - recebimento/importacao do documento; - roteirizacao; - expedicao/saida do veiculo; - entrega ou coleta. - [ ] Definir dias da semana, feriados, tolerancia em minutos e regra para documentos recebidos apos o corte. - [ ] Registrar os horarios reais de cada etapa para preservar a auditoria mesmo quando a configuracao mudar. - [ ] Criar relatorio com documentos dentro do prazo, fora do prazo e recebidos apos o cutoff. - [ ] Exibir tempo excedido e etapa responsavel pelo descumprimento. - [ ] Permitir justificar atrasos e classificar o motivo por responsabilidade: - cliente/remetente; - transportador; - motorista; - destinatario; - integracao/sistema; - motivo externo. - [ ] Disponibilizar filtros por periodo, filial, remetente, destinatario, regiao, motorista, veiculo e status. - [ ] Criar KPIs de cumprimento do cutoff em quantidade e percentual, com comparacao ao periodo anterior. - [ ] Permitir detalhar o KPI ate os documentos que compoem o resultado. - [ ] Criar alertas preventivos para operacoes proximas do horario de corte e alertas de cutoff vencido. - [ ] Considerar agendamentos, reprogramacoes, ocorrencias e dias nao uteis sem apagar o SLA originalmente contratado. - [ ] Preparar exportacao em Excel/PDF e uso dos indicadores no dashboard de performance. ### Formula principal `Cumprimento do cutoff (%) = operacoes elegiveis concluidas dentro do limite / total de operacoes elegiveis x 100` ## Painel de Retrabalho Operacional e Custo da Nao Entrega ### Objetivo - [ ] Criar painel com filtro por periodo para medir movimentos enviados para a rua que nao foram concluidos na primeira tentativa e geraram novo esforco operacional. - [ ] Demonstrar ao distribuidor/transportador que ocorrencias, reentregas e nao entregas podem consumir capacidade, veiculo, motorista, diaria e despesas adicionais em outro dia. - [ ] Separar a simples quantidade de falhas do impacto real: documentos, peso, volumes, valor de NF, frete, veiculos extras, diarias e custo estimado do retrabalho. ### Cards principais - [ ] Ocorrencias registradas no periodo. - [ ] Ocorrencias tratadas e nao tratadas. - [ ] Reentregas realizadas no periodo. - [ ] Nao consolidadas / nao entregues na primeira saida. - [ ] Entregas em atraso, comparando prazo/agendamento com a conclusao real. - [ ] Documentos que voltaram para a rua em outro dia. - [ ] Veiculos/dias adicionais consumidos pelo retrabalho. - [ ] Custo adicional estimado e custo confirmado do retrabalho. ### Fontes de informacao - `notas_fiscais` e `coletas`: documento, status atual, peso, volumes, valores, prazo e vinculo operacional. - `entregas`/romaneios: data da saida, veiculo, motorista, transportador e agrupamento dos movimentos por viagem. - historico/eventos operacionais: primeira alocacao, primeira saida, chegada, ocorrencia, cancelamento, reprogramacao, reentrega e conclusao; o painel nao deve depender apenas do status atual. - tratativas de ocorrencia: motivo, responsabilidade, ciencia, pendencia e decisao de reentrega. - regras e fechamentos de motorista: diaria, pagamento por saida, percentual e demais componentes efetivamente pagos. - custos do veiculo e despesas adicionais: custo por saida, pedagio, combustivel, descarga, pernoite e outros gastos relacionados ao novo romaneio. - agendamentos e parametros de SLA/cutoff: prazo prometido para identificar atraso real, sem classificar como atraso uma reprogramacao autorizada pelo cliente. ### Regra de identificacao do retrabalho - Considerar retrabalho quando o mesmo documento, coleta ou saldo pendente tiver uma nova alocacao/saida apos uma tentativa anterior nao concluida. - Nao marcar automaticamente toda reprogramacao como reentrega. Reentrega continua sendo somente a pontuada pelo usuario/tratativa ou comprovada por tentativa operacional anterior. - Preservar uma unica linha fiscal e reconstruir as tentativas pelo historico, comparando datas, romaneios, placas e motoristas. - Distinguir: - nao saiu para entrega e apenas foi reprogramado; - saiu, mas nao foi concluido; - teve ocorrencia e retornou em nova viagem; - foi parcialmente atendido e gerou saldo/reposicao; - atrasou por responsabilidade do cliente/destinatario, transportador, motorista ou motivo externo. - Quando varios documentos de retrabalho ocuparem o mesmo veiculo adicional, ratear o custo da saida por criterio configuravel: peso, volume, quantidade de documentos ou participacao no frete. ### Indicadores e detalhamento - [ ] Taxa de sucesso na primeira tentativa. - [ ] Taxa de retrabalho por transportador, motorista, veiculo, remetente, destinatario, regiao e motivo. - [ ] Ranking dos motivos que mais geram novas saidas. - [ ] Quantidade de dias entre a primeira tentativa e a conclusao. - [ ] Ocupacao do veiculo adicional formada por documentos reprogramados/reentregues. - [ ] Comparativo entre frete do documento e custo acumulado de todas as tentativas. - [ ] Drill-down do card ate NF/coleta, exibindo a linha do tempo completa e os custos apropriados. - [ ] Exportacao Excel/PDF para analise e apresentacao ao cliente. ### Formulas iniciais `Sucesso na primeira tentativa (%) = documentos concluidos na primeira saida / documentos que efetivamente sairam para operacao x 100` `Taxa de retrabalho (%) = documentos com nova saida apos tentativa nao concluida / documentos que efetivamente sairam para operacao x 100` `Custo do retrabalho = diarias/saidas adicionais + despesas adicionais + custo proporcional do veiculo nas novas tentativas` `Resultado apos retrabalho = frete apropriado - custo acumulado de todas as tentativas` ## Ideias para Documentar Depois ## Frota, Manutencao e Estoque Corporativo - [x] Criar ordens de manutencao com veiculo, motorista, origem, urgencia, responsabilidade, parada e previsao de liberacao. - [x] Imobilizar o veiculo automaticamente e retira-lo da roteirizacao enquanto estiver em manutencao. - [x] Manter historico de mudancas e devolver o veiculo ao estado anterior quando liberado. - [ ] Criar comparacao de multiplos orcamentos, oficinas, pecas, servicos, prazo e garantia. - [ ] Criar aprovacao de orcamento e integracao com contas a pagar. - [ ] Criar rateio de responsabilidade entre empresa, motorista, terceiro e seguradora. - [ ] Integrar parcela aprovada do motorista ao fechamento, sem desconto automatico antes da analise. - [ ] Criar manutencao preventiva por data, quilometragem e horimetro. - [ ] Integrar checklist reprovado com abertura assistida de ordem de manutencao. - [ ] Criar indicadores de custo, reincidencia, tempo parado e custo por quilometro. - [ ] Criar modulo corporativo de estoque separado por almoxarifado, setor e centro de custo. - [ ] Controlar entradas, saidas, transferencias, inventario, lote, validade e custo medio. - [ ] Permitir que a manutencao reserve e consuma pecas do estoque. - [ ] Criar requisicao de material para qualquer usuario, com aprovacao do supervisor e entrega pelo almoxarifado. - [ ] Atender materiais administrativos, EPIs, ferramentas, brindes e pecas de manutencao. - [ ] Registrar solicitante, aprovador, recebedor e centro de custo em toda movimentacao. - Criar relatorio de historico por NF/coleta. - Criar tela de pendencias por responsavel. - Criar notificacoes internas para SAC/Frota/Operacao. - Criar alertas por SLA de entrega e ocorrencia sem tratativa. - Criar dashboard de eficiencia por motorista, filial e transportador. - Criar permissao por status de documento. - Criar logs de integracao externos com payload/resposta.