עזרה בבניית טבלאות עבור תשלומים
-
שלום וברכה
אני צריך לבנות ב db שלי טבלאות עבור תשלומים אני מתלבט איך יהיה הכי נכון לשמור את הנתונים אשמח לשמוע מה הכיוון שלכם,
אז מה יש לנו?יש תשלומים חד פעמיים שזה תשלום על מוצרים, יש מנויים שזה תשלום חודשי,
הלקוח יכול גם להטעין כסף ליתרה שלו ובהזמנת מוצר הוא יכול לשלם עם היתרה שלו, ההטענות ליתרה שלו אמור להיות רשום במקום כלשהוא,
תשלום בפועל על הזמנת מוצר יכול להיות בהזמנת המוצר ויכול להיות גם שייכנס למינוס וישלם על זה לאחר מכן,
לאחר שלקוח נכנס למינוס הוא יכול לשלם בפעם אחת על כל המינוס שיש לו כאשר המינוס הזה יכול להיות משוייך לכמה הזמנת מוצרים שלו,
כאשר תשלום על מנוי (שזה תשלום קבוע [לא ח"פ]) נכשל אמור להיות x נסיונות חוזרים והנציגים אמורים לראות את הנסיונות האלה ואת סיבת השגיאה,
לפעמים יש צורך לזכות את הלקוח על הזמנות שהוא עשה, איפה זה נכנס לאותו טבלה רק עם מינוס?
האם הזיכוי יהיה משוייך להזמנה שבוטלה? או שאין קשר?מאמין שזה נושא שהוא כמעט בכל חברה, מעניין לשמוע את דעתכם בנושא, עדיף בלי ai אם אפשרי... את זה יש לי גם...
-
אתה צריך טבלת חשבון לקוח (נגיד AccountJournal).
היא מרכזת את החובה וזכות פר לקוח, עם סוג שורה ומזהה לטבלה הזרה לפי הסוג.
היא מכילה מס' לקוח, סכום (אני עושה שלילי לטובת הלקוח וחיובי לרעתו, כי ככה זה מייצג אותי, אבל אפשר להיפך)
סוג שורה (תשלום, הזמנה, החזר סחורה, החזר תשלום וכולי), ומזהה זר אחד או יותר שמפנה לטבלאות לפי הסוג.
המצב של הלקוח מולך זה הSUM של העמודה סכום, לפי איך שאמרתי אז סכום שלילי אומר שאתה חייב לו וחיובי אומר שהוא חייב לך.
אם הלקוח מזמין מוצר, מלבד טבלת ההזמנות מוסיפים בAccountJournal את סכום החיוב ומזהה ההזמנה. אם הוא משלם, מלבד טבלאות הסליקה/תשלומים מוסיפים לAccountJournal שורה של סכום שלילי, עם מזהה לשורה הרלוונטית בטבלת הסליקה.
במנוי, יש שורה במנויים שגורמת לניסיון חיוב חודשי. הניסיון הזה מתועד לפי סוג הסליקה, למשל בטבלת סליקת אשראי.
רק במקרה של הצלחה אתה מוסיף לטבלת AccountJournal שורה של זכות, עם מזהה לשורה במנויים.
אם יש שורה תואמת בטבלת הסליקה עם הצלחה או בטבלת החשבון לקוח, החיוב הצליח ולא מנסים שוב.
אם מנסים שוב ושוב אמורים להיות כמה שורות בטלת הסליקה הרלוונטית, וככה אפשר לראות שיש מנוי ש"לא הולך".יש כאלו שלא עושים מזהה זר בכלל בטבלה הזו, אלא להיפך, בכל הטבלאות האחרות מפנים לטבלה הזו. יש בזה משהו תקין יותר מצד המסד נתונים (כי אין התניה בעמודת הקשר או שאין כמה עמודות קשר).
-
אתה צריך טבלת חשבון לקוח (נגיד AccountJournal).
היא מרכזת את החובה וזכות פר לקוח, עם סוג שורה ומזהה לטבלה הזרה לפי הסוג.
היא מכילה מס' לקוח, סכום (אני עושה שלילי לטובת הלקוח וחיובי לרעתו, כי ככה זה מייצג אותי, אבל אפשר להיפך)
סוג שורה (תשלום, הזמנה, החזר סחורה, החזר תשלום וכולי), ומזהה זר אחד או יותר שמפנה לטבלאות לפי הסוג.
המצב של הלקוח מולך זה הSUM של העמודה סכום, לפי איך שאמרתי אז סכום שלילי אומר שאתה חייב לו וחיובי אומר שהוא חייב לך.
אם הלקוח מזמין מוצר, מלבד טבלת ההזמנות מוסיפים בAccountJournal את סכום החיוב ומזהה ההזמנה. אם הוא משלם, מלבד טבלאות הסליקה/תשלומים מוסיפים לAccountJournal שורה של סכום שלילי, עם מזהה לשורה הרלוונטית בטבלת הסליקה.
במנוי, יש שורה במנויים שגורמת לניסיון חיוב חודשי. הניסיון הזה מתועד לפי סוג הסליקה, למשל בטבלת סליקת אשראי.
רק במקרה של הצלחה אתה מוסיף לטבלת AccountJournal שורה של זכות, עם מזהה לשורה במנויים.
אם יש שורה תואמת בטבלת הסליקה עם הצלחה או בטבלת החשבון לקוח, החיוב הצליח ולא מנסים שוב.
אם מנסים שוב ושוב אמורים להיות כמה שורות בטלת הסליקה הרלוונטית, וככה אפשר לראות שיש מנוי ש"לא הולך".יש כאלו שלא עושים מזהה זר בכלל בטבלה הזו, אלא להיפך, בכל הטבלאות האחרות מפנים לטבלה הזו. יש בזה משהו תקין יותר מצד המסד נתונים (כי אין התניה בעמודת הקשר או שאין כמה עמודות קשר).
@dovid כתב בעזרה בבניית טבלאות עבור תשלומים:
אם הלקוח מזמין מוצר, מלבד טבלת ההזמנות מוסיפים בAccountJournal את סכום החיוב ומזהה ההזמנה. אם הוא משלם, מלבד טבלאות הסליקה/תשלומים מוסיפים לAccountJournal שורה של סכום שלילי, עם מזהה לשורה הרלוונטית בטבלת הסליקה.
במנוי, יש שורה במנויים שגורמת לניסיון חיוב חודשי. הניסיון הזה מתועד לפי סוג הסליקה, למשל בטבלת סליקת אשראי.
רק במקרה של הצלחה אתה מוסיף לטבלת AccountJournal שורה של זכות, עם מזהה לשורה במנויים.
אם יש שורה תואמת בטבלת הסליקה עם הצלחה או בטבלת החשבון לקוח, החיוב הצליח ולא מנסים שוב.
אם מנסים שוב ושוב אמורים להיות כמה שורות בטלת הסליקה הרלוונטית, וככה אפשר לראות שיש מנוי ש"לא הולך".כמובן שצריך וחובה לבצע את זה אך ורק בטרנזקציה !!!
-
אתה צריך טבלת חשבון לקוח (נגיד AccountJournal).
היא מרכזת את החובה וזכות פר לקוח, עם סוג שורה ומזהה לטבלה הזרה לפי הסוג.
היא מכילה מס' לקוח, סכום (אני עושה שלילי לטובת הלקוח וחיובי לרעתו, כי ככה זה מייצג אותי, אבל אפשר להיפך)
סוג שורה (תשלום, הזמנה, החזר סחורה, החזר תשלום וכולי), ומזהה זר אחד או יותר שמפנה לטבלאות לפי הסוג.
המצב של הלקוח מולך זה הSUM של העמודה סכום, לפי איך שאמרתי אז סכום שלילי אומר שאתה חייב לו וחיובי אומר שהוא חייב לך.
אם הלקוח מזמין מוצר, מלבד טבלת ההזמנות מוסיפים בAccountJournal את סכום החיוב ומזהה ההזמנה. אם הוא משלם, מלבד טבלאות הסליקה/תשלומים מוסיפים לAccountJournal שורה של סכום שלילי, עם מזהה לשורה הרלוונטית בטבלת הסליקה.
במנוי, יש שורה במנויים שגורמת לניסיון חיוב חודשי. הניסיון הזה מתועד לפי סוג הסליקה, למשל בטבלת סליקת אשראי.
רק במקרה של הצלחה אתה מוסיף לטבלת AccountJournal שורה של זכות, עם מזהה לשורה במנויים.
אם יש שורה תואמת בטבלת הסליקה עם הצלחה או בטבלת החשבון לקוח, החיוב הצליח ולא מנסים שוב.
אם מנסים שוב ושוב אמורים להיות כמה שורות בטלת הסליקה הרלוונטית, וככה אפשר לראות שיש מנוי ש"לא הולך".יש כאלו שלא עושים מזהה זר בכלל בטבלה הזו, אלא להיפך, בכל הטבלאות האחרות מפנים לטבלה הזו. יש בזה משהו תקין יותר מצד המסד נתונים (כי אין התניה בעמודת הקשר או שאין כמה עמודות קשר).
@dovid
תודה על המענה המפורט, ראשית למה צריך את AccountJournal בנוסף לטבלאות האחרות?
במידה ומבצעים הכל עם טרנזקציה אני יכול פשוט לעדכן את היתרה בטבלת הלקוחות לא? -
@ivrtikshoret אין לי מושג איזה טבלאות יש לך, מצידי אתה יכול להשאיר רק אותה
כלומר השאלה היא למה אתה צריך טבלאות אחרות,
והתשובה היא כי כל שורה מורכבת מישות שונה, ויכולים להיות בה פרטים שונים.
נניח תשלום בשיק, אז אתה רוצה מספר שיק אז יש לך טבלת שיקים (או שלא...)
הטבלה הזו היא עיקרית, כי שמה אתה שם את המידע הקובע והאמיתי, שמייצג את תהליך ה"עובר ושב" מול הלקוח, עדכון של תא לא יעזור לך לשחזר ממה זה מורכב, ואיסוף המידע הזה מכל הטבלאות שכל קיומם אינו אלא לצורך פירוט, הוא להעביר את נטל המידע מכתיבה נכונה לקריאה עקומה, זה פיזור המידע החשוב במקומות הבלתי חשובים.
