Orquestrador Mobility ⟷ Omie

Toda rota da Mobility exige o header X-Api-Key.

• A chave é gerada pela IAXYS e fica na variável MOBILITY_API_KEY.
• Chave ausente ou diferente devolve 401. Servidor sem chave configurada devolve 503.
• A comparação é feita em tempo constante para não vazar informação por tempo de resposta.
• A chave pode ser a única do ambiente (MOBILITY_API_KEY) ou uma credencial criada no painel (RN21), que tem escopo e validade próprios.
• O painel de testes não usa chave: as chamadas feitas por lá são assinadas no servidor em nome da sessão de quem está logado, e aparecem na auditoria com o e-mail da pessoa.

Cada reserva é identificada por empresa, filial, File e CodigoWooMobil.

• Chave: {empresa}-{filial}-{file}-{CodigoWooMobil da reserva}. Exemplo: 29-26-00341130-341131.
• A Mobility envia um payload por reserva. Reservas diferentes do mesmo File são aceitas e ficam agrupadas.
• Reenviar a mesma reserva devolve 409 com o estado atual, a menos que ela esteja em ERRO. Nesse caso o novo payload substitui o anterior e o processamento recomeça.
• Na Omie, cada registro leva um código de integração único. Se a Omie responder que o registro já existe, o orquestrador consulta e reaproveita, sem duplicar.

O payload é validado campo a campo antes de ser aceito.

• Obrigatórios: file, empresa, filial, cliente, dataCriacao e ao menos uma reserva em movimentos.
• Cada reserva exige codigoWooMobil, localizadorFrontOffice, dataRetirada, dataEntrega e valores.tarifa.
• Cada recebimento exige codigoWooMobil, valor e formaRecebimento. Cada pagamento exige codigoWooMobil e valor.
• Números em texto são convertidos. Campos extras são aceitos e guardados para auditoria.

Número de cartão, validade e documentos nunca são gravados completos.

• Número do cartão vira **** **** **** 1234 antes de qualquer gravação. A validade é descartada.
• Documento do condutor é reduzido aos 3 últimos dígitos.
• Na Omie, os dados do cartão entram apenas na observação do título: bandeira, 4 últimos dígitos, NSU, autorização e operadora.

O cliente é localizado na Omie pelo código MOB-{id do cliente na Mobility}.

• O orquestrador consulta geral/clientes pelo codigo_cliente_integracao MOB-{cliente}.
• Se não existir e o payload trouxer clienteDados, o cliente é cadastrado com UpsertCliente.
• Se não existir e não houver clienteDados, a reserva vai para ERRO. A carga inicial de clientes resolve esse caso.

Cliente que ainda não existe na Omie é criado a partir do bloco clienteDados da própria venda.

• A busca é pelo código de integração MOB-{cliente}. Achou, usa o cadastro que já está na Omie e ignora o bloco — o orquestrador não sobrescreve cadastro existente.
• Não achou e o bloco veio: cria o cliente com razão social, nome fantasia, CNPJ ou CPF, e-mail, contato, telefone (DDD e número separados), inscrição estadual e endereço completo, com a tag mobility.
• Pessoa física é deduzida do documento: 11 dígitos marca pessoa física na Omie, 14 marca jurídica.
• Não achou e o bloco não veio: a venda para com erro de cadastro e fica aguardando a carga inicial de clientes ou o reenvio com o bloco.
• Obrigatórios: razaoSocial e cnpjCpf. O resto é opcional no contrato, mas a Omie exige endereço e documento na emissão de nota e na cobrança.

Cada reserva gera uma OS na Omie com um item de serviço por locação.

• cCodIntOS = MOB-{chave da reserva}. Etapa inicial configurável (OMIE_ETAPA_OS, padrão 10).
• Item: serviço OMIE_COD_SERVICO_LOCACAO, quantidade 1, valor da tarifa, descrição com locadora, localizador, rota, classe e período.
• Os dados adicionais da nota levam o File, os localizadores e a reserva de origem, quando houver.
• Pode ser desligada com OMIE_CRIAR_OS=false. Nesse caso só os títulos financeiros são criados.

