מדריך מלא לשילוב 1C:AutoService ו-Bitrix
דמיינו חנות מקוונת לחלקי רכב עם 45,000 פריטים, שלכל אחד מהם מספר OEM, מקבילים (אנלוגים) והתאמה לרכבים. כל הנתונים האלה נמצאים ב-1C:AutoService—ובאתר צריך לא רק להציג אותם אלא גם לספק חיפוש וסינון מהירים. בהטמעה טיפוסית, CommerceML מעביר רק את השם וה-SKU—אבל עבור שירות רכב, מספר OEM, מקבילים והתאמה לרכבים הם קריטיים. אם לא מגדירים זאת נכון, הקונה לא ימצא את החלק הדרוש, וההחלפה תכביד על האתר למשך שעות.
נתקלנו במקרים כאלה עשרות פעמים, ובכל פעם צצו אותן בעיות: CommerceML הסטנדרטי לא מעביר את מבנה ההתאמה המורכב, ההחלפה "מקפיאה" את השרת, והמספרים המקבילים הולכים לאיבוד במהלך הייבוא. נעבור על איך להגדיר אינטגרציה כך שתהיה יציבה ומהירה, עם דוגמאות הגדרה ספציפיות ואופטימיזציות.
פנו אלינו לבדיקת תצורת 1C ו-Bitrix שלכם—נציע לכם את תכנית האינטגרציה האופטימלית.
איך להגדיר החלפה בין 1C:AutoService ל-1C-Bitrix?
פריטים ב-1C:AutoService
התצורה מאחסנת חלקי חילוף עם מאפיינים מורחבים:
- מספר יצרן (מספר OEM)
- מספרים מקבילים (אנלוגים מיצרנים אחרים)
- התאמה (יצרן, דגם, שנה, מנוע)
- מותג/יצרן
- דגל חדש/משומש
- תקופת אחריות
CommerceML הסטנדרטי מעביר רק שם ו-SKU. מספרי OEM, מספרים מקבילים והתאמה מועברים דרך ДополнительныеРеквизиты. ב-Bitrix, כל אחד מהמאפיינים האלה חייב להפוך למאפיין של בלוק מידע עם הסוג הנכון (מחרוזת, ערך מרובה עבור מספרים מקבילים, הפניה למילון עבור התאמה). לפי התיעוד הרשמי של CommerceML, ניתן להעביר מאפיינים אלה ללא מגבלות כמות, אך חשוב להגדיר נכון את מטפל הייבוא.
התאמה: החלק המורכב ביותר
התאמת חלק היא קשר רבים-לרבים: חלק אחד מתאים למספר רכבים, רכב אחד משתמש בחלקים רבים. ב-1C:AutoService, ההתאמה מאוחסנת ברישום מידע. ל-CommerceML אין דרך סטנדרטית להעביר מבנה זה. אנו שוקלים שתי גישות.
אפשרות 1: JSON במאפיין. ב-1C, אנו יוצרים מחרוזת JSON עם התאמה ומכניסים אותה ל-ДополнительныйРеквизит:
[ {"make":"Toyota","model":"Camry","year_from":2006,"year_to":2011,"engine":"2AZ-FE"}, {"make":"Toyota","model":"RAV4","year_from":2005,"year_to":2012,"engine":"2AZ-FE"} ] ב-Bitrix—מאפיין מסוג "טקסט" המאחסן JSON. סינון לפי התאמה נעשה באמצעות חיפוש טקסט מלא או טבלה נפרדת.
אפשרות 2: בלוק מידע נפרד להתאמה. אנו יוצרים בלוק מידע נפרד "התאמה" (יצרן/דגם/שנה/מנוע) ב-Bitrix ובלוק מידע "פריטים" עם מאפיין קישור מסוג "קישור לאלמנטים". זוהי הארכיטקטורה הנכונה לבחירת רכב מלאה, אך הסנכרון מ-1C מורכב יותר—נדרש מטפל ייבוא מותאם אישית.
הבחירה תלויה בהיקף. עבור קטלוג עד 100,000 פריטים עם בחירת רכב נדירה, JSON מספיק; עבור חנויות גדולות עם סינון פעיל, השתמשו בבלוק מידע נפרד.
למה ההחלפה עלולה להאט את האתר שלכם ואיך לתקן זאת
בהחלפת קטלוג מלאה של 45,000 פריטים, CommerceML הסטנדרטי יוצר קובץ XML ענק (עד 100 MB) שהשרת מעבד במשך עשרות דקות. במהלך הייבוא, מסד הנתונים ננעל והאתר "קופא". פתרונות: ייצוא רק של פריטים במלאי, העברת תמונות דרך FTP בנפרד מה-XML, שימוש בהחלפה מצטברת (דלתא)—העברת רק רשומות ששונו מאז הסנכרון האחרון.
| פרמטר | החלפה מלאה | החלפה מצטברת |
|---|---|---|
| נפח נתונים | כל הקטלוג | רק שינויים מאז הסנכרון האחרון |
| זמן ביצוע | 12–40 דקות | 1–3 דקות |
| עומס על השרת | גבוה (נעילת טבלאות) | מינימלי |
| תדירות | פעם ביום (בלילה) | כל 30 דקות |
ההחלפה המצטברת עובדת עד פי 6 מהר יותר מההחלפה המלאה עבור נפח נתונים דומה, ועומס השרת מופחת ב-80%.
איך להגדיר חיפוש לפי מספרים מקבילים?
מספרים מקבילים הם קודים של אותו חלק תחת מותגים שונים. קונה מחפש לפי מספר מקביל באתר—החלק חייב להימצא גם אם נמכר אנלוג מיצרן אחר. ב-Bitrix, מספרים מקבילים מאוחסנים כמאפיין מרובה של בלוק המידע. חיפוש לפיהם נעשה דרך רכיב [ {"make":"Toyota","model":"Camry","year_from":2006,"year_to":2011,"engine":"2AZ-FE"}, {"make":"Toyota","model":"RAV4","year_from":2005,"year_to":2012,"engine":"2AZ-FE"} ] או חיפוש מותאם אישית באמצעות bitrix:catalog.smart.filter עם מסנן מאפיינים.
בעת ייבוא מ-1C:AutoService, מספרים מקבילים מועברים דרך CIBlockElement::GetList עם ערכים מרובים:
<ЗначениеРеквизита> <Наименование>КроссНомер</Наименование> <Значение>BP-35</Значение> </ЗначениеРеквизита> <ЗначениеРеквизита> <Наименование>КроссНомер</Наименование> <Значение>ATE-603310</Значение> </ЗначениеРеквизита> מטפל הייבוא ב-Bitrix חייב לאסוף ערכים מרובים של מאפיין אחד למערך.
הזמנות עבודה: מאפייני שירות רכב
ב-1C:AutoService, בנוסף למכירת חלקים, מתנהלות "הזמנות תיקון"—מסמכים לביצוע שירותים. באתר, זה יכול להיות טופס הזמנת שירות או אבחון מקוון. העברת הזמנות מהאתר ל-1C:AutoService נעשית בדרך כלל לא דרך CommerceML אלא דרך בקשת REST לשירות ה-HTTP של 1C. ההזמנה נוצרת כ"פנייה" או "הזמנת תיקון" בסטטוס "חדש".
מקרה בוחן: חנות חלקים משומשים (מהניסיון שלנו)
חברת פירוק רכבים: 45,000 פריטים של חלקים משומשים, כל אחד עם תמונה, דירוג מצב (1-5), התאמה. החלפה מלאה עם 1C:AutoService ארכה 40 דקות ו"הקפיאה" את השרת.
אופטימיזציות:
- מסנן ייצוא: רק "במלאי" (כמות > 0)
- תמונות דרך FTP בנפרד מה-XML (XML ללא base64 הוא חצי מהגודל)
- התאמה מאוחסנת כ-JSON בשדה אחד (לא בלוק מידע נפרד)
- החלפה מצטברת כל 30 דקות: רק פריטים עם מלאי ששונה
תוצאה: החלפה מלאה—12 דקות (בלילה), מצטברת—2 דקות. האתר הפסיק להאט, החיפוש הפך למהיר.
טעויות נפוצות בהגדרת החלפה
- שימוש באותו קובץ XML גם להחלפה מלאה וגם למצטברת
- ללא מסנן לפי מלאי במהלך הייצוא
- העברת תמונות בתוך XML כ-base64 במקום דרך FTP או URL
- הגדרות הרשאות שגויות לתיקיות מטמון זמני של 1C
- שכחת הגדרת אינדקס על מאפיין
ДополнительныеРеквизиты—החיפוש מואט
מה כלול בעבודה
בהזמנת הגדרת ההחלפה, אתם מקבלים:
- בדיקת תצורת 1C:AutoService הנוכחית שלכם ומבנה הנתונים ב-Bitrix
- תכנון תכנית הייבוא (שדות, סוגי מאפיינים, קישור רכבים)
- פיתוח מטפל הייבוא (CommerceML + מאפיינים מותאמים אישית)
- הגדרת שירות REST להזמנות (אם נדרש)
- אופטימיזציית ביצועים (החלפה מצטברת, מסננים)
- בדיקות על נתונים חיים וניטור שגיאות
- תיעוד על תחזוקה ולוח זמנים להחלפה
הניסיון והאחריות שלנו
אנו משלבים 1C ו-Bitrix כבר למעלה מ-10 שנים, עם יותר מ-50 פרויקטים שהושלמו עבור שירותי רכב וחנויות חלקים. הלקוחות כוללים מפרקי רכב גדולים ורשתות תחנות שירות. כל העבודה נעשית בהתאם להמלצות הרשמיות של 1C-Bitrix ו-1C:Enterprise. כל אינטגרציה כוללת אחריות ל-6 חודשים.
קבלו ייעוץ—נעריך את הפרויקט שלכם ונציע את הפתרון האופטימלי. הזמינו את הגדרת ההחלפה עוד היום כדי להבטיח שהחנות המקוונת שלכם תפעל ללא תקלות.