האם להתחבר ישירות לחברת שליחויות או להשתמש בפלטפורמת משלוחים?

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

האם גישה ל-API של מוביל היא אוטומטית ברגע שיש חשבון?

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

למה הזמנת איסוף צריכה אידמפוטנטיות?

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

אילו כללים עסקיים שוברים תהליכי משלוח בישראל?

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

מאיזה נפח שווה לבנות אינטגרציה עם חברת שליחויות?

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

חיבור לחברות שליחויות

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

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

המספר שקובע: כמה מובילים

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

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

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

זה בדיוק אותו היגיון שמוביל למעקב אחרי דואר ישראל - ולא במקרה. רוב העסקים לא שולחים במוביל אחד.

מה שצריך לברר לפני שמתמחרים - וזה לא טכני

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

ארבע שאלות, בכתב:

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

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

ארבע הפעולות - וההבדל ביניהן

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

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

אידמפוטנטיות - כאן זה קריטי

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

ההגנות זהות למדבקות משלוח:

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

הכללים העסקיים ששוברים תהליכים

אלה לא באגים - הם מציאות שהקוד חייב לדעת עליה.

שעת גזירה

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

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

אזורי שירות

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

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

חגים

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

מה שחייב להיות

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

מתי לא לבנות

שאלה ששווה לשאול לפני שמתחילים: כמה משלוחים ביום?

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

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

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

צ'קליסט

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

חיבור לחברות שליחויות בישראל: אינטגרציה ישירה או פלטפורמת משלוחים

עיקרי הדברים