Move accounting ap and ar to plugin ?

[Nicolas Malin-2]

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

--
logoNrd <https://nereide.fr/>
        Nicolas Malin
The apache way <http://theapacheway.com/> : *Charity* Apache’s mission
is providing software for the public good.
[hidden email]
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
<http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>

[Jacques Le Roux]

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
>

[taher]

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
<[hidden email]> 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
> >
>

[Jacques Le Roux]

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
> <[hidden email]> 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
>>>

[Pierre Smits-3]

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 <
[hidden email]> 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
>> <[hidden email]> 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
>>>>
>>>>
>

[Jacques Le Roux]

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 <
> [hidden email]> 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
>>> <[hidden email]> 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
>>>>>
>>>>>

[Julien NICOLAS]

+1


Le 02/09/2018 à 10:36, Jacques Le Roux a écrit :
> But do you really need to show all your medals in each email :) ?

[Jacopo Cappellato-5]

On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <[hidden email]>
wrote:

> 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 ?
>

As far as I remember, the AP/AR web applications were created as a
specialized versions of the user interfaces for some business processes
(account receivables and account payables related tasks) that were already
available in the more general "accounting" web application. I like the idea
to move them to plugins but, as mentioned by Taher, we should also verify
if there are specific features that are available only in the AP/AR version
and not in the "accounting" application: if we find some, then we should
migrate the basic artifacts to the main "accounting" app and then move the
specialized screens to plugins. I think such cases will be rare but one
possible candidate is the "batch payment" functionality of the AR app.


>
> 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 :)
>

+1

Jacopo


>
> Nicolas
>
>

[jsmith_dev]

Hi All,

Is there any module / code / notion of subscription billing?

As in automating SaaS accounting (on the service provider, SaaS producer
side) ??

If the module system is evolved - how might we be able to put something
like that together there? (If it doesn’t already exist in Ofbiz today)

Regards,

Julian Smith,

Blockfreight, Inc.
535 Mission street 14th floor
San Francisco, CA 94205

[Sharan Foga]

Hi All

I really like the idea of making AR and AP plugins. I’ve taken a quick look and from what I can see all of the functionality in them are just specialised filters of what is already available in the accounting menu.

It looks like our accounting module was originally created with all possible accounting functions combined into one module so we have  GL, AR, AP etc already all included as part of accounting.

Many users are used to having an accounting module with the accounting functions broken down into specialist submodules  and if people can’t see or find them easily they don’t think they exist so I can understand why the AR and AP applications were added. That being said – why keep this type of duplication in our framework? I think this is something that could be optional and so more useful as a plugin.

Having different implementations of base functionality is exactly where the plugins could help us give users what they are looking.

Thanks
Sharan

On 2018/09/03 08:11:26, Jacopo Cappellato <[hidden email]> wrote:

> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <[hidden email]>
> wrote:
>
> > 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 ?
> >
>
> As far as I remember, the AP/AR web applications were created as a
> specialized versions of the user interfaces for some business processes
> (account receivables and account payables related tasks) that were already
> available in the more general "accounting" web application. I like the idea
> to move them to plugins but, as mentioned by Taher, we should also verify
> if there are specific features that are available only in the AP/AR version
> and not in the "accounting" application: if we find some, then we should
> migrate the basic artifacts to the main "accounting" app and then move the
> specialized screens to plugins. I think such cases will be rare but one
> possible candidate is the "batch payment" functionality of the AR app.
>
>
> >
> > 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 :)
> >
>
> +1
>
> Jacopo
>
>
> >
> > Nicolas
> >
> >
>

[Sharan Foga]

On 2018/09/03 08:11:26, Jacopo Cappellato <[hidden email]> wrote:

> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <[hidden email]>
> wrote:
>
> > 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 ?
> >
>
> As far as I remember, the AP/AR web applications were created as a
> specialized versions of the user interfaces for some business processes
> (account receivables and account payables related tasks) that were already
> available in the more general "accounting" web application. I like the idea
> to move them to plugins but, as mentioned by Taher, we should also verify
> if there are specific features that are available only in the AP/AR version
> and not in the "accounting" application: if we find some, then we should
> migrate the basic artifacts to the main "accounting" app and then move the
> specialized screens to plugins. I think such cases will be rare but one
> possible candidate is the "batch payment" functionality of the AR app.

