Una policy è una campagna servizio nominata - i tuoi extra festivi, i vantaggi VIP, lo stack garanzia elettronica. Ogni policy contiene un albero condizioni (chi qualifica) e una o più regole servizio (cosa offri e a quale prezzo). Crea policy illimitate, ordina per priorità con drag-and-drop, attiva o metti in pausa singolarmente senza toccare codice.

Ogni regola definisce: codice servizio, etichetta e descrizione carrello multilingue (conorderservices_rule_lang), tipo valore (fisso, percentuale, a scaglioni), base valore (prodotti, carrello, spedizione, peso), limiti min/max costo, gruppo regole fiscali, icona o immagine caricata, tipo UI (checkbox o radio), gruppo radio e etichetta opzionali, flag pre-selezionato, priorità, date programmazione (valido da / valido a) e condizioni opzionali a livello regola.

Stop alla prima corrispondenza termina la valutazione dopo la prima policy idonea - utile quando le campagne non devono sovrapporsi. La strategia di merge per policy controlla come più regole nella stessa policy si combinano: impila tutti i servizi, vince la prima corrispondenza, cascata priorità, solo costo più alto, o codici servizio unici. Una strategia merge globale predefinita in Impostazioni si applica alle nuove policy.

La vista elenco policy mostra stato, strategia merge, conteggio regole e azioni rapide. Duplica, esporta JSON, importa da file o attiva/disattiva - tutto dal pannello policy con ogni modifica scritta nel log di audit.

Il builder condizioni è un editor albero AND/OR annidato - lo stesso pattern usato nei motori di regole professionali, reso come gruppi drag-friendly nel back office. Aggiungi un gruppo, scegli un campo, un operatore, imposta un valore. Annida gruppi per logica tipo: (gruppo VIP OR 5+ ordini passati) AND (totale carrello >= 100 euro) AND (categoria Saldi Estivi ha 3+ articoli).

35 campi condizione coprono l'intero contesto carrello: totale carrello, subtotale prodotti, costo spedizione, conteggio prodotti, conteggio SKU unici, peso, conteggio regole carrello esistenti, conteggio ordini cliente, spesa lifetime, giorno settimana, ora, data, CAP, valuta, paese, paese fattura, zona, gruppo cliente, corriere, modulo pagamento, stato loggato/ospite, prodotti, categorie, produttori, fornitori, flag virtuali/fisici, personalizzazione e rilevamento sconti esistenti.

Campi composti combinano entita + soglia in una condizione - es. prodotto #123 qty >= 3, categoria #45 totale riga >= 50 euro. Gli operatori includono uguale, diverso, maggiore/minore di, tra, in lista, non in lista, contiene, inizia con, regex, vuoto e non vuoto.

Riferimento tipi condizione

Ogni riga corrisponde esattamente a ciò che scegli nel menu a tendina del builder condizioni. I campi numerici supportano =, !=, <, <=, >=, > e between. I campi booleani usano Sì/No. I campi ricerca supportano in e not in con multi-selezione. I campi testo aggiungono contains, starts with e regex. Combina qualsiasi campo in gruppi AND/OR annidati - il motore li ricontrolla ad ogni aggiornamento carrello.

I picker prodotto, categoria, produttore e gruppo usano ricerca autocomplete integrata. Una frase anteprima live spiega cosa corrisponde all'albero. Gli utenti avanzati possono attivare JSON raw per copia-incolla tra ambienti. Le condizioni si rivalutano ad ogni sync carrello - aggiungi al carrello, cambia qty, login, cambia indirizzo - il motore reagisce subito.

Riferimento operatori

14 operatori disponibili nel builder. Il tipo campo determina quali operatori compaiono - i campi booleani usano solo = e !=; i campi numerici hanno il set completo di confronto.

Ogni regola servizio sceglie un tipo importo: fisso, percentuale o a scaglioni. Il fisso usa un singolo valore decimale. La percentuale usa un tasso più una base valore - totale prodotti, totale carrello, costo spedizione o peso carrello. A scaglioni apre una tabella a gradini salvata come JSON (tiers_json) con fasce from/to e costo per fascia.

Costo min e costo max limitano i calcoli percentuali così l'assicurazione non scende sotto 2 euro ne supera 50 euro. Il gruppo regole fiscali per regola assicura che la riga servizio erediti l'IVA corretta. I campi programmazione (date_from / date_to) limitano le offerte stagionali senza disabilitare l'intera policy.

Dietro l'UI, ConorderservicesEngine risolve le regole idonee, calcola ogni costo dal contesto carrello live, applica la strategia di merge e scrive il totale combinato su un SpecificPrice dinamico sul prodotto servizio condiviso. I chip riepilogo regola in admin mostrano i prezzi attivi a colpo d'occhio senza aprire l'editor.

Il builder scaglioni in adminPolicyRules.js aggiunge/rimuove righe visivamente. Passare da a scaglioni a fisso preserva le altre impostazioni regola. Importa una policy da staging, apri la card regola, modifica una soglia, salva - i dati strutturati restano coerenti.

