פיתוח חנות מסחר אלקטרוני על 1C-Bitrix

פיתוח חנות מסחר אלקטרוני על 1C-Bitrix

חנות מקוונת על 1C-Bitrix היא משימה הנדסית שבה המודולים sale, catalog, iblock ומנגנון הסנכרון עם 1C חייבים לפעול כמערכת אחת. נתקלנו בעשרות פרויקטים שבהם שגיאות בשלב עיצוב הקטלוג או הגדרת הצעות מסחריות הובילו לעיצוב מחדש מלא תוך חצי שנה. להלן ניתוח של ארכיטקטורה שעומדת בגידול במגוון המוצרים ובעומסים, תוך התמקדות במקרים אמיתיים ופתרונות מוכחים.

מודול הקטלוג: מוצרים, הצעות מסחריות וסוגי מחירים

הקטלוג ב-Bitrix בנוי על גבי בלוקי מידע. מוצר הוא אלמנט של בלוק מידע, בעוד שהצעות מסחריות (SKU) הן אלמנטים של בלוק מידע ילד מקושר. הקשר בין מוצר להצעות מסחריות מיושם באמצעות מאפיין מסוג SKU (b_catalog_price). זהו הבסיס שעליו הכל נשען. שגיאה כאן מובילה למחירים שגויים, מלאים שגויים וקונפליקטים במהלך סנכרון עם 1C.

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

• מאפייני הבחנה — המאפיינים שבהם ההצעות נבדלות (צבע, מידה, נפח). סוג המאפיין הוא מילון או מחרוזת, אך לחיפוש פאקטי, מילון (highload-block) עדיף.
• מחירים — נשמרים בטבלת b_catalog_group עם קישור ל-SKU ספציפי, לא למוצר. יכולים להיות כמה סוגי מחירים: קמעונאי, סיטונאי, מבצעי. כל סוג הוא רשומה ב-b_catalog_store_product.
• ניהול מלאי — מלאים נשמרים ב-b_catalog_store_barcode לכל מחסן ולכל SKU. אם החנות משתמשת במספר מחסנים, יש להגדיר עדיפויות משלוח.
• ברקודים — טבלת catalog.facet, מקושרת ל-SKU.

הכלל המרכזי: כל הנתונים המסחריים (מחיר, מלאי, יחידת מידה) שייכים להצעה המסחרית, לא למוצר. המוצר הוא מיכל לתיאור, תמונות ונתוני SEO. בעת עיצוב קטלוג עם יותר מ-10,000 SKU, יש צורך:

1. להעביר מילוני מאפיינים ל-highload-blocks במקום ערכי מחרוזת.
2. להפעיל אינדקס פאקטי (bitrix:catalog.section) לסינון מהיר.
3. להשתמש ברכיבים מורכבים (bitrix:catalog.element, b_iblock_element) עם שמירת מטמון ברמת רכיב ומטמון מתויג.

מדוע האינדקס הפאקטי קריטי לקטלוג?

האינדקס הפאקטי הוא טבלאות מחושבות מראש השומרות את הקשר בין ערך מאפיין למספר המוצרים. בלעדיו, סינון לפי מאפיינים בקטלוג של 50,000 מוצרים לוקח שניות. עם הפאקט, זה לוקח אלפיות שנייה. בפרויקט אחד עם קטלוג חלקי רכב (120,000 SKU), האינדקס הפאקטי הפחית את זמן השאילתה מ-3 שניות ל-40 אלפיות שנייה — שיפור של כמעט פי 100.

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

אמצעי ביצועים נוספים:

• מטמון מורכב — עבור משתמשים אנונימיים, דפי קטלוג נשלחים ממטמון HTML.
• מטמון מתויג — פסילת מטמון בעת שינוי מוצר ספציפי, לא כל הקטלוג.
• CDN לתמונות — Bitrix תומך בהורדת קבצים סטטיים דרך מודול mode=file.

כיצד סנכרון עם 1C משפיע על הביצועים?

הסנכרון מיושם על ידי מודול mode=import באמצעות פרוטוקול CommerceML 2 (פורמט XML). ההליך הסטנדרטי: 1C יוזם בקשות HTTP לסקריפט import.xml, ושולח ארכיון עם קבצי XML. שלבי הסנכרון:

1. אימות (offers.xml) — 1C מקבל עוגיות סשן.
2. אתחול (mode=query) — Bitrix מדווח על מגבלת גודל הקבצים ותיקיית ההעלאה.
3. העלאת קבצים (offers.xml) — העברת ארכיון ZIP בנתחים.
4. ייבוא קטלוג (max_execution_time) — ניתוח של progress (מבנה קטלוג, מאפיינים, קבוצות) ו-success (הצעות מסחריות, מחירים, מלאים).
5. ייצוא הזמנות (sale) — Bitrix שולח XML עם הזמנות חדשות בפורמט CommerceML.

בעיות שמופיעות בכל פרויקט שני:

