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 <nros...@salmonllc.com> 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. > > > > > >
