סנכרון МойСклад עם האתר: היכן הקטלוג מתפצל
הפער מתחיל במקום שבו חלון הראווה והנהון החשבונאי חיים לפי כללים שונים. המחסנאי מוריד את הסחורה במערכת החשבונאית, אך באתר הפריט נשאר זמין עד לחילופין הבא — הקונה מבצע הזמנה על משהו שכבר אינו במלאי.
המצב ההפוך אינו טוב יותר: הקבלה נרשמה בחשבונאות, אך חלון הראווה התעדכן כעבור שעה, והמנהל מוריד את הפריט ידנית מהמכירה, ומאבד הזמנות חיות. כל חלון כזה הוא ביטול הזמנה, החזרה, הסבר ללקוח ותיקון ידני בשתי מערכות.
נקודת פיצול נפרדת היא הקטלוג. אותו מוצר נרשם בחשבונאות ובאתר בכרטיסים שונים: מקטים אינם תואמים, יחידות המידה שונות, בחלק מהפריטים ההרכב משתנה. החלפה לפי שם או לפי קוד שמישהו תיקן ביד מתחילה ליצור כפילויות במקום עדכון — והנהון כפול של מוצרים גדל עם כל ייצוא.
בהמשך נפגעת עדכניות הקטלוג: מחירים, מאפיינים ומלאים של "הכפילים" מתפצלים, והקונה רואה משהו שאינו קיים באף אחת מהמערכות.
הסיבה השלישית היא כללי ההחלפה. ייצוא המוני פעם ביום אינו מתאים למוצרים עם תנועות תכופות, והחלפה של "הכול בבת אחת" מעמיסה על חלון הראווה ומוחקת תיקוני תוכן ידניים.
אם להזמנה, לביטול ולקבלה אין עדיפויות והגנה מפני עיבוד חוזר, אותה פעולה מיושמת פעמיים — המלאי יורד למינוס, והסנכרון של МойСклад הופך למקור שגיאות במקום לתיקונן.
אנו מפרקים כיצד זה נסגר: התאמת קטלוג לפי מזהים יציבים, הפרדת הרשאות כתיבה, עדיפויות פעולות ובקרת פערים לפני שהם מגיעים לקונה.
מה נותנת סנכרון דו-כיווני של הקטלוג
סנכרון דו-כיווני הוא כאשר שינויים נעים בשני הכיוונים: עריכה של כרטיס או מחיר במערכת החשבונאית עוברת לאתר, והזמנה מהאתר חוזרת למערכת החשבונאית כמסמך מבוצע. ייצוא חד-כיווני לא יודע לעשות זאת: מלאי ומחירים בחלון הראווה חיים חיים משל עצמם, והמנהל מאחד הזמנות ידנית.
חילוף מוגדר מסיר שלושה דברים בבת אחת. חלון הראווה מפסיק למכור את מה שאין: מלאי מתעדכן בזמן אמת לאחר כל פעולה במחסן, ולא פעם ביום לפי לוח זמנים. הזמנות מהאתר נופלות למערכת החשבונאית כמסמכים מוכנים — שיעור ההזמנות ללא עריכה ידנית מגיע ל-90%+ ונשאר שם. נעלם סוג שלם של כשלים: מכירה במינוס, פריטים כפולים, אי-התאמת מחירים בין חלון הראווה לקטלוג.
- מהירות עדכון הקטלוג — מדקות ועד שניות לפריט במקום ייצוא לילה שלם.
- מלאי בזמן אמת — חלון הראווה רואה את המחסן לאחר כל קליטה, משלוח ומחיקה.
- עריכה ידנית של הזמנות — רק במקרים לא סטנדרטיים: איסוף עצמי, משלוח חלקי, הנחה ידנית.
- סוג הכשל "מכרנו את מה שאין" — נסגר ברמת התאמת מלאי לפני ביצוע ההזמנה.
- אי-סנכרון מחירים ומאפיינים — נתפס אוטומטית, ולא בעיני המנהל.
- היסטוריית שינויים — ניתן לראות מי ומתי ערך את הכרטיס, ואפשר לבטל.
האפקט נמדד לא ב"נהיה נוח יותר", אלא במספרים konkretיים: כמה פריטים מתעדכנים במחזור, איזה שיעור הזמנות עובר ללא נגיעה של אדם, כמה אי-התאמות תופסת ההתאמה בשבוע. את המדדים האלה אנחנו מודדים לפני ואחרי — לפיהם רואים שהחילוף באמת עובד, ולא יוצר מראית עין.
דרכי החלפת נתונים: החלפה לפי לוח זמנים, לפי אירועים ולפי בקשה
מצב ההחלפה אינו קובע את "יופיו" של החיבור, אלא את מידת הפער בין הנתונים בקטלוג לבין המציאות ברגע נתון. נבחן שלוש סכמות עבודה ואת מגבלותיהן.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| החלפה לפי לוח זמנים | הקטלוג משתנה לעיתים רחוקות: מחירים, מלאי ומינוח מתעדכנים במקבצים. ריצה לילית מפנה עומס משתי המערכות. | השהיית העדכון שווה למרווח: בין הריצות הקטלוג מתקיים על מלאי מיושן. ריצות תכופות יוצרות עומס מיותר. |
| החלפה לפי אירועים | נדרשת תגובה לשינוי: תיקון מחיר או מלאי עובר מיד לקטלוג. | דורש תור ועיבוד אידמפוטנטי — אירוע חוזר לא אמור לשכפל פריט. תלוי בזמינות הצד המקבל. |
| סנכרון לפי בקשה | פעולות ממוקדות: לבנות מחדש כרטיס, להשלים נתונים שהוחמצו לאחר תקלה. | אינו מחליף החלפה שוטפת — זהו כלי להשלמה ידנית, לא זרם. |
בפועל משלבים בין המצבים: אירועים מכסים שינויים תפעוליים, לוח זמנים — התאמה והשלמה, ובקשה — הפעלה מחדש ידנית לאחר תקלה. כך השהיית העדכון נשארת מינימלית במקום שבו היא חשובה, והעומס ברקע אינו גדל.
המגבלה המרכזית של כל מצב היא התנגשות עריכות: אם פריט שונה משני הצדדים בין החלפות, נדרשת אסטרטגיית הכרעה, אחרת אחד הצדדים מוחק בשקט את הנתונים של האחר. אנו קובעים את עדיפות המקור ומתעדים אי-התאמות, כך שההתנגשות תהיה גלויה ולא תלך לאיבוד.
תארו כמה часто משתנה הקטלוג שלכם וכמה קריטית ההשהיה — נתאים מצב ונחזור עם הערכה.
שלבי הטמעת סנכרון: מביקורת נתונים ועד מסירה
את העבודה מתחילים בביקורת נומנקלטורה: מייצאים ספרי עזר, מוצרים, מאפיינים, מחירים, מלאי ומחסנים, סופרים כפילויות לפי מק"ט ושם, מחפשים פריטים ללא יחידות מידה וקבוצות עם היררכיה מתנגשת.
בשלב זה ניכר אילו נתונים כלל אינם ניתנים לסנכרון ללא נרמול מוקדם — אותם מתקנים לפני הפעלת החילוף, אחרת אי-ההתאמות ישתחזרו בכל מחזור.
- ביקורת נומנקלטורה. משווים את היקף ספרי העזר, כפילויות, קשרים שבורים «מוצר — מאפיין — יחידת מידה», היסטוריית שינויי מחירים ומלאי. מתעדים אילו רשומות דורשות נרמול ידני לפני ההתחלה.
- תכנון סכימת התאמת שדות. בונים טבלה «שדה מקור → שדה יעד → כלל המרה»: כיצד מתאחד השם, במה נבדלים מחיר הסיטונאי ומחיר הקמעונאי, מה עושים עם מוצרים ללא מלאי, כיצד מסומנים פריטים בארכיון.
- הגדרת כללי התנגשות. מסכמים איזה צד הוא המוביל במחיר, במלאי ובתיאורים, ומה קורה כאשר כרטיס אחד משתנה בו-זמנית משני הצדדים. ללא כלל זה החילוף נכנס ללולאה של דריסות הדדיות.
- הגדרת החילוף. מקימים ערוץ, מפעילים תיעוד יומן של כל בקשה ותגובה, קובעים לוח זמנים ומנות ייצוא, כך שהחילוף לא יחסום את עבודת הקטלוג בשעות שיא.
- בדיקה על אי-התאמות. מריצים קו מתאר לבדיקה על נתונים אמיתיים: משווים את מספר הפריטים, המחירים, המלאי והקטגוריות לפני ואחרי החילוף, ובוחנים בנפרד פריטים ששונו משני הצדדים.
- טיפול בשגיאות וניסיונות חוזרים. מגדירים התנהגות כאשר אחת המערכות אינה זמינה: תור, ניסיון חוזר, התראה לאחראי. החילוף לא אמור לאבד שינויים בעת תקלת תקשורת קצרה.
- מסירת נהלים. מוסרים תיעוד: סכימת ההתאמה, כללי ההתנגשות, הוראות להוספת שדות חדשים וסדר הפעולות בעת אי-התאמה. מדריכים את העובדים שינהלו את הקטלוג.
לאחר מסירת הנהלים החילוף פועל באופן אוטונומי, ושינויים בספרי העזר אינם דורשים מעורבות מפתח. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
כללי התאמה של מוצרים, מחירים ומחסנים
ההתאמה מתחילה בבחירת מפתח יציב: מק"ט הספק, ברקוד או מזהה חיצוני שאינו משתנה כאשר שם הפריט משתנה. אם אין מפתח, הקישור מתבצע לפי צירוף של "שם + מאפיינים", ואז כל עריכה של השם בצד МойСклад או בקטלוג האתר יוצרת כפילות. לכן כבר בהתחלה אנו קובעים כלל: פריט אחד — מפתח אחד, וכל שאר השדות נחשבים למאפיינים ניתנים לשינוי.
יחידות מידה ומכפילים — מקור שני לאי-התאמות. מוצר יכול להישמר במערכת החשבונאית באריזות, אך להימכר ביחידות בודדות או לפי משקל, ולכן בכללים נרשם מקדם המרה ויחידת הבסיס שאליה מיוחסים היתרות והמחירים.
בלי זה סנכרון МойСклад מחזיר מספר תקין, אך בממד שגוי, ובאתר מופיע "1" במקום "12".
כללי התוספת נקבעים בנפרד מהמחירים: מחיר הבסיס מגיע מהמערכת החשבונאית, והתוספת, העיגול וסף המחיר המינימלי מיושמים בצד האתר לפי קטגוריה או לפי לקוח. כך שינוי במחיר הרכש אינו מחייב עריכה ידנית של חלון הראווה, והנחות מבצעיות אינן מתנגשות עם הנתונים החשבונאיים.
חשבונאות המחסנים מבוססת על רשימה מפורשת: אילו מחסנים מספקים יתרות לאתר, כיצד מסתכמות הכמויות הזמינות ומה להציג כאשר היתרה אפס — הסרה מהמכירה או הזמנה מוקדמת.
כפילויות של פריטים נתפסות בשלב ההשוואה הראשונית: אנו מריצים את שני הקטלוגים לפי מפתחות, מציגים את אי-ההתאמות ומאחדים רשומות לפני הפעלת הסנכרון, ולא אחריו.
מה הלקוח מקבל לידיו לאחר ההטמעה
ההטמעה אינה מסתיימת בהפעלת הסנכרון, אלא במסירת ערכה שלמה שלפיה הצוות שלכם יוכל לתפעל את הסנכרון בלעדינו. כל מה שהוגדר באינטגרציה מתועד: כללי ההתאמה, טיפול בקונפליקטים, וההתנהגות בעת אי-התאמה בין מלאים.
- כללי סנכרון מוגדרים — אילו ישויות מסונכרנות (פריטים, מחירים, מלאים, ספקים/לקוחות, הזמנות), באיזה כיוון, באיזו תדירות ובאיזה טריגר מופעל הסנכרון.
- סכמת התאמה — טבלת מיפוי של שדות ומדריכים בין מערכת החשבונאות לקטלוג האתר: מק"ט, יחידות מידה, קטגוריות, שיעורי מס, מחסנים. לפיה ניתן לראות מה יקרה לפריט כאשר משתנה כל מאפיין.
- יומני סנכרון — לוגים לכל סשן: כמה פריטים התקבלו, כמה נדחו, אילו רשומות עברו לשגיאה ומדוע. לפיהם מנתחים תקלה ללא גישה לשרת.
- הוראות מפעיל — מה עושה המנהל כאשר מופיע פריט חדש, משתנה מחיר או מתבצעת עריכה ידנית של כרטיס באתר, כדי שהסנכרון הבא לא ידרוס את השינויים.
- נוהל שחזור — סדר הפעולות בעת תקלה: כיצד לחזור אחורה מסשן כושל, להפעיל מחדש את הסנכרון מנקודת ביקורת, ולשחזר את הקטלוג מגיבוי.
- תיעוד הסנכרון — תיאור הלוגיקה של האינטגרציה, נקודות ההרחבה והמגבלות: היכן מוסיפים שדה חדש, כיצד מחברים מחסן חדש או מחירון חדש.
- הרשאות ותפקידים — חשבונות עבור שירות הסנכרון עם ההרשאות המינימליות הנדרשות ונוהל החלפתם.
את הערכה אנו מוסרים בפורמט שלכם — מאגר קוד, בסיס ידע פנימי או נהלים מודפסים. לאחר המסירה אנו מקיימים סקירה עם הצוות שלכם: מראים היכן לצפות ביומנים, כיצד לקרוא את סכמת ההתאמה ומה לעשות בעת אי-התאמה.
מכאן ואילך אתם либо מנהלים את הסנכרון בעצמכם, либо חוזרים אלינו לתמיכה — בשני המקרים האינטגרציה אינה נשארת "קופסה שחורה".
תארו את המשימה — נחזור עם הערכה ותוכנית.
במה שונה ייצוא חד-כיווני מסנכרון דו-כיווני?
ייצוא חד-כיווני הוא מצב שבו הקטלוג, המלאי והמחירים יוצאים ממערכת הנה"ח אל האתר לפי לוח זמנים או לפי אירוע. האתר בסכמה הזו רק מקבל נתונים: הוא אינו מודיע למערכת הנה"ח שלקוח ביצע הזמנה או שהמוצר אזל במלאי המשלוח.
כל עוד העסק חי על ערוץ מכירה אחד, זה מספיק — אבל ברגע שמופיע מרקטפלייס, נקודת מכירה קמעונאית או מנהל שמוכר ידנית, הייצוא מפסיק לשקף את המציאות.
החלפה דו-כיוונית מוסיפה כתיבה חוזרת: הזמנות, מחיקות ותיקוני מלאי חוזרים מאפליקציית האינטרנט אל מערכת הנה"ח. כאן מופיעה המורכבות ההנדסית העיקרית — קונפליקטים של נתונים.
אותו מוצר יכול היה להשתנות משני הצדדים: המנהל תיקן את המחיר במערכת הנה"ח, והעורך התוכן — את התיאור באתר. בלי כלל עדיפות מקור, תיקונים כאלה מוחקים זה את זה, והקטלוג מתחיל "לרעוד": המחיר מתגלגל לאחור, המלאי קופץ.
לכן סנכרון דו-כיווני הוא בראש ובראשונה לא על תעבורה, אלא על מודל בעלות על שדות. בדרך כלל מסכימים כך: מערכת הנה"ח בעלת המחיר, המלאי והמק"ט, האתר — בעל התיאור, התמונות ושדות ה-SEO.
אז הקונפליקט לא נפתר "על הדרך", אלא כלל לא נוצר: כל צד כותב רק לשדות שלו, ושינויים מנוגדים נדחים לפי כלל זה.
השכבה השנייה — אידמפוטנטיות. כשל רשת, משלוח חוזר של אירוע או הפעלה מחדש ידנית של ההחלפה לא אמורים להכפיל הזמנה או למחוק מלאי פעמיים. כל פעולה מקבלת מזהה, וחזרה עם אותו מזהה מזוהה ככזו שכבר הוחלה. זה מה שמבדיל החלפה דו-כיוונית עובדת מייצוא ש"לפעמים משכפל הזמנות".
השכבה השלישית — יישוב אי-התאמות, כאשר הכללים בכל זאת לא כיסו את המקרה. יש צורך ביומן פעולות משני הצדדים ובהליך בירור ברור: נראה מי ומתי שינה את השדה, איזה ערך ניצח ומדוע. בלי יומן כזה, סנכרון דו-כיווני הופך למקור שאיש אינו סומך עליו, והצוות חוזר להשוואה ידנית.
קייס: איך הקטלוג הפסיק לסטות ממערכת החשבונאות
לפני ההטמעה, קטלוג החנות המקוונת התעדכן באמצעות ייצוא ממערכת החשבונאות לפי לוח זמנים — אחת לכמה שעות, באמצעות סקריפט שהופעל ידנית. בין הייצואים, המנהלים מכרו פריטים שכבר לא היו במלאי, והמלאי בכרטיסים לא תאם את המצב בפועל. הזמנות שנוצרו עבור מוצר שאינו קיים היו צריכות להתבטל או להיות מתואמות מחדש עם הלקוח.
מה היה לפני
העובדים בזבזו זמן על התאמות: חלק מההזמנות דרשו תיקון ידני — לוודא מלאי, להחליף פריט, לחשב מחדש את הסכום. הביטולים זרמו בקצב גבוה, והלקוחות איבדו אמון במלאי המוצג באתר.
גם סנכרון חוזר לא היה קיים: סטטוסי הזמנות ושינויים בנומנקלטורה לא חזרו למערכת החשבונאות, ובגלל זה הנתונים סטו בשני הכיוונים.
מה שינו
הגדירו חילוף דו-כיווני עם МойСклад דרך API: מלאי, מחירים ונומנקלטורה נמשכים לקטלוג, וההזמנות שנוצרו והסטטוסים שלהן חוזרים למערכת החשבונאות. החילוף מתבצע לפי אירועים, ולא לפי לוח זמנים, ולכן הכרטיס מתעדכן כמעט מיד לאחר השינוי במלאי.
הוספו התאמת מוצרים לפי מק"ט והגנה מפני קונפליקטים: אם פריט נערך משני הצדדים, העדיפות ניתנת למערכת החשבונאות, והסטייה נרשמת בלוג. שגיאות בחילוף לא מפילות את הקטלוג — התור מנסה שוב, ורשומות בעייתיות נכנסות לדוח לבדיקה.
מה נהיה
ההשהיה בעדכון המלאי הצטמצמה מכמה שעות לדקות, שיעור ההזמנות עם תיקון ידני ירד פי כמה, ומספר הביטולים מסיבת "אין במלאי" הצטמצם למקרים בודדים. המנהלים הפסיקו להשוות נתונים ידנית — הקטלוג ומערכת החשבונאות מציגים את אותו מצב.
ספקות טכניים נפוצים לפני ההתחלה
לפני ההתחלה לקוחות בדרך כלל שואלים אותן שאלות הנדסיות — לא על «נוחות הממשק», אלא על התנהגות המערכת במצבי חירום. להלן תשובות ישירות ללא שיווק: מה יקרה בעת כשל בתקשורת, כיצד נפתרים קונפליקטים והאם ניתן לסנכרן את הקטלוג באופן חלקי.
מה יקרה אם התקשורת תיקטע באמצע?
התקשורת מתבצעת בטרנזקציות במנות, ולא בחבילה אחת. כל מנה נרשמת ביומן הסנכרון רק לאחר כתיבה מוצלחת בשני הצדדים — אם הקשר אבד, המנה שלא הושלמה מסומנת כלא מבוצעת ומתבצעת שוב בהפעלה הבאה. כפילויות אינן אפשריות: לכל רשומה יש מפתח התאמה, סנכרון חוזר מעדכן את הפריט הקיים ולא יוצר פריט שני.
כיצד נפתרים קונפליקטים אם המוצר שונה משני הצדדים?
כלל ההכרעה נקבע בתחילת הדרך ומתועד בקונפיגורציה: עדיפות МойСклад, עדיפות האתר או השוואה לפי זמן השינוי האחרון. עבור שדות קריטיים — מחיר, מלאי, מק"ט — בדרך כלל אנו קובעים עדיפות למערכת החשבונאית, ולשדות תיאור ומדיה — עדיפות לאתר. רשומות בקונפליקט אינן «נמחקות בשקט»: הן נכנסות לדוח אי-התאמות שניתן לטפל בו ידנית.
האם ניתן לבצע תקשורת חלקית ולא את כל הקטלוג?
כן. הסנכרון מוגדר לפי מסננים: מחסנים ספציפיים, קבוצות מוצרים, סוגי פריטים או רק רשומות ששונו מאז ההפעלה הקודמת. הדבר מפחית את העומס ואת זמן התקשורת — בקטלוג של עשרות אלפי פריטים אין צורך בהרצה מלאה, די בדלתא.
מה עם שחזור נתונים אם משהו השתבש?
לפני כל הרצה נשמרת תמונת מצב של ההתאמה. אם לאחר התקשורת התגלתה שגיאה, אנו חוזרים לתמונת המצב ומפעילים סנכרון חוזר — הקטלוג חוזר למצב עקבי ללא עריכה ידנית של פריטים.
בואו נדון במשימת הסנכרון שלכם
אנחנו מציגים על מקרה אמיתי איך זה נראה בעבודה. אצל הלקוח — חברת סיטונאות עם מספר מחסנים — הקטלוג ב-МойСклад והאתר על פלטפורמה עצמאית חיו כל אחד חיים משלו: מנהלים תיקנו מלאים ידנית, מחירים באתר פיגרו אחרי הנתונים החשבונאיים ביום-יומיים, וחלק מהפריטים יצאו למכירה עם מלאי אפס.
הסנכרון הופעל לפי לוח זמנים אחת לכמה שעות ונכשל בקונפליקטים — בעת עריכה בו-זמנית של כרטיס אחד בשתי מערכות ניצחה זו שנרשמה אחרונה, והנתונים התפצלו בשקט.
מה שינו
ניתחנו את סכימת ההחלפה הנוכחית והעברנו אותה למודל מבוסס אירועים: שינויים ב-МойСклад ובאתר נכנסים לתור ומיושמים לפי כללי פתרון קונפליקטים — עדיפות למערכת החשבונאית במלאים ולעורך התוכן בתיאורים.
מקטעי המוצרים, הקטגוריות ויחידות המידה קיבלו מזהים יציבים, ולכן פריטים חדשים כבר לא משוכפלים בהעלאה חוזרת.
מה נהיה
השוואה מלאה של הקטלוג במקום כמה שעות אורכת דקות, עדכונים מצטברים — שניות. פערים במלאים הצטמצמו ממאות פריטים בשבוע למקרים בודדים שנראים מיד ביומן הסנכרון. החזרה למצב הקודם של הקטלוג אורכת הרצה אחת, ולא תיקון ידני.
מה נכלל בעבודה על המשימה שלכם:
- ניתוח סכימת ההחלפה הנוכחית: אילו מערכות, אילו ישויות, מי יוזם השינויים;
- כללי התאמה של מוצרים, קטגוריות, מחירים ומלאים בין המערכות;
- מדיניות פתרון קונפליקטים וטיפול בפריטים שנמחקו;
- תיעוד פעולות והתראות על תקלות;
- תוכנית הטמעה בשלבים עם בדיקה בסביבת בדיקה;
- הערכת לוחות זמנים והיקף העבודות בהתאם לגודל הקטלוג שלכם;
- תיעוד של סכימת ההחלפה והוראות למנהלים.
תארו איך ההחלפה בנויה כיום — אילו מערכות משתתפות, באיזו תדירות משתנים המלאים והמחירים, והיכן כבר נוצרו פערים. נחזור עם הערכת עבודות, תוכנית הטמעה ולוחות זמנים לפי שלבים.
