Re: [RFC] Order package entities

[Tim Ruppert]

On Feb 15, 2007, at 12:52 AM, Jacopo Cappellato wrote:

Chris Howe wrote:

There's just seems to be a lot of redundancy with this.  I'm not so

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

etc than it actually does.  I think there's some interest in making
these simpler to use/ more generic.  Are you against because of

of a technical aspect (backwards compatibility, fragile code, etc)?
Chris

concerned with request, quote or shoppinglist (i meant to include that 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, resources (time actually spent rewriting/reviewing it) or is there more

Jacopo

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.

+1

smime.p7s
Description: S/MIME cryptographic signature