סנכרון 1С:Розница ו-Bitrix: היכן הולכים לאיבוד מלאי ומחירים
התקלה הנפוצה ביותר בסנכרון 1С:Розница ו-Bitrix נראית כך: באתר ההזמנה כבר בוצעה ושולמה, אך במחסן הקמעונאי המוצר כבר אזל — הפריט ירד למינוס, והמנהל לומד על כך מהלקוח.
השני בשכיחותו — מחירים מיושנים באתר: הוויטרינה מציגה תג מחיר של המשלוח הקודם, הקופה מפיקה מחיר אחר, ופער המלאי נמשך אחרי כל משלוח.
הסיבה כמעט תמיד נמצאת בסכמה, ולא ב"תקלה במודול". הסנכרון פועל במנות לפי לוח זמנים, ובין סשנים המלאי באתר הוא תמונת מצב ולא נתון אמת מהמחסן: אם הקמעונאות מוכרת באותו רגע, הדלתא לא מיושרת.
רזרבות, מחיקות לפי סטים, החזרות וסיווג שגוי לעיתים כלל אינם נכנסים לייצוא, ולכן פער המלאי מצטבר ומפסיק להסתדר בדוח.
כפילויות של פריטי מלאי נוצרות במקום שבו ההתאמה מתבצעת לפי שם או מק"ט במקום לפי מזהה יציב. שינו את שם הפריט, החליפו מק"ט, יצרו מחדש את צומת הסנכרון — והייצוא הבא יוצר את הכרטיס מחדש, והישן נשאר תלוי עם מלאי אפס.
שגיאות בייצוא מוצרים לעתים רחוקות מפילות את הסנכרון כולו: חלק מהפריטים לא עוברים בגלל מאפיינים לא מלאים, התמונות לא נקלטות, הצעות המסחר נשארות תלויות בלי פריט אב — הסנכרון מדווח על הצלחה, והקטלוג מאבד בשקט מדור שלם.
נבחן כיצד סוגרים זאת: התאמה קשיחה לפי מזהים, בקרת מנות בכניסה ובדיקת התוצאה לאחר כל סשן.
מה נותן סנכרון תקין של הקטלוג והמחסן
סנכרון הקטלוג נבנה סביב המק"ט: פריטי מלאי, הצעות מסחר, מאפיינים ותמונות מיוצאים אל 1C-Bitrix לפי לוח זמנים, והמלאי — בתדירות גבוהה יותר, לפי אירוע מכירה באולם.
מפתח ההתאמה מוגדר פעם אחת, ולכן פריטים חדשים מופיעים באתר בלי עריכה ידנית של כרטיסים, ומוצר שנמכר יוצא מיד מהמלאי הזמין להזמנה.
המחירים מתעדכנים באותו זרם: כללי התווספת רווח, עיגול ותקופת המבצע מוגדרים במערכת החשבונאית, והאתר מקבל ערך מוכן. בקטלוג ובסל הקניות המחיר תואם לזה שבתוקף בקופה — הפער בין הוויטרינה לקבלה מפסיק להיות עילה לבירורים.
הזמנות מהאתר נוצרות במערכת החשבונאית כמסמכים: פריטים, משלוח, איש קשר, ההנחה שהופעלה ואמצעי התשלום מועברים בלי הקלדה חוזרת. בחזרה לאתר חוזרים סטטוסים ונתוני רזרבה, ולכן הקונה רואה שההזמנה נאספה, שולמה או הועברה למשלוח.
האפקט נמדד במדדים מוחשיים: שיעור הפריטים עם פער מלאי, הזמן מהמכירה באולם ועד העדכון באתר, שיעור ההזמנות שלא היה צורך לתקן ידנית. סוג התקלה "מכרנו משהו שאין" נעלם יחד עם ייצוא סדיר — המנהל לא מאשר מלאי בטלפון, אלא רואה אותו במערכת.
דרכי סנכרון נתונים: קבצים, שירות, אוטובוס הודעות
הסנכרון של 1С:Розница עם האתר לעתים רחוקות נסגר במנגנון אחד. קטלוג, מחירים ומלאי סובלים השהיה של דקות, אבל הזמנה והסטטוס שלה — לא: הקונה ממתין לאישור, והמנהל לא אמור לראות פריט שנמכר כזמין. לכן אנחנו קודם מקבעים את הדרישות להשהיה ולמחיר הטעות בעת חוסר סנכרון, ורק אחר כך בוחרים את השיטה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ייצוא קבצים לפי לוח זמנים | קטלוג, מחירים, מלאי; סנכרון כל 15–30 דקות דרך CommerceML | ההשהיה שווה למרווח; בעת ניתוק יש לבדוק את שלמות הקובץ ולחזור על המחזור; סשנים במקביל מתנגשים |
| קריאה ישירה לשירות | הזמנות, סטטוסים, רזרבות — במקום שבו נדרשת תשובה מיידית | המערכות מקושרות ישירות: אי-זמינות של צד אחד עוצרת את הסנכרון; חובה ניסיונות חוזרים והגנה מכפילויות |
| אוטובוס הודעות | מספר מערכות או מחסנים, עומס גבוה, אסור לאבד אירועים | דורש תשתית נפרדת ובקרת תורים; עלות עבודה גבוהה יותר בהטמעה ובתחזוקה |
בפועל לרוב עובד שילוב: פריטי המלאי והמלאי עוברים במנות לפי לוח זמנים, וההזמנות — דרך שירות עם אישור. כשקיימות כמה נקודות מכירה או מחסנים, הסנכרון המנותי מתחיל להתנגש עם עצמו, ואז מוציאים אותו לאוטובוס. מה כל אפשרות גובה בתחזוקה — נבחן בהמשך.
שלבי ההטמעה: מביקורת פריטי המלאי ועד למסירה
הסנכרון בין המערכת החשבונאית לאתר אינו הפעלה של מודול מוכן, אלא רצף עבודות שבו סדר השלבים קובע כמה תיקונים ידניים ייפלו על המנהלים לאחר ההשקה. אנחנו תמיד הולכים ממצב המרשמים אל סכמת הזרימות, ורק אחר כך נוגעים בקטלוג הפעיל. להלן כיצד נראה הרצף הזה בפרויקטים של «Розница» — «Bitrix».
-
ביקורת פריטי המלאי. מייצאים את המרשם כפי שהוא ומנתחים אותו: כפילויות לפי שם, פריטים בלי מק"ט, הצעות מסחר בלי מאפיינים, שמות קטועים, מוצרים עם מחיר אפס. מקבעים רשימת תיקונים שנעשים במערכת החשבונאית ולא בקטלוג האתר — אחרת הסנכרון הראשון כבר ידרוס אותם.
-
התאמת מרשמים. בונים טבלת התאמות: מחסנים, סוגי מחירים, יחידות מידה, לקוחות עסקיים, סטטוסי הזמנות. בלעדיה הסטטוס "שולם" מהאתר הופך לסטטוס חדש במערכת החשבונאית, וההזמנות עוברות למחסן הלא נכון.
-
סכמת הזרימות וכללי הייצוא. מגדירים את הכיוון וההרכב של הסנכרון: פריטי מלאי, מחירים, מלאי, הזמנות, תמונות, מאפיינים. מגדירים סינונים ולוח זמנים — למשל, מייצאים רק מוצרים עם מלאי ומקבוצות פעילות, כדי שהקטלוג לא יתנפח בפריטים מתים.
-
סביבת בדיקה. פורשים עותק של הקטלוג ושל בסיס הנתונים החשבונאי, ומריצים מחזור מלא: ייצוא פריטי מלאי, הזמנה מהאתר, החזרת סטטוס, ביטול פריט. בודקים את יומן הסנכרון ואת הזמן של כל מעבר.
-
בדיקת התנגשויות נתונים. מראש מחליטים מה מנצח בעת פער: המלאי באתר או במערכת החשבונאית, עריכה ידנית של הכרטיס או הייצוא, כפילות לפי מק"ט או לפי ברקוד. את הכללים מקבעים בכתב, כדי שלא ייבחנו מחדש בכל תקלה.
-
העברה לסביבת הייצור. מבצעים ייצוא מלא ראשוני, מפעילים את לוח הזמנים, בודקים את המחזורים הראשונים ואת השגיאות לפי פריטים. לאחר מכן מוסרים את נוהל הסנכרון, את ההרשאות ואת ההוראות למנהלים לתיקון הקטלוג.
מערך תיעוד והגדרות בסיום
לאחר השקת הסנכרון של 1С:Розница — Bitrix, אצל הלקוח נשאר מארז של ארטיפקטים שלפיו אפשר לתחזק את המערכת בלעדינו: מה הותאם למה, לפי איזה לוח זמנים פועלים הסשנים, ומה עושים כשהייצוא נתקע. זהו תיאור של סביבת הסנכרון שלכם, ולא תבנית.
- סכמת האינטגרציה — צומתי סנכרון, כיוון הזרימות (פריטי מלאי, מלאי, מחירים, הזמנות, סטטוסים), משתמשי שירות וההרשאות שלהם.
- מפת זרימת הנתונים — טבלה «אובייקט ב-1С — ישות בקטלוג — תדירות — מצב ייצוא — האחראי על המרשם».
- כללי ההתאמה — פריטי מלאי והצעות מסחר, מחסנים, סוגי מחירים, סטטוסי הזמנות, אמצעי תשלום; בנפרד — ההתנהגות לפריטים חדשים ולכפילויות.
- הגדרות הצומת ולוח הזמנים — פרמטרי הסשנים, משימות מתוזמנות, חלונות ייצוא וגדלי מנות, כדי שהסנכרון לא יחפוף לשיא העומס על הקטלוג.
- יומן שגיאות — תקלות אופייניות: פריט לא הותאם, התנגשות מלאי, סשן שנקטע, כשל בהרשאה; לכל אחת — הסיבה וסדר הפעולות.
- נוהל התחזוקה — מי ומתי בוחן את היומן, כיצד מפעילים סנכרון מלא ידנית, כיצד מחזירים ייצוא שנכשל.
- הוראות למנהל המערכת — תרחישים: הפעלה ועצירה של הסנכרון, אבחון, הוספת מחסן, שינוי לוח זמנים, בקרה לפני פרסום.
- פרוטוקול הקבלה — פריטים והזמנות ביקורת שהורצו דרך הסנכרון לפני המסירה, עם התוצאה הצפויה.
מקרה בוחן: כיצד רשת חנויות סילקה פערי מלאי
מה היה
רשת חנויות ייצאה מלאי ידנית: פעם ביום נוצר קובץ, והעלו אותו לאתר. בין מכירה באולם לעדכון הקטלוג חלפו עד 20 שעות — בוויטרינה נותר מוצר שאינו עוד על המדף, ואצוות חדשות הופיעו באיחור.
התוצאה: עד 15% מהשורות בהזמנות תוקנו ידנית, התמיכה קיבלה כ-30 פניות בחודש מהסיבה "יש באתר, אין בחנות", ומנהלים ביטלו הזמנות והחזירו תשלומים באופן קבוע.
מה עשינו
העברנו את הסנכרון מ-«1С:Розница» אל 1C-Bitrix מייצוא לילי לסנכרון לפי אירועים: שינוי במלאי או במחיר עובר לאתר מיד לאחר רישום המסמך. ההזמנות חוזרות למערכת החשבונאית עם שיוך למחסן שממנו המוצר באמת נמסר, ולכן הרזרבה כבר לא "נתקעת" על פריט שגוי.
בנפרד סגרנו את פערי המרשמים: התאמנו פריטי מלאי לפי קוד וברקוד, והוספנו יומן התנגשויות — אם פריט לא מסתדר, הוא לא עולה לוויטרינה אלא עובר לדוח.
מה השתנה
- השהיית עדכון הנתונים: 20 שעות → 2-3 דקות.
- שיעור התיקונים הידניים בהזמנות: 15% → פחות מ-1%.
- פניות לתמיכה בנושא מלאי: 30 → 4-5 בחודש.
טיפול בהתנגשויות פעם בשבוע גובה מסחב המלאי כחצי שעה במקום השוואה יומית בכל החנויות. ייצוא מלא חוזר של הקטלוג הושאר כרשת ביטחון — הוא פועל בלילה ואינו מעמיס על הוויטרינה.
במה שונה ייצוא לפי לוח זמנים מייצוא לפי אירועים?
ייצוא לפי לוח זמנים הוא משימה מתוזמנת בתדירות סנכרון קבועה: פעם בכמה דקות, פעם בחצי שעה, בלילה בתדירות נמוכה יותר. העומס צפוי, מפזרים אותו לאורך הזמן, והרצה שהוחמצה משלימה את השינויים במחזור הבא. המחיר — השהיה בין המכירה לאתר: הקבלה כבר הופקה, והמלאי בוויטרינה יתעדכן רק במעבר הבא.
ייצוא לפי אירועים מתחיל עם עצם השינוי — נרשמה קבלה, נוצר מסמך קליטה, השתנה מחיר. הסנכרון פועל מיד, וההשהיה בין המכירה לאתר נמדדת בשניות ולא במרווחים. זה פותר במקום שבו העותק האחרון נחטף בדקות: הוויטרינה מורידה את המוצר מהמכירה לפני שהספיקו למכור אותו פעמיים.
הצד השני — שיאים: מכירות בערב וקליטת סחורה יוצרים פרץ של הרצות, וכל אחת קוראת את בסיס 1С וכותבת לקטלוג. לכן מצמצמים את מצב האירועים לרשימת אובייקטים, מציבים תור וניסיון חוזר בעת ניתוק התקשורת. בלי זה הייצואים נערמים למפולת ומאטים גם את הקופה וגם את ממשק הניהול.
עם התנגשויות גרסאות נתונים שתי הסכמות מתמודדות באותה מידה: את המוצר מתקנים גם ב-1С וגם בכרטיס באתר. מראש מסכמים מי המקור הראשי, ומעבירים תג שינוי, כדי שרשומה מאוחרת לא תדרוס תיקון עדכני יותר.
בפועל לרוב בוחרים בגרסה משולבת: מחירים, מלאי ורשימות חסומים — לפי אירוע, תיאורים ותמונות — לפי לוח זמנים. מה לבחור — ייצוא לפי לוח זמנים או לפי אירועים — קובע לא גודל הקטלוג, אלא כמה יקרה הטעות במלאי. את הפרמטרים מקבעים בעת ההגדרה: רשימת האובייקטים, תדירות הסנכרון, עדיפות המקור.
ספקות טכניים נפוצים לפני תחילת העבודה
האינטגרציה של הקטלוג עם המערכת החשבונאית מלחיצה לא בפני עצמה, אלא בסיכונים: עצירת מכירות בזמן העבודה, ייצוא שנקטע ופריטי מלאי שהתפזרו. להלן תשובות לספקות שנשמעים לרוב בשלב ההערכה.
לוחות הזמנים תלויים בנפח הקטלוג ובמספר המחסנים: סנכרון טיפוסי לפי מחירון אחד — ימים, מטריצה עם כמה מחסנים וסוגי מחירים — זמן ארוך בהרבה. לאחר ההשקה נשאר יומן סנכרון עם היסטוריית מנות ונוהל לטיפול בפערים במלאי ובמחירים.
האם יהיה צורך לעצור את האתר בזמן ההגדרה?
את הסנכרון בונים ובודקים על עותק, ואת בסיס הנתונים הפעיל מחברים לנוהל בשלב האחרון. הוויטרינה ממשיכה למכור: העדכון פועל ברקע ואינו חוסם ביצוע הזמנות.
מה יקרה אם הייצוא ייקטע באמצע?
הנוהל פועל במנות ושומר מצב בכל שלב, ולכן הייצוא הבא ממשיך מהמקום שבו נקטע ולא מתחיל מהתחלה. המלאי והמחירים מחושבים מחדש כך שהמוצר לא יירד לאפס בוויטרינה.
יש לנו כמה מחסנים וסוגי מחירים — כיצד זה משתלב בקטלוג?
כל מחסן וסוג מחיר מקבלים הצעת מסחר נפרדת עם המלאי שלה. את המאפיינים מעבירים לפי כללי ההתאמה, ולכן בחירה לפי מאפיינים ומסננים לא מתפרקים.
אנחנו משנים מק"טים ושמות — האם הסנכרון ישרוד זאת?
הקישור מתבצע לפי מזהה פנימי של הפריט ולא לפי שם, ולכן שינוי שם אינו יוצר כפילות כרטיס. בעת החלפת מק"ט סוגרים את הכתובת הישנה בהפניה מחדש, כדי שהדף לא ייפול מהחיפוש.
מה עם התמיכה לאחר ההטמעה?
יומן הסנכרון מראה באיזה שלב ובאיזה פריט הנתונים התפצלו, ולכן הטיפול נעשה לגופו של עניין ולא בהפעלה מחדש של כל הסנכרון. תורנות למקרה תקלה ותיקון כללי הייצוא נידונים בנוהל נפרד.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי לדון במשימת האינטגרציה לעניין ולא לפי מספרים ממוצעים, בשיחה הראשונה אנחנו מפרקים את סביבת הסנכרון שלכם: אילו מרשמים משתתפים, היכן נתוני האב של מוצרים, מלאי ומחירים, כמה נקודות מכירה וכיצד הזמנה מהאתר נכנסת לחשבונאות. בנפרד בודקים מה כבר מוגדר — כללי הייצוא, התאמת פריטי המלאי, לוח הזמנים.
- אילו ישויות מסונכרנות: פריטי מלאי, מאפיינים, מחירים, מלאי לפי מחסנים, הזמנות וסטטוסי תשלום.
- מי הבעלים של הנתונים ולפי איזה כיוון מתבצעת הכתיבה, כדי שתיקונים לא ידרסו זה את זה.
- באיזו תדירות נדרש הסנכרון והאם מותר פער בין המלאי למחסן בפועל.
- כיצד מטפלים בפערים: יומן סנכרון, חזרה על מנות, הגנה מכפילות פריטים.
- כיצד בודקים בסביבת הבדיקה: השוואת מלאי וסכומים, תרחישי ניתוק תקשורת.
- מה כלול במסירת התיעוד: סכמת זרימת הנתונים, הגדרות הכללים, נוהל הפעלה וחזרה לאחור.
- כיצד בנויה התחזוקה לאחר ההשקה: בקרת תורי הסנכרון והרחבת הכללים לקטגוריות חדשות.
ההערכה ותוכנית העבודה מגיעות כרשימת שלבים עם הרכב ההגדרות וקריטריוני קבלה לכל סעיף — אפשר להשוות אותה עם הצוות שלכם ועם אנשי החשבונאות. תארו את המשימה: אילו מערכות, כמה נקודות, מה כבר עובד. נחזור עם הערכה ותוכנית.