Uma política é uma campanha de serviço nomeada - os seus extras de época festiva, benefícios VIP, stack de garantia de eletrónica. Cada política contém uma árvore de condições (quem se qualifica) e uma ou mais regras de serviço (o que oferece e a que preço). Crie políticas ilimitadas, ordene por prioridade com arrastar, ative ou pause individualmente sem tocar em código.

Cada regra define: código de serviço, etiqueta e descrição multilingues do carrinho (conorderservices_rule_lang), tipo de valor (fixo, percentual, escalonado), base de valor (produtos, carrinho, envio, peso), limites min/máx de taxa, grupo de regras fiscais, ícone ou imagem carregada, tipo de UI (caixa de seleção ou rádio), grupo de rádio e etiqueta opcionais, flag pré-selecionado, prioridade, datas de agenda (válido de / válido até) e condições opcionais ao nível da regra.

Stop on first match termina a avaliação após a primeira política qualificada - útil quando campanhas não devem sobrepor-se. Merge strategy por política controla como várias regras numa política se combinam: stack all services, first match wins, priority cascade, apenas maior taxa ou unique service codes. Estratégia de combinação global por defeito em Definições aplica-se a novas políticas.

A vista de lista de políticas mostra estado, estratégia de combinação, contagem de regras e ações rápidas. Duplicar, exportar JSON, importar de ficheiro ou alternar ativo - tudo no painel de políticas com cada alteração no registo de auditoria.

O construtor de condições é um editor de árvore AND/OR aninhada - o mesmo padrão de motores de regras profissionais, renderizado como grupos arrastáveis no back office. Adicione um grupo, escolha um campo, operador e valor. Aninhe grupos para lógica como: (grupo VIP OU 5+ encomendas anteriores) E (total do carrinho ≥ 100 €) E (categoria Summer Sale tem 3+ artigos).

35 campos de condição cobrem o contexto completo do carrinho: total do carrinho, subtotal de produtos, custo de envio, contagem de produtos, contagem de SKUs únicos, peso, contagem de regras de carrinho existentes, contagem de encomendas do cliente, gasto vitalício, dia da semana, hora, data, código postal, moeda, país, país de faturação, zona, grupo de clientes, transportadora, módulo de pagamento, estado com sessão/convidado, produtos, categorias, fabricantes, fornecedores, flags virtual/físico, personalização e deteção de desconto existente.

Campos compostos combinam entidade + limiar numa condição - ex. produto #123 qty ≥ 3, categoria #45 total da linha ≥ 50 €. Operadores incluem equals, not equals, greater/less than, between, in list, not in list, contains, starts with, regex, empty e not empty.

Tipos de condição - referência

Cada linha corresponde exatamente ao que escolhe no menu do construtor de condições. Campos numéricos suportam =, ≠, <, ≤, ≥, > e between. Campos booleanos usam Yes/No. Campos de pesquisa suportam in e not in com multi-seleção. Campos de texto acrescentam contains, starts with e regex. Combine quaisquer campos em grupos AND/OR aninhados - o motor reavalia a cada atualização do carrinho.

Seletores de produto, categoria, fabricante e grupo usam pesquisa autocomplete integrada. Uma frase de pré-visualização ao vivo explica o que a árvore corresponde. Utilizadores avançados podem alternar JSON bruto para copiar entre ambientes. Condições reavaliam a cada sincronização do carrinho - adicionar, mudar qty, login, morada - o motor reage de imediato.

Referência de operadores

14 operadores estão disponíveis no construtor. O tipo de campo determina quais operadores aparecem - campos booleanos usam apenas = e ≠; campos numéricos têm o conjunto completo de comparação.

Cada regra de serviço escolhe um tipo de valor: fixo, percentual ou escalonado. Fixo usa um valor decimal único. Percentual usa taxa mais base de valor - total de produtos, total do carrinho, custo de envio ou peso do carrinho. Escalonado abre tabela em degraus guardada como JSON (tiers_json) com faixas from/to e taxa por faixa.

Taxa mín. e taxa máx. limitam cálculos percentuais para o seguro nunca ficar abaixo de 2 € nem exceder 50 €. Grupo de regras fiscais por regra garante que a linha de serviço herda o IVA correto. Campos de agenda (date_from / date_to) limitam ofertas sazonais sem desativar toda a política.

Por detrás da UI, ConorderservicesEngine resolve regras elegíveis, calcula cada taxa do contexto live do carrinho, aplica estratégia de combinação e escreve o total combinado num SpecificPrice dinâmico no produto de serviço partilhado. Chips de resumo de regras no admin mostram preços ativos de relance.

O construtor de escalões em adminPolicyRules.js adiciona/remove linhas visualmente. Voltar de escalonado para fixo preserva outras definições da regra. Importe política de staging, abra o cartão da regra, ajuste um limiar, guarde - dados estruturados mantêm-se consistentes.

Serviços elegíveis renderizam num painel de checkout dedicado via displayShoppingCart, displayShoppingCartFooter ou displayCheckoutSummaryTop - posição configurável em Definições. Cada linha de oferta mostra caixa de seleção ou rádio, ícone/imagem opcional, nome, descrição e etiqueta de preço calculado.

O cliente alterna serviços via controlador AJAX front (checkout.js + endpoint ajax do módulo). Totais do carrinho e etiquetas atualizam sem recarregar a página. O painel também atualiza quando a qty muda. Eventos de seleção no audit (service_selected, service_deselected). Impressões quando o painel é mostrado (dedup por conjunto elegível).

Serviços selecionados sincronizam para um produto de catálogo oculto (CONORDERSVC-SERVICE) com SpecificPrice dinâmico por carrinho. Várias seleções numa linha de carrinho com etiquetas multilingues separadas por vírgula e valor combinado. Estado do carrinho em conorderservices_cart com instantâneo elegível, JSON de serviços selecionados e instantâneo aplicado para sync idempotente.

Hooks actionCartSave, hooks de remoção no carrinho, actionPresentCartProduct e actionProductPriceCalculation mantêm a linha de serviço sincronizada quando o carrinho muda. Compatível com temas PrestaShop 9, 8, 1.7 incluindo miniaturas Hummingbird via actionPresentProduct.

Cada regra de serviço suporta identidade visual no checkout: carregue JPG/PNG/GIF/WebP para views/img/services/ ou cole URL HTTPS externo. ConorderservicesRuleImage trata validação de upload, armazenamento, resolução de URL pública e eliminação segura quando imagens são substituídas ou removidas.

A UI dedicada do editor de imagens (adminPolicyRuleImage.js) mostra pré-visualização ao vivo, controlos remover/substituir e fallback do anterior durante gravação. Na duplicação ou importação de política, imagens são clonadas ou referenciadas com segurança para transferências staging-produção não quebrarem visuais do checkout.

Tamanho do ícone (1-256 px), posição (esquerda/centro/direita) e alinhamento dos controlos são Definições globais - uma loja pode mostrar ícones grandes de embrulho à esquerda enquanto outra mantém caixas compactas à direita. Alternâncias mostrar/ocultar para nome, descrição, preço e ícone por loja completam a camada de apresentação.

O separador Simulador é um fluxo de três passos contra dados reais na base de dados - não um carrinho simulado. Passo 1: pesquise carrinhos por ID, nome ou email do cliente. Passo 2: escolha um carrinho da lista live (mostra cliente, email, total, última atualização). Passo 3: execute avaliação e leia o detalhe completo dos resultados.

Os resultados mostram que políticas corresponderam, quais foram ignoradas (e porquê), taxas calculadas por regra, estado elegível vs selecionado, resolução de grupo de rádio e pré-visualização da linha com etiqueta e valor combinados. Filtro opcional de cliente reduz a lista a uma conta - ideal para reproduzir ticket de suporte.

Cada execução de simulação fica no registo de auditoria com tipo simulation_run, ID do carrinho, ator (funcionário) e instantâneo de resultado. Merchandising pode verificar campanha antes de ativar. Suporte pode explicar por que um carrinho específico viu ou não embrulho - sem encomenda de teste na loja live.

Use o simulador após cada edição de política, antes do go-live de época festiva e ao importar políticas de staging. É a rede de segurança que separa gestão empresarial de serviços de "alterar e esperar".

O separador Painel é a sala de controlo dos serviços opcionais. Cartões KPI num período selecionável (30 / 90 / 180 / 365 dias) mostram: impressões do painel, seleções no checkout, encomendas com serviços, taxa de compra e receita de serviços na moeda da loja. Números vêm do registo de auditoria - eventos reais, não estimativas.

Gráficos de tendência Chart.js visualizam o funil de receita em três granularidades: diário (janela configurável), semanal e mensal. Linhas seguem impressões, seleções, encomendas pagas e receita de serviços num eixo secundário. Altere o tipo de gráfico por defeito em Definições. Um gráfico circular divide receita paga por código de serviço para ver que extras realmente convertem.

A tabela por serviço lista cada código com impressões, seleções, encomendas, receita e taxa de compra. Seleções são um passo do funil - encomendas e receita são a verdade KPI (evita métricas de vaidade de alternâncias que nunca convertem). Entradas recentes de auditoria no painel para troubleshooting rápido.

Para agências e operadores multistore: o painel responde à pergunta que merchandising sempre faz - "Os nossos extras no checkout estão realmente a vender?" - com dados, não intuição.

