למה כללי הסל של 1С-Битрикс נכשלים במבצעים
ההנחה מחושבת בסל, אבל בהזמנה היא נעלמת — או שהסכום משתנה בדיוק ברגע האישור. כך מתגלה חישוב ההנחות ב-Bitrix כאשר כללי הסל של 1С-Битрикс מצטברים זה על זה: כל כלל בודק את קבוצת המוצרים, הסף והעדיפות שלו, והתוצאה תלויה בסדר שבו המערכת חישבה מחדש את הרכב הסל.
תקלות בעת ביצוע ההזמנה נראות לא מזיקות עד לבדיקה. מתנה להזמנה מתווספת פעמיים אם הקונה חוזר לסל, או נעלמת כשהוא משנה כמות. ההנחה לא חלה על הפריט השני, כי התנאי מקושר למק"ט מסוים ולא למאפיין של המוצר — והקונה רואה סכום אחד, בעוד שהחשבונית מתקבלת עם סכום אחר.
סיפור נפרד הוא המשלוח: עלותו מחושבת מסכום ששונה בשלבים שונים, ולכן סף המשלוח החינמי פועל לסירוגין. הגדרת הנחות בסל הופכת לתיקון ידני של תנאים לפני כל מבצע, והתמיכה הופכת לטיפול בפניות "המחיר שלי לא נכון".
נסביר איך סוגרים את זה: סט תנאים שנבדק במלואו, נקודת חישוב מחדש אחידה לסל ולהזמנה, ובדיקת תרחישים לפני שהמבצע יוצא ללקוחות.
אפקט מדיד ממכניקת הנחות ומתנות מוגדרת
לפני שדברים על האפקט, קובעים נקודת התחלה: מייצאים את שיעור ההמרה של הסל, מספר הפניות בנוגע להנחות בתקופה והזמן הממוצע מהגדרת המשימה ועד להשקת המבצע. לאחר מכן משווים את אותם מדדים כעבור חודש של עבודת הכללים על אותו תנועה — אחרת קל לתלות את הצמיחה בעונתיות ובמכירה.
- שיעור סלים נטושים. סף המשלוח החינמי, מדרגת הצבירה והמתנה מחושבים מחדש ישירות בסל — הקונה רואה את הסכום הסופי לפני ביצוע ההזמנה ולא עוזב כדי לברר את התנאים.
- פניות לתמיכה בנוגע להנחות. חלון הראווה, הסל וההזמנה המאושרת מחשבים את ההנחה באותו מנגנון ולפי אותם תנאים — פער בין מה שהוצג לבין מה שחויב נעלם כקטגוריה.
- מהירות השקת המבצע. מכניקה חדשה נבנית מתנאים ומערכי כללים מוכנים, ולא מתיקון תבניות: הפעלה, בדיקה על עותק בדיקה והשקה באתר החי מסתיימות בתוך שעות.
- עקביות החישוב. עדיפויות ותנאי החרגה מוגדרים במפורש, ולכן הנחה כפולה, הנחה על מוצר ממבצע או מתנה שאבדה מפסיקים לצוף לאחר ההשקה.
- צפיות העומס. שליחת מתנות המונית וצבירת בונוסים מתבצעות באצוות, בלי נעילות של הקטלוג — המבצע לא הופך להאטה של האתר בשעות שיא.
בנפרד אנחנו בוחנים את סוג השגיאות שנעלמו: כמה פעמים בוצעו תיקונים ידניים "מעל" הכללים וכמה הזמנות היה צריך לחשב מחדש ידנית. דווקא המדד הזה, ולא גידול מוחלט בהכנסות, מלמד שהמכניקה הפכה לניתנת לניהול.
בפלטפורמת 1С-Битрикс כללי הסל מתנהגים בצורה צפויה בתנאי שתרחישי ההנחות מתוארים לפני ההגדרה, ולא תוך כדי המבצע.
דרכים להגדרת הנחות: השוואת גישות
בחירת מנגנון המבצע נקבעת לא על ידי השיווק, אלא לפי המקום שבו חי המחיר: בחלון הראווה, בכללים של 1С-Битрикс או במערכת החשבונאית. להלן אפשרויות שאנחנו מיישמים בפרויקטים והמגבלות שלהן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| כללי סל מובנים | הנחות סגמנטיות, מתנה מסכום, משלוח חינם | הלוגיקה בהגדרות: קשה לנפות חפיפות מורכבות של תנאים |
| קופוני הנחה | מבצעים חד-פעמיים ואישיים, דיוורים, קודים שותפים | נדרשת בקרה על מכסות, תוקף ושימוש חוזר בקופון |
| תוכנית נאמנות צוברת | רכישות חוזרות, רמות לקוח, חשבון בונוסים | נדרשת היסטוריית רכישות וחישוב מחדש תקין של הסטטוס |
| החלפת הנחות עם 1С | מחירים ומבצעים נקבעים במערכת החשבונאית | השהיה בהחלפה וקונפליקטים בעת תיקון מחיר בחלון הראווה |
| חישוב מחיר חיצוני | נוסחאות מורכבות, תלות במלאי ובמחסן | נקודת כשל משלנו: חלון הראווה ממתין לתשובת השירות, נדרשים מטמון ותרחיש גיבוי |
מנגנונים מובנים מכסים את רוב התרחישים ולא דורשים תמיכה בקוד משלנו — אותם אנחנו שמים כשכבה הראשונה. חישוב חיצוני אנחנו מחברים כשנוסחת המחיר לא ניתנת להבעה בהגדרות: אז את העלות מחשב שירות נפרד, וחלון הראווה מקבל תוצאה מוכנה.
קופונים ותוכנית צוברת בדרך כלל עובדים יחד: הקופון נותן סיבה לרכישה הראשונה, והרמות מחזיקות ברכישה השנייה והשלישית. סכמות משולבות דורשות תעדוף — אחרת ההנחות מצטברות והמחיר יורד למינוס.
הטמעת כללי סל: שלבי עבודה הנדסית
כללי הסל ב-Bitrix הם סט תנאים עם מכניקת עדיפויות, לא מבצעי שיווק. שני כללים פעילים נותנים לקונה לא סכום הנחות, אלא תוצאה בלתי צפויה: המתנה נעלמת כשמקטינים כמות, הקופון מבטל את הנחת הצבירה. לכן אנחנו מבצעים את העבודה בשלבים — מביקורת ועד לתקנון.
- ביקורת כללי הסל. מייצאים כללים פעילים: תנאים, פעולות, תקופות, שיוך לקבוצות משתמשים. מתעדים חפיפות שבהן כלל אחד מבטל אחר, ופערים מול המבצעים בפועל.
- סכמת עדיפויות להנחות. מרכזים את הכללים במטריצה: מה חל יחד, מה עוצר את האחרים, ואיזה מחיר סופי רואה הקונה בשילוב מסוים של מוצרים. מאשרים אותה לפני ההגדרה.
- הגדרת כללים. מעבירים את המכניקה לסכמה מאושרת: הנחה על מוצר, על הזמנה ועל משלוח, מתנה, קופון. בודקים שהכללים לא מתנגשים עם החלפה מול 1С ומחירי הקטלוג.
- בדיקות מבצעים. מריצים מקרי קצה: סל ריק, מוצר אחד, סכום בדיוק על הסף, קופון יחד עם הנחת צבירה, מתנה כשאין מספיק מלאי, חישוב מחדש לאחר שינוי כמות.
- תקנון השקת הנחות. מתארים את סדר הפעלת הכללים, בדיקה לפני ההתחלה ונסיגה אם המספרים הסופיים לא תואמים את הצפוי.
- מסירת הגדרות. מוסרים תיעוד לכללים, הרשאות ונוהל להפעלת מבצעים באופן עצמאי, כדי שהשיווק לא ימתין למפתח בכל מכירה.
ערכת הגדרות ותיעוד לסל
העבודה לא מסתיימת במבצע שהושק, אלא בחבילת מסמכים שלפיה הצוות שלכם ממשיך לעבוד לבד. את לוגיקת הכללים, העדיפויות ונקודות התיאום מתעדים בכתב — כדי שהשינויים לא יהיו תלויים במי שזוכר את ההגדרה הקודמת.
- תצורת כללי הסל של 1С-Битрикс: תנאים, הגבלות ועדיפויות עם הסבר איזה כלל פועל ראשון בעת חפיפה.
- סכמת חישוב הנחות: סדר החלת ההנחה, המתנה, תנאי הצבירה והפרומוקוד — היכן נוצר המחיר הסופי.
- תיעוד הנחות: עבור כל כלל — ייעוד, תקופת תוקף, בעלים וכיסוי מוצרים או קבוצות.
- מדיניות הרשאות למחירים: תפקידים, למי מותר לשנות כללים ישירות, מה עובר לאישור, ואיך מתנהל יומן שינויים.
- תקנון מבצע: השקה, השהיה, סיום, אחראים והתנהגות המערכת כששני מבצעים חופפים.
- הוראה למנהל: פעולות שלב-אחר-שלב בממשק ופתרון מצבים נפוצים, כולל "ההנחה לא חלה".
- רשימת בדיקה: אורח וקונה מחובר, סל עם כמה מוצרים, פרומוקוד יחד עם מבצע.
- סכמת נסיגה: היכן נשמרת הגרסה הקודמת של ההגדרות ואיך מחזירים אותה במהירות לעבודה.
לאחר המסירה אנחנו עוברים על הערכה עם הצוות שלכם וסוגרים שאלות בכל סעיף. בהמשך המומחים שלכם משנים כללים ומבצעים בלעדינו.
מקרה בוחן: מבצע מתנות בלי תקלות בשיא העומס
מבצע עם מתנות הושק במכירה: מתנה נוספה להזמנה מסכום מסוים. כללי הסל חושבו מחדש בכל שלב של ביצוע ההזמנה, וכשהגיעו קונים רבים המתנה הופיעה ונעלמה לסירוגין, וחלק מההזמנות נשלחו בסכום בלי ההנחה שהובטחה.
התמודדו עם זה בדיעבד: התמיכה השוותה את הסל מול הלוגים ידנית, וכל מאה הזמנות שבע מהן היו צריכות תיקון. השקת מבצע חדש ארכה כמה ימים — הכללים חפפו, ותיקון הנחה אחת שבר את זו שלצדה.
מה שינינו
הפרדנו את הכללים לשכבות בלתי תלויות עם עדיפויות מפורשות: תנאי לפי סכום, תנאי לפי קבוצת מוצרים, מגבלת מתנות להזמנה אחת. המתנה כעת נרשמת בהזמנה ברגע האישור, ולא מחושבת מחדש בכל פנייה לסל — החישוב הפסיק להיות תלוי בכמה פעמים הקונה רענן את הדף. תנאי המבצע נשמרים במטמון, ושלבי ביניים לא מפעילים חישוב מחדש.
הכול נבנה על המנגנון המובנה של 1С-Битрикс — בלי שינויים בליבה, ולכן עדכוני הפלטפורמה לא שוברים את המבצע.
| מדד | לפני | אחרי |
|---|---|---|
| הזמנות עם סכום שגוי | 7% | 0.3% |
| השקה ותיקון מבצע | כמה ימים | שעתיים |
| פניות בנוגע לחישוב ההנחה | כ-120 למבצע | בודדות |
| ביצוע הזמנה בשיא | הואט פי שניים | ללא שינוי |
בנפרד הוספנו תיעוד לוגים של החישוב: בכל הזמנה רואים איזה כלל פעל ולמה המתנה לא חלה. סל שנוי במחלוקת משוחזר תוך דקה, ולא מנותח בהתכתבות עם הקונה.
איך מכניקת ההנחות משתלבת בהחלפת הזמנות עם 1С
מקור האמת למחיר הוא המערכת החשבונאית, לא חלון הראווה. כללי הסל באתר מחשבים עלות מקדימה, כדי שהקונה יראה את ההנחה לפני ביצוע ההזמנה, אבל המחיר הסופי והרכב ההזמנה נרשמים ברגע ההעברה ל-1С.
אם חלון הראווה יתחיל להציג את המחיר שלו כמחיר סופי, החלפת ההזמנות עם 1С תהפוך לבדיקה ידנית של כל מסמך.
ההנחה צריכה להגיע לחשבונאות בלי אובדן. יש שתי גישות עובדות: לפרוס אותה על שורות ההזמנה או להעביר אותה כשורת שירות נפרדת — הבחירה תלויה באופן שבו מחשבים בחשבונאות את ההכנסה ואת עלות הפריט.
בנפרד מסכמים מי מחשב מחדש את הסכום אם המחיר בחשבונאות השתנה בין ביצוע ההזמנה באתר לבין ייצוא ההזמנה.
העברת מתנות לחשבונאות היא המקור הנפוץ ביותר למחלוקות בעת סגירת משמרת. מתנה מכלל סל צריכה לעבור ל-1С כפריט נפרד עם סימון מבצע, אחרת המוצר יגיע ללקוח אבל לא ייגרע מהמלאי, והיתרות יתחילו לסטות מהמציאות.
בפועל: עלות אפסית ועוד סימון של מכניקת פרומו, או הנחה של מאה אחוז על שורה מסוימת — מה לבחור תלוי באופן שבו מוגדרת המחיקה בחשבונאות.
פערים בין חלון הראווה לחשבונאות כמעט תמיד נובעים מסנכרון הפריטים. הקישור נעשה לפי קוד חיצוני, לא לפי שם, אחרת שינוי שם של מוצר שובר את כלל הסל.
לאחר כל ייצוא של הקטלוג בודקים שכל הפריטים מהמבצעים קיימים בחשבונאות וזמינים למשלוח — כלל תקוע מפסיק בשקט לתת הנחה, והקונה רואה מחיר אחר מזה שהמנהל רואה.
לכן סדר העבודה הפוך מהרגיל: קודם מתעדים את סכמת החלפת ההזמנות, הרכב השורות וכללי מחיקת מתנות, ורק אחר כך בונים את המבצעים בחלון הראווה. כך חלון הראווה והחשבונאות מציגים את אותו סכום, וסגירת המשמרת לא הופכת לניתוח פערים.
שאלות טכניות נפוצות בנוגע להגדרת הנחות
כללי הסל כמעט אף פעם לא עובדים לבד: המנוע אוסף את כל אלה שמתאימים להרכב הסל הנוכחי ומיישם אותם לפי עדיפות. לכן השאלות העיקריות של לקוחות — לא "איך מפעילים הנחה", אלא איך להפריד בין מכניקות מתנגשות ולהעביר לוגיקה מוכנה למהדורה אחרת.
להלן ספקות טכניים אופייניים שאנחנו מבררים לפני תחילת המבצע: סדר הפעולה, התלויות ובדיקה בטוחה על הזמנות חיות.
שני כללים מתאימים לאותו סל — איזה יפעל?
שני הכללים יחושבו, אבל יחול זה עם העדיפות הגבוהה יותר; בעדיפות שווה — לפי סדר המיון. מתכננים את התנאים כך שהחפיפות יהיו צפויות: קובעים עדיפות מפורשת או מפרידים בין המכניקות לפי מאפיינים סותרים — קבוצת מוצרים, סכום, אמצעי תשלום.
האם אפשר להעביר כללים מוגדרים למהדורה אחרת?
כן, ההגדרות מיוצאות לקובץ ומועברות בין מהדורות ועותקים של האתר. אבל חלק מהמכניקות נשענות על מודולים שאין במהדורות צעירות יותר — כללים כאלה יצטרכו להיבנות מחדש. לפני ההעברה משווים את הרכב המודולים והתלויות, כדי לא לקבל מבצע שלא עובד בשקט.
איך בודקים מבצע בלי לשבור מחירים פעילים?
מפעילים את הכלל במצב כבוי ובודקים את החישוב על הזמנות בדיקה ובסל בתפקידים שונים: אורח, קונה מחובר, קבוצת סיטונאות. אחר כך מציגים את המכניקה לקהל מוגבל, מוודאים שההנחה לא חלה על מוצרים עם מחיר קבוע, ורק לאחר מכן פותחים לכולם.
נדון במשימה: הציגו את מכניקת ההנחות הנוכחית
כדי שהערכת העבודה על הסל תישען על עובדות ולא על הנחות, אנחנו צריכים תמונת מצב של מכניקת ההנחות הנוכחית. תארו את המשימה בצורה חופשית — את שאלות ההבהרה נשאל בעצמנו ונאסוף מהתשובות רשימת דרישות. מה עוזר לעשות זאת מהר יותר:
- אילו כללים כבר פעילים: הנחות על קטגוריות ומותגים, מתנות להזמנה, תנאי צבירה, פרומוקודים;
- איך נוצרים המחירים והאם יש החלפה עם המערכת החשבונאית, באיזו תדירות היא מתבצעת ומה היא דורסת;
- הגדרות הסל וביצוע ההזמנה: סוגי משלמים, ספים, עיגולים, תאימות מבצעים;
- מגבלות: מה אסור לשנות ואילו אינטגרציות תלויות בלוגיקה הנוכחית;
- דוגמאות להזמנות שבהן ההנחה לא פעלה או פעלה באופן שגוי, עם התוצאה הצפויה;
- גישות לסביבת בדיקה ותיאור האופן שבו הכללים מוגדרים כיום.
הפורמט כזה: נדון במשימה, נתעד רשימת דרישות ועדיפויות של כללים, ואז נחזור עם הערכה ותוכנית הטמעה — הרכב השלבים, סדר העלייה לסביבת הייצור, נקודות בדיקה בסביבת הבדיקה וסכמת נסיגה אם כלל יתנהג אחרת.
תחילת העבודה — לאחר אישור הרשימה הזו: כך באמצע לא יצוצו "עוד כמה תנאים" ששוברים את לוגיקת העדיפויות ואת סדר חישוב ההנחות.