GL implementation - implemented Journal setup screens for error journal

[Jacopo Cappellato]

As a followup to the recent discussion about GL journals to group the
failed accounting transactions, I've implemented the base screens to
create/edit journals and to define the error journal in rev.597976
It is also possible to search for transactions and transaction entries
by journal id.

The details are here:

http://docs.ofbiz.org/x/sgw

Jacopo

[David E Jones]

This looks great Jacopo.

-David


On Nov 25, 2007, at 8:11 AM, Jacopo Cappellato wrote:

> As a followup to the recent discussion about GL journals to group  
> the failed accounting transactions, I've implemented the base  
> screens to create/edit journals and to define the error journal in  
> rev.597976
> It is also possible to search for transactions and transaction  
> entries by journal id.
>
> The details are here:
>
> http://docs.ofbiz.org/x/sgw
>
> Jacopo

[Jacopo Cappellato]

In rev. 599065 I've implemented some code to assign an accounting
transaction that fails when posted to the error journal.
However, while writing the code, I've realized that maybe we have to
move the glJournalId from the AcctgTrans to the AcctgTransEntry entity.

In fact, in theory the entries of an AcctgTrans could belong to
different organizationPartyId; and each journal is associated to one
organizationPartyId.

Can I move the field and modify the code?

Jacopo


Jacopo Cappellato wrote:

> As a followup to the recent discussion about GL journals to group the
> failed accounting transactions, I've implemented the base screens to
> create/edit journals and to define the error journal in rev.597976
> It is also possible to search for transactions and transaction entries
> by journal id.
>
> The details are here:
>
> http://docs.ofbiz.org/x/sgw
>
> Jacopo

[David E Jones]

I would give this proposed change a solid no.

The organizationPartyId being in both places could introduce errors,  
but the one on the journal is meant for the primary organization,  
preferably one that is a parent to all organizations referred to in  
AcctgTransEntry records (we could even add something to enforce that  
if it is a great concern).

Moving the journal (GlJournal) ID from the transaction (AcctgTrans) to  
the transaction entry (AcctgTransEntry) seems like it would defeat the  
purpose of a journal. A journal is a place to keep track of a set of  
transactions, usually temporarily while preparing them for posting.  
Once a set is all balanced out (checked through a trial balance) and  
everything that is in it needs to be, then the whole journal or any  
individual transaction in the journal can be posted. Splitting  
different entries in a single transaction into multiple journals would  
make it impossible to do a reliable trial balance of a journal or  
generally keep order in manual journal management efforts.

The concept of a journal comes from the days of 100% manual  
accounting, when journals were the day to day primary work books of  
book keepers. Transactions and entries were written in journals, and  
then individual transaction entries were copied into the ledger for  
each GL account, aka the "posting" process.

Some of that translated into electronic data structures, but of course  
the database driven ones are far more flexible and because we can have  
many dimensions in a single table and the management of the data  
relationships and reporting on or interpretation of them can be  
automated it is easier and cleaner use a slightly different structure  
and avoid redundancy. That is why we don't have journal transactions  
and gl entries, the AcctgTrans/Entry entities are both used for both  
places.

-David


On Nov 28, 2007, at 10:13 AM, Jacopo Cappellato wrote:

> In rev. 599065 I've implemented some code to assign an accounting  
> transaction that fails when posted to the error journal.
> However, while writing the code, I've realized that maybe we have to  
> move the glJournalId from the AcctgTrans to the AcctgTransEntry  
> entity.
>
> In fact, in theory the entries of an AcctgTrans could belong to  
> different organizationPartyId; and each journal is associated to one  
> organizationPartyId.
>
> Can I move the field and modify the code?
>
> Jacopo
>
>
> Jacopo Cappellato wrote:
>> As a followup to the recent discussion about GL journals to group  
>> the failed accounting transactions, I've implemented the base  
>> screens to create/edit journals and to define the error journal in  
>> rev.597976
>> It is also possible to search for transactions and transaction  
>> entries by journal id.
>> The details are here:
>> http://docs.ofbiz.org/x/sgw
>> Jacopo
>

[Jacopo Cappellato]

Thanks David,

your notes are of great help.
I'd say that we could improve the errorGlAccountId setup in the
following ways:

a) allow to enter the errorGlJournalId only if the party is the parent
of all the organizations and
a1) automatically propagate the value into the children's
errorGlJournalId or
a2) create a service that retrieves the error journal for a given
organization by looking at the error journal of the parent record

This is probably a low priority task, but I'm going to file it in Jira
in a few hours.

Jacopo


David E Jones wrote:

>
> I would give this proposed change a solid no.
>
> The organizationPartyId being in both places could introduce errors, but
> the one on the journal is meant for the primary organization, preferably
> one that is a parent to all organizations referred to in AcctgTransEntry
> records (we could even add something to enforce that if it is a great
> concern).
>
> Moving the journal (GlJournal) ID from the transaction (AcctgTrans) to
> the transaction entry (AcctgTransEntry) seems like it would defeat the
> purpose of a journal. A journal is a place to keep track of a set of
> transactions, usually temporarily while preparing them for posting. Once
> a set is all balanced out (checked through a trial balance) and
> everything that is in it needs to be, then the whole journal or any
> individual transaction in the journal can be posted. Splitting different
> entries in a single transaction into multiple journals would make it
> impossible to do a reliable trial balance of a journal or generally keep
> order in manual journal management efforts.
>
> The concept of a journal comes from the days of 100% manual accounting,
> when journals were the day to day primary work books of book keepers.
> Transactions and entries were written in journals, and then individual
> transaction entries were copied into the ledger for each GL account, aka
> the "posting" process.
>
> Some of that translated into electronic data structures, but of course
> the database driven ones are far more flexible and because we can have
> many dimensions in a single table and the management of the data
> relationships and reporting on or interpretation of them can be
> automated it is easier and cleaner use a slightly different structure
> and avoid redundancy. That is why we don't have journal transactions and
> gl entries, the AcctgTrans/Entry entities are both used for both places.
>
> -David
>
>
> On Nov 28, 2007, at 10:13 AM, Jacopo Cappellato wrote:
>
>> In rev. 599065 I've implemented some code to assign an accounting
>> transaction that fails when posted to the error journal.
>> However, while writing the code, I've realized that maybe we have to
>> move the glJournalId from the AcctgTrans to the AcctgTransEntry entity.
>>
>> In fact, in theory the entries of an AcctgTrans could belong to
>> different organizationPartyId; and each journal is associated to one
>> organizationPartyId.
>>
>> Can I move the field and modify the code?
>>
>> Jacopo
>>
>>
>> Jacopo Cappellato wrote:
>>> As a followup to the recent discussion about GL journals to group the
>>> failed accounting transactions, I've implemented the base screens to
>>> create/edit journals and to define the error journal in rev.597976
>>> It is also possible to search for transactions and transaction
>>> entries by journal id.
>>> The details are here:
>>> http://docs.ofbiz.org/x/sgw
>>> Jacopo
>>
>

[David E Jones]

On Nov 28, 2007, at 11:18 PM, Jacopo Cappellato wrote:

> Thanks David,
>
> your notes are of great help.
> I'd say that we could improve the errorGlAccountId setup in the  
> following ways:
>
> a) allow to enter the errorGlJournalId only if the party is the  
> parent of all the organizations and
> a1) automatically propagate the value into the children's  
> errorGlJournalId or
> a2) create a service that retrieves the error journal for a given  
> organization by looking at the error journal of the parent record

I'm not sure if I like any of these approaches... but I guess that's  
probably because I still think that if something like this happens it  
won't be all that big of a deal, ie there aren't really big errors  
that would be caused by it.

If we were to do something about it I'd prefer it just be a warning  
message when viewing a journal that an entry is associated with  
another organization... or something... I'm not even sure what we  
would warn about and what the user would do about it. Maybe it's just  
too late tonight? ;)

-David

> This is probably a low priority task, but I'm going to file it in  
> Jira in a few hours.
>
> Jacopo
>
>
> David E Jones wrote:
>> I would give this proposed change a solid no.
>> The organizationPartyId being in both places could introduce  
>> errors, but the one on the journal is meant for the primary  
>> organization, preferably one that is a parent to all organizations  
>> referred to in AcctgTransEntry records (we could even add something  
>> to enforce that if it is a great concern).
>> Moving the journal (GlJournal) ID from the transaction (AcctgTrans)  
>> to the transaction entry (AcctgTransEntry) seems like it would  
>> defeat the purpose of a journal. A journal is a place to keep track  
>> of a set of transactions, usually temporarily while preparing them  
>> for posting. Once a set is all balanced out (checked through a  
>> trial balance) and everything that is in it needs to be, then the  
>> whole journal or any individual transaction in the journal can be  
>> posted. Splitting different entries in a single transaction into  
>> multiple journals would make it impossible to do a reliable trial  
>> balance of a journal or generally keep order in manual journal  
>> management efforts.
>> The concept of a journal comes from the days of 100% manual  
>> accounting, when journals were the day to day primary work books of  
>> book keepers. Transactions and entries were written in journals,  
>> and then individual transaction entries were copied into the ledger  
>> for each GL account, aka the "posting" process.
>> Some of that translated into electronic data structures, but of  
>> course the database driven ones are far more flexible and because  
>> we can have many dimensions in a single table and the management of  
>> the data relationships and reporting on or interpretation of them  
>> can be automated it is easier and cleaner use a slightly different  
>> structure and avoid redundancy. That is why we don't have journal  
>> transactions and gl entries, the AcctgTrans/Entry entities are both  
>> used for both places.
>> -David
>> On Nov 28, 2007, at 10:13 AM, Jacopo Cappellato wrote:
>>> In rev. 599065 I've implemented some code to assign an accounting  
>>> transaction that fails when posted to the error journal.
>>> However, while writing the code, I've realized that maybe we have  
>>> to move the glJournalId from the AcctgTrans to the AcctgTransEntry  
>>> entity.
>>>
>>> In fact, in theory the entries of an AcctgTrans could belong to  
>>> different organizationPartyId; and each journal is associated to  
>>> one organizationPartyId.
>>>
>>> Can I move the field and modify the code?
>>>
>>> Jacopo
>>>
>>>
>>> Jacopo Cappellato wrote:
>>>> As a followup to the recent discussion about GL journals to group  
>>>> the failed accounting transactions, I've implemented the base  
>>>> screens to create/edit journals and to define the error journal  
>>>> in rev.597976
>>>> It is also possible to search for transactions and transaction  
>>>> entries by journal id.
>>>> The details are here:
>>>> http://docs.ofbiz.org/x/sgw
>>>> Jacopo
>>>
>
>