I thought the batch payment was one of the options for the Payment Group which is on the main accounting menu so any processing can be done from there too.

Thanks
Sharan

>
>
> >
> > 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 :)
> >
>
> +1
>
> Jacopo
>
>
> >
> > Nicolas
> >
> >
>

[taher]

Very interesting thoughts Sharan, Jacopo and everyone.

Thinking about this some more, and given that -- as I understood it --
the AP and AR are really nothing more than specialized filtration
screens of the general purpose screens in the accounting webapp, then
why not delete them? Are people depending on these screens? Is it
worth writing and maintaining a plugin for it?
On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga <[hidden email]> wrote:

>
>
>
> On 2018/09/03 08:11:26, Jacopo Cappellato <[hidden email]> wrote:
> > On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <[hidden email]>
> > wrote:
> >
> > > 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 ?
> > >
> >
> > As far as I remember, the AP/AR web applications were created as a
> > specialized versions of the user interfaces for some business processes
> > (account receivables and account payables related tasks) that were already
> > available in the more general "accounting" web application. I like the idea
> > to move them to plugins but, as mentioned by Taher, we should also verify
> > if there are specific features that are available only in the AP/AR version
> > and not in the "accounting" application: if we find some, then we should
> > migrate the basic artifacts to the main "accounting" app and then move the
> > specialized screens to plugins. I think such cases will be rare but one
> > possible candidate is the "batch payment" functionality of the AR app.
>
> I thought the batch payment was one of the options for the Payment Group which is on the main accounting menu so any processing can be done from there too.
>
> Thanks
> Sharan
>
> >
> >
> > >
> > > 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 :)
> > >
> >
> > +1
> >
> > Jacopo
> >
> >
> > >
> > > Nicolas
> > >
> > >
> >

[Nicolas Malin-2]

Yeah thanks all for your constructive return :)

I saw two specific features: commission invoicing and batch payment. As
Sharan spot it, all functional process are present on the accounting
component, I have the feeling that we are all agree on this idea with a
attention to doesn't lost important part possibly hidden on AP/AR.

Taher, I have two reasons to don't just delete them:
* The code current works and seem to be easy to maintain
* Load in official plugins an example on business screen who simplify
generic screen with potential problem that can be raise by the split :)

I will try to split it.
Thanks

Nicolas


On 03/09/2018 13:07, Taher Alkhateeb wrote:

> Very interesting thoughts Sharan, Jacopo and everyone.
>
> Thinking about this some more, and given that -- as I understood it --
> the AP and AR are really nothing more than specialized filtration
> screens of the general purpose screens in the accounting webapp, then
> why not delete them? Are people depending on these screens? Is it
> worth writing and maintaining a plugin for it?
> On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga <[hidden email]> wrote:
>>
>>
>> On 2018/09/03 08:11:26, Jacopo Cappellato <[hidden email]> wrote:
>>> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <[hidden email]>
>>> wrote:
>>>
>>>> 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 ?
>>>>
>>> As far as I remember, the AP/AR web applications were created as a
>>> specialized versions of the user interfaces for some business processes
>>> (account receivables and account payables related tasks) that were already
>>> available in the more general "accounting" web application. I like the idea
>>> to move them to plugins but, as mentioned by Taher, we should also verify
>>> if there are specific features that are available only in the AP/AR version
>>> and not in the "accounting" application: if we find some, then we should
>>> migrate the basic artifacts to the main "accounting" app and then move the
>>> specialized screens to plugins. I think such cases will be rare but one
>>> possible candidate is the "batch payment" functionality of the AR app.
>> I thought the batch payment was one of the options for the Payment Group which is on the main accounting menu so any processing can be done from there too.
>>
>> Thanks
>> Sharan
>>
>>>
>>>> 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 :)
>>>>
>>> +1
>>>
>>> Jacopo
>>>
>>>
>>>> Nicolas
>>>>
>>>>

[taher]

Sounds good to me then. +1

On Mon, Sep 3, 2018, 4:32 PM Nicolas Malin <[hidden email]> wrote:

> Yeah thanks all for your constructive return :)
>
> I saw two specific features: commission invoicing and batch payment. As
> Sharan spot it, all functional process are present on the accounting
> component, I have the feeling that we are all agree on this idea with a
> attention to doesn't lost important part possibly hidden on AP/AR.
>
> Taher, I have two reasons to don't just delete them:
> * The code current works and seem to be easy to maintain
> * Load in official plugins an example on business screen who simplify
> generic screen with potential problem that can be raise by the split :)
>
> I will try to split it.
> Thanks
>
> Nicolas
>
>
> On 03/09/2018 13:07, Taher Alkhateeb wrote:
> > Very interesting thoughts Sharan, Jacopo and everyone.
> >
> > Thinking about this some more, and given that -- as I understood it --
> > the AP and AR are really nothing more than specialized filtration
> > screens of the general purpose screens in the accounting webapp, then
> > why not delete them? Are people depending on these screens? Is it
> > worth writing and maintaining a plugin for it?
> > On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga <[hidden email]> wrote:
> >>
> >>
> >> On 2018/09/03 08:11:26, Jacopo Cappellato <
> [hidden email]> wrote:
> >>> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <[hidden email]
> >
> >>> wrote:
> >>>
> >>>> 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 ?
> >>>>
> >>> As far as I remember, the AP/AR web applications were created as a
> >>> specialized versions of the user interfaces for some business processes
> >>> (account receivables and account payables related tasks) that were
> already
> >>> available in the more general "accounting" web application. I like the
> idea
> >>> to move them to plugins but, as mentioned by Taher, we should also
> verify
> >>> if there are specific features that are available only in the AP/AR
> version
> >>> and not in the "accounting" application: if we find some, then we
> should
> >>> migrate the basic artifacts to the main "accounting" app and then move
> the
> >>> specialized screens to plugins. I think such cases will be rare but one
> >>> possible candidate is the "batch payment" functionality of the AR app.
> >> I thought the batch payment was one of the options for the Payment
> Group which is on the main accounting menu so any processing can be done
> from there too.
> >>
> >> Thanks
> >> Sharan
> >>
> >>>
> >>>> 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 :)
> >>>>
> >>> +1
> >>>
> >>> Jacopo
> >>>
> >>>
> >>>> Nicolas
> >>>>
> >>>>
>
>

[Rishi Solanki]

+1 for moving AR/AP to plugins. And big +1 for Jacopo remarks.


--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com
www.hotwax.co


On Mon, Sep 3, 2018 at 7:15 PM Taher Alkhateeb <[hidden email]>
wrote:

> Sounds good to me then. +1
>
> On Mon, Sep 3, 2018, 4:32 PM Nicolas Malin <[hidden email]>
> wrote:
>
> > Yeah thanks all for your constructive return :)
> >
> > I saw two specific features: commission invoicing and batch payment. As
> > Sharan spot it, all functional process are present on the accounting
> > component, I have the feeling that we are all agree on this idea with a
> > attention to doesn't lost important part possibly hidden on AP/AR.
> >
> > Taher, I have two reasons to don't just delete them:
> > * The code current works and seem to be easy to maintain
> > * Load in official plugins an example on business screen who simplify
> > generic screen with potential problem that can be raise by the split :)
> >
> > I will try to split it.
> > Thanks
> >
> > Nicolas
> >
> >
> > On 03/09/2018 13:07, Taher Alkhateeb wrote:
> > > Very interesting thoughts Sharan, Jacopo and everyone.
> > >
> > > Thinking about this some more, and given that -- as I understood it --
> > > the AP and AR are really nothing more than specialized filtration
> > > screens of the general purpose screens in the accounting webapp, then
> > > why not delete them? Are people depending on these screens? Is it
> > > worth writing and maintaining a plugin for it?
> > > On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga <[hidden email]> wrote:
> > >>
> > >>
> > >> On 2018/09/03 08:11:26, Jacopo Cappellato <
> > [hidden email]> wrote:
> > >>> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <
> [hidden email]
> > >
> > >>> wrote:
> > >>>
> > >>>> 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 ?
> > >>>>
> > >>> As far as I remember, the AP/AR web applications were created as a
> > >>> specialized versions of the user interfaces for some business
> processes
> > >>> (account receivables and account payables related tasks) that were
> > already
> > >>> available in the more general "accounting" web application. I like
> the
> > idea
> > >>> to move them to plugins but, as mentioned by Taher, we should also
> > verify
> > >>> if there are specific features that are available only in the AP/AR
> > version
> > >>> and not in the "accounting" application: if we find some, then we
> > should
> > >>> migrate the basic artifacts to the main "accounting" app and then
> move
> > the
> > >>> specialized screens to plugins. I think such cases will be rare but
> one
> > >>> possible candidate is the "batch payment" functionality of the AR
> app.
> > >> I thought the batch payment was one of the options for the Payment
> > Group which is on the main accounting menu so any processing can be done
> > from there too.
> > >>
> > >> Thanks
> > >> Sharan
> > >>
> > >>>
> > >>>> 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 :)
> > >>>>
> > >>> +1
> > >>>
> > >>> Jacopo
> > >>>
> > >>>
> > >>>> Nicolas
> > >>>>
> > >>>>
> >
> >
>

