פיתוח אתר למסעדה על 1C-Bitrix

{
  "organizationId": "...",
  "order": {
    "phone": "+375...",
    "orderTypeId": "...", // delivery или self-pickup
    "items": [
      {
        "productId": "iiko-product-uuid",
        "amount": 2,
        "modifiers": [...]
      }
    ],
    "address": {
      "street": "...",
      "house": "...",
      "flat": "..."
    },
    "comment": "Без лука"
  }
}

נקודה קריטית — מיפוי productId. בבלוק המידע של Bitrix כל מנה מאחסנת מאפיין IIKO_PRODUCT_ID (מחרוזת, UUID מ-iiko). בעת סנכרון התפריט דרך GET /api/1/nomenclature, קטלוג iiko המלא נטען ומותאם לפריטי בלוק המידע לפי UUID זה. הסנכרון רץ על ידי סוכן CAgent כל 15 דקות או דרך webhook מ-iiko.

מסונכרן מ-iiko ל-Bitrix:

• זמינות מנות (stop-list). iiko שולחת POST ל-webhook endpoint /api/iiko-stoplist/. ה-handler מעדכן את מאפיין STOP_LIST של פריט בלוק המידע המתאים באמצעות CIBlockElement::SetPropertyValuesEx()
• מחיר. אם המסעדה משנה מחירים בקופה, הם חייבים להגיע לאתר. ה-handler בסוכן משווה מחירים מ-/api/1/nomenclature עם PRICE בבלוק המידע ומעדכן הבדלים
• מודיפיירים (תוספות, תוספות צד). מאוחסנים בבלוק מידע נפרד Modifiers עם מאפיין IIKO_MODIFIER_ID

נשלח מהאתר ל-iiko:

• הזמנה עם פריטים, כתובת, הערה
• סוג תשלום (אונליין או במשלוח)
• קוד קופון, אם יש — הנחה מחושבת בצד iiko

אינטגרציה עם r_keeper:

r_keeper משתמש ב-UCS DeliveryPOS API. העיקרון דומה, אבל הפרוטוקול הוא XML-RPC במקום JSON REST. בקשות עטופות במעטפת XML, תשובות מנותחות באמצעות SimpleXMLElement. מיפוי מוצרים לפי MenuItemID. המורכבות העיקרית — r_keeper דורש מנהרת VPN לשרת המסעדה, בעוד iiko עובדת דרך הענן.

אינטגרציה עם Poster POS:

Poster מספקת REST API עם הרשאת OAuth. יצירת הזמנה — POST /api/incomingOrders.createIncomingOrder. Poster פשוטה יותר לאינטגרציה: JSON API, פריסת ענן, webhook לעדכוני סטטוס הזמנה. מיפוי לפי product_id מ-Poster.

טיפול בסטטוס הזמנה: לאחר יצירת הזמנה בקופה, האתר חייב לעקוב אחר הסטטוס שלה. שתי גישות:

1. פולינג — סוכן או משימת cron כל 60 שניות שואל את API הקופה לפי orderId. סטטוסים: התקבלה, בהכנה, בדרך, נמסרה. מעדכן מאפיין STATUS בלוק Highload Orders
2. Webhook — הקופה שולחת POST ל-/api/order-status/ בעת שינוי סטטוס. מועדף עבור iiko ו-Poster, אבל לא תמיד זמין עבור r_keeper

הסטטוס מוצג ללקוח בעמוד /my-orders/ באמצעות פולינג AJAX כל 30 שניות או דרך WebSocket (אם התשתית מאפשרת).

הזמנת שולחנות

רכיב מותאם אישית project:table.reservation עם טופס: תאריך, שעה, מספר אורחים, שם, טלפון, הערה.

לוגיקת הזמנה:

• נתונים נכתבים ללוק Highload Reservations: DATE, TIME, GUESTS, NAME, PHONE, STATUS, TABLE_ID
• שולחנות — לוק Highload נפרד: TABLE_NUMBER, CAPACITY, ZONE (אולם, טרסה, VIP)
• בעת הזמנה, הרכיב בודק זמינות: שאילתה מ-Reservations לפי DATE + TIME עם חלון של +-2 שעות, התאמה לקיבולת של שולחנות פנויים
• אם אין שולחנות פנויים, הצע את הזמן הקרוב הזמין

אינטגרציה עם CRM Bitrix24: כל הזמנה יוצרת ליד באמצעות CRest::call('crm.lead.add', [...]). פרמטרים:

$leadData = [
    'TITLE' => 'Бронь столика: ' . $date . ' ' . $time,
    'NAME' => $name,
    'PHONE' => [['VALUE' => $phone, 'VALUE_TYPE' => 'WORK']],
    'SOURCE_ID' => 'WEB',
    'UF_CRM_TABLE' => $tableNumber,
    'UF_CRM_GUESTS' => $guests,
    'COMMENTS' => $comment
];
CRest::call('crm.lead.add', ['fields' => $leadData]);

