עם ניסיון של 10+ שנים ו-15+ פרויקטים של משלוחי מזון, אנו מספקים אתרי משלוחי מזון חזקים על 1C-Bitrix. תרחיש טיפוסי: מסעדה משיקה משלוחים, ולאחר חודש מגלה ש-30% מההזמנות אובדות עקב חישוב שגוי של אזור המשלוח, וכל הזמנה עשירית מוכפלת בעת העברה ל-iiko. אנו פותרים זאת עם מטפלי אירועים מותאמים אישית על הפלטפורמה, מבלי לגעת בליבה. התוצאה: הפחתה של 70% בשגיאות ועלייה של 15% בחשבון הממוצע הודות להתאמה אישית. השקעה טיפוסית לפתרון סוהר נעה בין 15,000 ל-30,000 דולר, תלוי באינטגרציות.
פרויקט אחד — רשת פיצריות עם 8 סניפים. לפני האינטגרציה, מנהלים העבירו הזמנות ידנית מפאנל הניהול ל-R-Keeper, מה שלקח עד 5 דקות להזמנה. לאחר אוטומציה דרך iiko REST API, הזמן ירד ל-10 שניות, ושגיאות הקלט נעלמו. שילבנו עם iiko למעלה מ-50 רשתות מסעדות.
קטלוג תפריט: קטלוג מסחרי עם מודיפיקטורים
הקטלוג בנוי על הקטלוג המסחרי של Bitrix. כל מנה היא אלמנט של בלוק מידע המקושר לקטלוג מסחרי. קטגוריות (פיצה, סושי, המבורגרים, משקאות, קינוחים) הן סעיפים של בלוק המידע. ניתן לקטלג למעלה מ-500 מנות בקלות.
מאפייני אלמנט: הרכב (טקסט), משקל (גרם), קלוריות/חלבון/שומן/פחמימות (מספרי), זמן בישול (דקות, משמש לחישוב זמן המשלוח), תוויות (רשימה מרובה: חריף, צמחוני, חדש, להיט), תמונה (מאפיין קובץ חובה).
מודיפיקטורים דרך הצעות מסחריות (SKU). פיצה 25 ס"מ ו-35 ס"מ — שני SKU עם מחירים ומשקלים שונים. תוספות (גבינה נוספת, בייקון, פטריות) — מיושמות דרך מאפייני הצעת מסחר מסוג 'רשימה' עם תוספת תשלום. כאשר נבחרת תוספת, רכיב JS בחזית מחשב מחדש את העלות הכוללת.
גישה חלופית למודיפיקטורים המוניים (רטבים לכל מנה) — בלוק מידע נפרד "תוספות" עם קשר רבים-לרבים דרך מאפיין קישור. בחזית, בעת הוספת מנה לעגלה, מופיע חלון לבחירת תוספות.
יישום מודיפיקטור למנה
כל מנה יכולה להיות עם מספר מודיפיקטורים: גודל, רוטב, מרכיבים נוספים. זה מיושם דרך הצעות מסחריות (SKU) עם תוספת תשלום או בלוק מידע נפרד למודיפיקטורים המוניים. בחזית, בעת בחירת תוספות, רכיב JS מחשב מחדש את הסכום הכולל, ובצד השרת, מודיפיקטורים מועברים למערכת המטבח. מבנה המודיפיקטורים הנכון הוא המפתח להצגה תקינה ב-iiko וללא שגיאות במהלך העברת ההזמנה.
קודי קידום ותוכנית נאמנות
קודי קידום — מנגנון סטנדרטי של מודול sale. סוגי הנחות: סכום קבוע להזמנות מעל N דולרים, אחוז על כל ההזמנה או קטגוריה, משלוח חינם, מתנה עם הזמנה (הוספת מוצר בעלות אפס).
תוכנית נאמנות — מצטברת. חשבון משתמש פנימי (מודול sale, סעיף "חשבונות לקוחות"): צבירת בונוסים כאחוז מההזמנה, מימוש בהזמנה הבאה. כללי הצבירה מוגדרים דרך הלוגיקה העסקית של המודול ללא פיתוח מותאם אישית.
התראות Push על סטטוס הזמנה
כאשר סטטוס ההזמנה משתנה (התקבלה → בבישול → בדרך → נמסרה), הלקוח מקבל הודעה. ערוצים:
- SMS — דרך
messageserviceעם ספק מחובר (SMS.ru, SMSC) - דוא"ל — תבניות אירועי דוא"ל של מודול
sale - Push בדפדפן — דרך Web Push API (Service Worker + מפתחות VAPID)
התראות Push מיושמות דרך מטפל מותאם אישית לאירוע OnSaleStatusOrder. כאשר הסטטוס משתנה, המטפל בודק את המינוי של המשתמש ושולח Push דרך פרוטוקול Web Push. המינוי מתבקש בהזמנה הראשונה.
עגלה עם אזורי משלוח
עגלת משלוחי המזון שונה מחנות מקוונת רגילה. תכונות מפתח:
אזורי משלוח לפי גיאולוקציה
העיר מחולקת לאזורים, לכל אחד פרמטרים משלו:
| פרמטר | אזור 1 (מרכז) | אזור 2 (אזורי מגורים) | אזור 3 (פרברים) |
|---|---|---|---|
| רדיוס | עד 3 ק"מ | 3–7 ק"מ | 7–15 ק"מ |
| זמן משלוח | 30–45 דקות | 45–60 דקות | 60–90 דקות |
האזורים מאוחסנים בבלוק עומס גבוה עם מצולעי קואורדינטות (GeoJSON). במהלך התשלום, הלקוח מזין כתובת; JavaScript שולח בקשה ל-Yandex.Geocoder (או DaData), מקבל קואורדינטות, וקובע את האזור דרך point-in-polygon. התוצאה נשמרת במטמון לפי כתובת.
חשיבות הבדיקה הכפולה של סכום ההזמנה המינימלי
סכום ההזמנה המינימלי נבדק בשני מקומות: בחזית (JS חוסם את כפתור התשלום) ובצד השרת (מטפל OnSaleBeforeOrderAdd מחזיר שגיאה). בדיקה כפולה מבטלת עקיפה דרך בקשת POST ישירה.
משבצות זמן
הלקוח בוחר "בהקדם האפשרי" או משבצת ספציפית (12:00–12:30, 12:30–13:00). משבצות זמינות נוצרות דינמית: זמן נוכחי + זמן בישול של המנה הארוכה ביותר בעגלה + זמן משלוח לפי אזור. משבצות עבר ומשבצות עמוסות (מגבלת הזמנות למשבצת) אינן זמינות.
שילוב משלוח עם מערכת המטבח
העברת ההזמנה ל-iiko או R-Keeper היא אינטגרציה חובה לאוטומציה. בלעדיה, מנהל מעביר את ההזמנה ידנית מהאתר למערכת הקופה, מבזבז זמן ועושה שגיאות. ה-iiko REST API מהיר פי 3 מהפרוטוקול המיושן R-Keeper XML.
תוכנית אינטראקציה עם iiko:
- הזמנה בוצעה באתר → אירוע
OnSaleOrderAdd - המטפל יוצר בקשת JSON ל-iiko Transport API (
/api/1/deliveries/create) - הבקשה כוללת: פריטים עם SKU מספר העיון של iiko (מיפוי דרך מאפיין בלוק המידע "ID ב-iiko"), כתובת, טלפון, הערה, זמן משלוח
- iiko מחזיר מזהה הזמנה, שנשמר במאפיין ההזמנה של Bitrix
- סוכן cron בודק את iiko כל 2 דקות עבור סטטוס ההזמנה (
/api/1/deliveries/by_id) - כאשר הסטטוס משתנה (בבישול → מוכן → בדרך) — סטטוס ההזמנה ב-
saleמתעדכן, והתראות מופעלות
מיפוי המינוח הוא שלב קריטי. כל מנה באתר תואמת לפריט ב-iiko. החיבור דרך מאפיין בלוק המידע "מזהה חיצוני." בעת הוספת מנה חדשה, המנהל חייב למלא שדה זה — בלעדיו, ההזמנה לא תועבר. אימות בשמירת אלמנט דרך מטפל OnBeforeIBlockElementUpdate. לפי תיעוד 1C-Bitrix, מודול המכירה תומך במטפלי משלוח מותאמים אישית (CDeliveryHandler). עוד על CommerceML.
מבנה מודיפיקטורים של iiko להעברה
מודיפיקטורים מועברים כאובייקטים מקוננים ב-JSON. מבנה המודיפיקטורים של iiko והאתר חייב להתאים — המיפוי מוגדר במהלך האינטגרציה ומקובע בתיעוד.
טיפול בשגיאות: אם iiko לא זמין — ההזמנה נשמרת ב-Bitrix עם סטטוס "ממתין להעברה למטבח." סוכן cron מנסה שוב כל 5 דקות. המנהל רואה הזמנות כאלה בפילטר נפרד בפאנל הניהול ויכול להעביר אותן ידנית.
R-Keeper עובד באופן דומה, אבל דרך פרוטוקול XML (R-Keeper XML API) או שירות מתווך (UCS Delivery). העיקרון זהה: מיפוי, העברה, בדיקת סטטוס.
דוגמה להעברת הזמנה ל-iiko:
{ "organization": "{organization_id}", "order": { "phone": "{client_phone}", "items": [ { "productId": "{iiko_product_id}", "name": "Пицца 25 см", "amount": 2, "modifiers": [ { "productId": "{iiko_modifier_id}", "name": "Двойной сыр", "amount": 1 } ] } ] } } צור קשר כדי לדון באינטגרציה עם מערכת המטבח שלך.
מעקב אחר שליח
יישום בסיסי — סטטוסי הזמנה ללא מפה. מורחב — הצגת השליח על מפה.
לגרסה המורחבת: השליח משתמש באפליקציה ניידת (מותאמת אישית או של צד שלישי — Yandex.Marshhrutization, Bringo) שמשדרת קואורדינטות. האתר מקבל קואורדינטות דרך API של שירות השליחים ומציג אותן על Yandex.Maps בחשבון האישי של הלקוח. עדכון — לפי בקשה (כפתור "רענן") או אוטומטי דרך בדיקה כל 30 שניות.
שלבי פיתוח
| שלב | תוכן | משך |
|---|---|---|
| אנליטיקה | אזורי משלוח, מיפוי מינוח iiko/R-Keeper, לוגיקה עסקית של העגלה | שבועיים |
| אב-טיפוס | UX של העגלה, תשלום, גרסה ניידת | שבוע |
| עיצוב | סקיצות לקטלוג, עגלה, חשבון אישי | שבועיים |
| חזית | קטלוג עם מודיפיקטורים, עגלה, זיהוי אזור, משבצות | 3 שבועות |
| שרת | קטלוג מסחרי, מטפל משלוח, אינטגרציית iiko/R-Keeper | 3 שבועות |
| בדיקות | בדיקת הזמנה מקצה לקצה (אתר → מטבח → שליח → לקוח), עומס | 1.5 שבועות |
| השקה | פריסה, ניטור אינטגרציה, הדרכת מפעילים | 3 ימים |
סה"כ: 12–14 שבועות. סיכון הלו"ז העיקרי הוא אינטגרציית מערכת המטבח: תלוי בתיעוד וביציבות ה-API בצד של iiko/R-Keeper.
מה כלול בפיתוח
- תיעוד מלא על אינטגרציית iiko/R-Keeper, מיפוי מינוח ואזורי משלוח
- גישה לפאנל הניהול ולמאגר הקוד
- הדרכת מפעילים על שימוש במערכת וטיפול בשגיאות
- תמיכה אחריות ל-3 חודשים לאחר ההשקה (תיקוני באגים, ייעוץ)
- קוד מקור עם הערות והוראות פריסה
קבל ייעוץ לפרויקט המשלוחים שלך. הזמן פיתוח אתר 1C-Bitrix סוהר. המומחיות שלנו בפיתוח אתרי משלוחי מזון מבטיחה שהעסק שלך יצמח עם אוטומציה אמינה.