Hur en pide-kedja med 30 restauranger centraliserar menyhanteringen

"Pide Sarayı" öppnade 1987 som en liten butik på Tunalı-gatan i Ankara. Idag har kedjan 30 restauranger, och ägaren Hakan står inför ett klassiskt problem: köttfärs-pide kostar 95₺ i Tunalı men 75₺ i Eskişehir, medan beskrivning, allergener och bilder måste vara identiska.

Parent-child-modell

I thMenu vilar multi-platshantering på parent_restaurant_id. Tunalı-restaurangen är "parent", de andra 29 är barn. Produkter ärvs; endast prisskillnader hamnar i price_override-tabellen.

Vid QR-skanning löser API:t override via en säker subquery (inte JOIN). Tunalı visar 95₺, Eskişehir 75₺. Samma SKU, beskrivning, bild.

Regional override-lager

Restauranger grupperas: 8 Marmara-butiker köper från samma leverantör. Istället för 8 individuella overrides skapar vi en region_id "Marmara".

Lösningsordning: restaurang > region > parent. 85% av restaurangerna hanteras på regionsnivå.

Nattlig push kl. 03:00

Hakan lägger till novemberkampanj i admin och schemalägger till 2026-11-01 03:00 UTC. Cron invaliderar cacher på 30 restauranger och skriver ny meny till KV. Kl. 05:00 ser alla gäster kampanjen.

POS-baserade priser skulle vara en mardröm. Menybaserade priser är den enda sanningen.

FAQ

Restaurang lämnar centralmenyn? parent_restaurant_id till NULL; rensa overrides manuellt.

Franchise-overrides? Ja, med rollbaserad åtkomst.

Vilken plan? Multi-plats från Pro+.

Var detta hjälpsamt? Dela det.