אנו משלבים את 1C-Bitrix עם Inflow WMS כדי לייעל את פעולות המחסן ולחסל שגיאות בעיבוד הזמנות. Inflow WMS היא מערכת מחסן למסחר אלקטרוני בינוני וגדול: אחסון לפי כתובות, ניהול אזורי קטיף, תמיכה בתיוג SSCC. האינטגרציה עם 1C-Bitrix כאן מורכבת יותר מאשר עם מערכות WMS ענן טיפוסיות — Inflow נפרסת לעיתים קרובות באתר הלקוח (on-premise), כוללת API הניתן להתאמה אישית, ודורשת התאמה של סכמת ההחלפה להגדרות הספציפיות של המערכת. צברנו ניסיון בפרויקטים כאלה ואנו מבטיחים שהפתרון הסופי יהיה עמיד לעומסים ולשגיאות.
לאחרונה פנתה אלינו חנות אלקטרוניקה מקוונת עם מחזור של 500 הזמנות ביום. מערכת ה-Inflow WMS שלהם פרוסה מקומית, והאינטגרציה עם Bitrix באמצעות סקריפטים מותאמים אישית של cron איבדה מעת לעת הזמנות עקב שגיאות קטיף. הלקוח הפסיד עד 5% מההכנסות עקב כשלים שלא טופלו. תכננו את ההחלפה דרך REST API של Inflow עם מיפוי סטטוסים ותורי ניסיון חוזר (retry queues). תוך חודש, מספר ההזמנות שאבדו ירד לאפס, וחסכנו ללקוח כ-15,000 דולר בחודש.
ארכיטקטורת החלפה עם Inflow WMS
Inflow מספקת REST API או ממשק SOAP בהתאם לגרסת הפריסה. רוב ההתקנות המודרניות משתמשות ב-REST עם JSON. אימות באמצעות מפתח API בכותרת X-API-Key או OAuth2. Inflow WMS מתמודדת עם עומסי שיא פי 2 טוב יותר מחלופות ענן בשל פריסה מקומית וחלוקת משימות אופטימלית.
נקודות קצה טיפוסיות של Inflow:
-
GET /api/v1/stock— מלאי נוכחי לפי מחסן/אזורים -
POST /api/v1/orders— יצירת הזמנת קטיף -
GET /api/v1/orders/{id}/status— סטטוס ביצוע הזמנה -
PUT /api/v1/orders/{id}/cancel— ביטול הזמנת קטיף
הבדל מרכזי ממערכות WMS פשוטות יותר: Inflow מפרידה בין המושגים של הזמנת קטיף והזמנת לקוח. הזמנת לקוח אחת יכולה לייצר מספר הזמנות קטיף — כאשר עובדים עם מספר אזורי אחסון או מובילים שונים.
פרטים טכניים: גרסאות API של Inflow
גרסאות API 3.0 ומעלה נטשו לחלוטין את SOAP. עבור התקנות ישנות יותר (גרסאות 2.x), SOAP עדיין נתמך, אך אנו ממליצים לעבור ל-REST — זה מפחית את זמן ההשהיה ב-30%.כיצד מתבצע מיפוי סטטוסי הזמנות?
החלק הגוזל ביותר הוא מיפוי הסטטוסים בין המערכות. ב-Bitrix, סטטוסי הזמנות ניתנים להגדרה חופשית (ספריית b_sale_status). ב-Inflow, מכונת הסטטוסים קבועה: NEW → ASSIGNED → PICKING → PICKED → PACKING → SHIPPED → DELIVERED.
נדרשת טבלת מיפוי כדי לתרגם סטטוסים של Inflow לסטטוסים של Bitrix:
| סטטוס Inflow | סטטוס Bitrix |
|---|---|
NEW |
P (ממתין) |
PICKING |
Q (קטיף) |
SHIPPED |
D (משלוח) |
DELIVERED |
F (הושלם) |
CANCELLED |
Z (בוטל) |
אנו שומרים את טבלת המיפוי בהגדרות מודול האינטגרציה כך שניתן לשנות אותה ללא פריסה מחדש. זה מאפשר להתאים את הסכמה לתהליכים העסקיים של הלקוח תוך שעה, לא יום. מקור: תיעוד רשמי של Inflow WMS.
סנכרון מלאי תוך התחשבות באחסון לפי כתובות
במערכות WMS מבוססות כתובות, "מלאי" אינו רק מספר אלא חלוקה בין מיקומים. עבור חנות מקוונת, רק הכמות הזמינה למכירה חשובה: qty_on_hand - qty_reserved - qty_in_picking.
אנו שולחים שאילתה ל-Inflow דרך GET /api/v1/stock?warehouse=main&available_only=true. אנו מקבלים מלאי מצטבר. אנו מעדכנים ב-Bitrix דרך \Bitrix\Catalog\ProductTable::update() עם ביטול מטמון. לפרטים נוספים על עדכון מוצרים, ראו תיעוד Bitrix.
תדירות סנכרון המלאי היא נושא לדיון נפרד עם הלקוח. מחסנים עם מחזור גבוה (100+ קטיפים בשעה) דורשים סנכרון כל 2–5 דקות או מעבר לאירועים. עבור מחסנים פחות עמוסים, מרווח של 15 דקות באמצעות סוכן Bitrix מספיק. אנו ממליצים להתחיל עם 5 דקות ולהתאים לפי העומס.
מדוע טיפול בשגיאות קטיף חשוב?
Inflow עשויה להחזיר סטטוס PICKING_ERROR — פריט לא נמצא במיקום שצוין, מיקום לא זמין. במקרה זה, ההזמנה ב-Bitrix צריכה לקבל סטטוס מיוחד ומשימה למנהל. זהו מצב לא סטנדרטי — הוא מטופל באמצעות לוגיקה מותאמת אישית באירוע עדכון הסטטוס של Inflow.
מקרה טיפוסי: מנהל ביצע הזמנה לפריט שהמלאי שלו עוד לא עודכן. WMS מחזירה שגיאה בעת ניסיון להזמין. האינטגרציה חייבת: להודיע למנהל, לשחרר את ההזמנה ב-Bitrix, להציע חלופה או ביטול. ללא טיפול בתרחיש זה, שגיאה "שקטה" הופכת להזמנה שלא מולאה ללא התראה. הערבות שלנו: אנו תמיד מכסים תרחיש זה.
תיוג וברקודים
אם המחסן מטפל במוצרים מסומנים (Chestny Znak, SSCC), האינטגרציה הופכת למורכבת יותר: בעת העברת הזמנה ל-Inflow, יש לציין את קודי התיוג, ובעת המשלוח, יש לקבל את רשימת הקודים שבהם נעשה שימוש להעברה למפעיל הנתונים הפיסקליים. זוהי לולאת החלפה נפרדת הכוללת b_catalog_product_barcode בצד Bitrix. יישמנו פרויקטים כאלה עבור רשתות עם מחזור של 1000+ הזמנות ביום, והפחתנו שגיאות תאימות ב-80%.
כיצד אנו מתכננים אינטגרציה: תוכנית שלב אחר שלב
- ביקורת של תצורת Inflow WMS הנוכחית וסכמת ה-API — יומיים.
- תכנון סכמת החלפה ומיפוי סטטוסים תוך התחשבות בתהליכים עסקיים.
- פיתוח מודול אינטגרציה עבור Bitrix: סוכנים מותאמים אישית, מטפלי אירועים, תורי ניסיון חוזר.
- הקמת סביבת בדיקה ובדיקות עומס (סימולציה של 1000+ בקשות במקביל).
- השקה הדרגתית: תחילה סנכרון מלאי, לאחר מכן הזמנות, ולבסוף טיפול בשגיאות.
- העברת תיעוד תפעולי והדרכה למנהלים.
- תמיכה בשלב ההשקה (שבועיים).
מה כלול
- תיעוד סכמת החלפה ומיפוי סטטוסים
- הגדרת גישת API עבור Inflow ו-Bitrix
- פיתוח מודול אינטגרציה מלא (turnkey)
- בדיקות עומס המדמות תרחישי שיא
- הדרכת מנהלים על המערכת החדשה
- תמיכה טכנית במהלך ההשקה (שבועיים)
אם אתם רוצים אינטגרציה אמינה, בקשו ביקורת מחסן — זה לוקח רק יומיים.
הערכות לוחות זמנים
| תרחיש | לוח זמנים | הערכת עלות (USD) |
|---|---|---|
| סנכרון מלאי והזמנות בסיסי | 4–8 שבועות | 15,000–25,000 |
| אינטגרציה מלאה עם סטטוסים וטיפול בשגיאות | 2–3 חודשים | 30,000–45,000 |
| אינטגרציה עם תמיכה בתיוג | 3–5 חודשים | 50,000–70,000 |
יש לנו ניסיון של 8+ שנים באינטגרציות WMS והשלמנו 25+ פרויקטים עבור לקוחות מסחר אלקטרוני עם מחזורים מ-1 מיליון עד 50 מיליון דולר. האינטגרציה בדרך כלל מחזירה את עצמה תוך 3–4 חודשים על ידי הפחתת שגיאות והאצת העיבוד. לקבלת ייעוץ והערכה ראשונית, צרו קשר.