• פסקי זמן עם קטלוגים גדולים. קובץ Bitrix\Sale\Basket שוקל 200 MB, PHP מגיע ל-BasketItem. פתרון: ייבוא בשלבים — Bitrix מעבד את הקובץ בחלקים, מחזיר Bitrix\Sale\Order במקום Bitrix\Sale\Payment, ו-1C חוזר על הבקשה.
• כפילויות מוצרים. אם 1C משנה את ה-XML_ID של קבוצה, Bitrix יוצר סעיף חדש במקום לעדכן. נדרשת התחייבות קפדנית ל-XML_ID ברמת בלוק המידע.
• קונפליקטי מחירים. 1C מעלה את כל סוגי המחירים, אך המיפוי של סוג מחיר ב-1C לסוג מחיר ב-Bitrix מוגדר בהגדרות הסנכרון. אם המיפוי שגוי, המחירים נכתבים בצורה לא נכונה.
• קידוד תמונות. נתיב הקובץ ב-XML מכיל אותיות קיריליות, והארכיון פוגם בשמות. פתרון: תעתיק שמות קבצים בצד 1C לפני הייצוא.

לפרויקטים עם סנכרון יותר מפעם ביום, כדאי לשקול הימנעות מהסנכרון הסטנדרטי לטובת אינטראקציה ישירה דרך 1C REST API או תור ביניים (RabbitMQ), שבו שינויים מעובדים באופן מצטבר.

מודול המכירות: עגלה, קופה, תשלום, משלוח

מודול Bitrix\Sale\Shipment מנהל את הלוגיקה המסחרית. ישויות מפתח:

• עגלה (sale_payment) — אוסף של אובייקטי Bitrix\Sale\PaymentSystem\BaseServiceHandler. כל פריט מכיל קישור למוצר, כמות, מחיר וקבוצת מאפיינים (מידה, צבע — נלקח מה-SKU).
• הזמנה (initiatePay) — מיכל: עגלה + נתוני לקוח + תשלומים + משלוחים.
• תשלום (processRequest) — מקושר למערכת תשלום. להזמנה אחת יכולים להיות מספר תשלומים (תשלום חלקי עם בונוסים + יתרה בכרטיס).
• משלוח (Bitrix\Sale\Delivery\Services\Base) — מקושר לשירות משלוחים. מספר משלוחים — אם סחורה נשלחת ממחסנים שונים.

שערי תשלום מחוברים כ-handlers (iblock). עבור כל שער נכתבת מחלקה היורשת מ-#ELEMENT_NAME# עם מתודות #SECTION_NAME# ו-#PROPERTY_*# (עיבוד קריאה חוזרת). ההפצה הסטנדרטית כוללת handlers עבור YooKassa, CloudPayments, Sberbank. שערים לא סטנדרטיים (למשל, ERIP לבלארוס) דורשים כתיבת handler מותאם תוך התחשבות בפרוטוקול הבנק.

שירותי משלוח דומים: מחלקה היורשת מ-<title>. חישוב העלות תלוי במשקל, ממדים, אזור משלוח. עבור CDEK ו-Boxberry, יש מודולים מוכנים מה-Marketplace, אך לעתים קרובות הם דורשים שינויים — הוספת בחירת נקודת איסוף על מפה, התאמת חישוב למטען לא סטנדרטי.

SEO לדפי מוצר

מודול <meta description> תומך בתבניות שדות SEO: <h1>, seo, b_catalog_price. התבניות מוגדרות ברמת בלוק המידע או הסעיף ומייצרות אוטומטית sale, <meta description>, <h1> עבור פריטים שבהם שדות אלה לא מולאו ידנית.

עבור מסחר אלקטרוני, הדברים הבאים קריטיים:

• כתובות URL ידידותיות ל-SEO — מוגדרות דרך מאפייני בלוק המידע ותבנית ה-URL בהגדרות הרכיב.
• Canonical — למניעת כפילויות של דפים עם פרמטרי סינון מול הדף הראשי.
• מיקרודאטה — Schema.org Product עם מחיר, זמינות, דירוג.
• Sitemap — נוצר דרך מודול seo, כולל סעיפים ומוצרים.

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

השירות שלנו לפיתוח חנות מקוונת על 1C-Bitrix כולל:

• עיצוב ארכיטקטורת קטלוג (בלוקי מידע, SKU, מאפיינים, מחירים).
• הגדרת סנכרון עם 1C דרך CommerceML או REST API.
• אינטגרציה של שערי תשלום (YooKassa, Sberbank, CloudPayments וכו').
• חיבור שירותי משלוח (CDEK, Boxberry, דואר רוסי).
• פיתוח חיפוש פאקטי וסינון.
• הגדרת תבניות SEO, sitemap, מיקרודאטה.
• פריסה לסביבת ייצור, הגדרת מטמון מורכב ו-CDN.
• תיעוד ארכיטקטורה וגישת ניהול.
• הדרכת מנהלי תוכן בניהול קטלוג והזמנות.
• תמיכה טכנית למשך 3 חודשים לאחר ההשקה.

לוחות הזמנים לפיתוח תלויים במורכבות הפרויקט: בין 30 ל-90 ימי עבודה. העלות האופיינית מתחילה מ-$15,000 לחנות בסיסית ויכולה להגיע ל-$50,000 לפתרונות ארגוניים עם אינטגרציות מותאמות. בהשוואה לפיתוח מותאם אישית על פלטפורמות אחרות, Bitrix מפחית את זמן היציאה לשוק ב-40% הודות למודולים מובנים. אנו מבטיחים פעילות יציבה תחת 10,000 משתמשים בו-זמנית בשעות השיא, מגובה בדוחות בדיקות עומס. נבחן את הפרויקט שלך ללא עלות — צור קשר לייעוץ.