שירותי פיתוח שוק מקוון על 1C-Bitrix

פיתוח מרקטפלייס על 1C-Bitrix: התגברות על מגבלות הארכיטקטורה הסטנדרטית

טבלת b_sale_order ו-b_sale_basket הקשורים אינם מיועדים לריבוי מוכרים (multivendor) כברירת מחדל. ב-Bitrix אין מודול 'מרקטפלייס' מובנה — בכל פעם מדובר בפיתוח מותאם אישית על גבי מודול המכירות. מודול המכירות הסטנדרטי אינו יכול לפצל הזמנות לפי ספקים שונים: אם העגלה מכילה פריטים משלושה מוכרים, Bitrix יוצר הזמנה אחת עם מספר אחד, סטטוס אחד וסכום אחד. אי אפשר לשלוח כל תת-הזמנה לדשבורד נפרד, לחשב עמלות לכל מוכר, או לאפשר משלוח חלקי. עלינו להגדיר מחדש את כל הלוגיקה: מהעגלה ועד מודל הסטטוסים. בנוסף, החיפוש הסטנדרטי (Sphinx) והקאשינג אינם מותאמים לקטלוג רב-מוכרים — עם 100,000 פריטים מ-500 ספקים, פילטרים לפי ספק גורמים לירידת ביצועים (שאילתות עם WHERE על IBLOCK_ELEMENT_PROPERTY הופכות לאיטיות פי 5–10). אנו כותבים מודול נפרד שמרחיב את העגלה הסטנדרטית: מוסיף קישור פריט-לספק דרך מאפיין הזמנה, מפצל הזמנה אחת לתת-הזמנות לפי מוכר, ומנתב כל אחת בנפרד.

מדוע פתרונות סטנדרטיים אינם מתאימים לפלטפורמות רב-מוכרים?

מודלים של מרקטפלייס

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

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

מרקטפלייס שירותים — בקשות, מכרזים, אסקרו. כאן, במקום b_sale_basket, ישות בקשות מותאמת אישית עובדת עם תהליך עבודה דרך תהליכים עסקיים של Bitrix.

מרקטפלייס B2B — חוזים, דוחות התאמה, מסגרות אשראי, EDI. אימות לפי ח.פ., קבוצות מחיר מרובות דרך b_catalog_group, מגבלות משלוח.

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

מודלי מונטיזציה

מה כולל דשבורד המוכר?

הדשבורד הוא הלב של המרקטפלייס. דשבורד לא נוח = פלטפורמה ריקה. אין פתרון סטנדרטי; אנו בונים מאפס באמצעות רכיבי Bitrix.

• ניהול קטלוג — CRUD למוצרים דרך רכיב מותאם אישית, העלאה גורפת של CSV/XML דרך CIBlockXMLFile. אף אחד לא מזין ידנית 10,000 SKU, אז ייבוא הוא הדבר הראשון שאנו עושים.
• עיבוד הזמנות — תת-ההזמנות מגיעות לדשבורד דרך ajax-polling או websocket. אישור, הדפסת חשבונית דרך CSalePdf, עדכון סטטוס עם סנכרון חזרה להזמנה הראשית.
• אנליטיקה פיננסית — דשבורד על בלוק מידע Highload של נתונים מצטברים. הכנסות, עמלות, תשלומים — פירוט לפי מוצר ותקופה. המוכר רואה מה נמכר ומה רק תופס מקום במדף.
• הגדרות משלוח — תעריפים משלו של המוכר, קישור ל-sale.delivery.handler.
• תקשורת — צ'אט מובנה ללא חשיפת פרטי קשר. מיושם דרך מודול im או טבלת הודעות מותאמת אישית.
• מבצעים — הנחות, קופונים דרך b_sale_discount עם פילטר לפי vendor_id.

מודרציה ובקרת איכות

מנה אחת של מוצרים מזויפים הורגת את המוניטין של הפלטפורמה. לכן, מודרציה היא חובה.

