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

מדוע הנחות לפי לוח זמנים ב-Bitrix נשברות בקטלוג חי

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

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

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

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

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

מה נותנת האוטומציה של מחירי מבצע: אפקט מדיד בפועל

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

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

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

כיצד להגדיר הנחות לפי לוח זמנים ב-Bitrix: אפשרויות ומגבלות

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

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

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

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

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

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

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

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

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

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

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

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

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

לפני: הכנת מבצע ידנית

ההכנה נמשכה כעשרה ימי עבודה. במבצע השתתפו כ-3,800 פריטים, ובכל גל 5–7% מהשורות עלו לחזית החנות עם מחיר שגוי — לאחר כיבוי ההנחה מחיר הבסיס לא חזר לכל המוצרים. חזית החנות והגשת ההזמנה הציגו סכומים שונים, וחלק מהפריטים נפלו מהמבצע רק משום שלא הספיקו להגיע אליהם.

אחרי: כללים ולוח זמנים

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

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

מה לעשות אם הקטלוג מתעדכן לעתים קרובות יותר מכללי המבצעים?

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

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

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

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

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

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

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

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

שאלות טכניות נפוצות לפני תחילת ההגדרה

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

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

כיצד מגדירים קבוצות מוצרים ואזורים?

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

מה יקרה להזמנות שהוגשו במהלך המבצע?

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

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

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

נדון במשימה: שלחו מבנה קטלוג וכללי מבצעים

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

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

שלחו את מה שיש בהישג יד — אפילו סט חלקי יאיץ את הניתוח:

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

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