איך מחשבים אחורה את מועד ההודעה מתוך תאריך סיום ותקופת הודעה, למה תזכורת שנשלחה בזמן עדיין מחמיצה את המועד, ואילו חריגים שוברים כל לוח תזכורות פשוט.
עיקרי הדברים
- שני שדות בלבד מייצרים את כל לוח התזכורות: תאריך סיום ותקופת הודעה. אם אחד מהם מוקלד ידנית בכל חוזה מחדש, השגיאה תופיע בחוזה שבו היא הכי יקרה.
- תזכורת שנשלחה בזמן ולא נענתה שקולה לתזכורת שלא נשלחה. מה שסוגר את הפער הוא אישור קבלה עם שם, לא עוד נמען ברשימת התפוצה.
- תאריך סיום חייב להישמר כתאריך לוח ולא כחותמת זמן. חותמת UTC של סוף שנה מוצגת באזור הזמן של ישראל כיום למחרת, וזה מספיק כדי לאחר בהודעה.
- חוזה עם חידוש אוטומטי מתגלגל מייצר עלות שונה לחלוטין מפספוס: לא חודש נוסף אלא תקופה שלמה נוספת, לרוב שנה.
- החריגים, ולא התזכורת, הם מה שנשבר. נספח ששינה את תאריך הסיום, מסמך אב עם הזמנת עבודה בעלת תאריך אחר, ונמען הודעה שהתחלף מאז החתימה.
מועד ההודעה על אי חידוש אינו תאריך שמישהו מקליד ביומן אלא תוצאה של חישוב: תאריך סיום התקופה פחות תקופת ההודעה, מוסט אחורה אם נפל ביום שאינו יום עבודה. כל התזכורות נגזרות מהמועד המחושב הזה, וכל חריג בחוזה משנה אותו.
שני שדות שמייצרים את כל לוח הזמנים
מועד ההודעה מחושב מתוך term_end פחות notice_days, וכל השאר נגזר ממנו. דוגמה מלאה על חוזה שירות SVC-2024-118:
term_endהוא 2026-12-31.notice_daysהוא 60, על בסיס ימי לוח.- מועד ההודעה המחושב: 2026-11-01.
- סולם התזכורות, נספר אחורה מהמועד המחושב: 60 יום לפניו ב-2026-09-02, 30 יום לפניו ב-2026-10-02, 14 יום לפניו ב-2026-10-18, ו-3 ימים לפניו ב-2026-10-29.
שימו לב שהתזכורות נספרות אחורה ממועד ההודעה, לא מתאריך הסיום. זו טעות נפוצה שמייצרת התראה ראשונה חודש אחרי שהחלון כבר נסגר. שימו לב גם לשדה notice_basis: 60 ימי לוח ו-60 ימי עבודה הם שני תאריכים שונים בכמעט שלושה שבועות, וחוזה שלא מגדיר במפורש מאלץ אתכם לבחור בעצמכם. כשהמערכת מחשבת ולא מקבלת תאריך מוקלד, מספיק לתקן שדה אחד כשמתגלה נספח.
למה תזכורת שנשלחה בזמן עדיין מחמיצה את המועד?
מפני שמשלוח אינו החלטה. המכשול כמעט אף פעם אינו טכני: ההתראה יצאה, נחתה בתיבה משותפת, ואיש לא לקח בעלות עליה. המבנה שסוגר את הפער בנוי משלושה חלקים.
- נמען בעל שם ולא תיבה משותפת.
owner_user_idעל החוזה, ולא כתובת מסוג contracts@. - אישור קבלה שנרשם כאירוע: מי אישר, מתי, ומה ההחלטה הזמנית.
- הסלמה כשאין אישור בתוך פרק זמן שנקבע מראש, למשל 72 שעות, אל מנהל שנקבע בשדה ולא אל "כולם".
ההחלטה עצמה נשמרת בשדה decision עם ערך אחד מתוך renew, renegotiate, terminate או undecided, ועם decision_by ו-decision_at. הערך undecided הוא החשוב מכולם, כי הוא היחיד שמאפשר לשאול בבוקר אחד "אילו חוזים עדיין ללא החלטה והמועד שלהם בתוך שלושים יום". רשימה כזאת היא כל הערך של המערכת. השלב שאחרי ההחלטה, יצירת מסמך החידוש והחתמתו, מתואר באוטומציה של חוזים וחתימות דיגיטליות.
שדות החוזה שמאפשרים לחשב במקום לנחש
| שדה | ערך לדוגמה | מה הוא קובע |
|---|---|---|
contract_id | SVC-2024-118 | מזהה יציב, נשמר גם אחרי חידוש |
term_end | 2026-12-31 | תאריך לוח, לא חותמת זמן |
notice_days | 60 | תקופת ההודעה מתוך נוסח החוזה |
notice_basis | calendar | ימי לוח או ימי עבודה |
auto_renew | true | האם שתיקה מחדשת או מסיימת |
renewal_term_months | 12 | אורך התקופה הבאה במקרה של חידוש |
price_basis | cpi_linked | קבוע, צמוד מדד או נתון למשא ומתן |
notice_recipient | שם ותפקיד מתוך החוזה | למי ההודעה נמסרת בפועל |
owner_user_id | u_2261 | מי אצלכם אחראי להחלטה |
parent_contract_id | MSA-2023-004 | קישור בין הזמנת עבודה למסמך האב |
השדה auto_renew הוא היחיד שהופך פספוס מטעות קטנה לטעות יקרה. כשערכו false, שתיקה מסיימת את ההתקשרות ואתם מגלים בינואר שהשירות נפסק. כשערכו true, אותה שתיקה מחייבת אתכם לתקופה נוספת שלמה. אותה תזכורת שנשכחה מייצרת שתי תוצאות הפוכות, ולכן הערך הזה חייב להופיע בגוף ההתראה עצמה ולא רק בכרטיס החוזה.
החריגים ששוברים כל לוח תזכורות פשוט
| חריג | איך הוא נראה במערכת | מה מונע אותו |
|---|---|---|
| נספח ששינה תאריך סיום | החוזה המקורי עדיין נושא את התאריך הישן | כל נספח מעדכן את term_end על רשומת האב |
| מסמך אב והזמנת עבודה | שני תאריכי סיום שונים לאותו ספק | parent_contract_id וחישוב נפרד לכל אחד |
| נמען ההודעה עזב | ההודעה נמסרת לאדם שאינו שם | סקירת notice_recipient בכל תזכורת ראשונה |
| הצמדה למדד | הסכום לחידוש שונה מהסכום הנוכחי | חישוב מחדש לפני התזכורת, לא אחריה |
| חידוש מתגלגל | פספוס עולה תקופה שלמה | הדגשת auto_renew בגוף ההתראה |
| הודעה בערוץ שנקבע בחוזה | נשלח מייל כשהחוזה נקב בדואר רשום | notice_channel נבדק לפני המשלוח, לא אחריו |
לפני שבודקים את הטבלה כולה כדאי למיין את החוזים לפי מה שהם מסתירים: כמעט תמיד יימצא ספק אחד עם ארבעה מסמכים נפרדים, ולקוח אחד שהנספח שלו מעולם לא הוקלד. שני המקרים האלה מייצרים יותר פספוסים מכל שאר השורות יחד, ולכן ניקוי חד פעמי של החוזים הפעילים שווה יותר מהוספת עוד תזכורת ללוח.
החריג הראשון הוא הנפוץ ביותר, והוא גם הכי שקט. נספח נחתם, נשמר בתיקייה, ואיש לא נגע ברשומה. המערכת ממשיכה לחשב מתאריך שכבר אינו נכון ושולחת תזכורת מדויקת לחלוטין למועד הלא נכון. הכלל היחיד שעובד: חתימה על נספח היא אירוע שמחייב עדכון שדה, ולא רק העלאת קובץ. כשהמחיר צמוד למדד, החישוב מחדש נעשה לפני המשלוח כדי שההחלטה תתקבל על הסכום האמיתי; המנגנון מתואר בהצמדת חוזים למדד המחירים לצרכן.
איך שומרים תאריך סיום כך שלא יזוז?
שומרים אותו כתאריך לוח בלבד, בפורמט של תאריך מלא ללא שעה ואזור זמן. RFC 3339 מגדיר במפורש את הצורה full-date בנוסח 2026-12-31, בנפרד מחותמת זמן מלאה. ההבדל אינו תיאורטי: 2026-12-31T22:00:00Z הוא ה-1 בינואר 2027 בשעה 00:00 באזור הזמן של ישראל, וכל חישוב שנשען עליו מזיז את מועד ההודעה ביום.
- שמרו את
term_endכתאריך ולא כחותמת זמן, גם אם הבסיס נתונים תומך בשעה. - אם המערכת מייצרת התראות בשרת שממוקם באזור זמן אחר, קבעו במפורש את אזור הזמן העסקי לפי מסד הנתונים של IANA, למשל
Asia/Jerusalem. - אל תסתמכו על היסט קבוע. ישראל עוברת בין שעון חורף לשעון קיץ, וההיסט מ-UTC משתנה בתוך תקופת התזכורות של חוזה שמסתיים בסוף השנה.
- הריצו את מחולל התזכורות בשעה קבועה בזמן המקומי, ורשמו על כל התראה את התאריך שממנו חושבה.
- כשמדובר בתשלומים חוזרים לאורך החוזה ולא רק בחידושו, לוח החיוב מתועד בנפרד באוטומציה של חשבוניות ותזכורות תשלום.
מקורות
שאלות נפוצות
כמה תזכורות כדאי לשלוח לפני מועד ההודעה?
ארבע נקודות מכסות את רוב המקרים: 60, 30, 14 ו-3 ימים לפני המועד המחושב. הראשונה נועדה לפתוח משא ומתן, השנייה לאסוף נתוני שימוש, השלישית לקבל החלטה והרביעית להתריע שהחלון נסגר. תזכורת חמישית ללא אישור קבלה מוסיפה רעש ולא מוסיפה החלטה.
מה עושים כשתקופת ההודעה בחוזה מנוסחת בחודשים?
ממירים לתאריך ולא לימים. "שלושה חודשים" מתאריך סיום 2026-12-31 הוא 2026-09-30, בעוד תשעים ימי לוח הם 2026-10-02. ההפרש קטן אך ממשי, ולכן `notice_basis` צריך לקבל גם ערך של חודשים, והחישוב צריך לעבוד על לוח שנה ולא על כפל בשלושים.
האם צריך לנהל חוזים ישנים שכבר חודשו?
כן, אבל כרשומה אחת עם היסטוריית תקופות. חידוש יוצר תקופה חדשה תחת אותו `contract_id` ולא חוזה חדש, כך שאפשר לראות את התפתחות המחיר לאורך השנים ולזהות שהתקופה הנוכחית היא כבר הרביעית. חוזה חדש בכל חידוש מוחק בדיוק את המידע הזה.
מי צריך לקבל את ההתראה, המנהל או איש הכספים?
בעל ההחלטה, שנרשם בשדה ייעודי לכל חוזה. ההסלמה למנהל היא שלב שני ולא נמען מקביל, מפני ששני נמענים ראשוניים מייצרים הנחה הדדית שהצד השני טיפל. איש הכספים מקבל את ההתראה רק אחרי שהתקבלה החלטה, כדי לעדכן תחזית ותשלומים.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.