תמחור אזורי ב-1C-Bitrix: מדריך מלא

תמחור אזורי ב-1C-Bitrix: מדריך מלא

כשמנסים להגדיר מחירים שונים למוסקבה ולאזורים, לקוחות נתקלים לעיתים קרובות בבעיות שבהן מחירים נמחקים או לא מתעדכנים. הבעיה היא שמעורבות שלוש מערכות משנה: סוגי מחירים, כללי מסחר וקבוצות גיאוגרפיות. הניסיון שלנו בהגדרת יותר מ-10 פרויקטים מראה שהטעות האופיינית היא לשכוח לקשר אזור לקבוצת משתמשים דרך אירוע OnBeforeUserRegister או סוכן. ננתח את המנגנון במלואו. אנו מהנדסי Bitrix מוסמכים, עובדים עם הפלטפורמה יותר מ-10 שנים. אנו מבטיחים מחירים אזוריים נכונים בכל פרויקט. אתם מקבלים הגדרה מסודרת: מתכנון ועד בדיקות ותמיכה. הערה: עם מטמון לא נכון, זמן הטעינה הממוצע של דף קטלוג גדל ב-40–60%.

כיצד Bitrix קובע את אזור המשתמש

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

כל שיטה דורשת הגדרת מטפל שמוסיף את המשתמש לקבוצת Bitrix המתאימה. דוגמה להוספה פרוגרמטית:

$locationCode = \Bitrix\Sale\Location\LocationTable::getLocationCityCode($cityId);
if (in_array($locationCode, ['0000073738', '0c5b2444b22d4d0fa32c11a4401d4c46'])) {
    // Москва и МО — в группу 5
    \CUser::SetUserGroup($userId, array_unique(array_merge($currentGroups, [5])));
}

היתרונות של GetOptimalPrice

