הגדרת הנחות להזמנה ב-1C-Bitrix: כללי שיווק, קופונים

הנחות על הזמנה ב-1C-Bitrix: למה סל הקניות מחשב לא נכון

הנחה בסל הקניות היא תוצאה של כמה מנגנונים בלתי תלויים: חוקי שיווק, קופונים, הנחות על מוצר והגדרות הסל עצמו. כל אחד מהם בנפרד מחשב נכון.

ברגע שעל הזמנה אחת פועלים שניים-שלושה תנאים בו-זמנית, מתחיל קונפליקט בין חוקי הסל: חוק אחד מחשב מחדש את שורת ההזמנה, השני נשען על הסכום שכבר שונה ומפיק חישוב הנחה שגוי. מבחוץ זה נראה כמו סל שבור — המספר משתנה אחרי רענון העמוד או מעבר לתשלום.

לרוב הסיבה היא עדיפות אטומה של חוקי השיווק. אם לכמה חוקים יש תנאי הפעלה זהים, והעדיפות והאיסור על חישובים נוספים מוגדרים כברירת מחדל, הפלטפורמה מיישמת אותם בסדר שקבוע בהגדרות, ולא בסדר שהתכוון אליו המשווק. מכאן ההפעלה הכפולה של התנאי: קופון מונח על גבי מבצע, הנחה על מוצר — על גבי הנחה על הזמנה.

בהמשך הפער עובר לתשלום. הלקוח רואה סכום אחד, מערכת התשלומים מקבלת סכום אחר, והמנהל בהזמנה — סכום שלישי: במקום אחד ההנחה חושבה לפני עיגול, במקום אחר הקופון שכבר הופעל לא נלקח בחשבון.

זו לא טעות קוסמטית בסכום ההזמנה — ההזמנה נופלת בשלב התשלום או מטופלת ידנית, והלקוח מפסיק לסמוך על המחיר בוויטרינה.

בהמשך נפרט איך זה נסגר: איך לבנות עדיפויות לחוקים, היכן לאסור החלה חוזרת של הנחה ואיך לבדוק את החישוב בכל התרחישים.

מה משתנה לאחר סדר בחוקי הסל

סדר בחוקי הסל הוא прежде прежде כל חישוב צפוי. לכל חוק יש עדיפות מפורשת, סט תנאים (סכום הזמנה, הרכב, קבוצת קונים, תקופת תוקף) וסימן מצטברות עם הנחות אחרות. בכרטיס ההזמנה רואים איזה חוק פעל וממה התגבש המחיר — במקום "קסם" בסכום הסופי. בפלטפורמת 1C-Bitrix זה נסגר באמצעים סטנדרטיים, בלי שינויים בליבה ובלי מודולים עוקפים.

מהירות ביצוע ההזמנה עולה בזכות העובדה שההנחה מוחלת מעצמה עם מילוי התנאי, ולא אחרי הזנת קוד קופון. הסל מחושב מחדש פעם אחת בשרת, מצבי ביניים לא מתרוצצים בין הדפדפן לשרת, ולכן המעבר בין שלבי הביצוע מפסיק "לחכות". בעמוד נשארת נקודת ציון אחת מובנת: הסיכום הנוכחי ורמז כמה חסר להנחה הבאה.

שיעור הסלים הנטושים יורד כשהלקוח רואה את ההיגיון, ולא רק את המספר: "עד ההנחה על הסט חסרה עמדה אחת", ולא שינוי מחיר שקט בשלב האחרון. הניסוח "הקוד לא מתאים" נעלם — החוק מופעל עם הגעה לסף, והחריגים מתוארים בטקסט אנושי.

העומס על התמיכה והיקף התיקונים הידניים יורדים בזכות לוג של חוקים שהופעלו. המנהל רואה ממה התגבש הסכום ומחשב מחדש את ההזמנה בלי להרכיב עמדות מחדש ידנית; שיעור ההזמנות שדורשות תיקון אחרי ביצוע קטן באופן ניכר. פניות "למה ההנחה לא פעלה" הופכות לתרחישי בדיקה עצמית טיפוסיים לתמיכה.

פורמטי חישוב הנחות: קודי קופון, חוקי סל, סטים

