הגדרת עמלות מרקטפלייס עבור 1C-Bitrix
ראינו שוב ושוב תרחיש זה: המרקטפלייס של Bitrix פעיל, אך העמלות מחושבות ידנית באקסל. המוכרים מתבלבלים, הנהלת החשבונות מבזבזת ימים על התאמות, ושגיאות חישוב מובילות להפסדים. לקוח אחד — מרקטפלייס עם 200 מוכרים — הפסיד עד 14–20 אלף דולר בחודש עקב יישום שגוי של תעריפים. האוטומציה פתרה את הבעיה: העמלות החלו להיצבר בצורה נכונה, וזמן ההתאמה ירד מ-3 ימים לשעתיים. הגדרת עמלות מרקטפלייס במפתח מלא ב-1C-Bitrix מאפשרת ליישם כל מודל חישוב תוך 1–3 שבועות. לפי התיעוד הרשמי, HL-blocks הם הדרך הסטנדרטית לאחסון ישויות מותאמות אישית, ומספקים גמישות לכללי עמלות. ניתן להפחית עלויות חישוב ידני ולשפר את השקיפות הפיננסית.
אילו מודלי עמלות קיימים?
עמלה היא אחוז או סכום קבוע שהפלטפורמה מנכה ממכירה. הכללים יכולים להיות:
- גלובלי — תעריף אחיד לכל המוכרים.
- לפי קטגוריה — אחוזים שונים לקבוצות מוצרים שונות.
- לפי מוכר — תנאים אישיים לשותפים מרכזיים.
- משולב — לדוגמה, 5% לפריטים עד 9–13 דולר, 3% מעל.
- פרוגרסיבי — האחוז יורד ככל שמחזור המכירות של המוכר עולה (מיושם באמצעות היסטוריית מכירות).
אנו מיישמים כל וריאנט באמצעות HL-blocks עם גרסאות ותקופות תוקף. זה אמין יותר מאחסון כללים ב-b_option. המהנדסים שלנו מוסמכים כ-"1C-Bitrix: Developer" ובעלי ניסיון של 10+ שנים, מה שמבטיח ביצועים יציבים של האלגוריתם גם בעומסים של 10,000+ הזמנות ביום.
למה HL-blocks הם אופטימליים לאחסון כללי עמלות
HL-blocks מאפשרים אחסון כללים בפורמט מובנה עם תמיכה בסוגי נתונים, אינדקסים וסינון. בניגוד ל-b_option, ניתן ליישם שאילתות מורכבות — לדוגמה, מציאת כלל לפי שילוב מוכר-קטגוריה. תקופות תוקף (ACTIVE_FROM, ACTIVE_TO) מיושמות על ידי הוספת שני שדות תאריך, וגרסאות דרך היסטוריית שינויים. זה מספק גמישות לניהול מבצעים ותעריפים זמניים ללא החלפת נתונים.
כיצד להגדיר כללי עמלות מורכבים
מבנה טבלת הכללים הוא אוניברסלי:
| שדה | סוג | תיאור |
|---|---|---|
| ID | int | מפתח ראשי |
| RULE_TYPE | varchar | global / category / vendor |
| VENDOR_ID | int | null = חל על כולם |
| CATEGORY_ID | int | מזהה של סעיף בלוק מידע, null = כל הקטגוריות |
| RATE_TYPE | varchar | percent / fixed |
| RATE_VALUE | decimal | אחוז או סכום קבוע |
| MIN_AMOUNT | decimal | עמלה מינימלית |
| MAX_AMOUNT | decimal | עמלה מקסימלית (null = ללא הגבלה) |
| ACTIVE_FROM | date | תאריך תחילת תוקף הכלל |
| ACTIVE_TO | date | תאריך סיום תוקף הכלל (null = ללא הגבלת זמן) |
אלגוריתם בחירת הכללים מיושם ב-handler OnAfterOrderAdd:
function calculateCommission(int $vendorId, int $categoryId, float $amount): float {
// Приоритет: vendor+category > vendor > category > global
$rule = findRule($vendorId, $categoryId) ?? findRule($vendorId, null) ?? findRule(null, $categoryId) ?? findRule(null, null);
if (!$rule) return 0.0;
$commission = $rule['RATE_TYPE'] === 'percent' ? $amount * $rule['RATE_VALUE'] / 100 : $rule['RATE_VALUE'];
if ($rule['MIN_AMOUNT']) $commission = max($commission, $rule['MIN_AMOUNT']);
if ($rule['MAX_AMOUNT']) $commission = min($commission, $rule['MAX_AMOUNT']);
return round($commission, 2);
}העמלה נכתבת לטבלת הפעולות הפיננסיות עם סוג function calculateCommission(int $vendorId, int $categoryId, float $amount): float { // Приоритет: vendor+category > vendor > category > global $rule = findRule($vendorId, $categoryId) ?? findRule($vendorId, null) ?? findRule(null, $categoryId) ?? findRule(null, null); if (!$rule) return 0.0; $commission = $rule['RATE_TYPE'] === 'percent' ? $amount * $rule['RATE_VALUE'] / 100 : $rule['RATE_VALUE']; if ($rule['MIN_AMOUNT']) $commission = max($commission, $rule['MIN_AMOUNT']); if ($rule['MAX_AMOUNT']) $commission = min($commission, $rule['MAX_AMOUNT']); return round($commission, 2); } ומקושרת להזמנה. זה מבטיח שקיפות מלאה להנהלת החשבונות ומאפשר בניית דוחות לפי מוכר ותקופה. הגדרת עמלות מרקטפלייס ב-1C-Bitrix כוללת גם אינטגרציה עם מערכות תשלום לחישוב נתוני פיסקליים נכונים.
כיצד להגדיר סולם עמלות פרוגרסיבי
סולם פרוגרסיבי כולל שינוי התעריף בהתאם למחזור המכירות המצטבר של המוכר בתקופה (לדוגמה, חודש או רבעון). זה דורש טבלה נוספת לאחסון היסטוריית מכירות לכל מוכר. האלגוריתם, בזמן חישוב העמלה, מסכם את המחזור לתקופה הנדרשת ובוחר את הכלל המתאים מה-HL-block. אנו מיישמים לוגיקה זו עם שמירת סכום המחזור במטמון כדי להימנע מחישוב חוזר בכל פעם. חיסכון טיפוסי בזמן חשבונאי עם סולם פרוגרסיבי — עד 60%.
דוגמה לחישוב עמלה פרוגרסיבית
מוכר עם מחזור של עד 4.5–6.5 אלף דולר בחודש משלם 5%, מ-500,000 עד 1,000,000 — 4%, מעל — 3%. עם מחזור של 11–16 אלף דולר, עמלה = 500,000 * 5% + 500,000 * 4% + 200,000 * 3% = 25,000 + 20,000 + 6,000 = 460–660 דולר.
השוואה בין מודלים בסיסיים ומורכבים
| פרמטר | מודל בסיסי | מודל מורכב |
|---|---|---|
| מספר כללים | 1–10 | 10–100+ |
| תעריפים אישיים | לא | כן |
| תעריפים פרוגרסיביים | לא | כן |
| מבצעים זמניים | לא | כן |
| זמן יישום | שבוע 1 | 2–3 שבועות |
| חיסכון בזמן חשבונאי | עד 30% | עד 60% |
מה כלול בעבודה?
- ניתוח הלוגיקה העסקית הנוכחית ודרישות העמלות.
- עיצוב מבנה הכללים ומסד הנתונים.
- יישום אלגוריתם החישוב עם טיפול בעדיפויות.
- פיתוח ממשק ניהול לכללים (CRUD, מסננים, בוחרי תאריכים).
- יצירת דוח עמלות עם ייצוא לאקסל.
- בדיקות על עותק מסד נתונים (מינימום 100 הזמנות מסוגים שונים).
- פריסה לסביבת הייצור והדרכת מפעילים.
- אחריות ל-30 יום לאיתור שגיאות נסתרות.
תהליך
- ניתוח — שיחה איתך, לימוד הדרישות, לכידת כל ניואנסי העמלות.
- אב-טיפוס — סכמת מסד נתונים ואלגוריתם תוך 1–2 ימים.
- פיתוח — כתיבת קוד, יצירת ממשק הניהול.
- בדיקות — אימות על נתוני בדיקה עם תרחישים מרובים (50+ הזמנות בדיקה).
- פריסה והדרכה — השקה על השרת החי, הוראות למנהלים.
לוחות זמנים ועלות
יישום בסיסי (תעריף יחיד + כללים לפי קטגוריה) אורך שבוע 1. מודל מורכב (תעריפים אישיים, תעריפים פרוגרסיביים, מבצעים זמניים) אורך 2–3 שבועות. העלות מחושבת באופן אישי לאחר ניתוח הדרישות. נבחן את הפרויקט שלך — פשוט צור קשר. בקשו ביקורת של מערכת העמלות הנוכחית שלכם — נזהה צווארי בקבוק ונציע פתרון אופטימלי.
אנו עובדים עם Bitrix למעלה מ-10 שנים ומוסמכים כ-"1C-Bitrix: Developer". בפרויקט שלך תקבל פתרון מוכן, תיעוד ותמיכה לאחר היישום. צור קשר לייעוץ — נבחר את הארכיטקטורה הטובה ביותר עבור מודל המרקטפלייס שלך.