תוכנית שותפים מבוססת ביטריקס: היכן החשבונאות נשברת
תוכנית שותפים מבוססת ביטריקס נשברת לא בשלב הרעיון, אלא במפגש בין שלוש תת-מערכות: זיהוי המשתמש, שמירת הקישור "מי הביא את מי" וחישוב התגמולים. כל עוד התעבורה קטנה, הסכימה נשענת על מילה טובה והצלבות ידניות.
ברגע שמספר השותפים עובר לעשרות, וההזמנות מתחילות להתבצע במספר מטבעות ובערוצים שונים, צפים קישורים אבודים, חיובים כפולים ואי-התאמות עם הנהלת החשבונות.
הסיבה השכיחה ביותר — קישור השותף חי ב-cookie או בסשן. המשתמש הגיע דרך קישור עם תג, נרשם כעבור יום ממכשיר אחר, ביצע הזמנה כעבור שבוע — והקשר "שותף → לקוח" כבר אבד.
אם מזהה השותף לא נרשם במסד הנתונים ברגע המגע הראשון ולא אושר בעת ההרשמה, שחזור השרשרת בדיעבד הוא כמעט בלתי אפשרי: נותרים רק לוגים של שרת האינטרנט, שגם הם כבר עברו רוטציה עד אז.
נקודת הכשל השנייה — רגע החיוב. כאשר הטריגר הוא אירוע "ההזמנה שולמה", ולא "ההזמנה הושלמה ולא הוחזרה", התוכנית מתחילה לשלם עבור רכישות שהלקוח יחזיר.
המצב ההפוך — חיוב לפי עובדת המשלוח ללא אידמפוטנטיות: קריאה חוזרת של המטפל בעת ניסיון חוזר של מערכת התשלומים יוצרת תגמול שני עבור אותה הזמנה. חשבונאות השותפים וחישוב התגמולים חייבים להישען על מפתח ייחודי של הפעולה, אחרת רשומות כפולות בלתי נמנעות.
שכבת הבעיות השלישית — אי-התאמה עם הנהלת החשבונות. תגמול לשותף הוא לא רק רשומה בטבלה, אלא התחייבות עם תאריך, סכום ובסיס. אם המודול מחשב בונוסים בלוגיקה אחת, והנהלת החשבונות מקבלת ייצוא בלוגיקה אחרת, הפער מצטבר חודשים ארוכים וצף בעת סגירת התקופה. נבחן כיצד זה נסגר ברמת הארכיטקטורה, ולא באמצעות טלאים במטפלים.
מה מספקת תוכנית שתוכננה כראוי
תוכנית שותפים שתוכננה כראוי היא בראש ובראשונה מודל חישוב דטרמיניסטי, ולא אוסף של מבצעים.
כאשר שיוך השותף (הפניה) נרשם ברגע ההרשמה ונשמר כישות בלתי ניתנת לשינוי במסד הנתונים, שיעור השיוכים האבודים יורד מ-8–12% לשברירי אחוז: המחלוקת "מי הביא את הלקוח" מפסיקה להתעורר, מכיוון שהמקור נרשם פעם אחת ואינו נכתב מחדש בדיעבד.
מהירות סגירת התקופה היא ההשפעה המדידה השנייה. אם התגמול מחושב לפי אירועי הזמנה (תשלום, משלוח, סגירת עסקה), ולא לפי איחוד טבלאות ידני, התקופה נסגרת בתוך שעות במקום שבועות. הנהלת החשבונות מקבלת מרשם חיובים מוכן, מתואם עם הזמנות וסטטוסי תשלומים, ללא התאמה ידנית של שורות.
ההשפעה השלישית — צמצום סוג החיובים השנויים במחלוקת. כאשר כללי תשלומים רב-רמתיים, תקופות החזקה וביטולים בעת החזרת הזמנה מתוארים בקוד, ולא בתקנון מילולי, נעלם שכבה שלמה של פניות "למה לא חויב" ו"למה נוכה". לכל חיוב יש הפניה לאירוע שיצר אותו — וזו השקיפות שהשותף בודק בעצמו, ללא פניות לתמיכה.
אנו מתכננים מודולים כאלה על 1С-Битрикс תוך התחשבות במודל ברירת המחדל של הזמנות וסל קניות, ולכן החיובים אינם סוטים מהמכירות בפועל, והדיווח לפי שותפים מיוצא בצורה שבה הנהלת החשבונות מקבלת אותו.
דרכי מימוש: מודול, התאמה, שירות חיצוני
הבחירה בין מודול מוכן, התאמת הליבה, שירות חיצוני ופיתוח מותאם אישית נקבעת לא לפי טעם, אלא לפי היכן נמצאים נתוני ההזמנות וכיצד מחושבים התגמולים.
אם קשרי הפניות וסטטוסי התשלומים חייבים להיות מתואמים עם הזמנות, סל וסטטוסי תשלום — הלוגיקה מחויבת לפעול בתוך הפלטפורמה, אחרת ייווצרו אי-התאמות בין המערכות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מודול מוכן לתוכנית הפניות | סכימה טיפוסית: קישור, קופון, אחוז מההזמנה | לוגיקת חישוב נוקשה, קשה להוסיף ריבוי רמות או תנאים משלך |
| התאמת הליבה | נדרשים כללים משלך: רמות, קטגוריות מוצרים, תשלומים נדחים | דורש עבודה זהירה עם עדכונים, אחרת השינויים נמחקים |
| שירות חיצוני | ניתוח הפניות נדרש בנפרד מהפלטפורמה, מספר אתרים | נתוני ההזמנות מסונכרנים באיחור, סטטוסי התשלומים יוצאים מסנכרון |
| פיתוח מותאם אישית | מכניקה לא סטנדרטית: רמות שותפים, מגבלות, אינטגרציה עם מערכת הנהלת חשבונות | השקה ארוכה יותר, נדרשים תמיכה ותיעוד |
מודול מוכן סוגר את המשימה בתוך ימים ספורים, אך נתקל בתקרה ברגע שהכללים מפסיקים להיות טיפוסיים. התאמת הליבה מעניקה גמישות, אולם כל עדכון של הפלטפורמה דורש בדיקה שהשינויים אינם מתנגשים עם הגרסה החדשה. שירות חיצוני נוח לניתוח, אך אינו מתאים כמקור אמת יחיד לחישובי התגמולים.
פיתוח מותאם אישית מוצדק כאשר תוכנית ההפניות היא חלק מהמודל העסקי, ולא תוספת לחנות. אנו מתכננים את הסכימה לפי כללי חישוב ספציפיים, כדי שקשרים, סטטוסים ותשלומים יישארו מתואמים עם ההזמנות.
כיצד מתבצעת הטמעת תוכנית הפניות ביטריקס
הטמעת תוכנית הפניות מתחילה לא בקוד, אלא בביקורת הנהוג: כיצד נרשמות כעת הזמנות, היכן נשמרים קישורי לקוחות לשותפים, אילו סטטוסי תשלום נחשבים לבסיס לחישוב.
בשלב זה אנו מאתרים צווארי בקבוק — התאמות ידניות, כפילויות בקישורים, היעדר היסטוריית שינויים — וקובעים מה ניתן לעשות בו שימוש חוזר ומה יהיה צורך לבנות מחדש.
לאחר מכן אנו מתכננים את סכימת הנתונים: ישויות נפרדות לשותפים, מעברי הפניות, צבירות ותשלומים, קישורים להזמנות ולמשתמשים. הסכימה נבנית מלכתחילה עבור דיווח — כך שניתן יהיה לחשב מחדש את התגמול עבור כל תקופה ולהסביר כל נתון.
- ביקורת הנהוג הנוכחי של הזמנות, תשלומים וקישורי לקוחות לשותפים.
- תכנון סכימת הנתונים: שותפים, מעברים, צבירות, תשלומים, קישורים להזמנות.
- הגדרת כללי צבירה: אחוז, בסיס חישוב, מועדי קיבוע, תנאי ביטול.
- מימוש אזור אישי לשותף עם סטטיסטיקת מעברים ותגמולים.
- בדיקת צבירות בתרחישים: תשלום חלקי, החזר, רכישה חוזרת, ביטול הזמנה.
- התאמת נתוני החישוב להזמנות בפועל וסגירת פערים.
- מסירה: תיעוד הכללים, הרשאות גישה, הדרכת העובד האחראי.
בנפרד אנו בודקים את התנהגות המערכת במקרי החזרים וביטולים — דווקא כאן נוצרות לרוב צבירות שנויות במחלוקת. בדיקת הצבירות מתבצעת על עותק של נתונים אמיתיים, כדי לראות לפני ההשקה כיצד הכללים מתנהגים בתשלומים חלקיים וברכישות חוזרות.
לאחר מסירת התוכנית נותר תקנון: מי משנה את הכללים, כיצד מתועדים התשלומים, היכן ניתן לראות את ההיסטוריה. תארו את סכימת הנהוג שלכם — נחזור עם הערכה ותוכנית הטמעה.
מה הלקוח מקבל לידיו לאחר ההשקה
השקת תוכנית הפניות היא לא רק קוד עובד, אלא גם מארז של חפצי אמנות שלפיהם הצוות שלכם יוכל לתחזק ולפתח את המערכת בלעדינו. אנו מעבירים הכול בצורה מובנית: מקונפיגורציה ועד לתקנונים, כדי שכעבור חצי שנה איש לא ישחזר את הלוגיקה מהזיכרון.
- תיעוד המודול — תיאור מבנה הנתונים, הקשרים בין משתמשים, שותפים וחיובים, וכן נקודות ההרחבה למשימות העתידיות שלכם.
- תקנון החיובים — כללי חישוב התגמולים, תנאי ההפעלה, סדר החישוב מחדש והסטורנו בעת החזרות וביטולי הזמנות.
- תרשים האינטגרציה — מפת האינטראקציה של המודול עם הזמנות, תשלומים, משתמשים ומערכות חיצוניות, כולל תורים ופעולות מושהות.
- הוראות לצוות — כיצד לפרוס את המודול בסביבת הבדיקה ובפרודקשן, כיצד להפעיל ולכבות את התוכנית, היכן לצפות בלוגים וכיצד לאבחן מצבים טיפוסיים.
- קונפיגורציה מוגדרת — רמות התוכנית הפעילות, שיעורים, תוקף קישור ההפניה והקוקי, מגבלות וכללי אנטי-פראוד בצורתם המוכנה.
- ממשק ניהולי — מדורים לניהול משתתפים, תיקון ידני של חיובים וייצוא דוחות לפי שותפים.
- מארז בדיקות — תרחישי בדיקה לחיוב, ביטול, רישום חוזר ומעבר בקישור של אחר, כדי שרגרסיה תיתפס לפני השחרור.
בנפרד אנו מתעדים את מסירת ההרשאות ואת סדר ההסלמה: מי מצד הלקוח אחראי על התוכנית ולמי מופנות שאלות בנוגע לאירועים. מארז כזה מסיר את הסיכון העיקרי — התלות באדם אחד ש"זוכר איך הכול בנוי כאן". תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
מקרה בוחן: כיצד צומצמו חיובים שנויים במחלוקת פי שלושה
הפרויקט — חנות מקוונת על 1С-Битрикс עם רשת שותפים: תוכנית ההפניות פעלה, אך החיובים חושבו "בעין" והתבססו על התאמות ידניות.
לפני הטמעת סכימת חשבונאות תקינה, מנהלים השקיעו בטיפול בחיובים שנויים במחלוקת כ-20 שעות בחודש, ושיעור העסקאות השנויות במחלוקת הגיע ל-18% מכלל העסקאות.
מה היה לפני
לוגיקת החיובים ישבה במטפלי ביצוע ההזמנה ולא התחשבה בהחזרות, ביטולים חלקיים ורכישות חוזרות דרך אותה קישורית הפניה. השותף ראה סכום אחד באזור האישי, והנהלת החשבונות ראתה סכום אחר בדוח, וכל התאמה הפכה להתכתבות.
בעיה נפרדת — מעברים "תקועים": אם הלקוח חזר דרך קישורית של מישהו אחר, התגמול עבר למשתתף הלא נכון.
מה שינו
הוצאנו את חישוב התגמולים למודול נפרד עם יומן אירועים: כל רכישה, החזרה וביטול נרשמים כרשומה נפרדת עם שיוך לשותף ולתקופה. החיוב מחושב לפי אירוע בלתי משתנה, ולא לפי מצב ההזמנה הנוכחי, ולכן זיכוי בגין החזרה אינו שובר תקופות שכבר נסגרו.
הוספנו כלל שיוך עם חלון והגנה מפני דריסה בקליק האחרון, ובאזור האישי של השותף הצגנו את אותו סכום כמו בדוח הנהלת החשבונות — מקור אחד.
מה נהיה
שיעור החיובים השנויים במחלוקת ירד מ-18% ל-6% — פי שלושה, והזמן להתאמות הצטמצם מ-20 ל-5 שעות בחודש. סגירת התקופה כעת דורשת הרצת דוח אחת במקום ייצוא ידני, והפערים בין אזור השותף להנהלת החשבונות נעלמו כקטגוריה. הסכימה עמדה בגידול רשת השותפים ללא שינוי הלוגיקה — כללי שיוך חדשים מתווספים בהגדרה, ולא בעריכת קוד.
במה שונה מודול מהתאמה אישית של הליבה?
מודול הוא חבילה נפרדת, המותקנת ב־/local/modules/ או /bitrix/modules/ ונרשמת דרך מנגנון החיבור הסטנדרטי. הליבה נשארת בלתי נגועה: עדכוני הפלטפורמה והפתרונות של צד שלישי מותקנים כרגיל, והלוגיקה של תוכנית ההפניות מתקיימת במרחב שמות מבודד. השבתת המודול היא פעולה אחת שאינה מותירה עקבות בקבצי המערכת.
התאמה אישית של הליבה היא עריכה של קבצי הפלטפורמה עצמה או של רכיבים בספריות המערכת. מהיר בהתחלה, אך כל עדכון הופך לבירור ידני של קונפליקטים: קבצים ששונו מסומנים ככאלה שנדרסו, העדכון או שאינו מותקן, או שמוחק את הלוגיקה שלכם.
לאחר מספר גרסאות, התמיכה בהתאמה אישית כזו עולה יותר מהמימוש המקורי, ויכולת העדכון של הפתרון יורדת לאפס.
הסיכונים של התאמה אישית של הליבה אינם מתגלים מיד. כבר התיקון הראשון של אבטחה או עדכון ראשי שובר את החישובים, והשחזור דורש השוואה ידנית של הקבצים ששונו — ובמקביל חלק מהשינויים עשוי היה כבר ללכת לאיבוד בעדכון הקודם. המודול מסיר את סוג הכשל הזה: העדכונים מותקנים כסדרם, והקונפליקטים מרוכזים בתוך חבילה אחת.
קיים גם נתיב ביניים — רכיב מותאם אישית או מטפל באירועים ללא עריכת הליבה. הוא מתאים ללוגיקה נקודתית, אך תוכנית הפניות מתעשרת בבונוסים, ברמות, בדוחות ובאינטגרציה עם הזמנות; ללא מבנה אחיד לוגיקה כזו מתפזרת על פני הפרויקט. המודול מספק ניהול גרסאות, מיגרציות ופריסה צפויה מראש על מספר אתרים בו־זמנית.
הקריטריון המעשי פשוט: אם הפתרון מתוכנן להתעדכן יותר מגרסה אחת — זה מודול. התאמה אישית של הליבה מוצדקת רק במקום שבו אין פיזית נקודות הרחבה סטנדרטיות, ומקומות כאלה אנו מתעדים במרשם נפרד עם תיאור של מה בדיוק נדרס ואיך זה מועבר בעת עדכון.
ספקות טכניים נפוצים לפני ההתחלה
לפני ההתחלה כמעט כל צוות שואל את אותה קבוצת שאלות: האם המודול ישבור את האתר הקיים, כיצד להעביר את הנתונים שכבר נצברו על שותפים, האם התשתית תעמוד בעומס והאם ניתן לסמוך על מנגנון החיובים. להלן — ניתוח של כל נקודה, בלי מילים כלליות.
האם המודול תואם לגרסת 1С-Битрикс שלנו ולרכיבים הנוכחיים?
המודול נבנה עבור ענף הליבה העדכני ואינו נוגע בקבצים הסטנדרטיים — כל הלוגיקה מופרדת למודול נפרד עם טבלאות ומטפלי אירועים משלו. אם בפרויקט כבר קיימים רכיבים מותאמים אישית של סל הקניות או ביצוע ההזמנה, אנו מתחברים אליהם דרך אירועים, ולא על ידי עריכת הקוד. המשמעות: עדכוני ליבה ומודולים של צד שלישי עוברים כסדרם, והלוגיקה של השותפים נשארת מבודדת.
מה יקרה לנתונים על שותפים שכבר נצברו?
הקשרים הקיימים «לקוח — מזמין» מועברים באמצעות סקריפט מיגרציה: תחילה הרצה על עותק של בסיס הנתונים, השוואת מספר הקשרים והיתרות, ולאחר מכן העברה לסביבת הייצור עם אפשרות שחזור במקרה של אי-התאמות.
את היסטוריית החיובים והתשלומים שומרים במלואה — השותפים אינם מאבדים את מה שהרוויחו, ואתם לא נדרשים להתנצל בפניהם לאחר ההשקה.
האם האתר לא יאט תחת העומס של חישובי השותפים?
החיובים וחישוב מחדש של הסטטוסים מבוצעים לא ברגע בקשת המשתמש, אלא באמצעות משימות מושהות לפי לוח זמנים. אזור השותפים מחזיר נתונים מטבלאות מוכנות מראש, ואין שליפות כבדות על כל היסטוריית ההזמנות.
עם גידול במספר השותפים מתווספים אינדקסים ומפוצלת תור העיבוד — האתר עבור הקונה עובד באותה מהירות כמו קודם.
כיצד מוגנים החיובים מפני מניפולציות והחלפות?
הקשר עם המזמין נרשם פעם אחת ומוגן מפני קישור חוזר, והחיוב מתבצע רק על הזמנה מאושרת ומשולמת. כל הפעולות נרשמות ביומן עם ציון המקור, ותיקונים ידניים של היתרה זמינים רק למנהל עם הרשאות ומשאירים עקבות בהיסטוריה. חיובים שנויים במחלוקת ניתן לבטל באופן נקודתי, בלי לחשב מחדש את כל התוכנית.
תארו את התצורה שלכם ואת הנתונים הנוכחיים על השותפים — נחזור עם הערכת תאימות, תוכנית מיגרציה ותרשים עומס בהתאם לתעבורה שלכם.
נדון במשימה שלכם בנושא תוכנית הפניות
כדי שההערכה תהיה מציאותית ולא "ממוצע שוק", אנחנו מפרקים את המשימה עד לשורה. חשוב לנו להבין איך אצלכם בנוי כיום החשבונאות של לקוחות והזמנות, היכן נשמרים הנתונים על ההפניות, אילו אירועים נחשבים ליעדיים ואיך מחושבת התגמול — אחוז מהסכום, תעריף קבוע או נקודות.
מזה נגזרת הארכיטקטורה של המודול: היכן לחשב את הצבירות, איך להגן מפני הפניות עצמיות וניפוח מלאכותי, איך לבצע תשלומים ולשקף אותם בדיווח.
בהמשך אנחנו בוחנים את האינטגרציות: החלפה עם 1С לפי פריטים, הזמנות והתחשבנויות, חיבור עם CRM, התראות למשתתפים, אזור אישי של המפנה עם סטטיסטיקה והיסטוריית צבירות. אם חלק מהתהליכים כבר אוטומטיים, נשתלב בלוגיקה הקיימת ולא נשבור אותה.
- ניתוח החשבונאות הנוכחית. בוחנים איך מוגדרים משתמשים, הזמנות ושותפים, היכן צווארי הבקבוק והכפילויות.
- קיבוע כללי התוכנית. רמות, תעריפים, תקופות חיים של קשר ההפניה, תנאי צבירה וקיזוז.
- תכנון סכמת הנתונים. טבלאות הפניות, צבירות, תשלומים, סטטוסים — תוך התחשבות בעומס ובגידול במאגר.
- אב טיפוס של התרחיש המרכזי. מעבר בקישור, הרשמה, הזמנה, צבירה — בודקים על נתונים אמיתיים.
- פיתוח המודול ופאנל הניהול. הגדרות התוכנית, התאמות ידניות, ייצוא דוחות, תפקידי גישה.
- אינטגרציות והחלפה. חיבור עם 1С ו-CRM, כדי שהצבירות והתשלומים יתאמו עם הנהלת החשבונות.
- בדיקות ומסירה. בודקים מקרי קצה, מכינים תיעוד ומכשירים את הצוות שלכם.
לאחר הניתוח נחזור עם הערכה לפי שלבים, תוכנית עבודה ורשימת סיכונים. אם במהלך הדיון נראה מסלול פשוט יותר — נאמר זאת ישירות, בלי לכפות נפח עבודה מיותר. תארו את המשימה בפורמט נוח, ואנחנו נחבר מהנדס שמוביל פרויקטים כאלה.