הגדרת עיגול מחירים ב-1C-Bitrix: דיוק ושיווק
לעתים קרובות אנו נתקלים במצב הבא: לקוח מעדכן את 1C, והאתר מציג מחיר של 3–4 דולרים עבור פריט שעולה 3–5 דולרים עם הנחה של 7%. מנהלים מתלוננים על מחירים "מכוערים", מחלקת הנהלת החשבונות על אי-התאמות עם 1C. עיגול מחירים ב-Bitrix הוא הנקודה שבה תוצאה נכונה מתמטית הופכת לארטפקט אם הכללים לא מוגדרים כראוי. הניסיון שלנו מראה: כללי עיגול מוגדרים כראוי חוסכים שעות של אישורים ומגבירים את אמון הלקוחות. בפרויקט אחד עם קטלוג של 50,000 פריטים ושלושה סוגי מחירים, תיקון ידני לקח עד 3 שעות ביום — לאחר אוטומציה של העיגול, הבעיה נפתרה תוך 4 שעות. הגישה שלנו מקצרת את זמן הגדרת הכללים פי 3 בהשוואה לפתרונות טיפוסיים.
עם ניסיון של 10+ שנים, השלמנו מעל 200 פרויקטים של Bitrix ואנו מוסמכים כ"1C-Bitrix: Developer". כל פתרון נבדק על עותק של האתר לפני הפריסה.
מידע נוסף על פסיכולוגיית התמחור — בויקיפדיה
היכן מגדירים עיגול?
Настройки → Настройки продуктов → Каталог → Округление цен. בגרסאות מוקדמות יותר, זה היה בהגדרות הרכיב של bitrix:catalog.element ו-bitrix:catalog.section עם פרמטרים PRICE_VAT_INCLUDE ועיגולים נפרדים.
כללי עיגול גלובליים — CCatalogProduct::getRoundRules() קורא מ-b_catalog_rounding_rule. הטבלה פשוטה: מזהה סוג מחיר, טווח, סוג ודיוק. אבל בפרויקטים עם עשרות סוגי מחירים ולוגיקת הנחות מורכבת, הגדרה ידנית דרך הניהול הופכת לסיוט. אנו כותבים סקריפטים של מיגרציה באמצעות \Bitrix\Catalog\RoundingTable.
אילו סוגי כללי עיגול תומך Bitrix?
| כלל | תיאור | דוגמה |
|---|---|---|
| מתמטי | סטנדרטי: 0.5 → למעלה | 324.57 → 325 |
| תמיד למטה | floor() |
324.57 → 324 |
| תמיד למעלה | ceil() |
324.01 → 325 |
| לספרה רצויה | דיוק בהגדרות | 324.57 → 320 או 324.6 |
עיגול מתמטי — הבחירה הבסיסית לחשבונאות, אבל הוא לא נותן מחירים "יפים" לחנות. עיגול למטה משמש לעתים קרובות בשיווק: מחיר 324 במקום 324.57 נראה אטרקטיבי יותר. עיגול למעלה נדיר, כאשר צריך להימנע מהפסד על אגורות.
כיצד אנו מגדירים עיגול: מקרה אמיתי
בפרויקט אחד עם קטלוג של 50,000 פריטים ושלושה סוגי מחירים (קמעונאי, סיטונאי, סיטונאי קטן), המשימה הייתה: לקמעונאי, עיגול למטה למספרים שלמים; לסיטונאי, עיגול למעלה לעשרות; לסיטונאי קטן, מתמטי ל-0.1. בנוסף, עבור מחירים מעל 90–130 דולרים — כלל נפרד. כתבנו סקריפט ב-PHP 8.1 באמצעות \Bitrix\Catalog\RoundingTable::add() ומיגרציה דרך Yurii\BitrixModels\Migration. כל התהליך לקח 4 שעות, כולל בדיקות על עותק. לאחר הפריסה, אי-ההתאמות עם 1C נעלמו, ומנהלים הפסיקו לתקן מחירים ידנית.
// Добавление правила округления
\Bitrix\Catalog\RoundingTable::add([
'CATALOG_GROUP_ID' => $priceTypeId, // 0 = все типы цен
'PRICE_FROM' => 0,
'PRICE_TO' => 999.99,
'ROUND_TYPE' => \Bitrix\Catalog\RoundingTable::ROUND_MATH,
'ROUND_PRECISION' => 0, // до целых
]);
// Для цен от 1000 — другое правило
\Bitrix\Catalog\RoundingTable::add([
'CATALOG_GROUP_ID' => $priceTypeId,
'PRICE_FROM' => 1000,
'PRICE_TO' => null,
'ROUND_TYPE' => \Bitrix\Catalog\RoundingTable::ROUND_MATH,
'ROUND_PRECISION' => -1, // до десятков
]);
// Добавление правила округления \Bitrix\Catalog\RoundingTable::add([ 'CATALOG_GROUP_ID' => $priceTypeId, // 0 = все типы цен 'PRICE_FROM' => 0, 'PRICE_TO' => 999.99, 'ROUND_TYPE' => \Bitrix\Catalog\RoundingTable::ROUND_MATH, 'ROUND_PRECISION' => 0, // до целых ]); // Для цен от 1000 — другое правило \Bitrix\Catalog\RoundingTable::add([ 'CATALOG_GROUP_ID' => $priceTypeId, 'PRICE_FROM' => 1000, 'PRICE_TO' => null, 'ROUND_TYPE' => \Bitrix\Catalog\RoundingTable::ROUND_MATH, 'ROUND_PRECISION' => -1, // до десятков ]); — מספר המקומות העשרוניים (ערכים שליליים מעגלים לעשרות, מאות). חשוב: אם יש לכם סוגי מחירים עם מע"מ, העיגול מוחל לפני הוספת המס. זו התנהגות סטנדרטית אבל לעתים קרובות מעלה שאלות.
מדוע העיגול בעגלה שונה מהחנות?
כללי העיגול מוחלים בעת חישוב המחיר הסופי דרך ROUND_PRECISION. ברכיב העגלה, זה בעת חישוב מחדש של סכום השורה. אבל הנחות, קופונים ומע"מ יכולים לעוות את התוצאה. לדוגמה: בחנות, מחיר עם מע"מ הוא 11–16 דולרים, ללא מע"מ — 9–13 דולרים. בעגלה, בעת החלת הנחה של 10%, המחיר הבסיסי מתעגל ל-1080 (עם מע"מ) או 900 (ללא). אם מע"מ מתווסף לאחר העיגול, הסכום הכולל עשוי לסטות באגורות. זה נורמלי ומוסדר על ידי הגדרות הרכיב המורכב.
תמחור פסיכולוגי
עבור מחירים כמו ".99", כללי עיגול אינם מתאימים — זו משימה שיווקית שנפתרת על ידי handler של פוסט-פיקס. לדוגמה, handler לאירוע עבור CCatalogProduct::GetOptimalPrice() או שיטת חישוב מחיר מותאמת אישית. אנו מיישמים תרחישים כאלה במפתח פתוח: מגדירים לוגיקה "המחיר תמיד מסתיים ב-9", "עיגול ל-49 או 99 אגורות" וכו'.
מה כלול בעבודה
- ביקורת של כללי העיגול הנוכחיים: ניתוח טבלת
OnSaleOrderBeforeSaved, זיהוי כפילויות וקונפליקטים. - פיתוח כללים מותאמים אישית: כתיבת סקריפטים של מיגרציה, handlers מותאמים למחירים פסיכולוגיים.
- בדיקות על עותק של האתר: בדיקת כל סוגי המחירים, הנחות, עגלה, ייצוא ל-1C.
- תיעוד: תיאור הכללים שנוצרו, הוראות למנהלים.
- הדרכה: כיצד להוסיף כללים חדשים דרך ה-API, לא דרך הניהול.
לוחות זמנים ואחריות
הגדרה בסיסית של כללי עיגול לכל סוגי המחירים — בין שעה ל-3 שעות. לוגיקה לא סטנדרטית (מחירים פסיכולוגיים, כללים שונים לקטגוריות, אינטגרציה עם 1C) — בין 4 ל-8 שעות. אנו מבטיחים שלאחר ההגדרה, המחירים בחנות ובעגלה יוצגו כראוי, ואי-ההתאמות עם 1C יבוטלו. אנו נעריך את הפרויקט שלכם — קבלו ייעוץ על ידי פנייה אלינו בצ'אט או במייל. הניסיון של הצוות שלנו: 10+ שנים בפיתוח Bitrix, מעל 200 פרויקטים שהושלמו, הסמכה "1C-Bitrix: Developer".
השוואת גישות עיגול
בואו נשווה גישות. עיגול מתמטי (ROUND_MATH) נותן דיוק חשבונאי אבל נראה מכוער בחנות. עיגול למטה (ROUND_DOWN) אטרקטיבי ללקוחות אבל מקטין מעט את המרווח. עיגול למעלה (ROUND_UP) מגן מפני הפסד, אבל לקוחות עשויים להבחין בתמחור יתר. handler פסיכולוגי מספק אפקט שיווקי אבל דורש פיתוח. עבור רוב הפרויקטים, אנו ממליצים על שילוב: לקמעונאי — עיגול למטה למספרים שלמים, לסיטונאי — מתמטי לעשרות, ולמחירי מבצע — handler מותאם אישית.
מדריך שלב-אחר-שלב להגדרת כללי עיגול
1. קבעו סוגי מחירים ודרישות דיוק לכל אחד. 2. כתבו סקריפט מיגרציה באמצעות `\Bitrix\Catalog\RoundingTable::add()`. 3. בדקו על עותק של האתר: בדקו חנות, עגלה, ייצוא ל-1C. 4. תעדו את הכללים למנהלים. 5. הדריכו את הצוות להוסיף כללים חדשים דרך ה-API.פנו אלינו כדי לדון בפרויקט שלכם. אנו ננתח את הכללים הנוכחיים שלכם ונציע את הפתרון האופטימלי.

