צורת מסד אופטימלית לניהול הוקי"ם

[רחמים]

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

תודה לכולם.

תרומות.rar

פורסם במקור בפורום CODE613 ב03/02/2014 16:19 (+02:00)

[ארכיטקט]

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

פורסם במקור בפורום CODE613 ב03/02/2014 16:41 (+02:00)

[רחמים]

תודה, כעת אני לא מתווכח רק רוצה לדעת איך אתה רואה את הדברים.

הזכרת שני סוגי של הוראות קבע:

1. על בסיס סכום ידוע מראש שמחולק לחודשים
2. על בסיס סכום קבוע לחודש עד תאריך לא ידוע כלומר לעולם ועד.

כעת יש לי כאן שני דברים שאני לא יודע איך לסדר אותם בתוך הפזל:

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

2. לגבי תיעוד הגביות שבוצעו יש חילוק בין כל סוג הוראת קבע:
   א. [u:61wkt1jq]הוראת קבע על בסיס סכום ידוע מחולק לחודשים[/u:61wkt1jq] - צריך לעקוב אחר מספר התשלומים שכבר נגבו, ומה היה גובה כל תשלום כיון שגם כאשר ידוע מראש שהלקוח צריך לשלם 980 ש''ח ב 9 תשלומים אפשר שירצה בחודש הראשון לשלם 180 ש''ח וכל חודש 100 ש''ח.
   ב. [u:61wkt1jq]הוראת קבע על בסיס חודשי ללא תאריך סיום[/u:61wkt1jq] - יש לעקוב רק שלא לגבות באותו חודש פעמיים.
   ג. ואם זו [u:61wkt1jq]הוראת קבע משולבת[/u:61wkt1jq] שגם יש סכום קבוע חודשי/כללי וגם אפשרות לגבות לפי המזדמן צריך לעקוב אחר הכל בלא שיהיה בלבול.

פורסם במקור בפורום CODE613 ב03/02/2014 17:08 (+02:00)

[שמואל]

אם כבר העלו את הנושא הרבה עסקתי בזה וחשוב לי גם לשתף את הציבור לתועלת כולנו
אני אפיינתי כך ויתכן שזה יפתור חלק מהשאלות של רחמים
יש טבלת עיסקאות (קרי: עיסקת תשלומים)
בטבלה זו מעודכנים כל פרטי ההוראת קבע תאריך התחלה מספר תשלומים תאריך סיום [u:iaoasqqq]משוער[/u:iaoasqqq]
בטבלה זו יש גם שדה סכום לגביה קרובה זאת אומרת שאם יהיה שינוי לחודש ספציפי במחיר נעדכן שם את הגביה לחודש הקרוב
ועוד פרטים כפי שתראה בקובץ המצורף
בכל חודש כאשר מגיע ה- 20 לחודש התוכנה בודקת מי הם האנשים שלהם יש הוראת קבע מעודכנת לתאריך זה
והיא לוקחת מטבלת ההוראות קבע את פרטי הבנק ומבצעת חיוב (שהינו בעצם שורה בטבלת תרומות בפועל)

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

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

trumot.rar

פורסם במקור בפורום CODE613 ב03/02/2014 19:07 (+02:00)

[רחמים]

איך זה מתנהל, כל גביה דרך הוראת קבע זה שורה חדשה בטבלת עיסקאות?

פורסם במקור בפורום CODE613 ב03/02/2014 20:18 (+02:00)

[שמואל]

לכל עיסקה יש שורה אחת לכל אורך חיי העיסקה
וכל פעם שנוצרת גביה נוספת שורה לטבלת התרומות כלומר שנתקבלה תרומה של 100 ש"ח נוספים

פורסם במקור בפורום CODE613 ב03/02/2014 21:01 (+02:00)

[רחמים]

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

פורסם במקור בפורום CODE613 ב03/02/2014 21:27 (+02:00)

[שמואל]

אם זה מה שהתכוונת אז אנחנו באותו ראש
רק השם "הוראות קבע" זה לא תמיד נכון כי יש גם אשראי וכו'

אני מצרף כאן את הדברים כפי שהם אצלי ואני מודה מראש לכל אחד שיועיל בטובו לעבור על הדברים

ולהלן הסבר:

א. כל הקשרים כאן הם יחיד לרבים.

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

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

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

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

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

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

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

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

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

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

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

פורסם במקור בפורום CODE613 ב04/02/2014 09:54 (+02:00)

