Accounting Entity & Service questions

[Cameron Smith-6]

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/ 

[David E Jones]

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

[Cameron Smith-6]

David, just to clear up your worry about
AcctgTrans.specialTimePeriodId.

It is not in fact the case that a certain date only
falls within one period.  At least within the Moz
acctg system, there are 16 accounting months - one for
opening, and three for closing.

Here's a concrete example.  Imagine our accounting
year is congruent with the calendar year.  Imagine our
firm is an off-licence (liquor store).

On the 1st of Jan, the firm sells a load of booze to
revellers.   Stock diminishes and cash increases.

The next working day, the accountant comes in to start
the accounting for this year.

First of all, he posts some opening transactions, to
carry over results from last year, and also any
pending assets and liabilities (e.g. a rent bill
received in December but which is paid in advance so
applies to Jan).  These should go in the opening
period.

Then he posts the receipts from the alcohol sales.
These should go in the period representing the
calendar month of January.

Same goes for transactions on 31st of December.

Yes, posting in the wrong period is v. bad, but that
is why most accounting systems allow the user to
explicitly select the period if needs be.  This is
what we do, and the UI has a fair bit of validation to
make sure they do not make an impossible choice.

Equally, in the altered postAcctgTrans, the
transaction can only be posted in one FISCAL_MONTH -
it cannot be both in the opening period and in the Jan
period, for instance.

Does this explanation help?

cameron


      ___________________________________________________________
Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for
your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html