הגדרת ייצוא הזמנות מביטריקס ל-1C:UT — מפתח מלא
אנו מגדירים ייצוא הזמנות מחנות הביטריקס שלך ל-1C:UT כך שמנהלים לא יצטרכו להעביר נתונים ידנית. זהו החלק השני של סנכרון דו-כיווני: מחירים ופריטים עוברים מלמעלה למטה (מ-1C לאתר), בעוד הזמנות עוברות מלמטה למעלה (מהאתר ל-1C). ללא הגדרת ייצוא נכונה, התפעול נתקע: הזמנות אובדות, גורמים חוזרים נוצרים כפולים, וסטטוסים לא מסונכרנים.
אנו לוקחים על עצמנו את הטמעת הסנכרון מקצה לקצה: מהגדרת צומת הסנכרון בביטריקס ועד לבדיקת הזמנת ניסיון. תוך 2 ימי עבודה תקבל העברת הזמנות יציבה עם אפשרות לסנכרון סטטוסים חזרה. רקורד העבודה שלנו: למעלה מ-10 שנות אינטגרציות ביטריקס-1C ו-500+ פרויקטים מוצלחים — אנו מבטיחים שהאוטומציה מפחיתה שגיאות ידניות ב-90% בהשוואה להזנה ידנית. אנו גובים מ-$270–390 עבור הגדרה בסיסית.
מה מועבר בהזמנה
בעת ייצוא הזמנה מביטריקס בפורמט CommerceML, מועברים הבאים:
- כותרת הזמנה: מספר, תאריך, סטטוס, הערה
- גורם: שם מלא / שם חברה, ח.פ., כתובת, טלפון, אימייל
- פריטי הזמנה: XML_ID של המוצר (או SKU), כמות, מחיר, סה"כ
- משלוח: שיטת משלוח, כתובת, עלות
- תשלום: שיטת תשלום, סטטוס תשלום
- מאפיינים נוספים: שדות הזמנה מותאמים אישית, אם מועברים
ב-UT ההזמנה נוצרת כ"הזמנת לקוח". הגורם נמצא לפי ח.פ. (לגורמים משפטיים) או לפי שם מלא (ליחידים). אם לא נמצא, נוצר חדש.
מיפוי סטטוסים: נקודת הכשל המרכזית
סטטוסי הזמנה בביטריקס הם קודי מחרוזת (N = חדש, P = שולם, F = בוצע). ב-UT הם ערכים מוגדרים מראש (НовыйЗаказ, ВРаботе, Выполнен). יש להגדיר את ההתאמה במפורש.
בהגדרות צומת הסנכרון של ביטריקס (הגדרות → חנות → אינטגרציה עם 1C) קיימת טבלת מיפוי סטטוסים. תצורה אופיינית:
| סטטוס ביטריקס | סטטוס UT |
|---|---|
| N (חדש) | NewOrder |
| P (שולם) | InWork |
| F (בוצע) | Completed |
| C (בוטל) | Cancelled |
מיפוי הפוך (מ-UT לביטריקס) — כאשר מנהל משנה את סטטוס ההזמנה ב-UT, האתר צריך לשקף את השינוי. זה מוגדר באופן דומה, בכיוון ההפוך. ללא מיפוי הפוך, הלקוח לא רואה את סטטוס ההזמנה בפועל בחשבון האישי שלו.
כיצד להגדיר יצירת גורמים ב-UT?
אדם פרטי מהאתר עובר ל-UT כ"יחיד" בספריית "גורמים". הזיהוי הוא לפי טלפון או אימייל (לא לפי שם מלא, שאינו ייחודי).
אנו ממליצים להוסיף שדה BITRIX_USER_ID (מזהה משתמש) למאפייני ההזמנה בביטריקס ולהעביר אותו ב-ДополнительныеРеквизиты של ההזמנה. UT שומר זאת כמזהה חיצוני של הגורם. בהזמנות חוזרות, הגורם נמצא לפי מזהה זה, ומונעים כפילויות.
// В обработчике выгрузки заказа добавляем ID пользователя $arOrderProps['BITRIX_USER_ID'] = $order->getUserId(); לגורמים משפטיים — חיפוש לפי ח.פ. ח.פ. חייב להיות שדה חובה בעת ביצוע הזמנה בחלק ה-B2B של האתר.
פריטי הזמנה: קישור לפריטי UT
כל פריט הזמנה ב-XML מכיל // В обработчике выгрузки заказа добавляем ID пользователя $arOrderProps['BITRIX_USER_ID'] = $order->getUserId(); — ה-XML_ID של רכיב בלוק המידע בביטריקס. XML_ID זה חייב להתאים ל-GUID של הפריט (או המאפיין) ב-UT. אם XML_ID אינו תואם, UT לא ימצא את הפריט וייצור "מוצר לא ידוע" או ידחה את ההזמנה. תרחישי שגיאה אופייניים:
- יצירה ידנית של מוצרים בביטריקס ללא סנכרון
- ייבוא פריטים ממקור אחר
- שחזור מסד נתונים של ביטריקס מגיבוי ישן
אבחון: לפני תחילת העברת הזמנות, בצע ייצוא ניסיון של הזמנה אחת ובדוק אם כל ערכי ИдТовара קיימים ב-UT. אנו מגדירים רישום שגיאות כך שתראה את סיבת הכשל.
משלוח ושירותי משלוח
שיטת המשלוח מהזמנת ביטריקס מועברת בשדה ИдТовара. ב-UT זה צריך להיות רכיב בספריית "שירותי משלוח". אם באתר יש מספר שירותים (שליח, דואר, CDEK, איסוף עצמי), יש ליצור ערכים תואמים ב-UT. ללא מיפוי, ההזמנה נוצרת ללא שירות משלוח, והמנהל מוסיף אותו ידנית.
כתובת משלוח מועברת ב-Доставка → СпособДоставки עם סוג "משלוח". UT שומר את הכתובת בכרטיס הגורם. אם לקונה יש מספר כתובות, כל הזמנה מעבירה את הכתובת הנוכחית.
מקרה מבחן: הלקוח שלנו — חנות עם הרכבה ידנית של הזמנות
הלקוח שלנו, מפיץ ציוד תעשייתי, נתקל בבעיה: כל ההזמנות מורכבות ידנית על ידי עובד מחסן מרשימה מודפסת, אך הזמנות מביטריקס לא הגיעו ל-UT בזמן. יישמנו שרשרת סטטוסים:
- הזמנה מהאתר → UT (סטטוס "חדש")
- מנהל ב-UT בודק זמינות → משנה ל"מאושר" → הסטטוס חוזר לביטריקס, הלקוח מקבל אימייל
- לאחר משלוח → "הושלם" → ביטריקס מעדכן את הסטטוס
מרווח סנכרון: הזמנות כל 3 דקות; סטטוסים חזרה כל 5 דקות. העיכוב בין פעולת המנהל להודעת הלקוח הוא לכל היותר 8 דקות. התוצאה: חיסכון של 30% בזמן למנהלים הודות לאוטומציה.
לפי תיעוד ביטריקס, סנכרון הזמנות מבוסס על תקן CommerceML 2.0 (dev.1c-bitrix.ru).
מה כלול בהגדרה במפתח מלא
- ביקורת תצורת הסנכרון הנוכחית
- הגדרת צומת סנכרון בביטריקס וב-1C:UT
- מיפוי סטטוסים (ישיר והפוך)
- הגדרת יצירת גורמים ופריטים
- בדיקת העברת מאפייני הזמנה (משלוח, תשלום, שדות נוספים)
- בדיקה על הזמנת ניסיון
- תיעוד על תכנית הסנכרון (PDF)
- גישה ליומנים ומעקב שגיאות
- שעת הדרכה אחת לצוות שלך באמצעות שיחת וידאו
- תמיכה לאחר ההגדרה למשך 30 יום
שגיאות נפוצות ופתרונותיהן
| בעיה | סיבה | פתרון |
|---|---|---|
| הזמנה לא נוצרת | אי-התאמה ב-XML_ID | בדוק את GUID של הפריט |
| גורמים כפולים | אין מזהה חיצוני | הוסף BITRIX_USER_ID |
| סטטוס לא מתעדכן | אין מיפוי הפוך | הגדר צומת סנכרון הפוך |
| כתובת לא מתקבלת | סוג "משלוח" לא מוגדר | תקן את מיפוי השדות |
לוח זמנים ואחריות
הגדרה בסיסית — מיום עבודה אחד עד יומיים. אם נדרשים שדות מותאמים אישית או שירותי משלוח לא סטנדרטיים, לוח הזמנים מתארך ל-3–5 ימים. אנו מבטיחים שלאחר ההגדרה, הזמנות יועברו ללא אובדן, וסטטוסים יסונכרנו בעיכוב של לא יותר מ-5 דקות. אנו מספקים תעודת גמר לעבודה שבוצעה.
אנו בשוק כבר 5+ שנים, השלמנו למעלה מ-500 אינטגרציות, ודירוג הפרויקטים הממוצע שלנו הוא 4.9/5. צור קשר לייעוץ והערכת לוח זמנים.