כיצד לשלב את 1C:Public Catering עם 1C-Bitrix למשלוחי מזון
בעת שילוב 1C:Public Catering עם אתר מבוסס Bitrix, הבעיה העיקרית היא חוסר התאמה בין מבני המינוח. מערכת החשבונאות משתמשת במנות, כרטיסי טכנולוגיה, מודיפיקטורים ומוצרים חצי-מוגמרים, בעוד שחנות המקוונת מצפה לקטלוג שטוח עם מחירים. ללא הגדרת החלפה נכונה, קטלוג האתר יהיה חלקי והזמנות לא יועברו כראוי לתוכנה. אחד הלקוחות שלנו — רשת של 8 פיצריות — נתקל בבעיה שההחלפה הסטנדרטית לא העבירה מודיפיקטורים (גודל, בצק, תוספות), כך שכל פריט היה צריך להיכנס ידנית. הפתרון לקח 12 ימי עבודה וחסך 20 שעות עבודה ידנית בשבוע, והפחית את המאמץ ב-80%.
מינוח ב-Public Catering: מה שונה
ב-1C:Public Catering, ספריית "מינוח" מורחב עם סוגים ספציפיים: מנות, מוצרים חצי-מוגמרים, סחורות, שירותים. אתר משלוחים צריך רק מנות (ולפעמים סחורות — משקאות ארוזים). מוצרים חצי-מוגמרים לא מועלים לאתר — הם אובייקטים פנימיים של ייצור. קטלוג טיפוסי מכיל 50 עד 200 מנות לכל סניף.
כיצד להעביר כראוי מודיפיקטורים מ-1C:Public Catering?
המנה "פיצה מרגריטה" עשויה לכלול מודיפיקטורים: גודל (25/30/35 ס"מ), סוג בצק (דק/עבה), תוספות נוספות. במודול 1C, מודיפיקטורים הם ספרייה נפרדת המקושרת למנה דרך "קבוצות מודיפיקטורים". תקן CommerceML אינו כולל תג עבור מודיפיקטורים — יש להעביר אותם דרך ДополнительныеРеквизиты או דרך מאפיינים.
בצד Bitrix, מודיפיקטורים מיושמים כ-SKU או כמאפיינים מותאמים אישית עם מבנה JSON. שתי הגישות עובדות; SKU פשוט יותר לקטלוג סטנדרטי, JSON גמיש יותר לשילובים מורכבים. שימוש ב-JSON עבור מודיפיקטורים יעיל פי 3-5 מאשר SKU מבחינת ניהול קטלוג. נשווה אותם בטבלה.
| שיטה | מספר SKU | גמישות | מורכבות תמיכה |
|---|---|---|---|
| מאפיינים (SKU) | גדל ליניארית עם מספר המודיפיקטורים | נמוכה | פשוטה |
| JSON במאפיין | מוצר אחד עם JSON | גבוהה | בינונית |
עבור מנות פשוטות (רק גודל), מאפיינים עובדים היטב. עבור שילובים מורכבים (גודל × בצק × תוספות), JSON מפחית את מספר הפריטים פי 3–5.
תוכנית העברה למודיפיקטורים דרך מאפיינים
ב-1C:Public Catering, הפעל העברה של קבוצות מודיפיקטורים כמאפייני מנה.
דוגמת XML למנה עם מודיפיקטורים
<!-- Пример XML для блюда с модификаторами --> <Товар> <Ид>abc-123</Ид> <Наименование>Пицца Маргарита</Наименование> <ХарактеристикиТовара> <ХарактеристикаТовара> <Ид>size-25</Ид> <Наименование>Размер 25 см</Наименование> <Цена>450</Цена> </ХарактеристикаТовара> <ХарактеристикаТовара> <Ид>size-30</Ид> <Наименование>Размер 30 см</Наименование> <Цена>650</Цена> </ХарактеристикаТовара> </ХарактеристикиТовара> </Товар> Bitrix קורא את המאפיינים ויוצר SKU. לכל SKU יש מחיר משלו. זה עובד עבור מודיפיקטורים פשוטים (גודל). עבור שילובים מורכבים (גודל × בצק × תוספות), מספר ה-SKU מתפוצץ: 3 גדלים × 2 בצקים × 10 תוספות = 60 SKU למנה. במקרה כזה, עדיף להעביר מודיפיקטורים כ-JSON במאפיין מנה מותאם אישית ולטפל בהם בצד הפרונטאנד.
תפריט וקטגוריות
בתוכנת החשבונאות, תפריט הוא אובייקט נפרד המקשר מנות לסניפים ולשעות היום. באתר, זה בדרך כלל רק סעיפי קטלוג (חם, קר, משקאות). מיפוי: "סוג מינוח" או "קבוצת מינוח" ב-Public Catering → סעיף בלוק מידע ב-Bitrix.
בעיה: מנה יכולה להשתייך למספר קטגוריות תפריט (למשל, "ארוחת עסקים" ו"מנות עיקריות"). CommerceML סטנדרטי מעביר קבוצה אחת. קישור למספר סעיפים צריך להיות מיושם דרך handler מותאם אישית או מאפיין נוסף של "קטגוריות נוספות".
פתרון בעיות בהעברת הזמנות ל-1C:Public Catering
הזמנות משלוחי מזון מהאתר חייבות להיכנס למערכת כ"הזמנת משלוח" או "מכירה". CommerceML סטנדרטי יוצר הזמנות לקוח, אבל המודול צריך קישור לכתובת משלוח, זמן משלוח ואזור.
כתובת המשלוח מועברת דרך מאפייני הזמנה. ב-Bitrix, אלה שדות פרופיל קונה סטנדרטיים. ב-XML של ההזמנה, הם נכנסים לסעיף <!-- Пример XML для блюда с модификаторами --> <Товар> <Ид>abc-123</Ид> <Наименование>Пицца Маргарита</Наименование> <ХарактеристикиТовара> <ХарактеристикаТовара> <Ид>size-25</Ид> <Наименование>Размер 25 см</Наименование> <Цена>450</Цена> </ХарактеристикаТовара> <ХарактеристикаТовара> <Ид>size-30</Ид> <Наименование>Размер 30 см</Наименование> <Цена>650</Цена> </ХарактеристикаТовара> </ХарактеристикиТовара> </Товар> . Public Catering עשוי שלא לקרוא שדות כתובת לא סטנדרטיים במהלך ייבוא — יש צורך ב-handler בצד 1C. בניסיון שלנו, פתרנו זאת עם מודול מותאם אישית שהופך את הכתובת לפורמט שהתוכנה מבינה.
מקרה בוחן: רשת פיצריות (מהניסיון שלנו)
רשת של 8 פיצריות: אתר Bitrix אחד, לכל סניף יש מסד נתונים משלו של 1C:Public Catering (לא מרוכז). משימה: קטלוג אחיד עם מחירים (מחירים זהים), אבל הזמנות חייבות להגיע למסד הנתונים של הסניף הספציפי לפי אזור המשלוח.
פתרון: ייצוא קטלוג מרכזי ממסד נתונים "ראשי" של Public Catering ל-Bitrix (פעם ביום). הזמנות מנותבות באתר: אזור המשלוח נקבע לפי כתובת → בחירת נקודת קצה של הסניף הספציפי → הזמנה נשלחת למסד הנתונים המתאים.
לכל מסד נתונים של סניף יש כתובת החלפה משלו ב-Bitrix (מספר צמתי החלפה, אחד לכל סניף). הנתב הוא רכיב מותאם אישית ב-Контрагент → Адреса.
זמן יישום: 12 ימי עבודה כולל בדיקת כל הסניפים. עלויות הגדרת אינטגרציה נעות בין $450–650 לסניף בודד ועד $1.4k–1.9k לרשת. חיסכון בפעולות ידניות יכול להגיע עד $270–390 בחודש. הפתרון ביטל 80% מהזנת הנתונים הידנית.
תהליך הגדרת האינטגרציה
| שלב | משך | תוצאה |
|---|---|---|
| ביקורת מבנה מינוח | 1-2 ימים | הבנת המיפוי |
| הסכמת מיפוי | יום אחד | תוכנית ייצוא |
| הגדרת ייצוא מודיפיקטורים | 2-4 ימים | העברת SKU/JSON עובדת |
| הגדרת החלפת הזמנות | 2-5 ימים | ניתוב לפי סניפים |
| בדיקות והדרכה | 2-3 ימים | פעולה יציבה |
מה כלול בהגדרה
- ניתוח סכימת נתונים ב-1C:Public Catering ו-Bitrix.
- פיתוח handler מותאם אישית למודיפיקטורים (אם נדרש).
- הגדרת מספר צמתי החלפה (לרשתות).
- מסירת תיעוד והדרכה.
- תמיכה באחריות למשך 30 יום לאחר ההשקה.
הניסיון שלנו: 8+ שנים באינטגרציות 1C ו-Bitrix, מעל 30 פרויקטים למוסדות מזון. אנו מבטיחים החלפה נכונה ומספקים תעודות התאמה אם נדרש.
צרו קשר להערכת פרויקט — נכין הצעה מסחרית תוך יומיים. קבלו ייעוץ עם מהנדס לדיון בפרטי האינטגרציה.