אינטגרציית החזרות דו-כיוונית בין 1C ל-Bitrix

אינטגרציית החזרות מלאה בין 1C ל-Bitrix

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

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

איך החזרה עובדת ב-Bitrix

החזרה ב-Bitrix היא אובייקט מהמחלקה \Bitrix\Sale\Payment\PaymentReturn בהקשר של תשלום או \Bitrix\Sale\Shipment\ShipmentReturn בהקשר של משלוח. מנקודת מבט של מסד הנתונים, רשומות מאוחסנות ב:

• b_sale_order_return — בקשת החזרה
• b_sale_order_return_item — פריטי החזרה
• b_sale_order_return_shipment — קשר למשלוח

סטטוסי החזרה (RETURN_STATUS): NEW, PROCESSED, COMPLETED, REJECTED. הטריגר להעברה ל-1C צריך להיות המעבר ל-COMPLETED—ייתכן שהנתונים ישתנו לפני כן.

סכימת החלפה

המודול הסטנדרטי bitrix.1c מעביר הזמנות דרך sale.order ב-CommerceML 2. החזרות אינן מתוארות ב-CommerceML—זהו צומת מותאם אישית שיש להוסיף לסכימה בעצמך.

Bitrix: возврат переходит в COMPLETED →
Обработчик события OnSaleReturnComplete →
Формирование XML-узла <Возврат> →
Запись в очередь обмена (b_agent / кастомная таблица) →
Следующий сеанс обмена с 1С →
1С создаёт документ "Возврат товаров от покупателя" →
Подтверждение из 1С →
статус возврата обновляется

השתמש באירוע Bitrix: возврат переходит в COMPLETED → Обработчик события OnSaleReturnComplete → Формирование XML-узла <Возврат> → Запись в очередь обмена (b_agent / кастомная таблица) → Следующий сеанс обмена с 1С → 1С создаёт документ "Возврат товаров от покупателя" → Подтверждение из 1С → статус возврата обновляется מהמודול OnSaleReturnComplete:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnSaleReturnComplete',
    function (\Bitrix\Main\Event $event) {
        $return = $event->getParameter('ENTITY');
        ReturnExchangeQueue::push($return->getId());
    }
);

מבנה XML להעברה ל-1C

1C עובדת עם CommerceML, אבל נוח יותר להעביר החזרות כצומת נפרד בתוך sale:

<Возврат>
  <Ид>RETURN-{return_id}</Ид>
  <НомерДокумента>R-{return_id}</НомерДокумента>
  <Дата>{date}</Дата>
  <ЗаказИд>{order_id}</ЗаказИд>
  <Контрагент>
    <Ид>{user_id}</Ид>
    <Наименование>{user_name}</Наименование>
  </Контрагент>
  <Товары>
    <Товар>
      <Ид>{product_id}</Ид>
      <Наименование>{product_name}</Наименование>
      <Количество>{qty}</Количество>
      <ЦенаЗаЕдиницу>{price}</ЦенаЗаЕдиницу>
      <Сумма>{sum}</Сумма>
    </Товар>
  </Товары>
  <СуммаВозврата>{total}</СуммаВозврата>
  <Причина>{reason}</Причина>
</Возврат>

בצד 1C, מטפל בתצורה קורא את הצומת הזה ויוצר מסמך "החזרת סחורה מהקונה" המקושר כראוי למכירה המקורית דרך \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleReturnComplete', function (\Bitrix\Main\Event $event) { $return = $event->getParameter('ENTITY'); ReturnExchangeQueue::push($return->getId()); } ); .

סנכרון מלאי לאחר החזרה