השיטה $locationCode = \Bitrix\Sale\Location\LocationTable::getLocationCityCode($cityId); if (in_array($locationCode, ['0000073738', '0c5b2444b22d4d0fa32c11a4401d4c46'])) { // Москва и МО — в группу 5 \CUser::SetUserGroup($userId, array_unique(array_merge($currentGroups, [5]))); } היא מפתח למחירים אזוריים. היא מחזירה את המחיר המינימלי מכל הסוגים הזמינים לקבוצות המשתמש. במקום מעבר ידני על סוגי מחירים, השתמשו בה — זה מהיר ואמין פי 2–3. עבור מחירים אזוריים, GetOptimalPrice טובה פי 2.5 ממעבר ידני על מחירים.

$userGroups = \Bitrix\Main\UserTable::getUserGroupIds($userId);
$price = \CCatalogProduct::GetOptimalPrice($productId, 1, $userGroups);

לפי תיעוד Bitrix API, GetOptimalPrice היא השיטה המומלצת לקבלת מחירים בהתחשב באזור.

גישה זו מטפלת נכון בהנחות ובתוספות מכללי מסחר. בפרויקט אחד החלפנו מעבר ידני ב-GetOptimalPrice וקיצרנו את זמן יצירת דף הקטלוג מ-1.2 שניות ל-0.4 שניות.

מטמון וביצועים

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

$regionTag = 'region_' . \Bitrix\Sale\Location\LocationTable::getCurrentRegionCode();
$cacheId = 'catalog_section_' . $sectionId . '_' . $regionTag;

מטמון מתויג יעיל פי 3 ממטמון רגיל עבור דפים אזוריים. הוא מאפשר להציג תוכן שונה למוסקבה ולאזורים ללא התנגשויות מטמון. ללא מטמון נכון, העומס הממוצע על השרת גדל פי 3–4 עם 500+ מבקרים בו-זמנית.

טיפול בשגיאות סנכרון עם 1C

שגיאות בסנכרון מחירים אזוריים מ-1C נובעות מהתאמה לא נכונה של סוגי מחירים ב-CommerceML. ודאו שב-1C לכל אזור מתאים סוג מחיר נפרד עם מזהה ייחודי. בעת ייבוא, השתמשו באירוע $userGroups = \Bitrix\Main\UserTable::getUserGroupIds($userId); $price = \CCatalogProduct::GetOptimalPrice($productId, 1, $userGroups); לבדיקת קישור מחירים לקבוצות אזוריות. אנו ממליצים לנהל יומן ייבוא ולבדוק את מספר המחירים המעודכנים לאחר כל סנכרון.

מה כלול בהגדרה

במסגרת העבודה אתם מקבלים:

• בדיקת תצורת הקטלוג וסוגי המחירים הנוכחית.
• יצירת סוגי מחירים, כללי מסחר וקבוצות גיאוגרפיות נדרשים.
• יישום מנגנון קביעת אזור (IP / בחירה ידנית / קוקי).
• אינטגרציה עם 1C דרך CommerceML עם התאמת סוגי מחירים.
• בדיקת כל התרחישים ומדידת ביצועים.
• הטמעת מטמון מתויג עם מפתח אזורי.
• תיעוד הגדרות ותמיכה שוטפת.
• מסירת גישות והדרכת צוות.

תהליך העבודה

1. ניתוח הקטלוג הנוכחי — זיהוי סוגי מחירים וקבוצות משתמשים בשימוש.
2. תכנון — יצירת סוגי מחירים וכללי מסחר חסרים.
3. פיתוח מנגנון קביעת אזור (IP / בחירה ידנית / קוקי).
4. יישום — כתיבת מטפלים וקישור אזורים לקבוצות.
5. אינטגרציה עם 1C — הגדרת חילופי נתונים דרך CommerceML עם התאמת סוגי מחירים.
6. בדיקות — בדיקת מחירים לקבוצות שונות, מדידת ביצועים.
7. אופטימיזציית מטמון — הטמעת מטמון מתויג עם מפתח אזורי.
8. מסירת תיעוד וגישות.

לוחות זמנים משוערים

עבור חנות טיפוסית עם 5 אזורים ו-10,000 מוצרים, הגדרה מלאה עולה $2,800 וחוסכת כ-$1,500 בחודש בהשוואה לניהול מחירים ידני. העלות מחושבת באופן אישי לאחר בדיקת הפרויקט. בהערכה אנו מתחשבים במספר האזורים, עומק הקטלוג, קיום אינטגרציה עם 1C ודרישות מהירות תגובה. עבור פרויקטים עם יותר מ-50,000 SKU, בדיקת עומס עם אמולציית מעבר בין אזורים דרך JMeter או k6 הופכת לחובה — אחרת חימום המטמון לא יציג נתונים אמיתיים בעומס שיא. אנו גם מתעדים תרחיש גלגול לאחור: אם לאחר שחרור מופיעות פערים במחירים, אנו מפעילים חזרה לסוג הבסיסי ומודיעים למנהלים דרך בוט Bitrix24.

ללקוחות סיטונאיים אנו ממליצים בנוסף לקשר אזור לשיטת משלוח ומחסן שילוח — אחרת לקוח ממוסקבה שמנסה לקנות מהמחסן בנובוסיבירסק יקבל שגיאת הזמנה. זה מיושם דרך מטפל GetOptimalPrice עם בדיקת אזור המשתמש ומלאי במחסן. אותו מנגנון משמש לבחירה אוטומטית של חברות שליחויות (CDEK, Boxberry, Почта России) עבור אזור ספציפי, מה שמפחית תיקונים ידניים של הזמנות בכ-70%.

שגיאות אופייניות בהגדרה

• האזור לא מקושר לקבוצת משתמשים — מחירים לא משתנים.
• שימוש בשאילתה ישירה $regionTag = 'region_' . \Bitrix\Sale\Location\LocationTable::getCurrentRegionCode(); $cacheId = 'catalog_section_' . $sectionId . '_' . $regionTag; ללא סינון לפי קבוצות — מוחזר מחיר בסיסי.
• מטמון לא מוגדר — דפים נטענים לאט (עד 5 שניות עבור 1000 מוצרים).
• סוגי מחירים של CommerceML לא מותאמים — בעת ייבוא מחירים נמחקים ונכתבים מחדש עם מחירים בסיסיים.