David, all,
I'm really interested in knowing more about the design for journal
management.
I did some research (existing data model and services) and it seems to
me that:
* a journal (GlJournal) is used to group together a set of accounting
transactions (AcctgTrans)
* a journal can be used to verify the correctness of all the
transactions associated to it (there is a service to check the trial
balance of a journal)
* a journal can be used to quickly post all the transactions associated
to it in one batch
My questions are:
1) who should create a journal and when? automatically by the system? by
users? or manager?
2) can a transaction be created without specifying a journal?
3) can a journal contain both posted and unposted transactions?
4) should we create a GlJournal.journalTypeId field to define an error
journal for transactions that failed auto-posting (as suggested by
David) and possibly other types (e.g. to group automatically posted
transactions from manually posted ones)
I've also created a new Wiki page to help to get this ball rolling:
http://docs.ofbiz.org/x/sgw
I'll do my best to add relevant information there as well.
Jacopo
David E Jones wrote:
On Nov 23, 2007, at 12:02 AM, [EMAIL PROTECTED] wrote:
I have some strong feelings about how Si has done this though. My
primary
concern is that some organizations prefer to post to the G/L in real time
and others prefer to do batch review/post. I hope we can do something
like
have a property or PartyAcctPreference that flips the switch.
The original design I did for the accounting stuff includes journal
management for un-posted transactions. The implementation was supposed
to put transactions that failed auto-posting into an error journal to be
manually reviewed, but if there was a switch like this somewhere we
could certainly use the journaling feature for what you are describing,
and it could even be configured to queue up certain types of
transactions but not others (like all purchase invoices for example, but
not sales invoices or inventory changes due to the extreme volume;
assuming a company where that is the case for sake of example).
I would only like to be involved if we can agree to spend the time to do
user-friendly, intuitive screens.
Feedback on screen designs, probably starting with putting down end-user
processes to support (use cases if you will) would be great.
-David
