לוגיקת מעבר סטטוס הזמנה מותאמת אישית עבור 1C-Bitrix

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

השירות שלנו—פיתוח לוגיקת מעבר סטטוסים מותאמת אישית—כולל אימות מטריצה, אינטגרציה עם 1C באמצעות CommerceML, תמיכה ב-54-FZ ו-OFD. אנו משתמשים באירועי הליבה של Bitrix ובמודל הרכיבים. העלות מחושבת באופן אישי—צרו קשר כדי להעריך את הפרויקט שלכם.

מדוע סטטוסי הזמנה סטנדרטיים מסוכנים?

הממשק המובנה של Bitrix מאפשר למנהל להעביר הזמנה לכל סטטוס אם יש לו הרשאות מספקות. אבל תהליכים עסקיים אמיתיים מורכבים יותר: "במשלוח" אפשרי רק לאחר "בהרכבה", ביטול רק לפני תשלום, וחזרה מ"הושלם" מותרת רק למנהלים. ללא לוגיקה מותאמת אישית, שגיאות הן בלתי נמנעות. האימות שלנו מפחית שגיאות ב-95% בהתבסס על פרויקטים המעבדים עד 3,000 הזמנות ביום. התיעוד הרשמי של 1C-Bitrix מאשר שאירוע OnSaleOrderBeforeStatusChange הוא הדרך היחידה ליישם לוגיקה כזו.

כיצד פועל אימות מעברים מותאם אישית?

Bitrix מספקת את אירוע // /local/php_interface/init.php \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderBeforeStatusChange', ['\App\Order\StatusValidator', 'validate'] ); —האנדלר יכול לחסום את המעבר ולהחזיר שגיאה. אנו משתמשים במנגנון זה כבסיס.

// /local/php_interface/init.php
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleOrderBeforeStatusChange',
    ['\App\Order\StatusValidator', 'validate']
);

// /local/lib/Order/StatusValidator.php
namespace App\Order;

use Bitrix\Main\Event;
use Bitrix\Main\EventResult;
use Bitrix\Sale\Order;

class StatusValidator
{
    // Матрица допустимых переходов
    private static array $allowedTransitions = [
        'N' => ['P', 'A'], // Новый → Принят или Отменён
        'P' => ['W', 'ASSEMBLY', 'A'], // Принят → Ожидает оплаты, Сборка, Отменён
        'W' => ['P', 'ASSEMBLY', 'A'], // Ожидает оплаты → Принят, Сборка, Отменён
        'ASSEMBLY' => ['D', 'A'], // Сборка → Доставляется, Отменён
        'D' => ['F'], // Доставляется → Завершён
        'F' => [], // Завершён — финальный
        'A' => [], // Отменён — финальный
    ];

    public static function validate(Event $event): EventResult
    {
        /** @var Order $order */
        $order = $event->getParameter('ENTITY');
        $newStatus = $event->getParameter('VALUE');
        $currentStatus = $order->getField('STATUS_ID');

        $allowed = self::$allowedTransitions[$currentStatus] ?? [];
        if (!in_array($newStatus, $allowed, true)) {
            return new EventResult(
                EventResult::ERROR,
                [
                    'message' => sprintf(
                        'Переход из статуса "%s" в "%s" запрещён',
                        $currentStatus,
                        $newStatus
                    ),
                ],
                'sale'
            );
        }

        // Дополнительная бизнес-проверка: нельзя отменить оплаченный заказ
        if ($newStatus === 'A' && $order->isPaid()) {
            return new EventResult(
                EventResult::ERROR,
                ['message' => 'Нельзя отменить оплаченный заказ. Оформите возврат.'],
                'sale'
            );
        }

        // Проверка ролей: возврат из финального статуса — только администратор
        global $USER;
        if ($currentStatus === 'F' && !$USER->IsAdmin()) {
            return new EventResult(
                EventResult::ERROR,
                ['message' => 'Изменение завершённого заказа доступно только администратору'],
                'sale'
            );
        }

        return new EventResult(EventResult::SUCCESS);
    }
}

אילו פעולות אוטומטיות ניתן להגדיר?