לאחר החזרה מוצלחת ב-1C, המלאי מתעדכן. חשוב ש-Bitrix תקבל את האות הזה ותעדכן את <КоммерческаяИнформация>. החלפת המלאי הסטנדרטית (<Возврат> <Ид>RETURN-{return_id}</Ид> <НомерДокумента>R-{return_id}</НомерДокумента> <Дата>{date}</Дата> <ЗаказИд>{order_id}</ЗаказИд> <Контрагент> <Ид>{user_id}</Ид> <Наименование>{user_name}</Наименование> </Контрагент> <Товары> <Товар> <Ид>{product_id}</Ид> <Наименование>{product_name}</Наименование> <Количество>{qty}</Количество> <ЦенаЗаЕдиницу>{price}</ЦенаЗаЕдиницу> <Сумма>{sum}</Сумма> </Товар> </Товары> <СуммаВозврата>{total}</СуммаВозврата> <Причина>{reason}</Причина> </Возврат> ) תעשה זאת בסשן הבא, אבל אם הסשנים נדירים, יש צורך בבקשה נפרדת:

// 1С вызывает URL после проведения возврата
// /bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth&return_confirm=Y&return_id=123
$returnId = (int)$_GET['return_id'];
ReturnSyncService::updateStocksFromReturn($returnId);

ב-ЗаказИд יש עדכון ישיר של b_catalog_store_product דרך offers.xml עם קריאה ל-// 1С вызывает URL после проведения возврата // /bitrix/admin/1c_exchange.php?type=catalog&mode=checkauth&return_confirm=Y&return_id=123 $returnId = (int)$_GET['return_id']; ReturnSyncService::updateStocksFromReturn($returnId); אם יש צורך בחישוב מחדש של מגרשים.

העברת סטטוס הפוכה

לאחר יצירת המסמך ב-1C, יש לשלוח אישור חזרה ל-Bitrix:

עדכון הסטטוס בצד Bitrix:

$return = \Bitrix\Sale\OrderReturn::load($returnId);
$return->setField('STATUS', 'COMPLETED');
$return->setField('COMMENTS', '1С: документ #' . $doc1cId);
$return->save();

מקרה בוחן: מפיץ סיטונאי, 150+ החזרות בחודש

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

יישמנו את הצעדים הבאים:

1. האירוע COMPLETED כותב את ההחזרה לתור 1C_SYNCED = Y.
2. סוכן (כל 10 דקות) בונה XML ושולח אותו לנקודת הקצה של 1C דרך בקשת HTTP למטפל ההחלפה הסטנדרטי.
3. 1C מעבדת את המסמך, מעדכנת מלאי, שולחת אישור ל-ERROR_1C.
4. Webhook ב-Bitrix מעדכן את סטטוס ההחזרה ומחשב מחדש את REJECTED עבור פריטי SKU המושפעים.

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

• ניתוח תצורת 1C: סוג מסמך "החזרת סחורה מהקונה", שדות מקשרים להזמנה
• פיתוח סכימת XML ומחולל PHP עבור Bitrix
• $return = \Bitrix\Sale\OrderReturn::load($returnId); $return->setField('STATUS', 'COMPLETED'); $return->setField('COMMENTS', '1С: документ #' . $doc1cId); $return->save(); מטפל אירועים, תור החלפה
• נקודת קצה של Webhook לאישור מ-1C
• עדכון מלאי ב-Bitrix לאחר אישור
• בדיקות במספר תרחישים: החזרה חלקית, החזרה ללא משלוח, החזרה עם מספר מחסנים

הערכות לוחות זמנים

אינטגרציה בסיסית (העברת החזרות + אישור) — 3–4 שבועות. עם סנכרון מלאי בזמן אמת וטיפול במקרי קצה — 6–8 שבועות. לוח הזמנים המדויק נקבע לאחר ביקורת של תצורת 1C שלך.

מלכודות נפוצות (מבוסס על פרויקטים אמיתיים)

• שכחת להפעיל את מערכת האירועים של מודול OnSaleReturnComplete עבור החזרות—האירוע local_1c_return_queue לעולם לא יופעל אם תהליך ההחזרה מותאם אישית ללא שימוש ב-API הסטנדרטי.
• ערבוב מסמכי החזרה עם מסמכי הזמנה ב-XML—1C עלולה לפרש החזרה כהזמנה חדשה אם מבנה הצומת חופף.
• הנחה שהמלאי מתעדכן דרך /api/1c/return-confirm/{returnId} הסטנדרטי—החלפה זו פועלת רק לפי לוח זמנים; לעדכונים בזמן אמת יש צורך ב-webhook נפרד.

הגישה שלנו

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

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

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