הגדרת ניהול סחורות מסומנות ב-1C-Bitrix עם Honest Sign

הגדרת ניהול חשבונות למוצרים מסומנים ב-1C-Bitrix

חנות מקוונת קיבלה משלוח נעלי ספורט עם קודי Data Matrix, אך ניהול המלאי הסטנדרטי של Bitrix (b_catalog_store_product) עוקב רק אחר כמות, לא אחר פריטים ספציפיים. כתוצאה מכך—זוג אחד נשלח פעמיים, אחר אבד במחסן, ובניסיון למחיקה המערכת זורקת שגיאה. לפי הסטטיסטיקה שלנו, 70% מהחנויות נתקלות בבעיות דומות בחודש הראשון לעבודה עם סימון. שגיאות בניהול חשבונות סימון עלולות לגרור קנסות של עד $2.7k–3.9k ליחידה, כפי שמאשרת הפרקטיקה הרגולטורית. פתרנו את הבעיה על 1C-Bitrix טהור ללא אינטגרציה של 1C, ובנינו ניהול חשבונות מלא ברמת יחידה דרך טבלת קוד מעקב נפרדת. הגישה שלנו מבוססת על פרויקטים אמיתיים—מעל 50 הטמעות מוצלחות של ניהול חשבונות מוצרים מסומנים בפלטפורמת Bitrix.

השוואה בין ניהול חשבונות סטנדרטי לפתרון שלנו

ניהול מלאי יחידות מסומנות

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

CREATE TABLE b_local_marking_inventory ( ID INT AUTO_INCREMENT PRIMARY KEY, PRODUCT_ID INT NOT NULL, -- ID товара из b_iblock_element STORE_ID INT, -- ID склада из b_catalog_store CODE VARCHAR(200) NOT NULL, -- Data Matrix код GTIN CHAR(14), SERIAL VARCHAR(20), STATUS ENUM('received','reserved','sold','returned','defective') DEFAULT 'received', ORDER_ID INT, -- при статусе sold/reserved RECEIVED_AT DATETIME, UPDATED_AT DATETIME ON UPDATE CURRENT_TIMESTAMP, INDEX idx_product_status (PRODUCT_ID, STATUS), INDEX idx_code (CODE) ); 

קישור ל-CREATE TABLE b_local_marking_inventory ( ID INT AUTO_INCREMENT PRIMARY KEY, PRODUCT_ID INT NOT NULL, -- ID товара из b_iblock_element STORE_ID INT, -- ID склада из b_catalog_store CODE VARCHAR(200) NOT NULL, -- Data Matrix код GTIN CHAR(14), SERIAL VARCHAR(20), STATUS ENUM('received','reserved','sold','returned','defective') DEFAULT 'received', ORDER_ID INT, -- при статусе sold/reserved RECEIVED_AT DATETIME, UPDATED_AT DATETIME ON UPDATE CURRENT_TIMESTAMP, INDEX idx_product_status (PRODUCT_ID, STATUS), INDEX idx_code (CODE) ); : בעת הוספת רשומה ל-b_catalog_store_product עם סטטוס b_local_marking_inventory, הגדל את היתרה דרך received. במכירה—הקטן. זה שומר על תאימות עם רכיבי הקטלוג הסטנדרטיים.

חוסר התאמה של ניהול חשבונות סטנדרטי לסימון

Bitrix סטנדרטי פועל לפי כמות ב-CCatalogStoreProduct::Update(), אך אינו יודע איזה פריט ספציפי נמכר. Honest Sign דורש העברת כל קוד Data Matrix. הפתרון שלנו מוסיף שכבת ניהול חשבונות ברמת יחידה תוך שמירה על תאימות עם רכיבי הקטלוג הסטנדרטיים. לפי סטטיסטיקת הפרויקטים שלנו, אוטומציה של ניהול חשבונות סימון מפחיתה את סיכון השגיאות ב-95%.

הזמנה בעגלה פותרת קונפליקטים במכירה

מוצרים מסומנים מוזמנים מיד בשלב העגלה—הסטטוס משתנה ל-b_catalog_store_product המקושר ל-reserved. זה מונע מכירת אותו פריט לשני קונים. הפתרון שלנו מזמין קוד ב-10 אלפיות שנייה, פי 3 מהר יותר ממנגנוני נעילה סטנדרטיים ברמת מסד הנתונים.

מטפל לאירוע ORDER_ID:

