אתר קטלוג 1C-Bitrix ללא עגלת קניות

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

מנקודת המבט של Bitrix, מדובר בארכיטקטורה שונה מהותית. לא "חנות מקוונת פחות עגלה", אלא מחלקת פרויקטים נפרדת עם פתרונות משלה בכל רמה — מהרישיון ועד מבנה בלוק המידע.

רישיון: 'Start' לעומת 'Standard'

השאלה הראשונה שמשפיעה על התקציב. מהדורת 'Start' אינה כוללת את המודולים sale ו-catalog. כלומר: אין SKU, אין סוגי מחירים, אין עגלה, אין הזמנות. עבור קטלוג ללא עגלה, זה בדיוק מה שצריך. מהדורת 'Standard' כוללת את catalog, אך מאפשרת שימוש סלקטיבי: הפעלת מאפייני קטלוג מסחרי עבור בלוק מידע מבלי לחבר את sale. זה מספק SKU ומחירים מרובים ללא עגלה.

חיסכון ברישיון: מהדורת 'Start' מתחילה ב-5,400 RUB, 'Standard' מ-35,000 RUB. עבור קטלוג עד 5,000 פריטים, בחירה ב-'Start' יכולה לחסוך עד 50% מתקציב הרישיון.

הבחירה תלויה בתרחיש:

ב-'Start', הקטלוג בנוי כולו על מודול iblock. מוצר הוא אלמנט בלוק מידע, קטגוריה היא סקציה. מאפייני בלוק מידע הם מאפייני מוצר. זה הכל. ללא עטיפות מסחריות.

מבנה בלוק מידע ללא SKU

קטלוג ללא SKU

בלוק מידע אחד — קטלוג אחד. אין קישור 'מוצר → SKU' דרך PROPERTY_CML2_LINK. אין טבלת b_catalog_product. אין b_catalog_price.

מבנה אופייני לקטלוג ציוד תעשייתי: בלוק מידע 'קטלוג ציוד' (סוג catalog, קוד API equipment):