I servizi idonei compaiono in un pannello checkout dedicato via displayShoppingCart, displayShoppingCartFooter o displayCheckoutSummaryTop - posizione configurabile in Impostazioni. Ogni riga offerta mostra controllo checkbox o radio, icona/immagine opzionale, nome, descrizione e badge prezzo calcolato.

Il cliente attiva/disattiva servizi via controller AJAX front (checkout.js + endpoint ajax modulo). Totali carrello ed etichette riga si aggiornano senza reload pagina. Il pannello si aggiorna anche quando cambia qty carrello. Gli eventi selezione vanno in audit (service_selected, service_deselected). Gli eventi impressione si registrano quando il pannello viene mostrato (deduplicati per set idoneo).

I servizi selezionati si sincronizzano su un unico prodotto catalogo nascosto (CONORDERSVC-SERVICE) con SpecificPrice dinamico per carrello. Piu selezioni compaiono come singola riga carrello con etichette multilingue separate da virgola e importo combinato. Lo stato carrello persiste in conorderservices_cart con snapshot idonei, JSON servizi selezionati e snapshot applicato per sync idempotente.

Gli hook actionCartSave, hook delete prodotto-in-carrello, actionPresentCartProduct e actionProductPriceCalculation mantengono la riga servizio sincronizzata quando il carrello muta. Compatibile con temi PrestaShop 9, 8, 1.7 incluso thumbnail carrello Hummingbird via actionPresentProduct.

Ogni regola servizio supporta un'identita visiva al checkout: carica JPG/PNG/GIF/WebP in views/img/services/ o incolla un URL HTTPS esterno. ConorderservicesRuleImage gestisce validazione upload, storage, risoluzione URL pubblico e cancellazione sicura quando le immagini vengono sostituite o rimosse.

L'UI editor immagini dedicata (adminPolicyRuleImage.js) mostra anteprima live, controlli rimuovi/sostituisci e fallback mantieni-precedente durante il salvataggio. Alla duplicazione o import policy, le immagini vengono clonate o referenziate in sicurezza così i trasferimenti staging-produzione non rompono le visual checkout.

Dimensione icona (1-256 px), posizione icona (sinistra/centro/destra) e allineamento controllo sono Impostazioni globali - così un negozio può mostrare icone confezione regalo grandi a sinistra mentre un altro mantiene checkbox compatte allineate a destra. Toggle mostra/nascondi per nome, descrizione, prezzo e icona per negozio completano lo strato presentazione.

La scheda Simulatore è un flusso in tre passi su dati reali nel database - non un carrello mock. Passo 1: cerca carrelli per ID, nome cliente o email. Passo 2: scegli un carrello dall'elenco live (mostra cliente, email, totale carrello, ultimo aggiornamento). Passo 3: esegui valutazione e leggi il breakdown risultato completo.

I risultati mostrano quali policy corrispondono, quali sono state saltate (e perché), costi calcolati per regola, stato idoneo vs selezionato, risoluzione gruppo radio e anteprima riga carrello con etichetta e importo combinati. Filtro cliente opzionale restringe l'elenco carrelli a un account - ideale per riprodurre un ticket supporto.

Ogni esecuzione simulazione viene registrata nel log di audit con tipo evento simulation_run, ID carrello, attore (dipendente) e snapshot risultato. Il merchandising può verificare una campagna prima di abilitarla. Il supporto può spiegare perché un carrello cliente specifico ha o non ha visto la confezione regalo - senza piazzare un ordine test sul negozio live.

Usa il simulatore dopo ogni modifica policy, prima del go-live festivo, e quando importi policy da staging. È la rete di sicurezza che separa la gestione servizi enterprise da "modifica e spera".

La scheda Dashboard è la sala controllo dei servizi opzionali. Le card KPI su un periodo selezionabile (30 / 90 / 180 / 365 giorni) mostrano: impressioni pannello, selezioni checkout, ordini con servizi, tasso acquisto e ricavi servizio in valuta negozio. I numeri provengono dal log di audit - eventi reali, non stime.

Grafici di tendenza Chart.js visualizzano il funnel di ricavi su tre granularità: giornaliera (finestra configurabile), settimanale e mensile. Le linee tracciano impressioni, selezioni, ordini pagati e ricavi servizio su asse secondario. Cambia il tipo grafico predefinito in Impostazioni. Un grafico a torta ripartisce i ricavi pagati per codice servizio così vedi quali extra convertono davvero.

La tabella per servizio elenca ogni codice servizio con impressioni, selezioni, ordini, ricavi e tasso acquisto. Le selezioni sono un passo funnel - ordini e ricavi sono la verita KPI (evita metriche vanita da toggle checkbox che non convertono). Le voci audit recenti compaiono in dashboard per troubleshooting a colpo d'occhio.

Per agenzie e operatori multistore: la dashboard risponde alla domanda che il merchandising fa sempre - "I nostri extra checkout vendono davvero?" - con dati, non sensazioni.