המארחת רואה הזמנות ב-CRM ומאשרת אותן. סטטוס ליד אושר → ה-handler מעדכן STATUS בלוק Highload → הלקוח מקבל SMS באמצעות מודול messageservice או שער SMS חיצוני.

אופטימיזציית Frontend

גלריית תמונות ואופטימיזציית תמונות

צילומי אוכל — קבצים כבדים. מקוריים מהצלם — 5-10 MB לתמונה. האתר צריך שלושה גדלים: תמונה ממוזערת לרשימת תפריט (400x300), בינונית לכרטיס מנה (800x600), ובגודל מלא ל-lightbox (1600x1200).

שינוי גודל באמצעות CFile::ResizeImageGet() עם BX_RESIZE_IMAGE_PROPORTIONAL. התוצאה נשמרת במטמון ב-/upload/resize_cache/. עבור WebP — המרה באמצעות imagewebp() ב-handler OnBeforeFileResize או דרך מודול Nginx ngx_http_image_filter_module.

srcset עבור תצוגות Retina:

<img src="/upload/resize_cache/menu/800x600/dish.webp"
     srcset="/upload/resize_cache/menu/400x300/dish.webp 400w, /upload/resize_cache/menu/800x600/dish.webp 800w, /upload/resize_cache/menu/1600x1200/dish.webp 1600w"
     sizes="(max-width: 640px) 400px, (max-width: 1024px) 800px, 1600px"
     loading="lazy"
     alt="Название блюда">

מאפיין loading="lazy" — טעינה עצלה מקורית. עבור דפדפנים ישנים — IntersectionObserver ב-JS. בעמוד תפריט עם 50+ מנות, זה חוסך 30-40 MB של טעינה ראשונית.

Mobile-first: 80% תנועה מטלפונים

אתר מסעדה נח�ש מטלפון — מסעדה קרובה, תפריט משלוחים. התבנית בנויה mobile-first:

• קטגוריות תפריט — גלילה אופקית עם overflow-x: auto, לא תפריט נפתח
• כרטיס מנה — תמונה ברוחב מלא, שם, משקל, מחיר. כפתור הוספה קבוע בתחתית באמצעות position: sticky
• טופס הזמנה — שדות מינימליים. טלפון + כתובת. שם והערה אופציונליים. השלמת כתובת אוטומטית באמצעות API של Dadata (POST https://suggestions.dadata.ru/suggestions/api/4_1/rs/suggest/address)
• טופס הזמנת שולחן — ו- מקוריים במקום datepickers מותאמים אישית

רספונסיביות — CSS Grid + Flexbox בתבנית הרכיב. שלוש נקודות שבירה: 375px (טלפון), 768px (טאבלט), 1280px (מחשב). בדיקות באמצעות Lighthouse: יעד Performance > 90, LCP < 2.5s. שיעור המרה ממוצע להזמנות אונליין הוא 5% במובייל.

תכונות SEO ורב-לשוניות

תפריט רב-לשוני

למסעדות באזורי תיירות — תפריט במספר שפות. ב-1C-Bitrix רב-לשוניות מיושמת באמצעות:

• אתר נפרד במערכת רב-אתרים (LID = s1 לרוסית, s2 לאנגלית). בלוקי מידע מחוברים לשני האתרים, מאפיינים NAME_EN, DESCRIPTION_EN — מאפייני טקסט נוספים
• או באמצעות מאפיין LANGUAGE (רשימה: ru, en, de) וסינון ברכיב לפי שפה נוכחית LANGUAGE_ID

האפשרות הראשונה אמינה יותר: כתובות URL שונות (/menu/ ו-/en/menu/), תגי hreflang נכונים, הגדרות SEO עצמאיות.

Schema.org: Restaurant + Menu

ב-result_modifier.php נוצר סימון JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Название ресторана",
  "servesCuisine": "Итальянская",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "...",
    "addressLocality": "Минск"
  },
  "openingHoursSpecification": [...],
  "menu": {
    "@type": "Menu",
    "hasMenuSection": [
      {
        "@type": "MenuSection",
        "name": "Горячее",
        "hasMenuItem": [
          {
            "@type": "MenuItem",
            "name": "Стейк рибай",
            "description": "...",
            "nutrition": {
              "@type": "NutritionInformation",
              "calories": "850 cal"
            },
            "offers": {
              "@type": "Offer",
              "priceCurrency": "BYN"
            }
          }
        ]
      }
    ]
  }
}

הסימון מוצג באמצעות $APPLICATION->AddHeadString(). סוגים Restaurant, Menu, MenuItem — ישויות Schema.org נפרדות, Google מזהה אותן עבור Rich Snippets בתוצאות חיפוש.

תכונות שיווק

