פיתוח מרקטפלייס רב-מוכרים: עמלות, KYB, ריבוי מטבעות

פיתוח מרקטפלייס רב-ספקים: היכן מתפרק החישוב

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

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

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

אי-הסנכרון בין המרשמים מצטבר תחילה בדוחות, אחר כך באמון המוכרים, ובשלב הזה הפלטפורמה מאבדת מגוון מוצרים.

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

מה נותן מודל מנוהל של עמלות ותשלומים דחויים

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

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

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

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

סכימות התחשבנות בין המוכר, הקונה והפלטפורמה

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

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

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

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

1. ביקורת סכימת ההתחשבנות. מפרקים כיצד מחושבות עמלות לפי קטגוריות, כיצד מתחלק הסכום בין המוכרים, כיצד עוברים החזרים והיפוכים, מי מתקן סכומים ביד ומדוע. בפלט — מפת אי-התאמות ורשימת המקומות שבהם המרשם מפסיק להתאים לדוחות ספק הסליקה.
2. עיצוב מודל ההתחשבנות. מתעדים חשבונות ורישום כפול, סדר שריון הכספים להזמנה, כללי חישוב מחדש בהחזרים ובסלים רב-מטבעיים: השער נלקח ברגע הפעולה, ולא ברגע התשלום, ולכן התוצאה אינה "שטה" בדיעבד.
3. הטמעת ליבת ההתחשבנות. רשומות מסומנות במפתח פעולה, ולכן קריאה חוזרת מצד הספק אינה יוצרת כפילות צבירה. לצד זה מציבים התאמה אוטומטית: חלק מהפערים נסגר מעצמו, והשאר עובר לתור בירור עם אחראי.
4. הגדרת בדיקת מוכרים ותשלומים. סטטוס הבדיקה קובע ישירות את הזכות לקבל תשלומים; מגבלות, הקפאה וסדר עדיפות התשלומים נקבעים בכללים, ולא בהחלטות ידניות של התמיכה.
5. תרחישי קבלה. מריצים מקרים בעייתיים לפני עלייה לאוויר: החזר חלקי של פריט אחד בהזמנה, ביטול לאחר משלוח, יתרה שלילית של המוכר, תיקון בדיעבד, אי-התאמה מול הספק. כל תרחיש — עם מצב מרשם צפוי.
6. מסירת נהלים והדרכת צוות הלקוח. מוסרים את סכימת החשבונות, נוהל תיקונים ידניים וטיפול בתקלות, סדר הסלמה; מעבירים הדרכה על פעולות אמיתיות, כדי שהתמיכה תסגור אי-התאמות טיפוסיות בעצמה.

לאחר העלייה לאוויר עוברים יחד את התקופה הסגורה הראשונה — לפי מדדי ההתאמה רואים היכן הכללים דורשים חידוד.

מארז האספקה: סכימות, מדיניות גישה, נהלים

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

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

כל מסמך מקושר לגרסת המערכת ומתעדכן יחד איתה — המארז לא מתיישן חצי שנה לאחר המסירה.

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

מה היה קודם

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

התמיכה ענתה שוב ושוב לאותה שאלה: "מדוע הסכום לתשלום נמוך מזה שבדוח שלי", ולכל שאלה כזאת נדרשו חצי שעה ומעלה לשחזור היסטוריית ההזמנה.

מה שינו

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

בדיקת המוכר הועברה לתהליך עם צ'ק-ליסט מסמכים וסטטוסים, ותשלומים במחלוקת הפכו למשימה עם מועד אחרון וקישור לרשומות במקום התכתבות במייל.

מה נהיה

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

מה לעשות אם המרקטפלייס כבר פועל על פלטפורמה מוכנה?

פלטפורמה מוכנה מביאה את האתר עד המכירות הראשונות: ויטרינה, קטלוג, סל, הזמנות, תשלומים בסיסיים. הגבול מגיע בדרך כלל בהתחשבנות — כשהספקים נספרים בעשרות, העמלה תלויה בקטגוריה, ומתווספים אליה ניכויים, החזרים, בדיקת ספקים ומטבע שני.

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

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

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

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

פעולות במחלוקת, החזרים והתאמה: ספקות טכניים

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

קושי נפרד הוא החזרים חלקיים ומחלוקות לאחר משלוח, כשהמוצר כבר אצל המוכר וההחלטה מתקבלת בבוררות של הפלטפורמה. להלן מה שמבהירים לרוב המהנדסים והפיננסים לפני תחילת הפיתוח של מרקטפלייס רב-ספקים.

כיצד נשלל סטטוס המוכר לאחר פעולות במחלוקת?

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

מה עם שערי מטבע אם המחלוקת נסגרת בתקופה אחרת?

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

נדון בסכימת ההתחשבנות ונחזור עם הערכה ותוכנית

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

תארו את היקף המוכרים: כמה פועלים עכשיו וכמה צפויים, כיצד מוסיפים חדשים, מי בודק מסמכים ובעלי שליטה. אם הפלטפורמה כבר פועלת, הוסיפו מה כואב — אי-התאמות ביתרות, תשלומים ידניים, ניכויים במחלוקת.

בתגובה אנחנו שולחים לא סיסמאות כלליות, אלא מסמך עבודה:

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

תארו את סכימת ההתחשבנות והיקף המוכרים — נחזור עם הערכה ותוכנית עבודה.