הגדרת משלוח טרנזיט ממחסן הספק ב-1C-Bitrix

מדוע משלוח טרנזיטיבי ב-Bitrix נשבר במשלוחים חלקיים

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

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

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

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

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

מה נותנת האינטגרציה עם מחסני הספקים

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

יתרות נלקחות מהמקור, ולא מהטבלה

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

ריזרב ברגע ביצוע ההזמנה

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

מועד האספקה מחושב לפי כללים

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

התראות לקונה נשלחות מעצמן

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

מצבי העברת הזמנות לספק: השוואת אפשרויות

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

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

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

שלבי הגדרת המשלוח: מהאודיט ועד ההעברה לתמיכה

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

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

Hmm — I accidentally left Russian. Must correct: "דווקא הוא זה שמייצר הזמנות תקועות."

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

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

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

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

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

הרכב ההגדרות והתיעוד הנמסרים

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

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

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

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

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

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

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

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

מה השתנה בגדלים מדידים

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

כיצד לנהל הזמנה כשהספק שולח בכמה מנות?

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

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

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

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

שאלות טכניות נפוצות על העברת הזמנות

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

היתרות התפצלו — מה יראה הקונה?

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

המועד נדחה לאחר ביצוע ההזמנה

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

ביטול לאחר שילוח — כיצד לא לאבד את המוצר?

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

כיצד מחושב המועד במשלוח חלקי?

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

נדון בתוכנית האספקה שלכם ונעריך את היקף העבודה

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

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

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

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