כשהגדרת החלפת נתונים של 1C-Bitrix נשברת בפרודקשן
הגדרת החלפת הנתונים של 1C-Bitrix בין «1С:Комплексная автоматизация» לאתר עוברת כמעט תמיד בצורה חלקה בסביבת בדיקות ונשברת בפרודקשן — תחת עומס, כשהזמנות פעילות ומנהלים עובדים במקביל.
הראשון שמתגלה הוא אי-סנכרון מלאי: מוצר נמכר באולם, אך באתר הוא עדיין זמין להזמנה, או להפך — הפריט קיים במחסן, אך הקונה רואה «אזל מהמלאי». הסיבה בדרך כלל היא שסשנים של החלפת נתונים מתבצעים בתדירות נמוכה יותר מקצב שינוי הנתונים, וחלק מהמלאי נופל מייצוא המוצרים בגלל מאפיינים חסרים.
סוג התקלות השני — כפילויות מלאי. אם ב-1С שינו שם או יצרו מחדש פריט, ובאתר הוא מותאם לפי שם ולא לפי מזהה יציב, סנכרון הקטלוג מוליד תאומים: שני מוצרים עם אותו מק"ט, מלאים שונים ומחירים שונים. הקטלוג מתפשט, החיפוש והמסננים מתחילים להחזיר זבל, והמנהלים מאחדים כרטיסים ידנית.
השלישי — תורים תקועים של החלפת הזמנות. הסשן נופל באמצע, חלק מההזמנות נשארות בסטטוס ביניים, והרצה חוזרת או מכפילה אותן או מאבדת אותן. בנפרד צצות הזמנות אבודות: הקונה שילם, אך המסמך לא הגיע ל-1С — הפער מתגלה רק בבדיקת התאמות.
כל התקלות הללו מאוחדות על ידי דבר אחד: ההחלפה עובדת כקופסה שחורה, בלי יומן ובקרת שלמות. ננתח כיצד זה נסגר באמצעות הגדרה, ולא באמצעות תיקונים ידניים הרואיים.
מה נותן חילופי נתונים מדויקים
מהירות ייצוא במקום חלונות לילה
החילופין בנויים על ייצוא מנותב של שינויים: מועברים רק אותם פריטי מלאי, מחירים ויתרות שהשתנו מאז הסשן הקודם, ולא כל הקטלוג כולו. סנכרון מלא של קטלוג עם עשרות אלפי פריטים מסתיים בדקות במקום שעות, והחילופין השוטפים מתנהלים בסשנים קצרים ואינם חוסמים את עבודת המנהלים במערכת החשבונאית. עומס השיא על האתר חל בשעות העבודה, ולכן לוח הסשנים מיושר כך שהייצוא הכבד לא יתנגש בפעילות הקונים.
יתרות מעודכנות ללא אי-התאמות
הסיבה המרכזית לאי-סנכרון היא עריכות מקבילות: מנהל משנה מחיר במערכת החשבונאית, ועורך תוכן בו-זמנית נוגע בכרטיס באתר. אנו מקבעים לכל ישות מקור אמת אחד: מחירים, יתרות ומלאי מחסן מגיעים רק מהמערכת החשבונאית, ואילו תיאורים ומדיה נשארים בצד האתר ואינם נדרסים בעת החילופין.
התאמת פריטים מתבצעת לפי מזהים יציבים, ולא לפי שם, ולכן שינוי שם מוצר אינו יוצר כפילות ואינו קוטע את הקשר.
פחות עבודה ידנית
לאחר ההגדרה מתבטלים הקלדה ידנית של מחירים ויתרות, הסרת פריטים מפרסום כאשר היתרה אפסית, והשוואת קטלוגים בסוף היום.
כללי החילופין מתארים תרחישים אלה במפורש: פריט עובר לארכיון בהיעדרו מהמחסן, חוזר למכירה עם קבלת סחורה, ומקרים שנויים במחלוקת מגיעים לדוח אי-התאמות ולא לתיבת הדואר של המנהל.
עמידות בפני תקלות
סשן החילופין אידמפוטנטי: הפעלה חוזרת לאחר ניתוק הקשר אינה מכפילה פריטים ואינה פוגעת בנתונים שכבר הועברו. שגיאות בפריטים ספציפיים אינן עוצרות את כל החילופין — פריטים בעייתיים עוברים ליומן עם הסיבה, והשאר מסונכרן כסדרו. אנו מנתחים כיצד זה נסגר בקטלוג ובמערכת החשבונאית שלכם.
אפשרויות סנכרון: מתואם ועד מבוסס אירועים
בחירת הסכימה קובעת לא רק את ההשהיה בהופעת המוצר באתר, אלא גם כיצד המערכת תתנהג בעת תקלה: סנכרון מתואם לפי לוח זמנים שורד ניתוק ערוץ בשלווה, בעוד שמבוסס אירועים דורש תור ואספקה חוזרת. להלן שלוש אפשרויות עבודה שאנו מגדירים, והמגבלות האמיתיות שלהן.
סנכרון מתואם לפי לוח זמנים
מנגנון ההגדרה הסטנדרטי של 1C-Bitrix: הייצוא יוצר חבילות ומעביר אותן לפי לוח זמנים — פעם בשעה, פעם ביום או בחלון לילה. מתאים כאשר הקטלוג משתנה לעיתים רחוקות, והמחירים והמלאי אינם קריטיים לדקות.
המגבלה — חלון אי-סנכרון: עד ההרצה הבאה האתר מציג מלאי של אתמול, והקונה עלול לבצע הזמנה על מוצר שכבר אינו קיים.
סנכרון מבוסס אירועים
כאן הייצוא מופעל על ידי טריגר — שינוי כרטיס, רישום מסמך, שינוי סטטוס הזמנה. ההשהיה מצטמצמת לדקות, אך מופיעה תלות בזמינות שירות הסנכרון: ללא תור וניסיונות חוזרים חלק מהאירועים הולכים לאיבוד בעת תקלת רשת. אנו תמיד מוסיפים יומן אספקה והשלמה של חבילות שאבדו — אחרת הפער מצטבר מבלי לשים לב.
סכימה היברידית
בפועל לרוב האופטימלית היא השילוב: קריטי (מלאי, מחירים, סטטוסי הזמנות) עובר באופן מבוסס אירועים, ואילו ישויות כבדות — תיאורים, תמונות, מאפיינים — מיוצאות לפי לוח זמנים בחלון לילה. כך אנו מסירים עומס מהמסד בשעות שיא ואיננו דוחפים את הקטלוג המלא בכל שינוי.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| מתואם לפי לוח זמנים | קטלוג יציב, מלאי לא קריטי | השהיה עד ההרצה הבאה, סיכון למכירת מוצר שאינו קיים |
| מבוסס אירועים | שינויים תכופים במחירים ובמלאי, מכירות פעילות | נדרשים תור ואספקה חוזרת, רגיש לתקלות בערוץ |
| היברידי | קטלוג גדול עם תדירות שינויים משתנה | מורכב יותר בהגדרה ובתמיכה, דורש הפרדת ישויות לפי זרמים |
את תדירות הסנכרון אנו בוחרים לפי העומס בפועל: בוחנים כמה שינויים בשעה מייצרת מערכת החשבונאות, ומכך בוחרים את המרווח או הטריגרים.
איך אנחנו מגדירים סנכרון: שלבי העבודה
מתחילים בביקורת: בודקים אילו ישויות כבר מיוצאות, לפי איזה סימן מזוהה שינוי של אובייקט, איך מוגדרות התאמות מפתחות ומה קורה לפריטים שאין להם מקבילה בצד האתר.
בשלב הזה בדרך כלל עולים כפילויות של פריטי מלאי, אי-התאמות ביחידות מידה ושאריות "תקועות" — טיפול בהם לפני תחילת העבודה חוסך שבועות של תיקונים אחר כך.
בהמשך מתכננים סכמת סנכרון שתתאים לתהליך שלכם, ולא לתבנית גנרית: מגדירים מה ובאיזה כיוון מועבר, באיזו תדירות, ומה נחשב למקור האמת לגבי מחיר ושאריות. בנפרד מתעדים כללי התנהגות בעת קונפליקט — למשל, כאשר מוצר שונה בו-זמנית במערכת החשבונאית ובקטלוג באתר.
- ביקורת הסנכרון הנוכחי. משרטטים מפת זרימת נתונים, מאתרים צווארי בקבוק במהירות ובלוגיקה, ומעריכים את היקף מפתחות הנתונים והמסמכים.
- תכנון האינטגרציה. מתאמים את הרכב האובייקטים המיוצאים, כיוון הסנכרון, לוח הזמנים להרצה וכללי פתרון קונפליקטים.
- הגדרת הייצוא. מגדירים צומתי סנכרון, התאמות של שדות ומפתחות נתונים, מסננים לפי הצעות מסחריות, מחסנים וסוגי מחירים.
- הרצת בדיקה. מריצים את הסנכרון על עותק של נתוני אמת: בודקים את תקינות המחירים, השאריות, המאפיינים והתמונות של המוצרים.
- בדיקת עומס. בוחנים כיצד הסנכרון מתנהג בהיקף מלא של הקטלוג ובזמן עבודה מקבילה של מנהלים במערכת החשבונאית.
- מסירה ותקנון. מגדירים הרצה אוטומטית לפי לוח זמנים, תיעוד ביומן והתראות על שגיאות, ומוסרים הוראות לצוות שלכם.
לאחר המסירה הסנכרון פועל לפי לוח זמנים ללא התערבות ידנית, ותקלות נראות ביומן ולא בתלונות של לקוחות על מחיר שגוי. תארו את סכמת החשבונאות והקטלוג שלכם — נחזור עם הערכה ותוכנית עבודה להגדרת הסנכרון.
מה נשאר לכם לאחר ההגדרה
הגדרת סנכרון היא לא רק ערוץ עובד בין מערכת הנה"ח לאתר, אלא גם סט ארטיפקטים שלפיהם הצוות שלכם יוכל להפעיל, לאבחן ולפתח את הסנכרון הזה בלעדינו. להלן מה שאנחנו מוסרים עם סיום הפרויקט.
- תרשים הסנכרון — מפת זרימות הנתונים: אילו ישויות (פריטים, מחירים, מלאי, הזמנות, לקוחות) זורמות לאיזה כיוון, באיזו תדירות, מה משמש כמפתח התאמה וכיצד מטופלים קונפליקטים של גרסאות רשומה.
- קונפיגורציות הסנכרון — פרופילים מיוצאים וכללי התאמת שדות משני הצדדים, כולל הגדרות צמתים, תורים והרשאות גישה של משתמש השירות. נפרס על קונטור נקי ללא הרכבה ידנית.
- נוהל הפעלה — לוח זמנים של סנכרונים, סדר הפעולות בעת אי-התאמת מלאי, נקודות בקרה וכללי הסלמה: מה מנהל מערכת סוגר בעצמו, ומה דורש התערבות מפתח.
- מדריך למנהל מערכת — תרחישים שלב-אחר-שלב לפעולות שגרתיות: הפעלה מחדש ידנית של סנכרון, ייצוא חוזר של פריט, בדיקת יומן, שחזור סנכרון כושל עד לנקודה תקינה אחרונה.
- תיעוד האינטגרציה — תיאור מבנה הנתונים, מפתח קודי שגיאה עם סיבות ודרכי טיפול, רשימת תלויות בגרסאות של קונפיגורציות ומודולים.
- רישום וניטור — לוגים מוגדרים של סנכרון והתראות על תקלות: מנהל המערכת לומד על הבעיה מהתראה, ולא מלקוח שלא ראה את המוצר באתר.
- צ'ק-ליסט קבלה — תרחישי בדיקה על קונטור בדיקות: ייצוא מלא, סנכרון אינקרמנטלי, טיפול באי-התאמות, התנהגות כאשר אחד הצדדים אינו זמין.
כל זה נשאר אצלכם בצורת תיעוד עובד, ולא הסכמות בעל-פה. תארו את המשימה — נחזור עם הערכה ותוכנית שבה יהיה ברור אילו ארטיפקטים אתם מקבלים בסיום.
מקרה בוחן: תיקון חוסר סנכרון בין הקטלוג להזמנות
מה היה לפני
פנה אלינו חנות אינטרנטית על 1C-Bitrix עם קטלוג של כמה עשרות אלפי פריטים וסנכרון עם 1С:Комплексная автоматизация לפי לוח זמנים. הסנכרון הופעל פעם בשעה, רץ בחבילה מלאה ולעיתים קרובות לא הגיע לסיומו: הסקריפט נתקל במגבלת זמן ההרצה, נשבר באמצע והותיר חלק מהמוצרים עם יתרות מיושנות.
המנהלים ראו באתר מלאי שכבר לא היה במחסן, והזמנות שנעשו ברגע הסנכרון לא תמיד נכנסו ל-1С — היה צורך להשוות אותן ידנית ביומן.
מחיר חוסר הסנכרון התברר כגבוה מכפי שנדמה: חלק מההזמנות אבדו בין האתר למערכת החשבונאית, ועל השוואה ידנית של יתרות והזנה חוזרת של מסמכים הושקעו כמה שעות ביום.
מה שינו
פירקנו את הסנכרון לשלבים והעברנו אותו מחבילה מלאה לייצוא מנותח עם נקודת בקרה: כל מנה של קטלוג והזמנות מאושרת, ובמקרה של תקלה הסנכרון ממשיך מהפריט המוצלח האחרון ולא מההתחלה.
ההזמנות קיבלו תור נפרד עם עדיפות — הזמנה חדשה יוצאת ל-1С מחוץ ללוח הזמנים הכללי, ולכן אינה ממתינה למחזור הבא. הוספנו יומן סנכרון עם סטטוסים ברורים והתראה במקרה של חריגה: אם פריט לא עבר, האחראי רואה זאת מיד ולא כעבור יממה לפי תלונת הלקוח.
מה נהיה
הסנכרון הפסיק להישבר: המנות נכנסות במגבלות, ונקודת החידוש סוגרת תקלות בלי אובדן נתונים. הפערים ביתרות הצטמצמו ממקרים קבועים למקרים בודדים, וההזמנות שאבדו נעלמו כקטגוריה — כל הזמנה מאושרת ב-1С ונראית ביומן.
הפעולות הידניות של השוואה והזנה חוזרת הצטמצמו פי שלושה בערך: המנהלים עוסקים בהזמנות ולא בבירור פערים.
תוצאה כזו ניתנת לא על ידי הסנכרון עצמו אלא על ידי הארכיטקטורה שלו — מנות, עדיפות הזמנות ויומן שקוף. תארו את התצורה שלכם ואת תרחיש הסנכרון הנוכחי — נחזור עם הערכה ותוכנית עבודה.
במה שונה חילוף טיפוסי מחילוף אירועי?
חילוף טיפוסי פועל לפי לוח זמנים: משימה מתוזמנת במרווח נתון סוקרת את המקור, שולפת שינויים ומחילה אותם על היעד. המפתח כאן — החילוף מתבצע ב"מנות" ואינו יודע מה בדיוק השתנה מאז ההרצה הקודמת: הוא קורא את כל מה שנכנס לבחירה לפי תאריך שינוי או לפי מרשם מידע.
מכאן גם התכונות האופייניות — עומס צפוי, יומן מובן, שחזור פשוט לאחר תקלה: החילוף נפל, חיכינו למחזור הבא, והוא הדביק את מה שהוחמץ. המחיר של אמינות כזו — השהיה. בין עריכת פריט במערכת החשבונאית להופעתו באתר חולף מרווח, ועבור קטלוג, יתרות או מחירים זה יכול להיות קריטי.
חילוף אירועי בנוי הפוך: השינוי נרשם ברגע כתיבת האובייקט ומיד מוכנס לתור לייצוא. לא מחכים לתקתוק של לוח הזמנים — התגובה מתרחשת עם התרחשות האירוע, ולכן הנתונים באתר ובמערכת החשבונאית מתכנסים כמעט באופן מיידי. אבל לגישה יש מחיר הנדסי משלה.
נדרש תור אמין עם אישור מסירה: אם היעד אינו זמין, האירוע לא צריך ללכת לאיבוד, אחרת נקבל אי-התאמה שאיש לא ישים לב אליה. נדרשת הגנה מפני מפולת — העברה מחדש המונית של מסמכים מייצרת אלפי אירועים, ובלי קיבוץ הם יפילו גם את האתר וגם את המערכת החשבונאית. נדרשת גם אידמפוטנטיות: מסירה חוזרת של אותו אירוע לא צריכה ליצור כפילות.
בפועל הבחירה אינה בינארית. ישויות שונות דורשות מצב שונה: יתרות ומחירים הגיוני להעביר באופן אירועי, כי מהעדכניות שלהם תלויה המכירה, ואילו מגדירים, צדדים נגדיים או היסטוריית הזמנות — בחילוף טיפוסי לפי לוח זמנים, שבו השהיה של כמה דקות אינה מטרידה איש.
לעתים קרובות התוכנית העובדת היא היברידית: ערוץ אירועי לדברים הקריטיים ומתוזמן כרשת ביטחון, שמדביק את כל מה שמסיבה כלשהי לא עבר כאירוע.
בנפרד עומדת השאלה מה נחשב ל"שינוי". במערכת החשבונאית אותו אובייקט יכול לעבור העברה מחדש עשרות פעמים ביום, ואם לשדר כל העברה, הערוץ האירועי ייחנק מרעש.
לכן לפני הגדרת החילוף אנחנו מנתחים אילו שדות ואילו פעולות באמת חשובים לאתר, ורק אותם הופכים לאירועים — השאר עובר לחילוף הטיפוסי. ניתוח כזה הוא שקובע איזה מצב להציב לכל ישות.
שאלות טכניות נפוצות בנושא סנכרון
סנכרון בין מערכת הנהונהלת לבין האתר נשבר באופן צפוי — וכמעט תמיד משלוש סיבות: גרסאות המודולים התפצלו, הקטלוג גדל מעבר להגדרות ברירת המחדל, או שהסנכרון עבר חלקית והותיר נתונים במצב ביניים. להלן ניתוח של כל מקרה, כיצד אנו סוגרים אותו ומה נשאר אצל הלקוח לאחר העבודה.
מה לעשות בעת קונפליקט בין גרסאות של מודול הסנכרון?
קונפליקט נוצר כאשר המודול בצד האתר והמטפל בצד מערכת הנהונהלת נבנו עבור גרסאות שונות של הפרוטוקול: חלק מהשדות מפסיקים לעבור, הסנכרון מסתיים ללא שגיאה מפורשת, והפערים מצטברים בשקט.
אנו מקבעים זוג גרסאות עובד, מנטרלים עדכון אוטומטי של רכיבי הסנכרון ומעבירים את ההגדרות לקונפיגורציה שאינה נדרסת בעת עדכון. לפני כל עדכון אנו מריצים סנכרון בדיקה על עותק — אם מדריכים או מאפייני מוצרים מתפצלים, אנו חוזרים אחורה לפני עדכון הפרודקשן.
כיצד להגדיר סנכרון כאשר בקטלוג עשרות אלפי פריטים?
סנכרון מלא בנפח כזה נתקל במגבלות זמן ריצה וזיכרון: התהליך נקטע באמצע, וחלק מהפריטים נשאר לא מעודכן. אנו מפצלים את הייצוא למנות, מפעילים העברה מדופדפת ומגדירים סנכרון רק עבור אובייקטים שהשתנו מאז ההרצה הקודמת.
מקטעים כבדים — מחירים, מלאי, מאפיינים — מוציאים לסשנים קצרים נפרדים לפי לוח זמנים, כך שכל מחזור נכנס לחלון הזמן המוקצב.
כיצד לבצע rollback של סנכרון כושל?
לפני ההרצה אנו יוצרים תמונת מצב של הטבלאות המושפעות ושומרים יומן פעולות — זה מספיק כדי להחזיר את הקטלוג וההזמנות למצב שלפני הסנכרון ללא אובדן נתונים שנצברו באתר. ה-rollback מבוצע באופן ממוקד: משוחזרים רק הישויות שהסנכרון שינה, והזמנות משתמש ובקשות נשארות ללא פגע.
לאחר ה-rollback אנו משווים סכומי ביקורת במקטעים המרכזיים ורק לאחר מכן מריצים את הסנכרון מחדש עם הגדרות מתוקנות.
האם ניתן לסנכרן ללא עצירת האתר?
כן, הסנכרון פועל ברקע ואינו חוסם את חלון הראווה: הקונה ממשיך לבצע הזמנות בזמן שמחירים ומלאי מסונכרנים. אנו מגדירים תור ועדיפויות כך שנתונים קריטיים — זמינות ומחיר — מתעדכנים ראשונים, ותיאורים ותמונות מדביקים אחריהם. אם סשן הסנכרון נופל, הוא מופעל מחדש מנקודת ההצלחה האחרונה, ולא מאפס.
בואו נדון במשימה שלכם לסנכרון
סנכרון בין 1С לאתר כמעט אף פעם לא נשבר "סתם כך" — מאחוריו עומדות סיבות קונקרטיות: מדריכי פריטים לא תואמים, הזמנות כפולות, מלאי בחלון הראווה לא תואם למחסן. כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים לראות את הסכימה הנוכחית שלכם בשלמותה.
תארו כיצד הסנכרון בנוי כעת: לפי איזה רגולציה הוא מופעל, אילו אובייקטים משתתפים, היכן נמצא "צוואר הבקבוק". זה מספיק כדי להבין את היקף העבודה ולא להמציא את מה שכבר עובד אצלכם.
מה שמועיל לצרף לתיאור המשימה:
- סכימת הסנכרון: אילו ישויות (מוצרים, מחירים, מלאי, הזמנות, לקוחות) ובאיזה כיוון מסונכרנות;
- קונפיגורציית 1С ומהדורת Bitrix — "Комплексная автоматизация", "Управление торговлей" או אחרת;
- כיצד הסנכרון מופעל כעת: לפי לוח זמנים, ידנית, דרך שירותי ווב או קבצים;
- מה כבר ניסיתם ומדוע התוצאה לא התאימה;
- היקף הנתונים: מספר משוער של מוצרים, הזמנות ביום, אתרים או נקודות מכירה;
- דרישות למהירות: כמה מהר ההזמנה והמלאי צריכים להופיע באתר;
- מי מצד 1С ומי מצד האתר יקבל את העבודה ויספק הרשאות.
לפי תיאור זה נחזור עם הערכת עבודה ותוכנית יישום: מה עושים בצד 1С, מה בצד האתר, באיזה סדר וכיצד בודקים שהנתונים תואמים. אם הסנכרון כבר מוגדר חלקית — התוכנית תתחיל באבחון, ולא בכתיבה מחדש של הכול.
תארו את המשימה — נדון בה באופן ענייני ונחזור עם הערכה ותוכנית.