מדוע מחשבון 1С-Битрикс מאבד פניות בשלב הסופי
רוב המחשבונים מאבדים פניות לא בחישוב אלא בשלב האחרון. הלקוח עובר את כל השלבים, רואה את הסכום הסופי, לוחץ על «שלח» — ולא מקבל דבר: לא מכתב ולא אישור. לפעמים המכתב בכל זאת מגיע, אבל ריק: הסכום נמצא, אך פרמטרי החישוב שמהם הורכב לא נכללו בו. לבעלים זה נראה כמו «המחשבון עובד», בעוד המשפך מתרוקן בשקט.
שתי הסיבות הנפוצות ביותר הן אובדן מצב בין שלבים ובדיקת תקינות בדפדפן בלבד. ערכי ביניים נשמרים בדרך כלל בזיכרון העמוד: הלקוח פתח את החישוב בכרטיסייה חדשה, חזר אחורה או רענן את העמוד — ובשלב הסופי נשלחת קבוצת שדות ריקה.
אם בדיקת שדות החישוב קיימת רק בסקריפטים בצד המבקר, השרת מקבל כל דבר: כמויות אפס, ערכים שליליים, פרמטרים חובה לא מלאים.
סוג שלישי של כשלים הוא שקט. הבקשה יוצאת, המטפל עונה «תודה», אך אירוע הדואר ב-1С-Битрикс לא פעל: תבנית המכתב איבדה משתנים, כתובת הנמען נשארה כתובת בדיקה, השליחה דרך שרת הדואר חסומה. הלקוח רואה תודה, המנהל לא רואה מכתב. תקלה כזו לא נתפסת בעין — רק ביומן השגיאות ובהשוואה: כמה חישובים הושלמו, כמה מכתבים באמת נשלחו.
אנחנו מתחילים בניתוח מלא של מסלול הפנייה: חישוב העלות באתר, שליחת הטופס למייל, הגעת המכתב לתיבת המנהל. לאחר מכן נבחן כיצד כל אחד מהחיבורים הללו נסגר.
מה משתנה כשהחישוב נעשה בשרת ולא בדפדפן
כשהנוסחה נמצאת בסקריפט של הדפדפן, התוצאה קיימת רק בזיכרון הכרטיסייה. רעננת את העמוד, איבדת את הרשת, עברת בין מכשירים — החישוב נעלם, המכתב עם הפנייה לא נשלח, ואין במה לשחזר מה בדיוק חישב הלקוח: במסד הנתונים אין לא פרמטרי קלט ולא תוצאה.
חישוב עלות בצד השרת מעביר את נקודת הכשל. הפרמטרים עוברים לצד 1С-Битрикс, הנוסחה ומדריכי הנתונים נמצאים בקונפיגורציה, התוצאה מחושבת ונרשמת במסד הנתונים לפני שליחת המכתב.
ניתוק הקשר אצל הלקוח כבר לא משמעו אובדן הפנייה: הטופס מרים חישוב שלא הושלם ומשלים אותו, והמנהל רואה את הפנייה גם אם המכתב לא הספיק להישלח.
אמינות החישוב מפסיקה להיות תלויה במכשיר ובדפדפן. גרסה אחת של הנוסחה לכל המבקרים, טווחים ומקדמים נערכים בממשק הניהול בלי לבנות מחדש את צד הלקוח, ואין אפשרות להחליף את הסכום בכלי מפתחים. נעלם סוג שלם של כשלים — אי-התאמה בין «מספר אחד על המסך למספר אחר במכתב» ופניות ריקות בלי פרמטרים.
מהירות התגובה של הטופס היא גם משימה שרתית. מדריכי הנתונים נשמרים במטמון, שאילתות כבדות מחושבות פעם אחת, והתשובה מגיעה בזמן שהמבקר לא מבחין בו: הטופס לא נראה תקוע. המנהל מקבל מכתב עם פרמטרים מוכנים ותוצאה, ואין צורך לחשב מחדש ידנית — התשובה הראשונה ללקוח יוצאת מהר פי כמה.
הדבר נבדק בקבלה בלי ניחושים: התוצאות מותאמות מול טבלת ייחוס לפי קבוצת פרמטרים, החיבור מנותק בכפייה — הפנייה חייבת להישאר במסד הנתונים עם סכום תקין.
שיטות חישוב: שרתי, דפדפני והיברידי
שיטת החישוב קובעת היכן מחושבים ערכי הביניים, באיזו תדירות הטופס פונה לשרת ומה יראה הלקוח אם המחיר במדריך הנתונים התעדכן. בטופס עם חמישה שדות ההבדל אינו מורגש; במחשבון עם פרמטרים תלויים הבחירה בשיטה קובעת את מהירות התגובה ואת מספר החישובים שהשרת עומד בהם בשעת שיא.
סכימה היברידית היא פשרה טיפוסית: הדפדפן מחשב עלות מקדמית לפי מקדמים מהטופס ומחשב אותה מחדש באופן מיידי כשהשדות משתנים, והשרת בודק את הנתונים, חוזר על החישוב לפי מדריכי נתונים עדכניים ושולח את המכתב. הלקוח רואה תגובה בלי השהיה, ובמכתב מופיע סכום שאושר בהיגיון השרת.
| אפשרות | מתי מתאימה | במה מוגבלת |
|---|---|---|
| דפדפני | תעריפים קבועים, מדריך הנתונים משתנה לעיתים רחוקות, נדרשת תגובה בלי פנייה לשרת | מחשב לפי מקדמים מהטופס: לאחר עדכון מחירים הלקוח רואה סכום מיושן, ואין דרך להבטיח בדיקת נתונים והגנה מפני החלפה |
| שרתי | כללים מורכבים, תלות במלאי ובתנאים אישיים | כל חישוב מחדש הוא פנייה לשרת; בלי מטמון והגבלת תדירות בקשות הטופס מאט בחיבור איטי |
| היברידי | מחשבון ציבורי עם תגובה מיידית ושליחת התוצאה למייל | כללי החישוב נמצאים בשני מקומות: אי-התאמה בין גרסאות נותנת סכומים שונים בטופס ובמכתב |
המגבלה של חישוב דפדפני היא שהוא רואה רק נתונים שכבר נטענו בטופס, ואינו יודע על מלאים ועיגולים במערכת החשבונאית. לכן חישוב מחדש בשינוי שדות נתלה על סיום הקלדת השדה או על השהיה קצרה, ולא על כל הקשה: אחרת הטופס מציף את השרת בבקשות שאף אחד לא קורא.
שלבי היישום: מביקורת טפסים ועד בדיקת מסירת מכתבים
סדר העבודה קבוע: קודם מנתחים את מה שכבר מותקן באתר, אחר כך מתכננים את החישוב, ורק לאחר מכן נוגעים בשליחה. סדר הפוך נותן מחשבון יפה עם מכתבים שנכנסים לספאם או מגיעים ריקים.
- ביקורת טפסים באתר. אוספים את כל נקודות איסוף הנתונים — טפסי יצירת קשר, פניות, הרשמות. בודקים אילו שדות באמת מגיעים לנמען, והיכן בדיקת התקינות מכניסה זבל. המחשבון לאחר מכן משתלב בסכימה הזו, ולא חי במקביל.
- סכימת חישוב. מתארים את הנוסחה, קבוצת המקדמים, תנאי הגבול והתנהגות בנתונים חסרים. קובעים מה מחושב בדפדפן ומה חייב להיות מחושב מחדש בשרת: אחרת התוצאה במכתב תסתור את מה שהלקוח ראה.
- אב טיפוס והשוואת היגיון. מריצים את החישוב על קבוצות נתוני מקור בקרה ומשווים למה שהמנהל שלכם מחשב ידנית. כמה אחוזי אי-התאמה נתפסים כאן בזול יותר מאשר במאה פניות שכבר נשלחו.
- הגדרת התראות דואר. תבניות מכתבים ללקוח ולנמענים פנימיים, עותקים, קובץ מצורף עם תוצאת החישוב. בנפרד — דומיין השולח ורשומות SPF, DKIM, DMARC: בלעדיהם המכתב נכנס לספאם ללא קשר לעיצוב.
- בדיקת מסירת מכתבים. שליחות בדיקה לתיבות של ספקים שונים: קריאות בתוכנות דואר, נפילה לספאם, תקינות קבצים מצורפים וקירילית בנושא.
- מסירה והוראות. מוסרים תיעוד: היכן לשנות מקדמים, איך להוסיף נמען, מה לבדוק ביומנים אם המכתב לא נשלח. בהמשך עריכת תעריפים ושדות לא דורשת לכתוב מחדש את המחשבון.
תיעוד והגדרות שנשארים אצלכם
אנחנו מוסרים לא רק מחשבון עובד על 1С-Битрикс, אלא גם כל מה שצריך כדי לשנות אותו בלעדינו. מערך המסמכים סוגר שלוש שאלות: איך מחושבת התוצאה, לאן היא נשלחת ומה לעשות אם המכתב לא הגיע.
הארטיפקטים נמצאים במאגר הקוד לצד הקוד — בעת פיתוח נוסף הם מתעדכנים יחד איתו, ולא חיים כקובץ נפרד אצל המנהל.
- כללי חישוב — נוסחאות, מקדמים, טווחים וסדר עיגול בצורת טבלה: לפיה כל תוצאה נבדקת ידנית תוך שתי דקות.
- סכימת זרימת נתונים — מקלט בטופס ועד רישום הפנייה ושליחת המכתב, עם נקודות בדיקת תקינות, תיעוד וטיפול בשגיאות.
- תבנית מכתב עם התוצאה — סימון וחלופה טקסטואלית, רשימת החלפות, הגדרות נושא וכתובת השולח.
- נוהל טיפול בפניות — מי מגיב ובאיזה פרק זמן, מה לעשות במקרה של כפילות, מכתב שלא נמסר, או כשל של שירות הדואר.
- הוראות למנהל מערכת — כיצד להוסיף שדה, לשנות מקדם, לצפות ביומן השליחות ולהוציא מחדש תבנית בלי לערוך קוד.
- תיאור קונפיגורציה — היכן נשמרים מפתחות שירות הדואר, אילו הרשאות דרושות לתפקיד מנהל המערכת, וכיצד להפעיל שליחה חוזרת.
- תרחישי קבלה — מערך בדיקות שלפיהן תוכלו בעצמכם להשתכנע בנכונות החישוב לאחר השחרור ובשדרוג הפלטפורמה הבא.
את המסמכים אנו כותבים בשפת הצוות שלכם: בלי תלות במפתח מסוים, עם דוגמאות מילוי. אם לאחר המסירה משתנים כללי החישוב או כתובת הנמען, התיקון נעשה במקום אחד, והחישוב עם המכתב נשארים מתואמים.
דוגמה ליישום: חישוב עלות הזמנה אצל יצרן
ממה התחלנו
חברת ייצור חישבה הזמנות ידנית: המנהל בירר חומר, עובי ותפוצה, ואז איחד מחירים לפי מחירון של יותר מ-60 פריטי מלאי. חישוב אחד ארך עד חצי שעה, ובימי שיא — יותר מכך באופן ניכר, וחלק מהלקוחות עברו למי שמגיב מהר יותר.
הטופס באתר שלח מכתב דרך שירות חיצוני, ותוצאת החישוב לא נשמרה בשום מקום — אם המכתב לא הגיע, לא היה במה לשחזר את הפנייה.
מה שינינו
את היגיון החישוב העברנו למחשבון על 1С-Битрикс: הלקוח בוחר פרמטרים של המוצר, רואה מיד עלות ומועד, והתוצאה נשלחת במכתב ובמקביל נשמרת במסד הנתונים יחד עם כל הפרמטרים שנבחרו.
את השליחה שינינו כך שהמכתב נוצר בצד האתר ומשוכפל לפנייה — הפנייה לא הולכת לאיבוד גם אם שירות הדואר החיצוני מחזיר שגיאה. המנהל מקבל פנייה עם סכום מוכן ולא שואל מחדש את מה שהלקוח כבר ציין בעצמו.
מדדים לפני ואחרי
- שיעור הפניות שנמסרו — מכ-70% ל-99%: הפסדים בשליחה כמעט נעלמו.
- הזמן מהחישוב ועד תגובת המנהל — מכמה שעות ל-15–20 דקות.
- בירורים ידניים לפנייה אחת — מ-3–4 לאחד: הפרמטרים נרשמים ברגע החישוב.
בנוסף נוסף יומן חישובים: רואים כמה פניות עברו במחשבון ובאיזה שלב לקוחות עוזבים לרוב. זה סיפק חומר לתיקון הבא של הטופס — כבר לפי התנהגות בפועל, ולא לפי ניחושים.
מה לעשות אם החישוב כבר נעשה, אבל הפניות עדיין הולכות לאיבוד?
אם החישוב באתר מחושב נכון אבל הפניות לא מגיעות, בדרך כלל אין צורך לכתוב מחדש את המחשבון: מה שהולך לאיבוד הוא לא האריתמטיקה אלא העברת התוצאה. אבחון של חישוב קיים אורך מעבר אחד — המהנדס עובר את התרחיש כמבקר, משאיר פניית בדיקה עם תיבה נפרדת ובודק באיזה שלב נשברת השרשרת.
הצוואר בקבוק של הטופס כמעט תמיד נמצא בגבול שבין החישוב לקבלת הפנייה.
סיבות אופייניות: שדה עם סכום או קונפיגורציה מגיע בצורה לא צפויה והמטפל פוסל אותה בבדיקת הנתונים; השליחה נתקלת במגבלה של שרת הדואר; המכתב נכנס לספאם בגלל דומיין לא חתום; הפנייה לא נשמרת בשום מקום, ולכן בעת כשל דואר לא נשאר ממנה עקבה.
בדיקת התרחיש מקצה לקצה מראה היכן בדיוק הולכת התוצאה לאיבוד.
אנחנו מנתחים את יומן האירועים ואת יומן הדואר, משווים את המכתב שנשלח לרישום במערכת החשבונאית, מריצים את הטופס עם ערכים ריקים וערכי גבול, חוזרים על השליחה כשהדואר אינו זמין — ומקבלים רשימת נקודות כשל עם תנאים שניתנים לשחזור.
לאחר מכן ההחלטה מתקבלת לפי המצב בפועל, ולא לפי הרגל. אם הנוסחאות, מדריכי הנתונים והיגיון החישוב תקינים, מפתחים רק את ההעברה: קודם שמירת הפנייה במסד הנתונים, אחר כך התראה ותור ניסיונות חוזרים.
בנייה מחדש כדאית כאשר ההיגיון עצמו אינו ניתן לתיקון — משוכפל בכמה תבניות, אינו בודק את הנתונים המוזנים או סותר את המחירים ממערכת החשבונאות.
שאלות נפוצות על המחשבון ושליחת החישוב
השקת מחשבון על 1С-Битрикс היא התחלה של תפעול, לא נקודת סיום. להלן שאלות טכניות שעולות לרוב בקבלה ובחודשי העבודה הראשונים.
האם אפשר לשפר חישוב קיים בלי לכתוב אותו מחדש?
כן, אם הנוסחאות אינן מעורבבות עם סימון העמוד. מוציאים את החישוב למודול נפרד, שומרים על הממשק הקודם ומחברים שדות חדשים בלי לבנות מחדש את הבלוק. שיפור המחשבון אורך שעות ולא שובר את שליחת התוצאה שכבר הוגדרה.
מכתבים נכנסים לספאם — האם זה נפתר בצד שלכם?
כן. אנחנו שולחים דרך תת-דומיין נפרד עם אימות דומיין וחתימות שלפיהן שירותי הדואר בודקים את השולח. מכתב ללקוח ועותק למנהל מופרדים לתבניות שונות, כדי שתפוצות מסוג אחד לא יגררו מכתבים עסקאיים אל מתחת למסננים.
מה יקרה אם שרת הדואר אינו זמין?
החישוב לא ילך לאיבוד: הפנייה נכנסת לתור וחוזרת על השליחה, והתוצאה נשמרת במסד הנתונים עם סטטוס. המנהל רואה את החישוב בפאנל גם בעת כשל דואר, ולכן הלקוח לא נשאר בלי תשובה.
מי אחראי לעדכניות נוסחאות החישוב?
הנוסחאות הן באחריותכם: את התעריפים והכללים אתם מכירים. אנחנו הופכים אותם לניידים — מקדמים, שלבים והנחות נשמרים בהגדרות, לא בקוד, ולכן המחיר נערך בלי מפתח. אחרי כל תיקון מריצים בדיקות על ערכי גבול.
נדון במשימה: מה לשלוח להערכה ולתוכנית עבודה
כדי לחזור עם הערכת עבודה ותוכנית יישום, אין צורך במסמך מוכן — די בנתוני פתיחה מהמזמין שנמצאים בהישג יד. מהם רואים את היקף הנוסחאות, מספר התלויות בין השדות וכמה זמן ייארך התיאום.
- חישוב נוכחי. איך מחשבים כיום: טבלה, קובץ או סדר פעולות מילולי של המנהל. מספיק קובץ או צילום מסך — נשחזר את ההיגיון.
- כללי עלות. נוסחאות, מקדמים, טווחים, שלב עיגול, התנהגות בערכי אפס ובהזמנה מינימלית.
- שדות וסוגים. מה המבקר מזין — מידות, חומר, כמות, מועד; מה חובה ומה תלוי בבחירה קודמת.
- מטריצת תנאים. צירופים שבהם התוצאה מחושבת אחרת: מידה לא סטנדרטית, דחיפות, אזור, תוספת תשלום עבור אפשרויות.
- דוגמאות מכתבים. שניים-שלושה מכתבים עם תוצאות שנשלחות ללקוחות: נושא, גוף המכתב, קובץ מצורף עם החישוב.
- נקודת יציאה. לאן הולכת התוצאה: כתובת מחלקת המכירות, עותק ללקוח, ייצוא ל-CRM או קובץ למנהל.
- מגבלות ומועדים. מה אסור להראות ללקוח, מי מאשר תיקונים בצד שלכם, לאיזה תאריך נדרשת ההשקה.
זה מספיק כדי לתעד את הגדרת המשימה לחישוב, לסמן נקודות מחלוקת ולחזור עם תוכנית: שלבים, תחום האחריות שלנו, מה נדרש מכם, היכן יידרשו הרשאות ומי מקבל את התוצאה. תארו את המשימה — נשלח הערכה ותוכנית עבודה.