תוכנת אקסס לגמח
-
זה השקפה עקרונית באופן כללי, אפילו לא התעמקתי במקרה הנוכחי.
אם מישהו רוצה לראות במסך משהו, בדרך כלל זה אומר שיש פה באמת "משהו".
אם היה מדובר רק בלראות כמה יוצא החוב או כמה תשלומים נשאר, זה לראות "חישוב". אבל אם רוצים לראות רשימת פרעונות או הפקדות, בעיני המשתמש יש פה ישויות, וממילא באפיון חייבים להניח שיש כזו ישות גם אם כל מרכיביה ניתנים להסקה בקלות.
כי לישות הזו צצים בהמשך מאפיינים ותכונות, כמו כל ישות. אין לי מושג איך לתרגם את זה למקרה שלך, וייתכן שיהיה קשה כעת לדמיין על מאפיינים של ישות הפקדה/פירעון, אבל מנסיוני זה מגיע. אפשר גם אז להתחכם ולהצמיד את המאפיינים לחישוב - ומפה מתחילה לגדול בעיה.
זו דעתי, לא חובה לקבל אותה, וגם לא בטוח שהיא רלוונטית למקרה שלא העמקתי בו (אני לא מבין מהי רשימת פרעונות, הייתי אומר כמה חודשים נשאר אבל לא הייתי בכלל מדבר על כזו רשימה, אותו דבר רשימת הפקדות. כלומר לא זו בלבד שאינני רואה פה ישות אלא אינני מבין מה המשתמש רוצה שיופיע במסך).
נ.ב. אולי יעזור שתפרט גם אתה מה הקושי טכני/נפשי/רעיוני עם הדרך של יצירת השורות מראש. -
דבר ראשון, עיקר הצורך של בעל הגמ"ח הוא לראות בסוף כמה כסף יש לו בקופה.
זאת אומרת הפקדות פחות משיכות ויתרת הלוואות שלא נפרעו עדיין.כוונת הרעיון שלי לא הייתה שלא יהיה טבלת של הפירעונות, אלא שלא יהיה טבלה של הפירעונות העתידיים, רק בכל פתיחה הוא יוסיף שורות בטבלה לכל פירעון שעבר התאריך שלו.
(לדוגמא אם יום הפירעון הוא ב15 לחודש, הוא יבדוק כמה 15 עברו ויוסיף שורות בהתאם)עיקר הקושי שלי זה לא עם ההלוואות אלא עם הפקדונות, ששם לכאו' אי אפשר לעשות טבלה עם כל ההפקדות העתידיות (כיון שיש כאלו ללא הגבלה) אלא להוסיף ע"י קוד שורות הפקדה לפי ימי ההפקדה שעברו. וממילא חשבתי לעשות אותו דבר גם להלוואות.
שוב תודה.
-
הבנתי. אמת, בגלל שבהפקדות זה לא רלוונטי ומעשי בכלל יצירה מראש, מתבקש שבכל מקרה יהיה כזה מנגנון.
יש בזה היגיון. אם כי אני עדיין מתעקש להבדיל בין פירעונות שהם דבר אמיתי (יש לווה שחייב בתאריך הזה לפרוע סכום מסוים), לבין הפקדות שהם הבטחה ומשאלת לב, ואין בהם שום דבר אמיתי. ככל שאפליקציה משקפת את המציאות, ככה קל לכתוב ולתחזק אותה. בעיני המשתמש הפקדה היא ישות שקיימת רק בגלל שעבר התאריך, מה שאין כן פירעון.בכל מקרה, אני מציע שלא תריץ קוד בפתיחת התוכנה, אלא הקוד רק יברר שניתן להוסיף שורות פירעונות והפקדות, ויציע למשתמש כפתור של "צור שורות הפקדות מהתאריך XYZ". הרעיון הוא למחוק כל טריקיות ואוטומציה שגורמים לפער בין תחת מכסה המנוע לבין המציאות והשקפת המשתמש לאופן בו היא פועלת.
אגב זה אמור לקחת זמן קצר ביותר, ולא הרבה קודים. זה אמור להיות:
א. טבלת חודשים, שאותה תמלא בלולאה. זו טבלת עזר.
ב. כל שאר הטבלאות עם INSERT של SELECT של חודשים שאין להם תאום, אמור לקחת שבריר שניה. -
בעצם לעשות טבלה של פירעונות עם כל הפירעונות העתידיים, ואם אני רוצה שאוטו' יתחשב כאילו כבר שולם, אז להריץ קוד שמסמן כבוצע כל פירעון שעבר זמנו?
בהפקדות לכאו' לא מספיק הפתרון שלך, כיון שלא כל תאריכי ההפקדה שווים, וממילא צריך לחשב לכל פקדון את תאריכי ההפקדה שלו.
-
@ארי כתב בתוכנת אקסס לגמח:
בעצם לעשות טבלה של פירעונות עם כל הפירעונות העתידיים, ואם אני רוצה שאוטו' יתחשב כאילו כבר שולם, אז להריץ קוד שמסמן כבוצע כל פירעון שעבר זמנו?
בלי לסמן. תחשב את אלו שעבר זמנם כאילו הם שולמו.
לגבי הפקדות הסכמתי שתיצור טבלה ושהיא תמולא לפי התאריך הנוכחי כמו שהצעת מלכתחילה, רק אמרתי שעדיף כפתור ולא קוד אוטומטי.
-
@dovid כתב בתוכנת אקסס לגמח:
בלי לסמן. תחשב את אלו שעבר זמנם כאילו הם שולמו.
אני רוצה שתהיה אפשרות ידנית לעדכן שהפירעון לא נכנס. כך שצריך לבדוק מה מסומן ולא כל מה שעבר זמנו.
@dovid כתב בתוכנת אקסס לגמח:
לגבי הפקדות
כוונתי למה שכתבת:
@dovid כתב בתוכנת אקסס לגמח:
א. טבלת חודשים, שאותה תמלא בלולאה. זו טבלת עזר.
זה לא יעזור כיון שלכל הפקדה יש יום אחר בחודש.
-
מנסיוני..... (יש לי תוכנה כזו)
בשביל לנהל מסד נתונים של גמ"ח את חייב לפצל את הנתונים האמיתיים (מה שקרה בפועל) מול הנתונים התיארוטים. (מה שאמור לקרוא) זה קיים בין בהפקדות ובין בפרעונות. כי גם אם רשום שיש פירעון בתאריך מסוים אין הכרח שזה באמת יקרה.
ראיתי שכבר הרגשת בזה ולכן אתה רוצה גם לסמן האם בוצע או שלא. אבל מה תעשה כשישלם רק חלק? או כרוצה לשלם את יום לפני התאריך?
או אם יש חודש אחד שהוא מבקש לא לשלם ולדחות לו את זה לסוף התשלומים?לדעתי הכי הגיוני זה 2 טבלאות שונות אחת של דברים שצריכים לקרוא. ואחת של מה שקרה בפועל. ואחת מעדכנת את השניה. כלומר כשמתבצע פירעון אתה מעדכן את הפעולה שאמורה לקרוא שהיא קרתה בפועל ואז נוצר רשומה בטבלת הפירעונות.
ואגב המלצה שלי. את כל זה תיישם גם בהלוואות ולא רק בפירעונות. אם בעל הגמ"ח רוצה לנהל תור של לווים מי ביקש ומי הולך לקבל וכו'.
אצלי יש 4 שהם 8
1.הלואה. 2. פירעון-
בקשת הלוואה. 2. תאריך פירעון. (תיארוטי)
-
הפקדה. 2. משיכה.
-
תוכנית הפקדה. 2. תוכנית משיכה.
-
-
@ממוו כתב בתוכנת אקסס לגמח:
לדעתי הכי הגיוני זה 2 טבלאות שונות אחת של דברים שצריכים לקרוא. ואחת של מה שקרה בפועל. ואחת מעדכנת את השניה. כלומר כשמתבצע פירעון אתה מעדכן את הפעולה שאמורה לקרוא שהיא קרתה בפועל ואז נוצר רשומה בטבלת הפירעונות.
מבחינת המבנה זה אכן נראה הכי הגיוני, רק צריך לשים לב שלבעל הגמ"ח זה גורם הרבה יותר עבודה, כי בצורה הזו נדרש ממנו לעדכן גם כל דבר שתיאורטית צריך לקרוא, ואח"כ גם לעקוב על כל דבר מה קרה בסוף בפועל.
