החלפה מתוזמנת בין 1С ל-1С-ביטריקס: הגדרת תזמון אוטומטי

הגדרת סנכרון לפי לוח זמנים ב-1C-Bitrix: היכן זה נשבר

הגדרת סנכרון לפי לוח זמנים ב-1C-Bitrix עוברת חלק בסביבת בדיקות ומתפרקת בשבוע השני להפעלה. המשימה רשומה כפעילה, אבל בפועל פועל הפעלה ידנית של הסנכרון — «כשהמנהל יזכור». חלון שהוחמץ אף אחד לא שם לב אליו: חזית החנות מוכרת במחירים ישנים, והדבר מתגלה רק בשיחת טלפון מהקונה.

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

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

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

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

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

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

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

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

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

חזית החנות שומרת על מהירות תגובה — הסנכרון מתבצע באופן אינקרמנטלי, וייצוא מלא מחדש נשאר כלי חירום, לא процедуרה יומית.

אפשרויות הפעלה אוטומטית: השוואת גישות

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

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

הגדרת סנכרון לפי לוח זמנים ב-1C-Bitrix: סדר העבודות

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

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

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

פרופילי ייצוא, יומנים ותיעוד: מה מוסרים

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

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

מקרה בוחן: איך נעלם חוסר הסנכרון בין מחירים ליתרות מלאי בחזית החנות

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

פירקנו את הסנכרון בצד 1C-Bitrix: מחזור מלא נמשך 55 דקות ורץ במלואו, גם אם השתנו שלושה פריטים. עברנו לדלתא לפי סכומי Hash והגדרנו משימה מתוזמנת במרווח של 10 דקות, ואת הייצוא המלא השארנו לחלון לילה.

דינמיקה לפי שלושה מדדים

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

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

במה שונה משימה לפי טיימר ממתזמן חיצוני

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

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

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

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

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

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

ספקות נפוצים: תקלות, ניסיונות חוזרים וכפילויות נתונים

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

למה באתר מופיעות כפילויות של מוצרים בזמן סנכרון?

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

איך רואים מה יוצא חלקית?

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

מי אחראי לנכונות המחירים ויתרות המלאי באתר?

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

אפשר לבטל סנכרון כושל?

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

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

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

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

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