למה סכום הזמנה מינימלי ב-1С-Битрикс לא עובד
ההגבלה מוגדרת בהגדרות, התיבה מסומנת, הערך הוזן — אבל חלק מהפניות מתחת לסף בכל זאת יוצאות לטיפול. הסיבה היא שהבדיקה נמצאת במקום אחד, בדרך כלל בסל בעת ביצוע הזמנת B2B, והפניות מגיעות גם מטופס הזמנה מהירה, ממייל, משיחה ומעסקה שנוצרה ידנית על ידי מנהל. אף אחד מהנתיבים האלה לא יודע על סכום הזמנה מינימלי.
הסיבה השנייה — הסף מחושב מבסיס לא נכון. ללקוח סיטונאי יש מחיר משלו לפי סוג מחיר ולפי הקבוצה שלו, ולקמעונאי — משלו; הנחה, עלות משלוח או עיגול מורידים את הסכום מתחת לסף, והבדיקה מסתכלת על הסכום הראשוני.
סיפור נפרד — תנאי אספקה בסיטונאות, שבהם את הסף מחשבים לפי סכום בלי מס או בלי התחשבות בפריטים בהזמנה, ואז ההיגיון מתפצל ממה שהלקוח רואה בסל.
המחיר של פער כזה — עבודה ידנית של מנהלים: כל פנייה מתחת לסף צריך לפתוח, לחשב מחדש, לתאם ולבטל, והלקוח בינתיים ממתין לתשובה. חלק מהפניות מספיקות לצאת להרכבה, ומשם או משלוח בהפסד, או שיחה מביכה עם הקונה.
זה לא "שכחנו להפעיל אפשרות", אלא פער בין מקום הבדיקה לבין המקום שבו הפנייה באמת מופיעה. בהמשך מפרקים איך סוגרים את זה: איפה לשים את הבקרה כך שתופעל בכניסה, ואיך להפוך את סף ההזמנה הסיטונאית לאחיד בכל הערוצים.
מה נותן סף הזמנה מנוהל ללקוחות סיטונאיים
סף סכום הזמנה מינימלי ב-1С-Битрикс הוא לא תיבה בהגדרות המכירות, אלא מטפל אירועים של הסל ושל ביצוע ההזמנה. הבדיקה מתבצעת בצד השרת בעת חישוב מחדש של הסל, לפני יצירת ההזמנה, ולכן אין לעקוף אותה על ידי עריכת העמוד בדפדפן.
קל לטעות כאן: לחשב את הסכום עם מס או בלי, להתחשב במשלוח, לקחת סף להזמנה אחת או באופן מצטבר על פני תקופה.
סירוב קשיח לפי סכום חד-פעמי פוגע בסיטונאים קבועים שמשלימים את המגוון במשלוח שני באותו חודש. ההגדרה הנכונה — סף לפי סוג מחיר וקבוצת לקוחות, עם פנייה להיסטוריית ההזמנות של הלקוח על פני תקופה. אז ההגבלה מסננת פניות קמעונאיות קטנות בערוץ הסיטונאי, אבל לא מפריעה ללקוחות גדולים.
חשובה גם תגובת הממשק: במקום "ההזמנה בלתי אפשרית" הלקוח רואה כמה חסר עד לסף ומה אפשר להוסיף, ופנייה לא מלאה נשמרת כטיוטה. היגיון כזה 1С-Битрикс מאפשר לתאר בקוד, ולא בהתאמה לתבנית.
האפקט נמדד בשלושה מדדים: שיעור התיאומים הידניים של פניות, מספר ביטולי ההזמנות הסיטונאיות, ועומס מחלקת המכירות. לפני ההגדרה המנהל אישר ידנית כל פנייה קטנה; אחרי — עיקר הפניות נסגר כבר בשלב הסל.
הביטולים עוברים לשלב הסל במקום לשלב המשלוח: הלקוח מתקן את הרכב ההזמנה בעצמו, כל עוד הסחורה לא נאספה ולא נשלחה. העומס במחלקת המכירות מפסיק לגדול יחד עם מספר הפניות — הוא גדל רק יחד עם מספר העסקאות האמיתיות.
דרכים להגבלת הרכישה: כללים, בדיקה ידנית, מודול
את סף סכום ההזמנה המינימלי סוגרים בארבע דרכים. הבחירה נקבעת לא לפי נוחות ההגדרה, אלא לפי מידת ההומוגניות של זרם ההזמנות והאם יש לקוחות עם תנאים שונים.
טעות טיפוסית — לתלות את הכלל רק על כפתור ביצוע ההזמנה: אם הבדיקה לא מופעלת בחישוב מחדש של הסל לאחר שינוי כמות, הסף נעקף בשתי פעולות.
מה להשוות לפני הבחירה
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| כללי הסל המובנים | רף אחד משותף לכולם, זרם הומוגני | תנאים מורכבים (קבוצה, קטגוריה, אופן קבלה) נאספים מכמה כללים, ובשינוי ההזמנה נבדקות כל הנקודות |
| הגבלה לפי קבוצת לקוחות | סיטונאות וקמעונאות, מפיצים עם תנאים נפרדים | דורש סדר בסיגמנטציה: בשינוי קבוצה צריך לחשב מחדש את הסף ולעקוב אחרי הזמנות קודמות |
| מודול לבדיקת הסף | כמה ספים לפי אזור, מחסן או קטגוריה, נדרשת אבחון של הפעלות | יש לתחזק מודול צד שלישי ולבדוק אותו אחרי עדכוני הפלטפורמה |
| אישור ידני על ידי מנהל | הזמנות נדירות ולא שגרתיות, נדרשת גמישות | המועד תלוי בעומס של אדם, והלקוח לומד על הסירוב רק אחרי ביצוע ההזמנה |
גם שילוב עובד: סף קשיח בכללי הסל בתוספת אישור ידני לחריגים. הסף צריך להיבדק בביצוע ההזמנה, בחישוב מחדש של הסל ובהפקת ההזמנה — אחרת המנהל מקבל פנייה שהמערכת לא הייתה אמורה להעביר.
שלבי ההטמעה: אודיט כללים, סכימה, הגדרה, בדיקה
סף סכום ההזמנה המינימלי הוא לא הגדרה אחת, אלא שכבת כללים שמצטלבת עם מחירים, הנחות, חוזים והיגיון ביצוע ההזמנה. לכן מתחילים בפירוק תנאי המכירה הקיימים, ולא בעריכת תבנית הסל: אחרת ההגבלה מתנגשת עם מנגנון ההנחות וחלק מההזמנות מפסיק לעבור.
- אודיט של תנאי המכירה — מפיקים את כללי האספקה הקיימים לפי קבוצות לקוחות, סוגי מחירון וחוזים, ומוצאים מקומות שבהם המינימום כבר מוחזק ידנית על ידי מנהלים או באופן בלתי פורמלי.
- סכימת ההגבלות — קובעים למה הסף קשור (סוג מחיר, קטגוריית מוצר, אזור, ישות משפטית) ובאיזה שלב הכלל מופעל: סל, ביצוע הזמנה או חילוף הזמנות עם מערכת הנהלת החשבונות.
- תיאום הרמות — סף כללי, סף לפי קבוצות לקוחות, חריגים לפריטים שנמכרים ביחידות או במנות קטנות. כל חריג מקבל תנאי מפורש, ולא הסכמה בעל פה.
- הגדרת הסף — מממשים בדיקה בצד השרת, כדי שלא ניתן יהיה לעקוף את ההגבלה על ידי שליחה חוזרת של הטופס, ומציגים הודעה מובנת על הסכום החסר עם רמז להשלמה.
- בדיקה על סביבת בדיקות — מריצים תרחישים: לקוח מעל ומתחת לסף, סל משולב, הפעלת הנחה, ביצוע הזמנה חוזר, חילוף עם מערכת הנהלת החשבונות. בודקים לוגים והתנהגות בעת סירוב.
- מסירה והדרכה — תיעוד הכללים, פירוק מקרים שנויים במחלוקת עם מחלקת המכירות ותקנון: איך המנהל מבצע חריג אם הלקוח מתעקש.
סדר כזה משאיר עקבה: רואים למה הסף הוגדר דווקא כך ומה לשנות בעת בחינה מחדש של התנאים.
כללים, תפקידים ותקנות שנשארים בפרויקט
הפרויקט נסגר לא ברגע שהסף הופעל לראשונה, אלא כשיכול לשנות אותו אדם שלא השתתף בהגדרה. לכן המסירה כוללת לא רק מנגנון עובד, אלא גם שכבת כללים: איפה הסף נשמר, אילו קבוצות לקוחות הוא משפיע עליהן, מי רשאי לערוך אותו ואיך להחזיר את הערך הקודם.
- מפת כללים: ספים לפי קבוצות לקוחות וסוגי משלמים, עם סימון היכן ההגבלה מופעלת והיכן הופסקה במכוון.
- הגדרות קבוצות לקוחות: אילו קבוצות עוברות את הסף, אילו עוקפות אותו לפי חוזה, ובמה זה מאושר בהזמנה.
- סכימת טיפול בפניות: המסלול מבדיקת הסכום בסל ועד אישור המנהל והפקה למערכת הנהלת החשבונות, עם נקודות כשל.
- תפקידים והרשאות גישה: מי משנה את ערך הסף, מי רק קורא, מי רואה את היסטוריית השינויים וההתראות.
- תקנון שינוי הסף: בקשה, מאשר, חלון להכנסת השינוי, בדיקה חובה על סביבת בדיקות לפני העלאה.
- תיעוד להגבלת ההזמנה: נוסח ההודעות לקונה, תזכורת למנהל, רשימת קבלה לאדמין.
- סדר החזרה לאחור: איפה נמצאת העתקת ההגדרות הקודמות ואיך להחזיר אותן בפעולה אחת, אם הכלל הופעל לא כשורה.
את החבילה בודקים בתרחיש: מחליפים תפקיד, משנים את הסף, מבצעים הזמנה מתחת לרף ורואים אם ההתראות והיומן הופעלו. אם האדמין עובר את זה בלי רמזים, התיעוד מספיק.
מקרה בוחן: איך הסף לרכש סיטונאי פינה את מחלקת המכירות
הלקוח — ספק סיטונאי של חלקים — קיבל הזמנות דרך האתר על 1С-Битрикс, אבל סף סכום ההזמנה המינימלי חי רק בתקנון של המנהל. הלקוח אסף סל בכל סכום, שלח פנייה, ועובד פירק אותה ידנית: התקשר, הסביר את התנאים, הציע להוסיף פריטים או סירב. על פירוקים כאלה הלכה כמעט מחצית מהמשמרת של המחלקה, וחלק מהפניות בכלל לא הגיע למשלוח.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הפניות מתחת לסף | 38% | 6% |
| פירוקים ידניים בשבוע | 120 | 14 |
| זמן טיפול ממוצע בפנייה | 3 שעות 20 דקות | 35 דקות |
| שיעור הפניות שהגיעו למשלוח | 61% | 88% |
מה שינו בהגדרה
את הסף העבירו לרמת הסל וקשרו אותו לקבוצות קונים: לקמעונאיים — מינימום אחד, לסיטונאים חוזיים — אחר, לאיסוף עצמי — כלל נפרד. את הסל לא חוסמים באופן קשיח: הלקוח רואה כמה חסר ואילו פריטים הגיוני להוסיף, והפנייה נשמרת כטיוטה. המנהל מקבל התראה רק אם הקונה עצמו ביקש חריג.
בנפרד הגדירו את החילוף עם 1С, כדי שהסף והקבוצות יתאימו בקטלוג ובהנהלת החשבונות — אחרת הלקוח רואה תנאי אחד, והחשבונית מונפקת לפי אחר.
אחרי חודשיים הפירוקים הידניים פחתו פי כמה, ואת הזמן שהתפנה המחלקה משקיעה בפניות סיטונאיות גדולות. את התמיכה בהגדרות ממשיכים להחזיק: הספים משתנים לפי עונה, היסטוריית השינויים נשמרת, והחזרה לכלל הקודם אורכת דקות.
מה לעשות אם ההגבלה כבר מופעלת, אבל העקיפות נשארו
בדיקה שמוטמעת בעמוד ביצוע ההזמנה סוגרת רק תרחיש אחד — כשהלקוח הולך במסלול הסטנדרטי. כדאי לעבור על שאר נקודות הכניסה לסל: הוספת מוצר לפי קישור, הזמנה מהירה, חזרה על הזמנה קודמת, אפליקציית מובייל, פנייה ישירה לממשק השרת. אם הסף נבדק רק בתבנית, כל אחת מהנקודות האלה נשארת פתוחה.
המקור העיקרי לעקיפת הגבלת הסף — כמה קבוצות לקוחות. הכלל לרוב מוגדר "לכולם", ולקבוצה הסיטונאית, למפיצים או לעובדים חלים תנאים משלהם, וההגבלה מופעלת לפני החלת ההנחות האישיות. הסכום בסל והסכום שהלקוח רואה נבדלים — וההזמנה עוברת.
אזור נפרד — פניות חוזרות: המנהל מבצע הזמנה מהפאנל או מעתיק הזמנה קודמת, והסף לא מחושב מחדש, כי הבדיקה נמצאת בוויטרינה ובתרחיש הזה לא נקראת. ב1С-Битрикс זה מטופל בהעברת הכלל לשכבה משותפת של חישוב הסל — ואז כל הערוצים משתמשים בפונקציה אחת.
את המעגל סוגרת בדיקה מצד הנהלת החשבונות: ההפקה משווה את הסכום שנרשם ולא יוצרת מסמך בהפרת הסף. החריג נופל מיד ליומן, ולא צף בהתאמות אחרי חודש.
זה נסגר בלי לכתוב מחדש את היגיון המכירות: כלל סף אחד לכל הערוצים, תנאים נפרדים לקבוצות, יומן של סירובים שהופעלו והתאמה עם מערכת הנהלת החשבונות. בדרך כלל זו התאמה בכמה נקודות, ולא סכימת מכירות חדשה.
ספקות טיפוסיים: עקיפת כללים, קבוצות לקוחות, חילוף עם מערכת הנהלת החשבונות
סף הסכום המינימלי בפלטפורמת 1С-Битрикс חי במפגש של הקטלוג, ביצוע ההזמנה והחילוף עם מערכת הנהלת החשבונות. רוב הספקות עולים לא סביב ההגבלה עצמה, אלא סביב העקיפה שלה, תנאים שונים לקבוצות קונים והעברת הפנייה להנהלת החשבונות באיסוף עצמי.
להלן תשובות לשאלות הטכניות שעולות לרוב בקבלה. כל אחד מהפתרונות נבדק על סביבת בדיקות לפני העלאה לאתר החי.
האם אפשר לעקוף את הסף דרך תהליך הזמנה ישן?
הגבלה ברמת הקטלוג לא עובדת: ההזמנה נוצרת במטפל השמירה. אם הבדיקה נמצאת רק בתבנית, הזמנה מתחת לסף בכל זאת תעבור — דרך תבנית מיושנת או קריאה חיצונית. לכן את הבדיקה שמים במטפל בצד השרת ומשכפלים בתבנית, כדי שהלקוח יראה הודעה מובנת לפני השליחה.
איך להגדיר ספים שונים לסיטונאות ולקמעונאות?
את הסף שומרים במאפיינים של קבוצת הקונים, ולא בקוד. אז הקבוצה הסיטונאית מקבלת ערך אחד, הקמעונאית — אחר, ואורח — בסיסי. בהעברת לקוח בין קבוצות התנאי מחושב מחדש תוך כדי, ואין צורך בעריכות תבניות.
האם הסף נחשב באיסוף עצמי?
ההגבלה נחשבת לפי סכום הסל ואינה תלויה באופן הקבלה. אם לאיסוף עצמי נדרש סף אחר, זה מוגדר בתנאי נפרד בכלל, ולא בכיבוי הבדיקה — אחרת ההגבלה תפסיק לעבוד גם למשלוח.
איך ההגבלה משתלבת עם חילוף הפניות?
ההזמנה יוצאת למערכת הנהלת החשבונות בשלמותה: הרכב, הסכום, הסטטוס, אופן הקבלה. מגדירים את החילוף כך שהמשלוח יופעל אחרי אישור ההזמנה, ופערים בסכום ייתפסו לפני ההפקה, ולא אחרי רישום המסמך.
נדבר על המשימה: נאסוף כללים ונחזור עם הערכה
כדי שכללי הסכום המינימלי יעבדו באופן צפוי, צריך נתוני קלט — הם קובעים איפה נקבע הסף, אילו תרחישים נשארים עובדים ואיך זה קשור לחילוף ההזמנות ב-1С.
- רשימת תנאי המכירה בסיטונאות: לאילו קבוצות קונים, סוגי מחירים וחוזים חל הסף, ואיפה נדרשים חריגים.
- היגיון החישוב: סכום מינימלי לפי הסל לפני הנחות או אחריהן, בהתחשבות במשלוח ובכפילות האריזה.
- תפקידים והרשאות: למי מותר לבצע הזמנה מתחת לסף — מנהלים, מחלקות נפרדות, איסוף עצמי.
- התנהגות הממשק: הודעה לקונה, רמז להשלים עד הסכום, חסימה או הסתרה של כפתור ביצוע ההזמנה.
- סכימת החילוף עם 1С: איך הסף מתייחס לסטטוסי תשלום, משלוח ותנאים חוזיים של הלקוח.
- גישות: סביבת בדיקות של האתר, העתקת בסיס הנתונים, פרטי האינטגרציה ואיש קשר אחראי על תיאום הכללים.
- סלים קיימים: האם צריך לחשב מחדש סשנים פעילים, כדי לא לאבד עסקאות בעבודה.
תארו את המשימה — נחזור עם הערכה ותוכנית עבודה: נפרק את הכללים לפי קבוצות קונים, נציג את התנהגות הסל על סביבת בדיקות ונציין לוחות זמנים. את תנאי המכירה בסיטונאות אחרי ההרצה נערוך דרך ההגדרות, בלי התאמת קוד.