בחנות מקוונת למוצרי אלקטרוניקה, קונה מזין מספר סידורי ורואה את תקופת האחריות, הדגם ותאריך המכירה. או שלקוח מכולת בוחר חלב ורואה שלקבוצה במלאי יש תאריך תפוגה של 25 במאי. ללא הגדרת ייצוא של מספרים סידוריים וקבוצות מ-1C ל-Bitrix, תרחישים כאלה בלתי אפשריים. הסנכרון הסטנדרטי של 1C-Bitrix באמצעות CommerceML מעביר מחירים ויתרות — אך לא מספרים סידוריים וקבוצות. עבור אלקטרוניקה, ציוד רפואי, מוצרי מכולת ותרופות, זה קריטי: ללא מספר סידורי, לא ניתן לארגן שירות אחריות, וללא מעקב קבוצות, לא ניתן לפקח על תאריכי תפוגה. יש לשנות את ההחלפה כך שהאתר יקבל נתונים אלה. הניסיון שלנו מראה שגם העברה מינימלית (למשל, רק תאריך תפוגה) מעניקה לעסק יתרון תחרותי ומפחיתה החזרות בעד 30%.
מדוע ההחלפה הסטנדרטית נכשלת עבור מספרים סידוריים וקבוצות
CommerceML (תקן העברת הנתונים בין 1C ל-Bitrix) אינו מטפל ישירות במספרים סידוריים וקבוצות. מבני ה-XML חסרים תגים למספרים סידוריים ביתרות מוצרים. יש להרחיב את הפורמט: הוסף ДополнительныеРеквизиты למסמך או צור קבצי החלפה נפרדים. חלופה היא REST API, אך 1C UT/KA אינן מספקות שירותי REST מוכנים לניהול קבוצות. תקן CommerceML אינו תומך במספרים סידוריים (ראה תיעוד רשמי).
מספרים סידוריים וקבוצות ב-1C
מספר סידורי — מזהה ייחודי של מופע ספציפי (מספר סידורי). טלוויזיה אחת = מספר סידורי אחד. החשבונאות ברישום ТоварыНаСкладах מתנהלת לפי מספר סידורי.
קבוצה — קבוצת מוצרים מקבלה אחת עם מאפיינים משותפים (תאריך ייצור, תאריך תפוגה, מספר קבוצת יצרן). קופסת חלב אחת מתאריך מסוים = קבוצה אחת. במחסן עשויות להיות 10 קופסאות משתי קבוצות שונות.
ב-1C:UT 11, חשבונאות מספרים סידוריים מופעלת בהגדרות הפריט: השתמש במספרים סידוריים. חשבונאות קבוצות היא הגדרה נפרדת. שני המנגנונים מגדילים את רמת הפירוט ומסבכים את החלפת הנתונים.
נתונים נדרשים באתר
לא תמיד יש צורך להעביר את כל המספרים הסידוריים והקבוצות. תרחישים אופייניים:
| תרחיש | תיאור | מורכבות יישום | הערכת עלות |
|---|---|---|---|
| בדיקת מספר סידורי | הקונה מזין מספר סידורי באתר ומקבל מידע על אחריות, תאריך ייצור | נמוכה — רק בקשת API ל-1C | $1,000 – $2,000 |
| תאריך תפוגה בכרטיס מוצר | כרטיס המוצר מציג את תאריך התפוגה הקרוב ביותר מהקבוצות הזמינות | בינונית — דורש הגדרת משימה מתוזמנת ב-1C ועיבוד ב-Bitrix | $2,000 – $3,500 |
| הקונה בוחר קבוצה ספציפית | הקונה רואה רשימת קבוצות זמינות (תאריכי מילוי, קבוצות אספקה) ובוחר אחת | גבוהה — כל קבוצה הופכת ל-SKU נפרד, דורש HighloadBlock, לוגיקה מורכבת | $4,000 – $6,000 |
המחירים לאינטגרציה נעים בין $2,500 לבדיקת מספר סידורי בסיסית ועד למעל $6,000 לבחירת קבוצה מלאה. לקוחות בדרך כלל רואים החזר השקעה תוך 6 חודשים.
כיצד ליישם תאריך תפוגה כמאפיין?
המקרה המבוקש ביותר הוא העברת תאריך התפוגה הקרוב ביותר מ-1C לאתר. שלבים:
- ב-1C (בצד UT/KA), צור משימה מתוזמנת.
- עבור כל פריט עם חשבונאות קבוצות, קבע את תאריך התפוגה הקרוב ביותר מהיתרות הקיימות.
- כתוב תאריך זה לתוך
ДополнительныйРеквизитשל הפריט "ExpirationDate". - בהחלפה הבאה, מאפיין זה יופיע ב-XML ויעדכן את המאפיין ב-Bitrix.
חלופה: בקשת HTTP ישירה מ-Bitrix לשירות 1C בעת טעינת כרטיס המוצר. עם זאת, זה יוצר תלות של מהירות העמוד במהירות 1C; זמן התגובה עשוי לגדול ב-300ms.
כיצד להעביר מספרים סידוריים במהלך הזמנה?
אם קונה מזמין מוצר עם חשבונאות מספרים סידוריים — בעת משלוח מ-1C, מספר סידורי ספציפי מצורף להזמנה. כדאי להעביר מספר זה חזרה ל-Bitrix: בחשבון האישי, הקונה רואה את המספרים הסידוריים של המוצרים שרכש — נוח לשירות אחריות.
העברה הפוכה של מספרים סידוריים: ב-CommerceML, הזמנה בעת עדכון סטטוס יכולה להכיל נתונים מורחבים. הוסף לוגיקת שמירה למספרים סידוריים מ-AdditionalRequisites של המסמך ל-handler עדכון הסטטוס ב-Bitrix.
// Обработчик обновления заказа из 1С function onOrderStatusUpdate($arOrder, $arXML) { foreach ($arXML['ITEMS'] as $item) { if (!empty($item['SERIAL_NUMBERS'])) { saveSerialNumbers( $arOrder['ID'], $item['PRODUCT_ID'], $item['SERIAL_NUMBERS'] ); } } } הזמנת קבוצות ב-1C
כאשר הזמנה מתבצעת באתר ונשלחת ל-1C, יש להזמין קבוצה ספציפית (במיוחד עם תאריך תפוגה קצר). מנגנון ההזמנה הסטנדרטי ב-1C מזמין אוטומטית קבוצה באמצעות אלגוריתם FEFO (First Expired First Out).
באתר, הקונה אינו בוחר קבוצה — 1C עושה זאת. האתר מעביר רק את הכמות. 1C מזמין את הקבוצה המתאימה ויכול להחזיר מידע עליה (תאריך התפוגה של הקבוצה המוזמנת) בתגובת ההזמנה.
REST API לעומת CommerceML להעברת מספרים סידוריים
REST API עדיף על CommerceML להעברת מספרים סידוריים. הוא מאפשר החלפת נתונים ללא תלות בסכמת ה-XML של CommerceML. מספרים סידוריים מועברים בפורמט JSON, שקל יותר לעבד. מהירות ההחלפה גדלה פי 2-3, ושגיאות תחביר מתבטלות.| היבט | CommerceML | REST API |
|---|---|---|
| פורמט נתונים | XML | JSON |
| מהירות | איטית יותר | מהירה יותר (פי 2-3) |
| מורכבות הגדרה | בינונית | בינונית |
| תמיכה במספרים סידוריים | דורש הרחבה | מובנית |
מקרה מהפרקטיקה שלנו: יצרן מזון
הלקוח שלנו הוא יצרן מוצרי חלב. מכירות B2B ישירות מהאתר לקמעונאים. כל הזמנה היא עבור SKU ספציפיים תוך התחשבות בקבוצות (תאריך ייצור, תאריך תפוגה). הקמעונאי רוצה לראות באתר לא רק 'חלב 1L', אלא 'חלב 1L, יוצר 10.03, תפוגה 20.03'.
יישמנו באמצעות HighloadBlock 'קבוצות': במהלך כל החלפה (כל שעתיים), רשימת קבוצות זמינות עבור כל פריט מועברת מ-1C. בכרטיס המוצר יש תפריט נפתח 'בחר תאריך ייצור'. בעת הוספה לעגלה, מזהה הקבוצה נשמר. כאשר ההזמנה נשלחת ל-1C, GUID הקבוצה מצוין במאפייני פריט ההזמנה.
1C מזמין את הקבוצה הספציפית — אין שגיאות תאריך תפוגה. חיסכון ללקוח: הפחתה של 20% בקלקול עקב תאריכי תפוגה, השווה ל-$50,000 בשנה.
תוצרים והיקף פרויקט
- ביקורת על החלפת 1C-Bitrix הנוכחית (יומיים)
- מסמך עיצוב עם תוכנית העברת מספרים סידוריים/קבוצות (יום אחד)
- שינוי 1C: משימות מתוזמנות, מאפיינים נוספים (3-5 ימים)
- שינוי Bitrix: מאפיינים, בלוקי HL, handlers להזמנות (3-5 ימים)
- בדיקות והשקה (יומיים)
- תיעוד והדרכה (יום אחד)
- תמיכה לאחר יישום (חודש אחד)
אנו עובדים עם 1C למעלה מ-7 שנים והשלמנו יותר מ-30 אינטגרציות עם Bitrix. נבחן את הפרויקט שלך תוך יום אחד. הזמן הגדרת ייצוא סוהרת למספרים סידוריים וקבוצות מ-$5,000. קבל ייעוץ כבר עכשיו.
במדריך זה, סקרנו כיצד להגדיר את החלפת 1C Bitrix עבור מספרים סידוריים וקבוצות. עבור אינטגרציה של חשבונאות קבוצות במסחר אלקטרוני, הגדרה נכונה מבטיחה מידע מדויק על מלאי ותפוגה.