ייצוא תיאורים מ-1С אל Bitrix דורס כרטיסי מוצר
הסנכרון בין 1С ל-Bitrix בנוי כברירת מחדל כך: מערכת ה-ERP היא מקור האמת לכל השדות שנכנסו לחוקי הייצוא. כל סבב מתאים פריטים לפי קוד חיצוני וכותב לכרטיס את הערכים מ-1С, בלי להשוות אותם למה שכבר נמצא באתר. אם תיאור מסומן לייצוא, הוא יידרס בכל סנכרון — גם כשבמערכת ה-ERP לא השתנה דבר.
לכן מחיקת העריכות באתר נראית פתאומית: העורך תיקן טקסט, העלה תמונות, הגדיר כותרות SEO — ואחרי סנכרון הלילה הכול חזר לגרסה של מערכת ה-ERP. דריסת כרטיסי המוצר פוגעת לא רק בתיאור: להחלפה נכנסים גם מאפיינים המחוברים לשדות, הצעות מסחריות וגלריות, אם הם משתתפים בחוקים.
מלכודת נפרדת היא סנכרון "לפי שינויים". הוא מקטין את נפח החבילה, אבל לא מבטל את הכתיבה: שדה שתאריך השינוי שלו ב-1С התעדכן נשלח במלואו, יחד עם העריכות הידניות. ואם מתקנים את החוקים בצד מערכת ה-ERP בגלל משימה אחת, ההתנהגות משתנה בבת אחת עבור כל הכרטיסים.
נסביר איך סוגרים את זה: ייצוא התיאורים מ-1С ל-Bitrix מוגדר כך שחלק מהשדות נשארים בניהול האתר, וחלק — בניהול 1С. את הגבול אנחנו מקבעים בחוקים ומגנים עליו מפני דריסה, כדי שהסנכרון יפסיק להיות איום על התוכן.
האפקט של ההגדרה: זמני פרסום, שגיאות, עריכות ידניות
אחרי הגדרת סנכרון המוצרים הקטלוג מפסיק לחיות עם שתי אמיתות: תיאורים, מאפיינים ומלאי מגיעים ממערכת ה-ERP, ובאתר נשאר רק מה שאין בה — טקסטים שיווקיים, מבחרים, בלוקים פרומו. אפשר לבדוק שהתרשים עובד לפי כמה סימנים בעבודה היומיומית.
- זמני פרסום. פריט חדש מופיע באתר ביום שבו הכרטיס מוכן במערכת ה-ERP, ולא אחרי העברה ידנית. ייצוא תיאורים בקבוצה מסיר את התור: עשרות פריטים מתפרסמים בהרצה אחת.
- צמצום העריכות הידניות. תיאורים ומאפיינים נערכים במקום אחד. שדה ששונה באתר לא נדרס בייצוא הבא — הקונפליקט נראה בדוח ההשוואה מיד, ולא אחרי חודש.
- סנכרון הקטלוג. הסנכרון מתבצע לפי לוח זמנים ולפי פריטים שהשתנו, ולא בהעברה מלאה. פריטים בלי קטגוריה וקשרים שאבדו צפים ביומן אחרי כל הרצה.
- עדכניות הכרטיסים. הפערים במאפיינים ובמלאי שואפים לאפס: מה שהקונה רואה זהה למה שהמנהל רואה במערכת ה-ERP.
- סוג השגיאות שנעלם. תיאורים ריקים, כפילויות לפי מק"ט, יחידות מידה שונות, עיגול מחירים שגוי — את אלה תופס חוק הסנכרון, ולא העורך באופן ידני.
אחרי שבועיים-שלושה בתרשים כזה דוח ההשוואה מתקצר: הפערים בודדים, ייצואי השלמה של תיאורים נעלמים מהיומן, והעורך עוסק בתוכן ולא בתיקון שגיאות סנכרון. ב-1С זה מוגדר באמצעים המובנים של החלפת מאפיינים ותיאורים.
גישות לסנכרון: תקנון, תור, טעינה חד-פעמית
את תרשים הסנכרון בוחרים לא לפי הנוחות של המפתח, אלא לפי המידה שבה תיאור הכרטיס ב-1С נחשב למקור האמת היחיד. אם את הקטלוג והטקסטים מנהלים רק במערכת ה-ERP, והאתר משמש ויטרינה, די בסנכרון קבוע.
אם מנהל התוכן מוסיף תיאורים ומאפיינים בצד האתר, כל ייצוא אוטומטי מוחק את העבודה הזו — ואז מתכננים את התרשים אחרת.
בפועל אנחנו עובדים עם שלושה תרשיםים, ולכל אחד יש את המחיר שלו.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| סנכרון לפי לוח זמנים | הקטלוג, המחירים והמלאי משתנים רק ב-1С; אין עריכות ידניות באתר | עריכות בצד האתר נדרסות בהרצה הבאה; כל הרצה מושכת את כל הנפח |
| סנכרון לפי אירוע (תור שינויים) | חשובה טריות הנתונים: המוצר מופיע באתר ברגע העריכה במערכת ה-ERP | דרושים יומן שינויים וטיפול בקונפליקטים בין שדות; אחרי תקלה נדרש מעבר חוזר על התור |
| טעינה חד-פעמית של נתונים | העברת קטלוג בהשקת אתר, הגירה, ייבוא מחירון | אינה שומרת על עדכניות — פערים מצטברים מיד אחרי הטעינה |
את השוואת תרשימי הסנכרון כדאי להתחיל מהשאלה מי הבעלים של התיאור. סנכרון לפי תקנון פשוט יותר לתחזוקה וצפוי יותר בעומס, תור השינויים מדויק יותר בזמן, וטעינה חד-פעמית סוגרת את ההעברה ומסתיימת שם. בקטלוג חי נהוג לשלב בין הגישות: תור לתיאורים, לוח זמנים למלאי.
סדר היישום: מביקורת הסנכרון ועד מסירת התקנון
סנכרון התיאורים נשבר לא בקוד, אלא בחוקים שלא נבדקו: שינו את שם המאפיין ב-1С, הוסיפו תיאור שני לכרטיס — והייצוא הבא דורס טקסט שהעורך בנה ביד. לכן את יישום הסנכרון אנחנו בונים שלב אחר שלב, וכל שלב בודקים על עותק של הקטלוג, ולא על האתר החי.
שלבי העבודה
- ביקורת חוקי הסנכרון. בודקים אילו מאפיינים משתתפים בייצוא, מי משנה אותם, באיזה סדר פועלים המטפלים ואיפה בדיוק הולכת לאיבוד העריכה הידנית.
- תכנון התרשים. בונים מפת התאמה בין השדות של 1С ל-Bitrix ומקבעים את עדיפות המקור: מה הסנכרון מעדכן ומה נשאר בידי העורך.
- סביבת בדיקה לקטלוג. פורשים עותק של המדור עם פריטים אמיתיים ומפעילים תיעוד של הסנכרון — הפערים נראים עוד לפני ההרצה בפרודקשן.
- בדיקה על פריטים אמיתיים. מריצים כמה ייצואים מלאים, משווים את התיאורים לפני ואחרי, ובוחנים בנפרד מוצרים עם עריכות ידניות ועם שדות ריקים.
- הגדרת הגנה מפני דריסה. קובעים עדיפויות לשדות, חוסמים ערכי מערכת ומוסיפים חוקים שבהם טקסט ידני לא נדרס.
- מסירת התקנון. מוסרים מסמך עם חוקי הסנכרון, התפקידים וסדר הפעולות בעת הוספת מאפיין חדש.
- ליווי הייצואים הראשונים. בודקים את היומנים עד שהסנכרון ישלים מחזור מלא בלי פערים.
אחרי זה שינויים בתיאורים מפסיקים להיות סיכון: מאפיין חדש עובר קודם את סביבת הבדיקה ורק אחר כך נכנס לסנכרון בפרודקשן.
הגדרות, חוקי התאמת שדות ותקנוני סנכרון
הסנכרון עובד בדיוק כל עוד החוקים שלו מתועדים במסמכי הפרויקט, ולא בהתכתבות עם הקבלן הקודם. להלן הסט המינימלי שאנחנו מוסרים ללקוח, כדי שעריכות בקטלוג לא ישברו את הייצוא וכדי שעובד חדש יוכל לשחזר את התצורה בלעדינו.
- תקנון סנכרון: מה ומתי מופעל — ייצוא מלא לפי לוח זמנים, טעינת השלמה של פריטים שהשתנו לפי אירוע, הפעלה ידנית אחרי עריכות גורפות בקטלוג.
- מפת התאמת שדות: טבלה «שדה ב-1С — מאפיין ב-Bitrix — סוג — חובה», כולל הצעות מסחריות, מאפיינים ומאפיינים נוספים.
- עדיפויות מקור: חוק מפורש מי הבעלים של השדה — מערכת ה-ERP, הכרטיס באתר או המנהל באופן ידני, ואיך נפתר קונפליקט ערכים בעת פער.
- חוקי התאמת שדות: לפי איזה מפתח מחפשים מוצר קיים ואיך מתאימים מדורים, כדי שמעבר חוזר יעדכן את התיאור ולא ייצור כפילויות.
- הגדרות הגנה מפני דריסה: רשימת השדות הסגורים לסנכרון ורשימת המקומות שבהם עריכה בצד האתר נשמרת בייצוא הבא.
- הנחיות לעובדים: מה מותר לשנות באתר, מה נערך רק במערכת ה-ERP, ולאן להסתכל כשיש פער בתיאורים.
- תיעוד הסנכרון: תרשים הזרימות, נקודות התיעוד ביומן, סדר החזרת הקטלוג למצב הקודם והרצת בקרה על עותק בדיקה אחרי עדכונים.
הסט הזה מספיק כדי להעביר את התמיכה לצוות אחר בלי לאבד את ההיגיון של הייצוא.
מקרה בוחן: איך הסנכרון הפסיק לשבור כרטיסי מוצר
מה היה לפני
קטלוג עם כמה עשרות אלפי פריטים הסתנכרן עם מערכת ה-ERP לפי לוח זמנים. כל סנכרון משך אחריו את כל סט השדות של הכרטיס, כולל התיאור המסחרי: המלאי השתנה — גם הטקסט נדרס. עורך התוכן תיקן מחדש כמאה תיאורים בשבוע, והסנכרון הבא מחק אותם שוב.
מה מצאנו ומה שינינו
צוואר הבקבוק התברר לא בסנכרון עצמו, אלא בהיעדר חלוקה של השדות לפי בעלים. בהגדרת ייצוא התיאורים מ-1С לקטלוג קיבענו את עדיפות המקור: הטקסט מתעדכן רק כששדות באמת משתנים, ועריכה בכרטיס מסומנת כעריכה של המחבר ומוגנת מפני דריסה. את הסנכרון המלא החלפנו בסנכרון לפי פריטים שהשתנו עם יומן פעולות — עכשיו רואים מה ומתי דרס שדה.
- שיעור הכרטיסים עם תיאור שנדרס: מ-18% לאפס;
- עריכות ידניות חוזרות: מ-120 ל-0 בשבוע;
- זמן הסנכרון המלא: התקצר בערך פי שלושה;
- כרטיסים המוכנים לפרסום מיד אחרי הסנכרון: 97%.
את שחזור התיאורים צמצמנו למעבר חד-פעמי על היומן: העלינו את הטקסטים מגיבויים וסימנו אותם מחדש כשל המחבר. מעתה אובדן תוכן מזוהה בדקות הראשונות, ולא אחרי שבוע. הקטלוג הפסיק להיות תלוי בלוח הזמנים של הייצוא — העורך מתקן את הכרטיס בכל רגע ויודע שהסנכרון לא ייגע בו.
מה לעשות אם הייצוא כבר דורס כרטיסים
קודם כול לעצור את הזרימה, ולא לנסות להבין תוך כדי. כל עוד הסנכרון רץ לפי לוח זמנים, כל עריכה שורדת עד ההפעלה הבאה של המשימה, לכן מעבירים את הסנכרון להפעלה ידנית או מסירים את המשימה לגמרי, מצלמים תמונת מצב מלאה של המסד והקטלוג, ואז מתעדים את רשימת הכרטיסים ששונו ביד במחזור האחרון. זה נותן נקודת אחיזה: ברור מה כבר אבד ומה עוד אפשר להציל לפני הדריסה הבאה.
הלאה — עדיפות מקור הנתונים. ממיינים את מאפייני הכרטיס לפי הסימן «מי הבעלים של הערך»: מחיר, מלאי, מק"ט, קישורי מחסן נשארים ב-1С; תיאור, מאפיינים, טקסטים, תמונות — אצל מנהל התוכן; חלק מהשדות מעורבים, אותם מספקת מערכת ה-ERP אבל האדם משלים אותם. בלי רשימה כזו כל הגנה על עריכות מפני דריסה הופכת לאוסף טלאים שנשברים בשינוי הבא של המאגר.
ההגנה עצמה נבנית על סימון של שינוי ידני: בכרטיס נשמרים סימן ותאריך עריכה לכל שדה, והסנכרון מדלג על מאפיינים שהסימון שלהם חדש יותר מהייצוא האחרון.
אפשרות צפויה יותר היא להפריד את הערכים למאפיינים שונים: «תיאור מ-1С» ו«תיאור הוויטרינה», כשהוויטרינה מציגה את השני אם הוא מלא, ואת הראשון — כגיבוי. אז הסנכרון לא נוגע בתוכן בכלל, והפער נראה בעין.
השחזור נעשה מגיבוי: משווים כרטיסים, מחזירים טקסט שאבד, ומסמנים מחדש שדות כשונו ביד. חוק העדיפות וההגנה מפני דריסה מוגדרים לפני ההפעלה הבאה של הסנכרון — אחרת המחזור יחזור על עצמו והעבודה תרד לטמיון.
ספקות לגבי הסנכרון: הרשאות, קונפליקטים בין שדות, נפח הנתונים
ההרשאות מוגדרות לפני הסנכרון הראשון: הייצוא רץ תחת חשבון שירות נפרד שיש לו קריאה של הקטלוג וכתיבה רק למאפיינים שהסנכרון מנהל. תיאורים ומדורים שהעורך עורך ביד לא נכנסים לרשימה הזו — הסנכרון לא דורס אותם ולא שובר את הפריסה. כל שינוי נשאר ביומן: רואים מה הגיע ממערכת ה-ERP ומה הוסף באתר.
את הנפח סוגרים בסנכרון חלקי. אין טעם להעביר קטלוג של עשרות אלפי פריטים במלואו: הטעינה הראשונה מלאה, ובהמשך מועברים רק רשומות שהשתנו וקבוצות המאפיינים הנדרשות. אפשר להגביל את הסנכרון למדור, למחסן או למותג, ולקבוע אותו לשעות הלילה כדי שלא יחפוף לשיא התנועה.
מה יקרה אם התיאור ב-1С ובאתר שונים?
לכל מאפיין ממונה מראש בעלים. אם המקור הוא 1С, הערך שלה דורס את האתר; אם הבעלים הוא האתר, עריכת העורך נשארת והסנכרון רק קורא אותה. מאפיינים בלי בעלים לא נגעים בכלל.
אפשר לייצא רק חלק מהקטלוג?
כן, הסנכרון מוגדר לפי מסננים: מדור, מחסן, ספק, רשימת מאפיינים. שאר הפריטים נשארים בלי שינוי, ולוח הזמנים קובע את התדירות ואת חלון ההפעלה.
איך מחזירים ייצוא כושל?
לפני הסנכרון מצלמים תמונת מצב של הכרטיסים והמאפיינים. אם החוקים נתנו תוצאה שגויה, מחזירים את המצב הקודם ומתקנים את ההגדרות — בלי שחזור ידני של התיאורים.
נדון בתרשים הסנכרון שלכם ונחזור עם הערכה
הערכה מדויקת של עבודת הסנכרון מגיעה לא מתיאור כללי, אלא מהתצורה שלכם: אילו שדות יוצרים את התיאור, מי ומתי עורך את הטקסט בצד האתר ומה בדיוק נדרס בייצוא הבא. כדי לדון במשימת הסנכרון באופן ענייני, שלחו את מה שכבר יש בהישג יד — את השאר המהנדסים שלנו יבדקו בעצמם.
- מבנה מאפייני התיאור ב-1С ובאתר: אילו שדות נחשבים למקור אמת ואילו לנגזרים;
- שתיים-שלוש דוגמאות של מוצר: איך התיאור נראה במערכת ה-ERP עכשיו ואיך הוא צריך להישאר אחרי הסנכרון;
- תקנון העריכות: מי עורך את הטקסט דרך פאנל הניהול, באיזה היקף ובאיזו תדירות;
- לוח הזמנים של הסנכרון והנפח המשוער של פריטים שעוברים בסבב אחד;
- יומן הסנכרון מהתקופות האחרונות, אם הוא נשמר — לפיו רואים דריסות שנויות במחלוקת;
- גישות לסביבת בדיקה או לעותק של הקטלוג: עליהם אפשר לשחזר את התרחיש בבטחה ולבדוק את ההתנהגות בלי סיכון לאתר הפעיל.
אחר כך אנחנו מנתחים את צומת הסנכרון: בודקים את המטפלים, את סדר כתיבת המאפיינים ואת הרגע שבו הערך נדרס. בסיום תקבלו תרשים סנכרון עם נקודות הגנה, רשימת תיקונים ותוכנית עבודה בשלבים — עם אומדן שעות העבודה, סדר הפריסה ודרך החזרה להתנהגות הקודמת. אפשר להזמין הגדרת סנכרון גם בלי גישה מלאה: נתחיל מניתוח התרשים, ונחזור עם הערכה ותוכנית.