I produced a credit card applicatoin couple of days ago that are responsible for invoicing. I must understand how to best integrate a price reduction to my bills. Must I place it as an adverse item (within the invoice_products table) or must i produce a "discount" column within the invoice table ?
What effects would either of individuals options have for you personally in the future? For instance, do you want to have multiple discount rates, or very specified discount rates afterwards? If there are only one discount per invoice, i quickly wouldn't allow it to be anymore complicated than necessary. For me it's simpler and clearer to be within the invoice table - getting it as being an adverse item can make the processing of products harder, I believe.
I fully accept which makes it as easy as possible, only one factor to think about is that if anything ought to be excused in the discount? For the reason that situation you have to give a bool area within the particulars to keep in mind which line must have discount.
I might say as an adverse-valued item. The reason why are:
- With invoicing, it is extremely essential that the calculated value remains contant forever even when your calculation formula later changes, you are able to properly reproduce a invoice. This really is even true when the value was improperly calculated at that time - it had been what it really was.
- Getting something amount implies that manual changes for exceptional conditions is definitely handled - eg, your marketing manager/accountant might wish to provide a one-off discount of $100 due to a late delivery. This really is trivial with negative values - just add another row, but difficult/hassle with special discounts
- You could have multiple discount amounts per invoice
- It's completely flexible - it features its own space to exist and become whatever it must be. Actually, I'd result in the discount another "product" (possibly even multiple items Body for every distinct discount reason, eg christmas, coupon, referral, etc.
- Using its own item, you can include grounds description as with every other "product" - eg "10% discount for having to pay cash" or whatever
- You do not need any special code or database posts! Just total products as before and print them around the invoice. "There's no spoon (discount)": It is simply another line item - what is simpler than no code/db changes needed?
- Not every products ought to be reduced - eg refunds, returns, monthly subscriptions (if relevant). It might be too complicated and it is unnecessary to represent the company logic of discount rates within the database. Leave the calculation etc within the application code, keep increase the risk for db
- Getting its very own item means the calculation could be randomly complex. What this means is no db maintenance because the complexity develops. It's a great deal simpler to keepOrmodify code than to keepOrmodify a database
- Finally, I effectively built an invoicing system, and that i required the "item" approach also it labored very well