מודול הזמנה סיטונאית ביטריקס: היכן הסל נשבר
הסל הסיטונאי נשבר לא בשלב ביצוע ההזמנה, אלא קודם לכן — כאשר מחירים, רזרבות ומגבלות מחושבים במקומות שונים ואינם מתיישבים זה עם זה.
מנגנון החישוב מחדש של מחירים לפי מחיר בסיס אחד אינו עובד כאן: אצל הסיטונאי המחיר תלוי בחוזה, בנפח האצווה ובהיסטוריית ההזמנות המצטברת, ולכן מודול הזמנה סיטונאית ביטריקס חייב לחשב את העלות לפי רמות, ולא לפי ההנחה האחרונה שהוחלה.
הכשל הטיפוסי הראשון — חישוב מחדש של מחירים בעת שינוי כמות. הלקוח מוסיף פריט, הסל מחשב מחדש את השורה, אך אינו מחשב מחדש את הסכום הכולל לפי החוזה, ובשלב ביצוע ההזמנה הסכום אינו תואם לזה שהמנהל ראה.
השני — רזרבת מלאי: הסל הסיטונאי מחזיק נפחים גדולים, והמחסן מוסר אותם להזמנה אחרת, משום שהרזרבה נקבעת ברמת הפריט ולא ברמת המחסן והאצווה. השלישי — מגבלות: דחיית תשלום, מסגרת אשראי ואצווה מינימלית נבדקות ברגע האישור ולא ברגע ההוספה, וההזמנה יוצאת לביצוע בחריגה.
כאב נפרד — משלוח חלקי. כאשר ההזמנה מתפצלת למספר אספקות, הסטטוסים, הרזרבות ומסמכי הסגירה חייבים לנוע בסנכרון, אחרת היתרה בהזמנה מחושבת פעמיים, והלקוח מקבל חשבונית על סחורה שכבר נשלחה.
את כל זה נפרק בהמשך — כיצד מודול הזמנה סיטונאית סוגר חישוב מחדש של מחירים, רזרבות, מגבלות ומשלוחים חלקיים ברמת הלוגיקה, ולא כפתרונות מאולתרים בתבנית.
מה נותן המודול המעובד של הזמנה סיטונאית
המודול המעובד של הזמנה סיטונאית ב-Bitrix משנה לא את הממשק, אלא את עצם הלוגיקה של ביצוע ההזמנה: הסל מחשב מחירים וזמינות לפי רמת הלקוח בצד השרת, ולא מדביק אותם באמצעות סקריפטים בדפדפן.
בזכות זה מהירות ביצוע הזמנה של סל גדול עולה פי כמה — הפריטים מחושבים מחדש באופן מקובץ, בלי טעינת הדף מחדש על כל שינוי בכמות.
שיעור ההזמנות המוצלחות עולה במקומות שבהם קודם הלקוח נטש את ביצוע ההזמנה: המודול של הזמנה סיטונאית ב-Bitrix מציב אוטומטית רמות מחיר חוזיות, מחסן וכפילות אריזה, ולכן למנהל אין צורך לבדוק ידנית כל שורה.
תיקונים ידניים לאחר שליחת ההזמנה מצטמצמים — שגיאות אופייניות (מחיר מרמה לא נכונה, פריט שאינו במלאי, כמות שאינה כפולה של האריזה) נחסמות בשלב ההזנה, ולא צפות בחשבונית.
אפקט נפרד — צפיות עבור המנהלים: ההזמנה מגיעה כבר עם רמת מחיר ותפוסה נכונות, ולכן הטיפול מתנהל לפי תרחיש אחד, ולא לפי שיחת טלפון עם הלקוח על כל שורה שנויה במחלוקת. להלן נבחן כיצד זה נסגר ברמת האינטגרציה עם 1С והגדרת רמות המחיר.
דרכים למימוש הזמנה סיטונאית: השוואת גישות
המנגנון המובנה של Bitrix מכסה את התרחיש הבסיסי: סל קניות, ביצוע הזמנה, קישור לפרופיל הקונה. הבעיה מתחילה במקום שבו הסיטונאות דורשת את שלה — מחירונים לפי חוזה, מנה מינימלית, כפילות אריזה, דחיית תשלום. ככל שמתרחקים מהקמעונאות, כך יותר הגדרות מובנות הופכות לפתרונות מאולתרים.
התאמה אישית של הרכיב היא הדרך המהירה ביותר כאשר לוגיקת הסיטונאות נכנסת לתבנית עיצוב אחת או שתיים. מודול נפרד מוצדק אם כללי התמחור והמגבלות חיים ב-1С וצריכים לחול על כל נקודות הכניסה: האתר, האזור האישי, המנהל. שירות חיצוני מחברים כאשר ההזמנה עוברת למערכת חשבונאית זרה ו-Bitrix נשאר חלון ראווה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מנגנון מובנה | קמעונאות עם אלמנטים של סיטונאות, הנחות טיפוסיות | אין מנה מינימלית, כפילות, מחירים לפי חוזה |
| התאמה אישית של הרכיב | סיטונאות בתרחיש עיצוב אחד | התיקונים משוכפלים בעת עדכון התבנית, הלוגיקה מפוזרת |
| מודול נפרד | כללי מחיר עצמאיים, מגבלות, אינטגרציה עם 1С | דורש תכנון ותמיכה, לוקח יותר זמן להטמיע |
| שירות חיצוני | ההזמנה חיה במערכת חשבונאית חיצונית | תלות במערכת חיצונית, עיכובי סנכרון |
הבחירה נקבעת לא לפי נפח הקוד, אלא לפי המקום שבו חי הכלל. אם המחיר והמגבלות מחושבים ב-1С — מודול עם חילוף אמין יותר מהתאמה אישית של התבנית: הכלל משתנה במקום אחד, ולא בכל רכיב.
שלבי יישום מודול ההזמנה הסיטונאית
יישום מודול ההזמנה הסיטונאית מתחיל לא בקוד, אלא בביקורת: בוחנים כיצד בנויים כעת המחירים וההנחות, היכן מאוחסנים המלאי, מי קונה ובאילו תנאים. בשלב זה מתברר אילו כללים יהיה צורך להעביר למערכת, ואילו כדאי לבנות מחדש — אחרת המודול רק יקבע את הכאוס הנוכחי במחירונים.
- ביקורת תהליכים ונתונים. מפרקים את הקטלוג, קבוצות הקונים, מטריצות ההנחות, הדחיות והמגבלות. מתעדים אילו כללים מחושבים ב-1С ואילו צריכים לפעול בצד האתר, והיכן כיום יש אי-התאמות ביניהם.
- סכמת האינטראקציה. מתכננים את החילוף: אילו ישויות מסונכרנות, באיזו תדירות, מה קורה בעת קונפליקט בנתונים. קובעים כיצד מתבצעת ההזמנה — סל קניות, הזמנה מהירה לפי מק"טים או העלאת רשימה בקובץ.
- הגדרת המודול. מגדירים סוגי מחירים ושיוך לקבוצות קונים, ספי הנחות וכלליהן, סכום הזמנה מינימלי, כפילות אריזה, מגבלות דחייה. עבור לקוחות קבועים — תנאים אישיים והיסטוריית רכישות באזור האישי.
- אינטגרציה עם מערכת הנה"ח. מקשרים הזמנות, מלאי וסטטוסי תשלום עם 1С, מגדירים ייצוא קטלוג ומחירים, טיפול בשגיאות חילוף ושליחה חוזרת בעת תקלה.
- בדיקה בתרחישים אמיתיים. מריצים מקרים טיפוסיים ומקרי גבול: הזמנה גדולה עם הנחות משולבות, מוצר עם מלאי אפס, שינוי מחיר בין ביצוע ההזמנה לתשלום, ביטול פריט. משווים את התוצאה ב-1С עם מה שהקונה רואה.
- מסירה והדרכה. מוסרים גישות, הוראות למנהלים ולקונים, מראים היכן לצפות ביומן החילוף וכיצד להגיב לאי-התאמות.
לאחר ההשקה, בשבועות הראשונים מלווים את החילוף ואת כללי ההנחות — בזרימת הזמנות חיה צצים מצבים שלא היו בנתוני הבדיקה. תארו כיצד בנויים אצלכם המכירות הסיטונאיות — נחזור עם הערכה ותוכנית עבודה.
מה הלקוח מקבל לידיו
אנחנו מוסרים לא "מודול מוכן", אלא ערכה שלמה שלפיה הצוות שלכם יוכל להפעיל אותו ולפתח אותו ללא תלות בנו. כל מה שמתואר להלן מתועד במאגר הפרויקט ובוויקי שלו, ולא נשאר בהתכתבות.
- קונפיגורציות של המודול: קובצי הגדרות של קבוצות מחירים, כללי חישוב מחדש של הנחות, ספי הזמנה מינימלית ושיוך למחסנים — עם הערות המסבירות איזה פרמטר משפיע על מה.
- תרשימי תקשורת: דיאגרמות של זרימות נתונים בין האתר, 1С וניהול המלאי — מה מסתנכרן ובאיזה סדר, היכן נקודות הכשל וכיצד הן מטופלות.
- מדיניות הרשאות: מטריצת תפקידים ללקוחות סיטונאיים — מי רואה מחירי רכש, מי מבצע הזמנה, מי מאשר מסגרות; בנפרד כללים עבור מנהלים ועבור משתמש אינטגרציה של החלפת נתונים.
- תיעוד: תיאור מבנה המודול, נקודות ההרחבה וסדר העדכון עם יציאתן של גרסאות חדשות של הפלטפורמה.
- נהלי הפעלה: סדר הפעלת סנכרון מלא, פעולות במקרה של אי-התאמה ביתרות, כללים לחזרה לקונפיגורציה קודמת.
- הוראות למשתמשים: כיצד מנהל בודק הזמנה, כיצד לקוח חוזר על רכש קודם, מה לעשות במקרה של פריט שנדחה.
- סט תרחישי בדיקה: בדיקות על הזמנות סיטונאיות טיפוסיות, כולל מקרי קצה בכמות ובמחיר.
בנפרד אנחנו מוסרים יומן שינויים ורשימת ההתאמות שהחלטנו במכוון לא לבצע בגרסה הראשונה — כדי שתבינו את גבולות הפתרון ותוכלו לתכנן את הפיתוח. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית.
מקרה בוחן: כיצד הזמנה סיטונאית הואצה פי 3
הלקוח — מפיץ של כימיקלים לבנייה עם מגוון של אלפי פריטים וצבר קבלנים קבועים. המנהלים קיבלו הזמנות סיטונאיות באופן ידני: הלקוח שלח רשימה במייל או במסנג'ר, המנהל בדק מק"טים, חישב מחדש מחירים לפי טבלת ההנחות שלו והזין את ההזמנה ל-1С.
בהזמנה גדולה של 80-120 שורות זה ארך עד 40 דקות, ופערים במק"טים ובכפילות האריזה צפו כבר בשלב הליקוט.
1C-Bitrix כבר שימש כבסיס לקטלוג, ולכן לא הוכנסה מערכת נפרדת — הורחב המתאר הקיים.
מה שינו
הרכבנו מודול להזמנה סיטונאית: אזור אישי עם מחירון אישי ומטריצת הנחות, העלאת הזמנה בקובץ וחזרה על הזמנות קודמות בקליק אחד. המודול עצמו בודק מק"טים, כפילות אריזה ומלאי, מחשב מחדש מחירים לפי הסכם הלקוח ומעביר מסמך מוכן ל-1С דרך סנכרון — ללא העברה ידנית.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן עריכת הזמנה של 100 שורות | ~40 דק' | ~13 דק' |
| שיעור הזמנות עם שגיאה במק"ט או במחיר | 18% | 2% |
| פעולות ידניות של המנהל להזמנה | 9-11 | 2 |
זמן העריכה הצטמצם פי שלושה — בעיקר בזכות העובדה שהלקוח מרכיב את ההזמנה בעצמו, והמחירים והמלאי מוצבים בזמן אמת. השגיאות נעלמו לא מפני שהמנהלים became יותר קשובים, אלא מפני שבדיקת המק"ט והכפילות נמצאת כעת בצד המודול, ולא בצד האדם. שתי הפעולות הידניות שנותרו — אישור הנחה לא סטנדרטית ואישור דחיית תשלום.
חודשיים לאחר ההשקה, שיעור ההזמנות שנערכו דרך האזור האישי הגיע ל-70% מכלל הזרימה הסיטונאית, והשאר — הזמנות מכרז גדולות שהמנהלים מנהלים ידנית במודע.
במה שונה הזמנה סיטונאית מהזמנה קמעונאית ב-Bitrix?
הזמנה קמעונאית ב-Bitrix היא פריט אחד או סל מקושר למחסן אחד ולמחיר אחד מהקטלוג. הזמנה סיטונאית פועלת לפי כללים אחרים: המחיר תלוי בנפח ובהסכם עם הלקוח, הכמות מוגבלת במנה מינימלית ובכפילות אריזה, והמשלוח כמעט לעולם אינו מתבצע במלואו ברגע ביצוע ההזמנה.
קו פרשת המים הראשון — רמות מחירים. בקמעונאות המחיר הוא אחד, לכל היותר הנחה במבצע. בסיטונאות על אותה נומנקלטורה פועלת רשת מחירים: בסיסית, סוחר, מפיץ, ובנוסף תנאים אישיים לפי הסכם ספציפי.
המודול צריך להציב את רמת המחיר הנדרשת לפי פרופיל הקונה ולחשב מחדש את הסל בעת שינוי הנפח, ולא לתת מחיר אחד לכולם.
השני — מנה מינימלית וכפילות. סיטונאי אינו יכול להזמין שלוש יחידות אם האריזה היא בת שתים עשרה, והסכום המינימלי למשלוח קשור להסכם. הבדיקות מופעלות בשלב ההוספה לסל, ולא בשלב ביצוע ההזמנה, אחרת הלקוח נודע על המגבלה ברגע הכי לא מתאים.
השלישי — שריון ומשלוחים חלקיים. שריון קמעונאי מתקיים עד לתשלום ומוסר אוטומטית. בסיטונאות הסחורה נשמרת לשריון עבור בקשה ספציפית במחסן, יכולה להישלח בחלקים לפי הגעת הסחורה, והיתרה מועברת לאספקה הבאה. בלי זה המחסן ומחלקת המכירות עובדים לפי נתונים שונים.
הרביעי — ניהול מסמכים. מכירה קמעונאית נסגרת בקבלה, סיטונאית — בחשבונית, תעודת משלוח, חשבונית מס והתאמה, שחייבות להתאים להזמנה ב-Bitrix. לכן מודול סיטונאי מתוכנן יחד עם סנכרון ל-1С, ולא כתוספת מעל הסל הקמעונאי.
ספקות טכניים נפוצים
מודול הזמנה סיטונאית אינו סקריפט נפרד מעל הסל, אלא שכבת לוגיקה בין הקטלוג, המחירים ומערכת החשבונאות. לכן הספקות של הלקוחות בדרך כלל זהים: לא "האם זה ישבור את האתר", אלא "איך זה יתנהג בזרימת הזמנות אמיתית ומה יקרה בעת עדכון הפלטפורמה".
להלן מה שעולה לרוב בשלב ההערכה, עם תשובות טכניות.
האם המודול מתנגש עם עדכוני הליבה ותוספים אחרים?
הלוגיקה מועברת למודול נפרד עם נקודות הרחבה דרך אירועים, ולא על ידי עריכת הליבה או טלאים לתבנית. עדכון הפלטפורמה אז אינו מוחק את ההתאמה, והמנגנונים הסטנדרטיים ממשיכים לפעול.
לפני כל עדכון אנו מריצים רגרסיה בסביבת בדיקה: ביצוע הזמנה סיטונאית, חישוב מחדש של מחירים לפי רמות, ייצוא למערכת החשבונאות. אם עדכון משנה את ההתנהגות של API תלוי — אנו מתאימים את המודול לפני העלאה לסביבת הייצור.
איך המודול עובד עם 1С והאם הוא לא ייצור חשבונאות כפולה?
מקור האמת לפריטים, מלאי ומחירים — מערכת החשבונאות, האתר מקבל נתונים בסנכרון ואינו שומר אותם כ"אמת שנייה". ההזמנה נשלחת ל-1С כמסמך, הסטטוסים חוזרים בחזרה, ולכן המחסן והאתר אינם סוטים זה מזה.
הסנכרון מתבצע במנות עם עיבוד אידמפוטנטי: ייצוא חוזר אינו מכפיל פריטים, ופער במלאי נראה בלוג, ולא צף אצל הלקוח בעת ביצוע ההזמנה.
האם הקטלוג עם עשרות אלפי פריטים וסלים סיטונאיים יעמוד בכך?
צוואר הבקבוק של הזמנה סיטונאית — לא הקטלוג, אלא חישוב מחדש של מחירים והנחות על סל גדול. אנו מחשבים מחירים לפי רמות באופן מרוכז, שומרים במטמון ספרי עזר ואינדקסים של שאילתות, ופעולות כבדות מעבירים למשימות רקע. סל עם מאות שורות מחושב מחדש ללא טעינת הדף מחדש, והביצוע אינו חוסם קונים אחרים.
איך מוגדרות הרשאות הגישה ואיך מוגנים המחירים?
מחירים ותנאים סיטונאיים משויכים לחברת הקונה ולחוזה שלה, ולא לסשן הדפדפן, ולכן החלפת נתונים בצד הלקוח אינה מועילה. בדיקות הרשאות וחישוב מחדש של מחירים משוכפלים בשרת בכל פעולה.
הגישה לאזורי הסיטונאות חסומה לאורחים ולמשתמשים קמעונאיים, ופעולות של מנהלים על הזמנות של אחרים נרשמות בלוג.
אם נותרו שאלות לגבי התצורה שלכם — תארו את המשימה: אילו רמות מחירים, איך בנוי הסנכרון עם 1С ואיזו זרימת הזמנות צפויה. נחזור עם הערכה ותוכנית עבודה.
בואו נדון במשימה שלכם להזמנה סיטונאית
כדי שההערכה של מודול ההזמנה הסיטונאית תהיה מדויקת, ולא "ממוצעת בשוק", אנחנו צריכים להבין את הספציפיקה שלכם: איך נוצרת המחיר לסיטונאי, מאיפה מגיעים היתרות, מי ואיך מאשר את ההזמנה.
ככל שהנתונים הראשוניים konkretיים יותר, כך יהיו פחות הנחות בתוכנית והלוחות זמנים יהיו צפויים יותר. להלן — מה כדאי לברר ואיזה נתונים להכין לפני השיחה.
מה מבררים בהתחלה
- איך מתקבלות כיום הזמנות סיטונאיות: ידנית על ידי מנהל, דרך דואר, ייצוא לטבלה או שכבר קיים אזור אישי ראשוני.
- מאיפה מגיעים המחירים וההנחות: סוג מחיר נפרד ב-1С, סולם מצטבר, תנאים חוזיים לפי לקוח.
- איך מחושבות היתרות והכפילות: לפי מחסן, לפי משלוחים, עם שריון להזמנה או בלעדיו.
- מי מאשר את ההזמנה ובאיזה שלב: מנהל, כספים, מסגרת חוב לפי גורם מתקשר.
- איך ההזמנה עוברת לחשבונאות: סנכרון עם 1С בזמן אמת, לפי לוח זמנים או דרך קובץ.
- תפקידים והרשאות: סיטונאי, מנהל, נציג אזורי — לכל אחד סט הרשאות משלו ונראות מחירים משלו.
מה להכין לשיחה
- דוגמה להזמנה סיטונאית אמיתית: איך היא נראית מהבקשה ועד המשלוח, עם כל האישורים.
- צילומי מסך או תיאור של האזור האישי הנוכחי, אם קיים, ורשימה של מה שלא מתאים בו.
- תרשים הסנכרון עם 1С: איזו קונפיגורציה, מה כבר מוגדר, אילו ישויות מסונכרנות.
- כללי התמחור וההנחות כפי שמחיל אותם מחלקת המכירות.
- מגבלות בלוחות זמנים ובשלביות: מה צריך להשיק ראשון, מה יכול לחכות.
לסיכום השיחה נחזור עם הערכה ותוכנית: נפרק את ההיקף לשלבים, נקבע מה נכלל בכל שלב, ונסמן נקודות שבהן יידרש ההחלטה שלכם. תארו את המשימה — נברר את הפרטים ונכין הצעה מותאמת לתהליך שלכם.