הגדרת מחירים ב-1С-Битрикс לפי נפח הזמנה
כל עוד בקטלוג יש מחיר אחד למוצר, החישוב מסתדר מעצמו: העמוד, הסל וההזמנה מציגים מספר אחד. ברגע שמופיע חישוב מחיר לפי כמות ומחירי סף לסיטונאים, המחיר מפסיק להיות הערך של שדה אחד — הוא הופך לתוצאה של כמה כללים שפועלים בזמנים שונים ובמקומות שונים.
המקום הראשון שבו זה נשבר — פער בין מחיר הקטלוג למחיר ההזמנה. כרטיס המוצר מחזיר מחיר מסוג בסיסי, בעוד הנחות נפח בסל מחושבות בנפרד, ולכן הקונה רואה ספרה אחת בקטלוג ואחרת בסל — זה לא עיגול, אלא שני אלגוריתמים שונים.
אם כלל הנפח קשור לסכום ההזמנה ולא לפריט, מחיר השורה משתנה עם הוספת כל מוצר, והמספר "צף" בכל שלב של ביצוע ההזמנה.
השני — חישוב מחדש ידני של ההזמנה. המנהל מתקן את הכמות או מכניס מחיר מוסכם, ההזמנה בשמירה מחושבת מחדש, או שמוחקת את התיקון, או שמיישמת את הנחת הנפח שוב.
לאחר ביצוע ההזמנה הפריטים מקובעים, ושינוי הסף בקטלוג כבר לא משפיע עליהם — ומכאן נוצרים פערים בין ההזמנה, החשבונית והמשלוח, שמחפשים אחר כך ידנית.
הדבר נסגר בנקודת חישוב שרתית אחת: הגדרת מחירים ב-1С-Битрикс מכנסת את הקטלוג, הסל והביצוע לאלגוריתם משותף — עם סוגי מחירים לכל סף, סדר עיגול ומס אחיד והיסטוריית שינויים לפי הזמנה.
מה משתנה אחרי ההטמעה: חמישה אפקטים מדידים
כללי חישוב המחיר עוברים מהתכתבות עם המנהל אל הגדרות הקטלוג: ספי נפח, מדרגת הנחה, חריגים לקבוצות מוצרים מסוימות. ב1С-Битрикс הדבר מתואר בכללים מובנים, ולכן הוויטרינה, הסל והחשבונית מחשבים את אותו מספר. האפקט של ההטמעה ניכר בגדלים מדידים.
שיעור ההזמנות ללא תיקון ידני
הלקוח רואה את המחיר הסופי ברגע הוספת הפריט, ולא אחרי שיחת טלפון. החישוב מחדש פועל בכל שינוי בהרכב ובכמות, ולכן המנהל לא צריך לאשר את ההנחה ידנית. שיעור ההזמנות שיוצאות לעבודה ללא תיקונים עולה ממקרים בודדים לרוב.
זמן ביצוע ההזמנה
ההמתנה לתשובת המנהל לגבי המחיר היא החלק הארוך ביותר בביצוע ההזמנה. כשהסכום מחושב מחדש בכל שלב, הלקוח עובר את הסל בלי הפסקות ובלי אישורים חוזרים. זמן הביצוע הכולל מתקצר פי כמה, ושיעור הסלים הנטושים יורד.
ביטולים ותשלומי השלמה בגלל מחיר שגוי
סוג שלם של שגיאות נעלם: פער בין הוויטרינה, הסל והחשבונית. המסמכים נוצרים מאותו מחיר שהלקוח ראה, ולכן ביטולים ותשלומי השלמה לאחר הוצאת החשבונית מפסיקים, ומקרים שנויים במחלוקת לא מגיעים להנהלת החשבונות.
לוגיקת הנחות אחידה ועומס על המנהלים
הכללים נמצאים במקום אחד: מבצע חדש משנה את המחיר בכל ערוצי המכירה, ולא בכמה טבלאות. המנהלים מפסיקים לעבוד עם מחשבון — הזמן מוקדש לעסקאות ולא להשוואת סכומים. העומס על המחלקה יורד ביחס למספר ההזמנות עם הנחת נפח.
איך לחשב מחירים לפי נפח: מדרגות, הנחות, כללי סל
תמחור לפי נפח ב-1С-Битрикс נבנה מכמה מנגנונים בלתי תלויים. בוויטרינה הם נראים אותו דבר, אך בוחרים מחיר אחרת, נשמרים במטמון אחרת ומשתלבים זה עם זה בדרכים שונות — ולכן בוחרים את המצב לא לפי המראה, אלא לפי היכן נמצאת האמת לגבי המחיר.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מחירי מדרגה לפי כמות | ספי יציבים: 10 / 50 / 100 יח' | הסף נחשב לפי שורת הסל — הרכב מעורב לא מגיע אליו |
| הנחה מצטברת לפי סכום הזמנות | יחסים ארוכי טווח עם לקוחות קבועים | נדרשת היסטוריית הזמנות וחישוב מחדש של הפרופיל; ההזמנה הראשונה לפי מחיר בסיסי |
| כללי סל לפי הרכב וסכום | סטים, "מעל N פריטים — אחוז" | כמה כללים יכולים לפעול על שורה אחת — נדרשים סדרי עדיפויות ואיסור כפילויות |
| תנאים לקבוצות קונים | סיטונאות וקמעונאות, מחירוני שותפים | המחיר קשור לקבוצה: שינוי שלה מצריך חישוב מחדש ואיפוס מטמון המחירים |
| רמות מחיר ממערכת הנהלת חשבונות חיצונית | המחירון מחושב בהנהלת החשבונות ומגיע מוכן | השהיה בסנכרון וקונפליקט עם כללי הנחה מקומיים |
המגבלה העיקרית — שילוב הנחות. כלל הסל מיושם מעל המחיר שנבחר כבר, ולכן הנחת מדרגה והנחה מצטברת מצטברות אם לא הוגדר במפורש איסור יישום חוזר. כללים ורמות מחיר נשמרים במטמון: לאחר תיקון נדרש איפוס, אחרת הוויטרינה מחזירה ערכים ישנים עד לפקיעת התוקף.
אם מחשבים מדרגות והצטברות בו-זמנית בקטלוג ובמערכת חיצונית, הפער בין המחיר בוויטרינה לסכום בחשבונית הוא רק עניין של זמן. נבחן על המשימה שלכם איזה מצב מכסה את מודל המכירות שלכם בלי חישוב כפול.
סדר ההטמעה: מביקורת הקטלוג ועד למסירה
העבודה מתבצעת ברצף: תחילה מפרקים את מה שכבר פועל בקטלוג, אחר כך מתכננים את סכימת החישוב, מגדירים אותה, בודקים בסביבת בדיקה ורק לאחר מכן מעבירים לאתר הפעיל. הסדר אינו אקראי — כל שלב מסיר סיכון שיוקר יותר בפרודקשן: קונפליקט בין כללים, עיגול שגוי, חישוב מחדש של הסל בעת שינוי כמות.
- ביקורת ההנחות הנוכחיות — אוספים את הכללים הפעילים לפי מדורים ומותגים, מצטברים ומבצעים, קובעים את סדרי העדיפויות שלהם ומוצאים את החפיפות שבגללן המחיר משתנה באופן בלתי צפוי.
- סכימת חישוב ההזמנה — מתאמים ספים ומדרגת מדרגה, בסיס חישוב (מחיר לפני או אחרי הנחות אחרות), עיגול והתנהגות סל מעורב. זהו תקן הייחוס שלפיו נשווה בהמשך את התוצאה.
- הגדרת המנגנון — יוצרים כללי מחיר על עותק של הקטלוג ומקשרים אותם לאירועי הסל, כדי שהמחיר יחושב מחדש בכל שינוי כמות.
- סביבת בדיקה — מריצים סלים אמיתיים וסינתטיים: בדיוק על הסף, בפריט מתחת, עם מוצרים ממדורים שונים וסוג משלם שונה.
- בדיקת סלים בגבול — משווים לתקן הייחוס ובודקים את יומן החישובים מחדש: היכן הכלל לא פעל או הופעל פעמיים.
- העברת ההגדרות לאתר הפעיל — הגירת כללים, איפוס מטמון הקטלוג והסל, הפעלה בחלון עומס נמוך עם בקרה על הזמנות חיות.
- מסירה — סכימת החישוב, מפת הכללים והוראות למנהל: איך להוסיף מדרגה, לשנות סף, לכבות מבצע.
תצורת ההנחות: מה נשאר בפרויקט
הנחה בפרויקט היא לא תיקון חד-פעמי בקוד, אלא שורה במטריצת התנאים שאפשר לראות ולבדוק. כך בדיוק בנויה הגדרת מחירים ב-1С-Битрикс לאחר המסירה: לוגיקת החישוב מתוארת, ולא מפוזרת בין תבניות ומטפלים. אנו מוסרים את הסביבה יחד עם גישה לעמדת הבדיקה, כדי שהתיקונים ייבדקו לפני הפרסום.
- מטריצת תנאי ההנחות — קטגוריות מוצרים וסוגי לקוחות לפי שורות, נפח הזמנה ותקופה לפי עמודות; בתאים אחוז וסדר עדיפות ההפעלה.
- כללי סל מוגדרים — ספי נפח, הנחה לפי כמות, תנאים מצטברים; מחושבים ברמת הסל ואינם מתנגשים עם מבצעים בכרטיס המוצר.
- סכימת סדרי עדיפויות — איזה כלל מנצח כשכמה מתאימים להזמנה: המחיר לא "קופץ" עם הוספת פריטים, הנחות כפולות נשללות.
- נהלים לשינוי הנחות — מי יוזם את התיקון, אילו נתונים מצרף, מי מאשר ובאיזה מועד הערך מגיע לאתר.
- תפקידי האחראים — המשווק מנהל את האחוזים, מנהל התוכן — את ההצמדה לקטגוריות, המפתח מתערב רק בשינוי לוגיקת החישוב.
- הוראות למנהל התוכן — היכן לשנות את הערך, איך להרכיב הזמנת בדיקה ולפי אילו סימנים לזהות שהכלל לא פעל.
- מערכת תרחישי בדיקה — הזמנות בגבולות הספים, סל מעורב, הזמנה חוזרת של לקוח קבוע; מריצים בכל תיקון של המטריצה.
את הלוגיקה משנים דרך הממשק, בלי להזמין מפתח — בקוד נוגעים רק עם הופעת סוגי תנאים חדשים.
ניתוח מקרה של הטמעה: איך השתנה חישוב ההזמנות
לספק של ציוד תעשייתי — קטלוג של כמה אלפי פריטים, שלוש מדרגות הנחה לפי נפח ותנאים נפרדים לסוחרים. המנהלים הרכיבו את המחיר ידנית: הסתכלו על סכום הסל, בחרו אחוז לפי הטבלה ורשמו אותו בחשבונית. מתוך 1,200 הזמנות בחודש כך עברו 340 — כמעט כל רביעית, והביצוע ארך בממוצע 11 דקות.
לפני: המחיר כפעולה ידנית
כללי ההנחות חיו בטבלה ובזיכרון של מחלקת המכירות, ולכן אותו סל אצל שני מנהלים יכול היה לקבל מחיר שונה. הזמנה עם תיקון נשלחה ללקוח לאישור חוזר, והזמן עד לחשבונית גדל. בנושא המחיר הגיעו כ-90 פניות בחודש — בעיקר ממי שראו בסל סכום אחד ובחשבונית אחר.
אחרי: המערכת מחשבת את הכללים
את התנאים העבירו ל1С-Битрикс: מדרגות הנפח תוארו כמערכות כללים עם הצמדה לקבוצת הקונים ולסכום הפריט, ואת החישוב מחדש הפעילו בשינוי הסל ולא ברגע הביצוע. כל כלל שהופעל משאיר רשומה בהזמנה — רואים איזה אחוז הופעל ועל איזו שורה, ולכן מחיר שנוי במחלוקת נבחן לפי העובדות, בלי התכתבות.
שיעור ההזמנות עם התאמת מחיר ידנית ירד מ-28% ל-3%: ידנית נשארו רק הסכמים אישיים, שבהם ההחלטה באמת בידי האדם. הרכבת ההזמנה הממוצעת התקצרה מ-11 ל-4 דקות — הלקוח רואה את העלות הסופית מיד ולא ממתין לאישור. הפניות בנושא המחיר הצטמצמו לכ-20 בחודש, והחזרות הזמנה לחישוב מחדש — פי שלושה פחות.
במה נבדלים מחירי מדרגה מכללי הסל
מחיר מדרגה של פריט הוא תכונה של הפריט עצמו בקטלוג: המחיר קשור לכמות בשורה, עד הסף אחד ואחרי הסף אחר. החישוב מחדש מתבצע ברגע שינוי הכמות, והתוצאה נכתבת מיד למחיר שורת ההזמנה. לכן מחיר כזה נראה זהה בקטלוג, בביצוע ההזמנה ובהעברה למערכת הנהלת החשבונות.
כללי חישוב הסל פועלים ברמה אחרת. הם עובדים עם ההזמנה כולה: סכום לפי קבוצת פריטים, מספר פריטים שונים, תנאים מצטברים לפי התוצאה. התוצאה של כלל כזה היא הנחה על סיכום ההזמנה, בעוד מחיר השורה עצמה לא משתנה.
ההסתעפות מופיעה כשהתנאי קשור לנפח הכולל: "לקח מאה יחידות בקבוצה — המחיר נמוך יותר בכל אחת". מחיר מדרגה של פריט לא יראה זאת, הוא מסתכל רק על השורה שלו. כלל הסל יראה את התנאי, אבל יחיל את ההנחה על הסיכום, ובפריטים יישארו המחירים הקודמים.
מכאן מתחיל משלוח חלקי. אם ההנחה יושבת על הסיכום, החלוקה שלה בין השורות אינה חד-משמעית: חצי מההזמנה יוצא — ולמערכת הנהלת החשבונות מגיע סכום שאינו תואם את המסמך המקורי. הפער צף כבר במסמכי הסגירה, כשהתיקונים יקרים.
לכן הגדרת מחירים ב-1С-Битрикс נבנית על התאמה בין הקטלוג להזמנה: הכלל או מחשב מחדש את מחיר הפריט לפני שמירת ההזמנה, או שומר באופן מפורש את פיזור ההנחה בין השורות. אז סיכום ההזמנה והפריטים מתלכדים בכל חלוקה למשלוחים, וחישוב חוזר נותן את אותה תוצאה.
ספקות לפני ההתחלה: מה כדאי להבהיר
לפני ההתחלה עולים אותן שאלות: האם מחירים בהזמנות שכבר בוצעו יידרסו, האם ההעברה החוזרת ממערכת הנהלת החשבונות תישבר, כיצד יתנהג סל עם מאות פריטים ואיך להפריד בין קמעונאות לסיטונאות. נעבור לפי הסדר — ונראה היכן עובר הגבול בין חישוב הוויטרינה לנתוני הנהלת החשבונות.
ההגדרה נמצאת בצד של 1С-Битрикс: כללי הסל, קבוצות הקונים וסוגי המחירים מקושרים זה לזה ולמודול הסנכרון. מערכת הנהלת החשבונות נשארת המקור לפריטים ולמחירי הבסיס, והוויטרינה מחשבת את הסיכום לפי הכללים.
האם מחירים בהזמנות שכבר בוצעו ישתנו?
לא. מחיר הפריט נק�ע ברגע הביצוע ונשמר בהזמנה — לא חישוב מחדש בוויטרינה ולא סנכרון חדש נוגעים בו. כללים ששונו פועלים רק בחישובים הבאים, והמסמכים במערכת הנהלת החשבונות נשארים כפי שהיו.
מה יקרה בהעברה חוזרת של מחירים ממערכת הנהלת החשבונות?
הסנכרון מתבצע דרך המודול המובנה: משווים בין סוגי המחירים וסימן החישוב מחדש, כדי שההעברה תכתוב ערכי בסיס והוויטרינה תחשב מעליהם את תנאי הנפח. לוח הזמנים ונהלי הסנכרון נשארים כשהיו.
כיצד מתנהג סל גדול?
הכללים מחשבים מחדש את הסיכום בכל שינוי בהרכב, ולכן במאתיים פריטים צוואר הבקבוק אינו החישובים אלא כללים מיותרים. משאירים מערכת מינימלית עם סדרי עדיפויות מפורשים ומריצים אותה על סל של כמה מאות שורות.
איך להפריד בין קמעונאות לסיטונאות?
דרך קבוצות הקונים: לכל אחת מערכת כללים משלה, סף לפי סכום או כמות וסדר יישום. תנאי הסיטונאות נראים רק לקבוצות הסיטונאיות, והחפיפות בין הכללים נפתרות בסדר עדיפות ולא בתיקון הקוד.
נדון בתרחיש החישוב שלכם ונעריך את העבודה
כדי שהערכת העבודה על חישוב המחירים תהיה מדויקת ותוכנית ההטמעה — מציאותית, אנחנו צריכים לא בקשה כללית אלא פרטים קונקרטיים על הקטלוג שלכם ועל כללי התמחור.
תארו את המשימה כפי שמנהל מחלקת המכירות רואה אותה וכפי שמערכת הנהלת החשבונות מחשבת אותה — זה מספיק כדי שנחזור עם הערכה ותוכנית לפי שלבים.
- הרכב הקטלוג: כמה מוצרים והצעות מסחריות, היכן נשמרים המחירים והמלאי, האם יש מאפיינים שהמחיר תלוי בהם.
- תנאי החישוב הנוכחיים: כיצד מוקצים כעת מחירים לפי נפח ההזמנה, אילו הנחות, עיגולים ומנות מינימליות פועלים.
- תפקידי הקונים: קמעונאות, סיטונאות, קבוצות שותפים — אילו כללים קשורים לכל תפקיד ומי משנה אותם.
- נקודות אינטגרציה עם מערכת הנהלת החשבונות: סנכרון פריטים, מחירים ומלאי, נהלי הסנכרון, מטפלים באירועים, תיקונים ידניים.
- מגבלות וכללים: מחירונים אזוריים, כפולות הזמנה, סדר עדיפות של כללים, מתי ההנחה אינה מיושמת.
- גישות וסביבת בדיקה: עותק של מסד הנתונים או עמדה נפרדת, גישות לפאנל הניהול, כדי לבדוק השערות בלי סיכון לקטלוג הפעיל.
לאחר מכן נחזור עם הערכת העבודה על חישוב המחירים ותוכנית הטמעה לפי שלבים: תחילה הכללים, אחר כך הסנכרון, ואחר כך בדיקה על הזמנות אמיתיות. תארו את המשימה — נדון בה לעומק ונציע סדר עבודה.