מדוע ייצוא המאפיינים מ-1С УТ יוצר כפילויות SKU
ב-1С:УТ פריט מוגדר על ידי צמד "פריט + מאפיין", ואילו ב-1C-Bitrix כל שילוב של תכונות הוא הצעת מכר נפרדת עם סט ערכים משלו. סנכרון הקטלוג מקשר ביניהם לפי מזהה, ולכן הכול תלוי עד כמה המפתח המורכב מלא והאם הוא קבוע במערכת הנה"ח.
טעות נפוצה בסנכרון הקטלוג — המפתח נשאר רק קוד הפריט. נוסף מאפיין חדש — השרת אינו מוצא את הצעת המכר הקיימת לפי הסימן המורכב ויוצר הצעה נוספת: הפריט משוכפל בסנכרון, וה-SKU הקודם נשאר בלי מחיר ומלאי. בקטלוג זה נראה כמו כרטיס שאי אפשר לקנות.
השכבה השנייה — תכונות. אם בכלל הסנכרון לא מופעלת העברת תכונות ההצעות עם קישור למאגר, הערכים מגיעים ריקים או כטקסט חופשי. ההתאמה מתבצעת אז לפי המחרוזת, ו«black» מול «Black» מתפצלים לשני SKU.
מספור מחדש של מאפיינים בעת הרצה מחדש של מסמכים מוסיף משלו: המזהה משתנה, והייצוא הבא של מאפיינים מ-1С УТ שוב לא מזהה את מה שכבר נטען.
התוצאה — אי-התאמה בנתונים: המלאי נמצא בפריט אחד, המחיר באחר, וכפילויות ה-SKU בקטלוג גדלות מהר יותר משמצליחים לנקות אותן ידנית. בהמשך נפרט כיצד זה נסגר ברמת כללי הסנכרון, מפתחות ההתאמה ומילוי התכונות.
מה נותן סנכרון תקין: תוצאות מדידות
כרטיס מוצר אחד במקום אוסף כפילויות — האפקט הבסיסי שממנו נגזרים השאר. מאפיינים (צבע, מידה, חומר, אריזה) מגיעים ממערכת הנה"ח כתכונות של הצעת מכר ומצטברים לכרטיס אחד עם וריאנטים, ולא לפריטים נפרדים בקטלוג. החיפוש והמסננים מפסיקים להציג מוצר אחד בחמש שורות, והמנהל — לאחד אותן ידנית.
מהירות פרסום השינויים נמדדת לא במספר הלחיצות, אלא בזמן מעדכון במערכת הנה"ח ועד להופעה בחזית החנות. כשהסנכרון מוגדר, מחיר חדש, תיאור או הסרה מהמכירה עוברים במעבר אחד; בהעברה ידנית, אותו עדכון ממתין לייצוא הבא או הולך לאיבוד בין הטבלאות.
צמצום העריכות הידניות בקטלוג — תוצאה של אותו סדר. ההתאמה מתבצעת לפי קוד וכללים, ולא לפי שם, ולכן היקף הפעולות הידניות יורד לכדי טיפול בחריגים: קבוצות תכונות חדשות, יחידות מידה לא סטנדרטיות, פריטים בלי קוד.
בנפרד נעלם סוג של כשלים הקשור לתכונות מוצר שאבדו. אם תכונה לא הגיעה או הגיעה בלי קישור לווריאנט, הכרטיס נשאר בלי מסנן — הקונה פשוט לא מוצא אותו, והשגיאה צפה רק מאוחר יותר. כשהסנכרון מוגדר, אי-התאמות כאלה נכנסות לדוח הצלבה כבר באותו יום.
לסיכום האפקט: הקטלוג מפסיק לדרוש כוננות מתמדת, והנתונים במערכת הנה"ח ובאתר כבר אינם חלוקים. זה יוצר רקע יציב לגידול במגוון — פריטים חדשים נכנסים לאותו קו בלי לבנות מחדש את הלוגיקה.
אפשרויות סנכרון הקטלוג: מלא, אינקרמנטלי, תור
ייצוא מלא של הקטלוג קורא מחדש את כל הפריטים ואת מאגר המאפיינים. הלוגיקה פשוטה וללא מצב בצד הסנכרון — אבל בקטלוג של עשרות אלפי פריטים מעבר אחד נמשך שעות וכל הזמן הזה מחזיק עומס על שני הקווים. לכן בוחרים בה לאכלוס ראשוני ולהצלבות תקופתיות, ולא כמשטר יומיומי.
סנכרון אינקרמנטלי מעביר רק את מה שהשתנה מהסימן שנקבע — העומס יורד פי כמה, אבל הסכמה נשענת על סימן שינוי אמין. אם השעה בשרתים אינה מסונכרנת או שהסימן מתאפס בהעברת מסד הנתונים, חלק מהעדכונים לא מגיע בשקט, והפער צף רק בהצלמה.
תור אירועי הסנכרון הופך את הלוגיקה: העדכונים נאספים ברגע הכתיבה ומעובדים אחד-אחד, ומעניקים השהיה מינימלית וידיעה מדויקת מה בדיוק לא הגיע — במחיר של שירות נפרד וטיפול בהודעות שנתקעו.
| סכמת סנכרון הקטלוג | מתי מתאימה | מגבלות |
|---|---|---|
| ייצוא מלא של הקטלוג | אכלוס ראשוני, הצלבות נדירות, קטלוג קטן | מעבר ארוך, עומס שיא, לא עומד בקצב של עריכות תכופות |
| סנכרון אינקרמנטלי | הקטלוג משתנה באופן קבוע, אך לא תמיד | תלוי בתקינות סימן השינויים; פספוסים נראים רק בהצלמה |
| תור אירועי סנכרון | עריכות תכופות, מחירים ומלאי נדרשים כמעט מיד | נדרש שירות תור נפרד, טיפול בתקלות ובחזרות |
את סכמת סנכרון הקטלוג בוחרים לפי ההיקף ותדירות העריכות, ולא לפי קלות ההגדרה. עבור ייצוא מאפיינים מ-1С УТ זה עקרוני: הסנכרון חייב להתבצע לפי מפתח יציב של פריט ותכונה, אחרת מוצר אחד מגיע בכמה כרטיסים וכפילויות ה-SKU מצטברות בכל סנכרון.
שלבי הטמעת הסנכרון: מביקורת ועד מסירה
הסנכרון נשבר לא בהגדרה, אלא בקלט: אם ב-1С:УТ מאפיינים מוגדרים כפריטים נפרדים, ותכונות המוצר באתר מתוארות אחרת, הייצוא יוצר כפילויות SKU. לכן קודם מנתחים את המאגר, ורק אחר כך כותבים את הכללים. כל שלב נסגר בתוצאה ניתנת לבדיקה.
- ביקורת הפריטים — מייצאים את המאגר לקובץ, סופרים פריטים אמיתיים מול וריאנטים, מאתרים מקרים מעורבים: חלק מהמאפיינים מוגדרים כתכונות, חלק ככרטיסים נפרדים. בפלט — מפת אי-התאמות עם היקף הנרמול.
- התאמת תכונות המוצר — טבלת התאמה: מאפיין במערכת הנה"ח → תכונה, הצעת מכר או שדה בקטלוג האתר. מסמנים מה הופך לווריאנט SKU ומה למאפיין עבור המסנן. מתאמים לפני כתיבת הכללים.
- הגדרת סנכרון הקטלוג — צומת סנכרון, הרכב האובייקטים, חלוקת הייצוא למנות כדי שמדורים גדולים לא יחסמו את האתר. כפילויות נסגרות בכללים: התאמה לפי מפתח חיצוני, ולא לפי שם.
- העברת נתונים לניסיון — ריצה על עותק של הקטלוג החי: מצליבים את מספר הפריטים, הווריאנטים והמחירים לפני ואחרי, בודקים שייצוא חוזר אינו יוצר כרטיסים. מודדים את זמן הסנכרון המלא ואת זמן סנכרון השינויים.
- בדיקת הכרטיסים והמסננים — הווריאנטים נבחרים, המחירים והמלאי מוזנים, המסנן לפי תכונה מחזיר רשימה נכונה. אי-התאמות מתקנים בכללים, ולא ידנית בקטלוג.
- מסירה לתמיכה — תרשים הצומת, טבלת ההתאמה, נהל ההרצה וסדר הפעולות בעת תקלה. את הרישום ביומן מגדירים כך שבמקרה של אי-התאמה ייראה באיזה שלב בסנכרון היא נוצרה.
תיעוד, נהלים וכללי התאמת המאפיינים
סנכרון עם קונפיגורציית מסחר חי שנים: מופיעות תכונות חדשות, משתנות קבוצות מוצרים, מתחבר אתר שני. אם ההסכמות נשארו בהתכתבות, העריכה הראשונה כבר שוברת את ההתאמה — ייצוא המאפיינים עובר למוצרים זרים, והמק"טים משוכפלים. לכן בסוף העבודה מוסרים ערכת תוצרים שלפיהם כל מהנדס ומנהל תוכן ממשיכים את הסנכרון.
- תרשים הסנכרון: סדר ייצוא המאפיינים והצעות המכר, מה חוזר בחזרה, והיכן עובר גבול האחריות בין המערכות.
- מפת התאמת השדות: שדה המקור, התכונה או המאפיין באתר, חובה, כלל ההמרה, יחידת מידה.
- כללי התאמת התכונות: מה הופך למאפיין, אילו ערכים מנורמלים, כיצד מטפלים בריקים ובמתנגשים — עם דוגמאות לפי קבוצות מוצרים.
- נהל עדכון הקטלוג: לוח הזמנים של הסנכרון, פעולות בעת אי-התאמה, תמונת מצב של הקטלוג לפני הטעינה ונוהל החזרה לאחור.
- הנחיות למנהל התוכן: כיצד לתקן מאפיין ידנית כדי שהסנכרון הבא לא ידרוס אותו ולא ייצור מק"ט שני.
- תיעוד הסנכרון: תיאור הצומת, הרשאות הגישה, המטפלים והיומנים — כדי שניתן יהיה למסור את המערכת למהנדס בלי התכתבות.
- יומן עריכות של כללי ההתאמה: מה השתנה, עבור אילו קבוצות מוצרים ומדוע — בניתוח אי-התאמות הסיבה נראית מיד.
מקרה בוחן: קטלוג ומערכת הנה"ח בלי כפילויות פריטים
מה היה לפני
ב-1С:УТ מאפיינים הם מאגר נפרד המקושר לפריטים, ואילו בקטלוג כל שילוב של תכונות הפך למוצר עצמאי. הסנכרון ייצא פריטים ומאפיינים בשני זרמים בלתי תלויים: שינו שם של תכונה או הוסיפו ערך חדש — האתר פתח פריט חדש במקום לעדכן את הקיים. על 18,000 מק"טים פעילים הצטברו 4,100 כפילויות, והמנהלים תיקנו ידנית כ-60 כרטיסים בשבוע.
מה שינו
הפכנו את המאפיין לחלק ממפתח ההתאמה: לכל שילוב של תכונות נוצר מזהה יציב שאינו תלוי בשם. הסנכרון הפך לדו-שלבי — תחילה מסונכרן מאגר המאפיינים, ואחר כך הפריטים מפנים לערכים הקיימים; במקרה של אי-התאמה הפריט אינו נוצר, אלא נכנס לדוח אי-ההתאמות.
סנכרון מלא ארך 40 דקות, ובמהלכן הקטלוג עבר למצב קריאה בלבד; כעת הנתונים מיושמים במנות, בלי לעצור את המכירות.
מה התוצאה
את הכפילויות סגרו באמצעות איחוד כרטיסים עם העברת היסטוריית ההזמנות והשיוך למדורים — שיעור הפריטים שהותאמו אוטומטית עלה מ-71% ל-99.4%. עריכות ידניות נותרו כעשר בחודש, וכמעט כולן — עבור אספקות חדשות, ולא עבור מוצרים שהוזנו קודם. השבתת הקטלוג בזמן הסנכרון הצטמצמה מ-40 דקות לאפס: הקונה אינו מבחין ברגע שבו הנתונים מתעדכנים.
במה שונה סנכרון לפי אירוע מסנכרון לפי לוח זמנים?
סנכרון לפי אירוע וסנכרון לפי לוח זמנים פותרים משימה אחת — להעביר שינויים במאפיינים מ-1С:УТ אל 1C-Bitrix — אך מתנהגים אחרת עם גידול במספר הפריטים. במקרה הראשון מערכת הנה"ח עצמה מודיעה שהאובייקט השתנה. בשני האתר שולף מעת לעת מנת נתונים.
לפי אירוע. עריכה של תכונות או של הרכב הצעת המכר נכנסת לתור, והמטפל מיישם אותה על הכרטיס לפי מפתח חיצוני. השהיית עדכון הקטלוג — שניות, ונפח ההעברה פרופורציונלי למספר העריכות, ולא לגודל הקטלוג.
הצד השני: אירוע שהוחמץ לא חוזר מעצמו, ולכן נדרשים יומן אספקה ועיבוד אידמפוטנטי — אחרת חזרה יוצרת כפילות SKU.
לפי לוח זמנים. אחת לשעה או בלילה מתבצע ייצוא של מאפיינים מ-1С УТ והשוואה למצב הקטלוג הנוכחי. קל להפעיל מחדש את הסכמה ולהצליב, אבל בין הריצות האתר מציג מחירים ומלאי ישנים. כשמספר הפריטים גדול, חלון הריצה גדל, הריצות חופפות, וחלק מהשינויים הולכים לאיבוד.
| סכמה | השהיית עדכון | מתי מתאימה | מגבלות |
|---|---|---|---|
| לפי אירוע | שניות | עריכות תכופות של מחירים, מלאי, מאפיינים | נדרשים יומן ועיבוד חוזר |
| לפי לוח זמנים | מריצה לריצה | שינויים נדירים, סנכרון לילי | פער בין הריצות, חלון הולך וגדל |
הפתרון המעשי — היברידי: אירועים מספקים את השדות הקריטיים, וריצת הלילה משלימה את מה שהוחמץ ומשמשת כהצלמה.
שאלות טכניות בהגדרת הסנכרון
שאלות בנוגע לסנכרון הקטלוג צפות לא בהתחלה, אלא אחרי השבועות הראשונים: מצטברות כפילויות של הצעות מכר, מופיעות תכונות בלי תאום במערכת הנה"ח, ולעיתים מתרחש ניתוק של הפעלת הסנכרון. להלן תשובות למה שבדרך כלל מבררים לפני תחילת העבודה.
מה עושים עם כפילויות שכבר הצטברו?
מנתחים לפי מפתח ההתאמה: המזהה הייחודי של הפריט ממערכת הנה"ח נשמר בתכונה של הצעת המכר. תחילה מקשרים את הפריטים הקיימים לרשומות במערכת הנה"ח, ואחר כך מקפלים את המיותרים — הזמנות, מלאי ומחירים מועברים למק"ט הראשי. כפילויות בלי היסטוריה נמחקות, והסנכרון מעדכן מכאן והלאה רק פריטים מקושרים.
כיצד מועברות תכונות שאין להן מקבילה באתר?
התכונה נוצרת אוטומטית: הסוג, הריבוי והקישור למאגר נלקחים מהגדרות הייצוא. אם במערכת הנה"ח זהו מנייה — מרימים מאגר ערכים ומתאימים את הווריאנטים לפי קוד, ולא לפי שם, כדי ששינוי שם לא ייצור ערך חדש. טקסט חופשי מועבר כמחרוזת עם הגבלת אורך.
מה קורה בעת ניתוק של הפעלת הסנכרון?
הסנכרון מתבצע במנות, וכל אחת נרשמת ביומן לפני היישום. מנה שלא הושלמה אינה מועברת: הפעלה חוזרת מטפלת בה מחדש לפי אותו מזהה, ולכן לא נותרות מאפיינים שאבדו או הוכפלו. לוח הזמנים ממשיך מהשלב המוצלח האחרון, ואין צורך בסנכרון ידני.
נדון במשימה: כיצד מתבצע הניתוח הראשוני
הניתוח הראשון אינו שיחה להכירות, אלא איסוף עובדות שבלעדיהן ההערכה הופכת לניחוש. כדי לדון במשימת הסנכרון באופן ענייני, אנחנו בוחנים כיצד המאפיינים מנוהלים במערכת הנה"ח, כיצד הם מגיעים לקטלוג כיום ובאילו מקומות נוצרות כפילויות של הצעות מכר.
- מה מבררים במערכת הנה"ח: אילו מאגרים ותוכניות סוגי מאפיינים משמשים כמקור האמת, לפי איזה שדה הפריט מקושר למוצר באתר, והאם לערכים יש מק"טים ומלאי משלהם.
- מה בודקים בצד הקטלוג: מבנה המדורים והאינפובלוקים, סוגי התכונות, הקישור של הצעות המכר למוצר וכלל יצירת הקוד הסימבולי.
- אילו נתוני מקור נדרשים להערכה: ייצוא של פריטים עם תכונות וערכים, רשימת פריטים בעייתיים עם כפילויות, היקף הקטלוג ותדירות השינויים.
- מה מגדירים לגבי גבולות הסנכרון: כיוון (רק ייצוא או כתיבה חוזרת של הזמנות ומלאי), מצב ההרצה לפי אירוע או לפי לוח זמנים, והתגובה לערכים שנמחקו או ששמם שונה.
- הרכב עבודות האינטגרציה: התאמת שדות וסוגי תכונות, נרמול ערכים, כללי קיפול של מאפיינים זהים, טיפול בשגיאות ויומן הסנכרון.
- תוכנית הטמעת הסנכרון: קו ניסוי, ייצוא ניסיוני על חלק מהקטלוג, הצלבת התוצאה מול מערכת הנה"ח, ואחר כך ריצה מלאה ומעבר למצב סדיר.
- מה מקבלים בסוף הניתוח: מפת התאמות, רשימת התאמות נדרשות, רצף שלבים עם נקודות בקרה ודרישות להרשאות.
תארו את משימת הסנכרון — נחזור עם הערכה ותוכנית שבה ייראה באילו שלבים הכפילויות מפסיקות להופיע.