לאחר מעבר מוצלח, אירוע // /local/lib/Order/StatusValidator.php namespace App\Order; use Bitrix\Main\Event; use Bitrix\Main\EventResult; use Bitrix\Sale\Order; class StatusValidator { // Матрица допустимых переходов private static array $allowedTransitions = [ 'N' => ['P', 'A'], // Новый → Принят или Отменён 'P' => ['W', 'ASSEMBLY', 'A'], // Принят → Ожидает оплаты, Сборка, Отменён 'W' => ['P', 'ASSEMBLY', 'A'], // Ожидает оплаты → Принят, Сборка, Отменён 'ASSEMBLY' => ['D', 'A'], // Сборка → Доставляется, Отменён 'D' => ['F'], // Доставляется → Завершён 'F' => [], // Завершён — финальный 'A' => [], // Отменён — финальный ]; public static function validate(Event $event): EventResult { /** @var Order $order */ $order = $event->getParameter('ENTITY'); $newStatus = $event->getParameter('VALUE'); $currentStatus = $order->getField('STATUS_ID'); $allowed = self::$allowedTransitions[$currentStatus] ?? []; if (!in_array($newStatus, $allowed, true)) { return new EventResult( EventResult::ERROR, [ 'message' => sprintf( 'Переход из статуса "%s" в "%s" запрещён', $currentStatus, $newStatus ), ], 'sale' ); } // Дополнительная бизнес-проверка: нельзя отменить оплаченный заказ if ($newStatus === 'A' && $order->isPaid()) { return new EventResult( EventResult::ERROR, ['message' => 'Нельзя отменить оплаченный заказ. Оформите возврат.'], 'sale' ); } // Проверка ролей: возврат из финального статуса — только администратор global $USER; if ($currentStatus === 'F' && !$USER->IsAdmin()) { return new EventResult( EventResult::ERROR, ['message' => 'Изменение завершённого заказа доступно только администратору'], 'sale' ); } return new EventResult(EventResult::SUCCESS); } } מופעל. אנו מצמידים האנדלר שמריץ לוגיקה עסקית: יצירת משימות למחסן, שליחה לשירות משלוחים, הענקת בונוסים.

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleOrderStatusChange',
    function(Event $event) {
        $order = $event->getParameter('ENTITY');
        $newStatus = $event->getParameter('VALUE');
        $oldStatus = $event->getParameter('OLD_VALUE');
        switch ($newStatus) {
            case 'ASSEMBLY':
                WarehouseIntegration::createPickingTask($order);
                break;
            case 'D':
                DeliveryService::registerShipment($order);
                Notifications::sendTrackingNumber($order);
                break;
            case 'F':
                LoyaltyProgram::creditPoints($order);
                ReviewRequest::schedule($order->getUserId(), 3);
                break;
            case 'A':
                if ($oldStatus !== 'N') {
                    StockManager::releaseReservation($order);
                }
                if ($order->isPaid()) {
                    RefundManager::initiate($order);
                }
                break;
        }
    }
);

מה מספק ממשק מותאם אישית עם הערות?

כל שינויי הסטטוס מתועדים אוטומטית ב-OnSaleOrderStatusChange. לצורך ביקורת נוספת, אנו יוצרים טבלה משלנו עם היסטוריית מעברים וסיבות. בכל שינוי סטטוס, אנו רושמים order_id, from_status, to_status, user_id, הערה וחותמת זמן. הממשק הסטנדרטי אינו מספק שדה הערה בעת שינוי סטטוס. אנו מיישמים האנדלר AJAX מותאם אישית בדף פרטי ההזמנה בפאנל הניהול, שבו המנהל מזין את סיבת המעבר. ההערה נשמרת בסשן ומועברת לאירוע.

כיצד לשלב לוגיקה מותאמת אישית עם 1C ושירותי משלוחים?

אינטגרציה עם 1C באמצעות CommerceML מאפשרת סנכרון אוטומטי של סטטוסי הזמנות. כאשר הסטטוס משתנה ל"ASSEMBLY", הנתונים מועברים ל-1C: ניהול מסחר, שם הסחורה נשמרת. באופן דומה, בסטטוס "D", הנתונים מועברים לשירות המשלוחים (CDEK, דואר רוסי) דרך ה-API שלהם. אנו מגדירים את ההחלפה כך ששגיאות סנכרון לא חוסמות את ההזמנה—נעשה שימוש בתורים ומנגנוני ניסיון חוזר. זה מבטיח שהסטטוסים מתעדכנים גם אם מערכות חיצוניות אינן זמינות זמנית.

השוואה ליישום עצמי

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

טעויות אופייניות ביישום לוגיקה מותאמת אישית

הנה מה שנכשל לעיתים קרובות:

• שכחה להשבית אירועים סטנדרטיים בעת דריסה—מובילה לביצוע כפול.
• אי התחשבות בכך ש-\Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderStatusChange', function(Event $event) { $order = $event->getParameter('ENTITY'); $newStatus = $event->getParameter('VALUE'); $oldStatus = $event->getParameter('OLD_VALUE'); switch ($newStatus) { case 'ASSEMBLY': WarehouseIntegration::createPickingTask($order); break; case 'D': DeliveryService::registerShipment($order); Notifications::sendTrackingNumber($order); break; case 'F': LoyaltyProgram::creditPoints($order); ReviewRequest::schedule($order->getUserId(), 3); break; case 'A': if ($oldStatus !== 'N') { StockManager::releaseReservation($order); } if ($order->isPaid()) { RefundManager::initiate($order); } break; } } ); נקרא גם עבור משלוחים חלקיים—יש לבדוק את סוג הישות.
• חוסר טיפול בשגיאות באינטגרציות עם שירותים חיצוניים—ההזמנה נתקעת בסטטוס ביניים.
• אי שמירת מטריצת המעברים במטמון—כל בקשה להזמנה גורמת לקריאת קובץ.

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

מה כלול בעבודה?

כמה זמן לוקח הפיתוח?

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

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