תארו לעצמכם: יש לכם 1C:Comprehensive Automation עם שלושה מחסנים, שני אתרי Bitrix, מאות מוצרים עם מאפיינים, והחלפת CommerceML עובדת לסירוגין — הזמנות הולכות לאיבוד, המחירים באתר הקמעונאי לא תואמים לסיטונאי. נשמע מוכר? חברות בוחרות בתצורת CA כשהן גדלות מעבר לניהול סחר (UT) אבל לא מוכנות ל-ERP. היא כוללת CRM, ייצור, שכר — וייתכן שיהיה צורך בנתונים מכל תתי-המערכות באתר. עם זאת, מנגנון ייצוא CommerceML ב-CA יורש מ-UT ויש לו אותן מגבלות. במשך יותר מ-10 שנים אנו מגדירים החלפת 1C:Comprehensive Automation עם 1C-Bitrix, ויותר מ-200 פרויקטים מאשרים: סנכרון יציב אפשרי גם בתצורות מורכבות.
מה CA יכול לעשות מחוץ לקופסה ואיפה הוא נופל
ל-CA יש צומת החלפה מובנה עם האתר — כמעט זהה לצומת ב-UT 11. הוא מייצא: פריטים עם מאפיינים, מחירים (סוגים מרובים), יתרות מלאי לפי מחסן והזמנות לקוחות. הוא לא מייצא מחוץ לקופסה: נתוני CRM (לקוחות, עסקאות), הזמנות ייצור, מסמכי התחשבנות בפורמט נוח לאתר.
| ישות | מיוצא כברירת מחדל | דורש התאמה אישית |
|---|---|---|
| פריטים | כן | לא |
| מאפיינים | כן, למעט סוגי הפניה | כן, אם הסוג הוא 'Reference' |
| מחירים (סוגים מרובים) | כן | לא |
| מלאי לפי מחסן | כן | לא |
| הזמנות לקוחות | כן | מיפוי סטטוסים |
| לקוחות מ-CRM | לא | כן |
| הזמנות ייצור | לא | כן |
ייחודיות CA: התצורה מתעדכנת באופן קבוע, ועדכונים לפעמים משפיעים על מודול ההחלפה. אם התאמתם אישית את הייצוא בצד CA (הוספתם תגיות ל-XML), ההתאמות האלה עלולות להישבר לאחר עדכוני תצורה. תמיד יישמו שינויים בהרחבת תצורה, לא בתצורה עצמה. לפי תיעוד 1C, הרחבות נועדו להתאים אישית תצורות סטנדרטיות מבלי לשנות את התצורה עצמה.
למה הרחבת תצורה היא הדרך הבטוחה היחידה להתאמה אישית
שימוש בהרחבה אמין פי 100 מעריכה ישירה — שום התאמה אישית לא אובדת במהלך עדכונים. הפתרון הוא להשתמש בהרחבות תצורה (BSP 3.1+, 1C 8.3). כל השינויים בכללי ההחלפה, בספריות וברישומים מיושמים באובייקט 'Extension' נפרד. כשהתצורה הסטנדרטית מתעדכנת, ההרחבה נשארת ללא פגע. גישה זו הוכחה שוב ושוב — המקרה שלנו עם מפיץ עם שלושה מחסנים הראה: 4 עדכוני CA בשנה, שום התאמה אישית לא נפגעה. הגדרת החלפת 1C:Comprehensive Automation ו-1C-Bitrix דורשת הבנה של שתי המערכות, אבל עם הרחבה אתם מוגנים מהפתעות.
מידע נוסף על הגדרת מאפיינים
ב-CA, מאפייני פריטים מאוחסנים ברישום המידע `ЗначенияСвойствОбъектов`. במהלך הייצוא, הם מופיעים בקטע `Свойства` של ה-XML. Bitrix קורא אותם ויוצר מאפייני בלוק מידע. הבעיה נוצרת כשמאפיין ב-CA הוא מסוג הפניה. יש צורך ב-handler שבמהלך עיבוד ה-XML מחליף את ה-GUID בערך מחרוזתי. דוגמה ל-handler מובאת להלן.איך להימנע מאובדן התאמות אישיות במהלך עדכוני 1C
צרו הרחבת תצורה ב-1C. זה מבטיח שכל השינויים בכללי ההחלפה יישארו פעילים לאחר עדכוני תצורה סטנדרטיים. אנחנו תמיד משתמשים בהרחבות, ובמשך שנים של עבודה לא היה מקרה אחד שבו התאמה אישית נשברה במהלך עדכון.
מדריך הגדרת החלפה שלב אחר שלב
- צרו הרחבת תצורה ב-1C.
- הגדירו את צומת ההחלפה: כתובת האתר, שם משתמש/סיסמה, ארגון, סוג מחיר, מחסנים.
- הגדירו את מיפוי סוג המחיר בצד Bitrix.
- אם יש מאפיינים מסוג הפניה, הוסיפו את ה-handler
OnIBlockCMLImport2ElementAdd. - מפו את סטטוסי ההזמנות בשתי המערכות.
- הריצו החלפת מבחן ובדקו את כל הישויות.
הגדרת צומת ההחלפה ב-CA
נתיב: Администрирование → Обмен данными → Обмен с сайтом на 1С-Битрикс. צרו צומת חדש. פרמטרים נדרשים:
- כתובת האתר —
https://example.com/bitrix/admin/1c_exchange.php - שם משתמש/סיסמה — משתמש Bitrix עם זכויות החלפה (קבוצת 'Administrators' או תפקיד מותאם אישית)
- ארגון — איזה ארגון לייצא (אם יש כמה)
- סוג מחיר — קבוצת מחירים אחת או יותר
- מחסנים — בחרו מחסנים ספציפיים או 'הכל'
ניואנס מחירים: ב-CA אפשר להגדיר ייצוא של מספר סוגי מחירים בו-זמנית. בצד Bitrix, כל סוג מחיר הוא סוג מחיר נפרד בקטלוג המסחרי. המיפוי מוגדר ב-Настройки → Торговый каталог → Типы цен.
מאפייני פריטים: בעיה אופיינית
ב-90% מהמקרים, בעיות מאפיינים נפתרות על ידי הוספת handler. ב-CA, מאפייני פריטים מאוחסנים ברישום המידע ЗначенияСвойствОбъектов. במהלך הייצוא, הם מופיעים בקטע Свойства של ה-XML. Bitrix קורא אותם ויוצר מאפייני בלוק מידע.
הבעיה נוצרת כשמאפיין ב-CA הוא מסוג הפניה (לדוגמה, 'יצרן' → ספריית לקוחות). Bitrix מקבל את ה-GUID של הלקוח במקום השם שלו. יש צורך ב-handler שבמהלך עיבוד ה-XML מחליף את ה-GUID בערך מחרוזתי.
// Обработчик события обмена AddEventHandler('catalog', 'OnIBlockCMLImport2ElementAdd', 'fixReferenceProperties'); function fixReferenceProperties(&$arFields, &$arProps, $arXML) { // Если значение свойства — GUID (формат 8-4-4-4-12) foreach ($arProps as $propCode => &$propVal) { if (preg_match( '/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i', $propVal )) { // Ищем значение в таблице маппинга $propVal = getPropertyValueByGuid($propCode, $propVal); } } } איך להחליף הזמנות בין Bitrix ל-1C?
הזמנות מ-Bitrix ל-CA מועברות בפורמט CommerceML — הקטע // Обработчик события обмена AddEventHandler('catalog', 'OnIBlockCMLImport2ElementAdd', 'fixReferenceProperties'); function fixReferenceProperties(&$arFields, &$arProps, $arXML) { // Если значение свойства — GUID (формат 8-4-4-4-12) foreach ($arProps as $propCode => &$propVal) { if (preg_match( '/^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i', $propVal )) { // Ищем значение в таблице маппинга $propVal = getPropertyValueByGuid($propCode, $propVal); } } } . ב-CA, הן נוצרות כ'הזמנת לקוח' בקטע המתאים.
נקודה קריטית: סטטוסי הזמנות. ב-Bitrix, הסטטוס הוא קוד (לדוגמה, Документы, N, P). ב-CA, זהו enum (F, НовыйЗаказ, ВРаботе). יש להגדיר את המיפוי ידנית בצומת ההחלפה בשני הצדדים. בלי זה, הזמנות נוצרות ב-CA ללא סטטוס או עם סטטוס שגוי.
שדות הזמנה נוספים. אם לאתר יש שדות מותאמים אישית (לדוגמה, 'תאריך משלוח רצוי', 'הערה להזמנה'), הם מועברים דרך Выполнен ב-XML של ההזמנה. בצד CA, יש להוסיף תכונות מתאימות לאובייקט 'הזמנת לקוח' ולציין אותן בהגדרות צומת ההחלפה.
מקרה מהפרקטיקה שלנו: CA + ריבוי מחסנים + ריבוי אתרים
מפיץ מוצרי חשמל ביתיים: CA עם 3 מחסנים (מוסקבה, קאזאן, קרסנודר), שני אתרי Bitrix — קמעונאי וסיטונאי (מחירים שונים, מלאי שונה). המהנדס שלנו הגדיר שני צמתי החלפה ב-CA — אחד לכל אתר. כל צומת מוגדר עם סוג מחיר משלו וקבוצת מחסנים. החלפה מצטברת (רק שינויים) — כל 20 דקות. החלפה מלאה — בלילה.
מורכבות: שני האתרים על אותו שרת, תהליכי החלפת PHP חפפו בזמן וחסמו את קובץ הנעילה של Bitrix. נפתר על ידי הוספת עיכוב ב-cron: קמעונאי רץ ב-00:00, סיטונאי ב-00:15.
מה כלול בעבודת הגדרת ההחלפה
- ביקורת של צומת ההחלפה הנוכחי וזיהוי צווארי בקבוק
- יצירת הרחבת תצורה של 1C (התאמות אישיות שורדות עדכונים)
- הגדרת שדות וסוגי מחירים לפי הקטלוג שלכם
- יישום handlers לנתונים לא סטנדרטיים (מאפיינים מסוג הפניה, שדות הזמנה מותאמים אישית)
- אינטגרציה מרובת מחסנים וריבוי אתרים (אם נדרש)
- בדיקת החלפה במחזור מלא: ייצוא, ייבוא, סנכרון סטטוסים
- תיעוד והדרכת מנהלים
- אחריות ל-30 יום על תפקוד ההחלפה
ציפיות ללוח זמנים
| שלב | משך | הערה |
|---|---|---|
| ביקורת ועיצוב | יום אחד | ניתוח התצורה הנוכחית והדרישות |
| הגדרת צומת החלפה | 1–2 ימים | הגדרות בסיסיות והרחבה |
| פיתוח handler | 1–3 ימים | לנתונים לא סטנדרטיים |
| בדיקות וניפוי שגיאות | 1–2 ימים | אימות מחזור מלא |
| תיעוד והדרכה | 0.5 ימים | העברת ידע למנהל |
הגדרה בסיסית (פריטים + מחירים + מלאי + הזמנות) — 2–4 ימי עבודה. אם נדרשות ישויות לא סטנדרטיות (מאפיינים מסוג הפניה, ריבוי מחסנים, ריבוי אתרים) — 5–10 ימים כולל בדיקות. הגדרת החלפת 1C:Comprehensive Automation ו-1C-Bitrix היא השקעה שמחזירה את עצמה 80% מהר יותר מפיתוח מותאם אישית מאפס. קבלו ייעוץ על הגדרת החלפה — פשוט כתבו לנו. צרו קשר להערכת עלות ולוח זמנים.