ב-1C-Bitrix התנאים מחושבים בשלושה מנגנונים, והם אינם מחליפים זה את זה. חוקי הסל מחשבים הנחה מהרכב וסכום ההזמנה, קופונים וקודי קופון נותנים לקונה קוד, וסטים של תנאים מתארים שילובים של מוצרים, כמויות וקבוצות קונים. ערבוב מצבים בחוק אחד הוא סיבה נפוצה לכך שההנחה מונחת על עמדה לא נכונה או מתאפסת בחישוב מחדש של הסל.

עדיפות החלת החוקים נקבעת ידנית ומכריעה איזה מנגנון מנצח בחפיפה. אנחנו מתקבעים מטריצת עדיפויות ומריצים אותה על סלים לבדיקה: בודקים על איזה שיעור של עמדות ההנחה הונחה כמתוכנן, האם אין חיוב כפול והאם החישוב מחדש אחרי הסרת מוצר תקין. בנפרד בודקים תאימות עם מבצעים קיימים — חוק חדש לא אמור לבטל ישן בלי החלטה מפורשת.

איך אנחנו מיישמים: מביקורת הסל ועד מסירת נהלים

מתחילים בביקורת הסל: מוציאים את כל חוקי ההנחות הפעילים, בודקים איך הם חופפים ובאיזה שלב של הביצוע הם פועלים. לעיתים קרובות מקור הקונפליקט הוא לא ההנחה עצמה, אלא סדר ההחלה שלה: החוק פועל על עמדה, בעוד שמצפים שיפעל על ההזמנה, או שהמצטברות מחושבת לא במקום שבו תוכננה.

לכן קודם מרכיבים את סכמת החישוב, ורק אחר כך ניגשים להגדרה — אחרת התיקונים נבחרים בניסוי וטעייה ולא מתוכננים.

1. ביקורת הסל והלוגיקה הנוכחית. מיפוי מלא של חוקים פעילים, קודי קופון, הצמדות לקבוצות קונים ולסוגי משלמים, ונקודות הפעלה בשלבי הביצוע.
2. סכמת החישוב. מתקבעים את סדר ההחלה: מעמדה להזמנה, מה מסתכם, מה נדרס, ובאיזה רגע מחושבים עיגול ומיסים.
3. הגדרת החוקים. מעבירים את הסכמה לחוקי שיווק ולקודי קופון: תנאים לפי סכום הסל, הרכב ומדורים, מגבלות לפי ערוצים, תקופות ותדירות שימוש.
4. הזמנות בדיקה. סטים של ערכי ייחוס: סכום מינימלי, הרכב מעורב, החלה והסרה של קוד קופון, ביצוע חוזר, ביטול והחזרה.
5. בדיקת תרחישים. דוגמאות בקרה על הגבולות: סף בדיוק יחידה אחת, תחרות בין שני מבצעים, הנחה על מוצר שכבר מוזל, אורח מול קונה מזוהה.
6. מסירה לתפעול. נוהל תיקונים, יומן שינויים, אחראים על הפצת מבצעים וסדר חזרה מהירה של החוק האחרון.

כל שלב מסתיים בתוצאה שאפשר לבדוק: רשימת חוקים עם עדיפויות, סכמת חישוב עם דוגמאות, סט הזמנות בדיקה עם סכומים צפויים. אחרי המסירה לתפעול הצוות שלכם מפיץ מבצעים חדשים לפי הנוהל — בלעדינו ובלי סיכון לשבור הנחות שכבר עובדות.

מה אתם מקבלים: חוקים, קודי קופון, סכמות ונהלים

התוצאה של ההגדרה היא לא מבצעים בודדים, אלא קונטור מנוהל של הנחות על הזמנה ב-1C-Bitrix: חוקי שיווק, קופונים, סכמת עדיפויות ונוהל שלפיו המשווק משנה תנאים בלי לפגוע בסל ובביצוע ההזמנה. אנחנו מוסרים סט חפצים — לפיו מנהל חדש מסתדר בלי לפנות למפתח.

