אתה מפעיל חנות מסחר אלקטרוני על 1C-Bitrix עם מאות וריאציות מוצר: ספות ב-20 צבעים, נעלי ספורט ב-10 מידות, מחשבים ניידים עם גדלים שונים של זיכרון. סכימת בלוק המידע הסטנדרטית לעתים קרובות מתעלמת מהמאפיינים הספציפיים של קטלוג רב-וריאציות, מה שמוביל לבעיות scaling. מסנן הפרמטרים חייב להציג רק את מה שיש במלאי, והחלפה עם 1C לא צריכה ליצור כפילויות.
אם תעשה טעות בעיצוב SKU בשלב זה, ההשלכות ישפיעו על הביצועים ועל דיוק המלאי. כל שאילתת מסד נתונים נוספת מפחיתה את מהירות התגובה, וקישור שגוי של הצעות יוצר כפילויות. אנו מתכננים הצעות מסחר (SKU) כך שהסינון יעבוד באופן מיידי והמלאי לא ישוכפל.
הניסיון שלנו כולל עשרות פרויקטים עם אלפי וריאציות מוצר. אנו יודעים כיצד להפריד כראוי בין מאפייני מוצר להצעות, להגדיר את האינדקס המפוצל ולארגן החלפה יציבה עם 1C. אנו נעריך את הפרויקט שלך turnkey תוך 3-8 ימים — פשוט צור קשר. קבל ייעוץ ואנו ננתח את מבנה הקטלוג שלך.
סכימת SKU טכנית ב-Bitrix
הצעת מסחר היא אלמנט של אינפובלוק ההצעות המקושר למוצר האב. במסד הנתונים:
b_iblock_element— מוצר (סוגTYPE_PRODUCT)b_iblock_element— הצעה (סוגTYPE_OFFER)b_catalog_product.OWNER_ID— קישורb_catalog_price— מחיר ברמת ההצעהb_catalog_store_amount— מלאי
המונח SKU (Stock Keeping Unit) משמש לזיהוי ייחודי של וריאנט. הגדרת קישור: תוכן → קטלוג → [אינפובלוק] → הצעות מסחר. הרכיב catalog.element מציג את כרטיס המוצר; עליו לבחור נכון את ההצעה הפעילה.
כיצד להפריד נכון בין מאפיינים של מוצר להצעת מחיר?
הכלל המרכזי: מאפיין שייך להצעת מחיר אם הערך שלו משנה את המחיר או את המלאי. לדוגמה:
- מאפייני מוצר: שם, תיאור, מותג, קטגוריה, תמונות בסיס.
- מאפייני הצעת מחיר: צבע, מידה, נפח, SKU, ברקוד, תמונת וריאנט.
טעות היא להכניס צבע למוצר: אז אי אפשר לסנן "שמלות כחולות מידה 42" כי המלאי קשור להצעת המחיר.
| סוג מאפיין | דוגמאות | משפיע על מחיר/מלאי |
|---|---|---|
| מוצר | מותג, קטגוריה, תיאור | לא |
| הצעת מחיר | צבע, מידה, SKU | כן |
מדוע סינון לפי מאפייני הצעות מאט?
הרכיב הסטנדרטי bitrix:catalog.smart.filter יכול לסנן לפי מאפייני הצעות, אך האינדקס הממודר נבנה בנפרד. אם למוצר יש 50+ הצעות, השאילתות עלולות להיות כבדות. סינון מותאם אישית עם ממודר תקין עובד פי 2–3 מהר יותר.
מקרה מורכב הוא סינון בו-זמני לפי מאפייני מוצר והצעות: הממודר הסטנדרטי אינו תומך בין-אינפובלוקים. יש צורך בשינוי הרכיב, למשל, מסנן מותאם אישית עם צבירה מקדימה.
עבור קטלוגים גדולים (מאות אלפי SKU), אנו משתמשים באינדקס ממודר עם צבירה מקדימה. זה נותן שיפור מהירות של 40% בהשוואה לפתרון הסטנדרטי. הניסיון שלנו מאשר: תכנון מסנן מו� competent משתלם תחת עומס. חיסכון בתקציב על תיקונים יכול להגיע עד 30%.
כיצד להימנע משכפול SKU במהלך החלפה עם 1C?
ב-CommerceML, הצעות מועברות ב-ЗначенияРеквизитов. קריטי: ה-XML-ID חייב להיות ייחודי ויציב. לפי התיעוד של 1C-Bitrix, אפילו שינוי חד-פעמי של המזהה מוביל לשכפול. יש לסכם על הפורמט עם צוות 1C לפני ההתחלה.
| בעיה | פתרון |
|---|---|
| מוצרים כפולים בהעלאה חוזרת | XML-ID יציב, ייחודי לכל מאפיין |
| מיפוי מאפיינים שגוי | לסכם סכימה עם 1C מראש |
| אובדן הקישור בין מוצר להצעה | הגדרה נכונה של מאפיין הקישור (CML2_LINK) |
מקרה בוחן: חנות ריהוט עם 14,000 מק"ט
הגדרנו קטלוג לחנות ריהוט מרופד: 1,200 דגמים, כל אחד ב-8–20 וריאציות בד — סה"כ 14,000 הצעות. לאחר ההגדרה הראשונית, מסנן הצבע הציג מוצרים שבהם הצבע היה במאפיין של מוצר האב, ולא של ההצעה. הספה "Marco" בצבע "בז'" הופיעה גם אם כל וריאציות הבז' אזלו. הפתרון:
- העברנו את הצבע והחומר לאינפובלוק של ההצעה.
- הגדרנו את האינדקס הפאסטי על אינפובלוק ההצעה.
- הוספנו בדיקה ברכיב המדור: מוצר מוצג רק אם קיימת הצעה עם מלאי > 0 והצבע הנדרש.
- תמונות הווריאציות במאפיין ההצעה, תמונות הדגם במוצר.
לאחר השינוי, הסינון עבד כראוי, ו"אזל מהמלאי" מוצג עבור וריאציות ספציפיות מבלי להסתיר את המוצר. חיסכון בזמן בעיבוד שאילתות — 40%. אנו מבטיחים שהקטלוג שלך יעבוד ללא תקלות. עלות הבעלות על הקטלוג מצטמצמת ב-20% הודות לארכיטקטורה נכונה.
מה כלול בעבודת עיצוב SKU
רשימה מלאה של שלבים
- ניתוח משתנות המוצר וזיהוי מאפייני ההצעה.
- עיצוב הפרדת מאפיינים: אילו תכונות הן מוצר ואילו הן הצעה.
- הגדרת קישור אינפובלוק ומאפיין מחייב.
- תכנון אינדקס פאסטים לסינון נכון.
- מיפוי שדות CommerceML להחלפה יציבה עם 1C.
- סכימה להצגת SKU בכרטיס המוצר.
- בדיקת כל תרחישי הסינון והתצוגה.
לצוות שלנו יש ניסיון בפיתוח 1C-Bitrix, עם השלמה של למעלה מ-30 פרויקטים עם הצעות מסחר. קבלו ייעוץ — צרו קשר לניתוח הפרויקט שלכם.