• מודרציית מוצרים — סטטוס ACTIVE='N' עד לאימות. מודרציה אוטומטית מסננת הפרות ברורות (מילים אסורות, תמונות חסרות), מודרציה ידנית מטפלת במחלוקות. Handler OnBeforeIBlockElementUpdate מונע עקיפה.
• אימות מוכרים — בדיקת ח.פ. דרך API של רשות המסים, העלאת סריקות מסמכים. סטטוסים: חדש → מאומת → פרימיום. כל רמה פותחת מגבלות על מספר מוצרים ועמלות.
• מערכת דירוג — לא רק כוכבים. האלגוריתם מתחשב במהירות משלוח (AVG(ship_date - order_date)), שיעור החזרות ואיכות תשובות.
• אנטי-הונאה — זיהוי מניפולציות דירוג לפי דפוסים (IP זהה, טקסטים זהים, תדירות חריגה). חשבונות כפולים נתפסים לפי ח.פ. ופרטי בנק.
• טעות אופיינית: אחסון נתוני ספקים בבלוק מידע רגיל — עם 1000+ מוכרים, השאילתות הופכות לאיטיות. השתמשו בבלוקי מידע Highload.

כיצד בנויה מערכת התשלומים למוכר?

המודול הפיננסי הוא הסיבה שמוכרים מצטרפים לפלטפורמה.

• חישוב עמלה — handler על שינוי סטטוס הזמנה. העמלה תלויה בקטגוריה, סטטוס מוכר ותנאים עדכניים. נשמרת בטבלה נפרדת vendor_transactions.
• תשלומים תקופתיים — משימת cron מייצרת רישום: שבועי, דו-חודשי או חודשי. סכום תשלום מינימלי, החזקה עד לאישור.
• חשבוניות ודוחות — הפקת PDF דרך PhpOffice\PhpSpreadsheet, מספור אוטומטי, הורדה בלחיצה אחת.
• החזקה — כספים מוחזקים עד קבלת המוצר. מפחית מחלוקות והחזרות.
• תשלומים דרך API בנקאי — YooKassa, CloudPayments, API בנקאי ישיר. המוכר מקבל כסף ללא שיחות או תזכורות.
• חשוב: פיצול הזמנות ב-handler של OnSaleOrderSaved מוביל לחוסר התאמה בסטטוסים. פצלו בשלב העגלה.
• פיסקאליזציה ידנית של כל תת-הזמנה מפרה את חוק 54-FZ. השתמשו בקבלה אחת עם מאפיין 'סוכן'. בפרויקט אחד, אוטומציית פיסקאליזציה חסכה עלויות חודשיות משמעותיות. בפרויקט אחר, אופטימיזציית חיפוש דרך Elasticsearch הפחיתה את זמן טעינת הקטלוג ב-80% (מ-3 שניות ל-0.6 שניות).

כיצד אנו בונים ארכיטקטורת מרקטפלייס

1. הגדרת מודל עסקי — בחירת סוג מרקטפלייס ותוכנית מונטיזציה.
2. עיצוב מסד נתונים — בלוקי מידע Highload לקטלוגים מעל 50,000 SKU, טבלאות נפרדות לתת-הזמנות (orders_split) ועסקאות.
3. פיתוח ליבה — יצירת מודול marketplace.vendor, יישום קישור מוצר-לספק, מנגנון פיצול הזמנות, סוכנים לחישוב עמלות.
4. שער תשלום ואינטגרציית 54-FZ — הגדרת פיסקאליזציה דרך ATOL Online או CloudPayments.
5. בדיקות עומס — שימוש ב-k6 או ab לאימות 5000 הזמנות ביום.

טעויות אופייניות בפיתוח מרקטפלייס על Bitrix

• אחסון ספקים בבלוק מידע רגיל — גורם להאטות עם >1000 רשומות. השתמשו בבלוקי מידע Highload.
• פיצול הזמנות לאחר השמירה — שובר את מודל הסטטוסים. פצלו בשלב העגלה.
• פיסקאליזציה ידנית של כל תת-הזמנה — מפרה את 54-FZ. בצעו פיסקאליזציה עם קבלה אחת עם מאפיין סוכן.
• התעלמות מקאשינג מתויג (tagged caching) לקטלוג — עם multivendor, הקאש נפסל לחלוטין. הגדירו תגיות לפי vendor_id.

