modelling a marketplace with multiple sellers and buyers

[Rajesh Mallah]

Hi

I am trying to model a use case with many sellers and buyers.

There is a large intersection in the sets of item that these sellers
shall be dealing with.

I have gone through some of the resources (documentation) that
covers entities like Categories , Products , Catalog , Store etc.

My Question is: is the  below   linkage of products to PartyID ( seller)

PartyID --> Facility --> Store --> Catalog -> Product Category -> Products.
feasible?  ---- (Q1)

We would want to maintain a Global Category Tree/Hierarchy for all sellers
but I am thinking of duplicating the products from a master list of products
for each Seller (ie, partyID) . As each sellers might want to add their own
version of content (i.e, marketing pitch) for these generic(OEM)  products.

Eg: A concrete product is lets say a "LED Monitor" under "Electronics"
category ,
there can be many manufactures of LED Monitors with their own specs
and variations.

The idea of having a global category and catalog is to make their on
boarding
easier so that they quickly get started by indicating the items they they
would
want to copy into their catalogs.

Q2: Do/Should  I also duplicate categories for each seller catalog ?

any comments/guidance are solicited.

regds
mallah.

[Rajesh Mallah]

>
> My Question is: is the  below   linkage of products to PartyID ( seller)
> PartyID --> Facility --> Store --> Catalog -> Product Category -> Products.
> feasible?  ---- (Q1)
>

I could see that it is possible to relate a Party with each of the above
entities
via Entities

FacilityParty , ProductStoreRole  , ProdCatalogRole , ProductCategoryRole ,
ProductRole
respectively.

regds
mallah.






On Mon, Mar 19, 2018 at 11:07 PM, Rajesh Mallah <[hidden email]>
wrote:

> Hi
>
> I am trying to model a use case with many sellers and buyers.
>
> There is a large intersection in the sets of item that these sellers
> shall be dealing with.
>
> I have gone through some of the resources (documentation) that
> covers entities like Categories , Products , Catalog , Store etc.
>
> My Question is: is the  below   linkage of products to PartyID ( seller)
>
> PartyID --> Facility --> Store --> Catalog -> Product Category -> Products.
> feasible?  ---- (Q1)
>
> We would want to maintain a Global Category Tree/Hierarchy for all sellers
> but I am thinking of duplicating the products from a master list of
> products
> for each Seller (ie, partyID) . As each sellers might want to add their own
> version of content (i.e, marketing pitch) for these generic(OEM)  products.
>
> Eg: A concrete product is lets say a "LED Monitor" under "Electronics"
> category ,
> there can be many manufactures of LED Monitors with their own specs
> and variations.
>
> The idea of having a global category and catalog is to make their on
> boarding
> easier so that they quickly get started by indicating the items they they
> would
> want to copy into their catalogs.
>
> Q2: Do/Should  I also duplicate categories for each seller catalog ?
>
> any comments/guidance are solicited.
>
> regds
> mallah.
>

[Shi Jinghai-3]

We used to use public/master list products concept which looks beautiful but not flexible for business, now we give up this implement, we're changing to duplicate product categories and will introduce a CLOUD concept like Ariba's cloud suggestion to help customers on products.


-----邮件原件-----
发件人: Rajesh Mallah [mailto:[hidden email]]
发送时间: 2018年3月20日 6:13
收件人: [hidden email]
主题: Re: modelling a marketplace with multiple sellers and buyers

>
> My Question is: is the  below   linkage of products to PartyID ( seller)
> PartyID --> Facility --> Store --> Catalog -> Product Category -> Products.
> feasible?  ---- (Q1)
>

I could see that it is possible to relate a Party with each of the above entities via Entities

FacilityParty , ProductStoreRole  , ProdCatalogRole , ProductCategoryRole , ProductRole respectively.

regds
mallah.






On Mon, Mar 19, 2018 at 11:07 PM, Rajesh Mallah <[hidden email]>
wrote:

> Hi
>
> I am trying to model a use case with many sellers and buyers.
>
> There is a large intersection in the sets of item that these sellers
> shall be dealing with.
>
> I have gone through some of the resources (documentation) that covers
> entities like Categories , Products , Catalog , Store etc.
>
> My Question is: is the  below   linkage of products to PartyID ( seller)
>
> PartyID --> Facility --> Store --> Catalog -> Product Category -> Products.
> feasible?  ---- (Q1)
>
> We would want to maintain a Global Category Tree/Hierarchy for all
> sellers but I am thinking of duplicating the products from a master
> list of products for each Seller (ie, partyID) . As each sellers might
> want to add their own version of content (i.e, marketing pitch) for
> these generic(OEM)  products.
>
> Eg: A concrete product is lets say a "LED Monitor" under "Electronics"
> category ,
> there can be many manufactures of LED Monitors with their own specs
> and variations.
>
> The idea of having a global category and catalog is to make their on
> boarding easier so that they quickly get started by indicating the
> items they they would want to copy into their catalogs.
>
> Q2: Do/Should  I also duplicate categories for each seller catalog ?
>
> any comments/guidance are solicited.
>
> regds
> mallah.
>

[Rajesh Mallah]

Thanks Shi . It was nice to hear real world experience.
--mallah.

On Tue, Mar 20, 2018 at 7:02 AM, Shi Jinghai <[hidden email]> wrote:

> We used to use public/master list products concept which looks beautiful
> but not flexible for business, now we give up this implement, we're
> changing to duplicate product categories and will introduce a CLOUD concept
> like Ariba's cloud suggestion to help customers on products.
>
>
> -----邮件原件-----
> 发件人: Rajesh Mallah [mailto:[hidden email]]
> 发送时间: 2018年3月20日 6:13
> 收件人: [hidden email]
> 主题: Re: modelling a marketplace with multiple sellers and buyers
>
> >
> > My Question is: is the  below   linkage of products to PartyID ( seller)
> > PartyID --> Facility --> Store --> Catalog -> Product Category ->
> Products.
> > feasible?  ---- (Q1)
> >
>
> I could see that it is possible to relate a Party with each of the above
> entities via Entities
>
> FacilityParty , ProductStoreRole  , ProdCatalogRole , ProductCategoryRole
> , ProductRole respectively.
>
> regds
> mallah.
>
>
>
>
>
>
> On Mon, Mar 19, 2018 at 11:07 PM, Rajesh Mallah <[hidden email]>
> wrote:
>
> > Hi
> >
> > I am trying to model a use case with many sellers and buyers.
> >
> > There is a large intersection in the sets of item that these sellers
> > shall be dealing with.
> >
> > I have gone through some of the resources (documentation) that covers
> > entities like Categories , Products , Catalog , Store etc.
> >
> > My Question is: is the  below   linkage of products to PartyID ( seller)
> >
> > PartyID --> Facility --> Store --> Catalog -> Product Category ->
> Products.
> > feasible?  ---- (Q1)
> >
> > We would want to maintain a Global Category Tree/Hierarchy for all
> > sellers but I am thinking of duplicating the products from a master
> > list of products for each Seller (ie, partyID) . As each sellers might
> > want to add their own version of content (i.e, marketing pitch) for
> > these generic(OEM)  products.
> >
> > Eg: A concrete product is lets say a "LED Monitor" under "Electronics"
> > category ,
> > there can be many manufactures of LED Monitors with their own specs
> > and variations.
> >
> > The idea of having a global category and catalog is to make their on
> > boarding easier so that they quickly get started by indicating the
> > items they they would want to copy into their catalogs.
> >
> > Q2: Do/Should  I also duplicate categories for each seller catalog ?
> >
> > any comments/guidance are solicited.
> >
> > regds
> > mallah.
> >
>

[taher]