Cada recebimento vira um título por parcela, com vencimento pela forma de recebimento.

• Código: MOB-{file}-CRE-{CodigoWooMobil}-R{nº do recebimento}-P{nº da parcela}. Dois recebimentos da mesma reserva geram títulos distintos.
• Parcelas: o valor é dividido igualmente e a diferença de centavos fica na última parcela.
• Vencimento: dataVencimento do payload, se vier. Senão, a data de confirmação somada ao prazo da forma de recebimento. Cada parcela seguinte soma 30 dias.
• Os prazos por forma ficam na tabela Formas de recebimento e pagamento do banco de dados. Valores iniciais: FATURADO e CC 30 dias, CARTAO_CORPORATIVO e FATURADO + CARTAO 30 dias, BOLETO 7 dias, demais formas no mesmo dia. O intervalo entre parcelas vem de INTERVALO_PARCELAS_DIAS.
• Categoria OMIE_CATEG_RECEITA e conta corrente OMIE_CONTA_CORRENTE. A observação traz forma de recebimento, localizadores, crédito de reemissão e reembolso.

Cada pagamento vira um título, classificado como comissão, reembolso ou despesa.

• Código: MOB-{file}-CPA-{CodigoWooMobil}-{nº do pagamento}.
• Favorecido: a pessoa do pagamento (MOB-{pessoa}). Se for o próprio cliente, ou não vier, usa o cliente da venda.
• Categoria: OMIE_CATEG_COMISSAO quando pagamentoDeComissao é verdadeiro, OMIE_CATEG_REEMBOLSO quando é reembolso (RN09) e OMIE_CATEG_DESPESA nos demais casos.
• Vencimento: dataVencimento do payload ou a data de confirmação somada ao prazo da forma de pagamento (tabela Formas de recebimento e pagamento, padrão PRAZO_PAGAMENTO_DIAS).
• Comissão repassada no pagamento e comissão da reserva são tratadas como informações independentes, como orientou a Mobility.

Pagamento ao próprio cliente numa venda com ValorReembolso vira devolução.

• Um pagamento é reembolso quando não é comissão, o favorecido é o cliente e algum recebimento da reserva tem valorReembolso maior que zero.
• O título a pagar recebe a categoria de reembolso e a observação Reembolso ao cliente.
• Cancelamento continua fora do fluxo: a Mobility usa CancelarVenda e a regra (contas a pagar em categoria de abatimento) aguarda a especificação técnica.

Reservas com o mesmo File formam uma venda. A reserva vinculada aponta para a origem.

• Cada reserva gera sua própria OS e seus títulos. A consulta por File junta todas.
• O campo reservaVinculada guarda o localizador da reserva de origem e aparece na OS e nas consultas.
• O crédito de reemissão da reserva de origem é registrado na observação do título. O abatimento automático aguarda definição da Mobility.

Datas vão para a Omie em dd/mm/aaaa e valores com duas casas.

• Datas ISO do payload são convertidas para dd/mm/aaaa, formato exigido pela Omie.
• A Omie trabalha só em reais. Reservas em moeda estrangeira já chegam com a tarifa convertida pela Mobility, e o câmbio aplicado fica registrado.

Rentabilidade = total a receber menos total a pagar do File.

• Situação do item: Real quando o título está baixado na Omie (recebido, pago ou liquidado), Previsto nos demais casos.
• percentualRentabilidade = rentabilidade dividida pelo total a receber, vezes 100.
• Se a Omie falhar para algum título, o valor do orquestrador é usado e a falha aparece em avisos.

Cotação de venda do boletim de fechamento do Banco Central.

• Dias sem cotação (fins de semana e feriados) são pulados. A busca volta até 12 dias além do pedido.
• Cada cotação obtida fica gravada e é reaproveitada nas próximas consultas.
• O parâmetro tipo é mantido por compatibilidade com o WOOFFICE. A fonte é a mesma para todos os tipos.

