Re: Move accounting ap and ar to plugin ?

[Pierre Smits]

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 <
jacques.le.r...@les7arts.com>

> 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 , Vice President
> > Apache Directory , PMC Member
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
> privileges)
> > since 2008*
> > Apache Steve , committer
> >
> > On Fri, Sep 7, 2018 at 11:58 AM, Nicolas Malin  >
> > 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

Re: Move accounting ap and ar to plugin ?

[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 , Vice President
Apache Directory , PMC Member
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

On Fri, Sep 7, 2018 at 11:58 AM, Nicolas Malin 
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

Re: Move accounting ap and ar to plugin ?

[Pierre Smits]

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 , Vice President
Apache Directory , PMC Member
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

On Fri, Sep 7, 2018 at 11:58 AM, Nicolas Malin 
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
>>
>>
>

Re: Move accounting ap and ar to plugin ?

[Nicolas Malin]

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

Re: Move accounting ap and ar to plugin ?

[Deepak Dixit]

+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 
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  wrote:
>>
>>>
>>>
>>> On 2018/09/03 08:11:26, Jacopo Cappellato >> ms.com> wrote:
>>>
 On Sat, Sep 1, 2018 at 2:09 PM 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 ?
>
> 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
>
>
>
>

Re: Move accounting ap and ar to plugin ?

[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: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Mon, Sep 3, 2018 at 7:15 PM Taher Alkhateeb 
wrote:

> Sounds good to me then. +1
>
> On Mon, Sep 3, 2018, 4:32 PM Nicolas Malin 
> 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  wrote:
> > >>
> > >>
> > >> On 2018/09/03 08:11:26, Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> > >>> On Sat, Sep 1, 2018 at 2:09 PM Nicolas Malin <
> nicolas.ma...@nereide.fr
> > >
> > >>> 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
> > 
> > 
> >
> >
>

Re: Move accounting ap and ar to plugin ?

[Taher Alkhateeb]

Sounds good to me then. +1

On Mon, Sep 3, 2018, 4:32 PM Nicolas Malin  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  wrote:
> >>
> >>
> >> On 2018/09/03 08:11:26, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
> >>> On Sat, Sep 1, 2018 at 2:09 PM 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 ?
> 
> >>> 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
> 
> 
>
>

Re: Move accounting ap and ar to plugin ?

[Nicolas Malin]

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



On 2018/09/03 08:11:26, Jacopo Cappellato  
wrote:

On Sat, Sep 1, 2018 at 2:09 PM 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 ?


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

Re: Move accounting ap and ar to plugin ?

[Taher Alkhateeb]

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  wrote:
>
>
>
> On 2018/09/03 08:11:26, Jacopo Cappellato 
>  wrote:
> > On Sat, Sep 1, 2018 at 2:09 PM 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 ?
> > >
> >
> > 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
> > >
> > >
> >

Re: Move accounting ap and ar to plugin ?

[Sharan Foga]

On 2018/09/03 08:11:26, Jacopo Cappellato  
wrote: 
> On Sat, Sep 1, 2018 at 2:09 PM 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 ?
> >
> 
> 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
> >
> >
> 

Re: Move accounting ap and ar to plugin ?

[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  
wrote: 
> On Sat, Sep 1, 2018 at 2:09 PM 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 ?
> >
> 
> 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
> >
> >
> 

Re: Move accounting ap and ar to plugin ?

[Julian Smith]

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

Re: Move accounting ap and ar to plugin ?

[Jacopo Cappellato]

On Sat, Sep 1, 2018 at 2:09 PM 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 ?
>

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

Re: Move accounting ap and ar to plugin ?

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

Re: Move accounting ap and ar to plugin ?

[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 , Vice President
Apache Directory , PMC Member
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , 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
 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

Re: Move accounting ap and ar to plugin ?

[Taher Alkhateeb]

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

Re: Move accounting ap and ar to plugin ?

[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

Move accounting ap and ar to plugin ?

[Nicolas Malin]

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 
Nicolas Malin
The apache way  : *Charity* Apache’s mission 
is providing software for the public good.

informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz |The Apache Way 
|réseau LE