La scheda dedicata Log di audit è un journal eventi completo - non un file debug sepolto nei log server. Ogni riga memorizza timestamp, tipo evento, attore (nome dipendente, nome cliente o SYSTEM), riepilogo leggibile, riferimento ordine collegato, codice servizio, importo costo, ID carrello e ID policy/regola.

20+ tipi evento tracciati:

• service_impression - pannello checkout mostrato al carrello
• service_selected / service_deselected - il cliente attiva/disattiva un servizio
• service_applied - servizi sincronizzati alla riga carrello
• order_services - ordine piazzato con ricavi servizio (per riga)
• order_validated - hook validazione ordine attivato
• 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 condizione caricato nel builder
• settings_updated - modifica configurazione modulo
• simulation_run / simulation - valutazione carrello back office

Clicca Visualizza su qualsiasi riga per aprire un modal dettaglio con lo snapshot JSON completo - righe servizio applicate, diff policy, output simulazione o payload modifica impostazioni. Le applicazioni servizio memorizzano un fee_snapshot così puòi ricostruire esattamente cosa ha visto il cliente al checkout.

L'elenco supporta export CSV nativo PrestaShop per revisioni finance e compliance. Colonne join mostrano riferimento ordine, nome cliente e nome dipendente senza cross-reference manuale. Nella pagina ordine back office (hook displayAdminOrder), un pannello mostra quali servizi opzionali hanno contribuito a quell'ordine - nome servizio, codice, importo e snapshot.

Le policy sono documenti JSON portabili. Esporta scarica la policy completa - albero condizioni, tutte le regole, config prezzi, strategia merge, metadata immagini servizio, posizioni - pronta per version control o passaggio a un altro negozio. Importa carica un file JSON e crea una nuova policy con voce log di audit policy_imported.

Duplica clona una policy con un clic dal menu azioni elenco via ConorderservicesPolicyDuplicator - copia ogni regola, rinomina con suffisso, clona immagini in sicurezza, registra policy_duplicated. Perfetto per creare "Holiday v2" da "Holiday v1" senza ricostruire 10 regole a mano.

Flusso tipico agenzia: costruisci e simula su staging -> esporta JSON -> importa in produzione -> riesegui simulatore -> abilita. Le configurazioni servizio stagionali si spostano tra negozi clienti in minuti. Ogni trasferimento e tracciabile nel log di audit.

La scheda Impostazioni centralizza il comportamento a livello negozio. Interruttore master abilita/disabilita. Strategia merge globale predefinita per nuove policy. Gruppo regole fiscali predefinito per nuove regole servizio. ID prodotto servizio - scegli quale prodotto catalogo rappresenta la riga carrello o usa il prodotto nascosto auto-creato CONORDERSVC-SERVICE.

Posizione display controlla dove il pannello checkout viene renderizzato: blocco integrato riepilogo carrello, solo pagina carrello, solo riepilogo checkout, hook tema carrello e checkout, o sotto elenco prodotti carrello. Le impostazioni display offerta controllano mostra/nascondi nome, descrizione, prezzo e icona; dimensione icona (1-256 px); posizione icona (sinistra/centro/destra); allineamento controllo checkbox/radio.

Log debug scrive tracce verbose del motore per supporto. La sezione analytics configura periodo grafico predefinito (30/90/180/365 giorni), finestre grafico giornaliero/settimanale/mensile e tipo grafico predefinito. Anteprima live in Impostazioni mostra come appariranno le righe offerta con le opzioni display correnti.

Ogni salvataggio impostazioni registra settings_updated nel log di audit con snapshot prima/dopo. Nessuna deriva configurazione silenziosa.

I servizi materializzano come riga carrello reale sul prodotto nascosto condiviso con prezzo dinamico ed etichetta multilingue. Compaiono in riepilogo carrello, checkout, conferma ordine, fatture e vista ordine back office - esattamente come una riga prodotto normale, senza hack tema o importi negativi finti.

Il motore si aggancia a actionCartSave, add/remove prodotto, init front controller, validazione ordine (actionValidateOrder, actionValidateOrderBefore su PS 8.1+) e presentazione carrello - ricalcolando ogni volta che il contesto carrello cambia. Le colonne tabella ordine conorderservices_service_amount e conorderservices_service_snapshot memorizzano totali servizio storici sul record ordine.

Le policy sono scoped per negozio (id_shop) per setup multistore. Ogni negozio del gruppo può eseguire stack servizio indipendenti. PrestaShop 9, 8 e 1.7 condividono un codebase via lib/prestashop9compatibility.php e ConorderservicesCompatibility.

Etichette checkout multilingue per regola (conorderservices_rule_lang) assicurano che la riga servizio sia corretta in ogni lingua negozio attiva. 30 pacchetti di traduzione pronti all'uso coprono back office e front office via PrestaShop l() - dall'inglese, tedesco e polacco a spagnolo, francese, italiano e mercati in Europa e Asia.