Re: [PHP-DB] Billing Module in PHP
Vinay Kannan wrote: Currently the DB structure stores the following : 1) Customer details. 2) Membership ID and the payment paid at the time of signing up (I am thinking i might not need the signing up amount to be stored in the customer DB in the first place, and have them seperate in a table called signinupfeespaid or something like) 3) And maybe have another table called 'memberfeesintervals) which will have (membershipid, paymentinterval,nextdueon) and then pick up the pending fees (Customer can also issue part payments) from a pendingfees table Any suggestion is welcome! Thank You in advance! Personally I'd have a table for payments received since you will have many payments per MembershipId over time, but I'd probably keep the 'nextdue' and 'period' fields as part of a single customer detail table. There should only be one answer for 'nextdue' based on the last payment which will show the period paid for, and even this is a little redundant since it is available from the last payment record, but I see no need for a third table? Just set the right 'relations' between the master record and payment list? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Billing Module in PHP
I am working on an appplication with a Billing Module. The customers will pay in the following manner. 1) Signing up Fees, at this time they will choose they payment intervals, monthly, quaterly, 6 months or annual. 2) A customer can also change the billing type at a later time, Eg: after paying the signing up fees, he/ she decides to go for quaterly payment, at the end of the term, he / she can then decide to pay monthly or in any other intervals. 3) I checked online and on stack point, i did come across certain helpful articles, but i thought it would be best to ask the experts at sitepoint for their suggestions / advice on the topic too. Currently the DB structure stores the following : 1) Customer details. 2) Membership ID and the payment paid at the time of signing up (I am thinking i might not need the signing up amount to be stored in the customer DB in the first place, and have them seperate in a table called signinupfeespaid or something like) 3) And maybe have another table called 'memberfeesintervals) which will have (membershipid, paymentinterval,nextdueon) and then pick up the pending fees (Customer can also issue part payments) from a pendingfees table Any suggestion is welcome! Thank You in advance!
