Agreements: where is their home?
Locked
Agreements: where is their home?
 
|
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 |
RE: Agreements: where is their home?
|
|
Hi, Just to add to the choice of components, would adding Agreements under the "Order" component be appropriate (provided it is technically feasible). The reasoning is as follows: Be it an Order or an Agreement, the components that are common is the Products and Parties. In order to create a "Order" or an "Agreement" both the above mentioned components are normally required. Thanks and Regards, Devarajan -----Original Message----- From: Jacopo Cappellato [mailto:[hidden email]] Sent: Wednesday, August 16, 2006 12:55 PM To: [hidden email] Subject: Agreements: where is their home? 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 |
Re: Agreements: where is their home?
|
|
In reply to this post by Jacopo Cappellato
Jacopo Cappellato schrieb:
> 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. I was wondering too why the agreements are under accounting .. [..] > 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! What about moving it to the order application? -- Christian |
Re: Agreements: where is their home?
|
|
In reply to this post by Devarajan Ramachandran
Devarajan,
thanks for your feedback. Yes, moving the agreements to the order component really makes sense (and this is something I've considered in the past); however, since agreements setup really happens before orders/requests/quotes are done I think it would be nice to have them in the product or party component. If this will not happen, I think that moving them to the order component will be the best solution. Jacopo Devarajan Ramachandran wrote: > Hi, > > Just to add to the choice of components, would adding Agreements under the "Order" component be appropriate (provided it is technically feasible). > > The reasoning is as follows: > > Be it an Order or an Agreement, the components that are common is the Products and Parties. > > In order to create a "Order" or an "Agreement" both the above mentioned components are normally required. > > Thanks and Regards, > Devarajan > > > -----Original Message----- > From: Jacopo Cappellato [mailto:[hidden email]] > Sent: Wednesday, August 16, 2006 12:55 PM > To: [hidden email] > Subject: Agreements: where is their home? > > 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 > > |
Re: Agreements: where is their home?
|
|
Jacopo Cappellato schrieb:
> Devarajan, > > thanks for your feedback. > Yes, moving the agreements to the order component really makes sense > (and this is something I've considered in the past); however, since > agreements setup really happens before orders/requests/quotes are done I I'd think that agreements happen after requests/quotes? -- Christian |
Re: Agreements: where is their home?
|
|
Christian Geisert wrote:
> Jacopo Cappellato schrieb: >> Devarajan, >> >> thanks for your feedback. >> Yes, moving the agreements to the order component really makes sense >> (and this is something I've considered in the past); however, since >> agreements setup really happens before orders/requests/quotes are done I > > I'd think that agreements happen after requests/quotes? > Well, you are probably right... but maybe if there is an agreement there is no need for requests/quotes. Jacopo |
RE: Agreements: where is their home?
|
|
In reply to this post by Jacopo Cappellato
HI, I suppose, one option is to add the Agreements tab after the Requests and Quotes tab on the Order manager application. Thanks & Regards, Devarajan Ramachandran -----Original Message----- From: Christian Geisert [mailto:[hidden email]] Sent: Wednesday, August 16, 2006 1:55 PM To: [hidden email] Subject: Re: Agreements: where is their home? Jacopo Cappellato schrieb: > Devarajan, > > thanks for your feedback. > Yes, moving the agreements to the order component really makes sense > (and this is something I've considered in the past); however, since > agreements setup really happens before orders/requests/quotes are done I I'd think that agreements happen after requests/quotes? -- Christian |
Re: Agreements: where is their home?
|
|
In reply to this post by Jacopo Cappellato
Hi Jacopo
I agree with the party component, agreements are always between parties and don't always include products or orders (e.g. employment agreements). It seems logical to me that whenever an agreement is being worked on, the main focus is on the parties involved. Regards Scott 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 > |
Re: Agreements: where is their home?
|
|
In reply to this post by Jacopo Cappellato
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 |
Re: Agreements: where is their home?
|
|
Thanks to all for your feedback.
What about the entity definitions? The only lower level component that is using them is the product component... should we move them from party to product? This would resolve the dependency to the product data model caused by the AgreementProductAppl entity. And, in general, it's ok for me to move the screens to the order component: however I think that it would be nice to add an agreement tab to the party detail screen (to show all the agreements associated to a given party) and also an agreement tab to the product details screen (to show all the agreements associated to a given product)... this will imply that, for example, the party manager application will depend on upper level components (that it is not a good thing) but, in my opinion, this will greatly improve the usability of the system. So, in my opinion we should allow for some (not strictly correct) dependencies between applications (and in fact this already happens here and there in the system)... what is your opinion about this? Jacopo David E. Jones 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 |
|
|
In reply to this post by David E Jones-2
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" <[hidden email]> 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 > > |
Re: Agreements: where is their home?
|
|
To summarize:
should we only move the following two entities (and their services) from party to product: AgreementProductAppl AgreementPromoAppl and the following one from party to workeffort: AgreementWorkEffortAppl ? And move all the ui (and more complex services) from accounting to order? Jacopo Chris Howe wrote: > 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. > |
Re: Agreements: where is their home?
|
|
Part of the point of a loosely coupled architecture like the one we use in OFBiz is the while reduction of dependencies can be helpful to keep things better organized, they are not necessary. In other words when a cluster of functionality that is fairly coherent (like the Agreement stuff) has dependencies on other things you can still keep it all in one place, even if it results in cross- dependencies. Of course, the other side of this is that certain parts of things are more "core" to a certain piece but in addition may have things that are not necessary that extend it and those can and usually should be put in other places (which is part of the point of the new extend-entity stuff). Being able to keep this all together is one reason I like putting it in the order component. It makes sense for the most common use of the existing artifacts, plus it is a higher level component and it is fine for it to depend on lower level things like Product, Party, and WorkEffort. -David On Aug 16, 2006, at 8:00 AM, Jacopo Cappellato wrote: > To summarize: > > should we only move the following two entities (and their services) > from party to product: > > AgreementProductAppl > AgreementPromoAppl > > and the following one from party to workeffort: > > AgreementWorkEffortAppl > > ? > > And move all the ui (and more complex services) from accounting to > order? > > Jacopo > > > Chris Howe wrote: >> 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. > |
|
|
I agree on the benefit of loosely coupled
architecture, but for a different reason. I find it beneficial as a community because if it were modularized to the point of what I find ideal, the different higher level functionalities would find it easier to fork and we would only be worried about solving our own problems and not each other's problems. Finding solutions to each other's problems gives us a more robust and closer to complete application. I do find the agreement dependency discussion to be a bit of backward logic. An order is dependent on an agreement, an agreement is not dependent on an order. It's just that the agreement logic isn't as far along as the order because most companies don't find as much benefit in keeping track of agreements in a database. As it is, I would find it beneficial to reorganize quite a bit of the structure. However, this requires quite a bit of community feedback to decide on the logic patterns to be used. The project as it is today follows pretty much a single logic pattern. While others might make things easier to understand, mixing of the patterns would make things, in general, more difficult to understand. Moving agreement related stuff would be mixing the patterns. --- "David E. Jones" <[hidden email]> wrote: > > Part of the point of a loosely coupled architecture > like the one we > use in OFBiz is the while reduction of dependencies > can be helpful to > keep things better organized, they are not > necessary. > > In other words when a cluster of functionality that > is fairly > coherent (like the Agreement stuff) has dependencies > on other things > you can still keep it all in one place, even if it > results in cross- > dependencies. Of course, the other side of this is > that certain parts > of things are more "core" to a certain piece but in > addition may have > things that are not necessary that extend it and > those can and > usually should be put in other places (which is part > of the point of > the new extend-entity stuff). > > Being able to keep this all together is one reason I > like putting it > in the order component. It makes sense for the most > common use of the > existing artifacts, plus it is a higher level > component and it is > fine for it to depend on lower level things like > Product, Party, and > WorkEffort. > > -David > > > On Aug 16, 2006, at 8:00 AM, Jacopo Cappellato > wrote: > > > To summarize: > > > > should we only move the following two entities > (and their services) > > from party to product: > > > > AgreementProductAppl > > AgreementPromoAppl > > > > and the following one from party to workeffort: > > > > AgreementWorkEffortAppl > > > > ? > > > > And move all the ui (and more complex services) > from accounting to > > order? > > > > Jacopo > > > > > > Chris Howe wrote: > >> 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. > > > > |
Re: Agreements: where is their home?
|
|
I believe the Agreement portion should be a part of the Party component, as was
mentioned previously. From my perspective, an Agreement will ALWAYS involve a Party, whereas an Order MIGHT involve an Agreement. Chris Howe wrote: > I agree on the benefit of loosely coupled > architecture, but for a different reason. I find it > beneficial as a community because if it were > modularized to the point of what I find ideal, the > different higher level functionalities would find it > easier to fork and we would only be worried about > solving our own problems and not each other's > problems. Finding solutions to each other's problems > gives us a more robust and closer to complete > application. > > I do find the agreement dependency discussion to be a > bit of backward logic. An order is dependent on an > agreement, an agreement is not dependent on an order. > It's just that the agreement logic isn't as far along > as the order because most companies don't find as much > benefit in keeping track of agreements in a database. > > As it is, I would find it beneficial to reorganize > quite a bit of the structure. However, this requires > quite a bit of community feedback to decide on the > logic patterns to be used. The project as it is today > follows pretty much a single logic pattern. While > others might make things easier to understand, mixing > of the patterns would make things, in general, more > difficult to understand. Moving agreement related > stuff would be mixing the patterns. > > --- "David E. Jones" <[hidden email]> > wrote: > > >>Part of the point of a loosely coupled architecture >>like the one we >>use in OFBiz is the while reduction of dependencies >>can be helpful to >>keep things better organized, they are not >>necessary. >> >>In other words when a cluster of functionality that >>is fairly >>coherent (like the Agreement stuff) has dependencies >>on other things >>you can still keep it all in one place, even if it >>results in cross- >>dependencies. Of course, the other side of this is >>that certain parts >>of things are more "core" to a certain piece but in >>addition may have >>things that are not necessary that extend it and >>those can and >>usually should be put in other places (which is part >>of the point of >>the new extend-entity stuff). >> >>Being able to keep this all together is one reason I >>like putting it >>in the order component. It makes sense for the most >>common use of the >>existing artifacts, plus it is a higher level >>component and it is >>fine for it to depend on lower level things like >>Product, Party, and >>WorkEffort. >> >>-David >> >> >>On Aug 16, 2006, at 8:00 AM, Jacopo Cappellato >>wrote: >> >> >>>To summarize: >>> >>>should we only move the following two entities >> >>(and their services) >> >>>from party to product: >>> >>>AgreementProductAppl >>>AgreementPromoAppl >>> >>>and the following one from party to workeffort: >>> >>>AgreementWorkEffortAppl >>> >>>? >>> >>>And move all the ui (and more complex services) >> >>from accounting to >> >>>order? >>> >>>Jacopo >>> >>> >>>Chris Howe wrote: >>> >>>>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. >>> >> > > |
Re: Agreements: where is their home?
|
|
In reply to this post by David E Jones-2
I read the data book. the common data is PartyID.
as ofbiz expands, agreements will be in Human resources as well. in other industries there are agreements as well. Maybe more discussion before moving from party manager. David E. Jones sent the following on 8/16/2006 2:20 AM: > > 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 > > |
Re: Agreements: where is their home?
|
|
In reply to this post by Jacopo Cappellato
I tried to find the complete thread in markmail but did not.
is it ok to make a patch that moves the agreements to party from accounting. I have some code and screens that expands the Agreements based on partyrelationshiptypes. it is also in the party component. Jacopo Cappellato sent the following on 8/16/2006 12:24 AM: > 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 > |
Re: Agreements: where is their home?
|
|
In reply to this post by Jacopo Cappellato
I tried to find the complete thread in markmail but did not.
is it ok to make a patch that moves the agreements to party from accounting. I have some code and screens that expands the Agreements based on partyrelationshiptypes and the agreement types called out in the data model book. it is also in the party component. I have created a jira and would be glad do add a subtask to move agreements. Jacopo Cappellato sent the following on 8/16/2006 12:24 AM: > 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 > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |