אילו בעיות תמחור והנחות אופייניות אנחנו פותרים?
לעתים קרובות אנו נתקלים בתרחישים שבהם משווק מפעיל קמפיין "20% הנחה על מוצרי אלקטרוניקה", מנהל קובע ידנית מחיר מיוחד ללקוח VIP, ומערכת הנאמנות מוסיפה עוד 10%. התוצאה: הלקוח רואה 44% הנחה במקום 20% המתוכננים, והמוצר נמכר מתחת לעלות. שורש הבעיה הוא עדיפויות שגויות של כללי סל במודול sale וקונפליקטים בין סוגי מחירים ב-b_catalog_price. הגדרה נכונה של תמחור והנחות ב-1C-Bitrix מבטלת את הכאוס ושומרת על המרווחים גם עם מאות מבצעים פעילים. אנו יכולים להעריך את הפרויקט שלך ביום אחד—פשוט צור קשר.
כיצד להגדיר סוגי מחירים ולבחור אסטרטגיה?
Bitrix מאחסן מחירים בטבלת b_catalog_price—שורה אחת לכל סוג מחיר לכל מוצר. סוגי מחירים מוגדרים ב-b_catalog_group ומקושרים לקבוצות משתמשים דרך b_catalog_group2group. הגדרה נכונה של סוגי מחירים היא הבסיס לכל מנגנון הנחות.
| סוג מחיר | קישור | איך זה עובד |
|---|---|---|
| קמעונאי | קבוצת "כל המשתמשים" | מחיר ברירת מחדל באתר |
| סיטונאי | קבוצת "סיטונאים" | אוטומטית לאחר התחברות סיטונאי |
| משווק | קבוצת "משווקים" | מקדם אישי מהמחיר הבסיסי |
| רכישה | לצורכי חשבונאות פנימית בלבד | מחיר עלות, מוסתר מהמשתמשים |
| מחיר ישן | למחיר מחוק | "היה X, עכשיו Y" |
| אזורי | מקושר גיאוגרפית | מחירים בהתחשב בלוגיסטיקה אזורית |
עבור כל סוג, אנו מגדירים:
- חישוב אוטומטי באמצעות נוסחאות רווח/הנחה מהמחיר הבסיסי (handler
CCatalogProductProviderאוOnGetOptimalPrice) - כללי מטבע ועיגול ב-
b_catalog_rounding - ייבוא/ייצוא CSV וסנכרון 1C (CommerceML)
ריבוי מטבעות מיושם באמצעות עדכוני שערי חליפין עם \Bitrix\Currency\CurrencyManager::updateCBRFRates() או ידנית ב-b_catalog_currency. הצגת מחירים במטבע המשתמש נעשית באמצעות מיקום גיאוגרפי (דרך geoip) או הגדרות פרופיל. הנחות פועלות כראוי לאחר המרה: האחוז מחושב מהסכום המומר.
כללי סל: כיצד להימנע מקונפליקטי הנחות
המודול sale, סעיף "כללי סל" (/bitrix/admin/sale_discount.php), הוא בונה חוקים שאינו דורש כישורי פיתוח אך יכול בקלות לשבור הכל.
תרחישים נפוצים:
- הנחה לפי סכום:
BASKET_AMOUNT >= 5000 → DISCOUNT 10% - "3 במחיר 2" — תנאי על כמות בסל לפי קטלוג
- הנחת חבילה: "טלפון + נרתיק + זכוכית = 15% הנחה" — דרך כלל עם מספר תנאים
PRODUCT_ID IN (...) - טיימר: הנחה פעילה מ-23:00 עד 07:00 דרך שדות
ACTIVE_FROM/ACTIVE_TO - הנחה קבוצתית: בדיקת
USER_GROUPבתנאי הכלל
עדיפויות — איפה בדרך כלל טועים
שתי הנחות של 20% אינן שוות 40%. ביישום רציף: 100 → 80 → 64, כלומר 36% הנחה נטו. ביישום מקבילי: 100 − 20 − 20 = 60, כלומר 40% הנחה נטו. אם לא מגדירים עדיפויות, Bitrix עלול להחיל את שתיהן ככללים נפרדים ולתת 36% הנחה. או ההפך.
אנו מגדירים:
- שדה
PRIORITYלסדר היישום - דגל
LAST_DISCOUNT = Yלציון "אל תחיל הנחות נוספות אחרי זה" - אחוז מקסימלי דרך handler מותאם אישית
OnBeforeSaleOrderFinalAction - החרגת מוצרים/קטגוריות מהכללים דרך תנאי
EXCLUDE
הגדרת העדיפויות שלנו עם LAST_DISCOUNT מפחיתה את הסבירות לקונפליקטי הנחות פי חמישה בהשוואה ליישום כאוטי. ב-8 מתוך 10 חנויות שבהן הנחות "הצטברו" באופן בלתי צפוי, הבעיה הייתה עדיפויות והיעדר דגל LAST_DISCOUNT. אנו מתקנים זאת בשלב הביקורת.
כיצד להימנע מקונפליקטים בכללי סל?
ללא עדיפויות ברורות, קל לגרום למפל של הנחות בלתי מבוקרות. הפתרון הוא קביעת סדר היישום דרך PRIORITY ואיסור הנחות נוספות עם LAST_DISCOUNT = Y. למבצעים מורכבים (למשל, מצטבר + קוד קופון), אנו משתמשים ב-handlers מותאמים אישית המשווים את ההנחה הסופית מול המרווח המותר. כך הלקוח לעולם לא יוצא עם עגלה שאינה רווחית.
הנחות מצטברות ותוכניות נאמנות
ארבעה מודלים לבחירה:
- מבוסס סף — ההנחה עולה עם סכום הרכישה. פשוט יותר ללקוחות ולתמיכה.
- מבוסס נקודות — נקודות שנצברות מרכישות, נפדות לפרסים. גמיש יותר אך קשה יותר להבנה.
- מדורג — כסף/זהב/פלטינה. גימיפיקציה שומרת על לקוחות.
- קאשבק — מוחזר לחשבון פנימי (
b_sale_user_account).
מערכת ספים: דוגמת יישום
| טווח סכום רכישה | רמה | הנחה |
|---|---|---|
| עד סף מסוים | רגיל | 0% |
| מסכום בינוני | כסף | 5% |
| מסכום גבוה יותר | זהב | 10% |
| מעל הסף הגבוה ביותר | פלטינה | 15% |
טכנית: ה-handler OnSaleOrderPaid מחשב מחדש את סכום ההזמנות ששולמו דרך CSaleOrder::GetList() עם הפילטר PAYED = Y, מעדכן את קבוצת המשתמש דרך CUser::SetUserGroup(). הקבוצה מקושרת לסוג מחיר—ההנחה מוחלת אוטומטית בביקור הבא.
תכונות נוספות:
- הודעה "חסרים לך רק $X נוספים כדי להגיע לסטטוס זהב" — דרך רכיב מותאם אישית בחשבון האישי.
- תקופת תוקף לרמה — שנתית (מחושב מחדש על ידי
CAgent) או קבועה. - חישוב נפרד לפי קטגוריה — רכישות אלקטרוניקה אינן משפיעות על סטטוס הביגוד.
נוסחה לחישוב הנחה מצטברת
סכום ההזמנות ששולמו בתקופה (ברירת מחדל 12 חודשים) מסוכם, ואז מושווה לספים. כאשר מגיעים לסף חדש, המשתמש מועבר לקבוצה המתאימה. דוגמה: לקוח שביצע רכישות בסך $X — הוא ב"כסף" (5%). לאחר הרכישה הבאה של $Y, הסכום מגיע לסף גבוה יותר, מה שמפעיל מעבר ל"זהב" (10%).איך זה עובד בפועל: מקרה בוחן
לאחרונה הקמנו תוכנית נאמנות מבוססת ספים לחנות מקוונת למוצרי חשמל ביתיים עם מגוון של 15,000 פריטים. בעבר לא הייתה מערכת נאמנות, והנחות ניתנו ידנית על ידי מנהלים. יישמנו מערכת ספים בארבע רמות. תוצאה: רכישות חוזרות עלו ב-40% תוך שישה חודשים, והמרווחים לא ירדו—ההנחה רק לעתים רחוקות עלתה על 10% מהעגלה הממוצעת.
קודי קופון והאפשרויות שלהם
ניהול דרך CSaleDiscount וממשק ניהולי מותאם אישית:
- חד-פעמי — קוד ייחודי המקושר לקופון (
b_sale_discount_coupon). - רב-פעמי — קוד משותף עם מגבלת שימוש דרך
MAX_USE. - אישי — מקושר ל-
USER_ID. - יצירה המונית —
CSaleDiscountCoupon::Add()בלולאה, ייצור אלפים בדקה.
הגבלות: סכום הזמנה מינימלי, קטגוריות מוצרים, מגבלה למשתמש, תקופת תוקף, תאימות להנחות אחרות. סטטיסטיקות—מי השתמש באיזה קוד, מתי, ועם איזה סכום עגלה—דרך דוח על b_sale_discount_coupon עם JOIN על b_sale_order. קישור לתגי UTM מראה איזה ערוץ באמת מניב המרות.
תמחור סיטונאי (B2B)
מנגנונים שאינם זמינים כברירת מחדל:
- מעבר אוטומטי של סוג מחיר כאשר כמות > N דרך handler
OnGetOptimalPrice. - הצגת טווח מחירים בכרטיס המוצר דרך רכיב מותאם אישית: "1–9 יח': $X, 10–49: $Y, 50–99: $Z, 100+: $W".
- מחירונים אישיים — יצירת PDF/Excel מהחשבון האישי באמצעות PhpSpreadsheet.
- טופס בקשת מחיר מיוחד → ליד ב-CRM.
- מסגרת אשראי ותשלום דחוי דרך
b_sale_user_accountו-handler תשלום מותאם אישית.
מבצעים והתאמה אישית
תזמון דרך ACTIVE_FROM / ACTIVE_TO — התחלה וסיום אוטומטיים. טיימר ספירה לאחור — רכיב JS המקושר ל-ACTIVE_TO של הפריט. הגבלת כמות פריט במבצע דרך מאפיין QUANTITY_LIMIT ובדיקות handler בעגלה. סעיף "מבצעים" — דרך פילטר חכם על מאפיין IS_SALE = Y.
סוגים: מכירה, מוצר היום (מסתובב על ידי agent), מבצע בזק, סוף עונה, עונתי. התאמה אישית:
- הנחות VIP דרך קבוצת משתמשים אישית → סוג מחיר אישי.
- תנאים ארגוניים: תשלום דחוי, משלוח מותאם.
- פילוח התנהגותי דרך
b_sale_order→ הקצאת הנחות אוטומטית. - תמחור דינמי — מודול מותאם אישית המתאים מחיר לפי ביקוש, מלאי ומחירי מתחרים.
אינטגרציה עם 1C
- ייבוא סוגי מחירים דרך CommerceML (החלפה סטנדרטית
bitrix:catalog.import.1c). - סנכרון כרטיסי הנחה: מספר כרטיס → קבוצת משתמש → סוג מחיר.
- כללי עיגול ומע"מ — התאמה בין 1C ל-Bitrix כדי להבטיח שמחיר האתר תואם לחשבונית.
- עדכונים מתוזמנים (cron + agent) או בזמן אמת דרך REST API.
כיצד אנו מגדירים מחירים והנחות: תהליך שלב אחר שלב
- ביקורת מערכת התמחור הנוכחית — זיהוי קונפליקטי כללים, שגיאות עדיפות, סוגי מחירים שאינם בשימוש.
- פיתוח תוכנית הנחות — בהתחשב במרווחים ובלוגיקה העסקית (מצטבר, סיטונאי, קודי קופון, התאמה אישית).
- הגדרת כללי סל — עדיפויות, דגלים, חריגים.
- אינטגרציית 1C — סנכרון סוגי מחירים, כרטיסי הנחה, עיגול.
- בדיקות — בדיקות עומס עם 100+ כללים פעילים, בדיקות קונפליקטים.
- תיעוד — תיאור כל ההגדרות, הוראות למשווקים.
- הדרכת מנהלים — כיצד ליצור ולהשבית מבצעים ללא סיכון.
- תמיכה ל-30 יום — תיקון כל חריגה לאחר ההשקה.
לוחות זמנים
| משימה | לוח זמנים |
|---|---|
| ביקורת והגדרת סוגי מחירים | 2–3 ימים |
| כללי סל בסיסיים | 3–5 ימים |
| מערכת הנחות מצטברות | 1–2 שבועות |
| תמחור B2B | 2–4 שבועות |
| מערכת קודי קופון | שבוע אחד |
| מערכת תמחור מקיפה | 4–8 שבועות |
העלות מחושבת באופן אישי—היא תלויה בעומק הביקורת ובמספר המוצרים. הניסיון המצטבר שלנו (מעל 7 שנים) ומומחים מוסמכים מבטיחים שהמרווחים שלך יישארו תחת שליטה. קבל ייעוץ בנושא תמחור והגדרת הנחות—צור קשר, ונעריך את הפרויקט שלך ביום אחד.

