Dance Classes
in [Tables]
|
Prev: doctors office database
Next: ORGANIZATIONAL CHART
From: BruceM via AccessMonster.com on 26 Feb 2010 13:24 Actually, I kind of wish I had not suggested a separate table for non-class payments, as a single table for all payments/income may be preferable. Starting from Steve's suggested structure for tblClassPayment, maybe you could modify it along these lines: tblPayment PaymentID (primary key) FamilyID (linking field) PaymentDate PaymentReason (optional) PaymentMethod (e.g. check/cash) CheckNum Each family may make many payments. I don't know if you have gotten to the point of making forms, but if you have a Family form you can have a Payment subform based on tblPayment. Also, you could build a standalone form based on tblPayment for non-class payments. tblPayments would then contain a listing of all payments for all reasons. FamilyID would default to 0 for non- class payments. CheckNum would be 0 for Cash payments. It should be possible to build a query that lists each check separately, and combines all cash payments into a single line (although it would depend on you depositing all cash received). I won't go too deep into the options just now. Anyhow, the query could be the source for the deposit slip, with no need to store the deposited amounts. However, if it is your practice to keep deposit slips, at least for a while, if makes sense to store the deposit information, in which case you can create a deposit record, then open a recordset based on tblDepositDetails and add the records that appear in the query. This is not nearly as complicated as it may sound, but I will wait to see how you want to proceed before I launch into details. Nomy wrote: >Bruce, >Oh, you're right. I don't really need that kind of pmt detail in the >deposit detail table. All I really need is a date, pmt type, I can get >that info from the class payment tables. I agree with the comments field in >the deposit detail. > >I like the idea of a separate table to list non class payment income. In >fact, the more I think about it, the more I like it. Thank you for >suggesting it. > >Thank you again for taking so much time to help. > >Nancy > >> As I understand, a payment is made by the person identified in the Family >> table. It may be for more than one student, in which case it is for a >[quoted text clipped - 77 lines] >>>>>>>>>> Thank you in advanch so much. >>>>>>>>>> Nancy -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/201002/1
From: Nomy on 1 Mar 2010 11:07 Bruce, Thanks for the idea, I'll have some time later today to try it. A stand alone form for non class payments I can see working but I would have to have another form based on tblpayments with the fields you list and have a subform based on class enrollment to allocate the payment as a parent could pay make a single payment for two students in different classes. I've started to build a couple of small basic forms to test the suggestions I've received in this newsgroup. Thanks. Nancy "BruceM via AccessMonster.com" <u54429(a)uwe> wrote in message news:a438b14053915(a)uwe... > Actually, I kind of wish I had not suggested a separate table for > non-class > payments, as a single table for all payments/income may be preferable. > Starting from Steve's suggested structure for tblClassPayment, maybe you > could modify it along these lines: > > tblPayment > PaymentID (primary key) > FamilyID (linking field) > PaymentDate > PaymentReason (optional) > PaymentMethod (e.g. check/cash) > CheckNum > > Each family may make many payments. I don't know if you have gotten to > the > point of making forms, but if you have a Family form you can have a > Payment > subform based on tblPayment. Also, you could build a standalone form > based > on tblPayment for non-class payments. tblPayments would then contain a > listing of all payments for all reasons. FamilyID would default to 0 for > non- > class payments. CheckNum would be 0 for Cash payments. It should be > possible to build a query that lists each check separately, and combines > all > cash payments into a single line (although it would depend on you > depositing > all cash received). I won't go too deep into the options just now. > Anyhow, > the query could be the source for the deposit slip, with no need to store > the > deposited amounts. However, if it is your practice to keep deposit slips, > at > least for a while, if makes sense to store the deposit information, in > which > case you can create a deposit record, then open a recordset based on > tblDepositDetails and add the records that appear in the query. This is > not > nearly as complicated as it may sound, but I will wait to see how you want > to > proceed before I launch into details. > > Nomy wrote: >>Bruce, >>Oh, you're right. I don't really need that kind of pmt detail in the >>deposit detail table. All I really need is a date, pmt type, I can get >>that info from the class payment tables. I agree with the comments field >>in >>the deposit detail. >> >>I like the idea of a separate table to list non class payment income. In >>fact, the more I think about it, the more I like it. Thank you for >>suggesting it. >> >>Thank you again for taking so much time to help. >> >>Nancy >> >>> As I understand, a payment is made by the person identified in the >>> Family >>> table. It may be for more than one student, in which case it is for a >>[quoted text clipped - 77 lines] >>>>>>>>>>> Thank you in advanch so much. >>>>>>>>>>> Nancy > > -- > Message posted via AccessMonster.com > http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/201002/1 >
From: BruceM via AccessMonster.com on 1 Mar 2010 13:07 The Family table is one of the top-level tables. Below that is the ClassPayments table, followed by PaymentDetails to show how the payment was allocated. Even if a Family has just one person taking classes, you still would want a Detail record to show how the payment is allocated. With several students in one family it would of course be necessary to do it that way. In either case, the ClassPayments record is the one used for the deposit ticket (unless you require a separate check for each student, which would be unnecessary for the database and inconvenient for the client). Making some forms makes sense for parts of the database where you are clear on the design. Good luck. Keep us posted on your progress. Nomy wrote: >Bruce, >Thanks for the idea, I'll have some time later today to try it. A stand >alone form for non class payments I can see working but I would have to have >another form based on tblpayments with the fields you list and have a >subform based on class enrollment to allocate the payment as a parent could >pay make a single payment for two students in different classes. > >I've started to build a couple of small basic forms to test the suggestions >I've received in this newsgroup. > >Thanks. >Nancy > >> Actually, I kind of wish I had not suggested a separate table for >> non-class >[quoted text clipped - 60 lines] >>>>>>>>>>>> Thank you in advanch so much. >>>>>>>>>>>> Nancy -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/201003/1
From: Nomy on 1 Mar 2010 14:07 Bruce, Thank you so much for your help. I will post back in a few days. You are so nice to do this for people. Nancy "BruceM via AccessMonster.com" <u54429(a)uwe> wrote in message news:a45e44be2cd73(a)uwe... > The Family table is one of the top-level tables. Below that is the > ClassPayments table, followed by PaymentDetails to show how the payment > was > allocated. Even if a Family has just one person taking classes, you still > would want a Detail record to show how the payment is allocated. With > several students in one family it would of course be necessary to do it > that > way. In either case, the ClassPayments record is the one used for the > deposit ticket (unless you require a separate check for each student, > which > would be unnecessary for the database and inconvenient for the client). > > Making some forms makes sense for parts of the database where you are > clear > on the design. Good luck. Keep us posted on your progress. > > Nomy wrote: >>Bruce, >>Thanks for the idea, I'll have some time later today to try it. A stand >>alone form for non class payments I can see working but I would have to >>have >>another form based on tblpayments with the fields you list and have a >>subform based on class enrollment to allocate the payment as a parent >>could >>pay make a single payment for two students in different classes. >> >>I've started to build a couple of small basic forms to test the >>suggestions >>I've received in this newsgroup. >> >>Thanks. >>Nancy >> >>> Actually, I kind of wish I had not suggested a separate table for >>> non-class >>[quoted text clipped - 60 lines] >>>>>>>>>>>>> Thank you in advanch so much. >>>>>>>>>>>>> Nancy > > -- > Message posted via AccessMonster.com > http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/201003/1 >
From: BruceM via AccessMonster.com on 1 Mar 2010 15:34
This is where I learned a lot of what I know. Just returning the favor. I will continue to monitor this thread. Good luck. Nomy wrote: >Bruce, >Thank you so much for your help. I will post back in a few days. You are >so nice to do this for people. >Nancy > >> The Family table is one of the top-level tables. Below that is the >> ClassPayments table, followed by PaymentDetails to show how the payment >[quoted text clipped - 33 lines] >>>>>>>>>>>>>> Thank you in advanch so much. >>>>>>>>>>>>>> Nancy -- Message posted via http://www.accessmonster.com |