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
