Hi Bruno:
Understood. I was just addressing Adrian's comment. IMO, component
dependency is all about business processes. What else would make one
piece of code dependent upon another? How would you know if there is or
should be a dependency unless you analyzed the process behind the logic?
Regards,
Ruth
Bruno Busco wrote:
Ruth,
the discussion was about *components dependence* not about a
particular business process.
We are addressing the issue that it seems that right now it is not
possible to remove the accounting component while leaving the party
component into OFBiz.
This should be because the party should be used for things different
from what accounting component is designed for as so an installation
where party is present and not accounting should definitively be
possible.
Please help us stay focused ot the subject. We have already
difficulties to understand each other.
-Bruno
2010/2/6 Ruth Hoffman <[email protected]>:
Hello Adrian:
Not necessarily. An "invoice" is a legal document. The use of an invoice to
bill a "party" is a business process. Perhaps you meant to say that the
creation of an invoice implies at least two parties?
Regards,
Ruth
Adrian Crum wrote:
I didn't say that. I asked "How do you create an invoice without a party?"
An invoice implies two parties - the party being billed and the party doing
the billing.
-Adrian
--- On Sat, 2/6/10, Abdullah Shaikh <[email protected]> wrote:
From: Abdullah Shaikh <[email protected]>
Subject: Re: party component dependency on accounting
To: [email protected]
Date: Saturday, February 6, 2010, 12:30 AM
I guess we can remove this kind on
interdependency too by having services to
communicate with other components instead of using a class
of some other
component to directly call a method.
As Adrian said, we can create an invoice without party, but
we can have
services using which the account & party component can
interact, this way
the components can work independent of each other and can
interact with
other component only when required using services.
For example party is dependent on invoice, and to interact
with invoice a
class of invoice component is being used, in this case its
necessary to have
the invoice component too, and if interaction would have
been using
services, the party component would have compiled/run
successfully and would
have failed only when services related to invoice are
required and for this
the user could add the invoice component.
I don't know if I am missing something, but I feel that the
interaction
between components using services would help in eliminating
the component
interdependency.
- Abdullah
On Sat, Feb 6, 2010 at 1:45 PM, Adrian Crum <[email protected]>
wrote:
Also keep in mind that interdependency between some
components is
intentional and sometimes necessary. Think about it -
how do you create an
invoice without a party?
-Adrian
--- On Sat, 2/6/10, Jacopo Cappellato
<[email protected]>
wrote:
From: Jacopo Cappellato <[email protected]>
Subject: Re: party component dependency on
accounting
To: [email protected]
Date: Saturday, February 6, 2010, 12:01 AM
Hi Christopher,
no, the PartyAcctgPreference entity is defined in
the
accounting component (it is used to define
accounting
preferences for a given organization) and so it
cannot be
moved to the party component.
Kind regards,
Jacopo
On Feb 5, 2010, at 11:46 PM, Christopher Snow
wrote:
In the party component, there is a view
dependent on
the accounting component:
<view-entity
entity-name="PartyAcctgPrefAndGroup"
package-name="org.ofbiz.party.party"
title="PartyAcctgPreference and
PartyGroup
Entity">
<member-entity
entity-alias="PTYACCPREF"
entity-name="PartyAcctgPreference"/>
<member-entity
entity-alias="PTYGROUP"
entity-name="PartyGroup"/>
<alias
entity-alias="PTYACCPREF"
name="partyId"/>
<alias
entity-alias="PTYACCPREF"
name="baseCurrencyUomId"/>
<alias
entity-alias="PTYGROUP"
name="groupName"/>
<view-link
entity-alias="PTYACCPREF"
rel-entity-alias="PTYGROUP">
<key-map
field-name="partyId"/>
</view-link>
</view-entity>
Should this view be relocated to the
accounting
component?
Many thanks in advance...
