June 1, 2006 at 11:13 am
How to define Debt and credit process in Payment ?
Its my payment module So how to declare Debit and credit process .
Payment:
I am not much known about making the database .its my first experience .I have done some work but I want that some one check my work .Is it correct or not ? OR its relations and its primary keys are correct .please help me about payment data and check this .Is it payment data is fully normalized or Not?
We make a Point of sale system for a mobiles. it’s a online application that’s keep all records in database.
In Payment process we make seven tables that’s are our entities in ERD such as
Payment table is the main table and that are linked with other tables.
Some data types are bigint, and varchar
· Payment Table : (mobileNo,customerNo,paymentId,customerName,referenceNo,paymentBalance,payCode,payDescription,amount,cerditCardName,paymentDate)
· PaymentTypes: (typeId,paymentId,typeName)
· BillPayment: (paymentId,billPaymentDate,dealerCode,billBalance)
· CashPayment: (paymentId,cashPaymentDate,cashReceipt,
depositedInBank,cashInHand)
· SecurityPayment: (paymentId,currentDeposit)
· CerditCardPayment: (paymentId,expirationDate,authorizationCode)
· InvoicePayment: (paymentId,invoiceBalance,invoicePaymentDate)
· ChequePayment: (paymentId,locOut,bankName,branch)
We make the relations are
· chequePayment: primary key goes to the payment Table and make a Foreign key in payment Table.
· In Payment Type Table we declare a “typeId “ is a primary key and “paymentId” is a composite Key because payment table relate to the payment types .payment types are “cashPayment,Billpayment,creditCardPayment”
· CerditCardPayment: paymentId is the primary key in the cerditCardPayment and forigen key in the Payment table
· cashPayment ,SecurityPayment ,billPayment,InvoicePayment are all have paymentID as a primary key and its foreign key represent in the payment table.
June 2, 2006 at 6:21 am
The simplest way is to record a credit as a negative "payment" amount. If your need for credits is fairly simple, that's a good way to go. It's simple, straightforward, and useful.
OTOH, in many businesses, debits and credits are actually different entities, and need to be handled differently. In that case, you'd just want to build a Credit table, with a very similar structure to the Payment table here. It will make some of your calculations of current balances a little trickier, as you'll have to join the tables. But, if they are different entities, it is best to separate them into different tables.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply