ייצוא מאפיינים נוספים מ-1C ל-Bitrix: מדריך הגדרה מעשי

ייצוא מאפיינים נוספים מ-1C ל-Bitrix אינו רק העתקת שדות. דמיינו: למוצר ב-1C יש 50 מאפיינים, אבל רק תריסר מוצגים באתר. או שבמקום ערכים מופיעים GUID, פילטרים לא עובדים, וכרטיס המוצר ריק. לקוחות מתלוננים, ההמרה יורדת. אם אתם נתקלים במצב כזה, ייצוא המאפיינים הנוספים מ-1C מוגדר לא נכון — והגיע הזמן לתקן. לדוגמה, ספריית "פרטים נוספים" ב-1C:UT 11 נותרת לעיתים קרובות ללא ייצוא, ומאפיינים מסוג קישור עטופים ב-GUID. כתוצאה מכך, פילטרים חשובים הולכים לאיבוד באתר, דפי מוצר נראים לא שלמים, ומנהלים מבלים שעות במילוי נתונים ידני. הגדרנו עשרות אינטגרציות ופיתחנו מתודולוגיה שפותר את הבעיות הללו ביעילות, תוך חיסכון משמעותי בעלויות.

סוגי מאפיינים נוספים ב-1C

ב-1C:UT 11, מאפיינים חיים בשני מקומות:

• מאפייני אובייקט (ДополнительныеРеквизиты) — ישירות באלמנט הספרייה. מיוצאים בכל החלפה.
• פרטי אובייקט (ДополнительныеСведения) — ברישום מידע נפרד. דורשים הכללה נפרדת בהגדרות צומת ההחלפה.

סוגי ערכים: מחרוזת, מספר, תאריך, בוליאני, קישור לספרייה, ומחרוזת עם וריאנטים. סוג הקישור הוא כאב הראש העיקרי.

כיצד מאפיינים מועברים ב-CommerceML

בקובץ ה-XML, מאפיינים ממוקמים בתוך <Товар>:

<ЗначенияРеквизитов> <ЗначениеРеквизита> <Наименование>Мощность</Наименование> <Значение>2500</Значение> </ЗначениеРеквизита> <ЗначениеРеквизита> <Наименование>ЕдиницаМощности</Наименование> <Значение>Вт</Значение> </ЗначениеРеквизита> <ЗначениеРеквизита> <Наименование>ГарантийныйСрок</Наименование> <Значение>24</Значение> </ЗначениеРеквизита> </ЗначенияРеквизитов> 

Bitrix, במהלך הייבוא, יוצר מאפייני בלוק מידע עם אותם שמות וממלא אותם בערכים.

השוואת סוגי מאפיינים וייצוגם ב-Bitrix

בעיה: קודי מאפיינים אוטומטיים

בייבוא הראשון, Bitrix מקצה קודים כמו <ЗначенияРеквизитов> <ЗначениеРеквизита> <Наименование>Мощность</Наименование> <Значение>2500</Значение> </ЗначениеРеквизита> <ЗначениеРеквизита> <Наименование>ЕдиницаМощности</Наименование> <Значение>Вт</Значение> </ЗначениеРеквизита> <ЗначениеРеквизита> <Наименование>ГарантийныйСрок</Наименование> <Значение>24</Значение> </ЗначениеРеквизита> </ЗначенияРеквизитов> , CML2_ATTR_001. העבודה איתם בתבניות היא כואבת. פתרון: לפני הייבוא לייצור, בצעו בדיקה על עותק, ולאחר מכן שנו ידנית קודים לשמות קריאים (CML2_ATTR_002, POWER_WATT). ייבואים עתידיים לא ישנו אותם כי Bitrix מתאים לפי שם.

או — כתבו handler על WARRANTY_MONTHS:

AddEventHandler('iblock', 'OnIBlockPropertyAdd', 'setReadablePropertyCode'); function setReadablePropertyCode(&$arFields) { if (empty($arFields['CODE'])) { $arFields['CODE'] = CUtil::translit( $arFields['NAME'], 'ru', ['change_case' => 'U', 'replace_space' => '_'] ); } } 

איך לפתור את בעיית ה-GUID? שתי גישות

מאפיינים מסוג קישור ב-XML מגיעים כ-GUID:

<ЗначениеРеквизита> <Наименование>Производитель</Наименование> <Значение>f3a2b1c0-1234-5678-abcd-ef0123456789</Значение> </ЗначениеРеквизита> 

באתר, כרטיס המוצר מציג ג'יבריש. אפשרויות:

