הגדרת תשלומים למוכרים ב-1С-Битрикс: היכן החישוב נשבר
הגדרת תשלומים ב-1С-Битрикс נשברת לא בשלב שבו «הכסף יצא», אלא קודם לכן — שם סטטוס ההזמנה וסכום התשלום חיים בשתי תמונות מצב בלתי תלויות של נתונים. ההזמנה עברה ל«הושלמה», אבל חישוב העמלות למוכרים עדיין רואה אותה במצב הקודם.
משם מופיעים תשלומים למוכרי המרקטפלייס בגין הזמנות שכבר בוטלו, או להפך — המוכר ממתין שבוע לזיכוי, אף שהקונה כבר קיבל את הסחורה.
נקודת כשל טיפוסית שנייה — מרשם שמנוהל ידנית בטבלאות. עמלה לפי קטגוריה, הנחה על חשבון המוכר, משלוח בתשלום, ניכויי מבצע ולוגיסטיקה מחושבים לפי נוסחה בראש של המנהל, ולא בקוד. עם כמה מוכרים זה עובד, עם עשרות — זה יוצר שגיאה שיטתית בחישובים במרקטפלייס, שמגלים רק בעקבות תלונה.
החזרים וניכויים מגיעים אחרי שהתקופה נסגרת. החזר חלקי, מחלוקת על פריט, ביטול לאחר משלוח — כל אלה משנים את הסכום של תשלום שכבר נוצר, ובלי מנגנון היפוך במרשם נשארת יתרה שלילית או כפולה.
בנפרד — החיבור לשירות תשלומים. התשלום יזום, אישור לא התקבל, הפעולה נתקעה בין מערכות; שליחה חוזרת של המרשם מובילה להעברה כפולה. נפרט איך זה נסגר: מרשם אחיד כמקור אמת, חישוב לפי אירועי הזמנה, תשלומים אידמפוטנטיים והתאמה מול דוחות של שירות התשלומים.
מה נותנת מערכת התחשבנויות מנוהלת עם המוכרים
מערכת מנוהלת נבנית על אירועי הזמנה, ולא על ייצוא מטבלאות: תשלום, משלוח, החזר וביטול יוצרים רשומה במרשם ההתחשבנויות עם קישור למוכר, לפריט ולתקופה. בצד 1С-Битрикс אלה מטפלי יצירת הזמנה בתוספת שכבת כללי חישוב משלנו — עמלה, לוגיסטיקה וניכויים מחושבים פעם אחת ובאופן ניתן לשחזור. הרצה חוזרת של תשלום עבור אותה הזמנה לא יוצרת זיכוי נוסף.
התאמת חישובים עם המוכרים מפסיקה להיות משימה חד-פעמית בסוף החודש. הדוח נבנה אוטומטית לפי תקופה סגורה, והמוכר רואה שורה-שורה ממה נוצר הסכום: הזמנה, עמלה, ניכוי, החזר. אי-התאמה לא נעלמת בהתכתבות, אלא נרשמת כשורה עם סיבה ומטופלת לפני התשלום.
החשבונאות של החזרים וניכויים עובדת באותה היגיון. החזר מבטל זיכוי בפריט מסוים, ולא במקדם ממוצע לתקופה; קנס או ניכוי מקושרים לעילה ולתאריך. זיכוי שנוי במחלוקת נשאר גלוי בתקופה שלו — אי אפשר לאבד אותו, רק לא לסגור את התשלום.
תוצאה מדידה של אוטומציה של התחשבנויות — צמצום פעולות ידניות: תשלומים טיפוסיים יוצאים לפי לוח זמנים, וטיפול ידני נשאר רק בחריגים, ששיעורם יורד ככל שמכווננים את הכללים. התקופה נסגרת עם יתרה מאוזנת לכל מוכר, והנהלת החשבונות והמוכר עובדים עם גרסה אחת של המספרים, ולא עם שתי טבלאות.
דרכים לארגון תשלומים: השוואת גישות
אופן התשלומים למוכרים נבחר לפי שלושה פרמטרים: כמה נמענים יש במחזור אחד, באיזו תדירות יוצא הכסף ומי מאשר את הסכומים. דיווח ואזור אישי למוכר נבנים מעל הסכימה שנבחרה, ולכן עדיף לקבע את כללי החישוב לפני הפיתוח — שינוי תוך כדי תפעול שוטף יקר בהרבה.
להלן שלוש אפשרויות שמכסות את רוב המרקטפלייסים, עם תנאי התאמה ומגבלות של כל אחת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| תשלומים המוניים במרשם | עשרות נמענים, תשלומים פעם בשבוע או בחודש, הסכומים מאושרים בידי מנהל | המרשם נשלח לבנק בחלונות, הסטטוסים חוזרים באיחור; שורה שגויה אחת חוסמת את כל הקובץ; הרצה חוזרת דורשת התאמה |
| תשלומים אוטומטיים דרך שירות תשלומים | תשלומים תכופים, מאות ואלפי נמענים, הסכומים מחושבים במערכת | נדרשים נמענים מזוהים והסכם עם השירות; מגבלות וזמני זיכוי משלו; זיכויים שנויים במחלוקת נסגרים בתהליך נפרד |
| היברידי עם אישור | זרימה מעורבת: תשלומים קטנים וקבועים עוברים אוטומטית, גדולים ושנויים במחלוקת — ידנית | דורש ספי הסלמה ברורים ואחראי להחלטה; מחזור התשלום ארוך יותר, חלק מהפעולות נשארות ידניות |
בחירת סכימת החישובים נתקלת בתקרת הפעולות הידניות: כל עוד יש מעט מוכרים, מרשם פשוט יותר לתחזוקה ושקוף יותר להתאמה.
עם גידול מספר הנמענים, פעולות אוטומטיות דרך שירות תשלומים מורידות עומס מהנהלת החשבונות, והיברידי משמש כשלב מעבר — האוטומציה נכנסת, אבל השליטה על סכומים שנויים במחלוקת נשמרת.
שלבי העבודה: מביקורת חישובים ועד העברה לתמיכה
העבודה מתבצעת ברצף: כל עוד הלוגיקה הנוכחית של הזיכויים לא מנותחת, כל שינוי בכללי התשלום שובר סכומים שכבר סוכמו עם המוכרים. לכן אנחנו מתחילים בביקורת חישובים ומסיימים בנהלים שלפיהם החישובים ממשיכים להתקיים בלעדינו. להלן שלבי הגדרת התשלומים לפי הסדר שבו הם מתבצעים בפרויקט.
- ביקורת חישובי המרקטפלייס. מייצאים היסטוריית הזמנות, החזרים והתחשבנויות, מתאימים זיכויים מול מסמכי מקור, מתעדים אי-התאמות: החזרים כפולים, פריטים חסרים, עמלה מקטגוריה לא נכונה.
- תכנון סכימת הזיכוי. קובעים מהו הבסיס: מועד התשלום, סגירת ההזמנה או תקופת הניכוי; כיצד נלקחים בחשבון הנחות, משלוח, סליקה וקיזוז בגין תביעות.
- הגדרת כללים והרשאות. כללי חלוקה לפי מוכרים וקטגוריות, תפקידי מנהלים, מגבלות לתיקונים ידניים, תיעוד ביומן של כל שינוי בסכום.
- מסלול בדיקות לתשלומים. פורסים העתק של הקטלוג וההזמנות, מריצים תרחישים: החזר מלא וחלקי, ביטול לאחר משלוח, תשלום ביתרה שלילית.
- קבלה על נתונים אמיתיים. תקופת דיווח אחת מחושבת במקביל — בשיטה הישנה ובחדשה, מתאימים תוצאות לכל מוכר, אי-התאמות מטפלים עד לאפס.
- העברת החישובים לתמיכה. סכימת נתונים, נוהל סגירת תקופה, הוראות לפעולות טיפוסיות, נקודות בקרה וסדר חזרה ללוגיקה הקודמת.
תיעוד, נהלים ויומני פעולות בחישובים
חישובים עם מוכרים נשברים לא בקוד, אלא ברגע הבירור: לא ברור מי שינה סטטוס, על מה התבסס הזיכוי ולמה לשני מוכרים יש תנאים שונים עבור אותן הזמנות. לכן יחד עם מודול החישובים אנחנו מעבירים חבילת תיעוד, שלפיה התמיכה והנהלת החשבונות סוגרות מצבים טיפוסיים בלי לפנות למפתח.
- סכימת זרימות כסף וסטטוסים — המסלול מתשלום הזמנה ועד תשלום סגור, כולל החזרים, ביטולים חלקיים וניכויים; לפיה רואים באיזה שלב הפעולה עלולה להיתקע.
- מטריצת הרשאות לתשלומים — מי יוצר את המרשם, מי מאשר, מי מתקן פרטי מוכר, מי רק קורא את היומן. היוזם והמאשר מופרדים: אדם אחד לא יכול להעביר תשלום בעצמו.
- נוהל תשלומים למוכרים — תדירות יצירת המרשם, כללי עמלות ועיגול, סדר עבודה עם יתרה שלילית וחוב של מוכר.
- יומן פעולות — לכל רשומה: יוזם, זמן, סכום בפירוט לפי הזמנות, עילה, תוצאה. הרשומות בלתי ניתנות לשינוי, תיקון נעשה בשורת היפוך.
- סדר התאמה מול דוח בנק — כיצד מותאמים זיכויים לחיובים בפועל ומאיזה סף אי-התאמה עוברת לטיפול ידני.
- נוהל טיפול בפעולות שנויות במחלוקת — זמני תגובה, אחראים, תבניות הודעות למוכר וסדר הסלמה.
- הוראות להנהלת חשבונות ולתמיכה — תרחישים טיפוסיים: סגירת תקופה, ייצוא מרשם, השהיית תשלומים למוכר לפי בקשה.
מקרה בוחן: מרקטפלייס צמצם אי-התאמות בחישובים עם המוכרים
מרקטפלייס על 1С-Битрикс עם כמה מאות מוכרים: התשלומים עברו לפי מרשם שנאסף ידנית מדוח עמלות, החזרים ולוגיסטיקה. אי-התאמות צפו כבר אחרי ההעברה — המוכר קיבל סכום שלא תאם את ההתאמה שלו עצמו, ופנה לתמיכה. תקופת החישוב נסגרה ב-8–12 ימי עסקים, וחלק ניכר מהפעולות דרש תיקון ידני.
מה שינו
מערכת החישוב קושרה לסגירת מסמכים: כל עוד דוח העמלות, ההחזרים והלוגיסטיקה לא מאוחדים למרשם אחד, התשלום לא נוצר. כל זיכוי וניכוי קיבלו קישור למסמך מקור, ולכן אי-התאמה נראית לפני העברת הכסף, ולא אחריה. דוחות התאמה ופירוט זיכויים מיוצאים אוטומטית לאזור האישי של המוכר — שני הצדדים רואים אותה תמונה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| אי-התאמות לא סגורות בתקופה | עשרות, הצטברו עד סוף החודש | בודדות, נסגרות בתוך יממה |
| סגירת תקופת חישוב | 8–12 ימי עסקים | 1–2 ימים |
| פעולות עם תיקון ידני | כשליש מהמרשם | פחות מ-5% |
| פניות מוכרים בנושא זיכויים | עיקר עומס התמיכה | ירדו פי כמה |
התמיכה הפסיקה לפרק חשבון והחלה לעסוק בשאלות מהותיות. אותו מערך התאמה לאי-התאמות עובר לכל סכימת תגמולים — ננתח איך זה נסגר עבור הקטלוג וכללי התשלום שלכם.
במה שונה תשלום אוטומטי ממרשם ידני?
מרשם ידני הוא קובץ עם זיכויים, שאותו מנהל אוסף מדוחות ומעלה לבנק. כל עוד יש מעט מוכרים, הסכימה עובדת: התקופה נסגרת מהר, וסכומים שנויים במחלוקת מתוקנים לפני הייצוא. אבל עם הצמיחה, כל נקודת מכירה חדשה וכל החזר מוסיפים שורה שמישהו חייב להתאים ידנית.
תשלום אוטומטי מחשב עמלה, ניכויים והחזרים בעצמו, יוצר הוראת תשלום ושולח אותה לפי לוח זמנים. סגירת התקופה מתקצרת מימים לשעות, ואי-התאמה נראית ביומן הפעולות עוד לפני שהכסף יצא למוכר. תשלום כפול או החזר שלא נלקח בחשבון הופכים לחריג, ולא לסיפור קבוע.
הסיכונים של מרשם ידני נראים בעיקר בתמיכה למוכרים. מחלוקת על תשלום חסר מתבררת בהתכתבות ומותאמת לפי ייצואים, וכל פנייה גוזלת זמן של מנהל והנהלת חשבונות. האוטומציה מספקת למוכר היסטוריית זיכויים וניכויים, ולכן השאלה נסגרת בתשובה מתוך האזור האישי.
עלות הבעלות על התהליך גם היא שונה. מצב ידני זול יותר בהתחלה, אבל דורש משאב אנושי קבוע ומחזיק את הסיכון אצל עובד אחד שמנהל את הטבלה. אוטומציה היא הגדרה חד-פעמית של כללי חלוקה ונוהל תשלומים, ומכאן והלאה גדל ההיקף, לא מספר הפעולות.
תשלומים ידניים למוכרים נשארים מוצדקים אם יש מעט מוכרים וכל סכום מאושר בידי אדם; בזרימה סדירה הבחירה בסכימת חישובים נוטה לאוטומציה.
ספקות טכניים: אינטגרציות, החזרים ופעולות חוזרות
תשלום למוכר הוא שרשרת: חישוב לפי הזמנות שהושלמו, בדיקת ניכויים, יצירת מרשם והעברתו לשירות תשלומים. אנחנו מתכננים את החיבור כך שלכל פעולה יהיה מזהה בלתי ניתן לשינוי וסטטוס חד-משמעי — אז האינטגרציה עם שירות התשלומים לא תלויה במהירות התגובה של המערכת החיצונית.
עבור מרקטפלייס על 1С-Битрикс קריטי שמערכת החישוב תדע להריץ מחדש אירועים: תשלום חוזר בעת תקלה, תשלום שבוטל, החזר לאחר תשלום שכבר בוצע. להלן שאלות שנשאלות לרוב לפני תחילת העבודה.
מה יקרה אם שירות התשלומים לא אישר את הפעולה?
המרשם לא מסומן כמבוצע, התשלום נשאר בסטטוס בעיבוד וחוזר לפי לוח זמנים עם אותו מזהה. השירות החיצוני מזהה את החזרה ולא מבצע חיוב כפול — המוכר מקבל תשלום אחד בדיוק.
איך החזרים וניכויים נכנסים לחישוב של המוכר?
החזר מקטין את הסכום של תקופת החישוב הבאה, ולא «שורף» את מה שכבר שולם. ניכוי — עמלה, משלוח, קנס — מופיע כשורה נפרדת במרשם עם סיבה, והמוכר רואה פירוט לכל הזמנה.
מה משתנה כשמחליפים סטטוס של מוכר בחישובים?
הסטטוס שולט רק בהשתתפות במרשמים: בבדיקה, פעיל, מושהה. היתרה שנצברה לא נשרפת, אלא מוחזקת עד בירור, והיסטוריית הפעולות נשמרת וניתנת לשחזור בכל רגע.
איך נלקחת בחשבון הספציפיקה המיסויית של המוכרים?
סטטוס המוכר — עצמאי, עוסק מורשה, תאגיד — קובע את הרכב מסמכי הסגירה ואם מנוכה מס בעת התשלום. התרחיש מוגדר בכרטיס המוכר, ומערכת החישוב מציבה אותו אוטומטית.
נדון בסכימת החישובים שלכם עם המוכרים
כדי לחזור עם הערכת עבודה על החישובים ותוכנית הטמעה, נדרשת האריתמטיקה האמיתית שלכם, ולא תיאור כללי של התהליך. נדון בסכימת החישובים בפגישת אבחון: מה נבהיר כדי שההערכה תתבסס על היקף הפעולות בפועל ומגבלות החשבונאות, ולא על ממוצעים.
בדרך כלל מספיק שיחה עם הנהלת החשבונות ואיש טכני בתוספת גישה להעתק בדיקה. נתעד:
- כללי זיכוי: עמלה לפי קטגוריות, משלוח, קנסות, החזרים וביטולים — היכן הכללים האלה חיים היום ומי משנה אותם.
- תפקידי תרחישי תשלום: מי משלם למוכר — הפלטפורמה או שותף סליקה, האם נדרשת חשבונאות נפרדת ורזרבה להחזרים.
- היקף פעולות: כמה מוכרים, תשלומים בתקופה וימי שיא, איזה חלק מהחישובים עדיין נעשה ידנית.
- מגבלות מערכת החשבונאות: תצורת 1С, תרשים חשבונות, סנכרון עם האתר, סגירת תקופה ודרישות למסמכי סגירה.
- תחום אחריות: מי יוצר וחותם על המרשם, איך מטפלים באי-התאמות ובזיכויים שנויים במחלוקת.
- דיווח למוכר: מה הוא רואה באזור האישי ואילו מסמכים מקבל — מזה תלוי נפח הפניות לתמיכה.
בהמשך, הגדרת התשלומים למרקטפלייס מתפרקת לשלבים עם תוצאה ברורה בכל אחד. תארו את המשימה — נחזור עם הערכה ותוכנית הטמעה של החישובים.