פיתוח מודול כללי מחירים ל-1C-Bitrix

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

הכישורים שלנו:

שאלות נפוצות

פיתוח מודול כללי מחירים ל-1C-Bitrix

תארו לעצמכם: מנהל רוצה להגדיר מבצע "15% הנחה על כל פריטי מותג X ללקוחות ממוסקבה שסכום ההזמנות שלהם ב-30 הימים האחרונים עולה על $90–130, אבל רק אם העגלה אינה מכילה פריטים מקטגוריה Y." מודול ההנחות המובנה של Bitrix (sale) מטפל במקרים פשוטים, אך תנאים משולבים הכוללים היסטוריית הזמנות או לוגיקה אזורית דורשים או קוד מאולתר בתבנית העגלה או מודול נפרד. אנו מתמחים בבניית מודולים כאלה במפתח-סוהר—זה מונע שינויים מסורבלים בליבה ושומר על תאימות לעדכוני מערכת.

מדוע מודול ההנחות המובנה אינו מספק

הנחות מובנות ב-sale פועלות דרך טבלת b_discount וסוגי תנאים מוגדרים מראש: קבוצת משתמשים, סכום הזמנה, סט מוצרים. אירוע OnGetDiscountConditionTypes מאפשר הוספת תנאים מותאמים אישית, אך היכולות שלו מוגבלות—לא ניתן לשלב תנאים בגמישות או להוסיף תלות בהיסטוריית הזמנות באמצעים סטנדרטיים. יתרה מכך, הביצועים סובלים: עם 5–10 כללים, שאילתה ל-b_discount_condition יכולה לקחת 0.2–0.5 שניות לכל בדיקה, ועם 50 כללים עד 2 שניות, דבר קריטי לחנויות בעלות עומס גבוה. בתיעוד 1C-Bitrix, האירוע מתואר כנקודת הרחבה אך אינו מבטיח ביצועים לשרשראות מורכבות.

תכונות מודול כללי המחירים

המודול המותאם אישית שלנו בנוי על גבי sale, מבלי לגעת בליבה—החלטה מרכזית שמבטיחה תאימות לסנכרון 1C ואינטגרציות צד שלישי. אנו משתמשים במטמון מתויג לתנאים כדי למזער עומס על מסד הנתונים. לדוגמה, מודול בסיסי עולה מ-$2,500 ויכול לחסוך עד $15,000 בשנה, עם החזר השקעה בפחות משישה חודשים.

מנוע הכללים מאחסן תצורות בטבלה ייעודית myvendor_price_rules. כל כלל הוא מבנה JSON עם תנאים ופעולות:

לחצו לראות דוגמת JSON של כלל
{
  "conditions": [
    {
      "type": "user_group",
      "value": [5, 8]
    },
    {
      "type": "region",
      "value": ["RU-MOW"]
    },
    {
      "type": "order_history_sum",
      "period_days": 30,
      "min_sum": 10000
    }
  ],
  "condition_operator": "AND",
  "actions": [
    {
      "type": "percent_discount",
      "value": 15,
      "target": "brand_X_items"
    }
  ],
  "priority": 100,
  "stackable": false
}

מעריך התנאים הוא אוסף של מחלקות אסטרטגיה המיישמות { "conditions": [ {"type": "user_group", "value": [5, 8]}, {"type": "region", "value": ["RU-MOW"]}, {"type": "order_history_sum", "period_days": 30, "min_sum": 10000} ], "condition_operator": "AND", "actions": [ {"type": "percent_discount", "value": 15, "target": "brand_X_items"} ], "priority": 100, "stackable": false } . תנאים הדורשים שאילתות מסד נתונים (היסטוריית הזמנות) נשמרים במטמון בתוך בקשה אחת באמצעות מערך סטטי.

פירוט: תנאי היסטוריית הזמנות

זהו התנאי היקר ביותר. ללא אופטימיזציה, שאילתת צבירה על ConditionInterface::check() ל-30 יום יכולה להיות איטית. אנו משתמשים בגישה זו:

לחצו לראות דוגמת קוד PHP
$cacheKey = "order_history_{$userId}";
if (!isset($_SESSION['price_rules_cache'][$cacheKey])) {
    $sum = \Bitrix\Sale\OrderTable::getList([
        'filter' => [
            '=USER_ID' => $userId,
            '>=DATE_INSERT' => (new \Bitrix\Main\Type\DateTime())->add('-30D'),
            '=CANCELED' => 'N',
        ],
        'runtime' => [
            new \Bitrix\Main\Entity\ExpressionField('TOTAL', 'SUM(%s)', 'PRICE'),
        ],
    ])->fetch()['TOTAL'] ?? 0;
    $_SESSION['price_rules_cache'][$cacheKey] = (float)$sum;
}

תנאי החרגה (חסימה כאשר קיים פריט מקטגוריה Y) מיושמים באמצעות סוג b_sale_order נפרד.

כיצד להבטיח ביצועים עם כללים רבים?

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

תוצרי הפרויקט

כל פרויקט כולל את התוצרים הבאים:

  1. ניתוח הנחות קיימות ב-$cacheKey = "order_history_{$userId}"; if (!isset($_SESSION['price_rules_cache'][$cacheKey])) { $sum = \Bitrix\Sale\OrderTable::getList([ 'filter' => [ '=USER_ID' => $userId, '>=DATE_INSERT' => (new \Bitrix\Main\Type\DateTime())->add('-30D'), '=CANCELED' => 'N', ], 'runtime' => [ new \Bitrix\Main\Entity\ExpressionField('TOTAL', 'SUM(%s)', 'PRICE'), ], ])->fetch()['TOTAL'] ?? 0; $_SESSION['price_rules_cache'][$cacheKey] = (float)$sum; } וייבוא כללים קיימים.
  2. עיצוב ארכיטקטורת תנאים ופעולות (עד 10 סוגים בגרסה הבסיסית).
  3. מימוש מודול עם מטמון מתויג ומטפלי אירועים.
  4. אינטגרציה עם העגלה דרך אירועי ExclusionCondition ו-b_discount.
  5. ממשק ניהולי: בונה כללים ויזואלי, תצוגה מקדימה של התאמה, היסטוריית הפעלות.
  6. תיעוד מלא (מדריך משתמש, הפניה ל-API, מפרט טכני) והדרכת מנהלים.
  7. גישה לקוד מקור מלא (מאגר Git).
  8. 3 חודשי תמיכה טכנית ואחריות על המודול.

השוואת ביצועים

פרמטר מודול סטנדרטי המודול שלנו
זמן בדיקה לכל כלל 0.1–0.5 שניות 0.02–0.1 שניות (עם מטמון)
תמיכה באזור לא כן, דרך קוד אזור
גמישות תנאים 15 סוגים מוגדרים מראש סוגים בלתי מוגבלים
עדיפויות לפי תאריך יצירה ניתנות להתאמה, גרירה ושחרור

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

לוח זמנים ועלות פיתוח

היקף הרכב לוח זמנים עלות (USD)
בסיסי עד 5 סוגי תנאים + הנחות אחוז וקבועות 3–4 שבועות מ-$2,500
בינוני + היסטוריית הזמנות + לוגיקה אזורית + עדיפויות 5–7 שבועות מ-$5,000
מלא + בונה ויזואלי + אנליטיקה + בדיקות A/B 8–12 שבועות מ-$10,000

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

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

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