פיתוח לוח שותפים על 1C-Bitrix

פיתוח פאנל שותפים מותאם אישית על 1C-Bitrix

כאשר המחזור החודשי של חנות מקוונת עולה על 9–13 אלף דולר, ניהול שותפים ידני הופך לבלתי אפשרי. יש צורך בפאנל שותפים ייעודי המטפל ברישום, מעקב הפניות, עמלות רב-רמתיות ותשלומים אוטומטיים. בנינו מערכות כאלה עבור לקוחות עם מאות שותפים פעילים ואלפי הזמנות ביום. עם ניסיון של למעלה מ-10 שנים ויותר מ-40 פרויקטים מוצלחים של Bitrix, אנו מספקים פתרונות יציבים וניתנים להרחבה. פיתוח טיפוסי אורך בין 2 ל-4 חודשים, תלוי באינטגרציות.

כיצד פועלת מערכת השותפים המובנית של Bitrix ומהן מגבלותיה

מודול sale כולל את תת-המערכת "שותפים" (sale). תכונות בסיסיות: רישום שותפים דרך sale, יצירת קישורי הפניה עם \Bitrix\Sale\Affiliate, מעקב אחר קליקים והזמנות, חישוב עמלה באחוז קבוע, ורכיב bitrix:sale.affiliate.register לסטטיסטיקה.

מגבלות: הפניה חד-רמתית בלבד, עמלה קבועה ללא תנאים גמישים, ממשק מינימלי (ללא גרפים), אין ניהול תשלומים, ואין חומרים שיווקיים. עבור תוכנית שותפים אמיתית, המודול המובנה משמש כבסיס, אך יש להרחיב את הלוגיקה העסקית עם handlers וישויות מותאמות אישית.

רישום שותפים: מה צריך לקחת בחשבון

רישום שותפים שונה מרישום משתמש רגיל. השותף ממלא טופס מורחב: שם מלא או שם חברה, מספר עוסק מורשה (לחברות), תחום פעילות, ערוצי קידום ופרטי תשלום. הבקשה עוברת לאישור. המנהל בודק את הנתונים ומאשר או דוחה. עם האישור, השותף משויך לקבוצת "שותפים" ולרמה ראשונית.

יישום טכני: טופס מורחב באמצעות partner_id עם שדות bitrix:sale.affiliate.cabinet מותאמים אישית, handler מסוג bitrix:main.register שיוצר רשומה ב-highload-block של שותפים, והודעה למנהל.

בניית מערכת הפניות: מודלי ייחוס ויישום

השותף מקבל קישור ייחודי כמו UF_* או OnAfterUserRegister. מזהה השותף נשמר בקוקי עם אורך חיים הניתן להגדרה (בדרך כלל 30–90 ימים).

מודלי ייחוס:

המודול המובנה תומך רק בקליק אחרון. עבור מודלים אחרים, אנו יוצרים טבלת קליקים מותאמת אישית שמתעדת את כל השרשרת, ו-handler של https://site.ru/?partner_id=XXX מיישם את הלוגיקה הנדרשת. מערכת רמות מותאמת אישית יכולה להעלות את המרת השותפים פי 2–3 בהשוואה לזו המובנית.

