אם יש לכם 80 דילרים, מנהלים מבזבזים חצי יום על הפצת מחירונים. זהו צוואר בקבוק שאנחנו מבטלים. פורטל נותן מענה לשלוש משימות: הזמנות עצמאיות של דילרים, תנאים אישיים לכל שותף, וסנכרון אוטומטי עם 1C ללא התערבות אנושית. אנחנו יכולים להעריך את הפרויקט שלכם ביום אחד—צרו קשר לשיחה על הפרויקט.
ההבדל המרכזי בין פורטל דילרים ל-B2B רגיל הוא ההיררכיה: יצרן → דילר → תת-דילר. דילר אחד יכול להחזיק מספר חנויות ועובדים עם הרשאות שונות. מודל קבוצות המשתמשים הסטנדרטי של ביטריקס (b_user_group) אינו מספק—הוא לא מאחסן את הקשר "משתמש שייך לחברה".
אנחנו מיישמים זאת באמצעות D7 ORM: אנו יוצרים את הישות DealerCompany (טבלה b_dealer_company) עם שדות למזהה 1C, סטטוס, סוג דילר ואזור. הקישור בין משתמש לחברה הוא דרך טבלת b_dealer_company_user עם שדה תפקיד. תפקידים: owner, manager, accountant—לכל אחד זכויות שונות ליצירת הזמנות, צפייה במסמכים וניהול עובדים. אימות דרך bitrix:system.auth.form מורחב עם handler מותאם אישית. בכניסת משתמש, אנו קובעים את החברה וסוג הדילר שלו, ומאחסנים במטמון בסשן. כל הבקשות הבאות למחירים ולקטלוג לוקחות בחשבון את dealer_type.
איך להגדיר תמחור לסוגי דילרים שונים?
תמחור דילרים הוא החלק המורכב ביותר. סכמה טיפוסית:
- מחירון בסיס (ציבורי או פרטי)
- הנחת דילר לפי סוג (כסף, זהב, פלטינה)—אחוז הנחה ממחיר הבסיס
- פריטי חוזה אישיים—SKU ספציפיים במחירים קבועים
- תנאים מבצעיים עם תאריכי תוקף
מנגנון CATALOG_GROUP_ID הסטנדרטי ב-b_catalog_price מכסה את שתי הרמות הראשונות. עבור פריטי חוזה, יש צורך ב-Highload block dealer_contract_prices עם מבנה: UF_DEALER_ID, UF_PRODUCT_ID, UF_PRICE, UF_CURRENCY, UF_DATE_FROM, UF_DATE_TO. בעת שאילתת מחיר, אנו בודקים תחילה פריטי חוזה, אחר כך סוג דילר, ולבסוף מחיר בסיס.
לוגיקת עדיפות המחירים מיושמת דרך אירוע OnBeforeSaleOrderDoFinalAction או ספק מחירים מותאם אישית המיישם Bitrix\Catalog\v2\Price\BasePriceProvider. האפשרות השנייה נקייה יותר—היא לא תישבר בעדכוני מודול sale. לפי תיעוד ביטריקס, BasePriceProvider מבטיח תאימות לעדכונים עתידיים. פתרון ביטריקס מותאם אישית מציע גמישות תמחור טובה יותר מאשר מודול CRM מוכן.
קטלוג ומלאי
דילרים עובדים לעיתים קרובות עם מבחר מוגבל—לא כל הקטלוג של היצרן זמין לכל שותף. הגבלת מבחר מיושמת דרך:
- סינון לפי מאפיין אינפובלוק: הוספת מאפיין
AVAILABLE_FOR_DEALER_TYPES(סוג רשימה), ציון סוגי דילרים. ברכיבbitrix:catalog.section, הוספת פילטרPROPERTY_AVAILABLE_FOR_DEALER_TYPES= סוג הדילר הנוכחי. - Highload block למבחר: להגדרות גמישות—טבלה
dealer_assortment(UF_DEALER_ID,UF_IBLOCK_SECTION_ID). הדילר רואה רק את סעיפי הקטלוג המופיעים ברישומים שלו.
מידע על מלאי מגיע ממודול catalog הסטנדרטי, טבלה b_catalog_store_product. עבור פורטל דילרים, חשוב להציג מלאי במחסנים ספציפיים הזמינים לדילר (לדוגמה, מחסן באזור שלו). הקישור בין דילר למחסן מאוחסן ב-Highload block; ברכיב, השאילתה ל-b_catalog_store_product נדרסת.
| גישה | גמישות | מורכבות | מתאימה ל |
|---|---|---|---|
| סינון לפי מאפיין | בינונית | נמוכה | קטלוג קטן, סוגי דילרים קבועים |
| Highload block למבחר | גבוהה | בינונית | קטלוג גדול, הגדרות אישיות |
ניהול מסמכים וכספים
דילרים מבקשים כל הזמן מסמכים—חשבוניות, תעודות משלוח, דוחות התאמה. אחסונם בביטריקס מיותר אם הם כבר קיימים ב-1C. תהליך העבודה:
- הפורטל מבקש רשימת מסמכי דילר דרך שירות REST של 1C (או מעלה לטבלת ביניים)
- מסמכים נשמרים במטמון ב-Highload block
dealer_documents:UF_DEALER_ID,UF_DOC_TYPE,UF_DOC_NUMBER,UF_DATE,UF_AMOUNT,UF_FILE_URL - סנכרון דרך cron כל שעתיים באמצעות סוכן מודול
main(CAgent::AddAgent) - קבצי PDF נשלפים לפי דרישה, נשמרים במטמון ב-
/upload/dealer/docs/למשך 24 שעות
חוב ומסגרת אשראי—בדומה: Highload block dealer_credit (UF_DEALER_ID, UF_LIMIT, UF_CURRENT_DEBT, UF_OVERDUE). אם המסגרת חריגה או שיש חוב באיחור, יצירת הזמנה נחסמת דרך handler של אירוע OnBeforeSaleOrderAdd.
מה קורה אם דילר חורג ממסגרת האשראי?
בכל פעם שנוצרת הזמנה, ה-handler של OnBeforeSaleOrderAdd פועל: הוא בודק את החוב הנוכחי מ-dealer_credit. אם המסגרת חריגה או שיש חוב באיחור, ההזמנה נחסמת והדילר מקבל הודעה. זה מבטל סיכוני תשלום ומבצע אוטומציה של בקרה.
הודעות ותקשורת
פורטל ללא הודעות הוא חצי עבודה. אנו מגדירים:
- אירועי דוא"ל (
CEventType,CEvent::Send): שינוי סטטוס הזמנה, התקרבות למועד תשלום, מחירון חדש - הודעות Push דרך מודול
pull(אם קיימת אפליקציה ניידת) - פיד פעילות בחשבון הדילר—Highload block
dealer_eventsעם סמני קריאה/לא קריאה
אינטגרציה עם CRM
אם היצרן משתמש ב-Bitrix24, פורטל הדילרים מסתנכרן עם CRM:
- רישום דילר חדש → יצירת חברה ב-CRM (
crm.company.add) - הזמנת דילר → עסקה ב-CRM המקושרת לחברה
- שינוי סטטוס עסקה → שינוי סטטוס הזמנה בפורטל דרך webhook
החיבור מיושם דרך Bitrix24 REST API, עם אחסון מזהי ישויות CRM בשדות חברה מותאמים אישית.
מה כלול בעבודה
- ניתוח ועיצוב: אב טיפוס, מפרט טכני
- פיתוח מערכת תפקידים ואימות
- תמחור בכל הרמות (הנחות, מחירי חוזה, מבצעים)
- חשבון אישי לדילר עם היסטוריית הזמנות ומסמכים
- אינטגרציה עם 1C דרך CommerceML או REST
- בדיקות והעלאה לשרת ייצור
- הדרכת עובדים ומסירת גישה
- תמיכה באחריות למשך 6 חודשים
לוחות זמנים
| שלב | משך |
|---|---|
| ניתוח ועיצוב | 2–3 שבועות |
| מערכת תפקידים ואימות | 2–3 שבועות |
| תמחור (כל הרמות) | 2–4 שבועות |
| חשבון אישי לדילר | 3–5 שבועות |
| אינטגרציה עם 1C | 3–6 שבועות |
| ניהול מסמכים וכספים | 2–3 שבועות |
| בדיקות | 2–3 שבועות |
סה"כ: 14–24 שבועות. השונות נקבעת על ידי עומק אינטגרציית 1C ומספר כללי העסק המותאמים אישית בתמחור. אנחנו יכולים להעריך את הפרויקט שלכם ביום אחד—צרו קשר לייעוץ.
דוגמה: איך קיצרנו את זמן עיבוד ההזמנות פי 3
עבור לקוח עם 50 דילרים, ביצענו אוטומציה של תמחור וניהול מסמכים. בעבר, הזמנה לקחה שעתיים לעיבוד; עכשיו זה 5 דקות. זה הביא לחיסכון משמעותי. פנו אלינו כדי להשיג תוצאות דומות.הזמינו פיתוח פורטל דילרים, ואנחנו נבחן את התהליכים הנוכחיים שלכם. זה יעזור להעריך במדויק את לוח הזמנים ואת היקף העבודה.