ועד בית: גבייה, ספקים וקריאות דיירים במערכת שקופה לביקורת

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

הרשומה שאינה נערכת

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

• entry_id - מזהה רץ ויציב, שאינו משתנה לעולם.
• unit_id - הדירה. אצל הוצאה משותפת השדה ריק וקיים expense_category במקומו.
• entry_type - חיוב, תקבול, הוצאה, היפוך.
• amount ו-currency - סכום חתום, כדי שסכימה פשוטה תיתן יתרה.
• effective_date - התאריך שאליו התנועה שייכת, למשל החודש שנגבה.
• recorded_at ו-recorded_by - מתי ומי רשם. שני שדות נפרדים מ-effective_date.
• document_ref - הפניה לאסמכתה: קבלה, חשבונית ספק, אישור העברה.
• reverses_entry_id - מלא רק בשורות היפוך.

השילוב של effective_date עם recorded_at הוא מה שמאפשר לענות על שתי שאלות שונות: מה היתה היתרה בסוף מרץ, ומה ידענו על היתרה של מרץ באותו זמן. ועד שמחליף ועד מקבל את שתיהן. העיקרון של רישום שנצבר ולא נדרס מתואר בפירוט ב-Event Sourcing של Martin Fowler.

אכיפה טכנית פשוטה יותר ממדיניות: טריגר שחוסם UPDATE ו-DELETE על טבלת התנועות הופך את הכלל למשהו שאי אפשר לשכוח, ותחביר כזה מתועד ב-SQLite CREATE TRIGGER.

למה הדירה היא החשבון ולא האדם?

כי האדם מתחלף והדירה לא. שוכר שעוזב באמצע שנה, בעלים שמוכר, יורש שנכנס - כל אלה משנים מי משלם ואינם משנים לאיזו יחידה החיוב שייך.

מבנה שעובד:

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

שלוש יתרות שחייבות להסתדר

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

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

תשלומי ספקים: ארבעה מסמכים, לא ארבע החלטות

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

1. הצעת מחיר - סכום, תיאור עבודה, תוקף. נשמרת גם כשלא נבחרה.
2. אישור - מי אישר ומתי, מול ההצעה הספציפית.
3. חשבונית - מגיעה אחרי הביצוע, ומקושרת להצעה שאושרה.
4. תשלום - מקושר לחשבונית, עם אסמכתת העברה.

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

איך מוכיחים שדייר שילם לפני שנתיים?

בשלושה חלקים שקיימים במערכת מהיום הראשון, ולא בחיפוש רטרואקטיבי.

הראשון הוא שורת התקבול עצמה, שלא נערכה מעולם, עם effective_date ו-recorded_at. השני הוא ה-document_ref שמצביע לקבלה או לאסמכתת ההעברה כפי שהיא נשמרה. השלישי הוא היכולת להפיק שוב את הדוח החודשי של אותו חודש ולקבל בדיוק את אותם מספרים.

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

קריאות דיירים: מקרה, לא תנועה

קריאה על נזילה או על תאורה שרופה איננה כסף, ולכן היא לא צריכה להיכנס לספר התנועות. היא מקרה עם שדות משלה:

• unit_id או אזור משותף, אחד מהשניים.
• reported_at ומי דיווח.
• category מרשימה סגורה: אינסטלציה, חשמל, מעלית, ניקיון, אחר.
• vendor_id כשהופנתה לספק.
• status מתוך נפתחה, הופנתה, בוצעה, נסגרה.
• linked_entries[] - הפניות לתנועות כספיות שנוצרו בעקבותיה, אם נוצרו.

השדה האחרון הוא הגשר. הוא מאפשר לענות כמה עלתה התחזוקה של המעלית השנה בלי לערבב את הקריאות עם החיובים. ערוצי הגבייה שדרכם נכנסים התקבולים עצמם נדונים בגבייה עסקית ב-Bit וב-PayBox.

מה נשבר בפועל

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

מקורות

• Martin Fowler - Event Sourcing
• SQLite - CREATE TRIGGER
• מס"ב - מרכז סליקה בנקאי