קודי קופון הם חלופה לקישורי הפניה. השותף מקבל קוד ייחודי; הלקוח מזין אותו בעת התשלום. הקוד מקושר לשותף באמצעות כלל סל (https://site.ru/?ref=PROMO_CODE) ובמקביל מייחס את המכירה. למידע נוסף על מודלי ייחוס, ראו ויקיפדיה.

למה רמות שותפים חשובות

תוכנית רב-רמתית מניעה שותפים להגדיל נפחים. הרמות נשמרות ב-highload-block נפרד עם פרמטרים:

חישוב הרמות מתבצע באמצעות סוכן (OnSaleOrderPaid) – יומי או בכל הזמנה ששולמה. בעת שינוי רמה, השותף מקבל הודעה ואחוז העמלה מתעדכן להזמנות עתידיות.

מודלי תגמול נוספים: סכום קבוע לכל הזמנה (לשירותים), אחוז מההזמנה הראשונה + LTV של הזמנות חוזרות, בונוסי סף, ושיווק רב-רמתי (מיושם באמצעות \Bitrix\Sale\Discount רקורסיבי).

לוח המחוונים לשותף: מדדים וכלים מרכזיים

המסך הראשי מציג:

• סטטיסטיקה: קליקי הפניה (יומי/שבועי/חודשי), רישומי לקוחות שנמשכו, הזמנות (כמות, סכומים, סל ממוצע), שיעורי המרה (קליק → רישום → הזמנה), עמלות שנצברו, יתרה נוכחית.

הנתונים מצטברים ב-highload-block סטטיסטי. גרפים נבנים עם Chart.js או ApexCharts, נתונים נטענים דרך AJAX ל-controller מותאם אישית (\CAgent).

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

חישוב עמלות: מתשלום הזמנה ליתרה

החישוב מתבצע כאשר סטטוס ההזמנה משתנה ל"שולם" באמצעות ה-handler parent_partner_id. אלגוריתם:

1. זיהוי השותף דרך קוקי \Bitrix\Main\Engine\Controller או קוד קופון המקושר להזמנה.
2. טעינת הרמה הנוכחית ואחוז העמלה.
3. חישוב הבסיס: סכום ההזמנה בניכוי משלוח, קופונים ומע"מ (ניתן להגדרה).
4. צבירת העמלה ליתרה הפנימית של השותף.
5. אם שיווק רב-רמתי מופעל, צבירה רקורסיבית של עמלות לשותפים במעלה השרשרת עם אחוז פוחת.
6. יצירת רשומה ביומן הצבירה (highload-block: partner_id, order_id, amount, type, date).

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

ניהול תשלומים: מבקשה לתשלום

מערכת התשלומים משתמשת בגישת בקשות. השותף מגיש בקשת משיכה ברגע שמגיע לסף המינימלי (ניתן להגדרה). שלבים:

• השותף לוחץ על "משיכת כספים", מזין סכום ופרטי תשלום.
• הבקשה עוברת לאישור.
• המנהל בודק ומאשר.
• לאחר התשלום בפועל, הסטטוס משתנה ל"שולם".

עבור חברות, נוצרת חשבונית מתבנית, השותף חותם עליה, והנהלת החשבונות מעבדת את התשלום.

מתן חומרים שיווקיים

מדור עם:

• באנרים בפורמטים שונים עם קישורי הפניה מוטמעים (קוד HTML להטמעה).
• לוגו ומדריך מיתוג למיתוג משותף.
• תבניות דוא"ל.
• תיאורי מוצרים/שירותים ששותפים יכולים להשתמש בהם באתריהם.
• מצגות PDF.

החומרים נשמרים ב-infoblock המקושר לרמות השותפים. שותפים מתחילים רואים חומרים בסיסיים; רמות גבוהות יותר פותחות אפשרויות מתקדמות.

מלכודות נפוצות בפיתוח פאנל שותפים

• חוסר אימות קוקי – מעברים עלולים ללכת לאיבוד אם קוקי חסום.
• שאילתות highload לא אופטימליות עם שותפים רבים – השתמשו ב-tagged caching.
• התעלמות מהחזרות והיפוכים – מוביל לפערים חשבונאיים.
• אין תהליך אישור לבקשות תשלום – יוצר כאוס.

התהליך שלנו וציר הזמן

אנו פועלים בגישה מובנית:

1. איסוף נתונים – הבנת העסק שלך, נפחי שותפים, אינטגרציות.
2. ביקורת/ניתוח – סקירת הגדרות Bitrix קיימות וזיהוי פערים.
3. עיצוב – הצעת ארכיטקטורת פתרון, אבטיפוס ממשק, מודל נתונים.
4. הערכת עלות – מחיר קבוע לאחר ניתוח (ללא עלויות נסתרות).
5. פיתוח – בניית מודולים מותאמים, handlers ואינטגרציה.
6. בדיקות – בדיקות יחידה, בדיקות אינטגרציה, UAT עם שותפים לדוגמה.
7. השקה – פריסה, הדרכת מנהלים, ניטור.

ציר זמן: בדרך כלל 2 עד 4 חודשים מתחילת הפרויקט ועד העלייה לאוויר.

מקרה מהפרקטיקה שלנו

עבור רשת אלקטרוניקה גדולה עם 150 שותפים קיימים ומחזור חודשי של 45–65 אלף דולר, יישמנו תוכנית שותפים רב-רמתית. הלקוח ניהל תשלומים ידנית באמצעות גיליונות אלקטרוניים, מה שלקח יומיים לכל מחזור תשלום. אוטמטנו את כל מחזור החיים: רישום עם העלאת מסמכים, חישוב עמלות רב-רמתי, ובקשות תשלום משולבות עם 1C. תוצאה: זמן קליטת שותפים ירד מ-3 ימים לשעה אחת, והשותפים הפעילים גדלו ב-40% ברבעון הראשון. זמן עיבוד התשלומים ירד ל-4 שעות. תיעוד רשמי של מודול Bitrix sale: dev.1c-bitrix.ru.

צרו קשר כדי לדון בתוכנית השותפים שלכם. נעריך את הצרכים שלכם ונציע פתרון אופטימלי.