Accounting Entity & Service questions

[Cameron Smith <ca...@yahoo.co.uk>]

Hi all, after developing our accounting application
based on OFBiz, we had to make the following fairly
minor alterations to certain entities and services.  
Is there a specific reason why they did not exist
before?  Perhaps I am missing something.

Otherwise, we could contribute these back to OFBiz as
patches.

AcctgTransAndEntries - we included the following
fields in this view entity, so we can pick up
everything handy in one find...
 *voucherRef
 *glJournalId
 *description

AcctgTrans & service postAcctgTrans - we added a
specialTimePeriodId field.  This is necessary for
opening and closing periods which notionally exist on
1st Jan or 31st Dec respectively.  The problem was
that the service postAcctgTrans would only decide
which CustomTimePeriod (and thus GlAccountHistory) to
post the transaction under, via the date.   We altered
postAcctgTrans to look at specialTimePeriodId - if it
is non-null, it will be used to define the period. 
Otherwise, period will be detected via
transactionDate, as normal.

UomConversionDated - we added an optional
organizationPartyId field here, as in a system doing
the accounting for multiple firms, each firm will have
its own policy and values for exchange rates.

I look forward to comments,
cameron



      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 

Re: Accounting Entity & Service questions

[David E Jones <jo...@hotwaxmedia.com>]

Cameron Smith wrote:
> Hi all, after developing our accounting application
> based on OFBiz, we had to make the following fairly
> minor alterations to certain entities and services.  
> Is there a specific reason why they did not exist
> before?  Perhaps I am missing something.
> 
> Otherwise, we could contribute these back to OFBiz as
> patches.

That would be great. The accounting component in OFBiz is still certainly a work in progress and there is a lot of functionality to flesh out.

> AcctgTransAndEntries - we included the following
> fields in this view entity, so we can pick up
> everything handy in one find...
>  *voucherRef
>  *glJournalId
>  *description

These sound fine. View entity definitions often change during implementation based on what the code needs. Actual entities sometimes change as well as it is difficult to be omniscient, as hard as we try... ;)

> AcctgTrans & service postAcctgTrans - we added a
> specialTimePeriodId field.  This is necessary for
> opening and closing periods which notionally exist on
> 1st Jan or 31st Dec respectively.  The problem was
> that the service postAcctgTrans would only decide
> which CustomTimePeriod (and thus GlAccountHistory) to
> post the transaction under, via the date.   We altered
> postAcctgTrans to look at specialTimePeriodId - if it
> is non-null, it will be used to define the period. 
> Otherwise, period will be detected via
> transactionDate, as normal.

I think this is okay, but it seems a little fishy to me. Even close to boundaries a date/time will be on one day or the other. What is the scenario you ran into where it would need to go into a different period? I'm pushing a little on this question because posting to the wrong period is a very big no-no in the accounting world.

> UomConversionDated - we added an optional
> organizationPartyId field here, as in a system doing
> the accounting for multiple firms, each firm will have
> its own policy and values for exchange rates.

Yes, I think that's a good additional feature for that entity/service.

-David