Bloqueio por consumo da Omie coloca a reserva em RETRY, reprocessada a cada 10 minutos.

• Mensagens como MISUSE_API_PROCESS e falhas de rede são tratadas como temporárias.
• Cada chamada tenta uma segunda vez após 2,5 segundos. Persistindo, a reserva vai para RETRY com nova tentativa em 10 minutos.
• A espera (RETRY_MINUTOS) e o limite de tentativas (MAX_TENTATIVAS, padrão 12) ficam na tabela Configurações do banco de dados. Esgotado o limite, a reserva vai para ERRO e precisa de reprocessamento manual.
• Erros de dados (cadastro ausente, categoria inválida) vão direto para ERRO.

RECEBIDO → ENVIANDO → INTEGRADO, RETRY ou ERRO.

• RECEBIDO: payload aceito e gravado.
• ENVIANDO: chamadas à Omie em andamento.
• INTEGRADO: cliente, OS e todos os títulos criados.
• RETRY: bloqueio temporário da Omie, nova tentativa agendada.
• ERRO: problema de dados ou tentativas esgotadas. O campo erros explica cada etapa.

Eventos são validados, gravados e ligados ao File da Mobility.

• A Omie não oferece token no webhook. A URL é cadastrada sem parâmetros e a autenticidade vem do appKey enviado no corpo de cada evento.
• appKey igual ao OMIE_APP_KEY: evento aceito. appKey diferente: 403. Sem appKey (notificação de teste): 200 e ignorado.
• O appKey não é gravado no histórico do evento.
• A resposta sai antes de 7 segundos, limite da Omie. O repasse para a Mobility acontece em segundo plano.
• O File é descoberto pelos códigos de integração MOB- presentes no evento.

Callback assinado com HMAC-SHA256, com nova tentativa a cada 10 minutos.

• Tipos: venda.status (fim do processamento de uma reserva) e omie.evento (evento repassado da Omie).
• Headers: X-Iaxys-Event, X-Iaxys-Delivery e X-Iaxys-Signature com o HMAC-SHA256 do corpo usando MOBILITY_WEBHOOK_SECRET.
• Respostas fora de 2xx são reenviadas pelo cron, até 30 tentativas.
• A URL de destino fica na tabela Configurações do banco de dados (MOBILITY_WEBHOOK_URL). Sem ela, os eventos ficam disponíveis na rota de polling. O segredo do HMAC fica no .env.

Categorias, conta corrente, serviço, prazos e URL de callback ficam na tabela Configurações.

• Prioridade de cada chave: registro ativo com valor na tabela Configurações do banco de dados, depois a variável de ambiente de mesmo nome, depois o padrão do código.
• O .env guarda só segredos e infraestrutura: OMIE_APP_KEY, OMIE_APP_SECRET, MOBILITY_API_KEY, MOBILITY_WEBHOOK_SECRET, CRON_SECRET, BANCO_DADOS_TOKEN, SESSION_SECRET e, se usado, DATABASE_URL.
• O orquestrador relê o banco de dados a cada 60 segundos. Alterações feitas pelo painel valem na hora.
• Se o banco de dados ficar indisponível, o último valor lido continua valendo.

Vendas, eventos, log e cotações são gravados no banco de dados do orquestrador.

• Tabelas: Vendas recebidas, Eventos Omie, Log de integração, Cotações, Configurações, Formas de recebimento e pagamento e Usuários.
• Payload e resultado de cada reserva ficam em JSON no próprio registro, para auditoria e reprocessamento.
• O banco atual aceita cerca de 3 gravações por segundo. Para volume de produção alto, basta configurar DATABASE_URL e PERSISTENCIA=postgres, sem mudar o contrato.

Toda chamada à API é registrada com autor, IP, horário, retorno e duração.

