אינטגרציה של חנות מקוונת עם KazanExpress / Magnit Market (API)

אינטגרציה עם KazanExpress: היכן נשבר חילוף הסחורות

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

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

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

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

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

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

מה נותן חילוף קבוע של הזמנות ומלאי

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

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

חילוף קבוע מסיר את שכבת הביניים הזו. המלאי מוקצה ברגע ביצוע ההזמנה, ולא ברגע הליקוט, ולכן הפריט יורד מהחזית של Магнит Маркет מיד לאחר שכבר אינו מספיק. ההזמנה נכנסת לחשבונאות תוך דקות, ולא עד סוף המשמרת, וממשיכה לעבור בין סטטוסים ללא מעורבות מפעיל.

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

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

דרכי חיבור: חילוף תוכנתי, קבצים, אזור אישי

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

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

את מגבלות החילוף אנו מפרטים מראש. ב-Магнит Маркет (לשעבר KazanExpress) כללי החילוף והמודרציה משתנים, ולכן חלק מהמגבלות אנו מסירים בצד שלנו: תור שליחות חוזרות, הגנה מכפילויות הזמנות, יומן שגיאות עם ניתוח מובן.

סדר העבודות: מביקורת מערכת החשבונאות ועד למסירה

חילוף עם KazanExpress (Магнит Маркет) אינו «להפעיל מודול», אלא פרויקט שבו שגיאה נראית כבר ביום הראשון: מלאי לא תואם, הגיעה כפילות הזמנה, סטטוס משלוח אבד. אנו מבצעים את העבודה במסלול קבוע — מספירת מלאי חשבונאית ועד מסירת הפתרון לצוות שלכם.

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

עד להפעלת החילוף במצב עבודה, הצוות כבר רואה כיצד המערכת מתנהגת בהזמנות אמיתיות, ויודע את סדר הפעולות בעת תקלה.

תרשים החילוף, מיפוי שדות ונהלי תמיכה

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

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

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

מקרה בוחן: חיבור מבחר וסנכרון מלאי

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

לקראת הערב הפערים בין המחסן לחזיתות הגיעו ל-8–9%, הזמנות על מוצר שאינו קיים עברו לביטול, והתגובה להזמנה חדשה ארכה 3–4 שעות.

מה שינינו

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

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

מדדים לפני ואחרי

• עדכון מלאי: פעם ביום → כל 10 דקות לפי הפרשים.
• פערים מחסן ↔ חזית: 8–9% → 0.5%.
• זמן תגובה להזמנה: 3–4 שעות → כ-10 דקות.
• פעולות ידניות במבחר: כ-120 ביום → 10 (רק כרטיסים חדשים).
• ביטולים מסיבת «אין במלאי»: 6% מההזמנות → פחות מ-0.4%.

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

במה שונה האינטגרציה עם KazanExpress מייצוא ידני

ייצוא ידני הוא קובץ שמפעיל מרכיב ומעלה לאזור המוכר של Магнит Маркет. כל עוד הפריטים מעטים והמחירים מתוקנים לעיתים רחוקות, השיטה עובדת. הפער מופיע כאשר הנתונים במערכת החשבונאית משתנים בתדירות גבוהה מזו שבה אתם מספיקים להרכיב מחדש את הקובץ.

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

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

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

שאלות טכניות בנושא חילוף עם מרקטפלייס

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

מה יקרה אם הקשר עם הפלטפורמה ינותק לשעה?

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

כיצד נלקחים בחשבון כמה מחסנים וקבוצות מוצרים מורכבות?

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

מה יקרה אם נרצה לתמוך באינטגרציה בעצמנו?

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

נדון במשימה שלכם ונחזור עם הערכה

כדי שההערכה תהיה מדויקת ולא «מהאוויר», יש צורך בנתוני מקור על החנות והלוגיקה הנוכחית של העבודה עם הפלטפורמה. אינטגרציה עם KazanExpress / Магнит Маркет כמעט תמיד נתקלת לא בקוד, אלא באופן שבו אצלכם בנויים הקטלוג, המלאי וטיפול ההזמנות — לכן מתחילים מכך.

מה לשלוח בהתחלה:

• מבנה קטגוריות המוצרים והתכונות — לפיו נבנית התאמת הכרטיסים בין מערכת החשבונאות שלכם לפלטפורמה;
• השיטה הנוכחית לייצוא מחירים ומלאי (קובץ, טבלה, מערכת חשבונאית) והתדירות שבה הנתונים צריכים להתעדכן;
• רשימת סכמות המשלוח שאיתן אתם עובדים וכללי חלוקת ההזמנות בין המחסנים;
• תיאור תהליך טיפול בהזמנה: מי מאשר, מי מדפיס מסמכים, באיזה רגע נקבע הסטטוס;
• מידע על החזרות וסיבות ביטול — הם קובעים את כללי הכתיבה חזרה לחשבונאות;
• אנשי קשר של מקבלי ההחלטות בנושא מבחר ולוגיסטיקה.

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

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