• סקציות — קטגוריות (משאבות → צנטריפוגליות → אופקיות)
• אלמנטים — פריטי מוצר
• מאפיינים:
  • MANUFACTURER (מילון, מקושר ל-Highload-block) — יצרן
  • ARTICLE (מחרוזת, ממוקדת) — מספר קטלוגי
  • POWER (מספר) — הספק, קילוואט
  • WEIGHT (מספר) — משקל, ק"ג
  • MATERIAL (רשימה) — חומר גוף
  • DOCS (קובץ, מרובה) — תיעוד PDF
  • GALLERY (קובץ, מרובה) — תמונות
  • PRICE_ON_REQUEST (תיבת סימון) — מחיר לפי בקשה
  • IN_STOCK (רשימה: 'במלאי', 'בהזמנה', 'הופסק')

  ספריות נשמרות ב-Highload-blocks. יצרנים, יחידות מידה, מדינות. HLBlock עבור 'יצרנים' — טבלת b_hlbd_manufacturers עם שדות UF_NAME, UF_LOGO, UF_COUNTRY, UF_WEBSITE. קישור מבלוק המידע דרך מאפיין מסוג 'ספרייה'.

  נקודה מרכזית: ללא SKU אין מכפיל טבלת b_iblock_element_property. אם למוצר יש 15 מאפיינים ואין SKU — אלה 15 שורות ב-EAV לכל אלמנט. עם SKU של 5 וריאציות — 75 שורות. עבור 10K פריטים, ההבדל בין 150K ל-750K שורות מורגש במהלך סינון.

  סינון: catalog.smart.filter ללא מודול catalog

  רכיב bitrix:catalog.smart.filter עובד עם בלוקי מידע גם ללא מודול catalog. אבל יש ניואנס: אינדקסי פנים (b_catalog_sm_*) זמינים רק כאשר מודול catalog מחובר. ב-'Start', אין פנים.

  ללא פנים, סינון נעשה באמצעות שאילתות ישירות ל-b_iblock_element_property. עבור קטלוג עד 10-15K פריטים עם 10 מאפיינים ניתנים לסינון, זה מקובל: 100-300ms. עבור 50K+, זה כואב: 2-5 שניות.

  חלופות לסינון ללא פנים:

  1. פילטר מותאם אישית על D7 ORM — Bitrix\Iblock\Elements\ElementXxxTable (כאשר Xxx הוא קוד ה-API של בלוק המידע). נוצר אוטומטית, מאפשר בניית שאילתות דרך ::getList() עם filter, select, runtime. יתרון: שליטה מלאה ב-SQL, יכולת הוספת מטמון לתוצאות סינון.
  2. Elasticsearch / Sphinx — עבור קטלוגים מ-50K פריטים. אינדוקס באמצעות סוכן או מטפל באירועים OnAfterIBlockElementUpdate. סינון: 5-20ms בכל נפח. חיסרון: תשתית נוספת.
  3. פילטר על Highload-block — אם הקטלוג מועבר ל-HLBlock, סינון משתמש בטבלה שטוחה עם אינדקסים. מהיר, אבל מאבד רכיבי SEO סטנדרטיים של בלוקי מידע.

  המלצה לרוב הפרויקטים: catalog.smart.filter סטנדרטי + אינדקסים נכונים במסד הנתונים. מותאם אישית רק כאשר הנתונים מוכיחים צורך.

  CIBlockElement::GetList לעומת D7 ORM

  API ישן: CIBlockElement::GetList($arOrder, $arFilter, $arGroupBy, $arNavStartParams, $arSelectFields). עובד, מתועד, אלפי דוגמאות. בעיה: אין טיפוסיות קפדנית, אין השלמה אוטומטית ב-IDE, פילטרים דרך מוסכמות מערכים (">=PROPERTY_POWER" => 100).

  API D7: \Bitrix\Iblock\Elements\ElementEquipmentTable::getList([...]). טיפוסים קפדניים, ממשק זורם, שדות runtime, registerRuntimeField() עבור עמודות מחושבות. IDE מבין את המבנה, רפקטורינג בטוח.

  כלל מעשי: קוד חדש על D7, קוד קיים — אל תשכתבו לשם השכתוב. CIBlockElement::GetList לא ייעלם, Bitrix תומכת בתאימות לאחור במשך עשורים. אבל אם אתם בונים פילטר או אגרגציה מאפס, D7 נותן SQL צפוי ויכולת לפרופיל כל שאילתה דרך \Bitrix\Main\Diag\SqlTracker. D7 ORM מייצר SQL צפוי, בדרך כלל מניב שיפור ביצועים של פי 2-3 לעומת iblock בפילטרים מורכבים.

  SEO לקטלוג על בלוקי מידע

  למודול {=this.Name} יש תבניות SEO מובנות. מוגדרות ברמת בלוק המידע: לשונית 'SEO' → תבניות לסקציות ואלמנטים. משתנים:

  • {=this.PreviewText} — שם אלמנט/סקציה
  • {=this.property.MANUFACTURER} — טקסט תצוגה מקדימה
  • {=parent.Name} — ערך מאפיין
  • <title> — שם סקציית אב

  תבנית {=this.Name} — купить {=parent.Name} от {=this.property.MANUFACTURER} למוצר: catalog.section. עבור קטלוג ללא עגלה, החליפו 'קנייה' ב'מאפיינים ומחיר' או 'הזמנה'.

  כתובות URL ידידותיות ל-SEO מוגדרות דרך תבנית URL בפרמטרי רכיב catalog.element / /catalog/#SECTION_CODE#/:

  • סקציה: /catalog/#SECTION_CODE#/#ELEMENT_CODE#/
  • אלמנט: SECTION_CODE

  ELEMENT_CODE ו-Product נוצרים אוטומטית משמות (תעתיק) כאשר אפשרות בלוק המידע 'תעתיק קוד תווים בעת הוספת אלמנט' מופעלת.

  מיקרודאטה — Schema.org Offer ללא name (ללא מחיר לרכישה). ציינו description, image, brand, sku, offers (מספר קטלוגי). עבור 'מחיר לפי בקשה' — השמיטו priceSpecification או השתמשו ב-priceCurrency עם price ללא bitrix:catalog.compare.list. Google מבינה, Yandex מקבל דרך Webmaster.

  השוואת מוצרים ללא מודול catalog

  ההשוואה הסטנדרטית ב-Bitrix ($_SESSION['COMPARE_LIST'][IBLOCK_ID]) תלויה במודול CIBlockElement::GetList. ב-'Start', זה לא עובד. פתרון: רכיב השוואה מותאם אישית.

  אחסון: מערך של מזהי מוצרים נבחרים ב-/rest/iblock.element.get או בעוגיות (למשתמשים לא מחוברים). פלט: webform לפי מערך מזהים עם בחירת כל המאפיינים, מוצג כטבלה 'מאפיין — ערך לכל מוצר'. יישום: 8-12 שעות פיתוח, כולל JS להוספה/הסרה ללא טעינת עמוד מחדש.

  בחזית React (גישת headless/SPA) — השוואה נשמרת ב-state או ב-localStorage, נתונים נשלפים דרך REST API ELEMENT_ID או בקר מותאם אישית.

  'בקשת מחיר' במקום 'קנייה'

  דפוס UX מרכזי של קטלוג ללא עגלה. יישום דרך מודול טפסי אינטרנט או מטפל מותאם אישית.

  הטופס מקושר לאלמנט הקטלוג: שדות נסתרים מעבירים ELEMENT_NAME ו-sale. המנהל מקבל דוא"ל: 'בקשת מחיר עבור [שם מוצר], מספר קטלוגי [XXX], מאת [שם, טלפון, דוא"ל]'. נתונים נשמרים בבלוק מידע של פניות או ב-Highload-block — כדי לעקוב אחר המרות.

  וריאציות של כפתור CTA לפי תעשייה:

  • ציוד: 'בקש הצעה מסחרית'
  • נדל"ן: 'קבע צפייה'
  • חלקי חילוף: 'בדוק זמינות ומחיר'
  • ריהוט מותאם אישית: 'חשב עלות'

  חילופי 1C ללא מודול catalog

  מודול /bitrix/admin/1c_exchange.php תומך בחילופים דרך CommerceML (CAgent). ב-'Start', זה לא זמין. חלופה: ייבוא מותאם אישית דרך CSV/XML או REST API.

  עבור קטלוג ללא עגלה, חילופים הם בדרך כלל חד-כיווניים: 1C → אתר. נומנקלטורה, יתרות מלאי, מאפיינים. מיושם דרך:

  • סוכן (HTTPСоединение) בלוח זמנים, מנתח ייצוא XML מ-1C
  • משימת Cron הקוראת לסקריפט ייבוא דרך CLI
  • REST API, אם 1C יכול לשלוח בקשות HTTP (דרך עיבוד catalog)

  בשימוש ב-'Standard' עם מודול sale — חילופי CommerceML סטנדרטיים עובדים במלואם; מודול sale פשוט לא מחובר.

  למה לא צריך עגלה לקטלוג B2B?

  במכירות B2B, עסקה דורשת לעתים קרובות משא ומתן ותנאים אישיים. המחיר עשוי להיות תלוי בנפח ההזמנה, באזור או בשער החליפין. בנוסף, למוצרים רבים יש מאפיינים מורכבים — 15+ פרמטרים, בחירה לפי מפרט. בתרחישים כאלה, עגלה רק יוצרת אשליה של פשטות, בעוד שבפועל היא מגדילה את שיעור הנטישה במהלך התשלום. קטלוג עם טפסי בקשה מספק הקשר להצעה מסחרית איכותית.

  קטלוג לעומת חנות

  קטלוג ללא עגלה מוצדק אם מתקיימים לפחות שני תנאים:

  • מחירים אינם ציבוריים או תלויים בהקשר (נפח, אזור, חוזה)
  • העסקה דורשת משא ומתן — לא ניתן להשלים ב-2 קליקים
  • המבחר מורכב: מוצר מתואר על ידי 15+ מאפיינים, נבחר לפי מפרט
  • אין לוגיסטיקת מחסן בצד האתר

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

  מה כלול בפיתוח

  • מפרט טכני ואבות טיפוס
  • מבנה בלוקי מידע ו-HL-blocks
  • עיצוב קטלוג, כרטיס מוצר, פילטר
  • פריסה ואינטגרציה עם Bitrix
  • הגדרת סינון, השוואה, טפסי בקשה
  • תבניות SEO ומיקרודאטה
  • ייבוא נתונים וחילופי 1C (במידת הצורך)
  • בדיקות ומסירה לתפעול

  שלבים ולוחות זמנים

  1. עיצוב (3-5 ימים) — מבנה בלוק מידע, מפת מאפיינים ניתנים לסינון, אבות טיפוס ב-Figma
  2. עיצוב (1-2 שבועות) — קטלוג, כרטיס מוצר, פילטר, השוואה, טפסי בקשה
  3. פיתוח (2-5 שבועות) — פריסה, אינטגרציית Bitrix, הגדרת פילטר, טפסי משוב, SEO
  4. תוכן וייבוא (3-7 ימים) — טעינת מוצרים, הגדרת חילופי 1C במידת הצורך
  5. בדיקות והשקה (3-5 ימים) — תאימות דפדפנים, גרסת מובייל, PageSpeed, מסירה

  היקף	לוחות זמנים
  קטלוג עד 500 פריטים, ללא אינטגרציות	3-5 שבועות
  קטלוג 1-10K פריטים, פילטר, השוואה	5-8 שבועות
  קטלוג 10-50K, חילופי 1C, אזור אישי	8-12 שבועות

  אנחנו בשוק מעל 5 שנים, יישמנו 40+ קטלוגים על Bitrix. ניסיון בתעשייה, בנייה, הפצה. תיעוד Bitrix.

  צרו קשר כדי לדון בפרויקט שלכם. הזמינו פיתוח קטלוג — קבלו הצעה תוך יום.