|
|
|
Forum Guru
 
Group: Forum Members
Last Login: 2010-05-16 05:14:12
Posts: 63,
Visits: 355
|
|
| Does some one share code/sell code for General Ledger(Double Entry) I need this for one of my applications that I am developing in ECO You may send me the details on venks at Vsnl.com
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 20:20:07
Posts: 241,
Visits: 7 537
|
|
| I have one that I made but I need to know more about the intricacies of exactly what kind of double entry accounting you want to make you a sample. There are a few things that complaicte it like: number of expected rows per account which determine how much derrive aggregation to do, and what are the account relationships you want to have with the ledger. Do you need transaction history? IMHO, the best thing to do is make as simple of a DE model as you can get by with for your direct needs - I guess if you are making a full blown accounting system that may have to include everything. Maybe you can map out a simple use case for me. What kind of accounts, transactions and ledgers - that sore of stuff. Then I will give you something that will at least be a starting point. Of course, I welcome everyone to take the sample and ripe it apart so I can learn better ways to do it too.
Rick Weyrauch
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: 2010-05-16 05:14:12
Posts: 63,
Visits: 355
|
|
I am not looking for a full blown accounting system.
The way I look it ,I require the following to start with
-Daily Entries under various accounts based on a double entry system
-Facility to prepare bills & reflect it in the ledger
-Payment of bills when made ,to be recorded in the ledger
-Facility to prepare Balance sheet on a monthly basis
-Bank reconciliation statement
-Audit trail of all transactions
I am not an expert accountant.May be more issues will come up as I progress further
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 20:20:07
Posts: 241,
Visits: 7 537
|
|
| Sorry this took so long. I had to find some time because I needed to extract if from a large solution and of course I wanted to do some things a little different. Due to that, there may be an error or omission or two. Please feel free to ask questions if you see something that does not look right (you will notice this is only the model and no sample usage) I did it this way for a number of reasons: 1) I have other kinds of DebitCreditAccounts that are not cash accounts. 2) I have multiple types of CashAccounts that are always either a Credit or a Debit account (1 account should never be both IMHO) 3) I needed to be able to reference the "other account" while I was displaying a list of Events on a given account - I never show a list of CashEvents but only ever the NetCashEvent (Note 1). This way I always get the proper relative value displayed, always have the "other account" available in the listing and I can store all of my CashEvents as positive vlaues. After all, the Event was for an amount of money, not for negative money, just sometimes that value is a bad thing. I realize some (many) will disagree with this but it worked out very well in my project. Note 1: I add all the derrivable attributes to the NetCashEvent because that is the list I always use in my UI. It gives you a very benefitial view of the transaction list. I have used this mechanism many times - just about every time I need to know things about "other like items". I also added the historical part a little different that I have it in my real project. This way is more in line with what I came to use for a Archiving pattern in later projects. Hope this helps and sorry for the delay.
Rick Weyrauch
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 20:20:07
Posts: 241,
Visits: 7 537
|
|
| There are a few things that I forgot to do in my sample: 1) All of the attributes of a CashEvent should be SaveAction = Freeze. This makes the event Immutable. 2) The CashEvents and HistoricalCashEvents lists of CashAccount and CashEvent should really be SaveAction = Freeze too. And you should have a derrived list, typicallly OderBy = CashEvent.Date. This also makes the list membership Immutable. The derrived list is a union of both CashEvents and HistoricCashEvents. 3) CashAccount, or some Supervisor class (depends on your business rules), should have a PostEvent(CashEvent ce) method to add new events. 4) PostedOnDate of CashEvent should be: self.Date.Date = self.PostDate.Date In fact, most every part of this model should be SaveAction = Freeze. Maybe someone can chime in with other things one should do to make a WriteOnceOnly environment.
Rick Weyrauch
|
|
|
|