• A origem é deduzida da forma de autenticação: chave da Mobility, sessão do painel, appKey da Omie no webhook, segredo do cron ou simulação do painel. Chave inválida aparece como Desconhecida.
• Também ficam gravados IP, país e cidade (cabeçalhos da Vercel), user agent, parâmetros da URL com tokens mascarados, tamanho do envio, status, duração e a referência de negócio (File ou chave da reserva).
• O registro acontece depois da resposta, então não soma no tempo do cliente, e uma falha na auditoria nunca derruba a chamada.
• Controles na tabela Configurações: AUDITORIA_ATIVA liga e desliga, AUDITORIA_IGNORAR_HEALTH evita o ruído do monitoramento e AUDITORIA_GUARDAR_IP=false mascara o último bloco do IP.
• Consulta pela tela Logs do painel ou pela rota /api/logs, ambas restritas a quem tem sessão.

Cada pessoa cria, acompanha e revoga as próprias chaves na tela Credenciais.

• Formato da chave: mob_<prefixo>_<segredo>. O prefixo identifica o registro e aparece nas telas e nos logs; o segredo tem 32 bytes aleatórios.
• No banco ficam apenas o prefixo e o SHA-256 da chave inteira. O valor completo é exibido uma única vez, na criação, e não pode ser recuperado.
• Escopos: "Integração total" usa qualquer rota; "Somente leitura" só executa GET e recebe 403 nas demais. O perfil Leitor só cria credenciais somente leitura.
• Validade opcional: depois da data a chave é recusada. A revogação é imediata (até um minuto, por causa do cache de validação) e guarda quem revogou.
• Cada uso atualiza o último acesso e o contador (no máximo uma gravação a cada cinco minutos por credencial). A auditoria registra o nome, o prefixo e o dono da credencial usada em cada chamada.
• A chave única do ambiente continua válida, identificada nos logs como "chave única do ambiente".

Assistentes de IA da Mobility consultam a operação por um servidor MCP somente de leitura, com a credencial de API de cada time.

• Oito ferramentas de consulta, todas marcadas como somente leitura no protocolo: nenhuma altera dado no orquestrador, na Omie ou na Mobility.
• As respostas são de negócio. O conector não devolve nome de banco, de tabela, de variável de ambiente, de biblioteca ou de provedor, nem caminho de arquivo ou mensagem interna de erro.
• A credencial é a mesma das outras rotas e vale a regra de escopo: credencial somente leitura é suficiente para o conector inteiro.
• Indicadores de uso saem agregados por rota, sem identificar quem chamou — nenhum IP ou nome de usuário de terceiros é exposto.
• Cada chamada é auditada (rota, origem, IP, país, retorno e duração) e aparece na tela Logs, então dá para ver exatamente o que cada assistente consultou.
• Revogar a credencial no painel corta o acesso do assistente em até um minuto.

A opção Faturado aparece apenas para cliente com cadastro pré-aprovado e limite de crédito ativo.

• O cadastro fica na tabela Clientes B2B do banco de dados: razão social, CNPJ, endereço, limite aprovado, calendário, forma de cobrança, e-mails de cobrança e situação (Ativo, Suspenso, Em análise).
• A plataforma consulta GET /faturamento/limite antes de oferecer o Faturado. Cliente sem cadastro volta com cadastrado: false e bloqueado: true, com o motivo — a opção não deve ser oferecida.
• A importação de venda com recebimento FATURADO de um cliente sem cadastro não derruba a venda: a reserva entra na Omie normalmente e o motivo fica registrado no log, para o Faturamento cadastrar o cliente.

Disponível = limite aprovado − (pré-DUPs abertas + DUPs emitidas e não quitadas). Reserva que ultrapasse o disponível não é emitida como Faturado.

• O comprometido soma pré-DUPs, pendências, DUPs emitidas e enviadas. Pagas e canceladas não contam.
• GET /faturamento/limite?cnpj=&valor= responde podeFaturar com o motivo exato da recusa.
• A inclusão de linha recusa com 422 quando o valor estoura o disponível, antes de criar a linha.

DUP vencida e não paga há mais de 2 dias úteis bloqueia novas emissões no Faturado. Cartão, Pix e boleto avulso continuam liberados.

