Posted by
Jacopo Cappellato on
URL: http://ofbiz.116.s1.nabble.com/RFC-Order-package-entities-tp178233p178236.html
Chris Howe wrote:
>
> There's just seems to be a lot of redundancy with this. I'm not so
> concerned with request, quote or shoppinglist (i meant to include that
> as well) as there isn't much business logic overlap. However, with
> return there is quite a lot (inventory management, possibly shipping,
> OrderItemAssoc, Adjustments etc). While it currently works, it makes
> it quite a bit more difficult to learn as someone trying to pick it up
> is likely to erroneously assume it has less in common with OrderHeader,
> etc than it actually does. I think there's some interest in making
> these simpler to use/ more generic. Are you against because of
> resources (time actually spent rewriting/reviewing it) or is there more
> of a technical aspect (backwards compatibility, fragile code, etc)?
>
> Chris
I don't think that the learning curve needed to use returns could be
much more different if the returns are stored in the order entities
instead of their own. For example, my clients are usually surprised (and
sometimes concerned) when I explain them that the purchase and the sales
orders are actually stored in the same entity (that is a good thing!)...
From the developers point of view, in my opinion there are pros and
cons (as I said before) for storing returns in the order entities:
less separate services that (probably, but I did not do a serious
analysis on this) could do similar tasks; on the other hand, the order
services will be more complex (and also data extraction and preparation).
For this, since I don't see real problems in the current implementation
that will be addressed by this refactoring, I don't see it really
something worth of the effort.
Jacopo