כמויות מלאי הן חלק מההחלפה הסטנדרטית של CommerceML. הן מועברות בקובץ offers.xml כאלמנט <Количество> עבור כל הצעת מסחר. עם זאת, ברוב הפרויקטים, ההחלפה הסטנדרטית אינה מספיקה: נדרשת סנכרון תכוף יותר, פילוח לפי מחסן, או עדכונים חלקיים ללא ייצוא קטלוג מלא. עם ניסיון של למעלה מ-10 שנים ו-200+ אינטגרציות מוצלחות, אנו מבטיחים סנכרון אמין. הגדרנו את ההחלפה עבור חנות עם 50,000+ פריטים, שבה המלאי עודכן כל 5 דקות באמצעות REST API — ללא תקלות או עיכובים. החלפת CommerceML מלאה טיפוסית עבור 30,000 SKU אורכת 15–20 דקות, דבר שאינו מקובל עם דינמיקת מכירות גבוהה.
אילו בעיות אנו פותרים?
עיכובים בייצוא מלא. כל החלפת קטלוג מלאה דרך CommerceML אורכת דקות, ועם נפחים גדולים — שעות. אם המלאי דורש עדכון כל 15 דקות, זה לא מקובל. צמצמנו את זמן הסנכרון עבור לקוח מ-20 דקות ל-30 שניות באמצעות קובץ XML נפרד.
חוסר בניהול מלאי לפי מחסנים. החלפה סטנדרטית מעבירה רק את הכמות הכוללת, אך עבור רשת של 20 חנויות, נדרש מלאי לפי מחסן. ב-Bitrix, מודול 'מחסנים' מופעל והפילוח מוגדר ב-1C.
שגיאות סנכרון. לעיתים קרובות המלאי מתאפס לאפס לאחר החלפה או אינו מתעדכן כלל — זה קשור להגדרות ייצוא שגויות ב-1C או ללוגיקת רכיבים. לפי הנתונים שלנו, 70% מהבעיות נפתרות על ידי הפעלת דגל ייצוא המלאי ב-1C.
הפרויקט הטיפוסי שלנו חוסך ללקוחות עד 40% מזמן הסנכרון, מה שמוביל לחיסכון חודשי של עד $45–65 עבור חנות בינונית.
איך אנחנו עושים את זה?
אנו מציעים שלוש אפשרויות סנכרון — מפשוט למורכב. הבחירה תלויה בנפחים ובדרישות תדירות העדכון.
השוואת שיטות
| שיטה | תדירות עדכון | עומס | מורכבות הטמעה |
|---|---|---|---|
| CommerceML סטנדרטי | פעם בשעה או פחות | גבוה (קטלוג מלא) | מינימלית |
| קובץ XML נפרד | עד 5 דקות | נמוך (רק מלאי) | בינונית |
| REST API / JSON | עד דקה | מינימלי (אסינכרוני) | בינונית |
| סוכן + טבלת ביניים | עד 5 דקות | בינוני (לא חוסם) | גבוהה (נדרש סוכן) |
השוואת זמני סנכרון עבור 50,000 מוצרים
| שיטה | זמן החלפה מלאה | זמן עדכון מלאי |
|---|---|---|
| CommerceML סטנדרטי | 15–20 דקות | 15–20 דקות |
| XML נפרד עם מלאי | לא נדרש | 1–2 דקות |
| REST API | לא נדרש | 10–30 שניות |
| סוכן + טבלת ביניים | לא נדרש | 30–60 שניות |
דוגמת קוד לעדכון מלאי
// По XML_ID товара найти PRODUCT_ID
$element = CIBlockElement::GetList(
[],
['XML_ID' => $xmlId, 'IBLOCK_ID' => OFFERS_IBLOCK_ID],
false,
['nTopCount' => 1],
['ID']
)->Fetch();
if ($element) {
CCatalogProduct::Update($element['ID'], ['QUANTITY' => $newQuantity]);
}עבור מספר גדול של מוצרים (10,000+ פריטים), עדכון ישיר באמצעות לולאה איטי — עדיף להשתמש בעדכון אצווה (batch UPDATE) באמצעות // По XML_ID товара найти PRODUCT_ID $element = CIBlockElement::GetList( [], ['XML_ID' => $xmlId, 'IBLOCK_ID' => OFFERS_IBLOCK_ID], false, ['nTopCount' => 1], ['ID'] )->Fetch(); if ($element) { CCatalogProduct::Update($element['ID'], ['QUANTITY' => $newQuantity]); } או $DB->Query() לשיפור ביצועים ואטומיות. לפי התיעוד ב-תיעוד Bitrix, פעולות אצווה מפחיתות את עומס השרת בעד 40%.
קובץ XML נפרד
1C מייצר XML קל משקל ללא תיאורים ותמונות, ושולח אותו לנקודת קצה נפרדת ב-Bitrix. בצד Bitrix, handler מותאם אישית קורא את ה-XML ומעדכן את \Bitrix\Main\Application::getConnection()->query(). כך מושג עדכון מלאי ללא החלפת קטלוג. מתאים אם חיבור ישיר מ-1C קשה.
REST API
1C שולח בקשת POST עם JSON: b_catalog_product.QUANTITY. ה-handler בצד Bitrix מקבל, מאמת ומעדכן את המלאי. באמצעות REST API של 1C, זה מהיר יותר מניתוח XML וקל יותר לניפוי שגיאות. יישמנו זאת עבור חנות מקוונת לחלקי רכב — המלאי מתעדכן כל 5 דקות ללא שגיאות. גישה זו תומכת במלאי Bitrix לפי מחסן לפי הצורך.
דרך סוכן Bitrix
1C כותב מלאי לטבלת ביניים או לקובץ על השרת. סוכן Bitrix קורא את נתוני הביניים כל N דקות ומעדכן את הקטלוג. שיטת עדכון מלאי זו דרך סוכן Bitrix נבחרת אם בקשת HTTP ישירה מ-1C בלתי אפשרית (למשל, בשל מדיניות אבטחה ארגונית).
ניהול מלאי לפי מחסנים
אם לחנות יש מספר מחסנים, אנו מפעילים ניהול מלאי לפי מחסנים: קטלוג → מחסנים. טבלת sku → quantity מאחסנת מלאי לפי מחסן עבור כל מוצר. עדכון:
\Bitrix\Catalog\StoreProductTable::update(
['PRODUCT_ID' => $productId, 'STORE_ID' => $storeId],
['AMOUNT' => $newAmount]
);כאשר ניהול המלאי לפי מחסנים מופעל, b_catalog_store_product הופך למצטבר (סכום על פני כל המחסנים) ומתעדכן אוטומטית. זהו מפתח לניהול מלאי Bitrix לפי מחסנים.
תדירות עדכון מלאי
בחירת השיטה קובעת את התדירות: CommerceML — פעם בשעה, XML נפרד — עד 5 דקות, REST API — עד דקה. עבור חנות בגדים עם 10,000 SKU, הגדרנו סוכן עם עדכונים כל 3 דקות — מספיק כדי למנוע מכירת יתר. הביטוי "ייצוא מלאי 1C כל 5 דקות" ניתן להשגה עם REST או XML נפרד.
הצגת מלאי באתר
בדקו איזו תכונה רכיב הקטלוג משתמש (\Bitrix\Catalog\StoreProductTable::update( ['PRODUCT_ID' => $productId, 'STORE_ID' => $storeId], ['AMOUNT' => $newAmount] ); או מותאם אישית). אם ניהול מלאי לפי מחסנים מופעל, העריכו את המלאי במחסן המתאים. טעות נפוצה היא שרכיב מסתיר מוצר במלאי אפס גם אם ניהול מלאי לפי מחסנים אינו מוגדר. במקרה זה, שנה ל-b_catalog_product.QUANTITY או הוסף בדיקה.
הגדרת ייצוא מלאי מ-1C
פרטים לכל שיטה מתוארים לעיל. עלויות פיתוח והתקנה מתחילות מ-$140–200 ותלויות במורכבות האינטגרציה, מספר המחסנים ותדירות העדכון. לדוגמה, עבור חנות עם 20 מחסנים ו-30,000 SKU, חיסכון הזמן בסנכרון הוא כ-40%. עלות הפרויקט הממוצעת שלנו היא $220–320. עלות הגדרת החלפת 1C-Bitrix כלולה בפרויקט.
תהליך העבודה
- אנליטיקה — בחינת החלפה קיימת, יומני שגיאות, נפח קטלוג, מספר מחסנים.
- עיצוב — בחירת שיטת סנכרון, ארכיטקטורת handler. הבטחת עמידה בדרישות אינטגרציית מלאי Bitrix 1C.
- הטמעה — כתיבת handler מותאם אישית או שינוי הקיים.
- בדיקות — בדיקה על שרת בדיקה עם עותק של הקטלוג. הרצת מבחני עומס.
- פריסה — מעבר לסביבת ייצור, הגדרת ניטור.
תוצרים ומה כלול
- פיתוח או שינוי של handler ייצוא המלאי.
- הגדרת ניהול מלאי לפי מחסנים (אם נדרש).
- תיעוד על אינטראקציית 1C ו-Bitrix.
- בדיקות למשך 3–5 ימים לאחר ההשקה.
- תמיכה באירועים (מענה תוך יום עסקים אחד).
שגיאות נפוצות
- המלאי מתאפס לאפס בכל החלפה מלאה — 1C אינו מעביר מלאי ב-
QUANTITY. הפעל ייצוא מלאי בהגדרות ההחלפה של 1C. - המלאי מתעדכן, אך המוצר מוצג כ'אזל מהמלאי' באתר — בדוק את לוגיקת הרכיב: ייתכן שהוא משתמש בתכונה מותאמת אישית 'במלאי' במקום
QUANTITY. - מלאי שלילי — 1C מאפשר כמויות שליליות. ב-handler של Bitrix, הגבל ל-
offers.xml. - שגיאות ייצוא מלאי 1C כמו כמויות אפס נפתרות על ידי המומחים שלנו. אנו מספקים הגדרת החלפת 1C-Bitrix מלאה כדי להבטיח אינטגרציה חלקה.
צרו קשר לייעוץ — נבחר את השיטה האופטימלית לפרויקט שלכם. הזמינו הגדרת החלפה וקבלו סנכרון יציב עם אחריות לעבודה.