Thanks Pierre,

Good and clear arguments!

But do you really need to show all your medals in each email :) ?

Jacques


Le 02/09/2018 à 10:14, Pierre Smits a écrit :
It is great to see that after approx. 2 years some viewpoints are swinging
towards having 3rd party solutions (the payment and shipment integrations)
disentangled from resp. accounting and product. With these disentanglements
these base components will be more business-domain oriented (process), and
easier to maintain and explain (documentation-wise).

Configuration- and overview-wise, each 3rd party solution integration
should be contained in its own component, feeding only transactional data
to the base application (payments to accounting, shipment-handling to
warehousing).
With the 3rd party payment integration solution MultSafepay, I outlined in
2016 how this could be achieved (see [1] and [2])

[1] https://github.com/ORRTIZ/omultisafepay
[2] https://github.com/ORRTIZ/omultisafepay/wiki/How-to-implement




Best regards,

Pierre Smits

Apache Trafodion <https://trafodion.apache.org>, Vice President
Apache Directory <https://directory.apache.org>, PMC Member
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer

On Sun, Sep 2, 2018 at 9:33 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Taher,

Obviously AR and AP are parts of accounting, but they should not be shown
at the application level.

At the very least they should sub-menus of accounting. This would give
some air to the apps tabs, w/o separating them.

Then come the thirdparty accounting elements which are clearly defined in
java/org/apache/ofbiz/accounting/thirdparty but are also scattered in
other places (services, etc.)

I totally agree with Nicolas that they should not be part of accounting.
They are mostly payments means, but that does not mean they should be in
the accounting applications, they are 3rd parties elements.

Separating them in plugins would be a good thing, OFBIZ-7415 is a WIP
aimed at that.

Moreover some are outdated, if not deprecated. Ideal for instance should
be moved to the Attic:  OFBIZ-5303 is a WIP.

Jacques



Le 01/09/2018 à 20:19, Taher Alkhateeb a écrit :

Hi Nicolas,

I'm not an expert accountant, but if I'm not mistaken then accounts
receivable and accounts payable are a fundamental accounting function
that comes with any accounting system, and perhaps the only reason we
notice them is because they are defined as separate webapps.

I have no strong opinion, but I would suggest perhaps an opposite
direction, as in integrating the the accounts receivable and payable
to the accounting component. I don't understand why they were
separated to different webapps in the first place.
On Sat, Sep 1, 2018 at 3:22 PM Jacques Le Roux
<jacques.le.r...@les7arts.com> wrote:

That's a great idea Nicolas!

+1

Jacques


Le 01/09/2018 à 14:09, Nicolas Malin a écrit :

Hello,

After analyze the webapp accounting AR and accounting AP, I didn't see
any logic to keep them on the functional framework. The main webapp is
accounting, AP/AR are a business orientation that we can load at demand
through plugins.

Your opinion ?

PS: In the same idea we can move on separate plugin all thirdparty
accounting element to slimdown the accounting component and must harness the
plugin system :)

Nicolas



Reply via email to