שילוב 1C-Bitrix עם Bitrix24 CRM
אנחנו רואים את זה מדי יום: חנות מקוונת על 1C-Bitrix מקבלת הזמנות בעוד שצוות המכירות עובד ב-Bitrix24 CRM. מנהלים מעבירים נתונים בין המערכות ידנית — מאבדים הזמנות, משכפלים אנשי קשר, ומפספסים היסטוריית לקוחות. הפתרון המוכן הוא REST API + webhooks בין שני מוצרים מאותו ספק, אבל הגדרה נכונה שלו מסובכת יותר ממה שזה נראה. הניסיון שלנו מראה: אוטומציה דרך REST API מקצרת את זמן העברת הנתונים הידנית פי 10 ומבטלת שגיאות. החיסכון בעבודה ידנית מגיע ל-80% — עבור חנות עם 500 הזמנות בחודש, זה שווה ערך ל-30 שעות עבודת מנהל. במאמר זה, נפרק היבטים טכניים מרכזיים: בחירת מתודות, מיפוי סטטוסים, טיפול בקונפליקטים, וקנה מידה דרך תור.
אילו מתודות REST API אתם צריכים?
Bitrix24 מספק REST API דרך OAuth 2.0 או webhooks נכנסים. 1C-Bitrix מתקשר דרך מודול bitrix24connector (אם מותקן) או ישירות דרך \Bitrix\Main\Web\HttpClient. מתודות מפתח:
| מתודת Bitrix24 | מטרה |
|---|---|
crm.lead.add |
יצירת ליד מטופס באתר |
crm.contact.add / crm.contact.update |
יצירה/עדכון איש קשר |
crm.deal.add / crm.deal.update |
יצירה/עדכון עסקה מהזמנה |
crm.deal.productrows.set |
צירוף פריטי מוצר לעסקה |
crm.company.add |
יצירת חברה (ל-B2B) |
crm.activity.add |
הוספת פעילות (שיחה, אימייל) |
איך להגדיר סנכרון דו-כיווני ללא קונפליקטים?
העברה חד-כיוונית (אתר → CRM) היא מהירה. בעיות מתעוררות בדו-כיווני: מנהל משנה סטטוס עסקה ב-Bitrix24 → האתר חייב לעדכן סטטוס הזמנה. במקביל, לקוח משנה הזמנה באתר → CRM חייב לעדכן עסקה.
מקרה בוחן. חנות מקוונת לחומרי בניין עם 200–300 הזמנות ביום. לאחר השקת סנכרון דו-כיווני, תוך 3 ימים מצאנו סטטוסי הזמנה "צפים" — הזמנה ששולמה באתר חזרה לסטטוס "חדש" מה-CRM. סיבה: ה-webhook מ-Bitrix24 הגיע לאחר אירוע האתר ודרס את הסטטוס ללא בדיקת עדיפות.
פתרון — שדה 'מקור אמת' (source_system) במיפוי סטטוסים:
// При получении вебхука из Б24 — проверяем метку времени $localOrder = CSaleOrder::GetByID($orderId); $localUpdated = strtotime($localOrder['DATE_UPDATE']); $b24Updated = strtotime($webhook['data']['FIELDS']['DATE_MODIFY']); if ($b24Updated > $localUpdated) { // Обновляем заказ на сайте CSaleOrder::StatusOrder($orderId, $newStatus); } למה מיפוי סטטוסים חשוב?
סטטוסי הזמנה ב-1C-Bitrix מאוחסנים ב-// При получении вебхука из Б24 — проверяем метку времени $localOrder = CSaleOrder::GetByID($orderId); $localUpdated = strtotime($localOrder['DATE_UPDATE']); $b24Updated = strtotime($webhook['data']['FIELDS']['DATE_MODIFY']); if ($b24Updated > $localUpdated) { // Обновляем заказ на сайте CSaleOrder::StatusOrder($orderId, $newStatus); } , סטטוסי עסקה ב-Bitrix24 הם שלבי pipeline (b_sale_status). המיפוי אינו אחד-לאחד: ל-Bitrix24 עשויים להיות 10 שלבים, לאתר 5 סטטוסים. אנחנו יוצרים טבלת מיפוי המאוחסנת בטבלה מותאמת אישית או בהגדרות מודול.
| סטטוס הזמנה (אתר) | שלב עסקה (Bitrix24) |
|---|---|
| N (חדש) | NEW |
| P (שולם) | WON |
| F (נמסר) | WON |
| C (בוטל) | LOSE |
| D (במשלוח) | EXECUTING |
אם יש לכם סטטוסים מותאמים אישית כמו "ממתין להרכבה" או "שמור", יש להוסיף אותם כשלבים נוספים ב-pipeline של Bitrix24. אנו משתמשים ב-crm.status.list ליצירת סטטוסים חדשים, ואז מקשרים אותם דרך המיפוי.
למה תור בקשות הוא קריטי?
ל-REST API של Bitrix24 יש מגבלת קצב: 2 בקשות בשנייה בתוכניות ענן. במהלך עליות בהזמנות, קריאות סינכרוניות ישירות פוגעות במגבלה. שימוש בתור מפחית שגיאות פי 5 בהשוואה לקריאות סינכרוניות. ארכיטקטורה נכונה:
- אירוע באתר (
crm.status.add) מכניס משימה לטבלת תור. - סוכן Bitrix מעבד את התור כל 30 שניות בקבוצות של 2 בקשות/שנייה.
- בשגיאה, הרשומה נשארת בתור עם מונה ניסיונות חוזרים מוגדל (מקסימום 5).
אנו גם משלבים ניטור: אם התור עולה על 1000 פריטים, מופעלת התראה, המאפשרת גילוי מוקדם של בעיות רשת או API.
איך מתבצע השילוב?
אנחנו מפרקים את זה לשלבים. ראשית, אנו מנתחים תהליכים עסקיים קיימים: אילו ישויות לסנכרן, אילו סטטוסים בשימוש, נפח נתונים. לאחר מכן אנו מתכננים את הארכיטקטורה — בוחרים מתודות REST API, מגדירים מיפוי שדות. אנו מיישמים מטפלי אירועים באתר ומגדירים webhooks ב-Bitrix24. לאחר מכן, אנו מגדירים תור ומנגנון ניסיונות חוזרים. בדיקות כוללות תרחישי קונפליקט, חריגות ממגבלת קצב, וכשלים. לבסוף, תיעוד והדרכה.
| שלב שילוב | מאמץ |
|---|---|
| הגדרת OAuth / webhooks | 2–4 שעות |
| מיפוי שדות וסטטוסים | 4–6 שעות |
| פיתוח מטפלי אירועים | 8–12 שעות |
| יישום תור וטיפול בשגיאות | 6–10 שעות |
| סנכרון סטטוסים דו-כיווני | 6–10 שעות |
| בדיקות וניפוי שגיאות | 8–12 שעות |
סנכרון קטלוג מוצרים
אם אתם משתמשים בקטלוג Bitrix24 (OnSaleOrderSaved), חשוב לסנכרן אותו עם קטלוג האתר. אחרת, לעסקאות יהיו פריטים "ידניים" ללא הפניות לנומנקלטורה. מתודת crm.product.* מקבלת מערך של פריטים עם crm.deal.productrows.set — מזהה המוצר בקטלוג Bitrix24.
אסטרטגיה: כאשר מוצר נוצר באתר דרך אירוע PRODUCT_ID, צור/עדכן אוטומטית את הרשומה ב-Bitrix24 באמצעות OnAfterIBlockElementAdd. XML_ID משמש כמזהה חיצוני למניעת כפילויות. זה מונע שכפול נומנקלטורה.
מה כלול ומתי זה משתלם
אנו מספקים חבילה מלאה: תיעוד מפורט על ארכיטקטורת השילוב, גישת REST API מוגדרת ו-webhooks, הדרכת מנהלים על ה-CRM המעודכן, ותמיכה של 30 יום לאחר ההשקה. כל העבודה מבוצעת על ידי מומחים מוסמכים עם למעלה מ-10 שנות ניסיון.
השילוב משתלם תוך 1–2 חודשים בזכות הפחתת עבודה ידנית. אנו נעריך את הפרויקט שלכם תוך שעתיים — צרו קשר לייעוץ. קבלו ייעוץ על הפרויקט שלכם כבר עכשיו.
למדו עוד על Bitrix24 REST API בתיעוד הרשמי.