Model db for easy accounting database

I have a question that rather no one has asked till now , well here goes my question In the simplest I use that word very insecurely of cases, how would you guys form a database in which refunds and overpayments be permitted at the same time as keeping the original charge ,payment transactions just as there are , in view of the fact that most of these entities or transactions have a many-to-many connection, things are seeming a bit more complicated than I previously thought so please help me according .

Well, I need to say that this thread made me seriously think for an 1 hour before I reply you but , as far as I have understood the question I have been able make out an solution for it , so how about adding a new table/row to it as that might help you to gain a better control over it , as that extra row/column would be named as credit = payment done by member and the charges that are paid by them ., so that would just auto –calculate the things .

In my opinion I don ‘ think storing that high values would be an better option for you as that might just miss all the normalization which need to be done when you are on it ,as the I have a analogous application in progress and I recalculate it every time when I input an value in it . The concern with storing the rate is that it constantly desires to be accurate. If you at one spot you overlook to modify the value, you'll have a massive mess and it will be tough to fix the wrong numbers.

This is what I can recall from the last accountant software that I made for an shopkeeper to keep an detailed trap on it , I made a new table called table 1 and they had all the necessary filed in to that table ( mind you I am using SQL ) here and then give each table an unique id to it and then I used an sql command to

Code:

---

Select Sum (Credit)-Sum (Debit) from table1 Where Account Number ='134323' And Type='labor’

---

While the other fields may vary according to your requirements .

Thanks for the replies all. Because a bit of an update, we're officially having a "back to the drawing board" gathering late this week (or early next). After the preceding tries and it has been unwavering that this purpose is much more multifaceted than the characteristic creep made obvious. That supposed, the whole thing is back on the table, together with growth framework, etc.