[Deepak Dixit-3]

+1 for moving AP/AR to plugins.
We can open jira ticket for the same.

On Mon, Sep 3, 2018 at 7:02 PM, Nicolas Malin <[hidden email]>
wrote:

> Yeah thanks all for your constructive return :)
>
> I saw two specific features: commission invoicing and batch payment. As
> Sharan spot it, all functional process are present on the accounting
> component, I have the feeling that we are all agree on this idea with a
> attention to doesn't lost important part possibly hidden on AP/AR.
>
> Taher, I have two reasons to don't just delete them:
> * The code current works and seem to be easy to maintain
> * Load in official plugins an example on business screen who simplify
> generic screen with potential problem that can be raise by the split :)
>
> I will try to split it.
> Thanks
>
> Nicolas
>
>
>
> On 03/09/2018 13:07, Taher Alkhateeb wrote:
>
>> Very interesting thoughts Sharan, Jacopo and everyone.
>>
>> Thinking about this some more, and given that -- as I understood it --
>> the AP and AR are really nothing more than specialized filtration
>> screens of the general purpose screens in the accounting webapp, then
>> why not delete them? Are people depending on these screens? Is it
>> worth writing and maintaining a plugin for it?
>> On Mon, Sep 3, 2018 at 12:27 PM Sharan Foga <[hidden email]> wrote:
>>
>>>
>>>
>>> On 2018/09/03 08:11:26, Jacopo Cappellato <jacopo.cappellato@hotwaxsyste
>>> ms.com> wrote:
>>>
>>>> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <[hidden email]>
>>>> wrote:
>>>>
>>>> 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 ?
>>>>>
>>>>> As far as I remember, the AP/AR web applications were created as a
>>>> specialized versions of the user interfaces for some business processes
>>>> (account receivables and account payables related tasks) that were
>>>> already
>>>> available in the more general "accounting" web application. I like the
>>>> idea
>>>> to move them to plugins but, as mentioned by Taher, we should also
>>>> verify
>>>> if there are specific features that are available only in the AP/AR
>>>> version
>>>> and not in the "accounting" application: if we find some, then we should
>>>> migrate the basic artifacts to the main "accounting" app and then move
>>>> the
>>>> specialized screens to plugins. I think such cases will be rare but one
>>>> possible candidate is the "batch payment" functionality of the AR app.
>>>>
>>> I thought the batch payment was one of the options for the Payment Group
>>> which is on the main accounting menu so any processing can be done from
>>> there too.
>>>
>>> Thanks
>>> Sharan
>>>
>>>
>>>> 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 :)
>>>>>
>>>>> +1
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> Nicolas
>>>>>
>>>>>
>>>>>
>

[Nicolas Malin-2]

Hello,

With you returns, I open the issue OFBIZ-10552 [1] with my first try.

Cheers,

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-10552

On 01/09/2018 14:09, Nicolas Malin wrote:

> 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
>

[Pierre Smits-3]

Instead of disentangling the AR and AP web-apps from accounting and
recreating them as new components in the plugins repository I suggest to
bring following UI functionalities under subsections of the Accounting
web-app:

Overviews [1] and [2] of outstanding invoices to become menu-items under
 the InvoiceTabBar

[1] https://demo-trunk.ofbiz.apache.org/ap/control/listReports
[2] https://demo-trunk.ofbiz.apache.org/ar/control/listReports

