נתקלנו פעמים רבות במצבים שבהם לקוח משתמש ב-1C UNF ורוצה לסנכרן את הקטלוג וההזמנות עם אתר Bitrix. UNF היא הבחירה של עסקים קטנים שמנהלים CRM, מחסן ומכירות במקום אחד ללא המורכבות המיותרת של ERP. האינטגרציה עם Bitrix כאן עובדת אחרת מאשר עם UT או KA: ל-UNF אין מנגנון החלפת CommerceML מלא בסגנון הישן, אבל יש לה REST API ו-Bitrix Drive — המחבר הרשמי מ-1C. הגדרת ההחלפה דורשת הבנה של פרוטוקולים ושגיאות נפוצות: לדוגמה, וריאנטים של פריטים לא תמיד ממופים נכון ל-SKU, ו-CommerceML הסטנדרטי לא מעביר מספרים סידוריים. נסקור שני מסלולים ונראה כיצד להימנע מכפילויות והקפאות.
איך לבחור את שיטת ההחלפה?
מסלול 1: CommerceML (קלאסי). UNF תומכת בפרוטוקול ההחלפה הסטנדרטי דרך /bitrix/admin/1c_exchange.php. נומנקלטורה, מחירים, יתרות מלאי מיוצאים, והזמנות מיובאות. זה עובד, אבל עם מגבלות: אין מאפיינים מלאים, אין מספרים סידוריים, ומסמכי CRM לא מועברים. קראו עוד על הפרוטוקול בCommerceML.
מסלול 2: REST API + Webhooks. ל-UNF מגרסה 1.6 יש שירות HTTP מובנה. Bitrix יכול לשאול אותו או לקבל הודעות push על שינויים. המסלול הזה גמיש יותר אבל דורש פיתוח משני הצדדים.
לרוב המשימות (קטלוג + הזמנות), CommerceML מספיק. REST נדרש כשמעבירים אובייקטים לא סטנדרטיים: עסקאות CRM, משימות, מסמכים.
איך להגדיר CommerceML ב-UNF שלב אחר שלב
- עברו אל חברה → אינטגרציה → החלפה עם אתר.
- ציינו את כתובת האתר (לדוגמה,
https://example.com) ופרטי התחברות (שם משתמש/סיסמה להחלפת 1C). - בחרו קבוצות פריטים לייצוא — סמנו רק את אלה שצריכות להופיע באתר.
- הגדירו סוג מחיר (קמעונאי או סיטונאי) ובחרו מחסנים לייצוא מלאי.
- הגדירו מיפוי סטטוסי הזמנות: ב-UNF הסטטוסים הם "חדש", "בתהליך", "הושלם", "בוטל" — מפו אותם לשרשרת הסטטוסים של האתר שלכם.
- הריצו החלפת בדיקה ידנית דרך הכפתור "הרץ החלפה".
הזמנות מ-Bitrix ל-UNF
הזמנות נוצרות ב-UNF כ"הזמנת לקוח". הצד הנגדי נוצר אוטומטית מנתוני ההזמנה. עיבוד ההזמנה אורך בממוצע 2 שניות במהלך הסנכרון. "בעבר, הסטטוס התעדכן פעם ב-15 דקות; עכשיו לקוחות רואים שינויים באופן מיידי. זה הגדיל את הנאמנות." — לקוח, מרכז שירות.
נקודה קריטית: סטטוסים. ב-UNF, הזמנה עוברת סטטוסים: חדש → בתהליך → הושלם / בוטל. ב-Bitrix יש שרשרת סטטוסים משלו. המיפוי מוגדר בצומת ההחלפה. אם לא מוגדר, הזמנות ב-UNF יתקעו בסטטוס "חדש".
סנכרון סטטוס הפוך — כשמנהל משנה את סטטוס ההזמנה ב-UNF, השינוי הזה חייב להגיע ל-Bitrix. החלפה סטנדרטית תומכת בזה: בסשן ההחלפה הבא, סטטוס ההזמנה מתעדכן ב-Bitrix. אבל יש עיכוב השווה למרווח ההחלפה (בדרך כלל 5–15 דקות).
למה REST API מהיר יותר מ-CommerceML?
עם CommerceML, עיכוב הסנכרון הוא 5–15 דקות. לחברות שירות שבהן הלקוח ממתין לעדכוני סטטוס תיקון, זה קריטי. REST API עם webhooks נותן משוב מיידי — העיכוב יורד ל-1–2 שניות. מעל 90% מהלקוחות שלנו עם מודל שירות בוחרים ב-REST.
מקרה בוחן: מרכז שירות (מהפרקטיקה שלנו)
הלקוח שלנו — מרכז שירות לתיקון ציוד. הם משתמשים ב-UNF ל-CRM (פניות לקוחות, היסטוריית תיקונים), ובאתר יש טופס פנייה וחשבון אישי ללקוח.
משימה: פניית האתר חייבת להגיע ל-UNF כ"פנייה", והלקוח חייב לראות את סטטוס התיקון בחשבון האישי באתר.
פתרון: השתמשנו ב-REST API של UNF. כשהטופס נשלח באתר:
- Bitrix יוצר הזמנה במערכת שלו.
- סקריפט שולח בקשת POST לשירות ה-HTTP של UNF: יוצר פנייה.
- UNF מחזירה את מזהה הפנייה; Bitrix שומר אותו בשדה הזמנה מותאם אישית.
לסנכרון סטטוס הפוך — webhook מ-UNF: כשסטטוס הפנייה משתנה, נשלחת בקשת POST לנקודת קצה של Bitrix, שמעדכנת את סטטוס ההזמנה.
עיכוב סנכרון סטטוס: 0 (מיידי דרך hook) במקום 5 דקות עם שאילתות.
דוגמה להגדרת webhook
{ "event": "crm.invoice.status.update", "url": "https://site.bitrix24.ru/rest/1/токен/hook.php" } סקירת תהליך
| שלב | משך | תוצאה |
|---|---|---|
| ניתוח מבנה הנתונים הנוכחי | 1–2 ימים | סכמת התאמת נומנקלטורה והזמנות |
| הגדרת CommerceML או REST | 2–3 ימים | החלפה עובדת בסביבת בדיקה |
| בדיקות וניפוי שגיאות | 1–2 ימים | טיפול בשגיאות, מקרי כפילויות |
| תיעוד והדרכה | 0.5 יום | הוראות למפעילים |
פרויקט טיפוסי אורך 5 עד 7 ימים. העלות מחושבת באופן אישי, אבל החיסכון הממוצע בזמן סנכרון הוא עד 90%.
מה כלול בעבודה
- ניתוח מבנה נתונים וסכמת החלפה — 1–2 ימים
- הגדרת CommerceML או REST API — 2–3 ימים
- בדיקת תרחישים (הזמנות, נומנקלטורה, סטטוסים) — 1–2 ימים
- תיעוד למפעילים ומנהלים — 0.5 יום
- הדרכת עובדים (1–2 שעות) — כלול
- תמיכה לאחר השקה למשך שבועיים
מגבלות אינטגרציה של UNF
| פרמטר | UNF | UT 11 |
|---|---|---|
| מאפייני פריט | וריאנטים (מוגבל) | מאפיינים מלאים |
| מחסנים מרובים | כן | כן |
| ניהול סידורי | כן (בסיסי) | כן (נרחב) |
| REST API | כן | מוגבל |
| אובייקטי CRM בהחלפה | רק דרך REST | לא |
| מקסימום פריטי קטלוג | עד 20,000 | עד 100,000 |
| מהירות סנכרון | 5–15 דקות (CommerceML), 1–2 שניות (REST) | תלוי בנפח |
UNF מתאימה היטב לאינטגרציה אם הקטלוג קטן (עד 20,000 פריטים) וחסרים מאפיינים מורכבים. אם העסק גדל — תכננו מעבר ל-KA או UT ללא בנייה מחדש של האתר (שמרו על XML_ID של הנומנקלטורה).
שגיאות נפוצות ורשימת בדיקה
- מיפוי סטטוסים לא מוגדר — הזמנות נתקעות.
- חוסר התאמה ב-XML_ID של נומנקלטורה במהלך החלפה — כפילויות.
- כל קבוצות הפריטים הועלו, כולל קבוצות שירות — עומס על האתר.
- משתמשים במספרים סידוריים אבל CommerceML לא מעביר אותם — צריך REST.
סיכום
למהנדסים שלנו יש הסמכות 1C ו-Bitrix, ניסיון של למעלה מ-5 שנים, והם ביצעו יותר מ-50 פרויקטי אינטגרציה. אנחנו מבטיחים החלפה חלקה ללא אובדן נתונים. הזמינו הגדרה סוהר — לוח זמנים מ-5 ימים. צרו קשר לניתוח הפרויקט שלכם – קבלו ייעוץ מהנדס.