On Feb 7, 2008, at 5:46 AM, Jacopo Cappellato wrote:
David,
thank you for your valuable feedback; please see my comments inline:
David E Jones wrote:
It sounds like Adrian's comments are a great scenario to address,
but probably only one of various that we should target.
In general with this sort of thing (or designing anything really) I
really like the idea of two goals:
1. make it as "fool-proof" as possible; fool-proof is kind of a
funny term and actually I prefer to avoid the opposite, ie make it
not-error-prone
2. make it easy to do setup and maintain, including as much as
possible having the system do the most obvious thing by default
(that's obviously subjective, but narrowing the target audience can
help significantly)
In this case this is why I would favor for most settings have child
organizations use parent organization settings if that setting is
not present for the child. These should be considered on a granular
level, like fields on the PartyAcctgPreference entity rather than
looking for the entire record.
We can (rather) easily implement this behavior for the
PartyAcctgPreference entity; but I fear that applying this in
general to all the GL settings is a rather complex task to implement
and, at least with the current status of the user interface, also
difficult to understand for the user.
I mean that there are already a lot of different entities (some of
them organization specific and some of them global) used to map
account types to real account ids. If, for each of the lookup (if it
fails), we have to lookup at the same parent organization setting,
then in my opinion we should "expose" this to the user interface as
well: showing the division specific setting if exists, the parent
division setting, and the global setting all in the same screen...
not easy to implement.
Also, should we address trees with more than one level (company-
>division->subdivision)?
Any ideas on how we can simplify this effort?
The easiest simplification would be to start with the code that looks
for parent and default settings, and not worry about the UI for a
while. In the UI (would be in various places) we could simply have a
note about this defaulting pattern.
We could eventually create a UI that made this more clear, with forms
for the current Int. Org. and all parent IntOrgs and any other default
structures or whatever is applicable. Would be nice, but maybe not
necessary with a little documentation.
-David
Some things may not default very well, like the chart of
accounts... but defaulting may help there too I guess. Let me think
out loud...
The general idea for the pattern is that a single master chart of
accounts is used for the entire "Company" and those would be
associated with the top-level organization. Each sub-organization
would have its own chart of accounts that is selected from the
global one for the entire organization. Unless there are not sub-
organizations the "root" organization would generally not have
transactions posted against it.
In that sense it would be nice to reduce maintenance and avoid run-
time errors to have some defaulting in place. In fact if some
GlAccount were a default for the parent organization, but not
mapped to the child org, then we'd have to do this sort of
defaulting to avoid a run-time error.
I hope that makes sense...
-David
On Jan 25, 2008, at 9:06 AM, Jacopo Cappellato wrote:
Adrian,
thanks for your comments:
Adrian Crum wrote:
Jacopo,
I was talking to our accountant about this the other
day. He said in a manual system, each division would
be responsible for maintaining its own GL, and the
results of those division's GLs would be posted to the
parent company's GL.
Is this done when the financial time period is closed (e.g. at the
end of the year), right?
In other words, the divisions would have all of the
journal detail, but only their ending balances, etc
would be posted to the parent company's GL.
Ok, this is helpful; however my question was more about the way to
setup the accounting setup (gl mappings, preferences etc...) for
each divisions.
Jacopo
-Adrian
--- Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
What is the best way to implement the ability to
setup default GL settings for divisions for a certain company?
For example, in the OFBiz demo data, we have the
"Company" company and some division (internal organizations,
part of
Company): MARKETING, ACCOUNTING, SALES, DEV, TESTING.
After that we setup the GL settings for the main
company ("Company"), what should we do to implement the GL
settings for
its divisions?
What are the data that we have to duplicate?
Recently David Jones suggested an interesting
approach for the PartyAcctgPreference entity: if the record is
missing for a division, then get the one of its parent; in this
way we can
define, in a central place one Error Journal for all the
divisions, one
currency etc...
We could also share the same approach for all the Gl
type/account mappings... but here things get tricky: how can we
know if we have to look at the parent's settings? Can we use the
existence of the PartyAcctgPreference as a way to know if there
are
settings for the division or not?
However there are records that simply need to be
copied over: GlAccountOrganization (and possibly others) is a
good example; how should we implement this? Automatically copy the
record, when it is created, to all the divisions?
There are many other similar issues and now I'm
start wondering if it is not simply better to just provide some
import/export
features that facilitate the process of cloning an accounting
setup from one company/division to another one.
Hmmm... so many questions... please help.
Jacopo
____________________________________________________________________________________
Looking for last minute shopping deals? Find them fast with
Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