• A contagem usa dias úteis, com a mesma tabela de feriados do calendário de corte.
• O prazo é configurável em FAT_BLOQUEIO_DIAS_UTEIS (padrão 2).
• O bloqueio vale só para o Faturado: as outras formas de recebimento seguem o fluxo normal da integração.

A baixa na Omie, após compensação, devolve o limite e desbloqueia o cliente automaticamente.

• A DUP marcada como Paga sai do comprometido na hora: limite de R$ 100 mil com DUP de R$ 80 mil deixa R$ 20 mil livres e volta a R$ 100 mil quando a DUP é quitada.
• Implementada a devolução do limite. O gatilho automático da baixa (webhook de financeiro da Omie ou consulta periódica) é Parte 2 — hoje a quitação é registrada pela rota de fechamento ou pelo painel.

Ao atingir um percentual do limite (90%), a plataforma avisa o cliente e o Financeiro Mobility, com canal para pedido de majoração.

• O percentual é configurável em FAT_ALERTA_LIMITE_PCT (padrão 90).
• A rota de limite e a tela Faturamento já devolvem o sinalizador de alerta e o consumo em percentual.
• O disparo do e-mail de aviso é Parte 2, junto com os outros avisos da régua. Majoração continua sendo alçada financeira, feita no cadastro do cliente.

O lote é definido pela data de emissão da reserva. Check-in e devolução do carro não interferem.

• Uma reserva emitida em 06/10 para devolução em janeiro entra no lote de 02 a 11/10.
• O orquestrador usa a data de emissão enviada pela plataforma; na falta dela, a data de criação da reserva.

Decendial padrão para cerca de 90% dos clientes, quinzenal ou próprio para os demais. Fechamento, envio e vencimento caem no próximo dia útil.

• Decendial: emissões do dia 02 ao 11 fecham no dia 12 e vencem no dia 22; do 12 ao 21 fecham no 22 e vencem no dia 02 do mês seguinte; do 22 ao dia 01 fecham no dia 02 e vencem no dia 12.
• Quinzenal: emissões do dia 01 ao 15 fecham no 16 e vencem no último dia do mês; do 16 ao último dia fecham no dia 01 e vencem no dia 15 do mês seguinte.
• Fim de semana e feriado empurram fechamento, envio e vencimento para o próximo dia útil, sem mudar a janela de emissões — como na DUP118333, com vencimento em 02/11/2025 (domingo) movido para 03/11.
• A lista de feriados fica na tabela Feriados do banco de dados, com fonte e manutenção a definir (D11). O calendário padrão vem de FAT_CALENDARIO_PADRAO e o do cliente prevalece.
• Calendário Próprio ainda cai no tratamento do decendial: a lista de clientes com datas próprias é a decisão D5.

A primeira reserva faturada do período cria a pré-DUP já com número sequencial. O número nunca é reaproveitado.

• A numeração usa a série nova com prefixo FAT (FAT_PREFIXO_NUMERO, a partir de FAT_NUMERO_INICIAL = 1001), para separar o faturamento novo do legado DUP do WOOFFICE — preferência do Financeiro registrada na decisão D9.
• A sequência só avança: pré-DUP vazia ou toda cancelada mantém o número e fica com status Cancelada.
• Pré-DUPs e DUPs ficam na tabela Duplicatas (DUP) e cada reserva, na tabela Linhas da DUP.

Inclusões e exclusões são atualizadas em tempo real. Reserva cancelada sai da pré-DUP automaticamente e não é cobrada.

• Cada inclusão ou retirada recalcula o valor total da pré-DUP na hora.
• A saída automática por cancelamento depende do evento de cancelamento da plataforma, que ainda não chega ao orquestrador: hoje a retirada é feita pela rota de fechamento (parâmetro retirar) ou pela tela Faturamento.

Reserva ativa retirada de uma DUP volta para a pré-DUP aberta do próximo período daquele cliente. Nunca retorna para um lote passado.