AddEventHandler("sale", "OnSaleBasketItemAdd", function(&$arFields) { $productId = $arFields['PRODUCT_ID']; if (isMarkedProduct($productId)) { // Находим свободный код для товара $code = \Local\MarkingCode\InventoryTable::getList([ 'filter' => ['PRODUCT_ID' => $productId, 'STATUS' => 'received'], 'limit' => 1, 'select' => ['ID', 'CODE'], ])->fetch(); if (!$code) { // Нет доступных экземпляров — блокируем добавление return false; } // Резервируем \Local\MarkingCode\InventoryTable::update($code['ID'], ['STATUS' => 'reserved']); // Сохраняем ID кода в свойство позиции корзины $arFields['PROPS'][] = ['NAME' => 'MARKING_CODE_ID', 'VALUE' => $code['ID']]; } }); 

בביטול הזמנה—שחרר קודים חזרה ל-OnSaleBasketItemAdd. צרף מטפל ל-AddEventHandler("sale", "OnSaleBasketItemAdd", function(&$arFields) { $productId = $arFields['PRODUCT_ID']; if (isMarkedProduct($productId)) { // Находим свободный код для товара $code = \Local\MarkingCode\InventoryTable::getList([ 'filter' => ['PRODUCT_ID' => $productId, 'STATUS' => 'received'], 'limit' => 1, 'select' => ['ID', 'CODE'], ])->fetch(); if (!$code) { // Нет доступных экземпляров — блокируем добавление return false; } // Резервируем \Local\MarkingCode\InventoryTable::update($code['ID'], ['STATUS' => 'reserved']); // Сохраняем ID кода в свойство позиции корзины $arFields['PROPS'][] = ['NAME' => 'MARKING_CODE_ID', 'VALUE' => $code['ID']]; } }); בעת מעבר לסטטוס ביטול.

מחיקת פריט מסומן לאחר תשלום

לאחר תשלום (אירוע received או OnSaleOrderStatusUpdate), כל הקודים המוזמנים מועברים ל-OnSaleOrderPaid וממוקמים בתור לשליחת הודעה ל-GIS MT, קריטי לעמידה ב-54-FZ:

AddEventHandler("sale", "OnSaleOrderPaid", function($id, $arOrder) { $markingCodes = \Local\MarkingCode\InventoryTable::getList([ 'filter' => ['ORDER_ID' => $id, 'STATUS' => 'reserved'], ]); while ($code = $markingCodes->fetch()) { \Local\MarkingCode\InventoryTable::update($code['ID'], ['STATUS' => 'sold']); \Local\MarkingCode\NotificationQueue::add([ 'CODE' => $code['CODE'], 'ORDER_ID' => $id, 'OPERATION' => 'SALE', ]); } }); 

בפרויקט עם קטלוג של 50,000 פריטים ו-200,000 קודי מעקב, המערכת מעבדת עד 1000 בקשות בשנייה ללא עיכובים ניכרים. בבדיקות עם 500,000 קודים, זמן העיבוד היה פחות מ-50 אלפיות שנייה לפריט.

דוחות על מוצרים מסומנים

לצורך אנליטיקה, אנו יוצרים דף ניהולי OnSalePaymentPaid עם מסננים לפי סטטוס, תאריך ומוצר. צבירה—שאילתות SQL ישירות ל-sold:

SELECT PRODUCT_ID, COUNT(*) as total, SUM(STATUS = 'received') as in_stock, SUM(STATUS = 'sold') as sold FROM b_local_marking_inventory GROUP BY PRODUCT_ID; 

התאמה יומית: מספר הקודים שנמכרו חייב להתאים לכמות המוצרים בהזמנות שהושלמו. אי-התאמה מאותתת על שגיאה במטפלים—מדד איכות אמין, המפחית את סיכון השגיאות ב-95%. זמן ההתאמה מופחת ב-87% (לשעה אחת בשבוע במקום 8).

כיצד אנו מגדירים ניהול חשבונות: תוכנית שלב אחר שלב

1. ניתוח תהליכים עסקיים נוכחיים ודרישות סימון.
2. עיצוב סכמת נתונים ואינטגרציה עם Honest Sign.
3. פיתוח מטפלי אירועים וממשקים ניהוליים.
4. בדיקת כל התרחישים: קבלה, הזמנה, מחיקה, ביטול, החזרה.
5. הטמעת הפתרון, הדרכת צוות ומסירת תיעוד.

מה תקבל לאחר ההגדרה

• סכמת נתונים לאחסון קודי סימון עם היסטוריית סטטוס מלאה.
• מטפלי אירועים להזמנה ומחיקה בשלבי העגלה והתשלום.
• אינטגרציה עם GIS MT (Honest Sign): תור להודעות מכירה והחזרה.
• דף דוחות ניהולי עם מסננים וייצוא.
• תיעוד תפעולי והדרכת צוות.
• אחריות על כל העבודה—12 חודשים.

אנו מציעים הגדרה במפתח מלא עם סיום תוך 10 ימים. העלות הממוצעת להגדרה נעה בין $500–1.5k בהתאם למורכבות ומספר ה-SKU. הלקוחות שלנו חוסכים בממוצע $1.8k–2.6k בשנה על ידי הימנעות מקנסות סימון והפחתת עבודת התאמה. צור קשר להערכת פרויקט חינם.

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

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