ilMenu

Elenca gli abbinamenti manuali e le aggiunte consigliate dei piatti di un menu, inclusi quelli senza suggerimenti. Richiede il modulo selling. Le preferenze sono condivise con web e app; la visibilità pubblica dipende da sede, orari e disponibilità. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Cerca nel nome e nella descrizione dei piatti in italiano di un menu, anche nascosti o esauriti, senza distinzione maiuscole/minuscole. Restituisce già descrizione, prezzo, varianti con prezzi e allergeni. Ometti category_id per cercare in tutte le categorie e sottocategorie del menu; se presente filtra solo quella precisa. Usa next_offset per le altre pagine. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Elenca eventi e promozioni in italiano, anche disattivati. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Elenca i menu del locale collegato. Può essere attivo al massimo un menu: attivarne uno disattiva gli altri. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Riordina tutte le categorie sorelle del menu, comprese quelle nascoste. Passa gli ID nell’ordine desiderato; parent_id per le sottocategorie. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Riordina tutti i piatti di una categoria, compresi quelli nascosti, passando tutti gli ID nell’ordine desiderato. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Imposta esplicitamente se la categoria è nascosta nel menu pubblico, senza eliminarla. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Attiva o disattiva la proposta di una combo dal dettaglio di un suo componente esistente. Richiede selling. Non aggiunge piatti né modifica prezzo, quantità, ordine o visibilità. Se lo stesso piatto compare con più varianti devi specificare variant_token da list_categories. La proposta appare solo quando combo e componente sono visibili al cliente; enabled=true non rimuove restrizioni di sede, orario o Fidelity. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Imposta un piatto come disponibile o esaurito senza nasconderlo. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Imposta cross-selling e upselling manuali del piatto. dish_ids è la lista COMPLETA ordinata degli altri piatti da abbinare, addition_ids quella delle aggiunte da consigliare. Ciascuna lista ammette fino a 12 elementi: omessa resta invariata, [] la svuota. Invia almeno una lista. Abbinamenti direzionali: non modificano il piatto suggerito. Richiede selling; usa get_dish_recommendations e list_dishes prima di salvare. Non cambia prezzi, ingredienti, disponibilità o composizione delle combo e non esegue richieste AI. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Nascondi o mostra un piatto nel menu pubblico. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Attiva o disattiva un evento o una promozione. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Carica o sostituisci un’immagine PNG, JPEG o WebP come base64 (massimo 8 MiB decodificati). Non accetta URL remoti. Archivia il file con URL pubblico, aggiorna tutte le traduzioni dell’elemento e rimuove il precedente file gestito dal servizio se sostituito. Per eventi conserva l’immagine originale; piatti e categorie usano le regole del gestionale. Per i piatti accoda anche l’aggiornamento dell’indice di ricerca con invio dei testi ai servizi AI configurati. Per la foto di una combo usa entity=category e il riferimento della combo: stesso archivio S3 e sincronizzazione delle categorie. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Modifica una categoria o sottocategoria in italiano, incluso testo informativo o categoria padre. Gli spostamenti devono mantenere l’intero ramo entro tre livelli; non è possibile spostare una categoria dentro se stessa o un suo discendente. Le combo sono sottocategorie con is_combo=true, parent_id principale, combo_price e combo_items. L’ordine dell’array determina l’ordine dei componenti. Usa soltanto piatti dello stesso menu; se hanno varianti, scegli variant_token da list_dishes. I componenti nascosti singolarmente sono ammessi; quelli esauriti rendono la combo non ordinabile. Per creare componenti esclusivi usa create_dish nella categoria padre con hide=true, poi includili nella combo. Non duplicare per le traduzioni. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. I testi da tradurre o analizzare vengono inviati ai servizi AI configurati tramite elaborazioni asincrone. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Modifica solo i campi forniti di un piatto italiano. Gli allergeni sostituiscono la lista; una lista vuota rimuove le associazioni. Se le traduzioni esistono sono associati subito; altrimenti allergen_sync.status=pending indica che la selezione è salvata e il backend tradurrà gli allergeni mancanti e completerà le associazioni automaticamente. Non serve risalvare. Anche i testi modificati richiedono traduzione asincrona. Le varianti devono includere tutte quelle esistenti con i relativi token: puoi aggiungerle o modificarle, non eliminarle. Gli allergeni manuali devono provenire da list_allergens. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Per cambiare soltanto il prezzo base invia dish_id, price numerico, operating_zone_id e request_id, più confirm_shared_changes quando necessario. Ometti zone_ids, allergens e variants se non richiesto: preserva visibilità, allergeni e varianti. Per un prezzo di variante usa invece variants con la lista completa esistente e i relativi token. Non duplicare il piatto né la modifica per ogni sede: il prezzo base è condiviso. Il prezzo base salvato viene sincronizzato subito alle traduzioni esistenti, senza attendere job di traduzione. I testi da tradurre o analizzare vengono inviati ai servizi AI configurati tramite elaborazioni asincrone. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Modifica i campi forniti di un evento o promozione. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. I testi da tradurre o analizzare vengono inviati ai servizi AI configurati tramite elaborazioni asincrone. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.

Modifica nome o stato attivo di un menu. active=true disattiva automaticamente tutti gli altri menu del locale nella stessa transazione: non è possibile mantenerne più di uno attivo. active=false può lasciare il locale senza menu attivi. Contesto della scrittura: passa operating_zone_id in ogni chiamata con più sedi; usa null esplicito per «entrambe/tutte le sedi», non omettere il campo. Questa scelta autorizza già l’ambito condiviso, senza un’altra conferma per le sedi. Se scegli invece una sola sede e modifichi campi condivisi con altre, passa confirm_shared_changes=true solo dopo l’autorizzazione dell’utente. Non richiedere di nuovo una conferma già data per la stessa modifica e lo stesso ambito; rispetta comunque le autorizzazioni richieste dal client. Usa un request_id distinto per ciascuna operazione/piatto; nei retry della stessa richiesta conserva UUID e argomenti identici. Esito: conferma il salvataggio solo con una risposta riuscita. In caso di errore indica il messaggio utile restituito dal tool (e lo stato se presente), senza credenziali o dati sensibili; distingui un rifiuto del server da una chiamata non eseguita dal client. Non inventare un «blocco tecnico» o una conferma mancante se la risposta non lo indica. Dopo un errore non ritentare indefinitamente. Le modifiche agli elementi pubblicati possono essere visibili subito nel menu pubblico. Prima consulta get_restaurant e chiarisci la sede operativa con l’utente se ci sono più sedi. Per rendere un piatto/categoria/combo visibile solo in alcune sedi usa zone_ids in create/update, non hide o not_available (globali). Gli elenchi includono tutte le sedi per permettere di trovare anche elementi da rendere visibili; effective_zone_ids indica le sedi consentite dalla gerarchia, non garantisce visibilità effettiva se nascosto, programmato o riservato. Non mostrare ID, token o identificativi tecnici all’utente: usa i nomi degli elementi.