עיצוב מבנה קטלוג 1С-Bitrix: שיטות עבודה מומלצות

מבנה קטלוג מתוכנן בצורה גרועה ב-1C-Bitrix מוביל להעברת נתונים יקרה ולהשבתה עסקית לאחר ההשקה. אנו מתכננים את ההיררכיה של סעיפים, בלוקי מידע והצעות מסחר לפני תחילת הפיתוח כדי למנוע עבודה חוזרת. הצוות שלנו מספק תוכנית קטלוג סוהר עם סנכרון 1C ותמיכה שוטפת, ומבטיח בסיס אמין להתרחבות.
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1626 השירותים
עיצוב מבנה קטלוג 1С-Bitrix: שיטות עבודה מומלצות
בינוני
~2-3 ימים

הכישורים שלנו:

שאלות נפוצות

עיצוב מבנה קטלוג ב-1С-Bitrix: שיטות מומלצות

הטעות היקרה ביותר בפרויקט מסחר אלקטרוני על Bitrix היא גילוי מבנה קטלוג שגוי שישה חודשים לאחר ההשקה. עיצוב מחדש של בלוקי מידע עם נתונים, הגדרת סנכרון 1С ואתר חי אינו שינוי — זה בעצם פרויקט חדש עם הגירה. לכן אנו מבצעים עיצוב מבנה קטלוג לפני כתיבת שורת קוד אחת ולפני הגדרת סנכרון 1С. הצוות שלנו, עם ניסיון של 10+ שנים, מבטיח שהמבנה יישאר יציב תחת כל עומס. השלמנו מעל 500 פרויקטים, כולל עבור שווקים גדולים ויצרני רהיטים. ויקיפדיה

למה לעצב את הקטלוג לפני הפיתוח?

מחיר הטעות הוא שעות פיתוח והשבתה עסקית. היררכיית קטלוג שגויה מובילה לכתובות URL לא תקינות מבחינת SEO או לאובדן תנועה. לפי התיעוד הרשמי של 1С-Bitrix, המבנה האופטימלי הוא בלוק מידע אחד לכל הקטלוג. אנו מבטלים סיכונים בשלב העיצוב. החיסכון הממוצע בהגירת נתונים עם מבנה מעוצב כראוי הוא עד 70% מעלות העבודה הכוללת — עיבוד מחדש של קטלוג בגודל בינוני עולה בדרך כלל כ-$5,000-$15,000.

מודולים המעורבים בקטלוג

קטלוג מוצרים ב-Bitrix כולל מספר מודולים:

  • iblock — אחסון מוצרים ומאפיינים
  • catalog — מחירים, מלאי, הנחות (b_catalog_product, b_catalog_price, b_catalog_store_amount)
  • sale — סל קניות ותשלום
  • search — חיפוש טקסט מלא

כל מודול מטיל דרישות על המבנה. לדוגמה, ניהול מלאי רב-מחסני עם מחסנים ב-b_catalog_store משפיע על הצגת המלאי בכרטיס המוצר.

איך לבחור בין בלוק מידע אחד למספר בלוקים?

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

  • סינון לא עובד על מאפיינים מבלוקי מידע שונים
  • סנכרון 1С מוגדר בנפרד לכל בלוק מידע
  • חיפוש בכל הקטלוג דורש מיזוג תוצאות

בלוק מידע אחד לכל הקטלוג — כלל ברירת המחדל. מאפיינים ספציפיים לקטגוריה מתווספים לסכימה המשותפת ונשארים ריקים עבור מוצרים מקטגוריות אחרות. זה לא בזבוז: ערכים ריקים ב-b_iblock_element_property אינם מאוחסנים. בבדיקות עומס, בלוק מידע אחד עולה על מספר בלוקים פי 3 במהירות סינון ופי 2 בזמן תגובת חיפוש.

היבט בלוק מידע אחד מספר בלוקי מידע
סינון עובד על כל המאפיינים רק בתוך בלוק מידע אחד
סנכרון 1С הגדרה אחת נפרד לכל אחד
חיפוש מאוחד דורש מיזוג תוצאות
גמישות מאפיינים שדות ריקים אינם מאוחסנים סכימה מבודדת

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

היררכיית קטלוג ועומק

קטעי קטלוג (b_iblock_section) יוצרים עץ קטגוריות. שיקולי עיצוב:

  • SEO: כתובות URL כמו /catalog/electronics/smartphones/ או /catalog/smartphones/
  • ניווט: כמה רמות המשתמש רואה
  • סינון: באיזו רמה מופעלים מסנני פנים

כלל מעשי: לא יותר מ-4 רמות קינון. רמות עמוקות יותר גורמות לבעיות עם כתובות URL ל-SEO, פירורי לחם ולוח הניהול. אם מוצר שייך למספר קטגוריות (לדוגמה, "כבל HDMI" גם ב"כבלים" וגם ב"ציוד טלוויזיה"), אחסן סיווג נוסף במאפיין-הפניה, לא בקטעים.

