הגדרת סנכרון בין 1C:UNF ל-Bitrix: היכן הנתונים מתפצלים
הגדרת סנכרון בין 1C:UNF ל-Bitrix כמעט תמיד עוברת בדיקה על עשרה מוצרי בדיקה — ומתפצלת בזרימת ההזמנות האמיתית. הבעיה אינה בערוץ ההעברה: הקטלוג, המלאי והמחירים נשלחים לפי לוח זמנים, והשינויים בשתי המערכות מתרחשים במקביל.
הפער הראשון — התאמת ספרי עזר. אם הקשר נשען על שם או מק״ט, כל בנייה מחדש של פריט ב-UNF מאבדת את המזהה, ולקטלוג נשלח מוצר שני. כך מופיעות כפילויות פריטים: שני "שולחנות אלון", לאחד יש מלאי זמין, ולשני מחירים ישנים, והמנהל לא יודע את מי לערוך.
הבא — אי-התאמה במלאי ובמחירים. המנהל משנה מחיר בכרטיס באתר, המחסנאי מוריד אצווה מהמלאי ב-UNF, ושתי ההעברות מתחילות לפי לוח זמנים. זו שנכתבה אחרונה מנצחת, והמצב הביניים אינו נשמר — אין דרך להחזיר אותו: ביומן רואים את התוצאה הסופית, אבל לא איזו רשומה דרסה רשומה אחרת.
היקרים ביותר הם שגיאות בייצוא הזמנות. הזמנה נוצרה עבור מוצר שעדיין לא עבר ב-UNF: השורה לא מותאמת, ההזמנה נוצרת ריקה או נכנסת לרשימת שגיאות. ייצוא חוזר של פריטים ללא הגנה מפני כפילויות מכפיל שורות ומוריד מהמלאי פעמיים. נסביר כיצד זה נסגר באמצעות מפתחות התאמה וכללי כתיבה.
מה נותן סנכרון מנוהל: דיוק ומהירות
ההבדל בין "ייצוא לפי לוח זמנים" לסנכרון מנוהל מתגלה ברמת הנתונים. החילופים מתבצעים לא באמצעות תמונת מצב מלאה של הקטלוג, אלא לפי דלתא: ב-1C:UNF עוקבים אחרי שינויים בפריטים, במחירים ובתנועות מלאי, ואל האתר נשלח רק מה שבאמת השתנה.
הפריטים מותאמים לפי מזהה פנימי, ולא לפי שם, ולכן שינוי שם של כרטיס אינו הופך לכפילות, והמלאי המעודכן באתר תואם לנתוני המערכת.
הזמנה מהאתר יוצרת במערכת החשבונאית מסמך מלא: הרכב, מחירים, מחסן, סטטוס, שריון. שליחה חוזרת של אותה הזמנה אינה יוצרת מסמך שני — הרשומה מקושרת למפתח ההזמנה, וזה מסיר סוג שלם של אי-התאמות בעת ניתוק הקשר.
שיעור הפעולות הדורשות תיקון ידני נמדד לפי יומן החילופים: ידנית מטופלים רק מקרים לא שגרתיים — מוצר בהזמנה מיוחדת, תנאי משלוח מיוחדים.
זמן הטיפול בהזמנה מתקצר לא בגלל "מדפיסים מסמכים מהר יותר", אלא מפני שבין ביצוע ההזמנה לחשבונאות נעלם המעבר הידני. המנהל מקבל הזמנה עם שריון מוכן ומחיר שנקבע במועד ביצוע ההזמנה — בקרת המחירים מפסיקה להיות תלויה בשאלה אם מישהו הספיק לעדכן את המחירון.
בנפרד נעלמת הסירוב מסוג "מכרנו משהו שאין במלאי": המלאי נכנס לשריון בעת ביצוע ההזמנה, ופריטים חסרים נחסמים בצד האתר לפני אישור התשלום. אנו מגדירים תרחישי חילופים, הפרדת הרשאות ותיעוד ביומן — כדי שהשפעות אלו יישענו לא על משמעת ידנית, אלא על נוהל.
דרכי סנכרון: לוח זמנים, אירוע, שכבת ביניים
פורמט הנתונים הוא משני — על היציבות וההשהיה משפיע בראש ובראשונה אופן ההעברה.
ייצוא מתוזמן פועל לפי לוח זמנים ולוקח רק את מה שהשתנה מאז הסנכרון המוצלח האחרון; העברה בעת שינוי רשומה שולחת את האובייקט מיד לאחר רישום המסמך; שכבת ביניים מפרידה בין המערכות ולוקחת על עצמה תור וניסיונות חוזרים.
אנו בוחרים סכימה לפי שלושה פרמטרים: נפח ספרי העזר והמסמכים, השיהוי המותר של הקטלוג באתר ועלות ההשבתה כאשר אחד הצדדים אינו זמין.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ייצוא לפי לוח זמנים | ספרי עזר גדולים, דוחות, היסטוריית הזמנות; השיהוי של עשרות דקות אינו קריטי | עומס שיא על מסד הנתונים ברגע ההרצה; כאשר אחד הצמתים נופל, הייצוא נדחה למחזור הבא |
| העברה בעת שינוי רשומה | מלאי, סטטוסי הזמנות, מחירים — נתונים שמצפים להם באתר מיד | תלות בזמינות הצד המקבל: בלי תור, כשל בחילופים מאבד אירוע; יש לכבות כפילויות בשליחה חוזרת לפי מפתח |
| שכבת ביניים | פרופיל משולב: מערכות שונות, נפחים ודרישות השהיה; ערוץ לא יציב | צומת נוסף לתחזוקה ולניטור; פורמט ההודעות מקובע ומנוהל בגרסאות |
בפועל, לרוב עובד שילוב: ספרי עזר נמשכים באופן מתוזמן, מסמכים יוצאים לפי אירוע, ושכבת ביניים מופעלת כאשר החילופים גדלים מעבר לחיבור ישיר. היא גם נותנת את הדבר העיקרי ליציבות בעת תקלה — צבירת הודעות ומסירה חוזרת בלי השלמה ידנית של הייצוא. נדון בפרופיל הנתונים שלכם — נחזור עם הערכה ותוכנית.
סדר העבודות: מניתוח הנתונים ועד מסירת נהלים
מתחילים במיפוי: רושמים את ספרי העזר והמסמכים שבאמת משתתפים בחילופים — פריטים, צדדים, מחסנים, מחירים, מלאי — ומתעדים נפח, תדירות שינויים והבעלים של כל ישות. בלי המפה הזו, מחצית מאי-ההתאמות נוצרות לא בערוץ, אלא מכך שאותו מוצר נרשם בשתי מערכות עם מאפיינים שונים.
- מיפוי ספרי העזר והזרימות. מגדירים מה מסונכרן, לאיזה כיוון ובאיזו תדירות, ומי הבעלים של רשומת המקור.
- כללי התאמת שדות. מתאימים מאפיינים, מסמנים שדות חובה, מגדירים התנהגות בעת אי-התאמה: לעדכן, לדלג או להעביר לתור טיפול ידני. את הכללים מחזיקים כטבלה — כך אפשר לערוך אותם בלי מפתח.
- הגדרת ערוץ החילופים. חשבונות עם הרשאות מינימליות, לוח זמנים, גודל מנה, ניסיון חוזר בעת ניתוק קשר. בודקים הרשאות משני הצדדים, לא רק במקום שבו מגדירים.
- הרצה בסביבת בדיקה. העתקת נתונים, מחזור מלא, השוואת סכומי ביקורת, ניתוק קשר מלאכותי — בודקים כיצד התור מתנהג והאם החילופים משתקמים מעצמם.
- הפעלה ויומן העברת נתונים. מפעילים משימה מתוזמנת ועוקבים אחרי היומן: כמה רשומות עברו, כמה נדחו, היכן גדל השיהוי. מגדירים התראות גם על שגיאות וגם על שתיקה של החילופים.
- מסירת נהלים ותוכנית מעבר. הוראות לתקלות טיפוסיות, סדר נסיגה לאחור, תוכנית מעבר לסכימה חדשה והדרכת עובדים.
ערכת המסירה: כללי התאמה, סכימות ונהלים
פרויקט הגדרת החילופים מסתיים לא בדוח "הכול עובד", אלא בסט ארטיפקטים שלפיהם אפשר לבדוק את העבודה ולהמשיך להפעיל אותה באופן עצמאי. להלן מה בדיוק נשאר אצל הלקוח בתיקיית הפרויקט לאחר המסירה.
- סכימת אינטגרציה: אילו זרימות נתונים עוברות ממערכת החשבונאות לאתר, אילו חוזרות בחזרה, באיזו תדירות וכיצד החילופים מתנהגים כאשר אחד הצדדים אינו זמין.
- טבלת התאמת מאפיינים: התאמה של פריטים, צדדים, מחירים, מחסנים ויחידות מידה — עם סימון אילו שדות הם חובה, אילו מתמלאים אוטומטית ואילו דורשים החלטה ידנית.
- מדיניות הרשאות: אילו תפקידים רואים מחירים, מלאי והזמנות, מה זמין למנהל ומה רק למנהל סביבת העבודה.
- יומן טיפול בקונפליקטים: אי-התאמות טיפוסיות — כפילויות פריטים, יחידות מידה שונות, הזמנות כפולות — וסדר הפעולות לכל מקרה.
- הוראות לעובדים: תרחישים קצרים של "מה לעשות אם", היכן לראות את סטטוס החילופים וכיצד להפעיל ייצוא חוזר בלי לקרוא למהנדס.
- נוהל תחזוקה: תדירות הבדיקות, בקרת נפח היומנים, עדכון ספרי התאמה ונקודות שבהן נדרשת התערבות מומחה.
- מטריצת אחריות: מי מצד הלקוח מאשר שינויים בכללי ההתאמה ומתאם שדות חדשים.
הסט חי יחד עם המערכת: כאשר מוסיפים קבוצת מוצרים או משנים את מבנה המחירים, מבוצע בו תיקון, ולא נבנה חילוף חדש מאפס. זה מה שמבדיל אינטגרציה מתוחזקת מייצוא חד-פעמי.
מקרה בוחן: כיצד הסרנו אי-התאמות במלאי בין המחסן לאתר
לקוח — חברת סיטונאות וקמעונאות: החשבונאות ב-1C:UNF, חלון הראווה והאזור האישי ב-Bitrix24. החילופים התנהלו לפי לוח זמנים, הפריטים הותאמו לפי שם, והמלאי הוצא במלואו — עד אמצע היום הצטברו עד 60 אי-התאמות, והמנהלים השוו בין המחסן לאתר ידנית.
מה היה לפני ההגדרה מחדש
הכשל לא התגלה מיד: האתר הציג מוצר כזמין כאשר במחסן הוא כבר אזל. הקונה ביצע הזמנה, המנהל התקשר וביטל — עד 14 ביטולים בחודש, וכ-18% מההזמנות דרשו תיקון ידני.
| מדד | לפני ההגדרה מחדש | אחרי |
|---|---|---|
| זמן העברת נתונים | 35–40 דקות, במנות פעם בשעה | 1–3 דקות, לפי אירוע |
| שיעור התיקונים הידניים בהזמנות | כ-18% | פחות מ-2% |
| ביטולים בגלל חוסר במוצר | עד 14 בחודש | 1–2 בחודש |
מה שינינו
התאמת הפריטים הועברה משם לצירוף "מק״ט + קוד", המלאי החל לצאת לפי אירוע, ולא במנה פעם בשעה. בייצוא נוספו ניסיון חוזר בעת ניתוק קשר בלי ליצור כפילויות ויומן חילופים: רואים איזה פריט ומתי נפרד. שריון המוצר מוגדר כעת לפני אישור ההזמנה באתר.
לאחר ההגדרה מחדש, אי-התאמות המלאי הפסיקו להיות סיפור יומיומי — אירועים מנותחים לפי היומן, ולא באמצעות ספירת מלאי חוזרת. זה בדיוק מקרה הבוחן של סנכרון, שבו הרווח מגיע לא מתדירות החילופים, אלא מסדר בכללי ההתאמה והשריון.
מתי לוח זמנים מספיק, ומתי נדרשת שכבת ביניים
הוויכוח "לוח זמנים או שכבת ביניים" נפתר באמצעות שלושה פרמטרים מדידים: נפח הפריטים, תדירות השינויים במלאי ומספר נקודות המכירה.
כל עוד הקטלוג נמדד במאות פריטים, המלאי משתנה כמה פעמים ביום, וערוץ המכירה הוא אחד — לוח זמנים מספיק, והוא פשוט יותר לתחזוקה: פחות צמתים שיכולים ליפול.
התמונה משתנה כאשר שינויים מגיעים כל כמה דקות ממספר קופות ומחסנים, ובקטלוג יש עשרות אלפי פריטים. חילופים לפי לוח זמנים מתחילים להפריע לעצמם: הרצה חדשה מתחילה לפני שהקודמת הסתיימה, רשומות דורסות זו את זו, וחלק מהשינויים הולכים לאיבוד בין המעברים.
העומס על שתי המערכות גדל באופן ליניארי עם התדירות, ובשעות שיא הייצוא מתחיל לגזול משאבים מביצוע ההזמנות.
שכבת ביניים — מסד נתונים נפרד או תור — מפרידה בין המעגלים: 1C:UNF כותב לשם רק שינויים, והאתר מושך אותם במנות ובקצב שלו. כל צד עובד במהירות שבה הוא מתוכנן, כשל במעגל אחד אינו חוסם את השני, ומסירה חוזרת של חבילה אינה יוצרת כפילויות. בד בבד מופיע יומן: רואים מה בדיוק יצא, מה התקבל והיכן התפצל.
הסימן המעשי פשוט. אם חילופים אינקרמנטליים נכנסים למרווח לוח הזמנים, התור אינו גדל, ואין אי-התאמות בין הקטלוג למערכת החשבונאית — שכבת ביניים אינה נחוצה, היא תוסיף נקודת כשל.
אם מופיע תור גדל, כפילויות פריטים ותלונות על מלאי לא מעודכן — זה סימן שתדירות השינויים כבר עברה את לוח הזמנים.
מה מבררים לפני ההתחלה: מגבלות ותקלות טיפוסיות
בשלב ההתחלה מתעדים את התנהגות המערכת בתקלות: ניתוק קשר, ייצוא חלקי, קונפליקט בשינויים — אלו אינם חריגים, אלא תרחישים שגרתיים. להלן ספקות טכניים שעולים לרוב אצל הלקוח, והתשובות שלנו לכל אחד.
מה קורה לחילופים בעת ניתוק קשר?
החילופים מתבצעים במנות, וכל מנה מאושרת רק לאחר כתיבה בצד המקבל. אם הקשר נותק באמצע, המסמכים שהועברו אינם משוכפלים, והמסמכים שלא הועברו נשארים בתור ויוצאים בסשן הבא. הפעלה חוזרת ממשיכה מהמקום שבו נותק הקשר, ולא מתחילת התקופה.
כיצד מזהים סנכרון חלקי ומה עם העומס?
כל סשן כותב יומן: כמה אובייקטים יצאו, כמה התקבלו, היכן אי-ההתאמה. החילופים מתבצעים רק עבור אובייקטים שהשתנו, ולכן העומס על מסד הנתונים אינו גדל יחד עם נפח ספרי העזר, והשוואה לפי פריטים מרכזיים מוציאה את אי-ההתאמה לדוח, ולא לתלונה של מנהל.
מי מנצח בקונפליקט בין רשומות?
כלל פתרון הקונפליקטים מוגדר לפי ישויות: הזמנות ותשלומים נשארים ב-1C כמקור האמת, תיאורים ותוכן — באתר. מסמך שנוי במחלוקת נכנס להסגר ואינו דורס נתונים בשקט, אלא מוצג לבדיקה משני הצדדים.
מה עם הרשאות גישה ושחזור לאחר מסירה?
את תת-המערכת מוסרים עם תיאור תפקידים וחשבונות שירות: מי רואה את הייצוא, מי יכול להפעיל מחדש סשן. השחזור לאחר תקלה מפורט צעד אחר צעד — המהנדס שלכם מרים את החילופים לפי ההוראות, בלי התמיכה שלנו.
נדון במשימת הסנכרון ונחזור עם תוכנית עבודה
כדי שהחילופים יתנהלו בלי אי-התאמות, אנחנו צריכים להבין את התצורה שלכם: אילו ספרי עזר מנוהלים ב-1C:UNF, אילו בצד האתר, מי עורך אותם ובאיזו תדירות. תארו את המשימה — נחזור עם הערכה, סכימת התאמת שדות ותוכנית עבודה שבה לכל שלב יש קריטריון מוכנות.
מה יידרש מצדכם להתחלה:
- גישות למעגלים: מסד בדיקה ומסד עבודה של 1C:UNF, ממשק הניהול של האתר, שרת החילופים. איננו עורכים נתוני אמת עד לאישור הסכימה.
- רשימת אובייקטים לחילופים: פריטים, מחירים, מלאי, הזמנות, צדדים — עם כיוון ותדירות לכל אחד.
- אחראי על ספרי העזר: אדם שמטפל בשאלות של כפילויות, קבוצות, יחידות מידה ומק״טים.
- כללי מקור האמת: היכן נמצא אמת המידה למחיר ולמלאי וכיצד מטופלים תיקונים ידניים באתר.
- סדרי עדיפויות בנתונים: מה קריטי קודם, ומה עובר לשלב השני.
- מגבלות: חלון שבו החילופים אינם אמורים להפריע לעבודת המחסן והמפעילים.
לאחר מכן — הרצה בסביבת בדיקה, השוואת סכומי ביקורת, ואז העלאה לפרודקשן. את לוחות הזמנים של ההטמעה נמסור לאחר הניתוח: הם תלויים במספר האובייקטים ובניקיון ספרי העזר, ולא בנפח התיאור.