Changes by last author:
Added:
Subpage of WebShop/UnderDevelopment - discussing acpects of multiple WebShop instances
Soon we need to raise stock levels in the US. At least in the East Coast warehouse, but West Coast too, if Keith likes so and the support infrastructure is created. Why ? * slightly different prices, because of logistics. Supply chain is different for many items in EU and US, with different purchase prices * default currency is USD in US, Euro in EU * better fault tolerancy * better load distribution (mainly for shop crew, but also for webservers) * less confidential info at one place ---- How ? We should finally forget oscommerce. It has serious scaling problems. * masterdata maintenance: maintained at one place, distributed to any. This is mainly the "article master" (-data) ** images (CVS or SVN repository, or DB) ** article descriptions ** article prices * transaction data ** order dispatch (possibly split to packages, serviced from different places) ** proper inventory variance for the facility that serviced the order While this could be solved with oscommerce, with * some maintenance guidelines and instructions * inventory bridge to ofbiz (oscommerce item number stored in ofbiz) The article variants make this a bit hard. To sum it up, with * oscommerce: sooner, but some work out the window * ofbiz: later, but nicer maintenance and final result ---- Other tools * compiere.org has a nice GUI client (besides the web-browser). Unfortunately it requires oracle. Programmed in Java. * [OfBiz] is our choice for future path. Programmed in java. Uses XML heavily. Quite awesome. It seems to solve most of our (catalog and stock handling, manufacturing-support, shipments, tasks) problems as is. It's extensible, so we can make entities for the rest (yet to do so). The entity-engine rocks. More on WebShop/UnderDevelopment/OfBiz |