ניתוח Excel/CSV: ייבוא אוטומטי ל-Bitrix

פרסינג Excel ל-1С-Битрикс: היכן הייבוא נשבר

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

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

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

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

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

מה נותן ייבוא אוטומטי של מחירונים לקטלוג

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

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

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

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

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

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

דרכי טעינת נתונים מ-Excel: השוואת מצבים

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

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

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

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

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

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

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

מה נשאר בידיכם אחרי היישום

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

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

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

מקרה בוחן: מחירון עם 40 אלף פריטים בלי תיקון ידני

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

מה שינו בייבוא

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

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

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

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

במה שונה ייבוא חד-פעמי מסנכרון סדיר

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

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

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

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

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

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

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

איך מסננים כפילויות של פריטים במחירון?

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

מה יקרה לקובץ עם מאה אלף שורות ולקטיעה בטעינה?

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

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

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

• דוגמאות קבצי Excel/CSV — שניים-שלושה, כולל אחד "מלוכלך": עם תאים מאוחדים, גיליונות מיותרים, שורות ריקות ופורמטים שונים של מספרים.
• מבנה הקטלוג: קטגוריות ותתי-קטגוריות, מאפייני מוצרים, הצעות מסחריות, קישור פריטים לקטגוריות.
• מקטי"ם וכללי התאמה — לפי איזה שדה מזהים מוצר שכבר קיים באתר, ומה לעשות עם כפילויות.
• מדיניות לפריטים חדשים, שהשתנו ונעלמו: להוסיף, לעדכן מחירים ומלאי, להסיר מפרסום או למחוק.
• כיוון ההחלפה: קובץ מהספק, ייצוא מ-1С לקטלוג או כתיבה חוזרת של הזמנות ומלאי מהאתר למערכת הנה"ח.
• נוהל עדכונים: באיזו תדירות משתנה הקובץ, מי מייצא אותו, מה לעשות בכשל ואיך לשחזר טעינה כושלת.
• הרשאות לסביבת בדיקה ולוח זמנים מתי אפשר לבצע שינויים בקטלוג העבודה.

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