מבצעים והצעות מיוחדות

בלוק מידע Promotions (סוג promotions). מאפיינים: DATE_START, DATE_END, PROMO_TYPE (ארוחת עסקים, happy hour, עונתי), DISCOUNT_PERCENT, LINKED_DISHES (קישור מרובה לפריטי בלוק מידע תפריט).

הצגה בעמוד הראשי באמצעות news.list עם פילטר תאריך: >=DATE_START ו-<=DATE_END יחסית לתאריך הנוכחי. מבצעים שפגו מוסתרים אוטומטית ללא התערבות מנהל.

לארוחת עסקים — סעיף תפריט נפרד עם הגבלת זמן: הרכיב בודק שעת שרת ומציג בלוק ארוחת עסקים רק בין 12:00 ל-16:00.

אירועי מסעדה

בלוק מידע Events — להודעות: מוזיקה חיה, ערבי נושא, טעימות. מאפיינים: EVENT_DATE, EVENT_TIME, DESCRIPTION, COVER_CHARGE (תיבת סימון — כניסה בתשלום/חינם), POSTER (תמונה).

הצגה — פיד בעמוד הראשי (שלושת האירועים הקרובים) ועמוד נפרד /events/ עם רשימה. אירועי עבר מועברים לארכיון אוטומטית לפי EVENT_DATE < now().

אינטגרציה עם אגרגטורי משלוחים

Yandex.Eda ו-Delivery Club מספקות API למסעדות שותפות. האינטגרציה דו-כיוונית:

• ייצוא תפריט — יצירת פיד XML/JSON עם פריטים, מחירים, תמונות, stop-list. הפיד נוצר על ידי סוכן כל 30 דקות מבלוק מידע תפריט
• קבלת הזמנות — webhook מהאגרגטור ל-/api/aggregator-order/. ה-handler יוצר הזמנה בלוק Highload ומעביר למערכת הקופה

זה חוסך מהמנהל עדכון ידני של תפריטים בחשבונות אגרגטורים, מפחית עבודה ידנית בכ-10 שעות בשבוע, שווה ערך לחיסכון חודשי של כ-$1,000.

תוצרים ותמיכה

• תיעוד: מבנה בלוק מידע מפורט, תוכנית אינטגרציית API, רשימת בדיקות פריסה.
• הדרכת מנהל: פגישת וידאו אחת של שעתיים המכסה ניהול תפריט, עיבוד הזמנות ופתרון תקלות.
• תמיכה לאחר השקה: חודש אחד של תיקוני באגים והתאמות קטנות (עד 5 שעות).
• גישה: גישה מלאה לפאנל הניהול של Bitrix, מאגר קוד מקור, ואישורי אינטגרציית קופה.

עלות הקמה טיפוסית לאינטגרציית קופה: $2,500. עלות פרויקט כוללת ממוצעת: $9,000.

שלבי פיתוח

1. גילוי (1-2 שבועות) — מבנה בלוק מידע, תוכנית אינטגרציית קופה, אבות טיפוס של עמודים, מיפוי נתונים בין Bitrix למערכת קופה
2. עיצוב (1-2 שבועות) — מוקאפים: עמוד ראשי, תפריט (רשימה + כרטיס), הזמנת שולחן, משלוחים, מבצעים
3. Backend (2-4 שבועות) — בלוקי מידע, רכיבי תפריט והזמנת שולחן, אינטגרציית קופה, CRM, עיבוד הזמנות
4. Frontend (1-3 שבועות) — תבניות רספונסיביות, אופטימיזציית תמונות, טפסי הזמנה והזמנת שולחן, עדכוני סטטוס AJAX
5. אינטגרציות (1-2 שבועות) — מערכת קופה, אגרגטורי משלוחים, הודעות SMS, מערכת תשלומים
6. בדיקות (1-2 שבועות) — פונקציונליות, הזמנות בדיקה דרך קופה, בדיקות מובייל, בדיקות עומס
7. השקה (3-5 ימים) — פריסה, ניטור סנכרון קופה, אימות עם הזמנות אמיתיות

עלויות הפיתוח משתנות; פרויקט טיפוסי מתחיל ב-$3,500 עבור אתר בסיסי עם תפריט+הזמנת שולחן ויכול לעלות על $15,000 עבור מערכת מלאה עם כל האינטגרציות.

לקוחות בדרך כלל רואים עלייה של 30% בהזמנות אונליין תוך 3 חודשים וגודל סל ממוצע גדל ב-25%.

צירי זמן תלויים במערכת הקופה הנבחרת (iiko משתלבת מהר יותר מ-r_keeper בשל API ענן), מספר השפות ודרישות חשבון הלקוח. בממוצע, אינטגרציית iiko אורכת 2-3 שבועות, r_keeper 3-4 שבועות, ו-Poster 1-2 שבועות.