Salmon LLC: OFBiz eCommerce Site Goes Live

[Nick Rosser]

All,

 

Just a note to let you know that we recently released an eCommerce site.
Check out www.purityproducts.com.

 

Launched a couple of weeks ago, to very little fanfare, this is a complete
replacement of an existing site, with no upgrades to the UI or basic
eCommerce structure. A straight conversion to OFBiz as a platform change to
allow for future changes, enhancements and growth.

 

This is on the back of a very successful ERP release last year for the same
customer, our first OFBiz implementation. Challenging, to say the least, but
very successful in terms of laying the same platform for the back-end
processes, with a specific focus on a very intense and customized CSR layer.


 

Of interest to some, particularly given recent posts about community-driven
OFBiz and various discussions about the lack of process and documentation I
thought I'd share our  experience of using OFBiz during the last 2 years.
First a little background on Salmon LLC that I think is relevant:

 

Our background:

 

*       we have released open-source framework software in the past

*       we have developed many custom J2EE solutions

*       we have adopted other ERP solutions prior to OFBiz (Compiere /
Adempiere - before bailing because it was not really open-source)

*       we have adopted other packaged solutions in other business areas

*       we're a technical company, with business savvy

*       we can figure stuff out

 

OFBiz, the good:

 

*       nice architecture, we were generally impressed with the service
based approach

*       the services work. For us, OFBiz is a starting point, the services
are available and they work!

*       the community support is amazing; the commitment of everyone
monitoring this thread and providing responses is commendable

 

OFBiz, the not so good:

 

*       UI ootb: not the best. BUT, we understand the objective (framework)
and we understand the ERP domain to realize that OFBiz is a starting point;
and a pretty good one

*       architecture: next level of concepts was harder to grasp, as you dig
more into the code the more confusing it can get; the lack of good coding
standards can make it very confusing as to what exactly is the best practice
(particularly when looking at "older" code)

*       the devil is in the details, and there are a lot of them; be
prepared to make mistakes, having to figure stuff out for yourself, lots of
trial and error

*       community support: when it gets a little tricky it's much more
difficult to explain the issue and get a good community response. Perfectly
understandable but this is where the risk comes into play . we spent
countless hours on some very tricky payment processing issues (credit, card,
returns, refunds) and inventory processing

*       what a pity that the documentation cannot encapsulate all the
knowledge from the user-group. Yes, I know we can search through email
postings. Yes, I know that the documentation is improving. But there are
still problems in this area, perhaps I can share one specific example:

 

One specific example:

 

*       Product A is put with product B in order to offer product C

*       Product A and B may (or may not) have inventory associated

*       When assembled into C, this can also carry inventory

*       When the item is returned, it may be put back into inventory as
product C, OR may be disassembled into products A and B

*       Fairly straight forward and not uncommon, and I'm sure that OFBiz
can handle this but we couldn't find ANY document that would clearly explain
product configuration and it's impact on other areas of the ERP solution

*       I remember being amazed that a thorough product configuration guide
was not available that would explain all the product attributes and a high
level description of the impact throughout OFBiz. What's more important is
that if you guess wrong then you can cause all sorts of problems

*       BTW: since this was a while ago I did review the current
documentation, the only item I saw that described setting up a product was
the "Business Setup Guide (for users)", the content for Product Setup is
pasted below. The best looking resource is I understand that there may be
more documentation available that is more appropriate . BUT, if I'm new to
OFBiz and cannot find something decent after a few minutes then I'll move on
very quickly

 

So, where are we now? Well, I think we can safely say that we are OFBiz
adopters, it took much sweat and tears to get to where we are now but I
consider my team to be well versed, near expert, with ERP and eCommerce
implementations using OFBiz. I'm very comfortable offering this service to
our clients, and very comfortable with our ability to deliver scalable ERP
and eCommerce solutions.

 

HOWEVER, our first implementation was very stressful. And in hindsight, very
risky. Remember that ERP solutions are "bet your business" propositions . we
cannot make mistakes. If we do, we jeopardize our business and the business
of our clients. In our first implementation we are processing 5000 orders
per day. For the first 3-4 weeks of go-live the background jobs were taking
more than 24 hours to run (build orders from a recurring order list, process
orders for fulfillment, manage incoming inventory, process credit card
transactions, PLUS any new orders for that day). Saturdays and Sundays were
used to make-up the time while we figured out solutions! As you can imagine
we had a very stressful time working with our client, tuning our processes
and working with our client to keep OFBiz as the ERP solution. I'm happy to
report that everything is perfectly fine now, but this is not the way we
like to do business.

 

I consider my team to be extremely committed, technically excellent and
business savvy. I wonder how small companies or small integrators adopt
OFBiz without these resources?

 

Conclusion:

 

*       As I re-read my comments and gather my thoughts it basically boils
down to documentation

*       We did not have the luxury of being able to hire a certified "guru"
to help out (we did have David Jones spend a week with us initially and used
a couple of committers for specific tasks) but there is generally no
"corporate" option to ensure success

*       Best practices / coding techniques etc are exposed because of the
open-source nature of OFBiz; it's probably better written than other
proprietary software; this is not an essential issue

*       So everything hinges on community support. Lots of it is required
for early adopters and we see these postings every day. For folks that have
moved into more complex areas (like we were 12 months ago), the community
support is not enough-the issues are too complex

*       As an open-source project, without formal corporate backing, the key
is documentation, not just technical. And I suspect that we need more than
Oracle and SAP because of the community nature of the project

 

Nick Rosser

Salmon LLC

 

 


Product Setup


Congratulations, you are finally to the point where you can start setting up
products....

To create a Product follow a process similar to those described for other
things, like Categories.

1. Go to the main page of the Catalog Manager and click on the "Create
New Product" link.
2. If you fill in an ID it will make sure that ID is valid, and if so
it will use that one. If you specify no ID it will generate one.
3. Set an Internal Name that makes it easy for you to recognize the
product. This name will be shown in the admin tools, but not to the
customer.
4. Note that if you are using the UPS or USPS or other online rate
estimation utilities then you must have values in the "Weight" and "Weight
Uom Id" fields.
5. Submit the form to create the product.

Add Content to the New Product

