למה מחשבון המשלוחים באתר מחשב לא נכון
מחשבון המשלוחים כמעט תמיד אינו תואם את המציאות, לא בגלל שגיאה בנוסחה, אלא בגלל הנתונים שלפיהם הוא מחשב.
טבלת התעריפים של המוביל משתנה לעתים קרובות יותר מאשר מספיקים להעביר אותה לקוד: בזמן שהמנהל מתקן ידנית את המחירון בממשק הניהול, השירות כבר הוסיף תוספת דלק או שרטט מחדש את האזורים.
בסופו של דבר חישוב עלות המשלוח באתר מציג סכום אחד, ובתעודת המשלוח בעת השילוח צץ סכום אחר — ואת ההפרש מסביר ללקוח נציג שירות, ולא האתר.
הסיבה השנייה — מידות. הלקוח מזין "קופסה, בערך קטנה", והמוביל מחשב משקל נפחי לפי שלושה ממדים ומשווה אותו למשקל בפועל. אם המחשבון לוקח בחשבון רק את המשקל, חבילה בגודל 40×30×20 ס"מ עם חומר מילוי קל תשלח במחיר של קילוגרם, והמוביל יוציא חשבונית לפי משקל נפחי.
בהמשך — אזורים וזמנים: חלק מהיעדים נשלחים בתעריף ראשי, חלק בתעריף מקומי, והפרברים בכלל מחושבים בנפרד.
הסיבה השלישית — הזנה ידנית. המנהל מזין ידנית עיר, מיקוד או אופן קבלה, ובמקום שבו נדרש קוד מדויק של יישוב, מופיע "בערך ליד".
אינטגרציה של שירות המשלוחים לפי ספר העזר וה-API מסירה את השכבה הזו: הכתובת מנורמלת, האזור נקבע אוטומטית, התעריף נשאל ברגע ביצוע ההזמנה, ולא נלקח ממטמון בן שבוע.
בנפרד יש לציין את אי-ההתאמה בתוספות התשלום — ביטוח, איסוף מנקודת מסירה, משלוח עד הדלת, מטען חורג. אם המחשבון לא מתחשב בהן, שגיאות בחישוב המשלוח מצטברות בכל הזמנה וצצות כבר במחלקת החשבונאות. מנתחים כיצד זה נסגר ברמת ארכיטקטורת החישוב.
איך עובד מחשבון המשלוחים עם אינטגרציה של СДЭК ו-Почта России
החישוב מבוסס על שני מעגלים בלתי תלויים: מדריך יישובים ותעריפים חיים. הראשון נשמר במטמון לזמן ארוך — רשימת הערים והמיקודים משתנה לעתים רחוקות. השני נשלף בכל בקשה עבור כל סל קניות, מכיוון שהתעריף תלוי במשקל, במידות, בערך המוצהר ובמצב הנבחר.
אינטגרציה של СДЭК ואינטגרציה של Почта России בנויות באופן שונה: אצל שירות אחד התעריף מחושב לפי משקל וירטואלי וצפיפות המטען, ואצל השני — לפי סוג המשלוח והאזור. מחשבון המשלוחים ממיר את שתי התשובות למבנה אחיד, כדי שהחנות תוכל להשוות אפשרויות לפי שדות זהים.
נרמול תשובות השירותים
כל תשובת API של שירותי המשלוחים ממופה למודל משותף: זמן באקלים ימים, סימון "עד הדלת או עד נקודת איסוף", מגבלות מידות. זה מסיר את הכאב העיקרי — כאשר ה-frontend מתחיל להסתעף לפי שם המוביל.
הזמנים מחושבים מחדש בהתחשב בתאריך המשלוח ובסופי שבוע, אחרת "3 ימים" ביום שישי וביום שני משמעם דברים שונים.
מטמון וירידה בביצועים
התעריפים נשמרים במטמון לפי מפתח "מסלול + משקל + מחלקת מידות" לפרק זמן קצר. זה מצמצם בקשות חוזרות בעת מעבר על הסל ושומר על החישוב בטווח של שנייה. אם השירות לא הגיב, אנו מציגים את התעריף הידוע האחרון עם הערה "מקדמי" — הלקוח לא מאבד את הסל בגלל תקלה של מישהו אחר.
מטענים חריגים ואזורים מרוחקים
פריטים כבדים ונפחיים עוברים לענף נפרד: חלק מהשירותים לא מקבלים אותם, וחלק מחשבים לפי volumetric weight. אזורים מרוחקים מסומנים כ"משלוח עד נקודת איסוף" — אחרת הלקוח בוחר שליח שאינו קיים שם.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שאילתה מקוונת ל-API של השירותים | תעריפים עדכניים, שינויים תכופים | תלות בזמינות של שירות חיצוני |
| מדריך תעריפים עצמאי | מסלולים יציבים, עומס גבוה | מתיישן בעת שינוי מחירון המוביל |
| היברידי: מטמון + מקוון | רוב חנויות האינטרנט | נדרשת לוגיקת ירידה בביצועים וגיבוי |
СДЭК ו-Почта России מספקים תעריפים דרך ממשקים רשמיים, ולכן אין צורך לתחזק את החישוב ידנית.
שלבי הטמעת מחשבון משלוחים באתר
הטמעת מחשבון משלוחים מתחילה לא בקוד, אלא בביקורת של הלוגיסטיקה הקיימת: אילו שירותים כבר בשימוש, כיצד מחושבים התעריפים, היכן מנהלים מחשבים מחדש את העלות ידנית ובאילו הזמנות החישוב סוטה מהמציאות.
בשלב זה מקבעים את הכללים — מאיפה מגיעים המשקל והמידות, כיצד נלקחות בחשבון אזורים, תשלום בעת מסירה, שווי מוצהר ומדידה. ללא כללי תעריפים מוסכמים, הגדרת חישוב המשלוח הופכת לתיקונים אין-סופיים לאחר ההשקה.
מכאן העבודה מתנהלת בשלבים, שכל אחד מהם מסתיים בתוצאה ניתנת לבדיקה:
- ביקורת לוגיסטית ואיסוף דרישות — מנתחים הזמנות קיימות, מאתרים פערים בין העלות המחושבת לעלות בפועל, ומקבעים את רשימת השירותים ואמצעי המשלוח.
- אישור כללי תעריפים — מתארים מטריצת «אזור / משקל / מידות / זמן», כללי עיגול, ספי משלוח חינם ותוספות. את הכללים מאשר הלקוח לפני תחילת הפיתוח.
- תכנון האינטגרציה — קובעים אילו נתונים נשלחים לשירותי המשלוח, כיצד נשמרות התשובות במטמון, ומה מציגים ללקוח אם השירות אינו זמין או החזיר שגיאה.
- הגדרת החישוב — מחברים מאגרי ערים ונקודות מסירה, מקשרים את סל הקניות לתעריפים, ומגדירים את התנהגות המחשבון בעת שינוי הרכב ההזמנה.
- בדיקת האינטגרציה — מריצים הזמנות אמיתיות: משקלים שונים, מטענים חריגים, אזורים מרוחקים, מספר שירותים בהזמנה אחת. משווים את החישוב לתעודות המשלוח בפועל.
- טיפול בכשלים — בודקים מה קורה כאשר השירות אינו זמין: הלקוח רואה הודעה ברורה, ההזמנה אינה הולכת לאיבוד, והמנהל מקבל התראה.
- מסירת תיעוד — מוסרים את תרשים האינטגרציה, מטריצת התעריפים, הוראות לתיקון הכללים ותקנון עדכון מאגרי הנתונים.
נקודת המפתח היא בדיקה על הזמנות אמיתיות ולא על נתוני בדיקה: דווקא שם עולים פערים במשקל נפחי ובמטענים חריגים. לאחר המסירה הלקוח יכול לשנות ספים ותוספות בעצמו, ללא פנייה למפתח. תארו את הלוגיסטיקה שלכם — נחזור עם הערכה ותוכנית לפי שלבים.
במה שונה החישוב דרך API של СДЭК מחישוב דרך Почта России?
חישוב דרך API של СДЭК בנוי סביב אזורי משלוח: השירות מחזיר תעריף עבור כיוון ספציפי "עיר השולח → עיר הנמען", והמחיר תלוי באיזה אזור נפל היישוב. Почта России פועלת אחרת — התעריף מחושב לפי דרגת היישוב ומשקל המשלוח, ולא לפי זוג ערים.
בגלל זה הזמנה זהה בהרכבה מחושבת במקרה אחד "מנקודה לנקודה", ובמקרה אחר — "מאזור לאזור", ומחשבון המשלוחים חייב לתמוך בשני התרחישים, ולא להתאים אחד לשני.
גם המגבלות על משקל ומידות שונות. СДЭК מחזיר חישוב לפי משקל בפועל ומשקל נפחי, ומתייחס בנפרד לחריגות מידות ולמגבלות על סכום שלושת הממדים. Почта России מחשבת לפי משקל בצעדים וחותכת באופן קשיח משלוחים החורגים מהמסה והגודל המרביים.
אם לא מפרידים בין הכללים האלה בקוד, הלקוח יראה מחיר שהשירות לאחר מכן לא יקבל — וההזמנה תיכשל כבר בשלב ביצוע ההזמנה, ולא בסל הקניות.
זמני עדכון התעריפים — הפער השלישי. אצל СДЭК התעריפים ואזורי המשלוח משתנים לעתים קרובות יותר ומגיעים יחד עם תגובת השירות, ולכן אסור לשמור אותם בזיכרון מטמון לזמן ארוך. אצל Почта России רשת התעריפים יציבה יותר, אך מתעדכנת בחבילות, ובין מהדורות ייתכן פיגור.
ההבדלים בחישוב המשלוח כאן מתבטאים בתדירות שבה פונים ל-API ובמשך הזמן שבו שומרים את התגובה בזיכרון מטמון: זיכרון מטמון ארוך מדי נותן מחיר מיושן, קצר מדי — בקשות מיותרות ועלייה בזמן התגובה של הסל.
החזרת שגיאות — הקטע הכי פחות מוערך. API של СДЭК מחזיר קודים מובנים וסיבות סירוב ברורות, API של Почта России מחזיר לעתים קרובות סימן שגיאה כללי, וצריך לפענח אותו לפי הקשר הבקשה.
לכן במחשבון נדרש שכבת נרמול: שני השירותים מיושרים למערכת מצבים אחת — "מחושב", "לא זמין לכיוון הזה", "חריגה מהמגבלות", "השירות לא זמין". אז הממשק לא תלוי בכך איזה שירות השיב, והלקוח רואה סיבה ברורה במקום בלוק ריק עם מחיר.
מסקנה מעשית: להשוות שני שירותים לפי בקשה אחת זה חסר טעם — יש להם מודל תמחור שונה, מגבלות שונות ומשמעת תגובות שונה. המחשבון נבנה כך שכל שירות מחושב לפי הכללים שלו, ובסופו של דבר המזמין מקבל אפשרויות ברות השוואה עם זמנים הוגנים וסיבות סירוב ברורות.
מקרה בוחן: כיצד מחשבון המשלוחים קיצר את זמן ביצוע ההזמנה
לפני ההטמעה, עלות המשלוח חושבה על ידי מנהל: בקשה עם כתובת ומשקל נשלחה ידנית לאזור האישי של המוביל, התשובה חזרה בתוך יום עבודה, והלקוח כל אותו הזמן לא ראה לא מחיר ולא זמן אספקה.
בעומסי שיא תור הבקשות גדל, חלק מהסלים התקררו, וההזמנה אבדה לא בגלל המוצר, אלא בגלל אי-ודאות בנוגע למשלוח.
מה שינו
נבנה מחשבון משלוחים שבעמוד ביצוע ההזמנה פונה בעצמו ל-API של המובילים ומחזיר ללקוח מחיר וזמן אספקה מדויקים. לוגיקת החישוב הועברה לשרת: הדפדפן שולח רק כתובת והרכב הסל, ואילו משקל, מידות ותעריף מוזנים מכרטיסי המוצרים ומספר העזר של המוביל.
- חישוב מול שני מובילים בו-זמנית — СДЭК ו-Почта России — עם בחירת נקודת מסירה על המפה.
- מטמון תעריפים בצד השרת: בקשות חוזרות ליעדים פופולריים אינן פוגעות ב-API של המוביל ומגיבות באופן מיידי.
- תרחיש גיבוי: אם השירות החיצוני אינו זמין, הלקוח רואה טווח מחיר וזמן אספקה, וההזמנה עוברת למנהל עם סימון לבדיקה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן ביצוע ההזמנה | 20-40 דקות בהשתתפות מנהל | 2-3 דקות ללא מנהל |
| דיוק החישוב | חישוב מחדש ידני, פערים במקרה של מטען חריג | מחיר וזמן אספקה תואמים לשטר המטען הסופי |
| שיעור ההזמנות עם חישוב מחדש של המשלוח | כל בקשה שנייה | מקרים בודדים |
| עומס על המנהלים | חישוב ידני לכל סל | רק משלוחים שנויים במחלוקת ובלתי סטנדרטיים |
האפקט המרכזי — לא מהירות התגובה כשלעצמה, אלא העובדה שהלקוח מקבל החלטת רכישה כשהוא כבר רואה את הסכום הסופי. הפערים בין המחיר באתר לזה שבשטר המטען, שבעבר צפו לאחר ביצוע ההזמנה וחייבו התכתבות, נעלמו: התעריף מחושב לפי אותם כללים כמו אצל המוביל.
החישוב מבוסס על ה-API הרשמיים של המובילים — СДЭК ו-Почта России — עם טיפול בשגיאות ובזמני פסק זמן, כדי שאי-זמינות של שירות חיצוני לא תחסום את ביצוע ההזמנה.
מה אם המוביל ישנה את התעריפים? רשת התעריפים וכללי החישוב הועברו לקונפיגורציה, ולא מוטבעים בקוד — עדכון אורך דקות ללא שחרור גרסה.
מה אם למוצר אין מידות? המחשבון מזין ערכי ברירת מחדל ומסמן את ההזמנה לבדיקה, במקום להציג מחיר שגוי.
ספקות לפני הטמעה: תאימות, הגירה, חזרה לאחור
הסיכון העיקרי בהטמעת מחשבון משלוחים אינו החישוב עצמו, אלא החיבור למה שכבר עובד באתר. אם יש לכם חישוב עצמאי לפי אזורים או תעריפים קבועים במסד הנתונים, אין צורך לעקור אותו: מעטפת מעל הלוגיקה הקיימת שומרת על התנהגות מוכרת של סל הקניות, והמודול החדש מתחבר לצידו ומופעל באמצעות דגל.
התעריפים הישנים נשארים כמצב גיבוי — אם השירות החיצוני אינו זמין, הקונה רואה מחיר לפי האזור הידוע האחרון, ולא בלוק ריק.
מה אם כבר קיים חישוב משלכם? משאירים אותו כמקור תעריפים כברירת מחדל, ומעבירים ל-API של СДЭК ושל Почта России רק את היעדים שבהם נדרש מחיר מדויק לפי משקל ומידות. כיצד מעבירים נתונים?
היסטוריית הזמנות ומדריך האזורים מיוצאים לפורמט ביניים, נבדקים שורה אחר שורה ונטענים למבנה החדש — פערים בכל פריט מתועדים בדוח. האם ניתן לחזור לאחור? כן: התצורה מנוהלת בגרסאות, ומעבר חזרה לחישוב הקודם הוא תיקון אחד ללא פריסת קוד חדש.
אילו הרשאות נדרשות לאינטגרציה?
מפתח API של СДЭК לבדיקות ולעבודה, חוזה ופרטי התחברות לחשבון האישי של Почта России, גישה לממשק הניהול של האתר לצורך עריכת תבנית סל הקניות ולמאגר הקוד. סודות נשמרים במשתני סביבה ולא בקוד — בעת החלפת מפתח מתקנים ערך אחד.
בסיום אתם מקבלים: תרשים של זרימת החישוב עם נקודות כשל, תצורת תעריפים ואזורים, מדיניות מטמון לתשובות API, סקריפט הגירה של מדריכים, הוראות למעבר ולחזרה לאחור, רשימת בדיקות לפני הפעלה ותיעוד משלוחים לצוות התמיכה.
תארו את החישוב הנוכחי ואת מחסנית הטכנולוגיות של האתר — נחזור עם הערכה ותוכנית עבודה.
לוחות זמנים להטמעת מחשבון משלוחים: שלבים ואבני דרך
לוחות הזמנים אינם תלויים במספר המובילים, אלא במצב הקטלוג ובמידת הצפיות של ה-API שלהם. אם למוצרים כבר יש מידות ומשקל, והמחסן הוא אחד — התכנון וההגדרה מתקדמים מהר יותר.
אם המשקל מחושב לפי נוסחה מתוך המאפיינים, וחלק מהפריטים נשלחים מכמה נקודות, מתווסף שלב נרמול הנתונים, והוא גם לרוב קובע את לוח הזמנים הכולל.
השלבים מתבצעים בחפיפה חלקית: ההגדרה מתחילה בעוד שכללי החישוב מסוכמים, ובדיקות לפי אזורים מופעלות לפני שהממשק מוכן לחלוטין. לכן לוח הזמנים הכולל — בדרך כלל 3–5 שבועות, ולא סכום שורות הטבלה.
בנפרד יש להקצות זמן לגישות: קבלת מפתחות ייצור וסיכום חוזה עם המוביל מתבצעים במקביל ולעיתים אורכים יותר מאשר הפיתוח עצמו.
СДЭК ו-Почта России מחזירים ספרים ותעריפים באופן שונה, ולכן החישוב נבנה דרך שכבה פנימית אחודה: המוביל מתחבר כמודול נפרד, והוספת מוביל שלישי אינה מחייבת לכתוב מחדש את הסל. זה גם מפשט את החזרה לאחור — בעת תקלה ב-API אחד המחשבון ממשיך לחשב לפי האחרים.
