מחשבון משלוחים Vue.js: מדוע החישובים נשברים בקופה
תרחיש קלאסי: הלקוח בוחר עיר, לוחץ על "ביצוע הזמנה", והדף נכנס להמתנה. חישוב המשלוח בסל הקניות מתבצע באופן סינכרוני בצד השרת: בזמן שהשירות החיצוני מגיב, תהליך ה-PHP מחזיק את החיבור, וכל בקשה הבאה עומדת בתור.
בשיא — מבצע מכירות, תעבורה ערבית, דיוור — זמן התגובה גדל משניות לעשרות שניות, וחלק מהקונים פשוט סוגרים את הלשונית.
החצי השני של הבעיה גרוע מהראשון. אם שירות המשלוחים החיצוני אינו זמין, מגיב בזמן פסק או משנה את פורמט התגובה, שגיאת חישוב העלות צפה בדיוק ברגע יצירת ההזמנה — וההזמנה כלל לא נוצרת. הסל נשאר, הכסף לא יוצא, והלקוח עובר למתחרה.
הלוגים במקרה זה מציגים לא "האתר נפל", אלא מקבץ של פסקי זמן שאף אחד לא מנתח עד שההכנסות מתחילות לרדת.
מחשבון המשלוחים ב-Vue.js מעביר את החישוב לדפדפן ומנתק אותו מתהליך ביצוע ההזמנה. העלות וזמני האספקה מחושבים מחדש בזמן אמת בעת שינוי עיר, משקל או שיטת משלוח — ללא רענון הדף וללא חסימת תהליכי השרת.
ההזמנה נוצרת ללא תלות בשאלה אם השירות החיצוני הגיב באותה שנייה: אם אין תגובה, מוצב תעריף חלופי לפי טבלת התעריפים, והפער נרשם לצורך חישוב מחדש על ידי המנהל.
בהמשך נפרק כיצד זה בנוי: היכן עובר הגבול בין החישוב בצד הלקוח לבדיקה בשרת, כיצד נשמרים התעריפים במטמון ומה קורה להזמנות שכבר בוצעו בעת שינוי מדיניות התעריפים.
מה נותן העברת חישוב המשלוח לצד הלקוח
חישוב המשלוח הוא הפעולה ה"יקרה" ביותר בסל הקניות: הוא תלוי בשירות חיצוני, שעשוי להגיב במאות מילישניות או לא להגיב כלל. כאשר החישוב מחדש מתבצע בשרת בכל שינוי בסל, הממשק ממתין לתשובה, וכל אי-זמינות של שירות המשלוחים הופכת לתהליך השלמת הזמנה לא מתפקד.
העברת לוגיקת החישוב לצד הלקוח באמצעות Vue.js מסירה את השלב החוסם הזה: הממשק מגיב באופן מיידי, והפניות לשירות המשלוחים מתבצעות באופן אסינכרוני ואינן עוצרות את עבודת הסל.
תגובת הממשק והמרת סל הקניות
חישובים בצד הלקוח מסירים את ההמתנה מכל פעולה — שינוי כמות, בחירת עיר, החלפת אופן המשלוח מחושבים מחדש באופן מקומי בשברירי שנייה. המשתמש רואה את הסכום הסופי מיד, ללא "גלגלת" וללא תקיעות, ופחות עוזב את העמוד בשלב שבו קודם לכן איבד את הסבלנות.
בפועל הדבר מפחית באופן ניכר את מספר הסלים הנטושים: האדם משלים את ההזמנה עד הסוף, משום שאינו נתקל באי-ודאות לגבי העלות.
עמידות בפני תקלות של שירות המשלוחים
השירות החיצוני לא תמיד מגיב — פסקי זמן, שגיאות, תחזוקה בצד המוביל. אם החישוב תלוי בשרת, תקלה כזו מפילה את כל תהליך התשלום. בהעברה לצד הלקוח אנו שומרים את התעריפים האחרונים שהתקבלו באחסון מקומי ומציגים אותם כאפשרות חלופית, והבקשה לשירות יוצאת ברקע עם ניסיונות חוזרים.
תהליך השלמת ההזמנה ממשיך לעבוד גם כאשר ה-API החיצוני אינו זמין — ההזמנה אינה הולכת לאיבוד, והחישוב מתעדכן ברגע שהשירות חוזר.
מה זה נותן מבחינת מדדים
מהירות השלמת ההזמנה עולה בזכות היעדר בקשות סינכרוניות על כל פעולה. תגובת הממשק הופכת לצפויה ללא תלות בעומס על השרת ובמהירות השירות החיצוני. העמידות בפני תקלות מסירה סוג שלם של כשלים שבהם הסל הפסיק לחשב את העלות. בסך הכול זה פועל לטובת המרת סל הקניות: פחות הזמנות נטושות, תהליך תשלום יציב, עומס צפוי על הבקאנד.
דרכי אינטגרציה של מחשבון: השוואת גישות
הבחירה בסכימה קובעת היכן חיים התעריפים, מי אחראי לסכום הסופי ומה יקרה בעת אי-התאמה בנתונים. להלן שלוש אפשרויות עבודה שבאמת בוחרים ביניהן בפרויקטים עם 1C-Bitrix: מחישוב קל בצד הלקוח ועד שירות פרוקסי שמבודד את הלוגיקה מהפרונטאנד.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חישוב מלא בצד הלקוח | תעריפים טיפוסיים, מעט שירותי משלוח, מחירים משתנים לעיתים רחוקות | התעריפים עוברים לדפדפן — ניתן לראותם בקוד המקור; בעת שינוי תנאים נדרש ריליס של הפרונטאנד; קל לזייף את התוצאה בקונסול |
| סכימה היברידית עם ולידציה בשרת | התעריפים תלויים במלאי, במשקל, במידות, באזור; נדרשת הגנה מפני זיוף | דורשת נקודת קצה בצד Bitrix וסנכרון מפקדים; השהיית תגובה קצת גבוהה יותר |
| פרוקסי דרך שירות עצמאי | מספר מקורות תעריפים, API חיצוניים של מובילים, עומס גבוה | קו נפרד שיש לתחזק; נדרשים ניטור ולוגינג של בקשות |
חישוב בצד הלקוח: מהיר, אך ללא ערבויות
Vue.js מחשב את העלות ישירות בדפדפן לפי המפקד הטעון — התגובה מיידית, השרת אינו משתתף. הסכימה מתאימה כל עוד רשת התעריפים יציבה ואינה סוד מסחרי. ברגע שמופיעה תלות במלאי או בתנאים אישיים של הלקוח, יש לעדכן את המפקד בכל שינוי, ואת הסכום הסופי — לקבל כאקסיומה.
היברידי ופרוקסי: היכן עובר גבול האמון
בסכימה ההיברידית הממשק ב-Vue.js מציג תוצאה מקדימה, ואילו העלות הסופית מחושבת מחדש על-ידי ולידציה בשרת בצד 1C-Bitrix לפני ביצוע ההזמנה. אי-ההתאמה נרשמת בלוג — ניתן לראות מה בדיוק זויף או לא נלקח בחשבון.
שירות הפרוקסי הולך רחוק יותר: הוא אוסף תעריפים ממספר מקורות, שומר תגובות במטמון ומחזיר לפרונטאנד פורמט אחיד, ולכן הוספת שירות משלוח חדש אינה נוגעת בקוד המחשבון.
בפועל, לרוב בוחרים בהיברידי: הוא מכסה גם את מהירות הממשק וגם את שלמות ההזמנה. פרוקסי מחברים כאשר מספר מקורות התעריפים עולה על שניים או ששירותים חיצוניים מגיבים באופן לא יציב.
כיצד אנו מטמיעים מחשבון משלוחים ב-Vue.js
ההטמעה מתחילה בביקורת של הלוגיקה הנוכחית של המשלוחים: בודקים מהיכן מגיעים התעריפים, כיצד מחושבים האזורים והמשקל, והיכן החישוב משוכפל בתבניות ובמטפלים. לרוב מתגלה שחלק מהכללים מוטבעים בסקריפטים של ביצוע ההזמנה, חלקם בהגדרות של 1С, ובעת שינוי תעריף הם מתפצלים. בשלב זה מקבעים מקור נתונים אחיד ואת הנקודות שבהן יש לקרוא לחישוב.
בהמשך מתכננים את הסכימה: אילו פרמטרים מגיעים מהסל, מה נדרש משירות המשלוחים, כיצד נשמרות התשובות במטמון ומה להציג כאשר השירות החיצוני אינו זמין. את המחשבון ב-Vue.js עושים כרכיב נפרד עם חוזה ברור — הוא אינו יודע דבר על הפנימיות של ביצוע ההזמנה ומקבל נתונים דרך ממשק מוסכם.
- ביקורת הלוגיקה של המשלוחים: מפרקים תעריפים, אזורים, כללי עיגול ואי-ההתאמות הנוכחיות בין האתר למערכת החשבונאית.
- תכנון סכימת החישוב: מגדירים את מקור התעריפים, את פורמט ההחלפה, את ההתנהגות בעת כשלים ואת המטמון.
- פיתוח הרכיב: בונים את המחשבון ב-Vue.js עם חישוב מחדש ריאקטיבי בעת שינוי כתובת, משקל ואופן משלוח.
- אינטגרציה עם ביצוע ההזמנה: מחברים את הרכיב לסל, מסנכרנים את התעריף הנבחר עם נתוני ההזמנה.
- חיבור למערכת החשבונאית: מגדירים את ההחלפה כך שהעלות ואופן המשלוח ייכנסו להזמנה ללא הזנה ידנית.
- בדיקות: בודקים מקרי קצה — שירות לא זמין, מטען חריג במידותיו, מספר מחסנים, שינוי תעריף ברגע ביצוע ההזמנה.
- מסירה: מוסרים תיעוד של סכימת החישוב, הוראות לתיקון תעריפים ונוהל חזרה לאחור.
לאחר המסירה הלקוח יכול לשנות תעריפים ואזורים ללא בנייה מחדש של הרכיב — הכללים הוצאו אל ההגדרות ולא אל הקוד. אם יהיה צורך להוסיף שירות משלוחים חדש, הדבר נעשה באמצעות חיבור לאותה סכימת החלפה, ללא כתיבה מחדש של ביצוע ההזמנה.
מה הלקוח מקבל לידיו לאחר ההטמעה
לאחר הטמעת מחשבון המשלוחים ב-Vue.js בתוך 1C-Bitrix, הלקוח מקבל לא "מודול עובד", אלא ערכה שלמה שלפיה הצוות יוכל להמשיך לתפקד ללא המפתח: לעדכן תעריפים, להוסיף מובילים, ולפרוס בסביבה חדשה. להלן מה בדיוק מועבר ומדוע כל פריט נדרש.
- קוד המקור של הרכיב — אפליקציית Vue והחלק הצד-שרתי עם לוגיקת חישוב ותצוגה מופרדות. הבנייה ניתנת לשחזור מתוך המאגר, ללא חבילות "שנבנו על מכונה של מישהו אחר".
- תרשים האינטראקציה — כיצד הצד-לקוח פונה אל 1C-Bitrix, היכן נשמרות התשובות במטמון, וכיצד מטופלים פסקי זמן וחוסר זמינות של API המוביל.
- כללי התמחור — טבלת אזורים, ספי משקל, תוספות ותנאים, המוצאת אל קובץ התצורה. המנהל עורך את התעריף ללא שינוי בקוד.
- תיעוד ה-API — פורמטים של בקשות ותשובות, קודי שגיאה, והתנהגות במקרה של כשל חלקי של שירות המשלוחים.
- הוראות עדכון — סדר הפריסה, מיגרציית נתונים, וחזרה לגרסה קודמת במקרה של תקלה.
- נוהל ניטור — אילו מדדי חישוב נאספים, ובאילו ערכים מופעלת התראה.
- הרשאות ותפקידים — מי מהעובדים רשאי לשנות את כללי התמחור, ומי רואה את יומני החישובים.
בנפרד אנו מגדירים את הגבולות: מה כלול בתמיכה, ומה נחשב לעבודה נוספת. הדבר מונע מצבים שנויים במחלוקת, כאשר כעבור חצי שנה יש צורך לחבר מוביל חדש או לשנות את לוגיקת המשלוח החינמי.
מקרה בוחן: כיצד מחשבון המשלוחים ב-Vue.js האיץ את השלמת ההזמנות
הלקוח — רשת קמעונאית עם קטלוג של 40,000 פריטים והשלמת הזמנה ב-1C-Bitrix.
מחשבון המשלוחים חושב בצד השרת: בעת בחירת עיר הדף עבר רענון, התשובה הגיעה לאחר 3-6 שניות, וכאשר ה-API של אחת מחברות המשלוחים לא היה זמין, הבלוק פשוט קרס עם שגיאה — הקונה לא ראה לא זמני אספקה ולא עלות, ועזב את הסל מבלי לנטוש אותו.
מה שינו
החישוב הועבר לצד הלקוח, ל-Vue.js: טבלת התעריפים ואזורי המשלוחים נטענים פעם אחת עם הכניסה לסל, ומכאן ואילך החישוב מחדש מתבצע מקומית בעת שינוי עיר, משקל או אופן קבלת המשלוח. רכיב השרת נשאר כמקור גיבוי — אם החישוב בצד הלקוח לא התאים, ההזמנה עוברת לבדיקה ללא אובדן נתונים.
היציבות נסגרה ברמת האינטגרציה: בקשות לחברות המשלוחים עוברות דרך תור עם ניסיונות חוזרים, התשובות נשמרות במטמון, וכאשר שירות חיצוני אינו זמין, הקונה רואה את העלות וזמן האספקה התקפים האחרונים עם הערה "נאשר בעת אישור ההזמנה". שגיאה של שירות אחד אינה מפילה עוד את כל הבלוק.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן תגובת המחשבון | 3-6 שניות | פחות מ-0.3 שניות |
| כשלי הבלוק בעת תקלת שירות | קריסה עם שגיאה | הצגת המחיר התקף האחרון |
| שיעור הסלים הננטשים בשלב המשלוח | בסיסי | ירד בכרבע בערך |
| עומס על השרת בעת חישוב מחדש | בקשה לכל פעולה | בקשה אחת עם הכניסה לסל |
חודש לאחר ההשקה, שיעור ההזמנות שהושלמו מהכניסה הראשונה לסל עלה באופן ניכר, ופניות לתמיכה בנוסח "המשלוח לא מחושב" פסקו. אותה גישה ניתנת להעברה לבלוקים כבדים אחרים של השלמת ההזמנה — אם אצלכם מחשבון או כלי בחירה מאט בייצור, תארו את המשימה, ונחזור עם הערכה ותוכנית.
במה שונה חישוב בצד הלקוח מחישוב בצד השרת?
חישוב בצד הלקוח הוא כאשר עלות המשלוח מחושבת על ידי הדפדפן של המבקר: Vue.js מחזיק את מצב הסל, מחשב מחדש את הסכום בעת שינוי עיר, משקל או אמצעי משלוח, ומציג את התוצאה באופן מיידי, ללא פנייה לשרת.
חישוב בצד השרת מתבצע בצד 1C-Bitrix: הבקשה נשלחת ל-backend, זה פונה ל-API של שירות המשלוחים או לטבלאות התעריפים, ומחזיר עלות מוכנה.
ההבדל עקרוני: במקרה הראשון הלוגיקה ונתוני התעריפים נמצאים בצד הלקוח, בשני — בשרת, ומזה בדיוק תלוי עד כמה החישוב עמיד בפני זיוף ועד כמה ממשק המשתמש מגיב במהירות.
בפועל, גישות טהורות כמעט לא קיימות. רשת התעריפים, האזורים והמגבלות לפי משקל נשמרים בשרת — אסור למסור אותם לדפדפן, אחרת המבקר יזייף את העלות באמצעות כלי הפיתוח.
לעומת זאת, חישוב מחדש בעת הזנת פרמטרים מועבר לצד הלקוח: Vue.js מקבל מהשרת סט תעריפים מעודכן ומחשב מחדש באופן מיידי את האפשרויות, בלי לפנות ל-backend בכל הקשה על מקש. זו בדיוק הסכמה העובדת: השרת — מקור האמת, הלקוח — תגובת ממשק מהירה.
לכל גישה יש מגבלות משלה. חישוב בצד הלקוח נתקל בנפח הנתונים: אם התעריפים והאזורים הם במאות, ושירותי המשלוחים הם כעשרה, להעביר הכול לדפדפן זה יקר — העמוד נטען לאט יותר, וחלק מהמבקרים עוזבים.
חישוב בצד השרת מדויק ובטוח יותר, אך בכל שינוי פרמטרים דורש בקשה, ובחיבור איטי המשתמש רואה השהיה בין ההזנה לתוצאה.
הבחירה נקבעת על ידי התרחיש. אם המבקר בוחר משלוח בסל ומשנה פרמטרים לעתים קרובות — יש צורך בחישוב מחדש בצד הלקוח עם ולידציה בצד השרת בשלב הסופי של ביצוע ההזמנה.
אם החישוב חד-פעמי ותלוי ב-API חיצוני של שירות המשלוחים — מחשבים בשרת ושומרים את התשובות במטמון, כדי לא לפנות לשירות חיצוני בכל בקשה. סכמה משולבת עונה על שתי הדרישות: ממשק מהיר ותעריפים מוגנים.
ספקות טכניים נפוצים בעת אינטגרציה של מחשבון
חישוב בצד הדפדפן אינו אומר שהלקוח יכול להחליף את המחיר. המחשבון ב-Vue.js מחשב רק הערכה מקדימה בחלון הראווה, ואילו את העלות הסופית מחשבת מחדש חלק השרת של 1C-Bitrix לפני יצירת ההזמנה — הסכום הכולל תמיד נלקח מתשובת השרת, ולא ממה שהדפדפן החזיר.
אם הנתונים בסל הקניות השתנו בין החישוב לביצוע ההזמנה, ההזמנה מחושבת מחדש, והלקוח רואה את הנתון המעודכן לפני האישור.
כמה שירותי משלוח מתחברים כמודולי חישוב נפרדים עם ממשק משותף: כל שירות מספק את הזמנים שלו, מגבלות מידות ומשקל, אזורים ותוספות. חלון הראווה מקבל רשימה מנורמלת של אפשרויות ומציג אותן בבלוק אחד, ולכן הוספת שירות חדש היא מודול חדש, ולא כתיבה מחדש של טופס ביצוע ההזמנה.
התעריפים משתנים — האם יהיה צורך לבנות מחדש את הפרונטאנד בכל פעם?
לא. רשתות התעריפים, האזורים והמגבלות נשמרים בהגדרות בצד השרת ומועברים למחשבון דרך API. עדכון תעריפים הוא עריכת נתונים וכללים, ולא שחרור גרסה של הפרונטאנד: השינויים נקלטים בחישוב הבא ללא בנייה מחדש וללא פריסה חוזרת של חלון הראווה.
מה יקרה אם שירות המשלוח לא יהיה זמין ברגע החישוב?
המחשבון אינו חוסם את ביצוע ההזמנה. השירות שאינו זמין מוחרג מרשימת האפשרויות, האחרים ממשיכים לחשב, והלקוח רואה הודעה ברורה במקום טופס תקוע. שגיאות חישוב נרשמות בלוג, כדי שניתן יהיה לתקן את האינטגרציה לפני שהקונים יבחינו בכך.
כיצד נבדקת תקינות החישובים לאחר האינטגרציה?
מריצים תרחישי בקרה: ערים שונות, משקל ומידות, ערכי גבול של אזורים, שירותים עם תוספות. תוצאות המחשבון מושוות לחישוב ב-1С — אי-התאמה בכל תרחיש נחשבת לפגם ומטופלת לפני המסירה.
בואו נדון במשימה שלכם של מחשבון משלוחים
כדי לחזור עם הערכה ותוכנית יישום, ולא עם מילים כלליות, עלינו להבין את הלוגיקה הנוכחית שלכם למשלוחים. תארו כיצד מחושבת כעת העלות: לפי אזורים, משקל, מידות, סכום הזמנה או דרך API של שירותי משלוחים, מאיפה מגיעים התעריפים והיכן הם נשמרים.
ככל שהנתונים הראשוניים מפורטים יותר, כך ההערכה של היקף העבודה מדויקת יותר וכמות ההנחות בתוכנית קטנה יותר.
בהמשך אנו מנתחים את התרחישים שלרוב שוברים את החישוב: מספר מחסנים, זמינות חלקית של מוצרים, משלוח חינם מעל סף מסוים, איסוף עצמי, הגבלות לפי אזורים. בנפרד נבחן כיצד המחשבון ב-Vue.js יקבל נתונים מ-1C-Bitrix ויחליף מידע עם 1С, כדי שהמחירים והמועדים לא יתפצלו בין חלון הראווה להזמנה.
מה כדאי לשלוח כדי להתחיל:
- כללי החישוב הנוכחיים של המשלוחים וטבלאות התעריפים;
- רשימת שירותי המשלוחים ודרכי האינטגרציה איתם;
- דוגמאות להזמנות שבהן החישוב פעל באופן שגוי;
- דרישות להצגת מועדים ועלות בכרטיס המוצר ובסל הקניות;
- הגבלות לפי אזורים, משקל ומידות של משלוחים;
- גישות לסביבת בדיקה או תיאור הסביבה.
לפי הנתונים האלה נחזור עם הערכה של היקף העבודה, תוכנית יישום בשלבים והרכב הצוות. אם חלק מהלוגיקה עדיין לא קבוע — ננתח אותה בשיחה ונציע גרסת חישוב עובדת. תארו את המשימה — נדון בפרטים ובלוחות הזמנים.