1. Click on the "Content" tab/button for the product you just created.
Here you can setup text and images for your product.
2. You will see some forms at the top for administering managed content
(ie from the Content Manager) with the product. For more advanced product
related content needs use this, but for more common and simple needs, this
can be more difficult to administer and slower at run time.
3. Near the bottom of the page is a section labeled "Override Simple
Fields". Here you will typically want to specify a Product Name, Product
Description, and Long Description. If you have images to associate with the
product, you can specify their locations here, or upload them. Note that
there are default locations for the images (can be quickly set by clicking
on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
but of course you can put your images anywhere. These can be an absolute
URL, or will be relative to the current server address, or the content URL
prefix if one is specified in the url.properties file.

Add Prices to the Product

1. Product pricing in OFBiz is very flexible. There are two main
aspects to it: Prices and Price Rules. This is independent of promotions,
which are applied after the price calculation is done.
2. For basic operation you should have at least one type of price setup
for each product: the Default Price. This is the price that is used when no
rules apply.
3. To add a Default Price go to the Prices tab for the Product, and use
the form at the bottom of the page.

1. The Product Price Type Id should be "Default Price", the Currency
Uom Id should be whatever currency the price is in, and the Product Store
Group Id can be left as Not Applicable, unless you are setting up multiple
groups of stores that have different pricing.
2. The From Date can be now or in the future, if you want the price to
take effect in the future. The Thru Date is optional, but can be used to
specify that this particular price expires at a certain date and time. Note
that if there are multiple prices of the same type, etc that are active at
once, it will use the one with the most recent From Date. This is useful
when you want a temporary price to override the normal "Default" price of
the product.

4. If you are using price rules or may do so in the future you may also
want to enter information such as the List Price and the Average Cost which
are often used in the price calculations.
5. Note that if a Minimum Price is set the price will never be less
than that. So, even if the Default Price is to 2.00 and the Minimum Price is
set to 3.00, then 3.00 will be used as the calculated price. The Maximum
Price setting works the same way as the ceiling for the price.

Make sure to put each product in a browse category, and in the All Products
category so that it can be searched for, viewed, and purchased in your
catalog.

Expert Recommendation: These are the basics, but there is a lot more
information about products that you can, or may need to, setup. We recommend
reviewing the more detailed documentation or engaging the services of an
experienced consulting to help you through this.

Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
Thesaurus, Features for special functionality or parametric search,
Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
Products, Virtual and Variant Products, Inventory/Facility/Location
settings, and so on

See the end-user documentation space for details on how to set these things
up and what they mean. Also see this for more advanced options for Products,
Categories, and so on.

 

 

[Tim Ruppert]

Great post Nick - and thanks for being one of those vendors who is giving back to the community - especially with this level of detail.  We enjoyed working with you and are stoked to see that thru your hard work and patience with the community you were able to achieve the level of internal adoption that many people strive for, but are unsuccessful.  The points you lay out here are great for everyone to hear - and I think really hit the nail on the head as far as the difficulty of less technical, and even less resourced companies face.

That being said, I believe that there are commercial entities in the OFBiz world with the right processes, enough firepower (read resources) and expertise to ensure success in your project.  This may not have been the case when you first started, but I think that has changed.

This does not mean that any one entity has to run the entire project - like say a JBoss or a MySQL - but there is really not much difference in paying for MySQL support services than paying the high tiered support offerings with OFBiz.  You just have to choose the right group and find the right individuals to help you along - and my personal opinion is that they are out there.

Sorry to digress - now, back to your original point, there are a ton of things that the community can improve upon that you mentioned below.  Can you put these together up on the Wiki, much like we've discussed in other threads, so that we can begin to track our progress?  I'd like to see the documentation angle continue to get worked thru (technical and end-user) - possibly moving some of the documentation that I know that people are creating internally - out to a place where everyone can appreciate it without having to pay additional money.

We need to come together to make this happen - and it will only get there if all of the corporate entities out there begin to or continue to support the community by donating a ton of time into documentation, mailing list responses, enhanced applications.   Thanks again Nick - this is great stuff.

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Mar 2, 2010, at 7:08 AM, Nick Rosser wrote:

> All,
>
>
>
> Just a note to let you know that we recently released an eCommerce site.
> Check out www.purityproducts.com.
>
>
>
> Launched a couple of weeks ago, to very little fanfare, this is a complete
> replacement of an existing site, with no upgrades to the UI or basic
> eCommerce structure. A straight conversion to OFBiz as a platform change to
> allow for future changes, enhancements and growth.
>
>
>
> This is on the back of a very successful ERP release last year for the same
> customer, our first OFBiz implementation. Challenging, to say the least, but
> very successful in terms of laying the same platform for the back-end
> processes, with a specific focus on a very intense and customized CSR layer.
>
>
>
>
> Of interest to some, particularly given recent posts about community-driven
> OFBiz and various discussions about the lack of process and documentation I
> thought I'd share our  experience of using OFBiz during the last 2 years.
> First a little background on Salmon LLC that I think is relevant:
>
>
>
> Our background:
>
>
>
> *       we have released open-source framework software in the past
>
> *       we have developed many custom J2EE solutions
>
> *       we have adopted other ERP solutions prior to OFBiz (Compiere /
> Adempiere - before bailing because it was not really open-source)
>
> *       we have adopted other packaged solutions in other business areas
>
> *       we're a technical company, with business savvy
>
> *       we can figure stuff out
>
>
>
> OFBiz, the good:
>
>
>
> *       nice architecture, we were generally impressed with the service
> based approach
>
> *       the services work. For us, OFBiz is a starting point, the services
> are available and they work!
>
> *       the community support is amazing; the commitment of everyone
> monitoring this thread and providing responses is commendable
>
>
>
> OFBiz, the not so good:
>
>
>
> *       UI ootb: not the best. BUT, we understand the objective (framework)
> and we understand the ERP domain to realize that OFBiz is a starting point;
> and a pretty good one
>
> *       architecture: next level of concepts was harder to grasp, as you dig
> more into the code the more confusing it can get; the lack of good coding
> standards can make it very confusing as to what exactly is the best practice
> (particularly when looking at "older" code)
>
> *       the devil is in the details, and there are a lot of them; be
> prepared to make mistakes, having to figure stuff out for yourself, lots of
> trial and error
>
> *       community support: when it gets a little tricky it's much more
> difficult to explain the issue and get a good community response. Perfectly
> understandable but this is where the risk comes into play . we spent
> countless hours on some very tricky payment processing issues (credit, card,
> returns, refunds) and inventory processing
>
> *       what a pity that the documentation cannot encapsulate all the
> knowledge from the user-group. Yes, I know we can search through email
> postings. Yes, I know that the documentation is improving. But there are
> still problems in this area, perhaps I can share one specific example:
>
>
>
> One specific example:
>
>
>
> *       Product A is put with product B in order to offer product C
>
> *       Product A and B may (or may not) have inventory associated
>
> *       When assembled into C, this can also carry inventory
>
> *       When the item is returned, it may be put back into inventory as
> product C, OR may be disassembled into products A and B
>
> *       Fairly straight forward and not uncommon, and I'm sure that OFBiz
> can handle this but we couldn't find ANY document that would clearly explain
> product configuration and it's impact on other areas of the ERP solution
>
> *       I remember being amazed that a thorough product configuration guide
> was not available that would explain all the product attributes and a high
> level description of the impact throughout OFBiz. What's more important is
> that if you guess wrong then you can cause all sorts of problems
>
> *       BTW: since this was a while ago I did review the current
> documentation, the only item I saw that described setting up a product was
> the "Business Setup Guide (for users)", the content for Product Setup is
> pasted below. The best looking resource is I understand that there may be
> more documentation available that is more appropriate . BUT, if I'm new to
> OFBiz and cannot find something decent after a few minutes then I'll move on
> very quickly
>
>
>
> So, where are we now? Well, I think we can safely say that we are OFBiz
> adopters, it took much sweat and tears to get to where we are now but I
> consider my team to be well versed, near expert, with ERP and eCommerce
> implementations using OFBiz. I'm very comfortable offering this service to
> our clients, and very comfortable with our ability to deliver scalable ERP
> and eCommerce solutions.
>
>
>
> HOWEVER, our first implementation was very stressful. And in hindsight, very
> risky. Remember that ERP solutions are "bet your business" propositions . we
> cannot make mistakes. If we do, we jeopardize our business and the business
> of our clients. In our first implementation we are processing 5000 orders
> per day. For the first 3-4 weeks of go-live the background jobs were taking
> more than 24 hours to run (build orders from a recurring order list, process
> orders for fulfillment, manage incoming inventory, process credit card
> transactions, PLUS any new orders for that day). Saturdays and Sundays were
> used to make-up the time while we figured out solutions! As you can imagine
> we had a very stressful time working with our client, tuning our processes
> and working with our client to keep OFBiz as the ERP solution. I'm happy to
> report that everything is perfectly fine now, but this is not the way we
> like to do business.
>
>
>
> I consider my team to be extremely committed, technically excellent and
> business savvy. I wonder how small companies or small integrators adopt
> OFBiz without these resources?
>
>
>
> Conclusion:
>
>
>
> *       As I re-read my comments and gather my thoughts it basically boils
> down to documentation
>
> *       We did not have the luxury of being able to hire a certified "guru"
> to help out (we did have David Jones spend a week with us initially and used
> a couple of committers for specific tasks) but there is generally no
> "corporate" option to ensure success
>
> *       Best practices / coding techniques etc are exposed because of the
> open-source nature of OFBiz; it's probably better written than other
> proprietary software; this is not an essential issue
>
> *       So everything hinges on community support. Lots of it is required
> for early adopters and we see these postings every day. For folks that have
> moved into more complex areas (like we were 12 months ago), the community
> support is not enough-the issues are too complex
>
> *       As an open-source project, without formal corporate backing, the key
> is documentation, not just technical. And I suspect that we need more than
> Oracle and SAP because of the community nature of the project
>
>
>
> Nick Rosser
>
> Salmon LLC
>
>
>
>
>
>
> Product Setup
>
>
> Congratulations, you are finally to the point where you can start setting up
> products....
>
> To create a Product follow a process similar to those described for other
> things, like Categories.
>
> 1. Go to the main page of the Catalog Manager and click on the "Create
> New Product" link.
> 2. If you fill in an ID it will make sure that ID is valid, and if so
> it will use that one. If you specify no ID it will generate one.
> 3. Set an Internal Name that makes it easy for you to recognize the
> product. This name will be shown in the admin tools, but not to the
> customer.
> 4. Note that if you are using the UPS or USPS or other online rate
> estimation utilities then you must have values in the "Weight" and "Weight
> Uom Id" fields.
> 5. Submit the form to create the product.
>
> Add Content to the New Product
>
> 1. Click on the "Content" tab/button for the product you just created.
> Here you can setup text and images for your product.
> 2. You will see some forms at the top for administering managed content
> (ie from the Content Manager) with the product. For more advanced product
> related content needs use this, but for more common and simple needs, this
> can be more difficult to administer and slower at run time.
> 3. Near the bottom of the page is a section labeled "Override Simple
> Fields". Here you will typically want to specify a Product Name, Product
> Description, and Long Description. If you have images to associate with the
> product, you can specify their locations here, or upload them. Note that
> there are default locations for the images (can be quickly set by clicking
> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
> but of course you can put your images anywhere. These can be an absolute
> URL, or will be relative to the current server address, or the content URL
> prefix if one is specified in the url.properties file.
>
> Add Prices to the Product
>
> 1. Product pricing in OFBiz is very flexible. There are two main
> aspects to it: Prices and Price Rules. This is independent of promotions,
> which are applied after the price calculation is done.
> 2. For basic operation you should have at least one type of price setup
> for each product: the Default Price. This is the price that is used when no
> rules apply.
> 3. To add a Default Price go to the Prices tab for the Product, and use
> the form at the bottom of the page.
>
> 1. The Product Price Type Id should be "Default Price", the Currency
> Uom Id should be whatever currency the price is in, and the Product Store
> Group Id can be left as Not Applicable, unless you are setting up multiple
> groups of stores that have different pricing.
> 2. The From Date can be now or in the future, if you want the price to
> take effect in the future. The Thru Date is optional, but can be used to
> specify that this particular price expires at a certain date and time. Note
> that if there are multiple prices of the same type, etc that are active at
> once, it will use the one with the most recent From Date. This is useful
> when you want a temporary price to override the normal "Default" price of
> the product.
>
> 4. If you are using price rules or may do so in the future you may also
> want to enter information such as the List Price and the Average Cost which
> are often used in the price calculations.
> 5. Note that if a Minimum Price is set the price will never be less
> than that. So, even if the Default Price is to 2.00 and the Minimum Price is
> set to 3.00, then 3.00 will be used as the calculated price. The Maximum
> Price setting works the same way as the ceiling for the price.
>
> Make sure to put each product in a browse category, and in the All Products
> category so that it can be searched for, viewed, and purchased in your
> catalog.
>
> Expert Recommendation: These are the basics, but there is a lot more
> information about products that you can, or may need to, setup. We recommend
> reviewing the more detailed documentation or engaging the services of an
> experienced consulting to help you through this.
>
> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
> Thesaurus, Features for special functionality or parametric search,
> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
> Products, Virtual and Variant Products, Inventory/Facility/Location
> settings, and so on
>
> See the end-user documentation space for details on how to set these things
> up and what they mean. Also see this for more advanced options for Products,
> Categories, and so on.
>
>
>
>
>

[Jacques Le Roux]

Nick,

This might fit well at http://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+User+Stories this page is editable (need an
account created)

Thanks

Jacques

From: "Nick Rosser" <[hidden email]>

> All,
>
>
>
> Just a note to let you know that we recently released an eCommerce site.
> Check out www.purityproducts.com.
>
>
>
> Launched a couple of weeks ago, to very little fanfare, this is a complete
> replacement of an existing site, with no upgrades to the UI or basic
> eCommerce structure. A straight conversion to OFBiz as a platform change to
> allow for future changes, enhancements and growth.
>
>
>
> This is on the back of a very successful ERP release last year for the same
> customer, our first OFBiz implementation. Challenging, to say the least, but
> very successful in terms of laying the same platform for the back-end
> processes, with a specific focus on a very intense and customized CSR layer.
>
>
>
>
> Of interest to some, particularly given recent posts about community-driven
> OFBiz and various discussions about the lack of process and documentation I
> thought I'd share our  experience of using OFBiz during the last 2 years.
> First a little background on Salmon LLC that I think is relevant:
>
>
>
> Our background:
>
>
>
> *       we have released open-source framework software in the past
>
> *       we have developed many custom J2EE solutions
>
> *       we have adopted other ERP solutions prior to OFBiz (Compiere /
> Adempiere - before bailing because it was not really open-source)
>
> *       we have adopted other packaged solutions in other business areas
>
> *       we're a technical company, with business savvy
>
> *       we can figure stuff out
>
>
>
> OFBiz, the good:
>
>
>
> *       nice architecture, we were generally impressed with the service
> based approach
>
> *       the services work. For us, OFBiz is a starting point, the services
> are available and they work!
>
> *       the community support is amazing; the commitment of everyone
> monitoring this thread and providing responses is commendable
>
>
>
> OFBiz, the not so good:
>
>
>
> *       UI ootb: not the best. BUT, we understand the objective (framework)
> and we understand the ERP domain to realize that OFBiz is a starting point;
> and a pretty good one
>
> *       architecture: next level of concepts was harder to grasp, as you dig
> more into the code the more confusing it can get; the lack of good coding
> standards can make it very confusing as to what exactly is the best practice
> (particularly when looking at "older" code)
>
> *       the devil is in the details, and there are a lot of them; be
> prepared to make mistakes, having to figure stuff out for yourself, lots of
> trial and error
>
> *       community support: when it gets a little tricky it's much more
> difficult to explain the issue and get a good community response. Perfectly
> understandable but this is where the risk comes into play . we spent
> countless hours on some very tricky payment processing issues (credit, card,
> returns, refunds) and inventory processing
>
> *       what a pity that the documentation cannot encapsulate all the
> knowledge from the user-group. Yes, I know we can search through email
> postings. Yes, I know that the documentation is improving. But there are
> still problems in this area, perhaps I can share one specific example:
>
>
>
> One specific example:
>
>
>
> *       Product A is put with product B in order to offer product C
>
> *       Product A and B may (or may not) have inventory associated
>
> *       When assembled into C, this can also carry inventory
>
> *       When the item is returned, it may be put back into inventory as
> product C, OR may be disassembled into products A and B
>
> *       Fairly straight forward and not uncommon, and I'm sure that OFBiz
> can handle this but we couldn't find ANY document that would clearly explain
> product configuration and it's impact on other areas of the ERP solution
>
> *       I remember being amazed that a thorough product configuration guide
> was not available that would explain all the product attributes and a high
> level description of the impact throughout OFBiz. What's more important is
> that if you guess wrong then you can cause all sorts of problems
>
> *       BTW: since this was a while ago I did review the current
> documentation, the only item I saw that described setting up a product was
> the "Business Setup Guide (for users)", the content for Product Setup is
> pasted below. The best looking resource is I understand that there may be
> more documentation available that is more appropriate . BUT, if I'm new to
> OFBiz and cannot find something decent after a few minutes then I'll move on
> very quickly
>
>
>
> So, where are we now? Well, I think we can safely say that we are OFBiz
> adopters, it took much sweat and tears to get to where we are now but I
> consider my team to be well versed, near expert, with ERP and eCommerce
> implementations using OFBiz. I'm very comfortable offering this service to
> our clients, and very comfortable with our ability to deliver scalable ERP
> and eCommerce solutions.
>
>
>
> HOWEVER, our first implementation was very stressful. And in hindsight, very
> risky. Remember that ERP solutions are "bet your business" propositions . we
> cannot make mistakes. If we do, we jeopardize our business and the business
> of our clients. In our first implementation we are processing 5000 orders
> per day. For the first 3-4 weeks of go-live the background jobs were taking
> more than 24 hours to run (build orders from a recurring order list, process
> orders for fulfillment, manage incoming inventory, process credit card
> transactions, PLUS any new orders for that day). Saturdays and Sundays were
> used to make-up the time while we figured out solutions! As you can imagine
> we had a very stressful time working with our client, tuning our processes
> and working with our client to keep OFBiz as the ERP solution. I'm happy to
> report that everything is perfectly fine now, but this is not the way we
> like to do business.
>
>
>
> I consider my team to be extremely committed, technically excellent and
> business savvy. I wonder how small companies or small integrators adopt
> OFBiz without these resources?
>
>
>
> Conclusion:
>
>
>
> *       As I re-read my comments and gather my thoughts it basically boils
> down to documentation
>
> *       We did not have the luxury of being able to hire a certified "guru"
> to help out (we did have David Jones spend a week with us initially and used
> a couple of committers for specific tasks) but there is generally no
> "corporate" option to ensure success
>
> *       Best practices / coding techniques etc are exposed because of the
> open-source nature of OFBiz; it's probably better written than other
> proprietary software; this is not an essential issue
>
> *       So everything hinges on community support. Lots of it is required
> for early adopters and we see these postings every day. For folks that have
> moved into more complex areas (like we were 12 months ago), the community
> support is not enough-the issues are too complex
>
> *       As an open-source project, without formal corporate backing, the key
> is documentation, not just technical. And I suspect that we need more than
> Oracle and SAP because of the community nature of the project
>
>
>
> Nick Rosser
>
> Salmon LLC
>
>
>
>
>
>
> Product Setup
>
>
> Congratulations, you are finally to the point where you can start setting up
> products....
>
> To create a Product follow a process similar to those described for other
> things, like Categories.
>
> 1. Go to the main page of the Catalog Manager and click on the "Create
> New Product" link.
> 2. If you fill in an ID it will make sure that ID is valid, and if so
> it will use that one. If you specify no ID it will generate one.
> 3. Set an Internal Name that makes it easy for you to recognize the
> product. This name will be shown in the admin tools, but not to the
> customer.
> 4. Note that if you are using the UPS or USPS or other online rate
> estimation utilities then you must have values in the "Weight" and "Weight
> Uom Id" fields.
> 5. Submit the form to create the product.
>
> Add Content to the New Product
>
> 1. Click on the "Content" tab/button for the product you just created.
> Here you can setup text and images for your product.
> 2. You will see some forms at the top for administering managed content
> (ie from the Content Manager) with the product. For more advanced product
> related content needs use this, but for more common and simple needs, this
> can be more difficult to administer and slower at run time.
> 3. Near the bottom of the page is a section labeled "Override Simple
> Fields". Here you will typically want to specify a Product Name, Product
> Description, and Long Description. If you have images to associate with the
> product, you can specify their locations here, or upload them. Note that
> there are default locations for the images (can be quickly set by clicking
> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
> but of course you can put your images anywhere. These can be an absolute
> URL, or will be relative to the current server address, or the content URL
> prefix if one is specified in the url.properties file.
>
> Add Prices to the Product
>
> 1. Product pricing in OFBiz is very flexible. There are two main
> aspects to it: Prices and Price Rules. This is independent of promotions,
> which are applied after the price calculation is done.
> 2. For basic operation you should have at least one type of price setup
> for each product: the Default Price. This is the price that is used when no
> rules apply.
> 3. To add a Default Price go to the Prices tab for the Product, and use
> the form at the bottom of the page.
>
> 1. The Product Price Type Id should be "Default Price", the Currency
> Uom Id should be whatever currency the price is in, and the Product Store
> Group Id can be left as Not Applicable, unless you are setting up multiple
> groups of stores that have different pricing.
> 2. The From Date can be now or in the future, if you want the price to
> take effect in the future. The Thru Date is optional, but can be used to
> specify that this particular price expires at a certain date and time. Note
> that if there are multiple prices of the same type, etc that are active at
> once, it will use the one with the most recent From Date. This is useful
> when you want a temporary price to override the normal "Default" price of
> the product.
>
> 4. If you are using price rules or may do so in the future you may also
> want to enter information such as the List Price and the Average Cost which
> are often used in the price calculations.
> 5. Note that if a Minimum Price is set the price will never be less
> than that. So, even if the Default Price is to 2.00 and the Minimum Price is
> set to 3.00, then 3.00 will be used as the calculated price. The Maximum
> Price setting works the same way as the ceiling for the price.
>
> Make sure to put each product in a browse category, and in the All Products
> category so that it can be searched for, viewed, and purchased in your
> catalog.
>
> Expert Recommendation: These are the basics, but there is a lot more
> information about products that you can, or may need to, setup. We recommend
> reviewing the more detailed documentation or engaging the services of an
> experienced consulting to help you through this.
>
> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
> Thesaurus, Features for special functionality or parametric search,
> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
> Products, Virtual and Variant Products, Inventory/Facility/Location
> settings, and so on
>
> See the end-user documentation space for details on how to set these things
> up and what they mean. Also see this for more advanced options for Products,
> Categories, and so on.
>
>
>
>
>
>

[Florin Popa]

Hello all,

One question please: is it a common thing to have a Microsoft-IIS/6.0 in
front of Tomcat rather than Apache?

Is the site behavior pretty good with a larger set of products? Now I
can only see arround 140 products there.

thanks,
 Florin

> Great post Nick - and thanks for being one of those vendors who is giving back to the community - especially with this level of detail.  We enjoyed working with you and are stoked to see that thru your hard work and patience with the community you were able to achieve the level of internal adoption that many people strive for, but are unsuccessful.  The points you lay out here are great for everyone to hear - and I think really hit the nail on the head as far as the difficulty of less technical, and even less resourced companies face.
>
> That being said, I believe that there are commercial entities in the OFBiz world with the right processes, enough firepower (read resources) and expertise to ensure success in your project.  This may not have been the case when you first started, but I think that has changed.
>
> This does not mean that any one entity has to run the entire project - like say a JBoss or a MySQL - but there is really not much difference in paying for MySQL support services than paying the high tiered support offerings with OFBiz.  You just have to choose the right group and find the right individuals to help you along - and my personal opinion is that they are out there.
>
> Sorry to digress - now, back to your original point, there are a ton of things that the community can improve upon that you mentioned below.  Can you put these together up on the Wiki, much like we've discussed in other threads, so that we can begin to track our progress?  I'd like to see the documentation angle continue to get worked thru (technical and end-user) - possibly moving some of the documentation that I know that people are creating internally - out to a place where everyone can appreciate it without having to pay additional money.
>
> We need to come together to make this happen - and it will only get there if all of the corporate entities out there begin to or continue to support the community by donating a ton of time into documentation, mailing list responses, enhanced applications.   Thanks again Nick - this is great stuff.
>
> Cheers,
> Ruppert
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> On Mar 2, 2010, at 7:08 AM, Nick Rosser wrote:
>
>  
>> All,
>>
>>
>>
>> Just a note to let you know that we recently released an eCommerce site.
>> Check out www.purityproducts.com.
>>
>>
>>
>> Launched a couple of weeks ago, to very little fanfare, this is a complete
>> replacement of an existing site, with no upgrades to the UI or basic
>> eCommerce structure. A straight conversion to OFBiz as a platform change to
>> allow for future changes, enhancements and growth.
>>
>>
>>
>> This is on the back of a very successful ERP release last year for the same
>> customer, our first OFBiz implementation. Challenging, to say the least, but
>> very successful in terms of laying the same platform for the back-end
>> processes, with a specific focus on a very intense and customized CSR layer.
>>
>>
>>
>>
>> Of interest to some, particularly given recent posts about community-driven
>> OFBiz and various discussions about the lack of process and documentation I
>> thought I'd share our  experience of using OFBiz during the last 2 years.
>> First a little background on Salmon LLC that I think is relevant:
>>
>>
>>
>> Our background:
>>
>>
>>
>> *       we have released open-source framework software in the past
>>
>> *       we have developed many custom J2EE solutions
>>
>> *       we have adopted other ERP solutions prior to OFBiz (Compiere /
>> Adempiere - before bailing because it was not really open-source)
>>
>> *       we have adopted other packaged solutions in other business areas
>>
>> *       we're a technical company, with business savvy
>>
>> *       we can figure stuff out
>>
>>
>>
>> OFBiz, the good:
>>
>>
>>
>> *       nice architecture, we were generally impressed with the service
>> based approach
>>
>> *       the services work. For us, OFBiz is a starting point, the services
>> are available and they work!
>>
>> *       the community support is amazing; the commitment of everyone
>> monitoring this thread and providing responses is commendable
>>
>>
>>
>> OFBiz, the not so good:
>>
>>
>>
>> *       UI ootb: not the best. BUT, we understand the objective (framework)
>> and we understand the ERP domain to realize that OFBiz is a starting point;
>> and a pretty good one
>>
>> *       architecture: next level of concepts was harder to grasp, as you dig
>> more into the code the more confusing it can get; the lack of good coding
>> standards can make it very confusing as to what exactly is the best practice
>> (particularly when looking at "older" code)
>>
>> *       the devil is in the details, and there are a lot of them; be
>> prepared to make mistakes, having to figure stuff out for yourself, lots of
>> trial and error
>>
>> *       community support: when it gets a little tricky it's much more
>> difficult to explain the issue and get a good community response. Perfectly
>> understandable but this is where the risk comes into play . we spent
>> countless hours on some very tricky payment processing issues (credit, card,
>> returns, refunds) and inventory processing
>>
>> *       what a pity that the documentation cannot encapsulate all the
>> knowledge from the user-group. Yes, I know we can search through email
>> postings. Yes, I know that the documentation is improving. But there are
>> still problems in this area, perhaps I can share one specific example:
>>
>>
>>
>> One specific example:
>>
>>
>>
>> *       Product A is put with product B in order to offer product C
>>
>> *       Product A and B may (or may not) have inventory associated
>>
>> *       When assembled into C, this can also carry inventory
>>
>> *       When the item is returned, it may be put back into inventory as
>> product C, OR may be disassembled into products A and B
>>
>> *       Fairly straight forward and not uncommon, and I'm sure that OFBiz
>> can handle this but we couldn't find ANY document that would clearly explain
>> product configuration and it's impact on other areas of the ERP solution
>>
>> *       I remember being amazed that a thorough product configuration guide
>> was not available that would explain all the product attributes and a high
>> level description of the impact throughout OFBiz. What's more important is
>> that if you guess wrong then you can cause all sorts of problems
>>
>> *       BTW: since this was a while ago I did review the current
>> documentation, the only item I saw that described setting up a product was
>> the "Business Setup Guide (for users)", the content for Product Setup is
>> pasted below. The best looking resource is I understand that there may be
>> more documentation available that is more appropriate . BUT, if I'm new to
>> OFBiz and cannot find something decent after a few minutes then I'll move on
>> very quickly
>>
>>
>>
>> So, where are we now? Well, I think we can safely say that we are OFBiz
>> adopters, it took much sweat and tears to get to where we are now but I
>> consider my team to be well versed, near expert, with ERP and eCommerce
>> implementations using OFBiz. I'm very comfortable offering this service to
>> our clients, and very comfortable with our ability to deliver scalable ERP
>> and eCommerce solutions.
>>
>>
>>
>> HOWEVER, our first implementation was very stressful. And in hindsight, very
>> risky. Remember that ERP solutions are "bet your business" propositions . we
>> cannot make mistakes. If we do, we jeopardize our business and the business
>> of our clients. In our first implementation we are processing 5000 orders
>> per day. For the first 3-4 weeks of go-live the background jobs were taking
>> more than 24 hours to run (build orders from a recurring order list, process
>> orders for fulfillment, manage incoming inventory, process credit card
>> transactions, PLUS any new orders for that day). Saturdays and Sundays were
>> used to make-up the time while we figured out solutions! As you can imagine
>> we had a very stressful time working with our client, tuning our processes
>> and working with our client to keep OFBiz as the ERP solution. I'm happy to
>> report that everything is perfectly fine now, but this is not the way we
>> like to do business.
>>
>>
>>
>> I consider my team to be extremely committed, technically excellent and
>> business savvy. I wonder how small companies or small integrators adopt
>> OFBiz without these resources?
>>
>>
>>
>> Conclusion:
>>
>>
>>
>> *       As I re-read my comments and gather my thoughts it basically boils
>> down to documentation
>>
>> *       We did not have the luxury of being able to hire a certified "guru"
>> to help out (we did have David Jones spend a week with us initially and used
>> a couple of committers for specific tasks) but there is generally no
>> "corporate" option to ensure success
>>
>> *       Best practices / coding techniques etc are exposed because of the
>> open-source nature of OFBiz; it's probably better written than other
>> proprietary software; this is not an essential issue
>>
>> *       So everything hinges on community support. Lots of it is required
>> for early adopters and we see these postings every day. For folks that have
>> moved into more complex areas (like we were 12 months ago), the community
>> support is not enough-the issues are too complex
>>
>> *       As an open-source project, without formal corporate backing, the key
>> is documentation, not just technical. And I suspect that we need more than
>> Oracle and SAP because of the community nature of the project
>>
>>
>>
>> Nick Rosser
>>
>> Salmon LLC
>>
>>
>>
>>
>>
>>
>> Product Setup
>>
>>
>> Congratulations, you are finally to the point where you can start setting up
>> products....
>>
>> To create a Product follow a process similar to those described for other
>> things, like Categories.
>>
>> 1. Go to the main page of the Catalog Manager and click on the "Create
>> New Product" link.
>> 2. If you fill in an ID it will make sure that ID is valid, and if so
>> it will use that one. If you specify no ID it will generate one.
>> 3. Set an Internal Name that makes it easy for you to recognize the
>> product. This name will be shown in the admin tools, but not to the
>> customer.
>> 4. Note that if you are using the UPS or USPS or other online rate
>> estimation utilities then you must have values in the "Weight" and "Weight
>> Uom Id" fields.
>> 5. Submit the form to create the product.
>>
>> Add Content to the New Product
>>
>> 1. Click on the "Content" tab/button for the product you just created.
>> Here you can setup text and images for your product.
>> 2. You will see some forms at the top for administering managed content
>> (ie from the Content Manager) with the product. For more advanced product
>> related content needs use this, but for more common and simple needs, this
>> can be more difficult to administer and slower at run time.
>> 3. Near the bottom of the page is a section labeled "Override Simple
>> Fields". Here you will typically want to specify a Product Name, Product
>> Description, and Long Description. If you have images to associate with the
>> product, you can specify their locations here, or upload them. Note that
>> there are default locations for the images (can be quickly set by clicking
>> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
>> but of course you can put your images anywhere. These can be an absolute
>> URL, or will be relative to the current server address, or the content URL
>> prefix if one is specified in the url.properties file.
>>
>> Add Prices to the Product
>>
>> 1. Product pricing in OFBiz is very flexible. There are two main
>> aspects to it: Prices and Price Rules. This is independent of promotions,
>> which are applied after the price calculation is done.
>> 2. For basic operation you should have at least one type of price setup
>> for each product: the Default Price. This is the price that is used when no
>> rules apply.
>> 3. To add a Default Price go to the Prices tab for the Product, and use
>> the form at the bottom of the page.
>>
>> 1. The Product Price Type Id should be "Default Price", the Currency
>> Uom Id should be whatever currency the price is in, and the Product Store
>> Group Id can be left as Not Applicable, unless you are setting up multiple
>> groups of stores that have different pricing.
>> 2. The From Date can be now or in the future, if you want the price to
>> take effect in the future. The Thru Date is optional, but can be used to
>> specify that this particular price expires at a certain date and time. Note
>> that if there are multiple prices of the same type, etc that are active at
>> once, it will use the one with the most recent From Date. This is useful
>> when you want a temporary price to override the normal "Default" price of
>> the product.
>>
>> 4. If you are using price rules or may do so in the future you may also
>> want to enter information such as the List Price and the Average Cost which
>> are often used in the price calculations.
>> 5. Note that if a Minimum Price is set the price will never be less
>> than that. So, even if the Default Price is to 2.00 and the Minimum Price is
>> set to 3.00, then 3.00 will be used as the calculated price. The Maximum
>> Price setting works the same way as the ceiling for the price.
>>
>> Make sure to put each product in a browse category, and in the All Products
>> category so that it can be searched for, viewed, and purchased in your
>> catalog.
>>
>> Expert Recommendation: These are the basics, but there is a lot more
>> information about products that you can, or may need to, setup. We recommend
>> reviewing the more detailed documentation or engaging the services of an
>> experienced consulting to help you through this.
>>
>> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
>> Thesaurus, Features for special functionality or parametric search,
>> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
>> Products, Virtual and Variant Products, Inventory/Facility/Location
>> settings, and so on
>>
>> See the end-user documentation space for details on how to set these things
>> up and what they mean. Also see this for more advanced options for Products,
>> Categories, and so on.
>>
>>
>>
>>
>>
>>    
>
>  

[goranjan]

Nick,

Congratulations.

I have more questions:

* How many developers did it take?
* What was their skill set?
* How many months did it take to customize/develop your system?

Thanks very much,
Goran

P.S. A general question to all: how many OFBiz live deployments are there?
P.S. I did search the mailing list and didn't find an answer.

On Tue, Mar 2, 2010 at 9:08 AM, Nick Rosser <[hidden email]> wrote:

> All,
>
>
>
> Just a note to let you know that we recently released an eCommerce site.
> Check out www.purityproducts.com.
>
>
>
> Launched a couple of weeks ago, to very little fanfare, this is a complete
> replacement of an existing site, with no upgrades to the UI or basic
> eCommerce structure. A straight conversion to OFBiz as a platform change to
> allow for future changes, enhancements and growth.
>
>
>
> This is on the back of a very successful ERP release last year for the same
> customer, our first OFBiz implementation. Challenging, to say the least,
> but
> very successful in terms of laying the same platform for the back-end
> processes, with a specific focus on a very intense and customized CSR
> layer.
>
>
>
>
> Of interest to some, particularly given recent posts about community-driven
> OFBiz and various discussions about the lack of process and documentation I
> thought I'd share our  experience of using OFBiz during the last 2 years.
> First a little background on Salmon LLC that I think is relevant:
>
>
>
> Our background:
>
>
>
> *       we have released open-source framework software in the past
>
> *       we have developed many custom J2EE solutions
>
> *       we have adopted other ERP solutions prior to OFBiz (Compiere /
> Adempiere - before bailing because it was not really open-source)
>
> *       we have adopted other packaged solutions in other business areas
>
> *       we're a technical company, with business savvy
>
> *       we can figure stuff out
>
>
>
> OFBiz, the good:
>
>
>
> *       nice architecture, we were generally impressed with the service
> based approach
>
> *       the services work. For us, OFBiz is a starting point, the services
> are available and they work!
>
> *       the community support is amazing; the commitment of everyone
> monitoring this thread and providing responses is commendable
>
>
>
> OFBiz, the not so good:
>
>
>
> *       UI ootb: not the best. BUT, we understand the objective (framework)
> and we understand the ERP domain to realize that OFBiz is a starting point;
> and a pretty good one
>
> *       architecture: next level of concepts was harder to grasp, as you
> dig
> more into the code the more confusing it can get; the lack of good coding
> standards can make it very confusing as to what exactly is the best
> practice
> (particularly when looking at "older" code)
>
> *       the devil is in the details, and there are a lot of them; be
> prepared to make mistakes, having to figure stuff out for yourself, lots of
> trial and error
>
> *       community support: when it gets a little tricky it's much more
> difficult to explain the issue and get a good community response. Perfectly
> understandable but this is where the risk comes into play . we spent
> countless hours on some very tricky payment processing issues (credit,
> card,
> returns, refunds) and inventory processing
>
> *       what a pity that the documentation cannot encapsulate all the
> knowledge from the user-group. Yes, I know we can search through email
> postings. Yes, I know that the documentation is improving. But there are
> still problems in this area, perhaps I can share one specific example:
>
>
>
> One specific example:
>
>
>
> *       Product A is put with product B in order to offer product C
>
> *       Product A and B may (or may not) have inventory associated
>
> *       When assembled into C, this can also carry inventory
>
> *       When the item is returned, it may be put back into inventory as
> product C, OR may be disassembled into products A and B
>
> *       Fairly straight forward and not uncommon, and I'm sure that OFBiz
> can handle this but we couldn't find ANY document that would clearly
> explain
> product configuration and it's impact on other areas of the ERP solution
>
> *       I remember being amazed that a thorough product configuration guide
> was not available that would explain all the product attributes and a high
> level description of the impact throughout OFBiz. What's more important is
> that if you guess wrong then you can cause all sorts of problems
>
> *       BTW: since this was a while ago I did review the current
> documentation, the only item I saw that described setting up a product was
> the "Business Setup Guide (for users)", the content for Product Setup is
> pasted below. The best looking resource is I understand that there may be
> more documentation available that is more appropriate . BUT, if I'm new to
> OFBiz and cannot find something decent after a few minutes then I'll move
> on
> very quickly
>
>
>
> So, where are we now? Well, I think we can safely say that we are OFBiz
> adopters, it took much sweat and tears to get to where we are now but I
> consider my team to be well versed, near expert, with ERP and eCommerce
> implementations using OFBiz. I'm very comfortable offering this service to
> our clients, and very comfortable with our ability to deliver scalable ERP
> and eCommerce solutions.
>
>
>
> HOWEVER, our first implementation was very stressful. And in hindsight,
> very
> risky. Remember that ERP solutions are "bet your business" propositions .
> we
> cannot make mistakes. If we do, we jeopardize our business and the business
> of our clients. In our first implementation we are processing 5000 orders
> per day. For the first 3-4 weeks of go-live the background jobs were taking
> more than 24 hours to run (build orders from a recurring order list,
> process
> orders for fulfillment, manage incoming inventory, process credit card
> transactions, PLUS any new orders for that day). Saturdays and Sundays were
> used to make-up the time while we figured out solutions! As you can imagine
> we had a very stressful time working with our client, tuning our processes
> and working with our client to keep OFBiz as the ERP solution. I'm happy to
> report that everything is perfectly fine now, but this is not the way we
> like to do business.
>
>
>
> I consider my team to be extremely committed, technically excellent and
> business savvy. I wonder how small companies or small integrators adopt
> OFBiz without these resources?
>
>
>
> Conclusion:
>
>
>
> *       As I re-read my comments and gather my thoughts it basically boils
> down to documentation
>
> *       We did not have the luxury of being able to hire a certified "guru"
> to help out (we did have David Jones spend a week with us initially and
> used
> a couple of committers for specific tasks) but there is generally no
> "corporate" option to ensure success
>
> *       Best practices / coding techniques etc are exposed because of the
> open-source nature of OFBiz; it's probably better written than other
> proprietary software; this is not an essential issue
>
> *       So everything hinges on community support. Lots of it is required
> for early adopters and we see these postings every day. For folks that have
> moved into more complex areas (like we were 12 months ago), the community
> support is not enough-the issues are too complex
>
> *       As an open-source project, without formal corporate backing, the
> key
> is documentation, not just technical. And I suspect that we need more than
> Oracle and SAP because of the community nature of the project
>
>
>
> Nick Rosser
>
> Salmon LLC
>
>
>
>
>
>
> Product Setup
>
>
> Congratulations, you are finally to the point where you can start setting
> up
> products....
>
> To create a Product follow a process similar to those described for other
> things, like Categories.
>
> 1.      Go to the main page of the Catalog Manager and click on the "Create
> New Product" link.
> 2.      If you fill in an ID it will make sure that ID is valid, and if so
> it will use that one. If you specify no ID it will generate one.
> 3.      Set an Internal Name that makes it easy for you to recognize the
> product. This name will be shown in the admin tools, but not to the
> customer.
> 4.      Note that if you are using the UPS or USPS or other online rate
> estimation utilities then you must have values in the "Weight" and "Weight
> Uom Id" fields.
> 5.      Submit the form to create the product.
>
> Add Content to the New Product
>
> 1.      Click on the "Content" tab/button for the product you just created.
> Here you can setup text and images for your product.
> 2.      You will see some forms at the top for administering managed
> content
> (ie from the Content Manager) with the product. For more advanced product
> related content needs use this, but for more common and simple needs, this
> can be more difficult to administer and slower at run time.
> 3.      Near the bottom of the page is a section labeled "Override Simple
> Fields". Here you will typically want to specify a Product Name, Product
> Description, and Long Description. If you have images to associate with the
> product, you can specify their locations here, or upload them. Note that
> there are default locations for the images (can be quickly set by clicking
> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
> but of course you can put your images anywhere. These can be an absolute
> URL, or will be relative to the current server address, or the content URL
> prefix if one is specified in the url.properties file.
>
> Add Prices to the Product
>
> 1.      Product pricing in OFBiz is very flexible. There are two main
> aspects to it: Prices and Price Rules. This is independent of promotions,
> which are applied after the price calculation is done.
> 2.      For basic operation you should have at least one type of price
> setup
> for each product: the Default Price. This is the price that is used when no
> rules apply.
> 3.      To add a Default Price go to the Prices tab for the Product, and
> use
> the form at the bottom of the page.
>
> 1.      The Product Price Type Id should be "Default Price", the Currency
> Uom Id should be whatever currency the price is in, and the Product Store
> Group Id can be left as Not Applicable, unless you are setting up multiple
> groups of stores that have different pricing.
> 2.      The From Date can be now or in the future, if you want the price to
> take effect in the future. The Thru Date is optional, but can be used to
> specify that this particular price expires at a certain date and time. Note
> that if there are multiple prices of the same type, etc that are active at
> once, it will use the one with the most recent From Date. This is useful
> when you want a temporary price to override the normal "Default" price of
> the product.
>
> 4.      If you are using price rules or may do so in the future you may
> also
> want to enter information such as the List Price and the Average Cost which
> are often used in the price calculations.
> 5.      Note that if a Minimum Price is set the price will never be less
> than that. So, even if the Default Price is to 2.00 and the Minimum Price
> is
> set to 3.00, then 3.00 will be used as the calculated price. The Maximum
> Price setting works the same way as the ceiling for the price.
>
> Make sure to put each product in a browse category, and in the All Products
> category so that it can be searched for, viewed, and purchased in your
> catalog.
>
> Expert Recommendation: These are the basics, but there is a lot more
> information about products that you can, or may need to, setup. We
> recommend
> reviewing the more detailed documentation or engaging the services of an
> experienced consulting to help you through this.
>
> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
> Thesaurus, Features for special functionality or parametric search,
> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
> Products, Virtual and Variant Products, Inventory/Facility/Location
> settings, and so on
>
> See the end-user documentation space for details on how to set these things
> up and what they mean. Also see this for more advanced options for
> Products,
> Categories, and so on.
>
>
>
>
>
>

[Adrian Crum]

Nick,

Congratulations on your successful deployment! And thank you for the
comments.

-Adrian

Nick Rosser wrote:

> All,
>
>  
>
> Just a note to let you know that we recently released an eCommerce site.
> Check out www.purityproducts.com.
>
>  
>
> Launched a couple of weeks ago, to very little fanfare, this is a complete
> replacement of an existing site, with no upgrades to the UI or basic
> eCommerce structure. A straight conversion to OFBiz as a platform change to
> allow for future changes, enhancements and growth.
>
>  
>
> This is on the back of a very successful ERP release last year for the same
> customer, our first OFBiz implementation. Challenging, to say the least, but
> very successful in terms of laying the same platform for the back-end
> processes, with a specific focus on a very intense and customized CSR layer.
>
>
>  
>
> Of interest to some, particularly given recent posts about community-driven
> OFBiz and various discussions about the lack of process and documentation I
> thought I'd share our  experience of using OFBiz during the last 2 years.
> First a little background on Salmon LLC that I think is relevant:
>
>  
>
> Our background:
>
>  
>
> *       we have released open-source framework software in the past
>
> *       we have developed many custom J2EE solutions
>
> *       we have adopted other ERP solutions prior to OFBiz (Compiere /
> Adempiere - before bailing because it was not really open-source)
>
> *       we have adopted other packaged solutions in other business areas
>
> *       we're a technical company, with business savvy
>
> *       we can figure stuff out
>
>  
>
> OFBiz, the good:
>
>  
>
> *       nice architecture, we were generally impressed with the service
> based approach
>
> *       the services work. For us, OFBiz is a starting point, the services
> are available and they work!
>
> *       the community support is amazing; the commitment of everyone
> monitoring this thread and providing responses is commendable
>
>  
>
> OFBiz, the not so good:
>
>  
>
> *       UI ootb: not the best. BUT, we understand the objective (framework)
> and we understand the ERP domain to realize that OFBiz is a starting point;
> and a pretty good one
>
> *       architecture: next level of concepts was harder to grasp, as you dig
> more into the code the more confusing it can get; the lack of good coding
> standards can make it very confusing as to what exactly is the best practice
> (particularly when looking at "older" code)
>
> *       the devil is in the details, and there are a lot of them; be
> prepared to make mistakes, having to figure stuff out for yourself, lots of
> trial and error
>
> *       community support: when it gets a little tricky it's much more
> difficult to explain the issue and get a good community response. Perfectly
> understandable but this is where the risk comes into play . we spent
> countless hours on some very tricky payment processing issues (credit, card,
> returns, refunds) and inventory processing
>
> *       what a pity that the documentation cannot encapsulate all the
> knowledge from the user-group. Yes, I know we can search through email
> postings. Yes, I know that the documentation is improving. But there are
> still problems in this area, perhaps I can share one specific example:
>
>  
>
> One specific example:
>
>  
>
> *       Product A is put with product B in order to offer product C
>
> *       Product A and B may (or may not) have inventory associated
>
> *       When assembled into C, this can also carry inventory
>
> *       When the item is returned, it may be put back into inventory as
> product C, OR may be disassembled into products A and B
>
> *       Fairly straight forward and not uncommon, and I'm sure that OFBiz
> can handle this but we couldn't find ANY document that would clearly explain
> product configuration and it's impact on other areas of the ERP solution
>
> *       I remember being amazed that a thorough product configuration guide
> was not available that would explain all the product attributes and a high
> level description of the impact throughout OFBiz. What's more important is
> that if you guess wrong then you can cause all sorts of problems
>
> *       BTW: since this was a while ago I did review the current
> documentation, the only item I saw that described setting up a product was
> the "Business Setup Guide (for users)", the content for Product Setup is
> pasted below. The best looking resource is I understand that there may be
> more documentation available that is more appropriate . BUT, if I'm new to
> OFBiz and cannot find something decent after a few minutes then I'll move on
> very quickly
>
>  
>
> So, where are we now? Well, I think we can safely say that we are OFBiz
> adopters, it took much sweat and tears to get to where we are now but I
> consider my team to be well versed, near expert, with ERP and eCommerce
> implementations using OFBiz. I'm very comfortable offering this service to
> our clients, and very comfortable with our ability to deliver scalable ERP
> and eCommerce solutions.
>
>  
>
> HOWEVER, our first implementation was very stressful. And in hindsight, very
> risky. Remember that ERP solutions are "bet your business" propositions . we
> cannot make mistakes. If we do, we jeopardize our business and the business
> of our clients. In our first implementation we are processing 5000 orders
> per day. For the first 3-4 weeks of go-live the background jobs were taking
> more than 24 hours to run (build orders from a recurring order list, process
> orders for fulfillment, manage incoming inventory, process credit card
> transactions, PLUS any new orders for that day). Saturdays and Sundays were
> used to make-up the time while we figured out solutions! As you can imagine
> we had a very stressful time working with our client, tuning our processes
> and working with our client to keep OFBiz as the ERP solution. I'm happy to
> report that everything is perfectly fine now, but this is not the way we
> like to do business.
>
>  
>
> I consider my team to be extremely committed, technically excellent and
> business savvy. I wonder how small companies or small integrators adopt
> OFBiz without these resources?
>
>  
>
> Conclusion:
>
>  
>
> *       As I re-read my comments and gather my thoughts it basically boils
> down to documentation
>
> *       We did not have the luxury of being able to hire a certified "guru"
> to help out (we did have David Jones spend a week with us initially and used
> a couple of committers for specific tasks) but there is generally no
> "corporate" option to ensure success
>
> *       Best practices / coding techniques etc are exposed because of the
> open-source nature of OFBiz; it's probably better written than other
> proprietary software; this is not an essential issue
>
> *       So everything hinges on community support. Lots of it is required
> for early adopters and we see these postings every day. For folks that have
> moved into more complex areas (like we were 12 months ago), the community
> support is not enough-the issues are too complex
>
> *       As an open-source project, without formal corporate backing, the key
> is documentation, not just technical. And I suspect that we need more than
> Oracle and SAP because of the community nature of the project
>
>  
>
> Nick Rosser
>
> Salmon LLC
>
>  
>
>  
>
>
> Product Setup
>
>
> Congratulations, you are finally to the point where you can start setting up
> products....
>
> To create a Product follow a process similar to those described for other
> things, like Categories.
>
> 1. Go to the main page of the Catalog Manager and click on the "Create
> New Product" link.
> 2. If you fill in an ID it will make sure that ID is valid, and if so
> it will use that one. If you specify no ID it will generate one.
> 3. Set an Internal Name that makes it easy for you to recognize the
> product. This name will be shown in the admin tools, but not to the
> customer.
> 4. Note that if you are using the UPS or USPS or other online rate
> estimation utilities then you must have values in the "Weight" and "Weight
> Uom Id" fields.
> 5. Submit the form to create the product.
>
> Add Content to the New Product
>
> 1. Click on the "Content" tab/button for the product you just created.
> Here you can setup text and images for your product.
> 2. You will see some forms at the top for administering managed content
> (ie from the Content Manager) with the product. For more advanced product
> related content needs use this, but for more common and simple needs, this
> can be more difficult to administer and slower at run time.
> 3. Near the bottom of the page is a section labeled "Override Simple
> Fields". Here you will typically want to specify a Product Name, Product
> Description, and Long Description. If you have images to associate with the
> product, you can specify their locations here, or upload them. Note that
> there are default locations for the images (can be quickly set by clicking
> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
> but of course you can put your images anywhere. These can be an absolute
> URL, or will be relative to the current server address, or the content URL
> prefix if one is specified in the url.properties file.
>
> Add Prices to the Product
>
> 1. Product pricing in OFBiz is very flexible. There are two main
> aspects to it: Prices and Price Rules. This is independent of promotions,
> which are applied after the price calculation is done.
> 2. For basic operation you should have at least one type of price setup
> for each product: the Default Price. This is the price that is used when no
> rules apply.
> 3. To add a Default Price go to the Prices tab for the Product, and use
> the form at the bottom of the page.
>
> 1. The Product Price Type Id should be "Default Price", the Currency
> Uom Id should be whatever currency the price is in, and the Product Store
> Group Id can be left as Not Applicable, unless you are setting up multiple
> groups of stores that have different pricing.
> 2. The From Date can be now or in the future, if you want the price to
> take effect in the future. The Thru Date is optional, but can be used to
> specify that this particular price expires at a certain date and time. Note
> that if there are multiple prices of the same type, etc that are active at
> once, it will use the one with the most recent From Date. This is useful
> when you want a temporary price to override the normal "Default" price of
> the product.
>
> 4. If you are using price rules or may do so in the future you may also
> want to enter information such as the List Price and the Average Cost which
> are often used in the price calculations.
> 5. Note that if a Minimum Price is set the price will never be less
> than that. So, even if the Default Price is to 2.00 and the Minimum Price is
> set to 3.00, then 3.00 will be used as the calculated price. The Maximum
> Price setting works the same way as the ceiling for the price.
>
> Make sure to put each product in a browse category, and in the All Products
> category so that it can be searched for, viewed, and purchased in your
> catalog.
>
> Expert Recommendation: These are the basics, but there is a lot more
> information about products that you can, or may need to, setup. We recommend
> reviewing the more detailed documentation or engaging the services of an
> experienced consulting to help you through this.
>
> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
> Thesaurus, Features for special functionality or parametric search,
> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
> Products, Virtual and Variant Products, Inventory/Facility/Location
> settings, and so on
>
> See the end-user documentation space for details on how to set these things
> up and what they mean. Also see this for more advanced options for Products,
> Categories, and so on.
>
>  
>
>  
>
>

[Ruth Hoffman-2]

Hi Nick:
First, thanks for taking the time to post this. It is very evident that
a lot of thought went into this and I found it a very good read.

Second, congratulations on the site! Very nice.

Third, I agree 100% with your assessment concerning documentation,
especially beginner documentation. Hopefully, there will be more efforts
along this line as more adopters join the fold.

Finally, I'd be interested in knowing more about specific requirements
for beginner documentation and/or training. If you have time, could you
post some more information about this? Or contact me directly at
[hidden email].

Regards,
Ruth
----------------------------------------------------
Find me on the web at http://www.myofbiz.com or Google keyword "myofbiz"
[hidden email]

Nick Rosser wrote:

> All,
>
>  
>
> Just a note to let you know that we recently released an eCommerce site.
> Check out www.purityproducts.com.
>
>  
>
> Launched a couple of weeks ago, to very little fanfare, this is a complete
> replacement of an existing site, with no upgrades to the UI or basic
> eCommerce structure. A straight conversion to OFBiz as a platform change to
> allow for future changes, enhancements and growth.
>
>  
>
> This is on the back of a very successful ERP release last year for the same
> customer, our first OFBiz implementation. Challenging, to say the least, but
> very successful in terms of laying the same platform for the back-end
> processes, with a specific focus on a very intense and customized CSR layer.
>
>
>  
>
> Of interest to some, particularly given recent posts about community-driven
> OFBiz and various discussions about the lack of process and documentation I
> thought I'd share our  experience of using OFBiz during the last 2 years.
> First a little background on Salmon LLC that I think is relevant:
>
>  
>
> Our background:
>
>  
>
> *       we have released open-source framework software in the past
>
> *       we have developed many custom J2EE solutions
>
> *       we have adopted other ERP solutions prior to OFBiz (Compiere /
> Adempiere - before bailing because it was not really open-source)
>
> *       we have adopted other packaged solutions in other business areas
>
> *       we're a technical company, with business savvy
>
> *       we can figure stuff out
>
>  
>
> OFBiz, the good:
>
>  
>
> *       nice architecture, we were generally impressed with the service
> based approach
>
> *       the services work. For us, OFBiz is a starting point, the services
> are available and they work!
>
> *       the community support is amazing; the commitment of everyone
> monitoring this thread and providing responses is commendable
>
>  
>
> OFBiz, the not so good:
>
>  
>
> *       UI ootb: not the best. BUT, we understand the objective (framework)
> and we understand the ERP domain to realize that OFBiz is a starting point;
> and a pretty good one
>
> *       architecture: next level of concepts was harder to grasp, as you dig
> more into the code the more confusing it can get; the lack of good coding
> standards can make it very confusing as to what exactly is the best practice
> (particularly when looking at "older" code)
>
> *       the devil is in the details, and there are a lot of them; be
> prepared to make mistakes, having to figure stuff out for yourself, lots of
> trial and error
>
> *       community support: when it gets a little tricky it's much more
> difficult to explain the issue and get a good community response. Perfectly
> understandable but this is where the risk comes into play . we spent
> countless hours on some very tricky payment processing issues (credit, card,
> returns, refunds) and inventory processing
>
> *       what a pity that the documentation cannot encapsulate all the
> knowledge from the user-group. Yes, I know we can search through email
> postings. Yes, I know that the documentation is improving. But there are
> still problems in this area, perhaps I can share one specific example:
>
>  
>
> One specific example:
>
>  
>
> *       Product A is put with product B in order to offer product C
>
> *       Product A and B may (or may not) have inventory associated
>
> *       When assembled into C, this can also carry inventory
>
> *       When the item is returned, it may be put back into inventory as
> product C, OR may be disassembled into products A and B
>
> *       Fairly straight forward and not uncommon, and I'm sure that OFBiz
> can handle this but we couldn't find ANY document that would clearly explain
> product configuration and it's impact on other areas of the ERP solution
>
> *       I remember being amazed that a thorough product configuration guide
> was not available that would explain all the product attributes and a high
> level description of the impact throughout OFBiz. What's more important is
> that if you guess wrong then you can cause all sorts of problems
>
> *       BTW: since this was a while ago I did review the current
> documentation, the only item I saw that described setting up a product was
> the "Business Setup Guide (for users)", the content for Product Setup is
> pasted below. The best looking resource is I understand that there may be
> more documentation available that is more appropriate . BUT, if I'm new to
> OFBiz and cannot find something decent after a few minutes then I'll move on
> very quickly
>
>  
>
> So, where are we now? Well, I think we can safely say that we are OFBiz
> adopters, it took much sweat and tears to get to where we are now but I
> consider my team to be well versed, near expert, with ERP and eCommerce
> implementations using OFBiz. I'm very comfortable offering this service to
> our clients, and very comfortable with our ability to deliver scalable ERP
> and eCommerce solutions.
>
>  
>
> HOWEVER, our first implementation was very stressful. And in hindsight, very
> risky. Remember that ERP solutions are "bet your business" propositions . we
> cannot make mistakes. If we do, we jeopardize our business and the business
> of our clients. In our first implementation we are processing 5000 orders
> per day. For the first 3-4 weeks of go-live the background jobs were taking
> more than 24 hours to run (build orders from a recurring order list, process
> orders for fulfillment, manage incoming inventory, process credit card
> transactions, PLUS any new orders for that day). Saturdays and Sundays were
> used to make-up the time while we figured out solutions! As you can imagine
> we had a very stressful time working with our client, tuning our processes
> and working with our client to keep OFBiz as the ERP solution. I'm happy to
> report that everything is perfectly fine now, but this is not the way we
> like to do business.
>
>  
>
> I consider my team to be extremely committed, technically excellent and
> business savvy. I wonder how small companies or small integrators adopt
> OFBiz without these resources?
>
>  
>
> Conclusion:
>
>  
>
> *       As I re-read my comments and gather my thoughts it basically boils
> down to documentation
>
> *       We did not have the luxury of being able to hire a certified "guru"
> to help out (we did have David Jones spend a week with us initially and used
> a couple of committers for specific tasks) but there is generally no
> "corporate" option to ensure success
>
> *       Best practices / coding techniques etc are exposed because of the
> open-source nature of OFBiz; it's probably better written than other
> proprietary software; this is not an essential issue
>
> *       So everything hinges on community support. Lots of it is required
> for early adopters and we see these postings every day. For folks that have
> moved into more complex areas (like we were 12 months ago), the community
> support is not enough-the issues are too complex
>
> *       As an open-source project, without formal corporate backing, the key
> is documentation, not just technical. And I suspect that we need more than
> Oracle and SAP because of the community nature of the project
>
>  
>
> Nick Rosser
>
> Salmon LLC
>
>  
>
>  
>
>
> Product Setup
>
>
> Congratulations, you are finally to the point where you can start setting up
> products....
>
> To create a Product follow a process similar to those described for other
> things, like Categories.
>
> 1. Go to the main page of the Catalog Manager and click on the "Create
> New Product" link.
> 2. If you fill in an ID it will make sure that ID is valid, and if so
> it will use that one. If you specify no ID it will generate one.
> 3. Set an Internal Name that makes it easy for you to recognize the
> product. This name will be shown in the admin tools, but not to the
> customer.
> 4. Note that if you are using the UPS or USPS or other online rate
> estimation utilities then you must have values in the "Weight" and "Weight
> Uom Id" fields.
> 5. Submit the form to create the product.
>
> Add Content to the New Product
>
> 1. Click on the "Content" tab/button for the product you just created.
> Here you can setup text and images for your product.
> 2. You will see some forms at the top for administering managed content
> (ie from the Content Manager) with the product. For more advanced product
> related content needs use this, but for more common and simple needs, this
> can be more difficult to administer and slower at run time.
> 3. Near the bottom of the page is a section labeled "Override Simple
> Fields". Here you will typically want to specify a Product Name, Product
> Description, and Long Description. If you have images to associate with the
> product, you can specify their locations here, or upload them. Note that
> there are default locations for the images (can be quickly set by clicking
> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
> but of course you can put your images anywhere. These can be an absolute
> URL, or will be relative to the current server address, or the content URL
> prefix if one is specified in the url.properties file.
>
> Add Prices to the Product
>
> 1. Product pricing in OFBiz is very flexible. There are two main
> aspects to it: Prices and Price Rules. This is independent of promotions,
> which are applied after the price calculation is done.
> 2. For basic operation you should have at least one type of price setup
> for each product: the Default Price. This is the price that is used when no
> rules apply.
> 3. To add a Default Price go to the Prices tab for the Product, and use
> the form at the bottom of the page.
>
> 1. The Product Price Type Id should be "Default Price", the Currency
> Uom Id should be whatever currency the price is in, and the Product Store
> Group Id can be left as Not Applicable, unless you are setting up multiple
> groups of stores that have different pricing.
> 2. The From Date can be now or in the future, if you want the price to
> take effect in the future. The Thru Date is optional, but can be used to
> specify that this particular price expires at a certain date and time. Note
> that if there are multiple prices of the same type, etc that are active at
> once, it will use the one with the most recent From Date. This is useful
> when you want a temporary price to override the normal "Default" price of
> the product.
>
> 4. If you are using price rules or may do so in the future you may also
> want to enter information such as the List Price and the Average Cost which
> are often used in the price calculations.
> 5. Note that if a Minimum Price is set the price will never be less
> than that. So, even if the Default Price is to 2.00 and the Minimum Price is
> set to 3.00, then 3.00 will be used as the calculated price. The Maximum
> Price setting works the same way as the ceiling for the price.
>
> Make sure to put each product in a browse category, and in the All Products
> category so that it can be searched for, viewed, and purchased in your
> catalog.
>
> Expert Recommendation: These are the basics, but there is a lot more
> information about products that you can, or may need to, setup. We recommend
> reviewing the more detailed documentation or engaging the services of an
> experienced consulting to help you through this.
>
> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
> Thesaurus, Features for special functionality or parametric search,
> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
> Products, Virtual and Variant Products, Inventory/Facility/Location
> settings, and so on
>
> See the end-user documentation space for details on how to set these things
> up and what they mean. Also see this for more advanced options for Products,
> Categories, and so on.
>
>  
>
>  
>
>
>  

[Nick Rosser]

I'll group together a number of q&a in one general response:

is it a common thing to have a Microsoft-IIS/6.0 in
front of Tomcat rather than Apache?
NICK: dunno, this was dictated by the client

Is the site behavior pretty good with a larger set of products? Now I
can only see arround 140 products there.
NICK: the back-end ERP is much more active, processing 5000 orders per day;
140 products on the web site reflects a subset of their product line. ERP is
performing well, with ~100 customer service users.

How many developers did it take?
NICK: 3 for the ERP system (lots of customization; close to 1 year by the
time we were fully live); 1-2 for the eCommerce site (approx 6 months)

What was their skill set?
NICK: Senior J2EE, experienced in the delivery of web based business
software

I'd be interested in knowing more about specific requirements for beginner
documentation and/or training. If you have time, could you post some more
information about this?
NICK: tough question. I think we generally struggled with implementation
concepts that we knew would be challenging. How do you properly extend
existing entities? What's the best practice for services etc? And the
classic struggle of not fully understanding what OFBiz does ootb and coding
around it, only to find out that a simple tweak / configuration would have
worked (or was close). This may simply be a nature of the sheer size of
OFBiz and generally not appreciating all the features, we are much better at
looking for stuff before we code it. This gets back to a lack of knowledge
available, particularly outside of simple issues, that we would have
appreciated greatly during our implementation.

Nick


-----Original Message-----
From: Florin Popa [mailto:[hidden email]]
Sent: Tuesday, March 02, 2010 10:38 AM
To: [hidden email]
Subject: Re: Salmon LLC: OFBiz eCommerce Site Goes Live

Hello all,

One question please: is it a common thing to have a Microsoft-IIS/6.0 in
front of Tomcat rather than Apache?

Is the site behavior pretty good with a larger set of products? Now I
can only see arround 140 products there.

thanks,
 Florin
> Great post Nick - and thanks for being one of those vendors who is giving
back to the community - especially with this level of detail.  We enjoyed
working with you and are stoked to see that thru your hard work and patience
with the community you were able to achieve the level of internal adoption
that many people strive for, but are unsuccessful.  The points you lay out
here are great for everyone to hear - and I think really hit the nail on the
head as far as the difficulty of less technical, and even less resourced
companies face.
>
> That being said, I believe that there are commercial entities in the OFBiz
world with the right processes, enough firepower (read resources) and
expertise to ensure success in your project.  This may not have been the
case when you first started, but I think that has changed.
>
> This does not mean that any one entity has to run the entire project -
like say a JBoss or a MySQL - but there is really not much difference in
paying for MySQL support services than paying the high tiered support
offerings with OFBiz.  You just have to choose the right group and find the
right individuals to help you along - and my personal opinion is that they
are out there.
>
> Sorry to digress - now, back to your original point, there are a ton of
things that the community can improve upon that you mentioned below.  Can
you put these together up on the Wiki, much like we've discussed in other
threads, so that we can begin to track our progress?  I'd like to see the
documentation angle continue to get worked thru (technical and end-user) -
possibly moving some of the documentation that I know that people are
creating internally - out to a place where everyone can appreciate it
without having to pay additional money.
>
> We need to come together to make this happen - and it will only get there
if all of the corporate entities out there begin to or continue to support
the community by donating a ton of time into documentation, mailing list
responses, enhanced applications.   Thanks again Nick - this is great stuff.

>
> Cheers,
> Ruppert
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> On Mar 2, 2010, at 7:08 AM, Nick Rosser wrote:
>
>  
>> All,
>>
>>
>>
>> Just a note to let you know that we recently released an eCommerce site.
>> Check out www.purityproducts.com.
>>
>>
>>
>> Launched a couple of weeks ago, to very little fanfare, this is a

complete
>> replacement of an existing site, with no upgrades to the UI or basic
>> eCommerce structure. A straight conversion to OFBiz as a platform change
to
>> allow for future changes, enhancements and growth.
>>
>>
>>
>> This is on the back of a very successful ERP release last year for the
same
>> customer, our first OFBiz implementation. Challenging, to say the least,
but
>> very successful in terms of laying the same platform for the back-end
>> processes, with a specific focus on a very intense and customized CSR
layer.
>>
>>
>>
>>
>> Of interest to some, particularly given recent posts about
community-driven
>> OFBiz and various discussions about the lack of process and documentation
I

>> thought I'd share our  experience of using OFBiz during the last 2 years.
>> First a little background on Salmon LLC that I think is relevant:
>>
>>
>>
>> Our background:
>>
>>
>>
>> *       we have released open-source framework software in the past
>>
>> *       we have developed many custom J2EE solutions
>>
>> *       we have adopted other ERP solutions prior to OFBiz (Compiere /
>> Adempiere - before bailing because it was not really open-source)
>>
>> *       we have adopted other packaged solutions in other business areas
>>
>> *       we're a technical company, with business savvy
>>
>> *       we can figure stuff out
>>
>>
>>
>> OFBiz, the good:
>>
>>
>>
>> *       nice architecture, we were generally impressed with the service
>> based approach
>>
>> *       the services work. For us, OFBiz is a starting point, the

services

>> are available and they work!
>>
>> *       the community support is amazing; the commitment of everyone
>> monitoring this thread and providing responses is commendable
>>
>>
>>
>> OFBiz, the not so good:
>>
>>
>>
>> *       UI ootb: not the best. BUT, we understand the objective

(framework)
>> and we understand the ERP domain to realize that OFBiz is a starting
point;
>> and a pretty good one
>>
>> *       architecture: next level of concepts was harder to grasp, as you
dig
>> more into the code the more confusing it can get; the lack of good coding
>> standards can make it very confusing as to what exactly is the best
practice
>> (particularly when looking at "older" code)
>>
>> *       the devil is in the details, and there are a lot of them; be
>> prepared to make mistakes, having to figure stuff out for yourself, lots
of
>> trial and error
>>
>> *       community support: when it gets a little tricky it's much more
>> difficult to explain the issue and get a good community response.
Perfectly
>> understandable but this is where the risk comes into play . we spent
>> countless hours on some very tricky payment processing issues (credit,
card,

>> returns, refunds) and inventory processing
>>
>> *       what a pity that the documentation cannot encapsulate all the
>> knowledge from the user-group. Yes, I know we can search through email
>> postings. Yes, I know that the documentation is improving. But there are
>> still problems in this area, perhaps I can share one specific example:
>>
>>
>>
>> One specific example:
>>
>>
>>
>> *       Product A is put with product B in order to offer product C
>>
>> *       Product A and B may (or may not) have inventory associated
>>
>> *       When assembled into C, this can also carry inventory
>>
>> *       When the item is returned, it may be put back into inventory as
>> product C, OR may be disassembled into products A and B
>>
>> *       Fairly straight forward and not uncommon, and I'm sure that OFBiz
>> can handle this but we couldn't find ANY document that would clearly

explain
>> product configuration and it's impact on other areas of the ERP solution
>>
>> *       I remember being amazed that a thorough product configuration
guide
>> was not available that would explain all the product attributes and a
high
>> level description of the impact throughout OFBiz. What's more important
is
>> that if you guess wrong then you can cause all sorts of problems
>>
>> *       BTW: since this was a while ago I did review the current
>> documentation, the only item I saw that described setting up a product
was
>> the "Business Setup Guide (for users)", the content for Product Setup is
>> pasted below. The best looking resource is I understand that there may be
>> more documentation available that is more appropriate . BUT, if I'm new
to
>> OFBiz and cannot find something decent after a few minutes then I'll move
on
>> very quickly
>>
>>
>>
>> So, where are we now? Well, I think we can safely say that we are OFBiz
>> adopters, it took much sweat and tears to get to where we are now but I
>> consider my team to be well versed, near expert, with ERP and eCommerce
>> implementations using OFBiz. I'm very comfortable offering this service
to
>> our clients, and very comfortable with our ability to deliver scalable
ERP
>> and eCommerce solutions.
>>
>>
>>
>> HOWEVER, our first implementation was very stressful. And in hindsight,
very
>> risky. Remember that ERP solutions are "bet your business" propositions .
we
>> cannot make mistakes. If we do, we jeopardize our business and the
business
>> of our clients. In our first implementation we are processing 5000 orders
>> per day. For the first 3-4 weeks of go-live the background jobs were
taking
>> more than 24 hours to run (build orders from a recurring order list,
process
>> orders for fulfillment, manage incoming inventory, process credit card
>> transactions, PLUS any new orders for that day). Saturdays and Sundays
were
>> used to make-up the time while we figured out solutions! As you can
imagine
>> we had a very stressful time working with our client, tuning our
processes
>> and working with our client to keep OFBiz as the ERP solution. I'm happy
to

>> report that everything is perfectly fine now, but this is not the way we
>> like to do business.
>>
>>
>>
>> I consider my team to be extremely committed, technically excellent and
>> business savvy. I wonder how small companies or small integrators adopt
>> OFBiz without these resources?
>>
>>
>>
>> Conclusion:
>>
>>
>>
>> *       As I re-read my comments and gather my thoughts it basically

boils
>> down to documentation
>>
>> *       We did not have the luxury of being able to hire a certified
"guru"
>> to help out (we did have David Jones spend a week with us initially and
used
>> a couple of committers for specific tasks) but there is generally no
>> "corporate" option to ensure success
>>
>> *       Best practices / coding techniques etc are exposed because of the
>> open-source nature of OFBiz; it's probably better written than other
>> proprietary software; this is not an essential issue
>>
>> *       So everything hinges on community support. Lots of it is required
>> for early adopters and we see these postings every day. For folks that
have
>> moved into more complex areas (like we were 12 months ago), the community
>> support is not enough-the issues are too complex
>>
>> *       As an open-source project, without formal corporate backing, the
key
>> is documentation, not just technical. And I suspect that we need more
than

>> Oracle and SAP because of the community nature of the project
>>
>>
>>
>> Nick Rosser
>>
>> Salmon LLC
>>
>>
>>
>>
>>
>>
>> Product Setup
>>
>>
>> Congratulations, you are finally to the point where you can start setting

up

>> products....
>>
>> To create a Product follow a process similar to those described for other
>> things, like Categories.
>>
>> 1. Go to the main page of the Catalog Manager and click on the "Create
>> New Product" link.
>> 2. If you fill in an ID it will make sure that ID is valid, and if so
>> it will use that one. If you specify no ID it will generate one.
>> 3. Set an Internal Name that makes it easy for you to recognize the
>> product. This name will be shown in the admin tools, but not to the
>> customer.
>> 4. Note that if you are using the UPS or USPS or other online rate
>> estimation utilities then you must have values in the "Weight" and

"Weight

>> Uom Id" fields.
>> 5. Submit the form to create the product.
>>
>> Add Content to the New Product
>>
>> 1. Click on the "Content" tab/button for the product you just created.
>> Here you can setup text and images for your product.
>> 2. You will see some forms at the top for administering managed content
>> (ie from the Content Manager) with the product. For more advanced product
>> related content needs use this, but for more common and simple needs,

this
>> can be more difficult to administer and slower at run time.
>> 3. Near the bottom of the page is a section labeled "Override Simple
>> Fields". Here you will typically want to specify a Product Name, Product
>> Description, and Long Description. If you have images to associate with
the
>> product, you can specify their locations here, or upload them. Note that
>> there are default locations for the images (can be quickly set by
clicking
>> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
>> but of course you can put your images anywhere. These can be an absolute
>> URL, or will be relative to the current server address, or the content
URL
>> prefix if one is specified in the url.properties file.
>>
>> Add Prices to the Product
>>
>> 1. Product pricing in OFBiz is very flexible. There are two main
>> aspects to it: Prices and Price Rules. This is independent of promotions,
>> which are applied after the price calculation is done.
>> 2. For basic operation you should have at least one type of price setup
>> for each product: the Default Price. This is the price that is used when
no
>> rules apply.
>> 3. To add a Default Price go to the Prices tab for the Product, and use
>> the form at the bottom of the page.
>>
>> 1. The Product Price Type Id should be "Default Price", the Currency
>> Uom Id should be whatever currency the price is in, and the Product Store
>> Group Id can be left as Not Applicable, unless you are setting up
multiple
>> groups of stores that have different pricing.
>> 2. The From Date can be now or in the future, if you want the price to
>> take effect in the future. The Thru Date is optional, but can be used to
>> specify that this particular price expires at a certain date and time.
Note
>> that if there are multiple prices of the same type, etc that are active
at
>> once, it will use the one with the most recent From Date. This is useful
>> when you want a temporary price to override the normal "Default" price of
>> the product.
>>
>> 4. If you are using price rules or may do so in the future you may also
>> want to enter information such as the List Price and the Average Cost
which
>> are often used in the price calculations.
>> 5. Note that if a Minimum Price is set the price will never be less
>> than that. So, even if the Default Price is to 2.00 and the Minimum Price
is
>> set to 3.00, then 3.00 will be used as the calculated price. The Maximum
>> Price setting works the same way as the ceiling for the price.
>>
>> Make sure to put each product in a browse category, and in the All
Products
>> category so that it can be searched for, viewed, and purchased in your
>> catalog.
>>
>> Expert Recommendation: These are the basics, but there is a lot more
>> information about products that you can, or may need to, setup. We
recommend

>> reviewing the more detailed documentation or engaging the services of an
>> experienced consulting to help you through this.
>>
>> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
>> Thesaurus, Features for special functionality or parametric search,
>> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
>> Products, Virtual and Variant Products, Inventory/Facility/Location
>> settings, and so on
>>
>> See the end-user documentation space for details on how to set these

things
>> up and what they mean. Also see this for more advanced options for
Products,
>> Categories, and so on.
>>
>>
>>
>>
>>
>>    
>
>  

[David E. Jones-2]

I'd like to add my thanks for sharing this Nick, it's really great feedback and a good case study too.

-David


On Mar 2, 2010, at 11:50 AM, Nick Rosser wrote:

> I'll group together a number of q&a in one general response:
>
> is it a common thing to have a Microsoft-IIS/6.0 in
> front of Tomcat rather than Apache?
> NICK: dunno, this was dictated by the client
>
> Is the site behavior pretty good with a larger set of products? Now I
> can only see arround 140 products there.
> NICK: the back-end ERP is much more active, processing 5000 orders per day;
> 140 products on the web site reflects a subset of their product line. ERP is
> performing well, with ~100 customer service users.
>
> How many developers did it take?
> NICK: 3 for the ERP system (lots of customization; close to 1 year by the
> time we were fully live); 1-2 for the eCommerce site (approx 6 months)
>
> What was their skill set?
> NICK: Senior J2EE, experienced in the delivery of web based business
> software
>
> I'd be interested in knowing more about specific requirements for beginner
> documentation and/or training. If you have time, could you post some more
> information about this?
> NICK: tough question. I think we generally struggled with implementation
> concepts that we knew would be challenging. How do you properly extend
> existing entities? What's the best practice for services etc? And the
> classic struggle of not fully understanding what OFBiz does ootb and coding
> around it, only to find out that a simple tweak / configuration would have
> worked (or was close). This may simply be a nature of the sheer size of
> OFBiz and generally not appreciating all the features, we are much better at
> looking for stuff before we code it. This gets back to a lack of knowledge
> available, particularly outside of simple issues, that we would have
> appreciated greatly during our implementation.
>
> Nick
>
>
> -----Original Message-----
> From: Florin Popa [mailto:[hidden email]]
> Sent: Tuesday, March 02, 2010 10:38 AM
> To: [hidden email]
> Subject: Re: Salmon LLC: OFBiz eCommerce Site Goes Live
>
> Hello all,
>
> One question please: is it a common thing to have a Microsoft-IIS/6.0 in
> front of Tomcat rather than Apache?
>
> Is the site behavior pretty good with a larger set of products? Now I
> can only see arround 140 products there.
>
> thanks,
> Florin
>> Great post Nick - and thanks for being one of those vendors who is giving
> back to the community - especially with this level of detail.  We enjoyed
> working with you and are stoked to see that thru your hard work and patience
> with the community you were able to achieve the level of internal adoption
> that many people strive for, but are unsuccessful.  The points you lay out
> here are great for everyone to hear - and I think really hit the nail on the
> head as far as the difficulty of less technical, and even less resourced
> companies face.
>>
>> That being said, I believe that there are commercial entities in the OFBiz
> world with the right processes, enough firepower (read resources) and
> expertise to ensure success in your project.  This may not have been the
> case when you first started, but I think that has changed.
>>
>> This does not mean that any one entity has to run the entire project -
> like say a JBoss or a MySQL - but there is really not much difference in
> paying for MySQL support services than paying the high tiered support
> offerings with OFBiz.  You just have to choose the right group and find the
> right individuals to help you along - and my personal opinion is that they
> are out there.
>>
>> Sorry to digress - now, back to your original point, there are a ton of
> things that the community can improve upon that you mentioned below.  Can
> you put these together up on the Wiki, much like we've discussed in other
> threads, so that we can begin to track our progress?  I'd like to see the
> documentation angle continue to get worked thru (technical and end-user) -
> possibly moving some of the documentation that I know that people are
> creating internally - out to a place where everyone can appreciate it
> without having to pay additional money.
>>
>> We need to come together to make this happen - and it will only get there
> if all of the corporate entities out there begin to or continue to support
> the community by donating a ton of time into documentation, mailing list
> responses, enhanced applications.   Thanks again Nick - this is great stuff.
>>
>> Cheers,
>> Ruppert
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>> On Mar 2, 2010, at 7:08 AM, Nick Rosser wrote:
>>
>>
>>> All,
>>>
>>>
>>>
>>> Just a note to let you know that we recently released an eCommerce site.
>>> Check out www.purityproducts.com.
>>>
>>>
>>>
>>> Launched a couple of weeks ago, to very little fanfare, this is a
> complete
>>> replacement of an existing site, with no upgrades to the UI or basic
>>> eCommerce structure. A straight conversion to OFBiz as a platform change
> to
>>> allow for future changes, enhancements and growth.
>>>
>>>
>>>
>>> This is on the back of a very successful ERP release last year for the
> same
>>> customer, our first OFBiz implementation. Challenging, to say the least,
> but
>>> very successful in terms of laying the same platform for the back-end
>>> processes, with a specific focus on a very intense and customized CSR
> layer.
>>>
>>>
>>>
>>>
>>> Of interest to some, particularly given recent posts about
> community-driven
>>> OFBiz and various discussions about the lack of process and documentation
> I
>>> thought I'd share our  experience of using OFBiz during the last 2 years.
>>> First a little background on Salmon LLC that I think is relevant:
>>>
>>>
>>>
>>> Our background:
>>>
>>>
>>>
>>> *       we have released open-source framework software in the past
>>>
>>> *       we have developed many custom J2EE solutions
>>>
>>> *       we have adopted other ERP solutions prior to OFBiz (Compiere /
>>> Adempiere - before bailing because it was not really open-source)
>>>
>>> *       we have adopted other packaged solutions in other business areas
>>>
>>> *       we're a technical company, with business savvy
>>>
>>> *       we can figure stuff out
>>>
>>>
>>>
>>> OFBiz, the good:
>>>
>>>
>>>
>>> *       nice architecture, we were generally impressed with the service
>>> based approach
>>>
>>> *       the services work. For us, OFBiz is a starting point, the
> services
>>> are available and they work!
>>>
>>> *       the community support is amazing; the commitment of everyone
>>> monitoring this thread and providing responses is commendable
>>>
>>>
>>>
>>> OFBiz, the not so good:
>>>
>>>
>>>
>>> *       UI ootb: not the best. BUT, we understand the objective
> (framework)
>>> and we understand the ERP domain to realize that OFBiz is a starting
> point;
>>> and a pretty good one
>>>
>>> *       architecture: next level of concepts was harder to grasp, as you
> dig
>>> more into the code the more confusing it can get; the lack of good coding
>>> standards can make it very confusing as to what exactly is the best
> practice
>>> (particularly when looking at "older" code)
>>>
>>> *       the devil is in the details, and there are a lot of them; be
>>> prepared to make mistakes, having to figure stuff out for yourself, lots
> of
>>> trial and error
>>>
>>> *       community support: when it gets a little tricky it's much more
>>> difficult to explain the issue and get a good community response.
> Perfectly
>>> understandable but this is where the risk comes into play . we spent
>>> countless hours on some very tricky payment processing issues (credit,
> card,
>>> returns, refunds) and inventory processing
>>>
>>> *       what a pity that the documentation cannot encapsulate all the
>>> knowledge from the user-group. Yes, I know we can search through email
>>> postings. Yes, I know that the documentation is improving. But there are
>>> still problems in this area, perhaps I can share one specific example:
>>>
>>>
>>>
>>> One specific example:
>>>
>>>
>>>
>>> *       Product A is put with product B in order to offer product C
>>>
>>> *       Product A and B may (or may not) have inventory associated
>>>
>>> *       When assembled into C, this can also carry inventory
>>>
>>> *       When the item is returned, it may be put back into inventory as
>>> product C, OR may be disassembled into products A and B
>>>
>>> *       Fairly straight forward and not uncommon, and I'm sure that OFBiz
>>> can handle this but we couldn't find ANY document that would clearly
> explain
>>> product configuration and it's impact on other areas of the ERP solution
>>>
>>> *       I remember being amazed that a thorough product configuration
> guide
>>> was not available that would explain all the product attributes and a
> high
>>> level description of the impact throughout OFBiz. What's more important
> is
>>> that if you guess wrong then you can cause all sorts of problems
>>>
>>> *       BTW: since this was a while ago I did review the current
>>> documentation, the only item I saw that described setting up a product
> was
>>> the "Business Setup Guide (for users)", the content for Product Setup is
>>> pasted below. The best looking resource is I understand that there may be
>>> more documentation available that is more appropriate . BUT, if I'm new
> to
>>> OFBiz and cannot find something decent after a few minutes then I'll move
> on
>>> very quickly
>>>
>>>
>>>
>>> So, where are we now? Well, I think we can safely say that we are OFBiz
>>> adopters, it took much sweat and tears to get to where we are now but I
>>> consider my team to be well versed, near expert, with ERP and eCommerce
>>> implementations using OFBiz. I'm very comfortable offering this service
> to
>>> our clients, and very comfortable with our ability to deliver scalable
> ERP
>>> and eCommerce solutions.
>>>
>>>
>>>
>>> HOWEVER, our first implementation was very stressful. And in hindsight,
> very
>>> risky. Remember that ERP solutions are "bet your business" propositions .
> we
>>> cannot make mistakes. If we do, we jeopardize our business and the
> business
>>> of our clients. In our first implementation we are processing 5000 orders
>>> per day. For the first 3-4 weeks of go-live the background jobs were
> taking
>>> more than 24 hours to run (build orders from a recurring order list,
> process
>>> orders for fulfillment, manage incoming inventory, process credit card
>>> transactions, PLUS any new orders for that day). Saturdays and Sundays
> were
>>> used to make-up the time while we figured out solutions! As you can
> imagine
>>> we had a very stressful time working with our client, tuning our
> processes
>>> and working with our client to keep OFBiz as the ERP solution. I'm happy
> to
>>> report that everything is perfectly fine now, but this is not the way we
>>> like to do business.
>>>
>>>
>>>
>>> I consider my team to be extremely committed, technically excellent and
>>> business savvy. I wonder how small companies or small integrators adopt
>>> OFBiz without these resources?
>>>
>>>
>>>
>>> Conclusion:
>>>
>>>
>>>
>>> *       As I re-read my comments and gather my thoughts it basically
> boils
>>> down to documentation
>>>
>>> *       We did not have the luxury of being able to hire a certified
> "guru"
>>> to help out (we did have David Jones spend a week with us initially and
> used
>>> a couple of committers for specific tasks) but there is generally no
>>> "corporate" option to ensure success
>>>
>>> *       Best practices / coding techniques etc are exposed because of the
>>> open-source nature of OFBiz; it's probably better written than other
>>> proprietary software; this is not an essential issue
>>>
>>> *       So everything hinges on community support. Lots of it is required
>>> for early adopters and we see these postings every day. For folks that
> have
>>> moved into more complex areas (like we were 12 months ago), the community
>>> support is not enough-the issues are too complex
>>>
>>> *       As an open-source project, without formal corporate backing, the
> key
>>> is documentation, not just technical. And I suspect that we need more
> than
>>> Oracle and SAP because of the community nature of the project
>>>
>>>
>>>
>>> Nick Rosser
>>>
>>> Salmon LLC
>>>
>>>
>>>
>>>
>>>
>>>
>>> Product Setup
>>>
>>>
>>> Congratulations, you are finally to the point where you can start setting
> up
>>> products....
>>>
>>> To create a Product follow a process similar to those described for other
>>> things, like Categories.
>>>
>>> 1. Go to the main page of the Catalog Manager and click on the "Create
>>> New Product" link.
>>> 2. If you fill in an ID it will make sure that ID is valid, and if so
>>> it will use that one. If you specify no ID it will generate one.
>>> 3. Set an Internal Name that makes it easy for you to recognize the
>>> product. This name will be shown in the admin tools, but not to the
>>> customer.
>>> 4. Note that if you are using the UPS or USPS or other online rate
>>> estimation utilities then you must have values in the "Weight" and
> "Weight
>>> Uom Id" fields.
>>> 5. Submit the form to create the product.
>>>
>>> Add Content to the New Product
>>>
>>> 1. Click on the "Content" tab/button for the product you just created.
>>> Here you can setup text and images for your product.
>>> 2. You will see some forms at the top for administering managed content
>>> (ie from the Content Manager) with the product. For more advanced product
>>> related content needs use this, but for more common and simple needs,
> this
>>> can be more difficult to administer and slower at run time.
>>> 3. Near the bottom of the page is a section labeled "Override Simple
>>> Fields". Here you will typically want to specify a Product Name, Product
>>> Description, and Long Description. If you have images to associate with
> the
>>> product, you can specify their locations here, or upload them. Note that
>>> there are default locations for the images (can be quickly set by
> clicking
>>> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
>>> but of course you can put your images anywhere. These can be an absolute
>>> URL, or will be relative to the current server address, or the content
> URL
>>> prefix if one is specified in the url.properties file.
>>>
>>> Add Prices to the Product
>>>
>>> 1. Product pricing in OFBiz is very flexible. There are two main
>>> aspects to it: Prices and Price Rules. This is independent of promotions,
>>> which are applied after the price calculation is done.
>>> 2. For basic operation you should have at least one type of price setup
>>> for each product: the Default Price. This is the price that is used when
> no
>>> rules apply.
>>> 3. To add a Default Price go to the Prices tab for the Product, and use
>>> the form at the bottom of the page.
>>>
>>> 1. The Product Price Type Id should be "Default Price", the Currency
>>> Uom Id should be whatever currency the price is in, and the Product Store
>>> Group Id can be left as Not Applicable, unless you are setting up
> multiple
>>> groups of stores that have different pricing.
>>> 2. The From Date can be now or in the future, if you want the price to
>>> take effect in the future. The Thru Date is optional, but can be used to
>>> specify that this particular price expires at a certain date and time.
> Note
>>> that if there are multiple prices of the same type, etc that are active
> at
>>> once, it will use the one with the most recent From Date. This is useful
>>> when you want a temporary price to override the normal "Default" price of
>>> the product.
>>>
>>> 4. If you are using price rules or may do so in the future you may also
>>> want to enter information such as the List Price and the Average Cost
> which
>>> are often used in the price calculations.
>>> 5. Note that if a Minimum Price is set the price will never be less
>>> than that. So, even if the Default Price is to 2.00 and the Minimum Price
> is
>>> set to 3.00, then 3.00 will be used as the calculated price. The Maximum
>>> Price setting works the same way as the ceiling for the price.
>>>
>>> Make sure to put each product in a browse category, and in the All
> Products
>>> category so that it can be searched for, viewed, and purchased in your
>>> catalog.
>>>
>>> Expert Recommendation: These are the basics, but there is a lot more
>>> information about products that you can, or may need to, setup. We
> recommend
>>> reviewing the more detailed documentation or engaging the services of an
>>> experienced consulting to help you through this.
>>>
>>> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
>>> Thesaurus, Features for special functionality or parametric search,
>>> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
>>> Products, Virtual and Variant Products, Inventory/Facility/Location
>>> settings, and so on
>>>
>>> See the end-user documentation space for details on how to set these
> things
>>> up and what they mean. Also see this for more advanced options for
> Products,
>>> Categories, and so on.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Sumit Pandit]

Hi Nick,

It is good work, nice analysis and feedback to community. Appreciating the
efforts. You are heaving a great site.

--
Thanks And Regards
Sumit Pandit



On Tue, Mar 2, 2010 at 8:08 PM, Nick Rosser <[hidden email]> wrote:

> All,
>
>
>
> Just a note to let you know that we recently released an eCommerce site.
> Check out www.purityproducts.com.
>
>
>
> Launched a couple of weeks ago, to very little fanfare, this is a complete
> replacement of an existing site, with no upgrades to the UI or basic
> eCommerce structure. A straight conversion to OFBiz as a platform change to
> allow for future changes, enhancements and growth.
>
>
>
> This is on the back of a very successful ERP release last year for the same
> customer, our first OFBiz implementation. Challenging, to say the least,
> but
> very successful in terms of laying the same platform for the back-end
> processes, with a specific focus on a very intense and customized CSR
> layer.
>
>
>
>
> Of interest to some, particularly given recent posts about community-driven
> OFBiz and various discussions about the lack of process and documentation I
> thought I'd share our  experience of using OFBiz during the last 2 years.
> First a little background on Salmon LLC that I think is relevant:
>
>
>
> Our background:
>
>
>
> *       we have released open-source framework software in the past
>
> *       we have developed many custom J2EE solutions
>
> *       we have adopted other ERP solutions prior to OFBiz (Compiere /
> Adempiere - before bailing because it was not really open-source)
>
> *       we have adopted other packaged solutions in other business areas
>
> *       we're a technical company, with business savvy
>
> *       we can figure stuff out
>
>
>
> OFBiz, the good:
>
>
>
> *       nice architecture, we were generally impressed with the service
> based approach
>
> *       the services work. For us, OFBiz is a starting point, the services
> are available and they work!
>
> *       the community support is amazing; the commitment of everyone
> monitoring this thread and providing responses is commendable
>
>
>
> OFBiz, the not so good:
>
>
>
> *       UI ootb: not the best. BUT, we understand the objective (framework)
> and we understand the ERP domain to realize that OFBiz is a starting point;
> and a pretty good one
>
> *       architecture: next level of concepts was harder to grasp, as you
> dig
> more into the code the more confusing it can get; the lack of good coding
> standards can make it very confusing as to what exactly is the best
> practice
> (particularly when looking at "older" code)
>
> *       the devil is in the details, and there are a lot of them; be
> prepared to make mistakes, having to figure stuff out for yourself, lots of
> trial and error
>
> *       community support: when it gets a little tricky it's much more
> difficult to explain the issue and get a good community response. Perfectly
> understandable but this is where the risk comes into play . we spent
> countless hours on some very tricky payment processing issues (credit,
> card,
> returns, refunds) and inventory processing
>
> *       what a pity that the documentation cannot encapsulate all the
> knowledge from the user-group. Yes, I know we can search through email
> postings. Yes, I know that the documentation is improving. But there are
> still problems in this area, perhaps I can share one specific example:
>
>
>
> One specific example:
>
>
>
> *       Product A is put with product B in order to offer product C
>
> *       Product A and B may (or may not) have inventory associated
>
> *       When assembled into C, this can also carry inventory
>
> *       When the item is returned, it may be put back into inventory as
> product C, OR may be disassembled into products A and B
>
> *       Fairly straight forward and not uncommon, and I'm sure that OFBiz
> can handle this but we couldn't find ANY document that would clearly
> explain
> product configuration and it's impact on other areas of the ERP solution
>
> *       I remember being amazed that a thorough product configuration guide
> was not available that would explain all the product attributes and a high
> level description of the impact throughout OFBiz. What's more important is
> that if you guess wrong then you can cause all sorts of problems
>
> *       BTW: since this was a while ago I did review the current
> documentation, the only item I saw that described setting up a product was
> the "Business Setup Guide (for users)", the content for Product Setup is
> pasted below. The best looking resource is I understand that there may be
> more documentation available that is more appropriate . BUT, if I'm new to
> OFBiz and cannot find something decent after a few minutes then I'll move
> on
> very quickly
>
>
>
> So, where are we now? Well, I think we can safely say that we are OFBiz
> adopters, it took much sweat and tears to get to where we are now but I
> consider my team to be well versed, near expert, with ERP and eCommerce
> implementations using OFBiz. I'm very comfortable offering this service to
> our clients, and very comfortable with our ability to deliver scalable ERP
> and eCommerce solutions.
>
>
>
> HOWEVER, our first implementation was very stressful. And in hindsight,
> very
> risky. Remember that ERP solutions are "bet your business" propositions .
> we
> cannot make mistakes. If we do, we jeopardize our business and the business
> of our clients. In our first implementation we are processing 5000 orders
> per day. For the first 3-4 weeks of go-live the background jobs were taking
> more than 24 hours to run (build orders from a recurring order list,
> process
> orders for fulfillment, manage incoming inventory, process credit card
> transactions, PLUS any new orders for that day). Saturdays and Sundays were
> used to make-up the time while we figured out solutions! As you can imagine
> we had a very stressful time working with our client, tuning our processes
> and working with our client to keep OFBiz as the ERP solution. I'm happy to
> report that everything is perfectly fine now, but this is not the way we
> like to do business.
>
>
>
> I consider my team to be extremely committed, technically excellent and
> business savvy. I wonder how small companies or small integrators adopt
> OFBiz without these resources?
>
>
>
> Conclusion:
>
>
>
> *       As I re-read my comments and gather my thoughts it basically boils
> down to documentation
>
> *       We did not have the luxury of being able to hire a certified "guru"
> to help out (we did have David Jones spend a week with us initially and
> used
> a couple of committers for specific tasks) but there is generally no
> "corporate" option to ensure success
>
> *       Best practices / coding techniques etc are exposed because of the
> open-source nature of OFBiz; it's probably better written than other
> proprietary software; this is not an essential issue
>
> *       So everything hinges on community support. Lots of it is required
> for early adopters and we see these postings every day. For folks that have
> moved into more complex areas (like we were 12 months ago), the community
> support is not enough-the issues are too complex
>
> *       As an open-source project, without formal corporate backing, the
> key
> is documentation, not just technical. And I suspect that we need more than
> Oracle and SAP because of the community nature of the project
>
>
>
> Nick Rosser
>
> Salmon LLC
>
>
>
>
>
>
> Product Setup
>
>
> Congratulations, you are finally to the point where you can start setting
> up
> products....
>
> To create a Product follow a process similar to those described for other
> things, like Categories.
>
> 1.      Go to the main page of the Catalog Manager and click on the "Create
> New Product" link.
> 2.      If you fill in an ID it will make sure that ID is valid, and if so
> it will use that one. If you specify no ID it will generate one.
> 3.      Set an Internal Name that makes it easy for you to recognize the
> product. This name will be shown in the admin tools, but not to the
> customer.
> 4.      Note that if you are using the UPS or USPS or other online rate
> estimation utilities then you must have values in the "Weight" and "Weight
> Uom Id" fields.
> 5.      Submit the form to create the product.
>
> Add Content to the New Product
>
> 1.      Click on the "Content" tab/button for the product you just created.
> Here you can setup text and images for your product.
> 2.      You will see some forms at the top for administering managed
> content
> (ie from the Content Manager) with the product. For more advanced product
> related content needs use this, but for more common and simple needs, this
> can be more difficult to administer and slower at run time.
> 3.      Near the bottom of the page is a section labeled "Override Simple
> Fields". Here you will typically want to specify a Product Name, Product
> Description, and Long Description. If you have images to associate with the
> product, you can specify their locations here, or upload them. Note that
> there are default locations for the images (can be quickly set by clicking
> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations,
> but of course you can put your images anywhere. These can be an absolute
> URL, or will be relative to the current server address, or the content URL
> prefix if one is specified in the url.properties file.
>
> Add Prices to the Product
>
> 1.      Product pricing in OFBiz is very flexible. There are two main
> aspects to it: Prices and Price Rules. This is independent of promotions,
> which are applied after the price calculation is done.
> 2.      For basic operation you should have at least one type of price
> setup
> for each product: the Default Price. This is the price that is used when no
> rules apply.
> 3.      To add a Default Price go to the Prices tab for the Product, and
> use
> the form at the bottom of the page.
>
> 1.      The Product Price Type Id should be "Default Price", the Currency
> Uom Id should be whatever currency the price is in, and the Product Store
> Group Id can be left as Not Applicable, unless you are setting up multiple
> groups of stores that have different pricing.
> 2.      The From Date can be now or in the future, if you want the price to
> take effect in the future. The Thru Date is optional, but can be used to
> specify that this particular price expires at a certain date and time. Note
> that if there are multiple prices of the same type, etc that are active at
> once, it will use the one with the most recent From Date. This is useful
> when you want a temporary price to override the normal "Default" price of
> the product.
>
> 4.      If you are using price rules or may do so in the future you may
> also
> want to enter information such as the List Price and the Average Cost which
> are often used in the price calculations.
> 5.      Note that if a Minimum Price is set the price will never be less
> than that. So, even if the Default Price is to 2.00 and the Minimum Price
> is
> set to 3.00, then 3.00 will be used as the calculated price. The Maximum
> Price setting works the same way as the ceiling for the price.
>
> Make sure to put each product in a browse category, and in the All Products
> category so that it can be searched for, viewed, and purchased in your
> catalog.
>
> Expert Recommendation: These are the basics, but there is a lot more
> information about products that you can, or may need to, setup. We
> recommend
> reviewing the more detailed documentation or engaging the services of an
> experienced consulting to help you through this.
>
> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword
> Thesaurus, Features for special functionality or parametric search,
> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured
> Products, Virtual and Variant Products, Inventory/Facility/Location
> settings, and so on
>
> See the end-user documentation space for details on how to set these things
> up and what they mean. Also see this for more advanced options for
> Products,
> Categories, and so on.
>
>
>
>
>
>