← חזרה לסיכום

אפיון מערכת מלא - בית שרה והלל נאמבר

מסמך אפיון מפורט (SRS) לבנייה. מאחד שלוש פגישות אפיון וחומרי לקוח למקור אמת אחד.

גרסה מלאהעודכן 21 ביולי 2026מסמך פנימי לבנייה

סקירת מנהלים, מטרות, היקף ושלבים

1. סקירת מנהלים (Executive Summary)

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

המהות אינה דיגיטציה של ניירת אלא מעבר לפלטפורמה גמישה, מהירה וניתנת להרחבה; חיסכון הניירת הוא תוצר לוואי. שני עקרונות מובילים את התכנון: (א) נראות ניהולית בכל רגע לצחי, מנהל העמותה, על מיקומו של כל מועמד וכל תשלום במסע; (ב) UX טבלאי מוכר ומהיר ללילך, מנהלת התפעול, כדי לשמר את קצב העבודה שהיא מכירה ולהוריד את חסם האימוץ.

התהליך כלל שלוש פגישות אפיון (5.7, 9.7, 21.7.2026) בליווי חומרי לקוח (טופס הרשמה, ייצוא דירות, דוגמת קבלה, טופס עזיבה). האפיון נסגר בפגישה 3 ועוברים לבנייה. מודל הבנייה שהוסכם: עבודה בשלבים, לו"ז go-live יעד חודש עד חודשיים, מעבר מלווה עם עבודה מקבילה קצרה ושתי פגישות הדרכה. קיים פוטנציאל מוצהר להמשך ליווי שוטף אחרי העלייה לאוויר.

מסגרת מסחרית: עמותה (ח.פ 580451433), תעריף 320₪/שעה, עוסק פטור. אפיון נחתם ושולם (8 שעות). הצעת הבנייה נפרדת.

2. סיכום פגישת אפיון 3 (21.7.2026) - הפגישה הסוגרת

השתתפו ניר וצחי (לילך לא נכחה; הערותיה למסמך האפיון רוכזו מראש ונסגרו בפגישה). זהו סבב הסגירה שהעביר את הפרויקט מאפיון לבנייה.

2.1 ארבע ההערות של לילך - נסגרו

#הנושאההכרעה
1הערות תיק אישינסגר בפגישות קודמות - הערות אישיות פנימיות בטיים-ליין של כרטיס הדייר, לא גלוי לדייר.
2קנסותסוג בתשלומים: טקסט חופשי לתיאור העבירה (עבירת תקנון) + סכום קנס משתנה, לא קבוע ← מייצר דרישת תשלום.
3הארכה (הארכת חוזה)נסגר - מנגנון גמיש (חודש/חודשיים/שלושה), יכול באותה דירה.
4העלאת תשלום = גורפתלא העלאה פרטנית לדייר בודד אלא לכלל הדירות מסוג מסוים. מנגנון: סוג דירה כ"מוצר" עם מחיר - עדכון המחיר במקום אחד מדרדר אוטומטית לכל הדירות מאותו סוג (דוגמה: סטודיו מ-1,050₪ ל-1,400₪). כל מספר נכס משויך לסוג דירה והמחיר משתקף אליו.

בנוסף: תשלום סיום/סיוד דירה אושר כחלק מהתשלומים השוטפים (בדוגמת קבלה 53115 - 500₪ "במקום שיק שחזר"), ולא כפריט נפרד.

2.2 דשבורדים - נסגר לפי הפרדת פרסונות

הוסכם (כפי שהומלץ) להפריד את המסכים לפי משתמש, כי "הרבה דברים שמעניינים את צחי לא מעניינים את לילך":

2.3 תחזוקה ומלאי

2.4 ספקים + רו"ח - נכנסו לסקופ

2.5 וואטסאפ ו-Make

2.6 אתר, דומיין ו-Google for Nonprofits

2.7 אפליקציית קריאות שירות חיצונית

צחי רוצה להעביר למאנדיי את אפליקציית דיווח התקלות החיצונית שבשימוש היום (שתחליף אותה). ישלח לניר גישה לבחינת מה היא עושה.

2.8 תנאי הצעת הבנייה (הוחלט בפגישה)

3. מצב קיים (As-Is) מול רצוי (To-Be)

צירמצב קיים (As-Is)מצב רצוי (To-Be)
פלטפורמהמערכת ותיקה, איטית מאוד ("לוקח שבועות"), אבטחה חלשה (כניסה ללא סיסמה), "טלאי על טלאי".מאנדיי - מהיר, גמיש, מאובטח, מודל הרשאות אמיתי.
מסע הדיירמפוצל ולא נראה; אין נראות ניהולית באיזה שלב כל מועמד/דייר.כרטיס אחד לאורך כל המסע עם סטטוס בכל שלב; משפך שקוף מרישום ועד בוגר.
רישום ומסמכיםטופס אתר שבור; מסמכים מגיעים בדואר רשום או לוואטסאפ האישי של לילך; לילך מדפיסה הכול.טופס הרשמה חדש בקוד, מחובר למאנדיי; לינק אישי דינמי להשלמת מסמכים חסרים; תיק דיגיטלי בכרטיס.
תלות באנשים"לילך היא האפליקציה" - ידע ותהליכים תלויים בה; ניירת בתיקים פיזיים.תהליך מובנה במערכת; הידע יושב בכרטיסים, לא בראש; מעבר הדרגתי לדיגיטל.
תשלומיםצ'קים (שנה מראש), תיעוד ידני, "קופה" וירטואלית מול הבנק.הוראת קבע שנתית באשראי (קארדקום, טוקן לכל דייר); ריכוז אוטומטי של מי שילם וכמה; קנסות/העברות חד-פעמיות מנוהלות.
מכתבי מוניםלילך שולחת ידנית לגורמים; למניב נמסר פיזית.מכתב מאוחד מופק ונשלח אוטומטית לכל הנמענים בעת אירוע דיור.
התנדבויות/ביטוחמעקב על דפים, לילך "שוטרת"; אין תזכורות ביטוח.דיווח עצמי + אישור, מונה 12 שעות, תזכורות אוטומטיות; התראות ביטוח (כניסה + חידוש שנתי).
תחזוקהאפליקציה חיצונית לדיווח בלבד; אין היסטוריית תיקונים.יומן תחזוקה פר דירה + מלאי מקרר/מזגן + חיבור ספקים ועלות פר דירה.
ניהולאין תמונת מצב בזמן אמת.דשבורדים מופרדים לצחי (ניהולי/ועד) וללילך (תפעולי).

4. היקף - שלב 1 מול שלב 2

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

בתוך הסקופ (שלב 1 - נבנה עכשיו)

מחוץ לסקופ הנוכחי (שלב 2 - עתידי)

5. בעלי תפקידים