• A retirada mantém os dados de identificação da reserva (File e ID) e recria a linha na pré-DUP aberta, com origem Manual e a DUP de origem registrada.
• A DUP de origem é recalculada mantendo número e vencimento, e a versão sobe (RN-20, RN-23).
• A menos de 2 dias úteis do vencimento vale a RN-22 e o valor vira crédito de reembolso, em vez de mudar de lote.
• Na retirada, a alçada informa se a reserva está ativa (volta ao próximo lote) ou cancelada (não é cobrada, RN-09).

Na data de corte o sistema valida cada linha: líquido recalculado igual ao valor da plataforma, comissão quando aplicável, campos obrigatórios e cadastro de cobrança completo.

• Fórmula aplicada ao Pacote: Líquido = Tarifa BRL + Encargo + Taxa de serviço − Comissão − Crédito reemissão − Desconto + Multa. Os sinais de crédito, desconto e multa são a decisão D7.
• Reembolso: Líquido = −Tarifa BRL × (1 − retenção), com retenção de 2,1% observada na DUP118333 (FAT_RETENCAO_REEMBOLSO_PCT) — regra a confirmar (D7).
• O arredondamento da plataforma é a fonte: a conferência aceita diferença de até FAT_TOLERANCIA_CENTAVOS (padrão R$ 0,02), que é a maior divergência observada na DUP118333. Acima disso a linha reprova.
• Também são verificados: cliente com endereço e e-mails de cobrança, datas e fornecedor preenchidos e forma de cobrança definida.
• A chave da linha é o File e o ID da reserva, nunca o nome do passageiro: o mesmo passageiro pode ter várias linhas, inclusive com grafia diferente.

Sem inconsistência, confirma a DUP, solicita boleto/bolecode na Omie, gera o kit e envia, sem intervenção humana.

• Implementado: a validação, a emissão da DUP com número, versão e vencimento, e o registro de quem fechou.
• A solicitação do boleto/bolecode na Omie (integração Itaú já ativa), a geração do kit e o envio do e-mail são a Parte 2 do projeto.

Com inconsistência, a DUP vai para a fila de pendências com o motivo. Liberação somente manual, após correção, com registro de quem liberou.

• A DUP fica com status Pendência e a lista de motivos por linha. O fechamento responde 409 com o detalhamento.
• Depois da correção, o fechamento é repetido pela tela Faturamento e o liberador fica no log imutável da DUP.

Fechamento e envio rodam em lote fora do horário comercial, para não sobrecarregar integrações.

• A rotina /api/internal/faturamento roda todo dia às 6h UTC pela Vercel: fecha os lotes com corte vencido e executa a conciliação.
• O fechamento automático fica desligado por padrão (FAT_CORTE_AUTOMATICO). Com ele desligado a rotina só aponta o que está vencido.
• A janela definitiva é a decisão D10.

O e-mail leva somente o link do kit. O acesso pode ter senha simples (8 primeiros dígitos do CNPJ) e a abertura do link é o registro de recebimento.

• Parte 2 do projeto. A validade do link está pré-configurada em FAT_VALIDADE_LINK_DIAS (padrão 90) e aguarda a decisão D6.

O kit traz a DUP em PDF, a DUP em Excel (obrigatória) e o instrumento de pagamento.

• A rota de detalhe da DUP já devolve exatamente os dados das duas peças: cabeçalho do cliente, identificação da DUP, emissor, linhas agrupadas por produto, subtotais e total geral.
• O nome do arquivo segue o padrão do guia: DUP{numero}_{CNPJ}_{vencimento AAAAMMDD}[_v{versao}].xlsx.
• A geração do PDF e do .xlsx e o instrumento de pagamento são Parte 2.

Cadastro de cobrança do cliente com múltiplos e-mails, mais cópia para e-mail interno da Mobility.

• O campo de e-mails de cobrança já existe no cadastro de Clientes B2B e é exigido na validação do fechamento.
• A migração da base do WOOFFICE é a decisão D3; o envio é Parte 2.

Assunto e corpo são modelos editáveis pela Mobility, com variáveis (cliente, nº DUP, valor, vencimento, link).

• Parte 2. Os modelos entram como configurações, editáveis na tela Configurações, como as demais.