[Jacopo Cappellato]

David E Jones wrote:

>
> On Nov 28, 2007, at 11:18 PM, Jacopo Cappellato wrote:
>
>> Thanks David,
>>
>> your notes are of great help.
>> I'd say that we could improve the errorGlAccountId setup in the
>> following ways:
>>
>> a) allow to enter the errorGlJournalId only if the party is the parent
>> of all the organizations and
>> a1) automatically propagate the value into the children's
>> errorGlJournalId or
>> a2) create a service that retrieves the error journal for a given
>> organization by looking at the error journal of the parent record
>
> I'm not sure if I like any of these approaches... but I guess that's
> probably because I still think that if something like this happens it
> won't be all that big of a deal, ie there aren't really big errors that
> would be caused by it.
>
> If we were to do something about it I'd prefer it just be a warning
> message when viewing a journal that an entry is associated with another
> organization... or something... I'm not even sure what we would warn
> about and what the user would do about it. Maybe it's just too late
> tonight? ;)
>

No, no... what you says makes perfect sense!
Mine was only an attempt to resolve a minor issue with the current ui:
when a user is in the context of an organization he can only filters
transactions by journals associated with the organization...
But it is a minor issue and we will find a way to fix this in the future

Jacopo

> -David
>
>
>> This is probably a low priority task, but I'm going to file it in Jira
>> in a few hours.
>>
>> Jacopo
>>
>>
>> David E Jones wrote:
>>> I would give this proposed change a solid no.
>>> The organizationPartyId being in both places could introduce errors,
>>> but the one on the journal is meant for the primary organization,
>>> preferably one that is a parent to all organizations referred to in
>>> AcctgTransEntry records (we could even add something to enforce that
>>> if it is a great concern).
>>> Moving the journal (GlJournal) ID from the transaction (AcctgTrans)
>>> to the transaction entry (AcctgTransEntry) seems like it would defeat
>>> the purpose of a journal. A journal is a place to keep track of a set
>>> of transactions, usually temporarily while preparing them for
>>> posting. Once a set is all balanced out (checked through a trial
>>> balance) and everything that is in it needs to be, then the whole
>>> journal or any individual transaction in the journal can be posted.
>>> Splitting different entries in a single transaction into multiple
>>> journals would make it impossible to do a reliable trial balance of a
>>> journal or generally keep order in manual journal management efforts.
>>> The concept of a journal comes from the days of 100% manual
>>> accounting, when journals were the day to day primary work books of
>>> book keepers. Transactions and entries were written in journals, and
>>> then individual transaction entries were copied into the ledger for
>>> each GL account, aka the "posting" process.
>>> Some of that translated into electronic data structures, but of
>>> course the database driven ones are far more flexible and because we
>>> can have many dimensions in a single table and the management of the
>>> data relationships and reporting on or interpretation of them can be
>>> automated it is easier and cleaner use a slightly different structure
>>> and avoid redundancy. That is why we don't have journal transactions
>>> and gl entries, the AcctgTrans/Entry entities are both used for both
>>> places.
>>> -David
>>> On Nov 28, 2007, at 10:13 AM, Jacopo Cappellato wrote:
>>>> In rev. 599065 I've implemented some code to assign an accounting
>>>> transaction that fails when posted to the error journal.
>>>> However, while writing the code, I've realized that maybe we have to
>>>> move the glJournalId from the AcctgTrans to the AcctgTransEntry entity.
>>>>
>>>> In fact, in theory the entries of an AcctgTrans could belong to
>>>> different organizationPartyId; and each journal is associated to one
>>>> organizationPartyId.
>>>>
>>>> Can I move the field and modify the code?
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> Jacopo Cappellato wrote:
>>>>> As a followup to the recent discussion about GL journals to group
>>>>> the failed accounting transactions, I've implemented the base
>>>>> screens to create/edit journals and to define the error journal in
>>>>> rev.597976
>>>>> It is also possible to search for transactions and transaction
>>>>> entries by journal id.
>>>>> The details are here:
>>>>> http://docs.ofbiz.org/x/sgw
>>>>> Jacopo
>>>>
>>
>>
>