The rest of the functionalities made available under the AP and AR web-apps
are already available in Accounting and having these in separate plugin
components adds - at the moment, with current designs - no extra value on
top of the existing functionalities in accounting.


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 Fri, Sep 7, 2018 at 11:58 AM, Nicolas Malin <[hidden email]>
wrote:

> Hello,
>
> With you returns, I open the issue OFBIZ-10552 [1] with my first try.
>
> Cheers,
>
> Nicolas
>
> [1] https://issues.apache.org/jira/browse/OFBIZ-10552
>
>
> On 01/09/2018 14:09, Nicolas Malin wrote:
>
>> 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
>>
>>
>

[Jacques Le Roux]

I also suggested that in a previous message in this thread https://s.apache.org/eSSf

pro: less work, less risks

cons: what about the thirdparty accounting elements? Clearly those should be plugins

Jacques


Le 09/09/2018 à 09:49, Pierre Smits a écrit :

> Instead of disentangling the AR and AP web-apps from accounting and
> recreating them as new components in the plugins repository I suggest to
> bring following UI functionalities under subsections of the Accounting
> web-app:
>
> Overviews [1] and [2] of outstanding invoices to become menu-items under
>   the InvoiceTabBar
>
> [1] https://demo-trunk.ofbiz.apache.org/ap/control/listReports
> [2] https://demo-trunk.ofbiz.apache.org/ar/control/listReports
>
> The rest of the functionalities made available under the AP and AR web-apps
> are already available in Accounting and having these in separate plugin
> components adds - at the moment, with current designs - no extra value on
> top of the existing functionalities in accounting.
>
>
> 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 Fri, Sep 7, 2018 at 11:58 AM, Nicolas Malin <[hidden email]>
> wrote:
>
>> Hello,
>>
>> With you returns, I open the issue OFBIZ-10552 [1] with my first try.
>>
>> Cheers,
>>
>> Nicolas
>>
>> [1] https://issues.apache.org/jira/browse/OFBIZ-10552
>>
>>
>> On 01/09/2018 14:09, Nicolas Malin wrote:
>>
>>> 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
>>>
>>>

[Pierre Smits-3]

There have been several attemps (ml postings, tickets, etc.) in the past to
trying toaddress the broader aspect of 3rd party functionalities, but none
of these led to something that could be regarded as consensus, and from
thereon materialize into actionable items the community could work upon.

Maybe, now the moment is there to achieve this? Maybe in a separate thread?



Op zo 9 sep. 2018 om 11:05 schreef Jacques Le Roux <
[hidden email]>

> I also suggested that in a previous message in this thread
> https://s.apache.org/eSSf
>
> pro: less work, less risks
>
> cons: what about the thirdparty accounting elements? Clearly those should
> be plugins
>
> Jacques
>
>
> Le 09/09/2018 à 09:49, Pierre Smits a écrit :
> > Instead of disentangling the AR and AP web-apps from accounting and
> > recreating them as new components in the plugins repository I suggest to
> > bring following UI functionalities under subsections of the Accounting
> > web-app:
> >
> > Overviews [1] and [2] of outstanding invoices to become menu-items under
> >   the InvoiceTabBar
> >
> > [1] https://demo-trunk.ofbiz.apache.org/ap/control/listReports
> > [2] https://demo-trunk.ofbiz.apache.org/ar/control/listReports
> >
> > The rest of the functionalities made available under the AP and AR
> web-apps
> > are already available in Accounting and having these in separate plugin
> > components adds - at the moment, with current designs - no extra value on
> > top of the existing functionalities in accounting.
> >
> >
> > 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 Fri, Sep 7, 2018 at 11:58 AM, Nicolas Malin <[hidden email]
> >
> > wrote:
> >
> >> Hello,
> >>
> >> With you returns, I open the issue OFBIZ-10552 [1] with my first try.
> >>
> >> Cheers,
> >>
> >> Nicolas
> >>
> >> [1] https://issues.apache.org/jira/browse/OFBIZ-10552
> >>
> >>
> >> On 01/09/2018 14:09, Nicolas Malin wrote:
> >>
> >>> 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
> >>>
> >>>
>
> --

Sent from my phone