מילוי אוטומטי של קטלוג מוצרים מפידי ספקים ב-1C-Bitrix

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

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

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

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

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

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

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

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

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

שיעור העריכות הידניות — אחוזים בודדים

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

עדכון מלא — דקות במקום שעות

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

סוג הכשלים בטעינה

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

מוצרים חדשים מוצגים באותו יום

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

עומס על העובד

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

סנכרון עם קטלוג Bitrix: סכמות טעינת פידים של ספקים

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

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

סדר ההטמעה: מניתוח פידים ועד תהליך עדכון

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

1. ניתוח פידים של ספקים. לוקחים מחירון אחד מכל מקור ובוחנים את המבנה: XML/YML, CSV או JSON, קידוד, מפרידים, קינון קטגוריות, שדות חובה. מחשבים את שיעור הפריטים בלי מק"ט, עם כפילויות ועם יחידות מידה שונות — מזה תלוי היקף הכללים.
2. תכנון סכמת הקטלוג. מחליטים איך המוצרים ישתלבו בבלוקי מידע ובהצעות מסחריות, אילו מאפיינים ממלא הפיד ואילו נשארים ידניים — תיאורים, תמונות, תגי מטא. בוחרים אסטרטגיית סנכרון: החלפה מלאה, עדכון לפי קוד או דלתא, ומה לעשות עם פריטים שנעלמו מהמחירון.
3. הגדרת התאמה. רושמים מפתחות קישור — קוד ספק, ברקוד, מק"ט, — נרמול שמות ומותגים, המרת יחידות וכללי תוספת מחיר. כל כלל מכסים במקרה בדיקה, כדי שפער יצוף בניתוח ולא בחנות.
4. הרצה על עותק. ייבוא מלא בסביבת בדיקה: מודדים את זמן הסנכרון, מספר הפריטים שנוצרו ועודכנו, היקף השגיאות ביומן. בודקים שהמחירים והמלאים חושבו מחדש, שהמדורים לא הוכפלו, וכתובות הכרטיסים לא השתנו.
5. קבלת הסנכרון. משווים את הקטלוג למחירונים לפי מדגמי ביקורת: מספר פריטים, מחירים, מלאים, מאפיינים, שיוך למדורים. מתעדים אילו פערים מותרים ואיך מטפלים בהם.
6. מסירה עם תהליך עדכון. מוסרים לוח זמנים להפעלות, סדר טיפול בשגיאות והתראות, הוראות לעורך הקטלוג וכללי שחזור: איך להחזיר את המצב הקודם אם הספק שלח מחירון פגום.

כללי התאמה ותבניות: מה הצוות מוסר לידיים

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

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

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

ניתוח פרויקט: 12 ספקים ו-40 אלף פריטים

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

נקודת התחלה

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

מה קרה לאחר הארגון מחדש

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

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

במה שונה עדכון לפי לוח זמנים מהפעלה לפי אירוע?

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

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

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

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

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

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

להלן השאלות שנשאלות לרוב לפני הפעלת מילוי אוטומטי של הקטלוג ב-1C-Bitrix.

אותו מוצר קיים אצל שני ספקים — תהיה כפילות?

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

הספק שינה את מבנה הקובץ — הסנכרון יישבר בשקט?

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

הסנכרון נפסק באמצע — הקטלוג יישאר חצי ריק?

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

אנחנו מוסרים את הסנכרון לצוות אחר — מה נדרש לכך?

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

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

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

• דוגמאות פידים של ספקים כפי שהם: XML, CSV, JSON, YML, כולל ייצואים בעייתיים וקבצים עם מבנה לא סטנדרטי;
• סכמת הסנכרון הנוכחית: מה ממלא את הקטלוג כעת, לפי לוח זמנים או ידנית, היכן נשמרים נתוני הביניים והלוגים;
• הרכב הכרטיסים: אילו מאפיינים והצעות מסחריות נדרשים, איך לטפל במחירים, במלאים ובפריטים שהוסרו מהמכירה;
• כללי התאמה: לפי מק"ט, ברקוד או שם, האם יש בסיס התאמות מצטבר ומי מנהל אותו;
• מגבלות המקורות: מגבלות על פניות, חלונות זמינות של ייצואים, דרישות לפורמט נתוני הפלט;
• הרשאות גישה: סביבת בדיקה עם עותק של הקטלוג, מפתח למקור או ייצוא חד-פעמי, איש קשר מצד הספק.

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