1. בצד 1C: לפני הייצוא, החליפו את ה-GUID בשם אלמנט הספרייה. זה עדיף — זה לא מכביד על Bitrix בלוגיקה נוספת.
2. בצד Bitrix: תחזקו טבלת מיפוי "GUID → ערך" שנבנית מההחלפה הראשונית, והחליפו את הערך בעת כתיבת המאפיין.

החלפה בצד 1C לא מעמיסה על Bitrix אבל דורשת גישה לקונפיגורציה. מיפוי בצד Bitrix מהיר יותר להגדרה (2–3 שעות) אבל מסוכן יותר כשספריות מתעדכנות.

מה לעשות עם ערכים מרובים?

אם מאפיין ב-1C מאפשר ערכים מרובים, ה-XML מעביר אותם כתגיות חוזרות עם אותו שם. המאפיין ב-Bitrix חייב להיות "מרובה". ה-handler אוסף את כל הערכים למערך:

$multiValues = []; foreach ($arXML['ADDITIONAL_REQUISITES'] as $req) { if ($req['NAME'] === 'Применяемость') { $multiValues[] = $req['VALUE']; } } $arProps['APPLICABILITY'] = $multiValues; 

מדריך הגדרה שלב אחר שלב

1. ייצאו XML לבדיקה מ-1C — ודאו שכל סוגי המאפיינים כלולים.
2. נתחו מאפיינים — זהו סוגי קישור, מרובים, ומחרוזת עם וריאנטים.
3. בחרו גישה — החליטו היכן לטפל ב-GUID: ב-1C או ב-Bitrix.
4. כתבו handler — שנו את מודול ההחלפה או צרו event handlers.
5. בדקו על עותק — ודאו סוגים, פילטרים, וכרטיסי מוצר.
6. פרסו והכשירו — העבירו הגדרות לייצור, הגדירו החלפה מצטברת.

מקרה בוחן: קטלוג תעשייתי עם 60+ מאפיינים

מהניסיון שלנו: יצרן ציוד משאבות. כל מוצר מתואר על ידי 60–80 פרמטרים (לחץ עבודה, טווח טמפרטורות, חומר גוף, דרגת הגנה). ב-1C — מאפיינים נוספים. בייבוא הראשון, Bitrix יצר 78 מאפיינים עם קודים לא קריאים. בילינו יום בשינוי קודים והגדרת סוגים: מספרי כ"מספר" עם יחידות מידה; מחרוזת כ"רשימה" לסינון.

לאחר ההגדרה, רכיב הפילטר החכם של Bitrix מציע אוטומטית סינון לפי לחץ, טמפרטורה, וחומר — ללא פיתוח נוסף. עדכוני מאפיינים מצטברים (כשערכים משתנים ב-1C) לוקחים 4 דקות לכל הקטלוג של 2,300 פריטים. חיסכון בזמן תחזוקה ידנית — עד 20 שעות בחודש, שבתעריף מפעיל ממוצע של 500 RUB לשעה נותן חיסכון של 10,000 RUB חודשי, ובשנה 120,000 RUB. זה יעיל פי 1.5 מהזנת נתונים ידנית.

מה כלול בעבודה

• ניתוח — ייצוא XML לבדיקה, זיהוי כל סוגי המאפיינים והקשרים.
• עיצוב — בחירת תוכנית עיבוד (צד 1C או Bitrix), הגדרת מאפיינים מרובים.
• יישום — שינוי מודול החלפה / כתיבת handlers, שינוי קודים.
• בדיקות — אימות על עותק קטלוג, השוואה עם 1C, בדיקת פילטרים וכרטיסי מוצר.
• פריסה — העברת הגדרות לייצור, הכשרת מפעילים.
• תיעוד — מתן הוראות מפורטות וקבצי הגדרה.
• תמיכה — 30 ימי תמיכה לאחר פריסה ותיקוני באגים.

לוח זמנים: 3 עד 7 ימי עבודה תלוי במספר המאפיינים ומורכבות שדות הקישור. עלות מחושבת באופן אישי — פרויקטים טיפוסיים מתחילים ב-80,000 RUB. בקשו הערכת מחיר מהמהנדסים שלנו.

הניסיון והערבויות שלנו

• 8+ שנות ניסיון באינטגרציה של 1C ו-Bitrix.
• מעל 120 פרויקטי החלפת נתונים שהושלמו.
• אנחנו מספקים תיעוד על הגדרות ומבטיחים את העבודה שלנו.

רוצים את אותו הדבר? קבלו ייעוץ לפרויקט שלכם — ננתח את הקונפיגורציה שלכם ונציע פתרון. צרו קשר — נתחיל בניתוח ההגדרה שלכם.

לפי CommerceML, מבנה ה-XML חייב להכיל את כל המאפיינים הדרושים להעברת נתונים נכונה.