• תיאור החוקים — איזה תנאי (סכום, כמות, מוצר או קבוצה, תקופה, תפקיד הקונה) על מה משפיע ואיך משתלב עם האחרים.
• סכמת עדיפויות — טבלה של סדר ההפעלה: הנחה על הסל, הנחה על עמדה, קופון, מצטברת, אישית; רואים מה מוחל ראשון בחפיפה.
• מנגנונים מוגדרים — חוקי שיווק, קופונים עם מכסת שימושים ותוקף, הנחות לפי קבוצות קונים, מגבלות לפי אמצעי תשלום ומשלוח.
• תפקידים והרשאות — הפרדת זכויות של מנהל מערכת, מנהל תוכן ומפתח, כך שתיקון תנאים לא ייגע בהגדרות ביצוע ההזמנה.
• נוהל תיקונים — מה משתנה בממשק בכוחות השיווק, מה דורש מעורבות של מהנדס, ואיך מתועד כל שינוי.
• מדריך למנהל — תרחישים צעד-אחר-צעד: להוסיף חוק, לבדוק חפיפה, לכבות קופון, לראות היסטוריית הפעלות וביטולים בהחזרות.
• סט הזמנות לבדיקה — תרחישים שלפיהם נבדקת כל הנחה, הביטול שלה ונכונות הסכום הסופי במסמכים.

סכמת העדיפויות והנוהל סוגרים את הסיכון העיקרי: שני מבצעים באותה תקופה לא יתחילו להצטבר ולא ייתנו לקונה הנחה גדולה מהמתוכנן. תנאים שמתועדים בכתב שורדים החלפת ספק ותיקונים בביצוע ההזמנה.

מקרה בוחן: איך עלה שיעור ההמרה של הסל אחרי בנייה מחדש של החוקים

חנות על 1C-Bitrix חיה עם סט חוקים שהצטברו באופן ספונטני: חלק מההנחות חושבו במעבד של ביצוע ההזמנה, חלק במודולים חיצוניים של קודי קופון. לא הייתה עדיפות משותפת, ובחפיפה בין מבצעים הסיכום היה תלוי בסדר הקריאות: הקונה ראה סכום אחד בסל ואחר בשלב התשלום. בדיוק שם אבד החלק העיקרי של ההזמנות, וכל פער בסכום הפך לפנייה למנהל ולחישוב ידני מחדש.

מה שינינו

העברנו את החישוב לרמת הסל ואיחדנו את התנאים למנגנון אחד של חוקי שיווק: לכל אחד נוספו עדיפות, תחום החלה, תאימות עם קודי קופון ואיסור הצטברות עם מבצעים אחרים.

תנאים מצטברים — על נפח, על סגמנט לקוח, על רכישות חוזרות — מחושבים מהמחיר הבסיסי פעם אחת ולא מחושבים מחדש בכל שינוי בסל, ולכן הסכום הפסיק "לצוף".

הוויטרינה, המייל והחשבונית משתמשים כעת באותו חישוב, ולכן לא נותרים פערים ביניהם. הירידה בנטישות בשלב הביצוע נתנה את עיקר הגידול בהמרת הסל, ותנאים מצטברים צפויים החזירו קונים — שיעור הרכישות החוזרות יותר מהוכפל.

במה שונה קוד קופון מחוק סל ומה לבחור

קוד קופון הוא הנחה שהקונה מפעיל בעצמו: מזין קוד בסל, ורק אז היא מוחלת. חוק סל ב-1C-Bitrix פועל בלי מעורבות הקונה — המערכת עצמה בודקת את הסכום, הרכב המוצרים, קבוצת המשתמש והתקופה, ואז מחשבת מחדש את המחיר.

הבחירה תלויה בהיקף ובאופן שבו תנהלו את המכניקה בהמשך. קוד קופון מתאים כשההנחה מיועדת לקהל מצומצם: מנויי דיוור, משתתפי תוכנית שותפים. חוק לוקחים כשההנחה צריכה לעבוד לכולם: סף לפי סכום, הנחה מצטברת, מבחר מוצרי מבצע.

חפיפת תנאים היא המקור העיקרי לטעויות. אם על ההזמנה פועלים גם קוד קופון וגם חוק, הסיכום תלוי בעדיפות שנקבעה בהגדרות: המכניקות או מצטברות, או שאחת בולעת את השנייה. לפני ההרצה אנחנו מרכיבים מטריצת שילובים ומריצים הזמנות בדיקה על כל זוג — אחרת קל לתת הנחה גדולה מהמתוכנן.

בתחזוקה המכניקות נפרדות. רשימת קודי הקופון גדלה מהר: לכל אחד תוקף משלו, מכסת שימושים והצמדות לקונה, ובלי נוהל היא הופכת למאות קודים שאיש לא זוכר אילו מהם פעילים. חוקים מתוקנים באופן מרוכז במדור אחד, אבל תנאים מורכבים דורשים זהירות: תיקון של פרמטר אחד משנה את ההתנהגות של כל המבצע.

