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