[clickone]

נושא קצת טעון....
יש הרבה גישות לזה.
והאמת כרגיל נמצאת איפושהוא באמצע...

אני משתמש בגישה הבאה:
טבלת הו"ק - מכילה את פרטי ההו"ק.
טבלת תרומות/עסקאות - מכיל את כל העסקאות (שמואל: שים לב: אני מצרף את 2 הטבלאות ל1, וטבלת המשנה שלה היא ההו"ק שתיגבה, או האשראי וכו')
טבלת העברות מס"ב
טבלת תנועות שיקים, מזומן, ואשראי
טבלת כרטיסי אשראי. (מסומן כטוקנים, כי אסור לשמור מספרי אשראי [גם לא מוצפנים])

כל שורה מההו"ק קשורה לשורה בעיסקאות.
כל שורה בהעברת מס"ב קשורה להו"ק שלה + לID של העסקה
כל שורה באשראי קשורה לטבלת העסקה + לטבלת התנועות אשראי. הסיבה: לכל אשראי יכולה להיות יותר מתשלום אחד כשמדובר על הו"ק באשראי [עם טוקנים כנ"ל].
בכל חודש כשהתוכנה מחייבת הו"ק באשראי, היא מוסיפה שורה אחת לטבלת התנועות ושומרת את הID של האשראי + הID של העסקה.

במס"ב - כנ"ל.

כשאני רוצה להוציא דוח משולב אני משתמש בUNION.

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

**לשמואל:**לא כ"כ ברור לי כשעשית טבלת שיקים האם זה טבלה של תנועות או טבלה של מקור של שיקים. (אם זה מקור, אין סיבה לעשות את זה, כי שיקים כל הזמן מתחלפים)
לגבי סעיף ח: יש לי בשכ"ל טבלה נוספת שהיא "לוח סילוקין" (-> כמו במשכנתא) ושם אני נותן אפשרות של תיכנון מראש כל תשלום כמה הסכום, ממה הוא יורכב, איך ישולם (הו"ק / אשראי וכו') ובאיזה חודש לגבות. (אח"כ ראיתי בתוכנה של ניהול עיריות, שאותה הגישה נמצאת שם בגביית הארנונה)
לגבי סעיף יא: אני שומר גם את הID של העקסה וגם של האיש קשר, ואפילו שאפשר לקחת את זה מהעסקה.
אני עושה את זה מטעמי נוחות, אבל מבחינת נירמול DB טהור לא עושים את זה. אבל גם מבחינת נירמול טהור אתה לא אמור לשמור מיקוד, אלא למצוא אותו לפי הכתובת, ובכ"ז נוהגים לשמור, כי זה נתון זעיר (מסוג מספר) וכח העיבוד שתוציא כדי לשלוף את המיקוד בזמן אמת כ"כ גדול שזה ל שווה את המאמץ. מאותה סיבה אני שומר גם את הID (אם כי דיי פשוט לשלוף את הID)
דבר נוסף, בטבלת העברות מס"ב אני שומר בכל העברה את מספר הבנק, הסניף והחשבון כי לפעמים משנים את הנתונים האלה במקום לפתוח הו"ק חדשה. ואז זה חשוב בשביל ההסטורייה.
ובנוסף, אני חושב שיש לאפשר יותר מהו"ק אחת פעילה לכל תורם. נניח שהוא רוצה להביא תרומה מהחשבון השני שלו??

**לארכיטקט:**אני מסכים איתך שאין סיבה לכתוב את תאריך הסיום, אני בכל מקרה נוקט בגישה של לכתוב 999 במקרה של בלתי מוגבל.

ושוב, יש בזה הרבה גישות, ותמיד טוב לשמוע עוד בנושא....

פורסם במקור בפורום CODE613 ב04/02/2014 13:07 (+02:00)

[שמואל]

@ClickOne

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

אתה צודק, ברור שכשמדובר לגבי שיקים זה צריך להיות פירוט של שיקים שהתקבלו
@ClickOne

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

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

@ClickOne

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

אכן זה מאופשר רק לדעתי זה נחשב לעיסקה חדשה, לא צודק?!
@ClickOne

**לארכיטקט:**אני מסכים איתך שאין סיבה לכתוב את תאריך הסיום.

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

פורסם במקור בפורום CODE613 ב04/02/2014 15:36 (+02:00)

[רחמים]

זה מה שיצא לי בסופו של דבר על פי דברי ידידי ClickOne
אשמח לשמוע את דעתכם.

תרומות - 3.rar

פורסם במקור בפורום CODE613 ב04/02/2014 20:50 (+02:00)

[רחמים]

אודה לכל מי שהוריד שיגיב מה דעתו, לטוב ולמוטב.

פורסם במקור בפורום CODE613 ב06/02/2014 13:42 (+02:00)

[shsh654]

איך אמר ClickOne האמת נמצאת איפשהו באמצע.
אני משתמש בשילוב של (כל) הנ"ל, ואפרט בקצרה:

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

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

נשמח לשמוע מClickOne כיצד אכן עובד לוח הסילוקין שלו - שורה במקרה של שינוי והקוד 'עובר' דרך שם לפני הביצוע?

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

שאלה לארכיטקט: שיקים אמור להיות טבלה קטנה נוספת או בשורת התנועות?
האמת, אשאל יותר לעומק - [u:3d25gum9]ה[/u:3d25gum9]טבלה האוניברסלית עליה אתה ממליץ תכיל גם פרטי מסב, שיקים וכו' ואז לדוגמא בעת ביצוע מסב הוא יקרא נתונים מטבלת העסקאות - יוסיף שורות לטבלת התנועות - ויבצע את הגביות?
לסיום החכמתי באשכול כאן בכמה דברים שהוספיו לי רבות, והאמת לא רק כאן אלא בכל רחבי הפורום הנפלא הזה
תודה לך ClickOne על:

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

פורסם במקור בפורום CODE613 ב07/02/2014 14:56 (+02:00)

[clickone]

@שמואל

@ClickOne

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

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

@shsh654

נשמח לשמוע מClickOne כיצד אכן עובד לוח הסילוקין שלו - שורה במקרה של שינוי והקוד 'עובר' דרך שם לפני הביצוע?

לא תמיד אני משתמש בלוח סילוקין. רק בשכ"ל ובגמ"ח. (בינתיים <!-- s8-) --><img src="{SMILIES_PATH}/icon_cool.gif" alt="8-)" title="מגניב" /><!-- s8-) --> )
וגם בשכ"ל הלוח סילוקין לא לא אינסופי. אלא ל12 החודשים הקרובים בלבד. (ז"א יש ללקוח מקום לבנות לכל שנתון את ה"שירותים" שהוא מספק לשנה זו - זה יכול להיות שכ"ל חודשי, ביטוח,, נזקים חד פעמיים וכו') הלקוח מגדיר סטטוס לכל שירות, האם הוא אוטו', ידני, וממה הוא נגזר שכ"ל, ביטוח וכו, וכן האם השירות פתוח [עדיין לא התחיל], פעיל, או נסגר.
יש בנייה חד פעמית לכל המוסד בשנתון של לוח הסילוקין, שבו מוגדרים השירותים שהתלמיד מקבל מהמוסד.
בכל חודש הלקוח עושה בניית הו"ק, ואז התוכנה בודקת אם יש שירות שמוגדר לתשלום בהו"ק שעדיין לא שולם, ואם כן היא מייצרת חיוב לתשלום.
כמובן שגם מי שמוגדר לתשלום בהו"ק, אם ההורה יבוא וישלם בשיקים, ברגע שיוציאו לו קבלה, התוכנה תבדוק ותשייך לו את התשלומים לאותם ה"שירותים" שהוא קיבל מהמוסד. - בדוגמא המצולמת להלן אפשר לראות שהייתה חזרת הו"ק, וההורה הגיע לשלם בשיק. (לגבי השורות הנוספות בתמונה של החזרת ההו"ק וכן של העמלה זה עם שאילתת UNION וכבר הסברתי ע"ז במקום אחר)

מצ"ב צילום מסך לדוגמא של לוח סילוקין לתלמיד

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

@שמואל

@ClickOne
ובנוסף, אני חושב שיש לאפשר יותר מהו"ק אחת פעילה לכל תורם. נניח שהוא רוצה להביא תרומה מהחשבון השני שלו??

אכן זה מאופשר רק לדעתי זה נחשב לעיסקה חדשה, לא צודק?!

נכון אתה צודק. אני לא הבנתי שלזה אתה מתכוון. ככה זה אמור להיות.

פורסם במקור בפורום CODE613 ב09/02/2014 01:08 (+02:00)