תשובה קצרה: קמפיינים ממוקדים עם שליטה בערוץ — קוד קופון; הנחות המוניות ומצטברות — חוק סל. בפרויקט אחד לעיתים קרובות נדרשות שתי המכניקות, ואז עדיפויות וחוקי שימוש משותף מונחים מלכתחילה.

ספקות טכניים: תאימות, קונפליקטים, חזרה לאחור

הנחות על הזמנה ב-1C-Bitrix מחושבות על ידי מנגנון אחד — חוקי השיווק של הסל והקופונים. לכן תנאים חדשים רק לעיתים רחוקות מתנגשים עם אלו שכבר הוגדרו: השאלה היא לא תאימות, אלא עדיפויות ההחלה והאם מותרת חפיפה של הנחות זו על זו.

לפני הפיתוח מוציאים את החוקים הפעילים ומרכיבים סט סלי בקרה, שעליהם בהמשך משווים את הסכומים הסופיים. זה גם נותן חזרה לאחור בטוחה: התצורה הקודמת מוחזרת במלואה, בלי תיקון ידני של תנאים.

אפשר להעביר את החישוב ממערכת אחרת?

את הלוגיקה מעבירים לחוקי שיווק ולקופונים: אותם תנאים, ספים וחריגים לפי מוצרים וקבוצות. אחר כך בודקים על הזמנות היסטוריות — הסיכום צריך להתאים לחישוב הקודם.

למה ההנחה הוחלה פעמיים?

התנאי פעל גם בחוק הסל וגם בקופון על אותו מוצר. מפרידים ביניהם לפי תחומי החלה, קובעים עדיפות ואוסרים חפיפה — או מעצבים במפורש הנחה מדורגת, שבה המדרגה השנייה תלויה בראשונה.

מה יקרה להזמנות אם במהלך הפיתוח משהו ילך לא כשורה?

עובדים על עותק, מפרסמים אחרי השוואה, ומייצאים את תצורת החוקים לפני כל שינוי. החזרה לחישוב הקודם לוקחת דקות, וכל הזמן הזה הקונה רואה מחירים רגילים.

נדון במשימה שלכם: שלחו את סכמת חישוב הסל

כדי לחזור עם הערכה ותוכנית עבודה, אנחנו צריכים נתוני מקור על המכניקה הנוכחית של הסל, ולא תיאור כללי של "צריך הנחות". ככל שתציגו בצורה מדויקת יותר איך מחושבים הסכומים כעת והיכן החוקים חופפים, כך תדרוש ההכנה פחות סבבי הבהרה.

• תנאי ההנחות: על אילו קבוצות מוצרים או מדורי קטלוג הן פועלות, מאיזה סכום הזמנה הן מופעלות, האם יש עיקרון מצטבר ותקופת תוקף.
• עדיפויות החוקים: מה צריך לנצח אם על סל אחד חלים כמה הנחות וקוד קופון — מחילים את המקסימלית, מסכמים או חוסמים חפיפות.
• חמש-שבע דוגמאות של הזמנות: הרכב הסל, קוד הקופון שהוחל, הסכום הסופי הצפוי והסכום לפני ההנחה — לפיהם נבדוק את לוגיקת החישוב על עותק בדיקה.
• התצורה הנוכחית: צילומי מסך או ייצוא של החוקים הקיימים לעבודה עם הסל, רשימת קודי הקופון הפעילים ותנאי המגבלות שלהם.
• נתוני אינטגרציה עם 1C: איך מגיעים המחירים וההנחות, האם יש מגבלות לפי מלאי ובאיזו תדירות מתעדכן הקטלוג.
• גישות לעותק בדיקה: סביבת בדיקה, חשבונות של התפקידים הנדרשים ורשימת מה שאסור לשנות בפרודקשן — תיקונים נבדקים בסביבה מבודדת.
• ההתנהגות הרצויה של הסל: ההנחה מחושבת על ההזמנה כולה או לפי עמדות, האם המשלוח נלקח בחשבון, ואיך מוצגת שורת ההנחה בביצוע.

תארו את המשימה בהיקף הזה — נחזור עם הערכה ותוכנית עבודה: נפרק את הלוגיקה לחוקים, נראה את סדר העדיפויות שלהם ונבדוק את החישוב על הדוגמאות שלכם לפני העלאה לאתר הפעיל.