Re: Should we keep the multi-tenants feature in OFBiz?
The automation of multi tenancy setup could happen through deployment scripts instead of OFBiz itself. So yes the tenants would have their own install, but I don't see why they'd have their own server farm. On Wed, Sep 5, 2018, 4:15 AM wrote: > So if you don't have multi-tenancy does that mean every tenant has their > own install of OFbiz, their own install of Postgres SQL, and their own > server farm? > > Original Message > Subject: Re: Should we keep the multi-tenants feature in OFBiz? > From: Taher Alkhateeb > Date: Tue, September 04, 2018 9:12 am > To: user@ofbiz.apache.org > > The question is: is it worth keeping it? To answer this question, > perhaps we need to perhaps look at the pros and cons > > pros of keeping multi-tenancy: > - less memory consumption. > - less storage consumption. > - single deployment (less effort) > > cons of keeping multi-tenancy: > - Inflexibility: all tenants are stuck with the same code base. > - risk: if one tenant goes down, all tenants go down. There is less > redundancy and recovery. > - lock-in: splitting out tenants to a new separate instance is hard > and time consuming. > - code complexity: The multi-tenancy feature in OFBiz is making nearly > every critical artifact in the system complex. It is hard wired in > tomcat, components, data loaders and many other places. I stopped > counting the "if" conditions to handle the multi-tenant corner cases > all over the code base. > - alternatives less complex: the advent of new technologies like > docker and containerization makes the need for multi-tenancy less > desired. Also, storage and memory is getting cheaper all the time. So > the pros listed above are getting less valuable over time. > > So for all the above, I find myself leaning more towards removing > multi-tenancy from the code base. > > > On Tue, Sep 4, 2018 at 5:49 PM Mike wrote: > > > > My opinion is to just completely ditch the multi tenant code since it > seems > > to be more trouble than it's worth. Anyone serious about designing a > > system to support a similar concept would do it their own way anyway, > most > > likely using completely separate DBs. Face it, using a common DB and > share > > between separate companies is a dangerous concept, let alone the scaling > > issues involved. > > > > > > > > > > On Sun, Sep 2, 2018 at 1:33 AM Jacques Le Roux < > jacques.le.r...@les7arts.com> > > wrote: > > > > > Hi, > > > > > > Note: this conversation started on the dev ML: > > > https://markmail.org/message/hb2kt5nkodhwnkgw > > > > > > The multi-tenants feature in OFBiz only allows a dozens or maybe even > few > > > hundreds tenants, after it begin to be a lot of DBs! > > > I faced that with a startup which wanted to handle thousands, if not > > > millions (actually they failed), of tenants, obviously OFBiz can't do > that. > > > > > > I don't break any secret to say that I was working with David (and > Andrew) > > > on a project in 2010 when David had to quickly answer to the client's > > > demand who wanted to have tenants. David brilliantly and quickly > > > delivered, but it was only a start. > > > > > > After many improvements, this feature still have some issues > > > https://issues.apache.org/jira/browse/OFBIZ-6066 > > > https://issues.apache.org/jira/browse/OFBIZ-7900 > > > https://issues.apache.org/jira/browse/OFBIZ-6164 > > > https://issues.apache.org/jira/browse/OFBIZ-6065 > > > > > > Also this is somehow related > > > https://issues.apache.org/jira/browse/OFBIZ-6712 > > > > > > And most importantly > > > https://issues.apache.org/jira/browse/OFBIZ-7112 > > > https://issues.apache.org/jira/browse/OFBIZ-7754 > > > > > > I recently read this article > > > > > > > > > > https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/ > > > > > > and, after my experiences with multi-tenant as is in OFBiz, it made me > > > wonder if we should not think about how it's done now in OFBiz in 2018 > with > > > the > > > clouds being everywhere! > > > > > > Before sending this email, I quickly exchanged with David about how > Moqui > > > handles that now. And we are on the same page, see > > > > > > https://www.linkedin.com/groups/4640689/4640689-6180851287941201924 > > > > > > > > > > https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1 > > > [1] > > > > > > [1] Initially David gave me this link > > > > > > > https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/ > > > > > > but it seems LinkedIn has lost it, as said in the stackoverflow > comment. > > > > > > So IMO why not deprecating the multi-tenants as is now and rather push > a > > > multi-instances way? > > > > > > Opinions? > > > > > > Jacques > > > > > > >
RE: Purchase order minimum and packing units
Rishi - So does it give you the ability to purchase in one UOM and sell in another OOTB? So I buy quantity of 1 which will potentially put 100 in inventory Original Message Subject: Re: Purchase order minimum and packing units From: Rishi Solanki Date: Tue, September 04, 2018 2:12 am To: ofbizuser Hi Frank, As shared by Suraj, I'm up for using the quantity UOM over marketing package. Also Agreement is best suited for the minimum order amount. So I would go with Suraj's suggestion. HTH! Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Tue, Sep 4, 2018 at 1:55 PM Suraj Khurana < suraj.khur...@hotwaxsystems.com> wrote: > Hi Frank, > > For packing units, IMO, there could be two possible solution for this case. > One is to setup product in OFBiz of type marketing package (if supplier > have multiple packing quantities this fits best), this is available OOTB > and services available to decompose marketing package into singular units > that can be used for selling, you can setup marketing packages and use them > for PO and individual product can be used for selling purpose. > > On the other hand, it seems more feasible and less confusing to setup > quantity UOM while creating PO. This requires some custom changes as per > business while creating PO. SupplierProduct also have quantityUomId field > which can be used for this. Data model support is available OOTB and we can > define conversion quantity as per package quantity from Supplier. > > For Order minimum, IMO, we can use agreement model to achieve this. We > could have an agreement with supplier about minimum order amount and can > have some custom logic to check that agreement and allow user to place > order or not. > > HTH. > > -- > Thanks and Regards, > Suraj Khurana > Omnichannel OMS Technical Expert > HotWax Systems > > On Tue, Sep 4, 2018 at 12:36 PM, Frank Herrman > wrote: > > > Hi Rishi, > > > > Thank you for your reply. I see there are two fields: 'units included' > and > > 'order qty increments', should I use the latter in my case? It is not > that > > we order 1 product which contain 6 products, but that we are required to > > purchase them per 6. So the costprice of the product is the price of 1 > > product, not a box of 6. > > > > The minimum order quantity is set on the product level, but I want to set > > it on the supplier level. Furthermore I would like to have a minimum > order > > _amount_. I am not required to order a minimum number of one specific > > product from a supplier, but I do need to have a minimum order amount > which > > can be spread over multiple products. > > > > Kind regards, > > > > Frank > > > > Op 04-09-18 07:26 heeft Rishi Solanki > > geschreven: > > > > Hi Frank, > > For packing units and minimum purchase please refer to > SupplierProduct > > entity fields minimumOrderQuantity and unitsIncluded. This modeling > > supportive for purchasing from supplier. It works for all possible > > business > > use cases including yours. > > For sales minimum amount/quantity you may need to setup the > > ProductPrice > > for that product of type MINIMUM_ORDER_PRICE. Once setup the customer > > won't > > be able to purchase that product below that amount. On the basis of > > requirement you can decide the price to match the minimum > > amout/quantity. > > > > All this support OOTB available. HTH! > > > > -- > > Rishi Solanki > > Sr Manager, Enterprise Software Development > > HotWax Systems Pvt. Ltd. > > Direct: +91-9893287847 > > http://www.hotwaxsystems.com > > www.hotwax.co > > > > > > On Tue, Sep 4, 2018 at 1:10 AM Frank Herrman > > wrote: > > > > > Hi there, > > > > > > I am currently looking into the purchase orders within Ofbiz. I > > would like > > > to define two things: > > > > > > Packing units > > > Many products are packaged in boxes in sets of multiple items. The > > > supplier delivers them per 6, we sell them per 1. Now there is an > > option > > > per product per supplier to enter the minimum order quantity. This > > does not > > > seem to ensure I will buy the product in this example per 6. I can > > also > > > order 7 in that case. I want the system to let me only order 6, 12, > > 18 etc. > > > What is the best way to go there? > > > > > > Order minimum > > > Many suppliers require me to place orders of a minimum amount and > > > sometimes a minimum quantity (usually it’s amount). Where can I set > > this > > > up? This is also something that does not seem to work well with the > > > requirements module. Every order that makes my QoH go below my > > minimum > > > quantity a requirement is created. I can make a purchase order out > > of it, > > > but that will only contain that specific product. When I order > with a > > > supplier I want to be able to select from all the products he > > provides that > > > are below the QoH, and not in separate purchase orders. Is this > >
RE: Should we keep the multi-tenants feature in OFBiz?
So if you don't have multi-tenancy does that mean every tenant has their own install of OFbiz, their own install of Postgres SQL, and their own server farm? Original Message Subject: Re: Should we keep the multi-tenants feature in OFBiz? From: Taher Alkhateeb Date: Tue, September 04, 2018 9:12 am To: user@ofbiz.apache.org The question is: is it worth keeping it? To answer this question, perhaps we need to perhaps look at the pros and cons pros of keeping multi-tenancy: - less memory consumption. - less storage consumption. - single deployment (less effort) cons of keeping multi-tenancy: - Inflexibility: all tenants are stuck with the same code base. - risk: if one tenant goes down, all tenants go down. There is less redundancy and recovery. - lock-in: splitting out tenants to a new separate instance is hard and time consuming. - code complexity: The multi-tenancy feature in OFBiz is making nearly every critical artifact in the system complex. It is hard wired in tomcat, components, data loaders and many other places. I stopped counting the "if" conditions to handle the multi-tenant corner cases all over the code base. - alternatives less complex: the advent of new technologies like docker and containerization makes the need for multi-tenancy less desired. Also, storage and memory is getting cheaper all the time. So the pros listed above are getting less valuable over time. So for all the above, I find myself leaning more towards removing multi-tenancy from the code base. On Tue, Sep 4, 2018 at 5:49 PM Mike wrote: > > My opinion is to just completely ditch the multi tenant code since it seems > to be more trouble than it's worth. Anyone serious about designing a > system to support a similar concept would do it their own way anyway, most > likely using completely separate DBs. Face it, using a common DB and share > between separate companies is a dangerous concept, let alone the scaling > issues involved. > > > > > On Sun, Sep 2, 2018 at 1:33 AM Jacques Le Roux > wrote: > > > Hi, > > > > Note: this conversation started on the dev ML: > > https://markmail.org/message/hb2kt5nkodhwnkgw > > > > The multi-tenants feature in OFBiz only allows a dozens or maybe even few > > hundreds tenants, after it begin to be a lot of DBs! > > I faced that with a startup which wanted to handle thousands, if not > > millions (actually they failed), of tenants, obviously OFBiz can't do that. > > > > I don't break any secret to say that I was working with David (and Andrew) > > on a project in 2010 when David had to quickly answer to the client's > > demand who wanted to have tenants. David brilliantly and quickly > > delivered, but it was only a start. > > > > After many improvements, this feature still have some issues > > https://issues.apache.org/jira/browse/OFBIZ-6066 > > https://issues.apache.org/jira/browse/OFBIZ-7900 > > https://issues.apache.org/jira/browse/OFBIZ-6164 > > https://issues.apache.org/jira/browse/OFBIZ-6065 > > > > Also this is somehow related > > https://issues.apache.org/jira/browse/OFBIZ-6712 > > > > And most importantly > > https://issues.apache.org/jira/browse/OFBIZ-7112 > > https://issues.apache.org/jira/browse/OFBIZ-7754 > > > > I recently read this article > > > > > > https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/ > > > > and, after my experiences with multi-tenant as is in OFBiz, it made me > > wonder if we should not think about how it's done now in OFBiz in 2018 with > > the > > clouds being everywhere! > > > > Before sending this email, I quickly exchanged with David about how Moqui > > handles that now. And we are on the same page, see > > > > https://www.linkedin.com/groups/4640689/4640689-6180851287941201924 > > > > > > https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1 > > [1] > > > > [1] Initially David gave me this link > > > > https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/ > > > > but it seems LinkedIn has lost it, as said in the stackoverflow comment. > > > > So IMO why not deprecating the multi-tenants as is now and rather push a > > multi-instances way? > > > > Opinions? > > > > Jacques > > > >
Re: Should we keep the multi-tenants feature in OFBiz?
The question is: is it worth keeping it? To answer this question, perhaps we need to perhaps look at the pros and cons pros of keeping multi-tenancy: - less memory consumption. - less storage consumption. - single deployment (less effort) cons of keeping multi-tenancy: - Inflexibility: all tenants are stuck with the same code base. - risk: if one tenant goes down, all tenants go down. There is less redundancy and recovery. - lock-in: splitting out tenants to a new separate instance is hard and time consuming. - code complexity: The multi-tenancy feature in OFBiz is making nearly every critical artifact in the system complex. It is hard wired in tomcat, components, data loaders and many other places. I stopped counting the "if" conditions to handle the multi-tenant corner cases all over the code base. - alternatives less complex: the advent of new technologies like docker and containerization makes the need for multi-tenancy less desired. Also, storage and memory is getting cheaper all the time. So the pros listed above are getting less valuable over time. So for all the above, I find myself leaning more towards removing multi-tenancy from the code base. On Tue, Sep 4, 2018 at 5:49 PM Mike wrote: > > My opinion is to just completely ditch the multi tenant code since it seems > to be more trouble than it's worth. Anyone serious about designing a > system to support a similar concept would do it their own way anyway, most > likely using completely separate DBs. Face it, using a common DB and share > between separate companies is a dangerous concept, let alone the scaling > issues involved. > > > > > On Sun, Sep 2, 2018 at 1:33 AM Jacques Le Roux > wrote: > > > Hi, > > > > Note: this conversation started on the dev ML: > > https://markmail.org/message/hb2kt5nkodhwnkgw > > > > The multi-tenants feature in OFBiz only allows a dozens or maybe even few > > hundreds tenants, after it begin to be a lot of DBs! > > I faced that with a startup which wanted to handle thousands, if not > > millions (actually they failed), of tenants, obviously OFBiz can't do that. > > > > I don't break any secret to say that I was working with David (and Andrew) > > on a project in 2010 when David had to quickly answer to the client's > > demand who wanted to have tenants. David brilliantly and quickly > > delivered, but it was only a start. > > > > After many improvements, this feature still have some issues > > https://issues.apache.org/jira/browse/OFBIZ-6066 > > https://issues.apache.org/jira/browse/OFBIZ-7900 > > https://issues.apache.org/jira/browse/OFBIZ-6164 > > https://issues.apache.org/jira/browse/OFBIZ-6065 > > > > Also this is somehow related > > https://issues.apache.org/jira/browse/OFBIZ-6712 > > > > And most importantly > > https://issues.apache.org/jira/browse/OFBIZ-7112 > > https://issues.apache.org/jira/browse/OFBIZ-7754 > > > > I recently read this article > > > > > > https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/ > > > > and, after my experiences with multi-tenant as is in OFBiz, it made me > > wonder if we should not think about how it's done now in OFBiz in 2018 with > > the > > clouds being everywhere! > > > > Before sending this email, I quickly exchanged with David about how Moqui > > handles that now. And we are on the same page, see > > > > https://www.linkedin.com/groups/4640689/4640689-6180851287941201924 > > > > > > https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1 > > [1] > > > > [1] Initially David gave me this link > > > > https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/ > > > > but it seems LinkedIn has lost it, as said in the stackoverflow comment. > > > > So IMO why not deprecating the multi-tenants as is now and rather push a > > multi-instances way? > > > > Opinions? > > > > Jacques > > > >
Re: Should we keep the multi-tenants feature in OFBiz?
My opinion is to just completely ditch the multi tenant code since it seems to be more trouble than it's worth. Anyone serious about designing a system to support a similar concept would do it their own way anyway, most likely using completely separate DBs. Face it, using a common DB and share between separate companies is a dangerous concept, let alone the scaling issues involved. On Sun, Sep 2, 2018 at 1:33 AM Jacques Le Roux wrote: > Hi, > > Note: this conversation started on the dev ML: > https://markmail.org/message/hb2kt5nkodhwnkgw > > The multi-tenants feature in OFBiz only allows a dozens or maybe even few > hundreds tenants, after it begin to be a lot of DBs! > I faced that with a startup which wanted to handle thousands, if not > millions (actually they failed), of tenants, obviously OFBiz can't do that. > > I don't break any secret to say that I was working with David (and Andrew) > on a project in 2010 when David had to quickly answer to the client's > demand who wanted to have tenants. David brilliantly and quickly > delivered, but it was only a start. > > After many improvements, this feature still have some issues > https://issues.apache.org/jira/browse/OFBIZ-6066 > https://issues.apache.org/jira/browse/OFBIZ-7900 > https://issues.apache.org/jira/browse/OFBIZ-6164 > https://issues.apache.org/jira/browse/OFBIZ-6065 > > Also this is somehow related > https://issues.apache.org/jira/browse/OFBIZ-6712 > > And most importantly > https://issues.apache.org/jira/browse/OFBIZ-7112 > https://issues.apache.org/jira/browse/OFBIZ-7754 > > I recently read this article > > > https://www.linkedin.com/pulse/architecture-constraints-end-multi-tenancy-gregor-hohpe/ > > and, after my experiences with multi-tenant as is in OFBiz, it made me > wonder if we should not think about how it's done now in OFBiz in 2018 with > the > clouds being everywhere! > > Before sending this email, I quickly exchanged with David about how Moqui > handles that now. And we are on the same page, see > > https://www.linkedin.com/groups/4640689/4640689-6180851287941201924 > > > https://stackoverflow.com/questions/41952818/does-moqui-framework-2-0-still-support-mutli-tenency?rq=1 > [1] > > [1] Initially David gave me this link > > https://www.linkedin.com/pulse/multi-instance-moqui-docker-david-e-jones/ > > but it seems LinkedIn has lost it, as said in the stackoverflow comment. > > So IMO why not deprecating the multi-tenants as is now and rather push a > multi-instances way? > > Opinions? > > Jacques > >
Re: Purchase order minimum and packing units
Hi Frank, As shared by Suraj, I'm up for using the quantity UOM over marketing package. Also Agreement is best suited for the minimum order amount. So I would go with Suraj's suggestion. HTH! Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Tue, Sep 4, 2018 at 1:55 PM Suraj Khurana < suraj.khur...@hotwaxsystems.com> wrote: > Hi Frank, > > For packing units, IMO, there could be two possible solution for this case. > One is to setup product in OFBiz of type marketing package (if supplier > have multiple packing quantities this fits best), this is available OOTB > and services available to decompose marketing package into singular units > that can be used for selling, you can setup marketing packages and use them > for PO and individual product can be used for selling purpose. > > On the other hand, it seems more feasible and less confusing to setup > quantity UOM while creating PO. This requires some custom changes as per > business while creating PO. SupplierProduct also have quantityUomId field > which can be used for this. Data model support is available OOTB and we can > define conversion quantity as per package quantity from Supplier. > > For Order minimum, IMO, we can use agreement model to achieve this. We > could have an agreement with supplier about minimum order amount and can > have some custom logic to check that agreement and allow user to place > order or not. > > HTH. > > -- > Thanks and Regards, > Suraj Khurana > Omnichannel OMS Technical Expert > HotWax Systems > > On Tue, Sep 4, 2018 at 12:36 PM, Frank Herrman > wrote: > > > Hi Rishi, > > > > Thank you for your reply. I see there are two fields: 'units included' > and > > 'order qty increments', should I use the latter in my case? It is not > that > > we order 1 product which contain 6 products, but that we are required to > > purchase them per 6. So the costprice of the product is the price of 1 > > product, not a box of 6. > > > > The minimum order quantity is set on the product level, but I want to set > > it on the supplier level. Furthermore I would like to have a minimum > order > > _amount_. I am not required to order a minimum number of one specific > > product from a supplier, but I do need to have a minimum order amount > which > > can be spread over multiple products. > > > > Kind regards, > > > > Frank > > > > Op 04-09-18 07:26 heeft Rishi Solanki > > geschreven: > > > > Hi Frank, > > For packing units and minimum purchase please refer to > SupplierProduct > > entity fields minimumOrderQuantity and unitsIncluded. This modeling > > supportive for purchasing from supplier. It works for all possible > > business > > use cases including yours. > > For sales minimum amount/quantity you may need to setup the > > ProductPrice > > for that product of type MINIMUM_ORDER_PRICE. Once setup the customer > > won't > > be able to purchase that product below that amount. On the basis of > > requirement you can decide the price to match the minimum > > amout/quantity. > > > > All this support OOTB available. HTH! > > > > -- > > Rishi Solanki > > Sr Manager, Enterprise Software Development > > HotWax Systems Pvt. Ltd. > > Direct: +91-9893287847 > > http://www.hotwaxsystems.com > > www.hotwax.co > > > > > > On Tue, Sep 4, 2018 at 1:10 AM Frank Herrman > > wrote: > > > > > Hi there, > > > > > > I am currently looking into the purchase orders within Ofbiz. I > > would like > > > to define two things: > > > > > > Packing units > > > Many products are packaged in boxes in sets of multiple items. The > > > supplier delivers them per 6, we sell them per 1. Now there is an > > option > > > per product per supplier to enter the minimum order quantity. This > > does not > > > seem to ensure I will buy the product in this example per 6. I can > > also > > > order 7 in that case. I want the system to let me only order 6, 12, > > 18 etc. > > > What is the best way to go there? > > > > > > Order minimum > > > Many suppliers require me to place orders of a minimum amount and > > > sometimes a minimum quantity (usually it’s amount). Where can I set > > this > > > up? This is also something that does not seem to work well with the > > > requirements module. Every order that makes my QoH go below my > > minimum > > > quantity a requirement is created. I can make a purchase order out > > of it, > > > but that will only contain that specific product. When I order > with a > > > supplier I want to be able to select from all the products he > > provides that > > > are below the QoH, and not in separate purchase orders. Is this > > possible as > > > well? > > > > > > Thank you in advance again. > > > > > > Kind regards, > > > > > > Frank > > > > > > > > > > > > >
Re: Purchase order minimum and packing units
Hi Frank, For packing units, IMO, there could be two possible solution for this case. One is to setup product in OFBiz of type marketing package (if supplier have multiple packing quantities this fits best), this is available OOTB and services available to decompose marketing package into singular units that can be used for selling, you can setup marketing packages and use them for PO and individual product can be used for selling purpose. On the other hand, it seems more feasible and less confusing to setup quantity UOM while creating PO. This requires some custom changes as per business while creating PO. SupplierProduct also have quantityUomId field which can be used for this. Data model support is available OOTB and we can define conversion quantity as per package quantity from Supplier. For Order minimum, IMO, we can use agreement model to achieve this. We could have an agreement with supplier about minimum order amount and can have some custom logic to check that agreement and allow user to place order or not. HTH. -- Thanks and Regards, Suraj Khurana Omnichannel OMS Technical Expert HotWax Systems On Tue, Sep 4, 2018 at 12:36 PM, Frank Herrman wrote: > Hi Rishi, > > Thank you for your reply. I see there are two fields: 'units included' and > 'order qty increments', should I use the latter in my case? It is not that > we order 1 product which contain 6 products, but that we are required to > purchase them per 6. So the costprice of the product is the price of 1 > product, not a box of 6. > > The minimum order quantity is set on the product level, but I want to set > it on the supplier level. Furthermore I would like to have a minimum order > _amount_. I am not required to order a minimum number of one specific > product from a supplier, but I do need to have a minimum order amount which > can be spread over multiple products. > > Kind regards, > > Frank > > Op 04-09-18 07:26 heeft Rishi Solanki > geschreven: > > Hi Frank, > For packing units and minimum purchase please refer to SupplierProduct > entity fields minimumOrderQuantity and unitsIncluded. This modeling > supportive for purchasing from supplier. It works for all possible > business > use cases including yours. > For sales minimum amount/quantity you may need to setup the > ProductPrice > for that product of type MINIMUM_ORDER_PRICE. Once setup the customer > won't > be able to purchase that product below that amount. On the basis of > requirement you can decide the price to match the minimum > amout/quantity. > > All this support OOTB available. HTH! > > -- > Rishi Solanki > Sr Manager, Enterprise Software Development > HotWax Systems Pvt. Ltd. > Direct: +91-9893287847 > http://www.hotwaxsystems.com > www.hotwax.co > > > On Tue, Sep 4, 2018 at 1:10 AM Frank Herrman > wrote: > > > Hi there, > > > > I am currently looking into the purchase orders within Ofbiz. I > would like > > to define two things: > > > > Packing units > > Many products are packaged in boxes in sets of multiple items. The > > supplier delivers them per 6, we sell them per 1. Now there is an > option > > per product per supplier to enter the minimum order quantity. This > does not > > seem to ensure I will buy the product in this example per 6. I can > also > > order 7 in that case. I want the system to let me only order 6, 12, > 18 etc. > > What is the best way to go there? > > > > Order minimum > > Many suppliers require me to place orders of a minimum amount and > > sometimes a minimum quantity (usually it’s amount). Where can I set > this > > up? This is also something that does not seem to work well with the > > requirements module. Every order that makes my QoH go below my > minimum > > quantity a requirement is created. I can make a purchase order out > of it, > > but that will only contain that specific product. When I order with a > > supplier I want to be able to select from all the products he > provides that > > are below the QoH, and not in separate purchase orders. Is this > possible as > > well? > > > > Thank you in advance again. > > > > Kind regards, > > > > Frank > > > > > > >
Re: Purchase order minimum and packing units
Hi Rishi, Thank you for your reply. I see there are two fields: 'units included' and 'order qty increments', should I use the latter in my case? It is not that we order 1 product which contain 6 products, but that we are required to purchase them per 6. So the costprice of the product is the price of 1 product, not a box of 6. The minimum order quantity is set on the product level, but I want to set it on the supplier level. Furthermore I would like to have a minimum order _amount_. I am not required to order a minimum number of one specific product from a supplier, but I do need to have a minimum order amount which can be spread over multiple products. Kind regards, Frank Op 04-09-18 07:26 heeft Rishi Solanki geschreven: Hi Frank, For packing units and minimum purchase please refer to SupplierProduct entity fields minimumOrderQuantity and unitsIncluded. This modeling supportive for purchasing from supplier. It works for all possible business use cases including yours. For sales minimum amount/quantity you may need to setup the ProductPrice for that product of type MINIMUM_ORDER_PRICE. Once setup the customer won't be able to purchase that product below that amount. On the basis of requirement you can decide the price to match the minimum amout/quantity. All this support OOTB available. HTH! -- Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Tue, Sep 4, 2018 at 1:10 AM Frank Herrman wrote: > Hi there, > > I am currently looking into the purchase orders within Ofbiz. I would like > to define two things: > > Packing units > Many products are packaged in boxes in sets of multiple items. The > supplier delivers them per 6, we sell them per 1. Now there is an option > per product per supplier to enter the minimum order quantity. This does not > seem to ensure I will buy the product in this example per 6. I can also > order 7 in that case. I want the system to let me only order 6, 12, 18 etc. > What is the best way to go there? > > Order minimum > Many suppliers require me to place orders of a minimum amount and > sometimes a minimum quantity (usually it’s amount). Where can I set this > up? This is also something that does not seem to work well with the > requirements module. Every order that makes my QoH go below my minimum > quantity a requirement is created. I can make a purchase order out of it, > but that will only contain that specific product. When I order with a > supplier I want to be able to select from all the products he provides that > are below the QoH, and not in separate purchase orders. Is this possible as > well? > > Thank you in advance again. > > Kind regards, > > Frank > >