Bolecode (padrão), boleto ou crédito em conta, parametrizado por cliente.

• O campo está no cadastro de Clientes B2B e sai na rota de detalhe da DUP, para o rodapé do kit.
• Em crédito em conta não há boleto e os dados bancários da Mobility vão no rodapé. A evolução para somente QR Pix fica para depois.

Alteração até 2 dias úteis antes do vencimento recalcula a DUP, baixa o boleto anterior, registra o novo e reenvia o kit com aviso de substituição.

• Implementado o núcleo: recálculo mantendo número e vencimento e controle de versão da DUP.
• A baixa e o novo registro de boleto via API Itaú/Omie e o e-mail de atualização são Parte 2, e a viabilidade do Plano A é a decisão D4.

Se o Plano A não for viável, o sistema notifica o Faturamento por e-mail e sinaliza a DUP para correção manual.

• A sinalização no módulo já existe (status Pendência com motivo). A notificação por e-mail é Parte 2.

A reserva permanece na DUP vigente e o crédito entra automaticamente como linha de reembolso na próxima pré-DUP.

• A retirada decide sozinha entre RN-10 e RN-22 pela distância em dias úteis até o vencimento.
• A linha de reembolso nasce com os mesmos dados de identificação da reserva original e valor negativo.

Atualização nunca altera o vencimento, já ajustado ao dia útil pela RN-07. Prorrogação é exceção manual, por alçada.

• O recálculo preserva o vencimento original da DUP e registra a nova versão.

Cancelamento após a DUP paga gera linha de reembolso (valor negativo) na próxima pré-DUP, com os mesmos dados da reserva original.

• O módulo aceita linhas de reembolso com emissão de períodos anteriores, como as três linhas de setembro que entraram na DUP de 22/10 na DUP118333.
• O destino de uma DUP com saldo líquido negativo (carregar crédito ou virar duplicata a pagar) é a decisão D8.

Incluir, retirar ou editar reservas de uma DUP, reemitir e reenviar é exclusivo de usuários internos Mobility com alçada. Nenhum usuário externo altera DUP.

• A tela Faturamento só aceita ações de usuários autenticados no painel; o perfil Leitor apenas consulta.
• Toda ação de alçada grava o e-mail de quem executou no log da DUP.

Reserva em contestação (SAC ou pendência com locadora) é retirada da DUP e segue a RN-10.

• A retirada exige motivo, que fica no log e na linha recriada no lote seguinte.

Toda edição manual usa o tratamento da RN-20 (baixa e novo boleto, mesmo número, e-mail de atualização) e o módulo tem botão de reenvio do kit.

• Depende do boleto e do envio do kit: Parte 2. O controle de versão da DUP já está pronto para suportar o reenvio.

Toda ação na DUP fica registrada: quem (robô ou usuário), o quê, data e hora, valor antes e depois.

• O histórico fica no próprio registro da DUP, em texto corrido, apenas por acréscimo, e nas tabelas de auditoria.
• Cada chamada às rotas de faturamento também entra em Acessos à API, com IP, país, retorno e duração, visível na tela Logs.
• O CPF do usuário ainda não é coletado no cadastro do painel: hoje o log identifica por e-mail.

Por DUP: envio e destinatários, liberador, aberturas do link com data, hora e IP, downloads e data da baixa. Serve de prova.

• A trilha de envio e de abertura do link depende do kit e do e-mail: Parte 2. O liberador e a baixa já ficam registrados.

Lembrete amigável ao cliente 3 dias úteis antes do vencimento, com o link do kit.

• Parte 2. O prazo já está em FAT_LEMBRETE_DIAS_UTEIS (padrão 3) e a rotina diária é o lugar do disparo.

DUP não quitada 1 dia útil após o vencimento gera aviso ao cliente e ao Financeiro Mobility.

• Parte 2. O prazo está em FAT_AVISO_ATRASO_DIAS_UTEIS (padrão 1).
• Pode usar a régua nativa da Omie, desde que o aviso inclua o link do kit.