I like to think of the ideal dependency structure this way: Party Product Content Workeffort
The data layer and basic logic layer independent of each other and everything else, utilizing ONLY itself and the OFBiz framework. For ERP, this essentially creates an ERP framework. No UI. These are basic services, very simple simple-methods, etc. In this thought experiment Agreement remains in Party as you can have Employment Agreements, Order Agreements, Service Agreements, Warranty Agreements?, Content Agreements, Production Agreements, and any number of other agreements. Again, these four would have no UI outside of possibly something similar to what webtools provides or the state of these components about a year to 18 months ago. The UI would only prove as an example of the robustness and likely never used in production environment. On top of that you build: Accounting Manufacturing Marketing Human Resources Content Management This again is your lower level data manipulation logic. A lot of your "join" entity logic goes here. (ie *Role, *Content, *WorkeffortAppl?) Next tier Order After these three tiers you can start building interrelated operation applications that go on top. This is where real ERP logic goes and OFBiz actually becomes useful in a business. You start getting user specific, purpose driven UI. This is where most of the backend UI begins. After that ecommerce and pos get thrown on top as UI applications that have very little logic of their own. This sort of structure modularizes OFBiz and makes it very easy to see where custom needs begin. Anyway, my two cents. But you do need to keep in mind employment agreements breaks any idea of moving the agreement data model over to product or order. I'm not sure if people's suggestions were to move the data model, or just the UI. --- "David E. Jones" <[EMAIL PROTECTED]> wrote: > > Just like the majority of responses I agree that the > order component > is most likely the best home for this. > > Originally the Agreement data model was in the party > package because > that is in essence what agreements relate directly > too (and because > that is the section of The Data Model Resource Book > where they are > described). Over time though Agreements have become > closer to an > Order because even though they could perhaps be used > for other > things, they are mostly used to track the terms > between a customer > and the company for future orders. In a way an > agreement in this way > is more like a Quote, but one that is meant to be > used many times and > in combination with other quotes or agreements, or > even retail level > purchases. A quote is a bit more rigid in the > implied constraints. > > So, from the most generic and future-proof > perspective the party > component would be the best. However, given how it > has evolved and > how it is now used and will most likely be used in > the future, the > order component makes more sense - especially for > the UI since in > this area it does tie into other parts of an > ordering process, kind > of an alternative for a quote (even perhaps in > response to an RFQ...). > > So, unless we can come up with other likely future > uses that would > make putting it in the party component make the most > sense, I'd say > we put it in the order component. > > -David > > > On Aug 16, 2006, at 1:24 AM, Jacopo Cappellato > wrote: > > > Hi all, > > > > what is the right component for the agreement > stuff (entity defs, > > services, screens)? > > Right now, the entity definitions are in the > "party" component and > > the service definitions and screens are in the > "accounting" component. > > > > Since I'm planning some enhancements for the > agreements' > > implementation, I'd like to put some order. > > I don't see any reason to keep them in the > accounting component and > > I'd like to move them to the right spot. > > My first choice is to move everything to the party > component (where > > the entities are already defined): in fact, after > you have created > > parties (suppliers, customers, agents...), it's > 'natural' to define > > agreements with them in the same application (I'd > like to add a > > party subscreen to list all the available > agreements). > > > > However there are some issues with this approach, > since agreements > > are also associated to the "product" component > > (AgreementProductAppl, AgreementPromoAppl) that is > an higher level > > component. > > > > So, what we can do? Should we move all the > agreement ui to the > > "catalog" application? Or just the product related > screens? (I > > don't like too much this approach since it is not > easy for users to > > jump from one application to the other to set up > one agreement). > > > > Your feedback is welcome! > > > > Jacopo > >
