On Nov 23, 2007, at 3:39 AM, Jacopo Cappellato wrote:

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?

This would depend on the business process that is implemented on top of the data model and these lower level services that exist.

In my reply to Skip's message I described two possible scenarios: one for an error journal and another for a manual posting (for review or whatever) journal.

2) can a transaction be created without specifying a journal?

Yes. In fact I think this is the only thing done in the opentaps auto- posting services, I don't think they use journals at all.

3) can a journal contain both posted and unposted transactions?

Yes. The posting status is on the AcctgTrans entity, so is independent of the journal.

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)

There may already be something for this, but if not then yes it would make sense just to make the UI easier. From the code and configuration perspective I think the current approach used elsewhere (and that should be applied here if not already) is to specify each journal by ID for a particular purpose, like journal 12345 is the error journal for organization 54321.

-David


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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to