O separador dedicado Registo de auditoria é um diário completo de eventos - não um ficheiro debug enterrado nos logs do servidor. Cada linha guarda carimbo, tipo de evento, ator (nome do funcionário, cliente ou SYSTEM), resumo legível, referência de encomenda, código de serviço, valor da taxa, ID do carrinho e ID de política/regra.

20+ tipos de evento são rastreados:

• service_impression - painel de checkout mostrado ao carrinho
• service_selected / service_deselected - cliente alterna um serviço
• service_applied - serviços sincronizados na linha do carrinho
• order_services - encomenda com receita de serviços (por linha)
• order_validated - hook de validação de encomenda disparado
• policy_created, policy_updated, policy_deleted, policy_toggled
• policy_duplicated, policy_imported, policy_exported
• rule_created, rule_updated, rule_deleted, rule_toggled
• preset_applied - preset de condição carregado no construtor
• settings_updated - alteração de configuração do módulo
• simulation_run / simulation - avaliação de carrinho no back office

Clique Ver em qualquer linha para abrir modal de detalhe com instantâneo JSON completo - linhas de serviço aplicadas, diff de política, saída de simulação ou payload de alteração de definições. Aplicações de serviço guardam fee_snapshot para reconstruir exatamente o que o cliente viu no checkout.

A lista suporta exportação CSV nativa do PrestaShop para revisões financeiras e de conformidade. Colunas unidas mostram referência de encomenda, nome do cliente e funcionário sem referência cruzada manual. Na página de encomenda no back office (hook displayAdminOrder), um painel mostra que serviços opcionais contribuíram - nome, código, valor e instantâneo.

Políticas são documentos JSON portáteis. Exportar descarrega a política completa - árvore de condições, todas as regras, configs de preço, estratégia de combinação, metadados de imagens, posições - pronta para controlo de versão ou outra loja. Importar carrega JSON e cria nova política com entrada policy_imported no audit.

Duplicar clona uma política com um clique no menu de ações via ConorderservicesPolicyDuplicator - copia cada regra, renomeia com sufixo, clona imagens com segurança, regista policy_duplicated. Perfeito para criar "Holiday v2" a partir de "Holiday v1" sem reconstruir 10 regras manualmente.

Fluxo típico de agência: construir e simular em staging → exportar JSON → importar em produção → executar simulador novamente → ativar. Configurações sazonais movem-se entre lojas de clientes em minutos. Cada transferência é rastreável no registo de auditoria.

O separador Definições centraliza o comportamento da loja. Interruptor principal ativar/desativar. Estratégia de combinação global por defeito para novas políticas. Grupo de regras fiscais por defeito para novas regras de serviço. ID do produto de serviço - escolha que produto representa a linha ou use o produto oculto CONORDERSVC-SERVICE criado automaticamente.

Posição de exibição controla onde o painel de checkout renderiza: bloco integrado no resumo do carrinho, só página do carrinho, só resumo do checkout, hooks de tema carrinho e checkout, ou abaixo da lista de produtos. Definições de exibição controlam mostrar/ocultar nome, descrição, preço e ícone; tamanho (1-256 px); posição (esquerda/centro/direita); alinhamento de caixa/rádio.

Registo debug escreve rastos verbosos do motor para suporte. Secção de analítica configura período de gráfico por defeito (30/90/180/365 dias), janelas diárias/semanais/mensais e tipo de gráfico por defeito. Pré-visualização ao vivo em Definições mostra como as linhas de oferta ficam com as opções atuais.

Cada gravação de definições regista settings_updated no log de auditoria com instantâneo antes/depois. Sem deriva silenciosa de configuração.

Os serviços materializam-se como linha real de carrinho no produto oculto partilhado com preço dinâmico e etiqueta multilingue. Aparecem no resumo do carrinho, checkout, confirmação, faturas e vista de encomenda no back office - como uma linha de produto normal, sem hacks de tema ou valores negativos falsos.

O motor liga-se a actionCartSave, adicionar/remover produto, init do front controller, validação de encomenda (actionValidateOrder, actionValidateOrderBefore no PS 8.1+) e apresentação do carrinho - recalcula sempre que o contexto muda. Colunas da tabela de encomendas conorderservices_service_amount e conorderservices_service_snapshot guardam totais históricos de serviços no registo da encomenda.

As políticas são por loja (id_shop) em configurações multistore. Cada loja do grupo pode executar stacks de serviço independentes. PrestaShop 9, 8 e 1.7 partilham uma base de código via lib/prestashop9compatibility.php e ConorderservicesCompatibility.

Etiquetas multilingues de checkout por regra (conorderservices_rule_lang) garantem que a linha de serviço se lê corretamente em cada idioma ativo da loja. 30 pacotes de tradução prontos cobrem back office e front office via l() do PrestaShop - de inglês, alemão e polaco a espanhol, francês, italiano e mercados na Europa e Ásia.