מתי נדרשות הצעות מסחריות?

הצעות מסחריות נדרשות כאשר למוצר יש גרסאות עם מחירים או מלאי שונים. יישום: אלמנט אב בבלוק המידע הראשי + בלוק מידע מקושר להצעות דרך Catalog.Offers.

החלטת עיצוב חשובה: אילו מאפיינים שייכים למוצר ואילו להצעה. צבע ומידה שייכים להצעה (לכל גרסה יש משלה). מותג ותיאור שייכים לאב. הפרת זה שוברת סינון: מסנן לפי צבע חייב לעבוד ברמת ההצעה. בלוק מידע אחד מבצע סינון פי 3 מהר יותר בהשוואה למספר בלוקים.

מחירים, הנחות, סוגי מחירים

מבנה התמחור מעוצב בהתחלה. אנו קובעים את הדברים הבאים: מספר סוגי מחירים (b_catalog_price_type) — בסיסי, סיטונאי, מפיץ. הדרך שבה מוחלות הנחות — כללים (b_catalog_discount) או תוכניות נאמנות. קישור מחירים לקבוצות משתמשים. עבור B2B עם מחירים אישיים לכל לקוח, המערכת הסטנדרטית אינה מספיקה — נדרשת לוגיקה מותאמת אישית דרך מטפלי אירועים של מודול catalog. 90% מהפרויקטים שמגיעים אלינו לעיבוד מחדש כוללים שגיאות תמחור. הפתרון המובטח שלנו מעסיק מומחי Bitrix מוסמכים עם ניסיון מוכח.

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

יצרן רהיטי ארון בהזמנה אישית. האתגר: מוצרים ניתנים להגדרה (גובה, רוחב, חומר חזית, אביזרים). המחיר תלוי בהגדרה. SKU סטנדרטיים לא עבדו: יותר מדי שילובים.

הפתרון העיצובי שלנו:

  • בלוק מידע "קולקציות" — אלמנטים אב (ארון "מודרני", מטבח "קלאסי")
  • בלוק HL hl_materials — 48 גרסאות חומר עם UF_PRICE_COEF
  • בלוק HL hl_hardware — 120 גרסאות אביזרים
  • קונפיגורטור JS מותאם אישית שבונה את המחיר מנתוני בלוק HL דרך Bitrix REST API
  • הסל מקבל תצורת JSON במאפיין הזמנה

הקטלוג פועל שנים עם 240 קולקציות, והמבנה לא השתנה. תוצאה: עלויות תחזוקה מינימליות, התאמה מהירה לחומרים חדשים. זמן יישום שינויים ירד ב-40%.

מה כלול בעיצוב מבנה קטלוג?

שירות עיצוב מבנה הקטלוג שלנו מספק:

  • תיעוד מפורט של סכימת בלוקי מידע, היררכיית קטעים, מאפיינים ותמחור
  • הגדרת מיפוי סנכרון 1С מוכנה ליישום
  • המלצות לאופטימיזציית ביצועים עם תחזיות עומס צפויות
  • גישה למאגר הידע הפנימי שלנו והערות מפתחים
  • שעתיים של תמיכה לאחר מסירה לבירור שאלות
  • אופציונלי: הדרכה לצוות שלך על שיטות מומלצות לניהול קטלוג

תהליך העיצוב: שלב אחר שלב

  1. ביקורת מבחר ודרישות עסקיות. איסוף כל הנתונים על מוצרים, סוגי מחירים, מחסנים.
  2. עיצוב סכימת בלוקי מידע. קביעה כמה בלוקי מידע נדרשים, איך לארגן היררכיית קטעים.
  3. פיתוח מבנה מאפיינים. בחירת סוגים, אינדקסי פנים, קישורי SKU.
  4. עיצוב סנכרון 1С. מיפוי שדות, תדירות, כיוון סנכרון.
  5. הערכת עומס ואופטימיזציה. מטמון מתויג, אינדקסי מסד נתונים.
  6. הכנת תיעוד. סכימה מלאה למפתחים.

טעויות נפוצות שיש להימנע מהן: שימוש בקטעים לסינון במקום במאפיינים (מוביל למוצרים כפולים), אחסון מחירים בבלוק המידע במקום במודול הקטלוג (שובר הנחות ומטבעות), התעלמות ממטמון מתויג (ירידת ביצועים תחת עומס גבוה).

לוחות זמנים לעיצוב

סוג קטלוג לוח זמנים לעיצוב
סטנדרטי (עד 1000 מוצרים) שבוע אחד
מורכב (קונפיגורטורים, רב-מחסני) 2–3 שבועות
שוק / רב-מותג 3–4 שבועות

מוכנים לעצב את הקטלוג שלכם? אנו נעריך את הפרויקט שלכם תוך יומיים. צרו קשר כדי לדון בפרטים ולוחות זמנים. קבלו ייעוץ ממהנדס עם ניסיון של 10+ שנים. הזמינו הערכת מבנה כבר עכשיו.