מחסן טכנולוגיות

• 1C-Bitrix 'Business' או 'Enterprise' — מודולי sale + catalog כבסיס. מעטפת multivendor — מודולים מותאמים אישית.
• בלוקי מידע Highload — קטלוגים מעל 100,000 SKU. בלוקי מידע רגילים בנפחים כאלה נכשלים בסינון: CIBlockElement::GetList עם תריסר מאפיינים מייצר JOINs על עשרות טבלאות b_iblock_element_prop_sNN. Highload פותר זאת עם מבנה שטוח.
• Elasticsearch — חיפוש טקסט מלא. Elasticsearch מעבד שאילתות פי 10 מהר יותר ממודול החיפוש המובנה (Sphinx). המשתמש מקליד 'נעלי נייק' — מוצא 'נעלי נייק'.
• תורים — ייבוא קטלוג, חישוב תשלומים, הפקת דוחות. סוכני Bitrix (CAgent) למשימות קלות, תור נפרד דרך RabbitMQ או supervisor + CLI מותאם אישית למשימות כבדות.

אנו מבטיחים שהמודול שפותח יעמוד בעומס של עד 5000 הזמנות ביום על VPS סטנדרטי. מומחי 1C-Bitrix מוסמכים (ניסיון של מעל 10 שנים, 50+ פרויקטים שהושלמו) מבצעים ביקורת ארכיטקטורה לפני תחילת הפיתוח. בקנה מידה של 2000 מוכרים, זמן מודרציה ממוצע הוא 15 דקות, ו-95% מההזמנות מעובדות אוטומטית.

מרקטפלייסים לפי תעשייה

לכל נישה יש את המלכודות שלה:

• חומרי בניין — חישוב משלוח לפריטים גדולים. משטחים, טונאז', הרמה לקומה. מחשבון המשלוח הסטנדרטי לא יכול להתמודד; אנו כותבים sale.delivery.handler מותאם אישית.
• מוצרי מזון — תאריכי תפוגה במאפייני בלוק מידע, משטר טמפרטורה, משבצות משלוח באותו יום. טעות לוגיסטית פירושה מחיקה.
• חלקי רכב — בחירת VIN דרך API של Laximo, הפניות צולבות, מקוריים וחלופיים. כאב ראש נפרד הוא זמני משלוח שונים מספקים שונים עבור אותו חלק.
• ביגוד — טבלאות מידות (EU/US/RU), שיעור החזרות גבוה. לוגיקת עיבוד החזרות עם חלוקת עמלות מחדש היא שכבה שלמה.
• ציוד תעשייתי — B2B עם מכרזים, בקשות הצעת מחיר. כרטיס מוצר עם 50+ פרמטרים בטבלה.

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

לנסות להשיק הכל בבת אחת זו דרך בטוחה לא להשיק כלום.

MVP תוך 3-4 חודשים. פלטפורמה מלאה — 6-12 חודשים של פיתוח אינקרמנטלי.

מה כלול

• תיעוד: דיאגרמת ארכיטקטורה, תיאור API, הוראות למוכרים.
• גישה: מאגר קוד, סביבת בדיקות, פאנל ניהול.
• הדרכה: שני מפגשים למנהלים ומנהלי מערכת.
• תמיכה: חודש תמיכה חינם לאחר ההשקה, ולאחר מכן לפי SLA.
• אחריות על מודולים שפותחו — 12 חודשים.

צרו קשר להערכת הפרויקט שלכם — נחשב לוחות זמנים ועלות באופן אישי. בקשו ייעוץ, ונראה על מקרה אמיתי כיצד אנו פותרים את בעיית ה-multivendor תוך 30 דקות. קבלו תוכנית פיתוח מפורטת למרקטפלייס שלכם היום.