I like your approach, and my recommendation is to try and stick with
the existing model. The combination between products, parties, stores
and roles should be robust for your needs. However, I think you will
probably need some custom logic around the processing of buyers and
sellers since you're developing an exchange kind of market.

I think maybe your custom logic is going to cover mostly the code
_before_ a transaction happens between buyers and sellers. Maybe you
can use the "opportunity" or "quote" or "requirement" entity to drive
the follow up until a deal is closed at which time you trigger maybe
an order which drives everything else. It depends on how you're
exactly designing your system.

On Tue, Mar 20, 2018 at 1:13 AM, Rajesh Mallah <[hidden email]> wrote:

>>
>> My Question is: is the  below   linkage of products to PartyID ( seller)
>> PartyID --> Facility --> Store --> Catalog -> Product Category -> Products.
>> feasible?  ---- (Q1)
>>
>
> I could see that it is possible to relate a Party with each of the above
> entities
> via Entities
>
> FacilityParty , ProductStoreRole  , ProdCatalogRole , ProductCategoryRole ,
> ProductRole
> respectively.
>
> regds
> mallah.
>
>
>
>
>
>
> On Mon, Mar 19, 2018 at 11:07 PM, Rajesh Mallah <[hidden email]>
> wrote:
>
>> Hi
>>
>> I am trying to model a use case with many sellers and buyers.
>>
>> There is a large intersection in the sets of item that these sellers
>> shall be dealing with.
>>
>> I have gone through some of the resources (documentation) that
>> covers entities like Categories , Products , Catalog , Store etc.
>>
>> My Question is: is the  below   linkage of products to PartyID ( seller)
>>
>> PartyID --> Facility --> Store --> Catalog -> Product Category -> Products.
>> feasible?  ---- (Q1)
>>
>> We would want to maintain a Global Category Tree/Hierarchy for all sellers
>> but I am thinking of duplicating the products from a master list of
>> products
>> for each Seller (ie, partyID) . As each sellers might want to add their own
>> version of content (i.e, marketing pitch) for these generic(OEM)  products.
>>
>> Eg: A concrete product is lets say a "LED Monitor" under "Electronics"
>> category ,
>> there can be many manufactures of LED Monitors with their own specs
>> and variations.
>>
>> The idea of having a global category and catalog is to make their on
>> boarding
>> easier so that they quickly get started by indicating the items they they
>> would
>> want to copy into their catalogs.
>>
>> Q2: Do/Should  I also duplicate categories for each seller catalog ?
>>
>> any comments/guidance are solicited.
>>
>> regds
>> mallah.
>>

[Rajesh Mallah]

Hi Taher ,

there is ample space for the custom logic in the architecture . Its
basically in
an MVC pattern . There is a direct Model connected to the Entities(via
non-ofbiz
database connection) and an Indirect one  via XMLRPC of OFBiz.
OFBiz is mostly being used as a data store now.

With time as I familiarize myself with OFBiz capabilities,  more custom
code can
be offloaded  to OFBiz's inbuilt capabilities. Currently I have less
capability or
intent to mess with OFBiz code/ plugins.

The only problem i see with the current approach is the lack of transaction
control.
I cannot rollback partial changes in case of run-time errors or failures.
the XMLRPC requests run on server in its own transaction context. But I am
yet
to face any real challenge due to this.

regds
mallah.



On Tue, Mar 20, 2018 at 3:24 PM, Taher Alkhateeb <[hidden email]
> wrote:

> I like your approach, and my recommendation is to try and stick with
> the existing model. The combination between products, parties, stores
> and roles should be robust for your needs. However, I think you will
> probably need some custom logic around the processing of buyers and
> sellers since you're developing an exchange kind of market.
>
> I think maybe your custom logic is going to cover mostly the code
> _before_ a transaction happens between buyers and sellers. Maybe you
> can use the "opportunity" or "quote" or "requirement" entity to drive
> the follow up until a deal is closed at which time you trigger maybe
> an order which drives everything else. It depends on how you're
> exactly designing your system.
>
>
>

