ארכיטקטורת מרקטפלייס מרובה ספקים על 1C-Bitrix

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

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

בפרויקט אחד, אנו מטפלים ב-50,000 מוצרים מ-200 ספקים — המערכת מעבדת 1,000 הזמנות ביום ללא השהיות. הזמינו הערכה מקדימה של הפרויקט שלכם — ננתח את המורכבות ונציע את המסלול האופטימלי.

כיצד לבודד נתוני ספקים?

הגישה המעשית ביותר היא להוסיף מזהה ספק ברמת בלוק המידע של הקטלוג. הספק נרשם כמשתמש Bitrix בקבוצת "ספקים"; ה-USER_ID שלו משמש כ-VENDOR_ID. בלוק המידע הראשי של הקטלוג מורחב בשדה UF מסוג UF_VENDOR_ID (קישור ל-b_user.ID). כל רכיבי הקטלוג מוסיפים סינון לפי UF_VENDOR_ID בעת הבחירה. בחשבון האישי של הספק, מופיעים רק אלמנטים עם ה-UF_VENDOR_ID שלהם.

חלופה למרקטפלייסים גדולים: בלוק מידע HighLoad כשכבת ביניים המאחסן את המיפוי PRODUCT_ID → VENDOR_ID ומשמש לבדיקות הרשאה מהירות.

טבלת ספקים (דרך בלוק מידע HL או מותאם אישית):

כיצד לפצל הזמנות בין ספקים?

לקוח מוסיף מוצרים משלושה ספקים לסל. ב-Bitrix, זו הזמנה אחת ב-b_sale_order. אנו משתמשים בתת-הזמנות כרשומות בנות: נוצרת טבלה נוספת mp_sub_orders עם השדות ORDER_ID, VENDOR_ID, STATUS, TOTAL, COMMISSION.

עם יצירת ההזמנה, המטפל OnAfterOrderAdd יוצר אוטומטית תת-הזמנות על ידי קיבוץ פריטי הסל לפי ה-UF_VENDOR_ID של המוצרים. הספק רואה רק את תת-ההזמנות שלו.

פתרון תת-ההזמנות שלנו מטפל ב-1,000 הזמנות ביום ללא עיכובים, בעוד שהגישה הטיפוסית מבוססת-האירועים מתחילה להתעכב ב-200 הזמנות. חלופה היא לאחסן VENDOR_ID ב-b_sale_basket כמאפיין מותאם אישית ולנהל סטטוסים ברמת הפריט. גישה זו פשוטה יותר אך מסבכת את צבירת התשלומים. עבור רוב הפרויקטים, תת-הזמנות הן אופטימליות.

חשבון אישי לספק

רכיבי חשבון ספק מינימליים:

• ניהול מוצרים: הוספה/עריכה/השבתה עם UF_VENDOR_ID = משתמש נוכחי כפוי
• ניהול תת-הזמנות: רשימה, שינוי סטטוס, הדפסת חשבונית
• ניהול מלאי ומחירים: עדכון גורפי דרך CSV או AJAX
• אנליטיקה: מכירות לפי תקופה, מוצרים מובילים, החזרות בהתבסס על תת-הזמנות
• פרופיל ופרטי תשלום: מסמכים, פרטי תשלום, סטטוס אימות
• פיננסים: עמלות נצברות, היסטוריית תשלומים, יתרה

הרשאות: משתמש בקבוצת "ספקים" בתוספת בדיקת UF_VENDOR_ID בכל בקשה.

מערכת עמלות

עמלות מחושבות ביצירת תת-ההזמנה או כשמגיעה לסטטוס סופי. לוגיקה:

// Simplified pseudocode
$commissionRate = $vendor['UF_COMMISSION_RATE'] ?? $categoryRate[$product['IBLOCK_SECTION_ID']] ?? $defaultRate;
$commission = $subOrder['TOTAL'] * $commissionRate / 100;

// Save to financial operations table
MpFinanceTable::add([
    'VENDOR_ID' => $vendor['ID'],
    'ORDER_ID' => $orderId,
    'TYPE' => 'commission',
    'AMOUNT' => -$commission,
    'STATUS' => 'pending',
]);

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

מודרציה של מוצרים

מוצרי ספקים עוברים מודרציה לפני פרסום. מבחינה טכנית, זהו סטטוס של אלמנט בלוק המידע: כאשר ספק מוסיף מוצר, נקבעים ACTIVE = N וסטטוס מיוחד UF_MODERATION_STATUS = 'pending'. המנהל (משתמש בקבוצת "מנהלים") רואה את תור המודרציה, בודק, קובע ACTIVE = Y או דוחה עם הערה. הודעת ספק דרך CEvent::Send() או התראות Bitrix מובנות.

מה כלול בפיתוח: אספקה ותיעוד

כל פרויקט כולל:

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

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

1. ניתוח וארכיטקטורה – עיצוב דיאגרמת ER, סכמת זכויות גישה.
2. רישום ספקים – הגדרת פרופילים, פרטי תשלום, אימות מספר עוסק מורשה.
3. בידוד מוצרים והזמנות – יישום UF_VENDOR_ID ותת-הזמנות.
4. חשבון אישי לספק – פיתוח מודול לניהול מוצרים, הזמנות ואנליטיקה.
5. מודול פיננסי – חישוב עמלות אוטומטי, תשלומים דרך API בנקאי.
6. מודרציה ואנליטיקה – תור מודרציה, דוחות מנהל.
7. בדיקות והשקה – בדיקות עומס, הדרכת צוות, שבועיים תמיכה.

לוח זמנים לפיתוח

לוחות הזמנים הם לפיתוח מאפס. שימוש במודול רב-ספקים מוכן כבסיס מפחית את ההתאמה האישית ל-10-16 שבועות.

היתרונות של עבודה איתנו

הניסיון שלנו בפיתוח Bitrix משתרע על פני יותר מ-5 שנים; השלמנו למעלה מ-30 פרויקטים. מומחים מוסמכים של 1C-Bitrix מבטיחים אחריות על הקוד ל-6 חודשים. צרו קשר לייעוץ — נעריך את הפרויקט שלכם ביום אחד ונציע פתרון.

אילו בעיות פותרת ארכיטקטורת ריבוי ספקים?

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