מחירי סיטונאות ב-Bitrix: היכן נשבר חישוב ההזמנה מחדש
מחירי סיטונאות ב-Bitrix נשברים לרוב לא ברגע הגדרת הכללים, אלא בחישוב מחדש של המחיר בסל הקניות. הלקוח צובר נפח, עובר את הסף פורמלית, אבל בהזמנה נשאר מחיר הקמעונאי — ההנחה לפי נפח ההזמנה או שלא הוחלה כלל, או שתפסה רק חלק מהפריטים.
המנהל מגלה את הפער רק לאחר השלמת ההזמנה, מבצע חישוב ידני של ההנחה ומאשר אותה במכתב: ההזמנה עוברת להתכתבות ולא למערכת, ולא ניתן יהיה לשחזר אותה לאחר מכן לפי מסמכים.
הסיבה היא בדרך כלל שהכלל מקושר לאירוע ולא למצב הסל. ההנחה מופעלת ברגע הוספת המוצר, אך אינה מחושבת מחדש כאשר משנים את הכמות ישירות בסל, כאשר המחיר נשלף מחדש ממערכת החשבונאות, או כאשר מוחזר כרטיס קטלוג מהמטמון.
אם הסף מחושב לפי שורה ולא לפי סכום ההזמנה כולה, לקוח גדול מקבל תנאי סיטונאות על פריט אחד ומחיר קמעונאי על השאר — וזה נראה כמו טעות של החנות, לא כמו מדיניות מחירים.
המחיר של תקלה כזו נמדד לא בהנחה, אלא בעבודה ידנית: כל אישור נפח — מכתב נפרד, בדיקה נפרדת, סיכון לטעות לטובת הלקוח או לטובתכם. בנוסף, אובדן שליטה: השיווק לא רואה אילו ספים באמת עובדים ואילו המנהלים עוקפים ידנית.
נסביר כיצד סוגרים זאת: הסף חייב להיחשב לפי כל הסל, המחיר — להתחשב מחדש בכל שינוי בהרכב ובכמות, וההנחה המוסכמת — להירשם בהזמנה כשורה נפרדת, ולא בטקסט של מכתב.
מה נותן ניהול מחירים לפי נפח ההזמנה
ספי הנפח מוגדרים באופן הצהרתי: עבור כל קבוצת מוצרים מתוארות רמות — מאיזו כמות או סכום של פריטים משתנה המחיר, כיצד מחושבת ההנחה וכיצד מעוגלת התוצאה. הכללים מיושמים בעת חישוב הסל מחדש, ולכן המחיר בקטלוג, בסל ובחשבונית — אותו מספר.
לפני ההטמעה הזמנה גדולה חושבה ידנית: המנהל בחר את רמת ההנחה לפי טבלה, חישב מחדש את השורות וסיכם את התוצאה בחשבונית. מכאן שני סוגי שגיאות — סף נפח שהוחמץ ועיגול שגוי, ואיתם חישוב חוזר לאחר כל שינוי בהרכב ההזמנה. 1C-Bitrix סוגר זאת בכך שהכללים חיים בהגדרות ולא בראש של העובד.
חישוב אוטומטי של ההנחה מסיר את שני סוגי השגיאות: הסף מיושם לפי ההרכב בפועל של ההזמנה, וכל שינוי בפריט מחשב מחדש את התוצאה מיד. שיעור החישובים הידניים יורד לאחוזים בודדים, זמן הטיפול בהזמנה גדולה מצטמצם פי כמה — המנהל מתאם תנאים, לא חשבון.
העומס על המנהל עובר לחריגים: תנאים מיוחדים, דחיות תשלום, הסכמים אישיים שהוצאו במכוון מהכללים הכלליים. עדיפות הכללים וסדר העיגול נקבעים פעם אחת, ולכן התוצאה משוחזרת עם כל עובד ובכל ערוץ — הזמנה עצמאית באתר או ביצוע דרך המנהל.
אפשרויות חישוב: מהנחה באחוזים ועד מטריצת מחירים
חישוב מחיר סיטונאי ב-1C-Bitrix נבנה בארבע דרכים, והן אינן מחליפות זו את זו: אחוז בסוג מחיר נפרד, הנחה לפי נפח בעת ביצוע ההזמנה, מטריצת מחירים והסכמים אישיים עם הלקוח העסקי.
לכל אפשרות יש גבול שמעבר לו היא מתחילה להפריע — בדרך כלל זה הרגע שבו מופיעה רמת סיטונאות שנייה או קבוצת קונים חדשה.
השוואת האפשרויות
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אחוז בסוג מחיר | רמת סיטונאות אחת, תנאים יציבים | אין דירוג לפי נפח, כל רמה חדשה — סוג מחיר נוסף |
| כלל הנחות לפי נפח בסל | 2-3 ספים, הסקאלה משתנה לעיתים רחוקות | מחושבת בעת ביצוע ההזמנה, אין מחיר בקטלוג, בעת חישוב מחדש הערך משתנה |
| מטריצת מחירים: נפח × קבוצת קונים | כמה סגמנטים, המחיר ידוע מראש | דורשת סנכרון עם מערכת החשבונאות ותקנון עדכון |
| הסכם עם לקוח עסקי | רכישות גדולות בודדות | מנוהל ידנית, מתקשה להתרחב לתפוקה שוטפת |
עיגול מחיר וקבוצות קונים הם הגורמים השכיחים ביותר לשבירת החישוב. כלל העיגול חייב להיות אחד לכל השרשרת: אם הקטלוג מעגל כלפי מעלה, הסל מחשב את ההנחה מסכום לא מעוגל, והחשבונית מגיעה עם ערך שלישי — המנהל מחשב את ההזמנה מחדש ידנית וטועה.
לכן את מודל החישוב מקבעים במקום אחד ומתארים את סדר העדיפויות: מה מיושם ראשון — סוג המחיר, כלל ההנחות או המטריצה. אז הרחבת הסקאלה מסתכמת בהוספת שורה לטבלה, ולא בשכתוב הלוגיקה על קטלוג חי.
כיצד אנו מטמיעים: מביקורת הקטלוג ועד לתקנונים
לפני שמפעילים הנחה לפי נפח, אנו בוחנים כיצד הקטלוג בנוי בפועל: אילו סוגי מחיר קיימים, במה הצעת המכירה נבדלת מהמוצר, והיכן המחירים משוכפלים ידנית. בלי זה הכללים מתחילים להתנגש — ההנחה מצטברת עם ההנחה המצטברת, הסף מחושב מהסכום לפני עיגול, והמנהל מתקן את ההזמנה ביד.
סדר העבודות
- ביקורת הקטלוג וסוגי המחירים. מייצאים את מבנה הצעות המכירה, רשימת סוגי המחירים והשיוך שלהם, מחפשים כפילויות ומוצרים ללא מחיר בסיס.
- תרשים חישוב ההנחות. קובעים את הספים — לפי כמות או לפי סכום, את המדרגה ביניהם, את התנהגות הסל המעורב ואת כלל עיגול התוצאה.
- הגדרת הכללים. מגדירים סוגים וקבוצות מחיר, כללי עבודה עם הסל והנחות מצטברות, קובעים עדיפות — כדי ששני מבצעים לא יחולו על פריט אחד.
- חיבור למערכת החשבונאות. מגדירים סנכרון של פריטים ומחירים, כדי שהספים באתר לא ייפרדו מאלה שבמערכת החשבונאות בעת החלפת המחירון.
- הזמנות בדיקה. מריצים את גבולות הסף, סל מעורב, אורח וקונה מאומת, ביטול והחזרה — ומשווים את המחיר בכל שלב.
- מסירת תיעוד. מוסרים את תרשים החישוב, מפת הכללים, הוראות למנהל ואת סדר העריכה של הספים ללא מפתח.
מה נשאר במערכת ובתיעוד
הגדרת מחירי הסיטונאות לא מסתיימת בכך שההנחה מתחילה להיחשב בחנות — לצוות שלכם נשאר סט של תוצרים שלפיהם אפשר לפתח ולהעביר את המערכת הלאה בלי לשחזר את הלוגיקה מהקוד. מה בדיוק אנחנו מוסרים:
- מטריצת כללים — טבלה «סוג לקוח × נפח הזמנה × מחיר בסיס → ההנחה המיושמת»: ספים, עיגול ועדיפות כאשר התנאים מצטלבים.
- מפת סוגי מחירים — אילו סוגים מוגדרים בקטלוג, איזה נחשב לבסיסי, אילו מוסתרים מהחנות והיכן כל אחד משמש.
- מפת החישוב — מסלול המחיר מהייצוא ממערכת החשבונאות ועד לקיבועו בהזמנה, כולל חישוב מחדש בעת שינוי נפח הסל.
- תקנון עדכון מחירונים — תדירות הייצוא, האחראי עליו ובדיקת פריטי בקרה לאחר כל טעינה.
- הוראות למנהל — חיבור לקוח לסוג מחיר הסיטונאי, מתן תנאי אישי, ופעולות בעת עריכה ידנית של פריט בהזמנה.
- יומן שינויי מחירים — מי, מתי ולפי איזה כלל שינה את התנאים; לפיו מנתחים פער בין החשבונית לחנות.
- תזכיר לתמיכה — פניות אופייניות בנושא מחירים וסדר הפעולות: מבדיקת השיוך של הלקוח ועד לבנייה מחדש של הסל.
סט זה מספיק כדי לשנות תנאי אספקה בלי לבנות את הלוגיקה מחדש.
מקרה בוחן: מחירון סיטונאי לרשת מפיצים
רשת מפיצים של חומרי בניין עם ארבע רמות שותפים הגיעה עם משימה: מחירי הסיטונאות חיו בטבלאות שהמנהלים ניהלו ידנית. להלן — המספרים לפני ואחרי העברת החישוב ל-1C-Bitrix.
לפני ההטמעה
מתוך 40 000 פריטים בקטלוג, המחיר הסיטונאי עבור 60% מההזמנות נבחר ביד: המנהל פתח את המחירון, איתר את העמודה המתאימה לרמת השותף ולנפח האצווה, והעתיק את הערך לחשבונית. הזמנה ממוצעת טופלה 3–4 שעות, ובשיא המשלוחים עברה ליום למחרת.
פערים בחשבוניות צפו ב-7–9% מהמשלוחים: הסל חישב את המחיר לפי תנאים אחדים, ומודול הסנכרון עם 1C יישם אחרים.
אחרי ההטמעה
הרכבנו סוגי מחיר לכל רמת שותף וכלל הנחה לפי נפח: המחיר מחושב מחדש לפי כמות וסכום בשורה, עם ספים ועיגול קבוע. ההנחה אינה מצטברת עם ההנחה האישית — המערכת בוחרת את המשתלמת יותר עבור השותף.
שיעור החישובים הידניים ירד למקרים בודדים — נותרו רק תנאים חוזיים אישיים. זמן הטיפול בהזמנה הצטמצם ל-15–20 דקות.
החשבונית נוצרת מאותם כללים כמו הסל, ולכן הפערים בחשבוניות כמעט נעלמו: משלוחים שנויים במחלוקת מנותחים כעת לפי יומן שינויי המחיר, ולא בחישוב חוזר ידני.
במה נבדלת הנחה לפי נפח מהנחה מצטברת?
הנחת סף מחושבת מהסל הנוכחי: עברת את הנפח — מחיר הפריט חושב מחדש. המצטברת פועלת אחרת — היא מסתכלת על היסטוריית הרכישות בתקופה ואינה מגיבה למה שנמצא בסל כרגע. מחיר חוזי כלל לא קשור לנפח: הוא נקבע לסוג הקונה.
| אפשרות | כיצד פועלת | מגבלות |
|---|---|---|
| הנחת סף על הזמנה | מחשבת מחדש את מחיר הפריט כאשר הכמות או הסכום בסל עוברים את הסף | הסרת הפריט — המחיר חזר; הספים נקבעים בנפרד לפי קבוצות מוצרים |
| הנחה מצטברת לתקופה | מחושבת לפי הזמנות שנסגרו בתקופה ומעלה את רמת הקונה | מופעלת לאחר התשלום או המשלוח; בעת החזרה רמת הקונה מחושבת מחדש |
| מחיר חוזי לפי סוג הקונה | מחיר קבוע לקבוצת קונים ללא תלות בנפח | נדרש מדריך סוגי קונים וסנכרון עם מערכת החשבונאות |
ב-1C-Bitrix כל שלושת המנגנונים חיים בכללי הסל ויכולים להצטלב על פריט אחד. אז פועלת עדיפות הכללים, ואם לא קובעים אותה במודע, הקונה יקבל את מה שחושב ראשון, ולא את מה שהבטחתם. לכן מפרידים את הכללים לפי סוגי קונים ולפי קבוצות מוצרים.
תנאי החישוב נקבעים בנפרד: ממה מחשבים את הסף — מהסכום עם מס או בלעדיו, האם המשלוח נכלל, ובאיזה רגע מחושבת מחדש הרמה המצטברת. דווקא הפרמטרים האלה נותנים תוצאה שונה בהנחות שנראות זהות.
שאלות טכניות בנוגע לחישוב מחירים
שינוי כללי חישוב מחירי הסיטונאות נוגע בשני רבדים בלתי תלויים: הכלל שלפיו הפלטפורמה מחשבת את המחיר בסל, והמחיר שכבר נרשם בפריט של הזמנה שהושלמה. הראשון משתנה בהגדרות, השני — בנתונים, ואלה פעולות שונות עם סיכונים שונים.
לכן על השאלה «האם הזמנות ישנות יחושבו מחדש» תמיד יש תשובה אחת: לא, כל עוד החישוב מחדש לא הופעל בנפרד.
הסנכרון עם מערכת החשבונאות מעדכן את המחירון לפי הצירוף «סוג מחיר + מק"ט + תקופת תוקף», ולכן מוטב להפריד בזמן בין הגדרת הכללים לבין עדכון המחירון — אחרת לא ברור מה בדיוק שינה את המספר. להלן — השאלות שמועלות לרוב לפני ההרצה.
האם המחיר ישתנה בהזמנות שכבר הושלמו?
לא. ברגע ביצוע ההזמנה המחיר מועתק לפריט ההזמנה יחד עם ההנחה — מכאן ואילך זהו עובדה היסטורית, לא תוצאה של חישוב מחדש. חישוב מחדש של הזמנות ישנות הוא פעולה נפרדת עם יומן: אילו הזמנות נפגעו, מה היה ומה נהיה. מוטב להפעיל אותה רק במקום שבו הפער כבר הוביל למחלוקת עם הקונה.
כיצד מתעדכן המחירון ממערכת החשבונאות ומה עושים עם מחירים ידניים?
הסנכרון כותב מחדש את הערכים בפריטים המשויכים לפריט הנומנקלטורה ולסוג המחיר. אם המחיר של מוצר הוזן ידנית או הוגדר באופן אישי, הסנכרון לא ייגע בו — יש להוציא פריטים כאלה לסוג מחיר נפרד, אחרת בייצוא הבא הערך הידני יאבד ללא אזהרה.
האם אפשר להגדיר מחירים אישיים לרשת קמעונאית וכיצד לבדוק את ההגדרה לפני ההרצה?
כן, באמצעות סוג מחיר נפרד ושיוך לקבוצת קונים: כללי החישוב לפי נפח ממשיכים לפעול מעל מחיר הבסיס. לפני ההרצה אנו מריצים סט בקרה של הזמנות — סכומים בגבול, קבוצות קונים שונות, פריטים עם מחיר ידני — כדי לוודא שהכלל הנכון מופעל, ושההזמנות הישנות נותרו ללא שינוי.
נדון במשימה ונחזור עם תוכנית הגדרה
תמחור הסיטונאות נשבר לא בחשבון, אלא במפגשים שבין החלקים: חישוב מחדש בעת שינוי כמות בסל, סנכרון עם 1C, יישום חוזר של כללים על הזמנה שכבר הושלמה. לכן הערכת העבודה מתחילה לא מהמחירון, אלא מהרכב הנתונים שלכם ומכללי התנהגות ההנחה במצבים שנויים במחלוקת.
כדי לדון במשימה באופן ענייני ולחזור עם תוכנית הגדרת מחירים, הכינו:
- הרכב הנתונים: אילו סוגי מחיר מוגדרים בקטלוג וב-1C, לאילו קבוצות ומדורים חל הסיטונאות, והאם יש מוצרים חריגים;
- תרשים החישוב: ספים לפי סכום, כמות פריטים או נפח — ומה לעשות כאשר הזמנה עומדת בכמה תנאים בבת אחת;
- סדר העיגול וההצטברות: האם מעגלים את התוצאה או כל שורה, והאם ההנחות מצטברות עם מבצעים פעילים;
- נקודות היישום: כרטיס המוצר, הסל, ביצוע ההזמנה, מכתב ללקוח, ייצוא המסמך ל-1C;
- כללי חישוב מחדש: כיצד מתנהג המחיר בעת הקטנת כמות, ביטול פריט או החזרה חלקית;
- מגבלות הרשאות: מי מהמנהלים יכול לשנות ידנית מחיר סיטונאי בהזמנה וכיצד זה מתועד;
- פיתוחים נוכחיים של הקטלוג והסנכרון, כדי שהלוגיקה החדשה לא תתנגש עם מה שכבר נכתב.
בסיום השיחה נחזור עם הערכת עבודה, תרשים חישוב ותוכנית הגדרת מחירים — עם שלבים, נקודות בדיקה על עותק בדיקה וסדר העלאה לאתר הפעיל. תארו את המשימה בצורה הנוחה לכם: נפרט מה חסר להערכה מדויקת, ונציע כיצד לסגור את הפערים האלה.