הגדרת ייצוא פריטים מ-1C:UT ל-ביטריקס: ללא אובדן נתונים

למה ייצוא הפריטים מ-1С УТ ל-Bitrix נשבר

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

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

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

מאפיינים וערכים ב-1С הם ספריית נתונים נפרדת עם היררכיה משלה, ובלי התאמה מפורשת למאפייני האינפובלוק היא או לא מיוצאת כלל, או שכל סנכרון דורס את מה שהמנהלים תיקנו באתר ידנית.

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

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

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

מה משתנה אחרי חילופים מסודרים: האפקט במספרים

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

עדכון הקטלוג — דקות במקום שעות

מחזור ייצוא מלא של הפריטים מ-1С:Управление торговлей מתבצע בדקות, ותיקון מחיר בודד מגיע לחלון הראווה כמעט באופן מיידי. החילופים מתבצעים במנות לפי פריטים שהשתנו, ולכן גידול הקטלוג לא מאריך את המחזור באופן ליניארי.

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

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

תיקונים ידניים — יוצא מן הכלל, לא הנורמה

תשעה מעשרה פריטים עוברים את החילופים בלי מעורבות עורך: מאפיינים, מחירים, יחידות מידה ותמונות נמשכים לפי כללי ההתאמה. מאמץ צוות העריכה מצטמצם פי כמה.

הכרטיסים מלאים לגמרי

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

נעלם סוג שלם של תקלות

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

דרכי חילוף הקטלוג: מודול מובנה, קבצים, אוטובוס שירותים

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

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

שלבי הגדרת החילופים: מהביקורת ועד ההעברה לתמיכה

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

1. ביקורת ספריות הנתונים — מייצאים חתך: כמה קבוצות פעילות יש, האם קיימות כפילויות וצמתים ריקים, אילו תכונות ויחידות מידה באמת בשימוש, ואיזה שיעור מהפריטים הופק מייצור או חסר מחיר.
2. תכנון הסכימה — קובעים מה הופך למדורים בקטלוג, מה להצעות מסחריות ומה למאפיינים; בנפרד מתארים את הכלל לפריטים שעדיין אין בקטלוג.
3. התאמת השדות — טבלה של «שדה המקור → שדה היעד» עם טיפוסים, חובה וערכי ברירת מחדל לתאים ריקים.
4. הגדרת כללי החילוף — צמתים וכיוונים, מסננים לפי קבוצות, לוח זמנים, התנהגות בעת עדכון והסרה מפרסום, סדר העברת התמונות והמלאי.
5. הרצת בדיקה של החילופים — הפעלה על עותק של הקטלוג: משווים את מספר הפריטים והמחירים לפי קבוצות בקרה, בודקים הרצה חוזרת — היא לא אמורה ליצור כפילויות ולאבד קישורים.
6. העברת החילופים לתמיכה — תקנון הפעלה, יומן שגיאות, נקודות בקרה אחרי כל ייצוא ונוהל פעולה בסטיות, הרשאות אצל האחראים.

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

מה נשאר אצלכם: סכימות חילוף, כללי התאמה, תקנונים

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

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

מקרה בוחן: קטלוג של 40 000 פריטים — חילופים בלי תיקונים ידניים

אצל מפיץ ציוד, קטלוג של 40 000 פריטים התעדכן ידנית: המנהל הפעיל ייצוא מלא של הפריטים מ-1С УТ פעם ביום ואחרי כל הפעלה עבר על יומן השגיאות. שלמות הייצוא נשמרה ברמה של 85–88% — פריטים בלי יחידת מידה מלאה או עם מק"ט כפול פשוט לא הגיעו לאתר, והפערים צפו בשיחות עם לקוחות. שינוי מחיר או תכונה המתין להפעלה התקנונית הבאה.

מה שינו

1С:Управление торговлей נשארה מערכת החשבונאות, האתר — חלון הראווה; ביניהם הוצב חילוף אוטומטי של פריטים לפי אירועי שינוי במסמכים, ולא לפי לוח זמנים. הפריטים מותאמים לפי קוד חיצוני ממערכת החשבונאות, ולכן שינוי שם או החלפת מק"ט לא יוצר כפילות ולא קוטע את הקישור.

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

מדדים לפני ואחרי

שלמות הייצוא עלתה מ-85–88% ל-99,9%, שיעור הפערים בין האתר לחשבונאות ירד מ-6–7% ל-0,1% — פריטים שנויים במחלוקת נראים כעת בדוח, ולא בהתכתבות עם הלקוח. זמן התגובה לשינוי במערכת החשבונאות הצטמצם מיממה ל-2–5 דקות. תיקונים ידניים בקטלוג אחרי ההטמעה — אפס.

במה שונה חילוף ישיר מחילוף דרך בסיס ביניים?

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

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

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

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

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

ספקות טכניים נפוצים לפני הפעלת חילוף הקטלוג

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

אפשר לעדכן לא את כל הקטלוג, אלא רק את השינויים?

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

כיצד נמחקים פריטים שהופקו מהחשבונאות?

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

הקטלוג כבר אוכלס ידנית — האם הנתונים לא יימחקו?

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

נדון במשימת חילוף הקטלוג ונחזור עם תוכנית

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

מה נכלל בתוכנית להגדרת חילופים עד הסוף:

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

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