פרסינג נתונים מיאנדקס מרקט עבור 1C-ביטריקס

פרסינג Яндекс.Маркет לקטלוג ב-1С-Битрикс: מה נשבר

הפלטפורמה עדכנה מחירים בלילה, אך הוויטרינה ב-1С-Битрикс נשארה בערכים הקודמים: הקונה מבצע הזמנה במחיר שכבר אינו קיים, והמנהל רואה מלאי שאינו תואם את המחסן האמיתי.

זו אינה תקלה חד-פעמית, אלא התנהגות תקינה של קטלוג ללא חילופין קבועים — פרסינג Яндекс.Маркет הופך למערכת של פעולות ידניות, בעוד שעליו להיות חלק מזרימת הנתונים.

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

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

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

מה נותן חילופין קבועים של נתוני מוצרים עם מרקטפלייס

איסוף חד-פעמי של הקטלוג פותר את הבעיה ליום אחד, ולאחר מכן המחירים והמלאי שוב אינם תואמים את המציאות. חילופין קבועים עם Яндекс.Маркет בנויים כמשימה שגרתית: המערכת בעצמה מושכת שינויים במוצרים ומחזירה מחירים ומלאי מעודכנים, ומשאירה לאנשים רק חריגים.

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

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

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

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

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

פורמטים של פרסינג: ייבוא חד-פעמי, לוח זמנים, זרם עדכונים

פורמט האיסוף קובע לא את נוחות העבודה, אלא את אי-ההתאמה המותרת בין הקטלוג באתר לכרטיס בפלטפורמה. ניתן למשוך נתונים מ-Яндекс.Маркет באופן חד-פעמי, לפי לוח זמנים, בזרם או דרך הממשק הרשמי של הפלטפורמה — לכל אפשרות סוג סירובים משלה ומגבלות איסוף משלה. להלן השוואה שלפיה בדרך כלל בוחרים את הסכמה.

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

סדר היישום: מביקורת קטלוג ועד העברת תקנונים

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

1. ביקורת קטלוג. אנו משווים מיון, הצעות מסחר ומאפיינים, מחפשים כפילויות, פריטים ללא מזהים חיצוניים ומוצרים שנמצאים בקטלוג אך אצל הספק כבר הוסרו מהמכירה. בפלט — מפת התאמה ורשימת מקומות שהחילופין ישברו.
2. סכמת חילופין. אנו מגדירים כיווני זרימות, תדירות הפעלה, התנהגות בעת אי-התאמה ומגבלות על נפח שינויים בהרצה אחת. הסכמה נקבעת בכתב לפני שורת הקוד הראשונה.
3. כללי התאמה. המפתח הראשי — מזהה חיצוני, המפתח המשני — מק"ט ושם מנורמל. בנפרד אנו מתארים יצירת פריטים חדשים, העברת נעלמים לארכיון וקדימות מחיר: מהכרטיס או מהמחירון.
4. הגדרת חילופין. אנו מיישמים חילופין ב-1С-Битрикс, קובעים משימות לפי לוח זמנים, מחברים יומן: כל הרצה כותבת דוח עם מספר הפריטים שנוצרו, עודכנו ונדחו.
5. בדיקה על עותק. אנו מריצים על עותק של קטלוג הייצור ועותק של בסיס הנתונים: הרצה חוזרת, ניתוק קשר, תגובה ריקה, נתונים שגויים חלקית. החזרה צריכה להיות פעולה שגרתית עוד לפני ההשקה.
6. העברת תקנונים. הוראות למנהל התוכן: כיצד לקרוא את הדוח, מה לעשות בסטיות המוניות, כיצד להוסיף קטגוריה. בנוסף יומן הרצות והתראות, כדי שתקלה תתגלה לפני תלונת הקונה.

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

לאחר הפעלת פרסינג Яндекс.Маркет נשארים לכם לא ייצואים חד-פעמיים, אלא קווי חילופין עובדים: סכמות, כללים ומסמכים שלפיהם הצוות ממשיך לעבוד ללא מחבר הפתרון. זהו קריטריון הקבלה העיקרי — ניתן להעביר את המערכת למהנדס אחר או למסור לתחזוקה, בלי לשחזר את ההיגיון מהתכתבות.

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

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

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

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

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

אספנו זרם נתונים מ-Яндекс Маркет לקטלוג: התאמה לפי מק"ט וברקוד, כללי קדימות, תור חילופין עם יומן לכל פריט וחזרה למצב התקין האחרון בעת תקלה במקור. שורות שנויות במחלוקת אינן מוחקות מחירים בשתיקה, אלא נאספות לרשימה נפרדת עם סיבה — העורך מטפל רק בהן.

העדכון מתבצע כל 30 דקות לפי מחיר ומלאי ופעם ביממה לפי קטגוריות ומאפיינים. שיעור הפערים ירד מתחת ל-1%, התערבות ידנית נדרשת בכ-3% מהפריטים, והעומס על העורך הצטמצם ל-40 דקות ביום: הוא בודק חריגים, ולא מאחד טבלאות. סירובים עקב מלאי הצטמצמו פי כמה, והכרטיסים הפסיקו לסטות מהמחסן האמיתי.

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

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

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

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

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

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

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

ספקות טכניים: התאמה, כפילויות, מגבלות פניות

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

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

מה יקרה לכפילויות כרטיסים בחילופין קבועים?

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

האם לא ניתקל במגבלות פניות למקור?

החילופין מתבצעים לפי לוח זמנים עם הפסקות בין פניות ו-кэширование של מדורים שלא השתנו. בתגובה על מגבלה, החילופין מושהים וממשיכים מאותו פריט, והניסיונות החוזרים נעשים בהשהיה הולכת וגדלה. היומן מתעד כל פעולה, לכן תקלה באמצע ייצוא אינה מביאה לקטלוג מעודכן חלקית.

נדון במשימה: מה להכין לשיחה ומה תקבלו

כדי שהשיחה על פרסינג Яндекс.Маркет תהיה עניינית ולא 'באופן כללי', די להכין לה כמה נתוני פתיחה על הקטלוג. ככל שהם מתוארים בצורה מדויקת יותר, כך יש פחות הנחות בהערכת הזמנים ותוכנית העבודה יוצאת konkretit יותר. להלן מה שבאמת משפיע על הרכב העבודה.

• מקור ויעד. מדור או רשימת קטגוריות ב-Маркет, מהם אנו לוקחים כרטיסים, ולאן הם נכנסים ב-1С-Битрикс: הצעות מסחר, מאפיינים, מדורי קטלוג.
• כללי התאמה. לפי איזה שדה אנו מקשרים מוצר לפריט קיים — מק"ט, ברקוד, שם עם דגם; מה עושים כאשר שני מקורות נותנים ערכים שונים.
• הרכב הכרטיס. אילו שדות נדרשים: מחיר, מאפיינים, גלריה, תיאור, מלאי; מה מתעדכן לעתים קרובות, ומה מספיק לטעון פעם אחת.
• תקנון עדכון. הפעלה ידנית, לפי לוח זמנים או לפי שינוי; מה קורה למוצר שנעלם מהתוצאות.
• גישות ומגבלות. האם יש גישה תוכנית רשמית לנתונים או שאנו עובדים דרך ייצואים, מהן המגבלות על תדירות הפניות, מי מצד המזמין מאשר את הכללים.
• אחראי על כרטיסים שנויים במחלוקת. מי מטפל במקרי גבול ובאיזה ערוץ מאשרים תיקונים בכללים.

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