מודול הזמנה סיטונאית ביטריקס: היכן נשבר תרחיש ה-B2B
מודול ההזמנה הסיטונאית ביטריקס נשבר לא בחלון הראווה, אלא בחישוב מחדש של הסל: רכיב טיפוסי מחשב מחיר לפי פריט בודד, בעוד שהסיטונאי מרכיב הזמנה מעשרות שורות עם כללים שונים. ברגע שנכנסים לתמונה הנחות אישיות, כפילות אריזה וסף לפי נפח, החישוב הסטנדרטי מתחיל לסטות ממה שהמנהל מאשר ידנית. משם הפער גדל כמפולת שלגים — בחשבונית, בהזמנה, במשלוח.
נקודת הכשל השנייה היא המלאי. הקטלוג, המחסן והנהלת החשבונות חיים במערכים נפרדים, הסנכרון מתבצע לפי לוח זמנים, והסיטונאי רואה מוצר שכבר אינו קיים. המנהל תופס זאת בשיחת טלפון, הלקוח — בסירוב למשלוח.
לכך מתווספים מסגרות ותשלומים דחויים: בלעדיהם ההזמנה יוצאת לעבודה, ואחר כך מתברר שהקונה חרג ממסגרת האשראי או עובד ללא תשלום מראש.
המחיר של צווארי בקבוק כאלה נמדד לא בשגיאות, אלא בשעות של מחלקת המכירות. חישוב ידני מחדש, התאמת מלאי, תיאום תשלומים דחויים בדואר — כל אלה חוזרים על עצמם בכל הזמנה גדולה ואינם מתרחבים: ככל שיש יותר סיטונאים, כך יש יותר עבודה ידנית על אותה הכנסה. פורטל B2B על ביטריקס מפסיק לפרוק את המנהלים מעומס ומתחיל להעמיס עליהם.
אנחנו מפרקים כיצד זה נסגר: היכן עובר הגבול בין הסל למערכת החשבונאית, כיצד מוציאים את חישוב המחירים והמסגרות, ומה צריך להיות באזור האישי של הסיטונאי כדי שההזמנה תורכב ללא מעורבות המנהל.
מה נותן מודול ההזמנה הסיטונאית של Битрикс ואיך לבחור מצב
מה משתנה בנתונים
מודול ההזמנה הסיטונאית של Битрикс מבטל את העברת ההזמנות הידנית בין האתר למערכת החשבונאית. בפועל זה ניכר בשלושה מדדים: שיעור ההזמנות שהושלמו ללא מעורבות מנהל, הזמן מאישור ועד הוצאת חשבונית ומספר אי-ההתאמות בין המלאי בחלון הראווה לזה שבמערכת החשבונאית.
אצל לקוחות עם זרימה של כמה עשרות הזמנות ביום הערך הראשון בדרך כלל עולה ל-80–90%, השני מתקצר משעות לדקות, והשלישי יורד לאפס, כי המלאי והמחירים נמשכים מהמערכת החשבונאית ולא מתוקנים ביד.
מצבי עבודה של ההזמנה הסיטונאית
המצב קובע היכן נמצאת הלוגיקה של המחירים והמלאי. בסנכרון לפי לוח זמנים האתר עובד על מטמון מקומי של הקטלוג ומסתנכרן עם המערכת החשבונאית במנות — זה עמיד לאי-זמינות של המערכת החשבונאית, אך המחירים והמלאי מפגרים בפער של מרווח הסנכרון.
בסנכרון ברגע הבקשה האתר פונה למערכת החשבונאית לקבלת מחיר מעודכן עבור הלקוח והנפח — הנתונים תמיד עדכניים, אך נוצרת תלות בזמינותה. מצב היברידי מחזיק מטמון ומעדכן אותו נקודתית לפי אירועים, ובכך מסיר את שתי המגבלות.
פונקציונליות סטנדרטית לעומת מודול
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פונקציונליות מובנית עם התאמות | מחירון אחד, לוגיקת הנחות פשוטה | אין מטריצת מחירים לפי נפח, תנאים אישיים ומגבלות; ההתאמות מתנגשות עם עדכונים |
| מודול נפרד עם סנכרון | כמה מחירונים, מחירי חוזה, מגבלות | דורש נוהל סנכרון ובקרת אי-התאמות |
| אזור אישי חיצוני עם אינטגרציה | לקוחות גדולים עם מערכת חשבונאית משלהם | יקר יותר בתחזוקה, נדרש סנכרון סטטוסים |
מה נותנת האוטומציה של מכירות סיטונאיות
האוטומציה של מכירות סיטונאיות סוגרת פעולות חוזרות: חישוב מחיר מחדש לפי נפח וחוזה, בדיקת מגבלה וחוב, שריון מלאי, הפקת חשבונית והודעה ללקוח. המנהל מתערב רק במקרים לא שגרתיים, ולא בכל הזמנה.
1С-Битрикс מספק אפיק סנכרון ואירועים מוכנים שעליהם נבנה המודול — ולכן האינטגרציה עם 1С אינה הופכת לפרויקט נפרד.
שלבי הטמעת מודול ההזמנה הסיטונאית
הטמעת מודול ההזמנה הסיטונאית אינה מתחילה בקוד, אלא בניתוח האופן שבו הקטלוג והמחירים פועלים כיום. אם ב-Bitrix כבר קיימות הצעות מסחריות, סוגי מחירים וכללי הנחה, מודול ההזמנה הסיטונאית נבנה מעליהם — אחרת תיווצר מערכת קטלוג מקבילה שנייה שתצטרך סנכרון ידני.
לכן הצעד הראשון הוא ביקורת קטלוג Bitrix: בוחנים את מבנה המדורים, את שיוך המאפיינים לאינפובלוקים, כפילויות של פריטים ואת האופן שבו נקבע כיום המחיר עבור קבוצות קונים שונות.
מכאן העבודה מתקדמת בשלבים, כאשר כל שלב נשען על התוצאה של השלב הקודם.
- ביקורת הקטלוג והמחירים הנוכחיים. מתעדים אילו סוגי מחירים והנחות כבר מוגדרים, היכן המחירים מוגדרים ידנית והיכן הם מגיעים מ-1C. התוצר — מפת נתונים: אילו מאפיינים ומדריכים המודול יקרא וישנה.
- תכנון לוגיקת הסיטונאות. מגדירים רמות קונים, כללי חישוב מחדש של מחירים לפי נפח, כמויות מינימום וכפולות אריזה. הלוגיקה מתוארת לפני הקוד — כך ניתן לבדוק אותה על הזמנות אמיתיות, ולא לאחר ההשקה.
- הגדרת החלפה עם 1C. מתאמים אילו ישויות עוברות למערכת החשבונאית ומה חוזר ממנה: יתרות, מחירים, סטטוסים של הזמנות. ההחלפה נבנית על המנגנון הסטנדרטי, כדי שהייצוא לא יישבר בעת עדכון הקטלוג.
- פיתוח וחיבור המודול. המודול מותקן כרכיב נפרד, מבלי לפגוע בחלק הציבורי של הקטלוג. סל הקניות והשלמת ההזמנה הסיטונאית פועלים לפי התבניות שלהם, ותרחישי הקמעונאות נשארים ללא שינוי.
- בדיקות ההזמנה הסיטונאית. מריצים תרחישים: הזמנה מתחת לכמות המינימום, חישוב מחדש של המחיר בעת שינוי כמות, עבודה בו-זמנית של כמה מנהלים, ייצוא חוזר ל-1C. בנפרד בודקים את ההתנהגות בעת אי-התאמה ביתרות.
- הדרכה ומסירת המודול ללקוח. מוסרים הרשאות, תיאור של לוגיקת המחירים והוראות למנהלים. מראים כיצד לשנות כללי סיטונאות ללא מפתח.
- תמיכה לאחר ההשקה. את מחזור ההזמנות הראשון מלווים בתשומת לב מוגברת: משווים סכומים ב-Bitrix וב-1C, מאתרים אי-התאמות על נתונים אמיתיים.
רצף כזה מספק תוצאה צפויה: לוגיקת המחירים נבדקת לפני הפיתוח, ההחלפה עם 1C אינה משכפלת נתונים, ואת מודול ההזמנה הסיטונאית ניתן לפתח מבלי לכתוב מחדש את הקטלוג. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי שלבים.
במה שונה הזמנה סיטונאית מהזמנה קמעונאית ב-Bitrix?
הזמנה קמעונאית ב-Bitrix היא מחיר קבוע מהקטלוג, תשלום מיידי ומשלוח מהמחסן. הזמנה סיטונאית בנויה אחרת: המחיר תלוי בהסכם עם הלקוח, ולא בחלון הראווה, ואותו מוצר עולה differently עבור קונים שונים.
לכן מודול ההזמנה הסיטונאית של Bitrix אינו עושה שימוש חוזר בסל הקמעונאי, אלא פועל מעליו כמעגל נפרד — עם כללי התמחור, המגבלות ומסלול האישור שלו.
ההבדל המרכזי — מחירים לפי הסכם. עבור כל צד מתקשר מוגדר סוג מחיר המחובר לתנאי האספקה: נפח, דחיית תשלום, הנחה אישית. הקטלוג מספק מחיר בסיס, והמודול מחשב אותו מחדש לפי כללי ההסכם ברגע ביצוע ההזמנה, ולא בחלון הראווה. הסל הקמעונאי אינו יודע לעשות זאת — הוא פועל עם מחיר אחד למוצר.
השכבה השנייה — כפילות אריזה ומגבלות. סיטונאות מזמינים לא ביחידות בודדות: המוצר הוא כפולה של קופסה, משטח או מנה מינימלית, ועל הפריט חל מלאי מינימלי שאינו יורד. המודול בודק את כפילות האריזה ואת הנפח המינימלי בשלב ההזנה, ומונע ביצוע הזמנה שהמחסן לא יוכל להרכיב. בקמעונאות אין מגבלות כאלה.
השכבה השלישית — אישור בקשות. הזמנה סיטונאית לעתים רחוקות יוצאת לעבודה מיד: המנהל בודק מלאים, מסגרת אשראי ודחיית תשלום, ולאחר מכן מאשר או מתקן את ההרכב. הבקשה חיה בסטטוסים — טיוטה, באישור, מאושרת — ורק המאושרת ממשיכה הלאה.
כאן נכנסת התפקיד של 1С בהזמנה סיטונאית. הבקשה המאושרת מיוצאת ל-1С כמסמך מימוש, שבו חלים עליה ההסכם, דחיית התשלום וההתחשבנות ההדדית. בחזרה מגיעים מלאים, מחירים וסטטוס תשלום — חלון הראווה והנהון החשבונאי אינם מתפצלים. הסל הקמעונאי אינו עובר ב-1С: שם התשלום והמשלוח סגורים על האתר.
מקרה בוחן: כיצד מודול ההזמנה הסיטונאית ביטל את החישוב הידני
הלקוח — חברה סיטונאית עם מלאי של כמה אלפי פריטים ו-1С משלה. המנהלים הרכיבו הזמנה ידנית: הורידו מחירון, השוו מלאי, חישבו הנחה לפי טבלה, והעבירו פריטים לחשבונית. הזמנה ארכה 40-60 דקות, ופערי מחירים צצו כבר בשלב המשלוח.
מה היה לפני ההטמעה
שגיאות במחירים היוו כ-8% מהשורות: המנהל לקח מחירון מיושן או לא יישם הנחה מדורגת לפי נפח. הסנכרון עם 1С פעל לפי לוח זמנים פעם בשעה, ובמקרה של תקלה נפל בשקט — המלאי והמחירים התפצלו, והשחזור ארך עד שעתיים של השוואה ידנית. סוג הכשל היה תמיד אותו אחד: הזמנה על נתונים לא מעודכנים.
מה שינו
מודול ההזמנה הסיטונאית ביטריקס הרכיב אזור אישי לסוחר: הלקוח בונה בעצמו סל לפי טבלת המחירים שלו, רואה מלאי וכפילות אריזה, וההנחה מחושבת תוך כדי לפי כללים מ-1С.
הסנכרון הועבר לסכימה מבוססת אירועים עם תור ועיבוד אידמפוטנטי — שליחה חוזרת לא מכפילה פריטים, ותקלה נרשמת בלוג עם נקודת המשך. לבדיקת מחירים הוספנו סכום ביקורת לכל שורת הזמנה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן הרכבת הזמנה | 40-60 דקות | 5-8 דקות |
| שיעור שגיאות במחירים | ~8% מהשורות | <0.5% |
| שחזור סנכרון עם 1С | עד שעתיים ידנית | דקות, אוטומטית |
| סוג הכשל | הזמנה על נתונים לא מעודכנים | נסגר בבקרת גרסת מחירון |
1С-ביטריקס בשילוב עם 1С מכסה גם את הקטלוג, גם את החישוב וגם את הסנכרון — אבל רק כאשר לוגיקת המחירים חיה במקור אחד, ולא משוכפלת בממשק ובמערכת החשבונאית.
ספקות לגבי תאימות, מיגרציה והרשאות גישה — בואו נדון במשימה
לפני ההתחלה, לקוחות שואלים לרוב את אותו הדבר: האם מודול ההזמנה הסיטונאית ישבור את המחירים הנוכחיים, המחסנים והחוזים עם הלקוחות.
אנו עונים באופן ענייני: המודול מותקן כהרחבה נפרדת ואינו כותב מחדש את הליבה — כללי ההנחות הקיימים, סוגי המחירים והשיוכים למחסנים ממשיכים לפעול, והתרחיש הסיטונאי מתחבר מעליהם כפרופיל נפרד.
אם באתר כבר קיימות התאמות עצמאיות של סל הקניות, אנו תחילה ממפים את התלויות ורק לאחר מכן נוגעים בקוד.
מה אם הנתונים כבר נצברו בלוגיקה הישנה? המיגרציה מתבצעת בשני שלבים: תחילה מעבירים את מאגרי הנתונים — לקוחות, חוזים, מחירים אישיים ויתרות מלאי, — מאמתים סכומי ביקורת לכל קבוצה, ורק לאחר מכן מעבירים את עיבוד ההזמנות לתרחיש החדש. הענף הישן נשאר פעיל עד לאישור שהפערים אפסיים.
כיצד מבצעים rollback? כל שלב — commit נפרד עם נקודת חזרה: ההרחבה מושבתת בפקודה אחת, מסד הנתונים חוזר לתמונת מצב מלפני המיגרציה, וההזמנות ממשיכות להתקבל במתכונת הקודמת. ה-rollback אינו דורש השבתה ואינו מאבד הזמנות שכבר בוצעו.
האם המודול יתאים לגרסה שלנו ולהתאמות הנוכחיות?
את התאימות בודקים לפני תחילת העבודה: בוחנים את ענף הליבה, המודולים המותקנים, שינויי התבנית והחלפת נתונים עם 1С. אם משהו מתנגש — מתעדים זאת בדוח ומציעים פתרון עוקף, ולא "נטפל בזה אחר כך". את ההחלפה עם 1С בודקים על עותק של מסד הנתונים, כדי לא לגעת בסביבת העבודה.
הלקוח מקבל לידיו לא "מודול מוכן", אלא ערכה שלמה שלפיה הצוות יוכל לתחזק אותו:
- תצורות המודול עם תיאור כל פרמטר וערכי ברירת המחדל;
- תרשים הקשרים: סל הקניות, סוגי מחירים, מחסנים, חוזים, החלפת נתונים עם 1С;
- מדיניות הרשאות ותפקידים — מי מהמנהלים רואה ומשנה מה;
- נוהל המיגרציה ותוכנית rollback שלב-אחר-שלב עם נקודות חזרה;
- תיעוד המודול: התקנה, הגדרה, תקלות אופייניות ומה לעשות;
- יומן הרצות בדיקה עם תוצאות אימות הנתונים.
תארו את המשימה שלכם — נחזור עם הערכה, תוכנית עבודה ורשימה של מה שנדרש מצדכם.
לוחות זמנים להטמעת מודול הזמנה סיטונאית לפי שלבים
לוחות הזמנים אינם תלויים בנפח הקוד, אלא במידת המהירות שבה מצליחים להסכים על כללי התמחור ומטריצת ההנחות — זה בדרך כלל צוואר הבקבוק. להלן לוח זמנים אופייני לעבודה על מודול הזמנה סיטונאית עבור Битрикс, שאותו אנו מדייקים לאחר ניתוח תצורת הקטלוג, המחסנים והחוזים עם הלקוחות שלכם.
השלבים מתבצעים בחפיפה חלקית: בזמן שהליבה נסגרת בסביבת בדיקות, ניתן כבר לכוונן את הסנכרון עם 1С על עותק של מסד הנתונים. לכן לוח הזמנים הכולל להטמעה לעיתים רחוקות מורכב מסכום שורות הטבלה — בדרך כלל הוא קצר ב-20-30%.
בנפרד אנו מקצים זמן להתאמות לאחר הקבלה הראשונה: סיטונאים אמיתיים כמעט תמיד מבקשים תיקונים בתרחיש ההזמנה המהירה, ומוטב להקצות אותם בלוח הזמנים מאשר למתוח את ההשקה. תוכנית הטמעה מדויקת עם תלויות בין השלבים תימסר לאחר שנראה את מבנה הקטלוג שלכם ואת כללי העבודה עם סוחרים.