[taher]

Lump services together. Look at ECAs and service groups. I think this will
satisfy your transaction requirements.

On Tue, Mar 20, 2018, 4:16 PM Rajesh Mallah <[hidden email]> wrote:

> Hi Taher ,
>
> there is ample space for the custom logic in the architecture . Its
> basically in
> an MVC pattern . There is a direct Model connected to the Entities(via
> non-ofbiz
> database connection) and an Indirect one  via XMLRPC of OFBiz.
> OFBiz is mostly being used as a data store now.
>
> With time as I familiarize myself with OFBiz capabilities,  more custom
> code can
> be offloaded  to OFBiz's inbuilt capabilities. Currently I have less
> capability or
> intent to mess with OFBiz code/ plugins.
>
> The only problem i see with the current approach is the lack of transaction
> control.
> I cannot rollback partial changes in case of run-time errors or failures.
> the XMLRPC requests run on server in its own transaction context. But I am
> yet
> to face any real challenge due to this.
>
> regds
> mallah.
>
>
>
> On Tue, Mar 20, 2018 at 3:24 PM, Taher Alkhateeb <
> [hidden email]
> > wrote:
>
> > I like your approach, and my recommendation is to try and stick with
> > the existing model. The combination between products, parties, stores
> > and roles should be robust for your needs. However, I think you will
> > probably need some custom logic around the processing of buyers and
> > sellers since you're developing an exchange kind of market.
> >
> > I think maybe your custom logic is going to cover mostly the code
> > _before_ a transaction happens between buyers and sellers. Maybe you
> > can use the "opportunity" or "quote" or "requirement" entity to drive
> > the follow up until a deal is closed at which time you trigger maybe
> > an order which drives everything else. It depends on how you're
> > exactly designing your system.
> >
> >
> >
>

[Rajesh Mallah]

>
> Lump services together. Look at ECAs and service groups. I think this will
> satisfy your transaction requirements.
>

kewl!

On Tue, Mar 20, 2018 at 7:42 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Lump services together. Look at ECAs and service groups. I think this will
> satisfy your transaction requirements.
>
> On Tue, Mar 20, 2018, 4:16 PM Rajesh Mallah <[hidden email]>
> wrote:
>
> > Hi Taher ,
> >
> > there is ample space for the custom logic in the architecture . Its
> > basically in
> > an MVC pattern . There is a direct Model connected to the Entities(via
> > non-ofbiz
> > database connection) and an Indirect one  via XMLRPC of OFBiz.
> > OFBiz is mostly being used as a data store now.
> >
> > With time as I familiarize myself with OFBiz capabilities,  more custom
> > code can
> > be offloaded  to OFBiz's inbuilt capabilities. Currently I have less
> > capability or
> > intent to mess with OFBiz code/ plugins.
> >
> > The only problem i see with the current approach is the lack of
> transaction
> > control.
> > I cannot rollback partial changes in case of run-time errors or failures.
> > the XMLRPC requests run on server in its own transaction context. But I
> am
> > yet
> > to face any real challenge due to this.
> >
> > regds
> > mallah.
> >
> >
> >
> > On Tue, Mar 20, 2018 at 3:24 PM, Taher Alkhateeb <
> > [hidden email]
> > > wrote:
> >
> > > I like your approach, and my recommendation is to try and stick with
> > > the existing model. The combination between products, parties, stores
> > > and roles should be robust for your needs. However, I think you will
> > > probably need some custom logic around the processing of buyers and
> > > sellers since you're developing an exchange kind of market.
> > >
> > > I think maybe your custom logic is going to cover mostly the code
> > > _before_ a transaction happens between buyers and sellers. Maybe you
> > > can use the "opportunity" or "quote" or "requirement" entity to drive
> > > the follow up until a deal is closed at which time you trigger maybe
> > > an order which drives everything else. It depends on how you're
> > > exactly designing your system.
> > >
> > >
> > >
> >
>