מדוע ייצוא יתרות 1С УТ ל-Bitrix נשבר במחסנים
לרוב ייצוא יתרות 1С УТ ל-Bitrix נשבר לא בשלב של "אין חיבור", אלא בלוגיקת התאמת המחסנים. ב-УТ מחסן הוא אוגר נפרד עם אנליטיקה משלו, ובקטלוג החנות המקוונת מתאים לו מחסן משלוח אחד או שניים.
אם ההתאמה מוגדרת "בערך", החלפת הנתונים בין 1С ל-Bitrix עוברת פורמלית, אבל אי-ההתאמה ביתרות לפי מחסנים מצטברת עם כל מסמך: הסחורה רשומה במחסן הסיטונאי, והאתר מוכר אותה מהמחסן הקמעונאי.
תקלה טיפוסית שנייה — תורים תקועים של החלפת נתונים. ייצוא מלא מופעל לפי לוח זמנים, אבל בתנועת מסמכים המונית הסשן לא מספיק להיסגר לפני ההתחלה הבאה. מנה חדשה של שינויים נעמדת בתור אחרי הישנה, ועדכניות היתרות בחלון הראווה מתחילה לפגר בשעות.
מבחוץ זה נראה כמו "המוצר קיים, אבל הוא לא קיים": הקונה מבצע הזמנה, והמלקט לא מוצא את הפריט.
סיבה שלישית — כפילויות של שריון במחסן. שריון שהוסר ב-1С בעת המשלוח לא תמיד מוסר ב-Bitrix, ולהפך: הזמנה שבוטלה באתר משאירה את הסחורה בשריון במערכת החשבונאית. היתרה "נאכלת" פעמיים, הכמות הזמינה למכירה יורדת, למרות שהסחורה פיזית נמצאת על המדף.
דווקא סוג תקלות זה פוגע במכירות הכי חזק — חלון הראווה מציג אפסים בפריטים נמכרים, והמנהל רואה מדף מלא.
בנפרד יש לציין אי-סנכרון בזמן: אם החלפת הנתונים מתבצעת רק לפי לוח זמנים, בין הסשנים האתר סוחר בנתונים מיושנים. מפרקים כיצד זה נסגר — מהתאמת מחסנים והפרדה בין ייצוא מלא לייצוא מהיר ועד לכללים להסרת שריון ובקרת התור.
מה נותן חילוף תקין של יתרות ומלאי מוקצה
חילוף תקין של יתרות אינו "המספרים תאמו", אלא התנהגות צפויה של חלון הראווה ברגע עומס שיא. כאשר היתרות לפי מחסנים מגיעות ל-Bitrix באיחור, הקונה מבצע הזמנה על מוצר שכבר אינו קיים, והמנהל מגלה על כך בזמן הליקוט. כל ביטול כזה הוא החזרה, התכתבות ולקוח אבוד שעובר למתחרה עם מלאי זמין בפועל.
מהירות עדכון היתרות נקבעת לא בתדירות הפעלת החילוף, אלא בארכיטקטורה שלו: ייצוא מצטבר של שינויים במקום איסוף מחדש מלא של הקטלוג, תור אירועים והפרדת זרמים לפי מחסנים.
בפועל זה מעביר את חלון הראווה ממצב של "נתונים בני שעה" למצב של "עדכניות בטווח של דקות" — שיעור הביטולים מסיבת היעדר מוצר יורד פי כמה, ולא באחוזים בודדים.
דיוק המלאי המוקצה חשוב יותר מהייצוא עצמו: יתרה ללא התחשבות במה שמוקצה להזמנות ולמשלוחים יוצרת זמינות כוזבת. כאשר המלאי המוקצה מ-1С:УТ מסונכרן עם סל הקניות וההזמנות שבוצעו, הקונה רואה בדיוק את הכמות שהמחסן יכול 실제 לשלוח, ואינו מקבל סירוב לאחר התשלום.
העומס על המחסן הוא גם פרמטר נשלט. אם החילוף מפעיל את 1С בכל צפייה בכרטיס, מסד הנתונים מדרדר בשעות שיא, והמלקטים עובדים עם משימות מיושנות. פריסת החילוף לפי לוח זמנים ושמירת זמינות במטמון בצד האתר מסירות פניות מיותרות ומאזנות את העומס בין חלון הראווה למערכת החשבונאית.
ולבסוף, סוג הכשל. חילוף שנבנה נכון שורד אי-זמינות של 1С או של האתר בלי אובדן נתונים: השינויים נצברים בתור ומדביקים את הפער עם חידוש הקשר, ולא אובדים בשקט. именно זה מבדיל אינטגרציה עובדת מזו ש"לפעמים מתפצלת" — וכאן בדיוק ניכר עד כמה התרחיש מעובד לעומק.
דרכי סנכרון: החלפה לפי לוח זמנים, אירועים ובקשה
מצב ההחלפה קובע באיזו מהירות המלאי בחלון הראווה מדביק את המחסן, ואיזה עומס זה יוצר על שתי המערכות. בפועל בוחרים בין שלוש סכימות — לפי לוח זמנים, לפי אירועים ולפי בקשה — ולעיתים קרובות משלבים אותן: ייצוא מלא וכבד בלילה, שינויים ממוקדים במהלך היום.
השוואת מצבים
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| לפי לוח זמנים | הקטלוג והמלאי משתנים באופן צפוי; נדרש תחזוקה פשוטה | השהיית העדכון שווה למרווח: בין ההרצות חלון הראווה מציג נתונים מיושנים |
| לפי אירועים | מכירות וקבלות זורמות ברצף; חשוב טריות המלאי | דורש תור וטיפול בתקלות; בעת סערת אירועים גדל העומס על השרת |
| לפי בקשה | קטגוריות נדירות, בדיקה לפי דרישה, חישוב מחדש ידני | כל בקשה — קריאה סינכרונית אל 1С: בתדירות גבוהה מסד הנתונים מגיב לאט |
מה לקחת בחשבון בעת הבחירה
החלפה לפי לוח זמנים מספקת עומס צפוי: אתם קובעים חלון, גודל מנה וסדר הייצוא, והשרת 1С לא מקבל פרצים בשעות שיא. החלפה מבוססת אירועים מקצרת את השהיית העדכון לשניות, אך דורשת עיבוד אידמפוטנטי — מסירה חוזרת של אותו שינוי לא צריכה להכפיל את המלאי.
החלפה לפי בקשה נוחה כתוספת: היא לא מחזיקה ערוץ קבוע, אך בתדירות קריאות גבוהה הופכת לצוואר בקבוק. אנחנו בדרך כלל בונים היברידי — אירועים עבור מחסנים תפעוליים, לוח זמנים עבור ספרי עזר, בקשה עבור התאמה. מפרטים כיצד זה מוגדר עבור התצורה שלכם.
כיצד אנו מגדירים ייצוא מלאי מ-1С УТ ל-Bitrix
מתחילים בבדיקת ספריית המחסנים ב-1С:УТ ובמבנה הקטלוג בצד האתר. בשלב זה מתברר אילו מחסנים באמת משתתפים במכירות, היכן קיימים שמות כפולים וכיצד ממופות כעת נקודות המכירה. בלי זה כל הגדרה של סנכרון מלאי מייצרת מלאי "באוויר" — המוצר רשום, אך לא במחסן שממנו מתכוונים לשלוח אותו.
- בדיקת מחסנים ונקודות מכירה. משווים את הספריות משני הצדדים, מסמנים מחסנים שאסור שיופיעו בחנות (פסולים, מעבר, אחסון באחריות), וקובעים רשימת מחסנים פעילים.
- סכימת התאמת מחסנים. בונים טבלת מיפוי: GUID של המחסן ב-1С, מזהה המחסן באתר, סימן פרסום, עדיפות בסיכום. סכימת התאמת מחסנים היא מסמך שלפיו מתקנים לאחר מכן כל אי-התאמה, ולא "הגדרה בממשק שאף אחד לא זוכר".
- הגדרת הסנכרון. קובעים כיוון ותדירות: ייצוא מלא בסנכרון ראשוני, ולאחר מכן — רק שינויים. מגדירים סינון לפי ארגונים ומחסנים, כדי שמלאי של ישויות משפטיות אחרות לא יעבור לאתר.
- בדיקת רזרבות. בנפרד מנתחים רזרבות וקבלות צפויות: מה להציג ללקוח — מלאי פנוי או מלאי בהתחשב ברזרבה. כאן לרוב עולים אי-התאמות בין "זמין להזמנה" ל"קיים במחסן".
- הרצת בדיקה. משווים את הייצוא לפי מדגם בקרה של פריטים: 1С → אתר ובחזרה, בודקים התנהגות במלאי אפס ובהתווספות מחסן חדש.
- נוהל עדכון. מגדירים לוח זמנים לסנכרון וכללי טיפול בשגיאות: מה לעשות אם הסשן לא הסתיים, כיצד להשלים שינויים שהוחמצו בלי העלאה מחדש ידנית של הקטלוג.
- מסירה והדרכה. מוסרים את סכימת ההתאמות, הנוהל וההוראות להוספת מחסן חדש — כדי שתיקונים לא ידרשו הזמנת מפתח.
לאחר המסירה הסנכרון פועל לפי לוח זמנים, והשינויים בספריית המחסנים מבוצעים לפי כלל מתועד.
מה נשאר לכם לאחר הגדרת הסנכרון
הגדרת הסנכרון היא לא רק ערוץ עובד בין 1С:УТ ל-Bitrix. כדי שייצוא היתרות לפי מחסנים לא יתפצל אחרי חודש, לאחר המסירה נשאר סט ארטיפקטים שלפיו ניתן לתחזק את המערכת בלעדינו.
- חוקי הייצוא — אילו מחסנים, קבוצות מלאי וסוגי יתרות נכנסים לאתר, באיזו תדירות ובאיזה סדר עדיפויות בעת התנגשות נתונים. החוקים מתוארים בטקסט, ולא רק "מוגדר במודול".
- התאמת מחסנים — טבלת השוואה בין מחסני 1С לבין מחסנים/אזורי מלאי באתר, כולל אלה שהוחרגו מהסנכרון במכוון. בנפרד — חוקים לנקודות מכירה ולמחסני אחסון זמני.
- יומן סנכרון — היכן לראות מה ומתי יוצא, אילו פריטים נדחו ומדוע. עם מסננים לפי מחסן ותקופה, כדי שחקירת תקלה תימשך דקות ולא שעות.
- נוהל עדכון — לוח זמנים של סשנים, סדר הפעלה ידנית, התנהגות כאשר אחת המערכות אינה זמינה וחוקי השלמה של מה שהוחמץ.
- הוראות מנהל — פעולות שלב אחר שלב למצבים טיפוסיים: היתרה לא התעדכנה, המחסן נעלם, הסנכרון נעצר לאחר עדכון קונפיגורציה.
- תרשים זרימת נתונים — ממסמך קבלת סחורה ב-1С ועד כרטיס המוצר באתר, עם נקודות בקרה בכל שלב.
- צ'קליסט קבלה — סט בדיקות שלפיהן אתם בעצמכם משתכנעים שהסנכרון עובד: פריטי בקרה, מחסנים בגבול, התנהגות ביתרה אפס.
את הסט מעבירים במערכת ניהול המשימות שלכם ובצורת מסמך לצד הפרויקט. בהמשך את הסנכרון מתחזק המנהל שלכם לפי ההוראות, ואנחנו מתחברים כשמשתנה מבנה המחסנים או היגיון המכירות.
מקרה בוחן: כיצד החלפת מלאי הפסיקה לעכב מכירות
הלקוח — רשת עם מספר מחסנים, מכירות דרך אתר על 1C-Bitrix ונקודות קמעונאיות. המלאי ב-1С:УТ התעדכן בחלון הראווה אחת לכמה שעות, וחלק מהפריטים כלל לא נכנסו להחלפה בשל אי-התאמות במדריכי הפריטים. מנהלים תיקנו ידנית את המלאי לפני אישור ההזמנה, וקונים ביצעו הזמנות של דבר שכבר לא היה במלאי.
מה היה לפני
שיעור הביטולים מסיבת "אין במלאי" עמד על כ-12% מההזמנות המאושרות. השהיית עדכון המלאי הגיעה ל-3-4 שעות בימי שיא, והמחסנאים השקיעו 1.5-2 שעות במשמרת על התאמות ותיקונים ידניים בכרטיסי המוצרים. השגיאות במלאי הצטברו: האתר הציג מלאי, והמחסן לא אישר אותו.
מה שינו
בנו מחדש את ההחלפה: במקום ייצוא מלא של הקטלוג לפי לוח זמנים, הגדירו החלפה מצטברת לפי פריטים שהשתנו, קישרו את הפריטים למדריך אחיד והוסיפו תור לשליחה חוזרת של פריטים שלא עברו בשל אי-התאמות.
ההחלפה מתבצעת לפי אירועי שינוי מלאי ולא לפי טיימר — חלון הראווה מקבל נתונים מעודכנים בתוך דקות ספורות.
מה נהיה
שיעור הביטולים מסיבת היעדר מוצר ירד ל-2-3%. השהיית עדכון המלאי הצטמצמה משעות לדקות, התיקונים הידניים בכרטיסים כמעט נעלמו — המחסנאים הפסיקו להתאים מלאי ידנית. העומס על המחסן בשעות השיא התאזן: הזמנות מגיעות רק על מה שבאמת נמצא על המדף, וזרימת הליקוט הפכה לצפויה.
במה שונה ייצוא מלאי לפי מחסנים מחילוף כללי של פריטי מלאי
חילוף כללי של פריטי מלאי וייצוא מלאי לפי מחסנים פותרים משימות שונות ופועלים בתדירות שונה. הראשון מסנכרן את הקטלוג: שמות, מקטי"ם, מאפיינים, מחירים, שיוך למדורי הקטלוג.
הוא משתנה לעיתים רחוקות — פריט חדש נוסף, מאפיינים התעדכנו — ולכן החילוף מתבצע לפי לוח זמנים או לפי אירוע, ובהחלט סובל השהיה של שעות. מלאי לפי מחסנים הוא נתונים תפעוליים: הם מתארים כמה סחורה פיזית נמצאת במחסן מסוים ממש עכשיו, ומתיישנים בתוך דקות.
ההבדל ברמת הפירוט של הנתונים הוא עקרוני. חילוף כללי מתייחס לפריט כאל שלם: הפריט קיים בקטלוג או שאינו קיים. ייצוא מלאי לפי מחסנים מפצל את אותו פריט עד לרמת המחסן — אולם המכירה, מחסן האינטרנט, מחסן השותף, מעבר.
אותו פריט מלאי יכול להיות במלאי במחסן אחד ובאפס במחסן אחר, והאתר חייב להציג זאת ביושר, אחרת הלקוח מבצע הזמנה על סחורה שאינה נמצאת בקרבת מקום.
מכאן התדירות השונה של החילוף. את הקטלוג אפשר למשוך פעם ביום, את המלאי — כל כמה דקות, ובמבצעים פעילים ובשעות שיא לעיתים קרובות יותר. אם להריץ את המלאי באותו חילוף כבד כמו פריטי המלאי, עומס גדל על 1С ועל האתר, והנתונים בכל זאת מגיעים בהשהיה. לכן את המלאי מייצאים בזרימה מוקלת: רק מפתח המחסן, מפתח הפריט והכמות.
ההשלכה העיקרית — ההשפעה על זמינות הסחורה והשריונים. כל עוד המלאי באתר אינו תואם את המציאות, הלקוח רואה "במלאי" במקום שריק, או להפך — מאבד מכירה על פריט שנמצא במחסן. שריון שנוצר באתר חייב לעבור ל-1С ולהפחית את הכמות הזמינה, אחרת שני ערוצי מכירה ימכרו את אותה סחורה.
דווקא השילוב של "רמת פירוט לפי מחסנים + ייצוא תכוף + שריון חוזר" הופך את הקטלוג למקור מהימן של זמינות, ולא לקישוט.
ספקות טכניים נפוצים בנוגע לסנכרון מלאי
סנכרון מלאי לעיתים רחוקות נשבר "לחלוטין" — לעיתים קרובות יותר הוא נשחק בהדרגה: זמן הייצוא גדל, מופיעים פערים בין מחסנים, מנהלים מפסיקים לסמוך על המספרים בתצוגה. להלן הספקות הטכניים שעולים לרוב לפני ההתחלה, וכיצד אנו סוגרים אותם ברמת ארכיטקטורת הסנכרון.
האם השרת יעמוד בייצוא מלאי קבוע מכל המחסנים?
העומס תלוי לא בנפח הקטלוג, אלא בתדירות וברזולוציה של הסנכרון. אנו מייצאים לא את כל המערך, אלא רק פריטים שהשתנו בכל מחסן — סנכרון דלתא לפי מאפיינים ורגיסטרים. סנכרון מלא מופעל לפי לוח זמנים בחלונות לילה, והאינקרמנטלי מתבצע במנות קצרות. השרת לא חווה עומסי שיא, והנתונים בתצוגה מתעדכנים בתדירות גבוהה יותר.
מאין מגיעים כפילויות מלאי וכיצד להימנע מהן?
כפילויות מופיעות כאשר אותו פריט נכתב משני מקורות: סנכרון מ-1С ועריכה ידנית בממשק הניהול, או כאשר מפתח ההתאמה של הפריטים שגוי. אנו קובעים מקור אמת יחיד — 1С:УТ, ובצד האתר משאירים רק קריאה. ההתאמה מתבצעת לפי קוד חיצוני, ולא לפי שם, ולכן שינוי שם של מוצר לא יוצר כרטיס שני.
כיצד נלקחים בחשבון שריון מלאי והאם הם לא ייפרדו מהמחסן בפועל?
שריון הוא רגיסטר נפרד, ואסור לערבב אותו עם מלאי פנוי. אנו מעבירים שני ערכים בלתי תלויים: מלאי פיזי וכמות משוריינת, והאתר מחשב בעצמו את הכמות הזמינה למכירה. כך הזמנה שנוצרה בתצוגה מפחיתה מיד את הכמות הזמינה, אך אינה מעוותת את חשבונאות המלאי ב-1С.
מה קורה בעת כשל בסנכרון — האם נתונים הולכים לאיבוד?
הסנכרון מתבצע באופן טרנזקציוני ועם יומן: אם מנה לא עברה, היא מסומנת כלא הושלמה ומתבצעת שוב, ולא מדולגת. אנו מגדירים הפעלה מחדש אוטומטית והתראה לאחראי, ולכן כשל בערוץ לא הופך לפער שקט. השחזור הוא טעינה מחדש של מנות חסרות, ולא השוואה ידנית של כל הקטלוג.
אם נותרו שאלות בנוגע לתצורת המחסנים ולכללי השריון שלכם — תארו את המשימה, ונחזור עם הערכה ותוכנית סנכרון.
נדון במשימה שלכם להחלפת יתרות
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, עלינו להבין את סכימת ההחלפה שלכם: אילו מחסנים משתתפים, כיצד הסחורה מותאמת בין 1С:УТ ל-Bitrix, ובאיזו תדירות היתרות צריכות להגיע לאתר. זה קובע גם את שיטת ההחלפה וגם את היקף העבודה. להלן — מה אנחנו מבררים ואילו נתונים אנחנו מבקשים לצורך הביקורת.
מה אנחנו מבררים בהתחלה
- כמה מחסנים ונקודות מכירה מוסרים יתרות, והאם יש עדיפות לניכוי בעת מכירה.
- כיצד הפריטים מקושרים בין הבסיסים: לפי קוד, מק"ט או מזהה חיצוני, ומה לעשות עם פריטים ללא התאמה.
- האם נדרש ייצוא של יתרות בלבד או גם מחירים, מאפיינים ותאריכי אספקה.
- באיזו תדירות לעדכן את הנתונים: לפי לוח זמנים, לפי אירוע ב-1С או לפי בקשה מהאתר.
- מה קורה בעת אי-התאמה: האתר מציג אפס, אך במחסן יש סחורה — איזה מקור נחשב לעיקרי.
- האם יש הזמנות ורזרבות שאמורות להפחית את היתרה הזמינה בחלון הראווה.
אילו נתונים לשלוח
- ייצוא של מלאי הפריטים מ-1С:УТ ומספריית המוצרים מ-Bitrix — לפחות 20-30 פריטים לצורך השוואת ההתאמה.
- רשימת המחסנים עם המזהים שלהם בשתי המערכות.
- תיאור ההחלפה הנוכחית, אם היא כבר מוגדרת: מה מפעיל אותה, לאן היא כותבת, ובאיזו תדירות היא נופלת.
- גישות לסביבת הבדיקה של 1С ו-Bitrix — עליהן נבנה את סכימת ההחלפה ונבדוק אותה על נתונים אמיתיים, מבלי לגעת באתר הפעיל.
כיצד נחזור עם הערכה ותוכנית
ננתח את הנתונים שלכם, נבנה סכימת החלפה המתאימה למקרה שלכם ונראה היכן נקודות התורפה: התאמת מלאי הפריטים, התנגשויות יתרות בין מחסנים, והתנהגות כאשר אחת המערכות אינה זמינה. בתשובה יהיו שלבי העבודה, לוחות הזמנים להגדרה ומה תקבלו בסוף — החלפה עובדת, יומן שגיאות והוראות לצוות שלכם. תארו את המשימה — נחזור עם הערכה ותוכנית.