שםתפקידהקשר במערכת
צחי בן דודמנהל העמותה, מקבל ההחלטות (Sponsor).דורש נראות ניהולית ודשבורד ניהולי/ועד; דוחף לשינוי תהליכי; מאשר את ההצעה (הוועד מיודע).
לילך קונצ'יצקימנהלת התפעול, בעלת-התהליך והמשתמשת המרכזית.מנהלת דיירים, תשלומים, קבלות, מונים, ועדות; רגישה לשינוי, אוהבת תצוגת טבלה ומהירות; דשבורד תפעולי; יעד עיקרי להדרכה ואימוץ.
מורדכי ("מורדי")מנהל תחזוקה.רואה דירות ותחזוקה, לא פרטי דיירים; דשבורד תחזוקה.
סופימשתמשת עתידית.גישה מוגבלת - לא רואה הכול; מחייב מודל הרשאות והפרדת בורדים רגישים.
יגאל איילוןIT / מחזיק דומיין ומפיק קבלות היום.הדומיין homeforbest.org.il רשום על שמו (2014, Cloudflare); מפיק את הקבלות במערכת הפנימית הנוכחית. השליטה מועברת ממנו לניר.
איזי כנעןמנהל הבית.חתום על מכתב הבנק (בקשה למשיכת צ'ק).
אביבבונה האתר החדש (Wix), ספק חיצוני.ניר יתואם מולה לחיבור הטופס והדומיין; אין ניהול אתר שוטף מצד העמותה.
ניר גילה-נולמן (KickOps)אפיון, בנייה, אירוח וניהול הדומיין, ליווי מעבר.ספק המערכת; יבצע את כל העבודה הטכנית בעצמו בשלב זה.

מסע הדייר המלא (Resident Journey End-to-End)

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

שרשרת הסטטוסים במסע (עמודת "סטטוס במסע")

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

#סטטוסמתי נכנסים אליוקבוצה בבורד
1נרשםהגיש טופס, טרם נבדקה שלמות מסמכיםמועמדים בתהליך
2חסרים מסמכיםהוגש טופס אך חסר מסמך חובה אחד או יותרמועמדים בתהליך
3חריג-ממתין אישורתאריך שחרור מעל שנה (הוארך לשנתיים) - ממתין להכרעת לילךמועמדים בתהליך
4ממתין לוועדהכל המסמכים הושלמו והחריג (אם קיים) אושרמועמדים בתהליך
5התקבל-ממתין לחוזהועדת קבלה אישרהמועמדים בתהליך
6חתםחתם חוזה מול עורכת הדיןמועמדים בתהליך
7שויך לדירהקושר למספר דירה פנויהדיירים פעילים
8בבנייןהושלמה כניסה (טופס קבלה + מונים)דיירים פעילים
9בעזיבהתהליך עזיבה נפתח (עזיבה או מעבר דירה)דיירים פעילים
10בוגרסיים ועזב את הבנייןבוגרים
11נדחהלא עבר תנאי סף / לא עבר ועדהנדחים / לא רלוונטי

שלב 1 - הגשה ורישום (שער תעודת זהות)

נקודת הכניסה: טופס ההרשמה (רכיב קוד נפרד ב-Next.js, מחובר למאנדיי ב-API), הפותח בשער תעודת זהות.

  1. המועמד מזין מספר זהות ולוחץ "בדיקת תעודת זהות". השער בודק זכאות ומאחזר טופס שמור אם קיים (המשך מילוי).
  2. חסימת הרשמה כפולה (החלטת פגישה 2): ניתן להירשם לבניין פעם אחת בלבד. ת"ז שכבר נרשמה - חסומה להגשה נוספת. פתיחה מחדש ידנית בלבד, בשיקול דעת העמותה (הדייר מתקשר, ואם מתאים לילך פותחת ידנית).
  3. שלילה אוטומטית ללא-לוחם (תנאי סף): תעודת לוחם היא תנאי סף מוחלט. גבר חייב תעודת לוחם - אחרת נשלל אוטומטית ולא יכול להגיש. אישה יכולה לצרף אישור "תומכת לחימה" (מופיע באישור מהלך השירות) במקום תעודת לוחם. בת זוג שאינה משרתת פטורה מתנאי הלוחם דרך checkbox ייעודי בטופס.
  4. הטופס נאסף לפי 7 השלבים (שער ת"ז, סלפי בתוקף 3 שעות, נתונים אישיים, שפות והשכלה, שירות צבאי, שאלות פתוחות, מסמכים). הצנעת שם היחידה: שדה היחידה הוא טקסט חופשי לא-חובה (הורדה מ-חובה בפגישה 2, מטעמי רגישות ביטחונית; מי שרוצה להבליט - ממלא). כולל שדה מקור הגעה ("איך שמעת עלינו") ושדה תמונה.

סטטוס בסיום ההגשה: "נרשם", ובמידה וחסר מסמך חובה - "חסרים מסמכים".

שלב 2 - הגשה לפני שחרור

מסלול ייעודי למי שטרם השתחרר (החלטת פגישה 2, מחליף את "מצלמים פתק" הידני):

שלב 3 - מסלול חריגים

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

  1. זיהוי אוטומטי של תאריך השחרור החורג → סטטוס "חריג-ממתין אישור".
  2. נפתח שדה חריגים (טקסט חופשי) בניסוח שסוכם בפגישה 2:
"מה עשית מאז השחרור? נא לציין רקע (משפחתי/כללי) ויוזמות: לימודים / עבודה / קריירה" + פירוט הבקשה לאישור חריג (על בסיס מה אתה מבקש להתקבל).

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

  1. הכרטיס נכנס לתור חריגים בתצוגה נפרדת מהנרשמים הרגילים, עם התראה ללילך.
  2. לילך מכריעה כן/לא (יעד ~3 ימי עבודה). העמותה פונה לדייר עם התשובה. אושר → "ממתין לוועדה". נדחה → "נדחה".

שלב 4 - השלמת מסמכים (מסלול 6 חודשים) והודעת קליטה

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

הודעת קליטה אוטומטית (טלפון + מייל): רק למי שהגיש הכל - הודעת קליטה תקינה. למי שחסר - הודעת חוסרים עם הלינק האישי.

מסלול השלמת מסמכים - 6 חודשים (החלטת פגישה 2): מועמד שלא השלים מסמכים לא נשאר תקוע ללא הגבלה. הרצף:

מועדפעולה
שבוע לאחר ההגשהתזכורת ראשונה (עוד "טרי")
כל חודשייםתזכורת חוזרת (כ-3 סבבים לאורך 6 חודשים)
חודשיים אחרוניםאזהרה אחרונה לפני סגירה
סוף 6 חודשיםסגירה - הכרטיס יוצא מהרשימה הפעילה

לאחר סגירה, פתיחה מחדש בשיקול דעת ידני (הדייר מתקשר).

שלב 5 - זימון ועדה ומעקב טלפוני

עד הזימון אין תהליך ביניים - הכרטיס ממתין בסטטוס "ממתין לוועדה". הזימון נעשה לפי מקום פנוי/מתפנה בבניין (המתנה עד כ-3 חודשים).

מעקב טלפוני (החלטת פגישה 2): הזימון עצמו הוא טלפוני, ולילך צריכה לסמן על הכרטיס את תוצאת יצירת הקשר:

מעקב זה הוא חלק מהמשפך ומופיע בדשבורד התפעולי של לילך (זימונים ללא מענה).

שלב 6 - ועדת קבלה

החלטה:

שלב 7 - קבלה, חוזה ועורכת דין

  1. עם המעבר ל"התקבל-ממתין לחוזה" נשלחת הודעת "התקבלת" אוטומטית בוואטסאפ (הערוץ המועדף, מחליף טלפון) עם פרטי עורכת הדין ומסגור זמן "לפנות תוך שבוע".
  2. הדייר מתאם ישירות מול עורכת הדין. עורכת הדין מגיעה לבניין לחתימה פיזית. חוזה לשנתיים.
  3. משך אופייני מקבלה לחוזה: כשבועיים. סטטוס לאחר החתימה: "חתם".

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

שלב 8 - שיוך לדירה וכניסה

שיוך: הכרטיס מקושר למספר דירה פנויה (עמודת "דירה משויכת" → בורד דירות). סטטוס "שויך לדירה"; הדירה עוברת ל"מאוישת". סוג הבקשה (עבור עצמך / עבורך ובן-בת זוג) נקבע כבר בטופס, אך סוג הדירה בפועל תלוי במלאי.

תהליך הכניסה בפועל:

  1. מורדכי (מנהל התחזוקה) עובר על הדירה המרוהטת.
  2. טופס קבלת דירה ("טופס טיולים") - תיעוד מונים וציוד.
  3. טופס תקינות דירה - ליקוי שלא דווח בכניסה = חיוב ביציאה.

מחויבויות תוך שבועיים מהכניסה (תיקון פיסוק מפגישה 2): הדייר חותם על טופס הקבלה במעמד הכניסה. שלושת אלו הם מחויבות נפרדת שיש להשלים תוך שבועיים:

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

סטטוס בסיום הכניסה: "בבניין".

שלב 9 - מכתבי מונים

מופעל באירוע דיור (כניסה, מעבר דירה, עזיבה). המכתב מבחין בין "נכנס לבניין" (חדש) לבין "נכנס לדירה" (מעבר פנימי).

מנגנון (דיוק מפגישה 1-2): זהו מכתב אחד מאוחד שמכיל את כל הנמענים; כל גורם קורא רק את השורה הרלוונטית לו. האוטומציה מפיקה ושולחת את המכתב ישירות ממילוי טופס המונים (background), ללא צורך בהעלאת קובץ ידנית. תבנית המקור בוורד.

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

נמענים (4 גורמים, מתוך המכתב בפועל):

גורםאיש קשר
עיריית ראשל"צ - הכנסותגב' קורין
גביה ואכיפה (ארנונה)אתי ממן
חברת מניב (מים)אלינור יצחקי
חברת החשמללירון

לגבי מניב - שליחה במייל בבירור (יש איש קשר: אלינור); עד לאישור, מסירה ידנית של מורדכי.

שלב 10 - תשלומים

טרמינולוגיה: "השתתפות בהוצאות" בלבד.

התראות תשלום: התראה 3 חודשים ולאחריה חודש לפני חידוש/תשלום (בולט, אדום/כתום), ללילך ולדייר. מודל התראות זה משתנה במעבר עתידי לתשלום חודשי.

שלב 11 - התנדבויות

שלב 12 - מעבר דירה

אירוע דיור ייעודי (החלטת פגישה 2). מעבר דירה = עזיבה + שיוך לדירה חדשה, כשהדייר נשאר פעיל - זה אינו עזיבת הבניין.

  1. סגירת החוזה מול הדירה הישנה: הדייר מבצע טופס פינוי + קריאת מונים (מפעיל מכתב מונים "עזיבה" עבור הדירה הישנה).
  2. שיוך לדירה חדשה: נפתחות רק דירות ריקות (אפס טעויות שיוך). הדייר משויך לדירה הפנויה (מפעיל מכתב מונים "כניסה" עבור הדירה החדשה).
  3. הדייר נשאר "דייר פעיל" לאורך כל המעבר - אין יציאה מהבניין.

שלב 13 - הארכת חוזה

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

שלב 14 - עזיבה ובוגרים

תהליך העזיבה מראה לכניסה, ללא עורכת דין:

  1. קריאת מונים סופית → מכתב מונים "עזיבה" לאותם 4 גורמים (עירייה הכנסות, גביה, מניב, חשמל).
  2. טופס טיולים (קבלת/החזרת דירה) + בדיקת תקינות (ליקוי שלא דווח בכניסה = חיוב).
  3. גמר חשבון: תשלום סיום/סיוד דירה, החזר יחסי בעזיבה מוקדמת, משיכת צ'קים שנותרו (מסמך לבנק). זיכויים אפשריים: צ'ק חוזר, מענק נישואין.
  4. סטטוס "בעזיבה" → עם העזיבה בפועל, "בוגר".

התראת עזיבה: התראה 3 חודשים ולאחריה חודש לפני העזיבה (ללילך ולדייר) - דיירים נוטים להיות מופתעים ממועד סיום החוזה. התראה זו נשמרת גם במעבר עתידי לתשלום חודשי.

בוגרים כמאגר פעיל: הבוגרים אינם ארכיון מת אלא קבוצה במסע הדייר (אותו כרטיס). יש להמשיך לגבות השלמות ולהוציא קבלות גם לאחר העזיבה; מיון לפי תאריך/סוג. שדות הליווי התעסוקתי (מקום עבודה, כיוון/תוכנית התפתחות) נאספים לאורך המסע ומאפשרים המשך קשר עם הבוגר.

שלב 15 - הערות אישיות ותיק דיגיטלי (רוחביים לאורך המסע)

Board Schema Spec - מבנה הבורדים, עמודות, קשרים והרשאות

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

1. מפת הבורדים (ERD)

המערכת מורכבת מ-11 בורדים בשני צירים מרכזיים: מסע הדייר (עמוד השדרה) ודירות. חלוקה לפי סקופ: 8 בורדים לשלב 1, ו-3 בורדים לשלב 2 (נכסים משותפים / תחזוקה מונעת, וחלקים מספקים). הפרדת הבורדים אינה עיצובית בלבד - היא נגזרת ההרשאות (ראו §5): מאנדיי לא תומכת בהרשאות ברמת שורה, ולכן כל תוכן שצריך להסתיר ממשתמש מסוים חייב לשבת בבורד נפרד.

` [טופס הרשמה - רכיב קוד נפרד] ──API──▶ ┌──────────────────┐ │ מסע הדייר │◀─┐ self N:1 (בן/בת זוג) │ (עמוד השדרה) │──┘ ┌──────────────┬───────────────┬───────────┴───────┬──────────────┐ │ 1:N │ 1:N │ 1:N │ N:1 │ ▼ ▼ ▼ ▼ │ [תשלומים [התנדבויות] [יומן דייר פנימי] [דירות] ─N:1─▶ [סוגי דירה/תעריפון] וקבלות] │ │ │ (mirror תעריף) ▲ N:1 1:N ▼ │ ▼ 1:N [משלמים חיצוניים] [תחזוקה]│ [מכשירים: מקרר/מזגן] ▲ N:1 │ │ N:1 [נכסים משותפים] ▼ (שלב 2) 1:N▲ [ספקים] ─1:N─▶ [תחזוקה] `

טבלת קשרים (קרדינליות מדויקת)

מ-קשרל-קרדינליותמימוש מאנדיי
מסע הדיירשויך לדירהדירותN:1Connect (two-way) + Mirror מס' דירה/סוג/תעריף
מסע הדיירבן/בת זוגמסע הדיירself N:1Connect (self-link)
מסע הדיירתשלומיםתשלומים וקבלות1:NConnect + Mirror ששולם/יתרה
מסע הדיירהתנדבויותהתנדבויות1:NConnect + Mirror סך שעות מאושרות
מסע הדייריומן פנימייומן דייר פנימי1:NConnect (בורד מוסתר - הרשאות)
דירותסוג/תעריףסוגי דירה (תעריפון)N:1Connect + Mirror מחיר חודשי
דירותקריאות שירותתחזוקה1:NConnect (two-way)
דירותמכשיריםמכשירים (מלאי)1:NConnect (two-way)
מכשיריםספקספקיםN:1Connect
נכסים משותפיםקריאות שירותתחזוקה1:NConnect
ספקיםקריאות/עבודותתחזוקה1:NConnect + Mirror עלות לדירה
משלמים חיצונייםתשלומיםתשלומים וקבלות1:NConnect

הערות קרדינליות:

2. סכמת הבורדים - עמודה-עמודה

בורד 1: מסע הדייר (Resident Journey) - עמוד השדרה

כרטיס אחד לכל אדם, מרגע הרישום ועד בוגר/נדחה. מבוסס Build חדש מאפס.

קבוצות: מועמדים בתהליך · דיירים פעילים · בוגרים · נדחים / לא רלוונטי.

#שם עמודהסוגערכים / יעדחובההערות
1שם המועמד/דיירname-כןראשי
2שלב במסעstatusמועמד · ועדה · התקבל-בחוזה · דייר פעיל · בעזיבה · בוגר · נדחהכןסטטוס-על (7 labels) - המיון הראשי בטבלה
3תת-שלבdropdownנרשם · חסרים מסמכים · חריג-ממתין אישור · ממתין לזימון ועדה · זומן-ממתין מענה · אישר הגעה · בדיון ועדה · התקבל-ממתין חוזה · חתם · שויך לדירה · בבניין · בהארכה · במעבר דירה · גמר חשבוןלאפירוט מתחת לסטטוס-העל (פותר את בעיית ריבוי ה-labels)
4תעודת זהותtext-כןמפתח dedup ייחודי
5טלפון ניידphone-כןלוואטסאפ/קארדקום
6טלפון נוסףphone-לא
7מיילemail-כןהודעות
8סוג בקשהstatusעבור עצמך · עבורך ובן/בת זוגכןתוקן בפגישה 2 (לא "יחיד/שותפים")
9בן/בת זוגboard_relation→ מסע הדייר (self N:1)לאקישור שני כרטיסי זוג
10תפקיד בכרטיסstatusדייר משלם · בת/בן זוג · שותףלאתואם "סוג דייר" בייצוא
11מיןstatusזכר · נקבהכןקובע דרישת מסמך לוחם (זכר=לוחם חובה; נקבה=לוחם או תומכת לחימה)
12חייל בודד?statusכן · לאלאכן → פטור מאישורי הכנסת הורים
13מקור הגעהdropdownמפה לאוזן · אתר · הפניה · אחרלאנוסף בפגישה 2
14צילום/סלפיfiles-לאמהטופס (סלפי בתוקף)
15תאריך שחרורdate-כןמזין את מסלול החריגים
16חריג?statusלא · חריג-ממתין אישור · חריג-אושר · חריג-נדחהלאחלון הגשה: עד שנתיים מהשחרור
17פירוט חריגlong_text-לא"מה עשית מאז השחרור (רקע + יוזמות: לימודים/עבודה/קריירה)"
18סטטוס זימון ועדהstatusלא זומן · זומן-ממתין מענה · ענה-אישר הגעה · ויתר · לא נמצאלאמעקב טלפוני (פגישה 2)
19מס' ניסיונות זימוןnumbers-לא
20תאריך ועדהdate-לא
21המלצת ועדהstatusהתקבל · נדחה · בדיוןלא
22הערות ועדהlong_text-לאתמצית לפרוטוקול
23דירה משויכתboard_relation→ דירות (N:1)לאמתמלא בשיוך; Mirror מס' דירה+סוג+תעריף
24תאריך כניסהdate-לא
25תאריך סיום חוזה צפויdate-לאמזין תזכורות 3ח'/1ח'
26תאריך עזיבה בפועלdate-לא
27סה"כ חודשיםformulaחישוב מ-כניסה/עזיבהלא
28שולם מהתקופהmirrorמבורד תשלומיםלאסכום ששולם
29יתרה לתשלוםformulaתעריף×תקופה - שולםלא
30טוקן קארדקוםtext-לארגיש - הרשאת עמודה; חיוב ע"י שליחת טוקן
31תוקף ביטוח דירהdate-לאמזין תזכורות כניסה+חידוש שנתי
32מחויבות ביטוחstatusממתין · הושלםלאצ'קליסט שבועיים ראשונים
33מחויבות תקינות דירהstatusממתין · הושלםלאטופס "קדוש" (ליקוי לא-מדווח=חיוב ביציאה)
34מחויבות שיחה אישיתstatusממתין · הושלםלאעם צחי
35סטטוס התנדבויותmirrorשעות מאושרות מתוך 12לאמבורד התנדבויות
36מקום עבודהtext-לארגיש (הרשאת עמודה) - ליווי תעסוקתי
37כיוון/תוכנית התפתחותlong_text-לארגיש (הרשאת עמודה)
38מסמכי חובהfilesת"ז (2 צדדים) · תעודת שחרור+הערכת מפקד · תעודת לוחם/תומכת לחימה · אישורי הכנסה הורים · אישור הכנסה מועמדכןתיק דיגיטלי
39מסמכים נוספיםfilesשכירות/משכנתא · הוצאות מיוחדות · אחרלא
40חוזה חתוםfiles-לאחתימה - ראו שאלה פתוחה
41פרוטוקול ועדהfiles-לאחובת שמירה לביקורת

חסימת הרשמה כפולה: ת"ז שנרשמה נחסמת (פתיחה ידנית בשיקול דעת). מנגנון: dedup ב-API של הטופס + אוטומציה.

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

בורד 2: דירות (Apartments)

מלאי הדיור. מקור מיגרציה: materials/04-ייצוא-אקסל/דירות.csv - 120 חדרים. מיושר לעמודות ה-CSV.

קבוצות: לפי סוג חדר (7 קבוצות, ראו §3) או לפי קומה - להכריע בבנייה לפי נוחות לילך.

#שם עמודהסוגערכים / יעדחובהמקור CSV / הערות
1מספר חדרname1–120כןעמודת "חדר"
2קומהstatusקרקע · קומה 1 · קומה 2 · קומה 3 · קומה 4 · קומה 5כןעמודת "קומה"
3סוג חדר / תעריףboard_relation→ סוגי דירה (N:1)כןMirror מחיר חודשי. 7 סוגים (§3)
4סטטוס תפוסהstatusפנויה · מאוישת · עומדת להתפנות · בשיפוץכןמזין "רשימת חדרים"
5דיירים נוכחייםboard_relation→ מסע הדייר (1:N)לאדייר משלם + בת/בן זוג / שותפים
6מספר נכסtext-לאעמודת "מספר נכס" - למכתבי מונים
7מספר מונה חשמלtext-לאעמודת "מונה חשמל" (מק"ט מונה)
8קריאת מונה חשמלnumbers-לאעמודת "קריאת מונה חשמל" (קריאה נוכחית)
9מספר מונה מיםtext-לאעמודת "מונה מים"
10קריאת מונה מיםnumbers-לאעמודת "קריאת מונה מים"
11תאריך כניסהdate-לאעמודת "תאריך כניסה" (של הדייר הנוכחי)
12סיום צפויdate-לאעמודת "סיום צפוי"
13תיק תחזוקהboard_relation→ תחזוקה (1:N)לאקריאות שירות והיסטוריה
14מכשיריםboard_relation→ מכשירים (1:N)לאמקרר/מזגן פר דירה
15עלות תחזוקה מצטברתmirror/formulaמבורד תחזוקהלאלדשבורד עלות/דירה

הערת מיגרציה: בייצוא, שם הדייר + טלפון + ת"ז ריקים (אנונימיזציה). השיוך דייר↔חדר יגיע מייצוא הדיירים המלא. סוג דייר בייצוא: "דייר משלם" / "בת / בן זוג". 4 חדרים ריקים בייצוא (16, 82, 97, 116) - לאמת אם פנויים או חוסר-נתונים. קריאות המונים בייצוא הן קריאה נקודתית; היסטוריית קריאות תיאסף באירועי דיור (כניסה/מעבר/עזיבה).

Views: *רשימת חדרים* (כל הדירות כולל פנויות + ספירת פנויים למעלה - המסך שלילך מכנה "מגרש המשחקים") · *לפי סוג* (Kanban) · *מפת תפוסה*.

בורד 3: סוגי דירה / תעריפון (Apartment Types / Pricing) - חדש (פגישה 3)

קטלוג מחירים - "סוג דירה כמוצר". בורד קטן (7 פריטים). מנגנון העדכון הגורף שצחי ביקש: המחיר מוגדר פעם אחת פר סוג, ומשתקף (Mirror) לכל הדירות מאותו סוג. עדכון במקום אחד מדרדר לכל הדירות (דוגמה: סטודיו 1,050→1,400).

#שם עמודהסוגערכיםהערות
1שם סוגname7 סוגים (§3)ראשי
2קטגוריית בסיסstatusיחיד · זוגי · שותפיםלקיבוץ
3מחיר חודשי (השתתפות בהוצאות)numbersהמחיר שמשתקף לדירות
4מספר דירות מסוג זהmirrorמבורד דירותלבקרה

ערכי מחיר ידועים (מהטופס, לאימות סופי): יחיד = 1,050₪/חודש · זוגות = 900₪/חודש. מחיר שותפים ותוספות תת-סוג (גינה/פנטהאוז) - טרם נמסרו, לאימות לפני go-live.

כלל תכנון חשוב: מאנדיי לא מאפשרת Mirror של Mirror. לכן סכום התשלום בפועל בבורד התשלומים לא ישקף שרשרת תעריפון→דירה→תשלום. במקום זה, סכום דרישת התשלום נזרע ממחיר הסוג ע"י אוטומציה בזמן יצירת הדרישה, ונשמר כמספר קבוע על הפריט (מאפשר גם חריגות/הנחות פר דייר). העדכון הגורף חל על דרישות עתידיות; דרישות קיימות אינן משתנות רטרואקטיבית.

בורד 4: תשלומים וקבלות (Payments & Receipts)

כל תשלום/קבלה - דיירים והכנסות נוספות. מודל תשלום: הוראת קבע שנתית באשראי דרך קארדקום (טוקן פר דייר). העברה בנקאית = חד-פעמי בלבד (קנס/נזק/צ'ק חוזר) + אסמכתא.

קבוצות: תקופה נוכחית · היסטוריה · זיכויים והחזרים · הכנסות נוספות.

#שם עמודהסוגערכיםחובההערות
1תיאור תשלוםname-כן
2דיירboard_relation→ מסע הדייר (N:1)לאריק אם משלם חיצוני
3משלם חיצוניboard_relation→ משלמים חיצוניים (N:1)לאריק אם דייר
4סוג משלםstatusדייר · חיצוניכן
5סכוםnumbersכןנזרע מהתעריפון (אוטומציה)
6סוג תשלוםstatusהשתתפות בהוצאות · צביעה/סיוד (שנה ראשונה) · סיוד/סיום דירה (עזיבה) · פיקדון · קנס · הכנסה נוספת · זיכוי/החזרכןטרמינולוגיה מחייבת
7פירוט עבירה (לקנס)long_text-לארלוונטי כשסוג=קנס; טקסט חופשי, סכום משתנה (פגישה 3)
8אמצעיstatusאשראי (קארדקום/הו"ק) · העברה בנקאית · מזומן · צ'קכן
9תאריךdate-כן
10תקופת כיסויdate/timeline-לאלתשלום שנתי-מראש
11סטטוס גבייהstatusממתין · שולם · הופקד · חזר · הוחזרכן
12אסמכתאfiles-לאחובה בהעברה בנקאית
13קבלהfiles-לאהפקה - ראו שאלה פתוחה
14מספר קבלהtext-לאדוגמה: 53115

דוגמת קבלה 53115: שותפים חדר 26, 3,200₪ = שנה ראשונה 2,700 + סיוד דירה 500. קבלה פנימית (מפיק: יגאל), לא חשבונית. עתיד: קארדקום מפיק קבלה על תשלום.

Views: *לפי דייר* · *ממתין לגבייה* · *הכנסות נוספות* · *Dashboard הכנסות*.

בורד 5: משלמים חיצוניים (External Payers)

כרטיס קבוע לכל גורם המשלם לעמותה שאינו דייר. יישות הכנסות דינמית.

#שם עמודהסוגערכיםהערות
1שם הגורםname-אנטנות גג (PH) · סלקום · מכונות כביסה · חברת חשמל (עודף)
2סוגstatusשכירות גג/אנטנה · שירות (כביסה) · החזר/עודף · אחר
3תשלום קבועnumbersאם רלוונטי
4איש קשרtext-
5תשלומיםboard_relation→ תשלומים וקבלות (1:N)

מכונות הכביסה מחזירות מים+חשמל; אנטנות הגג = שכירות. מודל התשלומים חייב לתמוך במשלם שאינו דייר (סוג משלם + connect כפול בבורד התשלומים).

בורד 6: התנדבויות (Volunteering)

מעקב 12 שעות/שנה, דיווח עצמי + אישור.

#שם עמודהסוגערכיםחובה
1תיאור פעילותname-כן
2דיירboard_relation→ מסע הדייר (N:1)כן
3סוגstatusשמירה · ניקיון · רס"ר · גינון · צביעהכן
4שעותnumbers-כן
5תאריךdate-כן
6סטטוס אישורstatusדווח · אושר · נדחהכן
7אחראי מאשרpeople-לא

Mirror לבורד הדייר: סכום שעות מאושרות מתוך 12.

בורד 7: יומן דייר פנימי (Internal Resident Log) - חדש (פגישה 2, נגזרת הרשאות)

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

#שם עמודהסוגערכיםהערות
1נושאname-
2דיירboard_relation→ מסע הדייר (N:1)
3סוג רשומהstatusשיחה אישית · הערה · אירוע · אזהרה
4תוכןlong_text-
5תאריךdate-
6נכתב ע"יpeople-

בורד 8: תחזוקה (Maintenance) - בסקופ שלב 1 (יומן), מונעת בשלב 2

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

#שם עמודהסוגערכיםהערות
1תיאור תקלה/עבודהname-
2דירהboard_relation→ דירות (N:1)
3נכס משותףboard_relation→ נכסים משותפים (N:1)חלופי לדירה
4מכשירboard_relation→ מכשירים (N:1)קישור לפריט ספציפי
5סוגstatusתיקון · החלפה · תחזוקה מונעת
6סטטוסstatusדווח · בטיפול · הושלם
7דחיפותstatusרגילה · דחופהלדשבורד תפעולי
8ספקboard_relation→ ספקים (N:1)
9תאריךdate-
10עלותnumbersMirror לדירה (עלות מצטברת)

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

בורד 9: מכשירים / מלאי ציוד (Appliances Inventory) - חדש (פגישה 3)

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

#שם עמודהסוגערכיםהערות
1מזהה מכשירnameלדוגמה "מקרר דירה 22"ראשי
2סוגstatusמקרר · מזגן
3דירהboard_relation→ דירות (N:1)
4ספקboard_relation→ ספקים (N:1)
5תאריך התקנהdate-
6תום אחריותdate-לתזכורות בהמשך
7דגם / מק"טtext-
8היסטוריית טיפולboard_relation→ תחזוקה (1:N)

בורד 10: נכסים משותפים (Shared Assets) - שלב 2

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

#שם עמודהסוגערכיםהערות
1שם נכסnameגנרטור · מעלית · משאבות · מועדון · אחר
2סוגstatusתשתית · ציוד · שטח משותף
3סטטוסstatusתקין · בטיפול · דורש חידוש
4חוזה תחזוקה שנתיdate-תאריך חידוש
5ספקboard_relation→ ספקים (N:1)
6תיק תחזוקהboard_relation→ תחזוקה (1:N)היסטוריית טיפולים

בורד 11: ספקים (Suppliers) - בסקופ שלב 1 (החלטת פגישה 3)

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

#שם עמודהסוגערכיםהערות
1שם ספקname-
2תחוםstatusחשמל · אינסטלציה · מיזוג · מקררים · כללי · תחזוקה מונעת
3איש קשר · טלפון · מיילtext/phone/email-
4עבודות/קריאותboard_relation→ תחזוקה (1:N)
5סה"כ הוצאהmirrorמבורד תחזוקהלדשבורד + ייצוא רו"ח

חיבור רו"ח: הרו"ח עובד עם חשבשבת ענן משלו, אין API ללקוח, פינאפ נדחה (משעבד). הפתרון: ייצוא הוצאות חודשי ממאנדיי בפורמט שהרו"ח יגדיר.

3. מלאי הדירות המדויק (מהייצוא - 120 חדרים, 7 סוגים)

בפגישת הגילוי דובר על 3 סוגי חדר (יחיד/זוגי/שותפים). הייצוא בפועל חשף 7 תת-סוגים (גינה/פנטהאוז) שלא עלו בדיבור. לכן עמודת "סוג חדר" נדרשת 7 ערכים (מיושמת כבורד תעריפון בקרדינליות N:1).

פילוח לפי סוג (מקור אמת לבנייה)

סוג חדרספירהקטגוריית בסיס
יחיד60יחיד
יחיד גינה8יחיד
זוגי21זוגי
זוגי פנטהאוז8זוגי
זוגי גינה1זוגי
שותפים19שותפים
שותפים גינה3שותפים
סה"כ12068 יחיד / 30 זוגי / 22 שותפים

פילוח לפי קומה

קומהטווח חדריםספירה
קרקע1–1616
קומה 117–4024
קומה 241–6424
קומה 365–8824
קומה 489–10820
קומה 5109–12012
סה"כ120

נתונים נוספים מהייצוא: תת-סוגי גינה קיימים אך ורק בקומת הקרקע (יחיד גינה 8, שותפים גינה 3, זוגי גינה 1). פנטהאוז אך ורק בקומה 5 (זוגי פנטהאוז 8). כ-195 רשומות דייר בייצוא (164 "דייר משלם" + 31 "בת/בן זוג"). 4 חדרים ללא נתוני דייר (16, 82, 97, 116).

אי-התאמה במספרים - סומנה כשאלה פתוחה (לא נסגרה בפגישה 3): הייצוא = 120 חדרים · תמלול פגישה 1 = 119 (75 יחיד / 22 שותפים / 22 זוגות) · הטופס = "119 יחידות + 44 דירות זוגות". שלושה מספרים שונים. לבנייה: הייצוא (120, 7 סוגים) הוא מקור האמת - עליו נבנה בורד הדירות והמיגרציה; המספר יאומת סופית מול צחי לפני go-live.

4. מפת הרשאות (Board + Column Permissions)

מאנדיי תומכת בהרשאות ברמת בורד (Owner/Member/Viewer/Guest) וברמת עמודה (View/Edit), אך אין הרשאות ברמת שורה. זהו המניע האדריכלי המרכזי: כל תוכן שצריך להסתיר ממשתמש = בורד נפרד (יומן דייר פנימי) או עמודה מוגבלת.

בורד / עמודהצחי (מנהל)לילך (תפעול)סופי (עתידית, מוגבלת)מורדכי (תחזוקה)דיירים
מסע הדיירמלאמלאמוגבל (בלי עמודות רגישות)איןאין
- עמודות רגישות (ת"ז, מקום עבודה, כיוון, טוקן קארדקום, שם יחידה)EditEditמוסתראיןאין
יומן דייר פנימימלאמלאאין גישהאיןאין
דירותמלאמלאViewView (בלי Mirror פרטי דייר)אין
תחזוקהמלאמלאViewEditאין
מכשיריםמלאמלאViewEditאין
נכסים משותפיםמלאמלאViewEditאין
ספקיםמלאמלאViewViewאין
תשלומים וקבלותמלאמלאלפי הצורךאיןאין
משלמים חיצונייםמלאמלאלפי הצורךאיןאין
סוגי דירה (תעריפון)EditEditViewאיןאין
דשבורדיםניהולי (DB-1)תפעולי (DB-2/3/4)תפעולי מוגבלתחזוקה (DB-5)אין

כללי מפתח:

5. מגבלות פלטפורמה (NFR)

  1. ריבוי labels בסטטוס - מסע הדייר דורש הרבה מצבים. פתרון מיושם: סטטוס-על (7) + dropdown תת-שלב במקום עמודת סטטוס אחת עמוסה.
  2. ספירת עמודות - מסע הדייר מונה ~41 עמודות (מעל ה-~30 הנוחים). ההעמסה מנוהלת ע"י הוצאת תוכן לבורדים מקושרים (תשלומים, יומן פנימי, התנדבויות) והישענות על Mirror. אם תגדל עוד - לפצל נתוני ביטוח/תשלום לבורד מקושר.
  3. אין Mirror של Mirror - שרשראות mirror אסורות. מחיר מהתעריפון משתקף לדירה (רמה 1) בלבד; הזרמת המחיר לדרישת תשלום נעשית באוטומציה, לא ב-Mirror שני.
  4. אין הרשאות ברמת שורה - לכן הפרדת בורדים (יומן פנימי) והרשאות עמודה הם היחידים שמסתירים מידע. תוקן בתכנון מראש (שינוי בדיעבד יקר).
  5. Self-link (בן/בת זוג) - נתמך ב-Connect. שיוך זוג לדירה משותף (שני הכרטיסים מצביעים לאותה דירה).
  6. Sub-items מוגבלים - אירועי דיור (כניסה/מעבר/עזיבה עם קריאות מונים) - להעדיף בורד "אירועי דיור" מקושר על-פני sub-items (Mirror ו-Views עשירים יותר בבורד מלא).
  7. קבצים - נשמרים על הפריט; מספיק לתיק הדיגיטלי של הדייר (מסמכים, חוזה, פרוטוקול).
  8. קיבולת - 120 דירות + ~195 כרטיסי דייר + תנועת תשלומים - הרבה מתחת למגבלות הפריטים של מאנדיי.
  9. DoD סכמה: כל ישות ממופה · אין mirror-chains (Mirror רק דייר↔תשלום/התנדבות, ותעריפון↔דירה ברמה אחת) · אין orphan · dedup לפי ת"ז.

טופס ההרשמה (רכיב קוד Next.js באינטגרציה מלאה למאנדיי)

1. סקירה ותחום

טופס ההרשמה אינו טופס מאנדיי native ואינו טופס Wix. הוא רכיב קוד עצמאי (אפליקציית Next.js, בסטאק KickOps, מאוחסן ב-Vercel תחת home4best.kickops.co.il) עם אינטגרציה מלאה למאנדיי דרך ה-API. הבחירה בקוד נובעת מהצורך בלוגיקה עשירה שטפסים גנריים לא מספקים: שער בדיקת ת"ז, מסלולי זוג/חריג/הגשה-לפני-שחרור, תנאי סף (תעודת לוחם) עם שלילה אוטומטית, לינק אישי דינמי להשלמת מסמכים, והעלאות קבצים מרובות ישירות לכרטיס.

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

מבנה הטופס = 7 שלבים (מקור: טופס הלקוח הקיים, "שאלון רישום מועמדות לדיור"), עם שער כניסה מקדים (שלב 0). כל התיקונים מפגישות 2-3 שולבו לתוך המבנה שלהלן.

כללי טרמינולוגיה מחייבים

מה מחוץ לתחום הטופס

2. שלב 0 - שער כניסה: בדיקת תעודת זהות

  1. שליפת טיוטה שמורה - אם קיים כבר טופס/כרטיס לאותה ת"ז, טוענים אותו להמשך מילוי (המשך מהמקום שנעצר).
  2. חסימת הרשמה כפולה - ת"ז שכבר נרשמה ומימשה את הזכות → חסומה להגשה חוזרת. הרשמה אחת לבניין פר ת"ז. פתיחה מחדש = ידנית בשיקול דעת לילך בלבד.
  3. ניתוב לפי תאריך שחרור (נקבע אחרי מילוי שלב 4, אך נגזר מכאן) - קובע אם המסלול רגיל / חריג / הגשה-לפני-שחרור (ראה §8).

3. שלב 1 - צילום עצמי (סלפי) + פרטי בסיס

4. שלב 2 - נתונים אישיים

שדהסוגחובההערות
מספר זהותtextכןאוטומטי מהשער
שם פרטיtextכן
שם משפחהtextכן
שם האבtextכן
טלפון סלולרי ניידphoneכןערוץ ראשי (וואטסאפ)
טלפון נוסףphoneלא
תאריך לידהdateכן
מיןselect (זכר / נקבה)כןמכתיב את דרישת מסמך הלוחם בשלב 6
מצב משפחתיselectכןרווק/ה, נשוי/אה, גרוש/ה, אלמן/ה
ארץ לידהselectכן
כתובת דוא"לemailכןלהודעות קליטה/קבלה
רחוב · מספר · יישוב · מיקודtextכן
סוג בקשהselectכן"עבור עצמי" / "עבורי ועבור בן/בת זוג" (ראה §5)
מקור הגעהselect + "אחר" (טקסט חופשי)לא"איך/איפה שמעת עלינו?" - דרישה חדשה של לילך (פגישה 2). בעתיד ניתן להזין אוטומטית מלינק-מקור
בעלות על רכבcheckbox conditionalלאאם כן → נפתחים דגם + שנה (text)

הערת ניסוח לסוג הבקשה: לא מציגים "דירת יחיד / דירת שותפים / דירת זוג". הבקשה היא רק האם המבקש בא לבד או בזוג - סוג הדירה בפועל נקבע לפי מלאי וזמינות בשיוך, לא בבחירת המועמד (לילך, פגישה 2). זה מונע ציפייה שגויה ("נרשמתי לדירת יחיד").

5. מסלול זוג (נגזר מ"סוג בקשה")

כאשר סוג הבקשה = "עבורי ועבור בן/בת זוג":

6. שלב 3 - שפות + השכלה

7. שלב 4 - שירות צבאי

שדהסוגחובההערות
מספר אישיtextכן
תאריך גיוסdateכן
תאריך שחרורdateכןמזין את ניתוב המסלול (חריג / לפני-שחרור, §8)
חילselectכן
חטיבה / תחוםselect + טקסט חופשיכןfallback: אם לא ברשימה → שדה טקסט חופשי
יחידהטקסט חופשילאשונה בפגישה 2: לא חובה. הצנעת שם יחידה רגישה - אין dropdown של יחידות; פרטים רגישים נמסרים בעל-פה בוועדה
מאפיין פעילותselectכן
תפקידselectכן
דרגהselectכן

מסלול זוג: בן/בת זוג שלא שירת/ה → השלב כולו מדולג עבור אותו כרטיס.

8. ניתוב מסלול לפי תאריך שחרור

תאריך השחרור (שלב 4) קובע אחד משלושה מסלולים:

מצבתנאיהתנהגות
רגילשחרור בעבר, עד 24 חודשים אחורהזרימה רגילה, כל המסמכים נדרשים מיד
הגשה לפני שחרורתאריך שחרור עתידי (טרם השתחרר)כל המסמכים נדרשים מלבד תעודת שחרור + תעודת הערכה (הערכת מפקד). שני אלה נדרשים בהמשך, כשישתחרר, דרך מסלול השלמת המסמכים. מחליף את ה"פתק מצולם" הידני הקיים
חריגשחרור לפני יותר מ-24 חודשים (החלון הוארך משנה לשנתיים בשל המלחמה)סטטוס "חריג-ממתין אישור"; נפתח שדה פירוט חריג (ראה למטה); הכרטיס מוצג ב-View חריגים נפרד; התראה ללילך לאישור (כן/לא, ~3 ימי עבודה). בלי קוד ידני - מחליף את שיטת הקוד-בתוקף הישנה

שדה פירוט חריג (מנוסח מחדש, פגישה 2)

טקסט חופשי ארוך, נוסח מאוחד:

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

מזין את עמודת "פירוט חריג" (long_text) בכרטיס.

9. שלב 5 - שאלות פתוחות (חובה, בלי אמוג'י)

ארבע שאלות טקסט חופשי (1-4 חובה):

  1. מניעים עיקריים לרצון להשתתף בתוכנית.
  2. מסלול קידום לימודי/מקצועי הצפוי מהמגורים.
  3. היכן למדתם בעבר.
  4. מידע נוסף רלוונטי.

10. שלב 6 - העלאת מסמכים

מסמכי חובה בסיסיים

מסמכים מותנים / רשות

כללים

לינק אישי להשלמת מסמכים

11. תנאי סף - תעודת לוחם / תומכת לחימה (שלילה אוטומטית)

12. לוגיקת תלושי שכר הורים

ברירת מחדל: שלושה תלושי שכר אחרונים של שני ההורים. חריגות:

מצבמסמך חלופי
חייל בודדאישור חייל בודד - במקום תלושי שכר ההורים
הורה ללא שכר (לא עובד)אישור מביטוח לאומי במקום תלוש
הורה נפטרדוח רווח והפסד (אפילו לא מבוקר) - "העיקר שיהיה משהו"

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

13. שלב 7 - סיכום ושליחה

14. אינטגרציה למאנדיי (חוזה קליטה)

בהגשה, הרכיב פונה ל-API של מאנדיי ומבצע:

  1. de-dup לפי ת"ז - בדיקה אם קיים כרטיס לאותה ת"ז לפני יצירה (מונע כפילות; מגובה בחסימת שער §2).
  2. יצירת/עדכון פריט בבורד מסע הדייר, קבוצת "מועמדים בתהליך".
  3. קביעת סטטוס אוטומטית לפי שלמות המסמכים והמסלול:
  1. העלאת כל הקבצים לעמודת המסמכים בכרטיס.

מיפוי שדות → עמודות בורד מסע הדייר

שדה בטופסעמודה בבורדסוג
שם פרטי + משפחהשם המועמד/דיירname
מספר זהותתעודת זהותtext (מפתח dedup)
טלפון ניידטלפוןphone
דוא"למיילemail
סוג בקשהסוג בקשהstatus (יחיד / זוג / שותפים)
בן/בת זוג (מסלול זוג)בן/בת זוגboard_relation (self-link)
דייר ראשי / נלווהדייר ראשי?status
תאריך שחרורתאריך שחרורdate
חייל בודד (נגזר)חייל בודד?status
פירוט חריגפירוט חריגlong_text
כל המסמכיםמסמכיםfiles
מקור הגעה(עמודה חדשה בבורד - לא במיפוי הטיוטה)dropdown/text

הערה למפתח הבורד: "מקור הגעה" ו"תמונה מזהה (סלפי)" הן תוספות משלב 2/פגישה 2 שלא הופיעו בטיוטת עמודות בורד מסע הדייר המקורית - יש להוסיף להן עמודות (מקור הגעה = dropdown; תמונה = files/מדיה).

שאר האינטגרציה

15. הודעות אוטומטיות מקושרות (מחוץ לרכיב הטופס, מופעלות מהקליטה)

Automation Register + Integration Contract

Automation Register + Integration Contract

סעיף זה מגדיר את כל האוטומציות במערכת (When / If / Then) ואת חוזה האינטגרציה מול השירותים החיצוניים. זהו המקור הקובע לבנייה: כל אוטומציה כוללת טריגר, תנאי, פעולה, מנגנון מניעת-כפילות (Idempotency), טיפול בשגיאה, פלטפורמת ריצה, אומדן נפח חודשי ועקיבות לדרישה עסקית. האוטומציות מפוצלות לחמישה שלבי בנייה בהתאם לתוכנית העבודה, אך מוגדרות כאן במלואן.

עקרונות מנוע (חלים על כל האוטומציות)

  1. מפתח ייחודי - תעודת זהות. כל בדיקת כפילות, איתור כרטיס קיים ושיוך מסמכים נשענים על ת"ז כמפתח. אין יצירת כרטיס חדש בלי בדיקת ת"ז קיים.
  2. פיצול פלטפורמות: אוטומציות פנים-מאנדיי (שינויי סטטוס, mirrors, התראות למשתמשים, תזכורות מבוססות-תאריך) רצות ב-מאנדיי native. אוטומציות עם ממשק חוץ (טופס, קארדקום, וואטסאפ, מיילים לגורמים, הפקת מסמכים מתבנית) רצות ב-Make. הפרדה זו קובעת גם את חלוקת הנפח מול המכסות.
  3. הפרדת סביבות: בבנייה ובבדיקות - לא נשלחת אף הודעה חיצונית (וואטסאפ/מייל/קבלה) לנמען אמיתי. כל תרחיש נבדק מול נמען בדיקה לפני מעבר להפקה.
  4. Idempotency בכל אוטומציה יוצאת: דגל "נשלח/הופק" (עמודה או שדה על הפריט/האירוע) נבדק לפני שליחה, כדי למנוע כפילות בהרצה חוזרת.
  5. טיפול בשגיאה: כל תרחיש Make כולל route כשל → לוג + התראה ללילך (Notification במאנדיי) עם הפריט והשגיאה. אין כשל שקט.
  6. טרמינולוגיה: בכל הודעה, מכתב, קבלה ודרישת תשלום - "השתתפות בהוצאות" (לא "שכר דירה"). העמותה עוסק פטור - אין אזכור מע"מ בשום מסמך שמופק.

מרשם האוטומציות (מלא)

מזההשםפלטפורמהWhen (טריגר)If (תנאי)Then (פעולה)Idempotencyנפח/חודששלב
AUT-01קליטת טופס → כרטיס מועמדMakeWebhook מטופס-הקוד (Next.js)ת"ז לא קיימת בבורדיצירת פריט בבורד מסע הדייר, קבוצת "מועמדים בתהליך", סטטוס לפי שלמות מסמכים, העלאת קבצים לכרטיסבדיקת ת"ז קיים~30-401
AUT-02חסימת הרשמה כפולהMake + טופסWebhook / בדיקת ת"ז בשער הטופסת"ז כבר רשומהחסימת יצירת כרטיס חדש, החזרת הודעה בטופס, עדכון הכרטיס הקיים (לא כפילות). פתיחה ידנית בשיקול דעת לילךת"ז = מפתח~51
AUT-03לינק אישי להשלמת מסמכיםMake + טופסחוסר מסמך חובה בכרטיסקיים מסמך חובה חסרהפקת לינק אישי דינמי שמציג רק את הקבצים החסרים; שליחה לדיירדגל "לינק פעיל"~401
AUT-04שלילה אוטומטית ללא-לוחםMake/Mondayקליטת טופס / עדכון מסמכיםמין=זכר וללא תעודת לוחם, או מין=נקבה וללא לוחם/תומכת-לחימהסטטוס=נדחה (תנאי סף), קבוצת "נדחים", ללא הודעת קליטה חיוביתדגל "נבדק תנאי סף"~51
AUT-05ניתוב חריג (תאריך שחרור)Make/Mondayיצירת פריט / עדכון תאריך שחרורהיום − תאריך שחרור > חלון הזכאות (שנה, הורחב לשנתיים)סטטוס=חריג-ממתין אישור, פתיחת שדה "מה עשית מאז השחרור", הצגה ב-View חריגים, התראה ללילך (תור אישור ~3 ימי עבודה)דגל "נותב לחריגים"~101
AUT-06הודעת קליטה (התקבל/חוסרים)Makeכל מסמכי החובה הוגשו / חלקם חסרשלמות מסמכיםהכול הוגש → הודעת "התקבל בהצלחה, הבקשה עוברת לוועדה" (וואטסאפ + מייל). חסר → הודעת חוסרים + לינק AUT-03דגל "הודעת קליטה נשלחה"~401
AUT-07מסלול תזכורות השלמת מסמכים (6 חודשים)MakeSchedule יומי סורק כרטיסים בסטטוס "חסרים מסמכים"ימים מאז רישוםשבוע 1 → תזכורת · אח"כ כל חודשיים → תזכורת · לפני סוף 6ח' → אזהרה · 6ח' → סגירה אוטומטית (סטטוס=נדחה/לא רלוונטי)חותמת "תזכורת אחרונה" + שלב במסלול~40-801
AUT-08מעקב זימון ועדהMondayעדכון שדה תוצאת שיחהלפי תוצאה: ענה / ויתר / לא נמצא / מספר ניסיונותעדכון סטטוס במשפך, ספירת ניסיונות, אישור הגעה; חריגה (X ניסיונות ללא מענה) → משימה/דגל ללילךמונה ניסיונות~103
AUT-09הודעת "התקבלת" + פרטי עו"דMakeסטטוס=התקבל-ממתין לחוזה-וואטסאפ לדייר עם פרטי עורכת הדין + מסגור "ליצור קשר תוך שבוע"דגל "הודעת קבלה נשלחה"~101
AUT-10הודעת "לא התקבלת"Makeהמלצת ועדה=נדחה-הודעת סירוב מנוסחת (וואטסאפ/מייל), סטטוס=נדחה, קבוצת "נדחים"דגל "הודעת דחייה נשלחה"~101
AUT-11עדכון סטטוס לאורך המסעMondayמעברי סטטוס בכרטיס-קידום אוטומטי בין שלבים (חתם→שויך→בבניין), הזזת קבוצה בהתאםnativenative1
AUT-12מכתב מונים מאוחדMakeמילוי/עדכון נתוני מונים באירוע דיורסוג אירוע: כניסה לבניין / מעבר דירה / עזיבההפקת מכתב אחד מתבנית Word עם כל 4 הנמענים + מייל אוטומטי לכל גורם. מבחין בין "נכנס לבניין" (חדש) ל"נכנס לדירה" (מעבר פנימי)דגל "מכתב נשלח" על האירוע~152
AUT-13תזכורות ביטוחMondayתאריך כניסה + תוקף ביטוחכניסה + 14 יום / תוקף − 30 יוםתזכורת ללילך ולדייר (וואטסאפ/מייל); כניסה ל-Dashboard תאימותחותמת "תזכורת נשלחה"~102
AUT-14התראות 3ח' + 1ח' לפני חידוש/עזיבהMondayתאריך עזיבה/סיום חוזה − 3ח' / − 1ח'-התראה בולטת ללילך + לדייר; הזנה לדשבורד צחי ("חוזים מסתיימים לפי חודש")חותמת פר סף (3ח'/1ח')~10-202
AUT-15תזכורת התנדבויות חודשיתMakeSchedule חודשישעות מאושרות < 12וואטסאפ/מייל לדייר עם מונה: "השלמת X מתוך 12 שעות" + לינק לדיווחחותמת חודש אחרון~1203
AUT-16קבלה אוטומטית בתשלוםMake (קארדקום)סטטוס גבייה=שולם / callback מקארדקוםתשלום נקלט בהצלחההפקת קבלה בקארדקום (קבלה על תשלום, לא תרומה), שמירת מס' קבלה + PDF על פריט התשלוםמס' עסקה קארדקום~1502
AUT-17חיוב הוראת קבע שנתית (סליקה)Make (קארדקום)Schedule (מועד חידוש שנתי) / חיוב יזוםקיים טוקן קארדקום לדיירשליחת טוקן לחיוב סכום השנתי; הצלחה→AUT-16; כשל (חיוב לא עבר/כרטיס מבוטל) → סטטוס=חזר + דגל בדשבורד לילךמזהה חיוב פר תקופה~120-160/שנה2
AUT-18מסמך משיכת צ'קים לבנקMakeדייר עוזב לפני מועד פרעון / זיכויקיימים צ'קים עתידיים במשמרתהפקת מכתב "בקשה למשיכת שקים" מתבנית (בנק לאומי 934, לידי רועי/ילנה), חתום איזי כנען; שליחה/הורדהדגל "מכתב משיכה הופק"~52
AUT-19דרישת תשלום (קנסות)Monday/Makeיצירת פריט קנס-פריט בבורד תשלומים, סוג=קנס, עבירה (טקסט חופשי) + סכום משתנה; דרישת תשלום לדיירדגל "דרישה נשלחה"~52
AUT-20פולו-אפ וואטסאפ (תהליך נטוש)Make (Green API)Schedule סורק כרטיסים תקועיםמילא ולא המשיך / חוסר מסמכים ממושךוואטסאפ יזום לדייר עם המשך התהליך והמסמכים החסריםחותמת פולו-אפ אחרון~304
AUT-21ייצוא חודשי לרו"חMakeSchedule חודשי-ייצוא הכנסות + הוצאות/ספקים (מקושר לדירות, עלות/רווח לדירה) בפורמט שהרו"ח יגדירחותמת חודש מיוצא1/חודש5
AUT-22עדכון מחיר גורף לפי סוג דירהMonday (mirror/lookup)עדכון מחיר על "סוג דירה כמוצר"-המחיר מדרדר לכל הדירות מאותו סוג (דוגמה: סטודיו 1,050→1,400). עדכון במקום אחד בלבדמקור אמת יחיד (המוצר)לפי צורך1
MIG-01מיגרציה מאקסל (חד-פעמי)MakeManual-ייבוא דיירים + דירות מייצוא מלא, dedup לפי ת"ז, שיוך דייר↔דירה, אימותrun יחידone-time6

כרטיסי אוטומציה מפורטים (החדשים והמורכבים)

AUT-12 · מכתב מונים מאוחד

#גורםלידיערוץ
1עיריית ראשל"צ - הכנסותקוריןמייל
2גביה ואכיפה (ארנונה)אתי ממןמייל
3חברת מניב (מים)אלינור יצחקימייל (בבירור; עד אז - מסירה ידנית ע"י מורדכי)
4חברת החשמללירוןמייל

AUT-16 + AUT-17 · קבלה וסליקה (קארדקום)

AUT-18 · מסמך משיכת צ'קים לבנק

Integration Contract

1. טופס ההרשמה ↔ מאנדיי - רכיב קוד נפרד

2. קארדקום (סליקה + קבלות)

3. וואטסאפ (Green API, לא-רשמי)

4. Make (מנוע האוטומציות)

5. מיילים לגורמים (חשמל / ארנונה / עירייה / מניב / בנק)

6. רו"ח (ייצוא חודשי ידני)

7. אתר Wix / דומיין

הערכת נפח מול מכסות

הנפח מחולק לשלושה מנועים נפרדים, כל אחד מול המכסה שלו:

מנועסוג פעולותנפח חודשי מוערךמכסהניצול
מאנדיי (native)שינויי סטטוס, mirrors, תזכורות מבוססות-תאריך, התראות למשתמשים~500-600 actionsPro = 25,000/חודש~2-3%
Makeקליטת טופס, קבלה/סליקה, מכתבים, פולו-אפים, ייצוא רו"ח~600-800 operationsתוכנית עמותות / חבילה חינמית נכבדתבתוך המכסה
Green APIהודעות וואטסאפ יוצאות~200-350 הודעות~12$/חודש (ללא cap הודעות מעשי)זניח

תשלומים, קבלות וסליקה

תשלומים, קבלות וסליקה

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

טרמינולוגיה מחייבת: בכל המערכת (שדות, מסמכים, קבלות, הודעות) המונח הוא "השתתפות בהוצאות" ולא "שכר דירה". העמותה היא עוסק פטור / מלכ"ר (ח.פ 580451433): מפיקים קבלות בלבד, אין חשבוניות, ואין כל אזכור מע"מ.

1. מודל התשלום

התשלום הוא שנתי מראש (החוזה הוא לשנתיים; חיוב/חידוש שנתי). מבנה החיוב נקבע לפי אמצעי התשלום:

מסלולאמצעישימושמנגנון
השתתפות שנתית בהוצאותהוראת קבע שנתית באשראי דרך קארדקוםברירת המחדל לכל דיירטוקן אשראי לכל דייר נשמר במאנדיי; החיוב מבוצע בשליחת הטוקן לקארדקום. לא תופס מסגרת אשראי ולא דורש העברה חודשית.
תשלום חד-פעמיהעברה בנקאיתקנס, נזק, החזר צ'ק שחזר, גמר חשבוןדורש העלאת אסמכתא (צילום/אישור העברה) לכרטיס התשלום.
מסלול מיגרציה (Legacy)צ'ק / מזומןתיעוד תשלומים היסטוריים בלבדבמערכת הישנה שולם ב-4 צ'קים רבעוניים שווים מראש. במערכת החדשה משמש רק לתיעוד היסטורי ולתקופת המעבר, עד השלמת המעבר לקארדקום.

החלטות שנסגרו:

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

2. מחיר לפי סוג דירה ("מוצר") - מנגנון עדכון גורף

העלאת מחיר היא גורפת לכל הדיירים מאותו סוג דירה, לא פרטנית. המנגנון:

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

מחירי בסיס ידועים (מתוך טופס ההרשמה, דמי השתתפות חודשיים): יחיד/סטודיו 1,050₪, זוגות 900₪. ראו שאלה פתוחה לגבי גזירת המחיר השנתי-מראש מהמחיר החודשי ואימות מחירון מלא לכל שבעת סוגי הדירה.

3. קנסות

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

4. סיוד / צביעה (תשלום סיום דירה)

5. זיכויים והחזרים

מנוהלים כקבוצה ייעודית בבורד התשלומים ("זיכויים והחזרים"), עם פריט מסוג "זיכוי/החזר":

עילהתיאור
צ'ק חוזרצ'ק שלא כובד → רישום זיכוי/חוב מתקן (בדוגמת הקבלה: סיוד נגבה "במקום שיק שחזר").
נישואין / מענקזיכוי בגין אירוע מזכה.
עזיבה מוקדמתהחזר יחסי של התקופה ששולמה מראש ולא נוצלה.

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

6. מנגנון הקבלות

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

מבנה קבלה (מדוגמה 53115):

שדהערך בדוגמה
כותרתמקור · קבלה מס' 53115 (תשלום)
לקוח(שם הדייר)
דירהחדר 26 - שותפים, קומה 1
סכום כולל3,200.00₪ (שלושת אלפים ומאתיים) - מספר + מילים
אמצעישיק · בנק הפועלים · זמן פרעון 23/06/2026
פיצול הסכוםשנה ראשונה 2,700₪ + סיוד דירה 500₪ ("במקום שיק שחזר")
תאריך / חותמת23/06/2026 · לילך קונצ'יצקי

מסקנות לבנייה: הקבלה תומכת בפיצול תשלום בתוך קבלה אחת (למשל השתתפות שנתית + סיוד), כוללת פירוט אמצעי (בנק/פרעון/סכום) ושדה הערות. יש לשמר יכולת זו במנגנון החדש.

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

7. מסמך משיכת צ'קים מהבנק

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

מבנה המכתב (מדוגמה):

המסמך מקושר לתהליך הזיכויים/החזרים (סעיף 5) ולאירוע עזיבה מוקדמת בבורד מסע הדייר.

8. משלמים חיצוניים / הכנסות נוספות

העמותה מקבלת תשלומים ומפיקה קבלות גם לגורמים שאינם דיירים - לכן בורד התשלומים תומך במשלם שאינו דייר (שדה "סוג משלם" + קישור כפול). כרטיס קבוע לכל גורם בבורד משלמים חיצוניים:

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

9. בורד תשלומים וקבלות - סכימה (Build)

#שם עמודהסוגערכים / Labelsחובההערות
1תיאור תשלוםname-כןראשי
2דיירboard_relation→ מסע הדייר (N:1)לאריק אם משלם חיצוני
3משלם חיצוניboard_relation→ משלמים חיצוניים (N:1)לאריק אם דייר
4סוג משלםstatusדייר · חיצוניכן
5דירהboard_relation→ דירות (N:1)לאלשיוך + שאיבת מחיר סוג הדירה
6סוג תשלוםstatusהשתתפות בהוצאות · סיוד/צביעה · קנס · זיכוי/החזר · הכנסה נוספתכן
7סכוםnumbers-כן
8עבירה (לקנס)long_text-לאטקסט חופשי; רלוונטי לסוג "קנס"
9אמצעיstatusהו"ק אשראי (קארדקום) · העברה בנקאית · צ'ק · מזומןכןברירת מחדל: הו"ק אשראי
10תאריךdate-כן
11סטטוס גבייהstatusממתין · שולם · הופקד · חזר · הוחזרכןפידבק קארדקום מעדכן כשל
12אסמכתאfiles-לאחובה בהעברה בנקאית חד-פעמית
13קבלהfiles-לאמנגנון פנימי (יגאל) → קארדקום בהמשך
14מספר קבלהtext-לאלדוגמה 53115

10. חיבור לרו"ח (בסקופ הבנייה)

צחי אישר להכניס ספקים + ייצוא חודשי לרו"ח לסקופ הנוכחי (לא נדחה לשלב 2). המנגנון:

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

דשבורדים, הרשאות, תחזוקה, ספקים, מיגרציה ושלב 2

1. דשבורדים

עיקרון מנחה שנסגר בפגישה 3: הפרדה לפי פרסונה. שני דשבורדים נפרדים, כי חלק גדול מהנתונים שמעניינים את צחי (ניהול) אינם רלוונטיים ללילך (תפעול יומיומי) ולהפך. לצחי תמיד יש גישה גם לדשבורד התפעולי; ההפרדה נועדה למקד כל פרסונה במה שהיא צריכה.

הדשבורד הניהולי נבנה על בסיס המוקאפ שצחי הכין (Gemini) כנקודת מוצא לעיצוב, ומעליו נבנה סיכום של השאלות הניהוליות שהדשבורד עונה עליהן. שני הדשבורדים נבנים כ-Dashboards של מאנדיי מעל הבורדים הקיימים (Widgets: Numbers, Chart, Battery, Table).

1.1 דשבורד ניהולי - צחי (והוועד)

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

#Widgetתוכןמקור
N-1תפוסהדירות מאוכלסות מול פנויות · אחוז תפוסה (Battery)דירות
N-2כספים - נכנסכמה כסף נכנס החודש / רבעוני (Numbers)תשלומים וקבלות
N-3כספים - פתוח לגבייהסכום פתוח לגבייה. רלוונטיות יורדת עם המעבר לחיוב אשראי בקארדקום, אך תמיד יש חיובים שלא עוברים (כרטיס מבוטל/נכשל)תשלומים וקבלות
N-4משפך קבלהכמות מועמדים בכל שלב במשפך · כמה נרשמו והפכו ללא-רלוונטי · כמה הגיעו לוועדה ולא התקבלו או הסירו את עצמם (Chart)מסע הדייר
N-5חוזים מסתיימים לפי חודשצפי חוזים המסתיימים בפילוח חודשי, אופק של כ-4 חודשים קדימה ("כמה חוזים צפויים להסתיים באוקטובר")מסע הדייר
N-6עלות תחזוקה לדירהסך הוצאות תחזוקה, ופירוט פר דירה: "כמה עולה כל דירה לתחזוקה". Widget מורכב יותr המתבסס על שיוך בורד התחזוקה + ספקים לדירותתחזוקה + ספקים + דירות
N-7אימפקט עתידיפילוח דיירים לומדים / עובדים. מתחיל ריק ומתמלא ככל שנאספים נתונים (שדות מקום עבודה / כיוון-תוכנית התפתחות בכרטיס הדייר) - ראה שלב 2מסע הדייר

1.2 דשבורד תפעולי - לילך

"מה דורש טיפול היום". ממוקד פעולה, לא ניתוח.

#Widgetתוכןמקור
O-1מסמכים תקועיםמועמדים שתקועים עם השלמת מסמכים · בקשות פתוחות שדורשות טיפולמסע הדייר
O-2זימונים ללא מענהאנשים שצריך לזמן ולדבר איתם · מי שלא ענה לזימונים (מספר ניסיונות), לפני נטישת התהליךמסע הדייר
O-3פיגורי תשלוםפידבק מקארדקום על חיוב שלא עבר / כרטיס מבוטל - קופץ בבירור לטיפולתשלומים וקבלות
O-4ביטוחיםביטוחים שפגים, בתצוגת דשבורד (בנפרד מהתזכורות האוטומטיות): ראייה של 3 חודשים מראש ("באוקטובר יש 15 דירות לטיפול") + מי טיפל / מי לאמסע הדייר
O-5מחויבויות כניסהצ'קליסט המחויבויות של 14 הימים הראשונים בכניסה לדירה + מעקב התנדבויות - הכל מול העינייםמסע הדייר + התנדבויות

1.3 בורד משימות נפרד (הצעה שנכנסה לסקופ)

בנוסף לדשבורד התפעולי - בורד משימות עצמאי למשימות שאינן חלק מהתהליך הסטרוקטורלי (מסע הדייר / תשלומים / תחזוקה). מאפשר ללילך ולצחי לנהל to-do כללי, כולל פרויקטים ניהוליים על ציר זמן (Gantt) בסביבת עבודה נוספת. הבורד הסטרוקטורלי נשאר נקי; משימות אד-הוק מנוהלות בנפרד.

2. הרשאות

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

2.1 מודל המשתמשים והגישה

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

2.2 יישום ההסתרה

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

3. תחזוקה

בורד התחזוקה משרת שני צרכים שנסגרו בפגישה 3: יומן טיפולים פר דירה ומלאי מכשירים (מקרר ומזגן).

3.1 יומן תחזוקה פר דירה

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

#שדהסוגערכים / הערות
1תיאור תקלה / טיפולnameטקסט חופשי (החלפת נורה, פאנל שנשבר, נזילה, החלפת מכשיר וכו')
2דירהboard_relation → דירותשיוך פר דירה
3נכס משותףboard_relation → נכסים משותפיםחלופי לדירה (שלב 2 - תחזוקה מונעת)
4פריט / ציודdropdownמקרר · מזגן · דוד · אחר
5סוגstatusתיקון · החלפה · תחזוקה מונעת
6סטטוסstatusדווח · בטיפול · הושלם
7תאריךdate-
8עלותnumbersמזין את עלות התחזוקה לדירה בדשבורד הניהולי (N-6)
9ספקboard_relation → ספקיםשיוך הטיפול לספק שביצע (סעיף 4)

3.2 מלאי מכשירים - מקרר ומזגן

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

#שדהסוגערכים / הערות
1מזהה מכשירnameלדוגמה "מקרר דירה 70"
2דירהboard_relation → דירותשיוך פר דירה
3סוג מכשירstatusמקרר · מזגן
4ספק / יצרןtext / board_relation → ספקיםספק המכשיר
5תאריך התקנה / כניסהdateמתי נכנס המכשיר
6אחריות עדdateלניהול אחריות (צורך מפורש של צחי)
7היסטוריית טיפוליםboard_relation → תחזוקהקישור לשורות היומן של אותו מכשיר

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

3.3 קריאות שירות - מעבר מאפליקציה חיצונית

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

4. ספקים

בורד ספקים חדש שנכנס לסקופ הבנייה (לא נדחה לשלב 2), מקושר לדירות ולבורד התחזוקה.

4.1 מבנה ומטרה

4.2 ייצוא חודשי לרו"ח

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

5. מיגרציה ומעבר (go-live)

5.1 מקור הנתונים

מיגרציה מייצוא אקסל מלא מהמערכת הישנה - כרטיסי דיירים + דירות. קובץ ה-CSV של הדירות שהתקבל אנונימי (שם + ת"ז ריקים מטעמי פרטיות); נדרש ייצוא מלא עם שמות ותעודות זהות לצורך שיוך דייר↔דירה. dedup לפי ת"ז כמפתח ייחודי.

5.2 שיטת המעבר - "מעבר פלסטר"

מעבר חד ומלווה, לא הדרגתי-ממושך במקביל:

  1. ייצוא - הוצאת כל הדאטה מהמערכת הישנה.
  2. ייבוא - הזנה למאנדיי (מיגרציה אוטומטית עם dedup).
  3. אימות - בדיקה שהכל נכנס מסודר ונכון (התאמת שדות, ספירות, שיוכים).
  4. החלפה - החלטה על מועד קטיעה: מכאן עובדים רק במאנדיי, המערכת הישנה יורדת.

5.3 ליווי המעבר

6. שלב 2 עתידי

מסומן במפורש מחוץ להצעת הבנייה הנוכחית, לתמחור ומימוש בהמשך:

נושאתוכןסטטוס
תחזוקה מונעת לבנייןנכסים משותפים: גנרטור, חדר משאבות, מעליות, מועדון. חוזה/הסכם תחזוקה שנתי לכל נכס, חידוש פעם בשנה, ותיעוד תקלות שנתיותצחי ישלח רשימת הנכסים הדורשים תחזוקה שנתית ואופן הניהול הנוכחי
ליווי תעסוקתי / אימפקטשדות בכרטיס הדייר: מקום עבודה, כיוון / תוכנית התפתחות, לומד/עובד. מתחילים לאסוף את השדות כבר בשלב 1; הדשבורד הניהולי (N-7) מתמלא עם הזמן ומאפשר להציג אימפקטאיסוף נתונים מתחיל בבנייה; הצגה/הרחבה - שלב 2
קריאות שירות חיצוניותהעברת האפליקציה החיצונית של קריאות השירות למאנדייצחי ישלח גישה למיפוי; ההעברה עצמה בסקופ הבנייה, ההיקף המדויק יתברר לאחר גישה
תשתית אתר ודומייןחיבור אתר Wix החדש, ניהול הדומיין, והרשמה ל-Google for Nonprofits (Workspace: מיילים ארגוניים, Drive מסונכרן, Gemini)אדמיניסטרטיבי - לתמחור בנפרד

עיקרון האימפקט (שלב 2): מבנה שדות הדייר בשלב 1 מתוכנן כך שהנתונים התעסוקתיים נאספים כבר עכשיו, גם אם הדשבורד הניהולי שמציג אותם מבשיל רק בהמשך. כך אין צורך בהזנה רטרואקטיבית כשמפעילים את מודול האימפקט.

שאלות פתוחות ופערים לפני בנייה

פערים שזוהו בביקורת השלמות

סתירות לפתרון

שאלות פתוחות (מאוחד)