WO2002021349A2

WO2002021349A2 - Method and apparatus for on-line merchandise customization

Info

Publication number: WO2002021349A2
Application number: PCT/CA2001/001041
Authority: WO
Inventors: David Remmer; Brett Marchand
Original assignee: Onside Inc.
Priority date: 2000-07-19
Filing date: 2001-07-19
Publication date: 2002-03-14
Also published as: AU2001275623A1

Description

METHOD AND APPARATUS FOR ON-LINE MERCHANDISE CUSTOMIZATION

FIELD OF THE INVENTION

This invention relates in general to on-line ordering of merchandise. More particularly, the invention relates to a method and apparatus for user customization of an item or items over the Internet including a visual platform, to perform the customization of a product or service following a constraint-based set of rules, placing an order for that customized item and then converting the customized order into a set of instructions which are sent electronically in a format understood by an end suppliers/manufacturers for fulfillment of the order.

BACKGROUND OF THE INVENTION

The Internet is especially conducive to conducting electronic commerce, particularly between businesses (B2B), due to its ability to link organizations with similar business interests, complementary products common and/or reciprocating goals. Many vendors utilize the reach and easy access of the World Wide Web to post electronic catalogues on the Internet for purchase by potential customers. Others have created 'exchanges' on the World Wide Web to connect sellers and buyers to transact by allowing sellers to electronically post their products and for buyers to browse what products are available for purchase

Although conducive to electronic cataloguing, the Internet has taken the human interaction out of the selling and buying process. One of the most important benefits of this human interaction is the exchange that takes place between a buyer and seller regarding any unique requirements the buyer might be looking for to satisfy his/her needs. The Internet possesses the ability to customize a product. However, existing methodologies usually require the user be skilled in design in order to create a satisfactory end product. One of the disadvantages of human interaction is the occurrence of errors when translating a buyer's unique product requirements into fulfillment instructions. This is especially true when, in order to fill the order, instructions must be given to many different intermediary suppliers and/or service providers, some of who may conduct business in a different language than that of the original buyer.

A number of customization technologies have been developed in the past which allow a user/buyer to select from choices that are text based only and are mutually exclusive of other choices. One prominent example is the Dell Computer on-line ordering site, which allows the user to select customizations of a microcomputer order, and shows the user the impact on price of the user's choices. No visualization is attempted (partially because it is not relevant) and choices are independent of one another.

Bill-Of-Materials systems generally allow the selection of components by an operator where prices are derived from the inputted values. These systems build a uni- lingual version of the Bill-Of-Materials that needs to be translated into a number of languages depending on the source of inputs and manufacturing.

SUMMARY OF THE INVENTION

According to the present invention, a system is provided which combines visualization with a rigid constraint based set of rules for customizing a product or service. Immediate feedback is provided to the user both on how an item will look in the real world when it is manufactured. Furthermore, the user is shown how changes in earlier selections will force new selections or options that are no longer be valid given the design constraints. For example, a certain color may not be offered for a certain fabric, meaning if that fabric is chosen the previous color selection would no longer be valid. As choices are made the rendered view of the product is altered.

According to the present invention, a method and apparatus are provided by which a non-expert user can customize an item, place an order for the item and then have the system convert that item into a electronic digital bill of materials to provide fulfillment instructions to supplier(s). The most rewarding aspects of human interaction are injected into the user's online ordering experience (e.g. customization, interaction with the design process, feedback on inventory and confidence in pricing, etc.), while eliminating the undesirable aspects (e.g. botched orders, uncertainty regarding product delivery status, etc.)

According to the present invention, during on-line product design and ordering the user creates a visualized set of selected customized aspects, resulting in a series of instructions on how to manufacture the customized item. These instructions for the sourcing of inputs, manufacturing instructions, shipping, packing, customs, and billing of a customized order are stored in a single XML file that has been translated into all of the languages of the relevant locales. The system then generates all of the required documentation for each step in the supply chain. Consequently, the inputs and manufacturing may be performed in a locale that does not use the same language as the originating locale of the order, since the bill of materials is multi-lingual.

BRIEF DESCRIPTION OF THE DRAWINGS

A detailed description of the preferred embodiment of the present invention is described herein below, with reference to the drawings in which:

Figure 1 is a block diagram of an Internet based environment for implementation of the invention;

Figure 2 is a block diagram of an on-line ordering system implemented according to the present invention;

Figures 3 A to 3N are screen prints of web pages generated by the system of Figure 2 for the purpose of user interfacing;

Figure 4 is a layer diagram of the system 3 of Figure 1 ;

Figure 5 is a block diagram of a configurator of Figure 4; Figure 6 is an UML object model diagram of the configurator of Figure 5; and

Figure 7 is a block diagram of modules for a digital bill of goods of Figure 4.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Turning to Figure 1, an on-line ordering system is shown by which a plurality of end users 1 interact over the Internet with the non-expert customization system 3 of the present invention for the purpose of designing and ordering merchandise. Upon establishing an on-line session with the non-expert customization system 3, the system prompts the user 1 for a set of constraints (e.g. quantity, price, time). The system then shows the user an electronically displayed set of configuration options which he or she can choose from to customize the design of the end product. These options include, but are not limited to colour, size, structural make-up, material and component options. The system 3 has the ability to show the user/buyer 1 only those options which will be compatible with the constraints laid out by the user/buyer and which can be supplied in a satisfactory manner by the seller operating the system 3. In addition, the user/buyer 1 will have transparent information regarding the pricing implications of his or her option choices.

The order placement system allows the seller to deliver the end product to the buyer 1 by asking the user/buyer for information including, but not limited to credit worthiness, currency preferences, sample requirements and delivery specifications. Then the order system 1 then links to the necessary service providers 5 via the Internet 2 for financing of the order, material ordering, shipment, etc.

Finally, the custom designed product is converted, electronically into a digital set of materials which gives instructions to service providers 5 (e.g. the shipper, material suppliers, manufacturer, customs broker, etc.) on how to fulfill the order. These instructions are a direct translation of the electronically displayed product into the end supplier's mother tongue. Turning now to Figure 2, the system 3 is shown in functional terms comprising a relational database 21, applications server 23 including, among other things, rules manager 25, a web access server 27, imaging server 29 and messaging server 31. Although the database 21 , rules manager 25, web server 27, imaging server 29, and messaging server 31 are shown as different functional blocks, in actual fact these functional blocks are preferably physically implemented within a single applications server.

Initially, domain analysis is performed to determine what the various customization aspects are of the product, and what the constraints are on those customizations. The end results of this domain analysis are actual customization instances. For example, when designing and ordering a customizable bag, only some colours may be available in certain fabrics, only certain pictures are applicable to certain styles, etc. Thus, in performing domain analysis the relationships between constraints and customization instances are determined and stored in relational database 21. In addition to constraints and customization instances, a raw description of the workflow is also stored in database 21. The workflow itself is dependent on three main constraints (price, quantity and time) such that the workflow is determined both by domain analysis and at run time by what constraints have been entered in the system by the user. Thus, if the user 1 is only willing to spend a certain amount of money, for many customization instances, many choices will not be shown. If the user specifies that the product is required at a certain time or in a certain quantity, other customization instances are not presented, etc.

The customization instances, constraints and flow description form tables within the database 21. The price ranges go into one rule table (Table A, below), the materials and the colours form actual instances within an element table (Table B) along with an indication of whether the element is "standard". Standard items in the database 21 dictate default elements for user presentation (e.g. default materials, default colours, etc.) An include/exclude table is provided (Table C) for dictating, as an example, what happens in the case of a material or colour which is non standard. For the present example of bags, the colour of the fabric is substantially dictated by the choice of fabric. So, in the present case there are no "standard" colours, but only a standard fabric. Consequently, the include/exclude table includes a series of rules to either add the other fabrics based on a selected style or remove the standard fabric from the styles for which such fabric is not acceptable. Finally, for the present example, a component table (Table D) is provided with a selection from three styles. Table A

Price Range Table

Upper/lower

Table B

Table C

Include/Exclude Table

If style 1 include material 1

If material 2 exclude colour 4

Table D

In operation, the user 1 initiates a session with the system 3 via web server 27. The user logs in to the system with a user name and password. The rules manager 21 only shows styles to the user based on predefined "categories" of user. Thus, a given user may be a customer of a particular product provider, (e.g. a category partner who has provided a customer list for storage on the database 21). This user will not be presented with any merchandise from a "competing" supplier.

The user is prompted to enter the three main constraints (price, quantity and time) and the style of bag (Table D). In response, a particular style of bag is presented with a default fabric, a default colour, default pocket configurations, default hardware, etc. The selected bag actually exists in inventory with the foregoing series of defaults. The system 3 determines the defaults from database 21 and presents to the user 1 a bag with all those defaults. It creates an entire complete "buyable" bag which, in theory, can be immediately purchased without any further customization, if the user so wishes.

Alternatively, as indicated above, the user 1 may select from other customizable features, which causes the rules manager 25 to fire the appropriate rules and in response add and remove elements for presentation to the user 1. More particularly, the rules manager 25 fires additional rules which are consistent with the previously entered price, quantity, time and style, in order to present all of the fabrics that match the price/time criteria as well matching the chosen style and fabric. Thereafter, the same rules firing takes place for colour, and so on. Ultimately, a bag data object is created from the user selections and consequential rule firing.

All of the user interaction with the system 3 is via the web server 27 which presents a series of web pages with graphical renderings of the product under development (i.e. being customized). These HTML pages and embedded graphical images including 3D models are generated by an image server 29 under control of rules manager 21 based on the firing of certain rules within database 21. The image server 29 performs its graphics rendering at the client (user 1) via downloading appropriate software to the client (e.g. Java 3D API, 3D visualization engine). However, it is contemplated that rendering could alternatively be implemented on the server side (i.e. system 3) rather than on the client side (i.e. user 1), to avoid the necessity of developing special software to run on the client. Three levels of customization are provided. The least level of customization simply presents the default item with standard features, for immediate ordering by the user 1. A second level of customization provides for quick turn around times on low quantity orders. In this case, the user selects fabric and colour for the product, which are displayed to the user as a 3D model via image server 29. The most elaborate level of customization allows the user to utilize 3-D type design tools to' customize the decoration and structure of the product order. The image server displays a control panel for indicating to the user 1 what design choices have been made, as well as the defaults for the particular product (e.g. bag). Continued customization is performed from the control panel display (e.g. hardware changes such as zipper, etc.). The user is permitted to change previously selected design features, in response to which the rules engine 25 fires the appropriate constraint rules from database 21 to determine whether, as a consequence of the change, some previously selected options are no longer valid. For example, if a new style is selected to replace an earlier one, the constraints mechanism checks to see whether the previously selected choices are still valid (e.g. price range, fabric, colour, etc.). At any point in this customization process, only valid options are presented to the user.

In order to set up the system for image rendering, digital photographs are first taken of a base style, to provide the "catalogue" representation. The more complex levels of customization results in a 3D computer design representation of the product using 3D modeling tools. Models are created of all of the different components that go into the product and digital photographs of the textures to be applied to the models. The models (e.g. AutoCAD, 3D Studio or VRML objects) are compiled or transformed into 3D player models that can be sent to the user browser, or alternatively, through Sun Java code using the 3D API library.

It is contemplated that a graphical button may be provided to allow the user to save a partially customized product, so that if a change is made to an earlier selection which then results in other earlier selected options being rendered invalid, the user has a simple way of returning to a previously satisfactory design. Furthermore, by saving a finished design, the design can be retrieved later for re-ordering (with or without modifications). Turning now to the screen prints of Figures 3 A to 3N, a representative example is set forth by which a user/buyer 1 is able to design and order a customized bag. In Figure 3 A, a web page is presented to the user for inviting the user to "log in". Upon initiating the "log in" hypertext link, a log in web page is presented (Figure 3B). Upon entering user name and password, and clicking the "submit" button, a "design your own Onside bag" page is displayed (Figure 3C). Before proceeding with a new design, the user can review his or her existing account transactions by pressing the "account" link (which results in the web page of Figure 3D). The user can open a "main folder" by clicking on the appropriate hypertext link, permitting additional operations such as uploading of new logos (Figure 3E) or opening a previously stored bag design (Figure 3F).

Upon pressing the "new designs" link, an introductory "what's new" page is displayed (Figure 3G), from which the user can select a category of bag (Figure 3H). Upon choosing a particular category of bag (in the illustrated example, the user selects sports bags/knapsacks), the user is prompted to enter a price range, quantity required and time required (Figure 31). Next, the user is prompted to choose a bag style (Figure 3J), as discussed above with reference to Table D. It will be noted that costs are indicated for each bag style. At this stage, the user can either order the bag as illustrated (Figure 3K) or can proceed to higher levels of customization. For example, as shown in Figure 3L, the user may choose one of a pair of fabrics, the cost implications of which are indicated, or fabric colour (Figure 3M). At the highest level of customization (Figure 3N), the user can further revise the design to include logos, customized zippers and pockets, hardware, etc.

The presentation of options and image rendering as set forth in Figures 3 A-3N complies with the constraints mapping set forth above in connection with Figure 2.

Turning now to Figure 4, there is shown a layer diagram of the system 3 of Figure 1. The system 3 is divided as a client/server application with a client layer and a server layer. On the client layer, an Internet browser is used to access the system 3 over the Internet. The Internet browser includes a 3D player to display models of products and manipulation of the products in three dimensions. The 3D player's activities are modified and controlled by commands from the server layer written in the browser's scripting language, namely Javascript.

The server layer is sub-divided into three layers: presentation layer, business logic layer, and data layer. The presentation layer sits in an Application Server and translates requests from the client layer into application calls in the business logic layer. The business logic layer contains modules that perform specific functions that support the system 3 : designing, managing customers, supplier information, image display, and other functions. These modules sit on four fundamental modules: accounting and ordering, digital bill of goods, brand manager, and configurator. They also communicate with a message queue for inter-enterprise communication and an image server for generating images and models.

Under the business logic layer is the data layer, which acts as a repository for all of the data in the system 3. It contains directories that store information, XML descriptors that describe products and rules, and a database to store transactional information. The database also has access to a brand bank to store digital brand information.

In the data layer, Table E defines the Navigation and Navigation Rules describing the data needed for the product catalog. The cataloged items can be scrolled or searched. The Url for each product category represents the presentation of the category or item. The Default Customer rules apply to all customers together with the customer specific rules or guest rules. Once the catalog item is chosen, the design center is activated and the product data is accessed.

Table E

In the data layer, Table F defined the Product and Product Rules describing the data needed for the Design Center. Componenets, options and option choices or elements are presented to the as the rules allow. Users are given the option of stepping back and rechoosing options.

Table F

Turning now to Figure 5, there is shown a block diagram of a configurator of Figure 4. The configurator comprises a rules engine, a state of design (or session), a database of items, a catalog navigation, an indexed product option tree, a loading system, and a saving system.

The configurator builds a series of instructions to the presentation layer for commanding the browser and 3D player. These instructions ensure that all user design choices for a customized product is within manufacturer's requirements based on time, quantity, price, feasibility and brand/product integrity, and that the browser and 3D player only displays what is available to a user. With each user selection, a new set of instructions is provided thus allowing users to assess all of the results of a modification as they go through the customization process. Because each modification impacts the sourcing and manufacturing processes, which in turn will affect pricing and delivery time, the users are able to see the impact of each modification as it is made.

These instructions indicate: a) what options can or cannot be changed; b) what options are available out of the option set; c) when changes have conflicted with what is and what is not possible within a model; d) instructions or assembling and displaying a 3D model through the 3D player.

The configurator manages all information in the customization and ordering process by encoding manufacturers' design and pricing specifications into a matrix rules set that discerns how options relate to each other in generating the instructions. The loading system loads a series of rules and option descriptions into an index product option tree, which is searchable and is sorted. Past configurations are also loaded to a state (or session) module i.e. a user can continue with a previous session.

Conversely, the saving system takes selections out of the indexed product option tree and save them to the data layer. These option selections are retrieved from the state (or session) module.

The loaded options are also specially indexed into a module that acts as a quick database lookup module. This module is used to get details about a specific item after it's key (or identifier) is known. Generally, this is used to look up information after the rules engine has returned a matrix of available options for a selection.

The catalog navigation module indexes options so that they can be displayed to the presentation layer for easy browsing. This presents a heirchacal map to options that would otherwise appear random and disjointed.

The state (or session) module stores the selections the user makes both while navigating through options as well as choosing specific options. It also records the constraints on any selection or navigation options in terms of limitations or quantity, time, price, or client specific permissions.

The rules engine builds sets or matrices, which determines which options are possible and which should be displayed. It does this by analyzing the current options selected and constraints, and firing an indexed series of rules to determine whether: a) a particular option should be added to the matrix; or b) an option should be discarded from the matrix. It also fires an indexed set of rules that checks to insure that the selection does not result in a set of configured options that would contravene other selection rules (a conflict).

A more complete understanding can be obtained by reference to the following specific Example. This Example is described solely for purposes of illustration and is not intended to limit the scope of the invention. A hypothetical case of how the rules engine works to decide, which colors are available for the body of a t-shirt: first the outside system asks for the top level of navigation which in this case we will make "type of shirts". The rules engine looks at the following set of rules (in this case just one) to determine which options in the navigation tree should be displayed: add the type "T-Shirt" to the list of "type of shirts". When asked for the list of "type of shirts", the rules engine thus returns one option: "T-Shirt", when the user selects, the Rules Engine is advised of this current "type of shirt". Then the rules engine is asked what options can be changed on this product. It then fires the following rules: if the "type of shirt" is "Dress Shirt" add "fabric" to the list of configurable options; if the "type of shirt" is "Dress Shirt" add "color" to the list of configurable options; and if the "type of shirt" is "T-Shirt" add "color" to the list of configurable options.

Thus, when the rules engine is asked for the list of configurable options, the first two rules are not added to the list since their criteria has not been met, but the last option is add to the list as it has had its criteria met. Finally, to determine which colors are available. The rules engine then fires the following rules: if the "type of shirt" is "Dress Shirt" add "cotton" to the list of fabrics; if the "type of shirt" is "T-Shirt" add "grey" to the list of colors; if the "type of shirt" is "T-Shirt" add "white to the list of colors; if the "type of shirt" is "T-Shirt" add "black to the list of colors; and if the "type of shirt" is "Dress Shirt" and the fabric is "cotton" add "white" to the list of colors. In this case, the criteria for the first and the last rule are not satisfied but rules 2,3 and 4 are satisfied thus resulting in a list of "grey, white and black" possible colors for the T-Shirt.

The results of the rules engine's calculation is a matrix that is then converted into HTML and Javascript that displays to the end user catalog and navigation options, product configuration options, and instructions to the browser on how to behave when options are selected. Also, the matrix is converted into XML instructions to the 3D player on details of geometry, light maps, textures, and animations to be displayed.

Turning to Figure 6, there is shown an UML object model diagram of the configurator of Figure 5.

One other important aspect of the database 21 is that it maintains a current indication of the per unit price of the product, which is displayed to the user as the product is being designed. Furthermore, the individual costs of selecting different materials, zipper layouts, etc. are also displayed so that the user/buyer understands the cost implications before making particular design choices. These individual costs may be positive or. negative (i.e. if the available option is less expensive than the default, a negative cost is displayed). This cost transparency feature has been identified as being particularly advantageous in terms of "human interaction" in the on-line buying process. This feature also allows the service provider the opportunity of identifying opportunities for obtaining lower costs from certain suppliers 5 when a number of users 1 are ordering material from a given supplier. These bulk ordering cost discounts may or may not be passed on to the users 1, depending on the wishes of the service provide who is implementing the system 3.

According to the present invention, each customizable element has a bill of materials table associated with it, such that all of the instructions for selecting components and elements is output by the system as an electronic bill of materials which, according to the invention, may be generated as an XML object in any suitable language to the suppliers 5 (e.g. materials suppliers, cut and sew operations, customs brokers, shippers, logistics professionals, etc). The suppliers 5 communicate with the system 3 either via web server 33 or through email via messaging server 31.

The XML document is used by a series of tools within rules manager 25 for outputting the documentation necessary for fulfillment at each stage of the supply chain. The Bill-Of-Materials serves as a single repository of instructions for the fulfillment process spanning geographic and language barriers. As steps in the process are completed by the suppliers 5, XML messages are sent back to the system 3 via messaging server 31 to update the status of the order. This status can be reviewed by the customer 1, suppliers 5, salespeople and other interested parties in order to better co-ordinate activities.

A single file is used to totally represent the order, rather than using related files for different ones of the suppliers (e.g. one file for the custom broker, one for materials, etc.) since the use of multiple files increases the likelihood of errors occurring in the supply chain. However, according to the present invention the single XML document may be rendered in multiple ways (e.g. as a customs declaration form, shipping waybill, etc.) by using a set of scripts to render the order according to the different languages of the suppliers.

Following domain analysis and component selection, a list is generated in a table, having a component id or an element id. The table relates the component id items supplier instructions on how to fulfil the order. Thus, the instructions may relate to how to cut and sew a particular pocket, what exact fabric is required, what pantone colour is required, etc. The instructions are entered first in English and then translated into other languages. The translation engine does not combine sentences since doing so might not actually make any grammatical sense in a language other than English. Instead, the table is built such that the instructions are already laid out on a page, in complete sentences by "plugging in" the information from the table.

The Digital Bill of Goods takes an XML file from the ordering system; this XML file describes what options have been selected and details about who is involved and where the goods are going. Additionally there are details on quantities of sizes being ordered.

The database is queried for manufacturer specific information about each option that has been selected. Data concerning manufacturer part numbers, descriptions, assembly instructions, categorisation, embroidery or silk-screening binary instructions, CAD and CAM binary instructions, and workflow information is retrieved and organised into a tree. Within this tree the translations for all of the languages that might be required to assemble and distribute the product are added.

The system then outputs a single XML document that contains all of the instructions necessary to source, assemble, ship, and distribute a custom built item. This document is organised hierarchically so that it may be added to or updated as the status of assembly and delivery change, as well as be easily queried so that information may be easily integrated into other systems.

The Digital Bill of Goods then takes this XML file and uses a series of templates to build working documents. These templates can be in a variety of formats such as HTML, RTF or PDF and contain fields for data to be filled in. These templates also contain areas that are to be printed or displayed conditionally based on data that is present in the XML file. The Digital Bill of Goods extracts the necessary data from the XML file to fill in the fields as well as executes rules to determine if an area within the template should be present or not. These documents are then stored within the repository as well as distributed to a list of recipients specified by the manufacturer.

The repository contains database tables and records that contain the data and instructions that will be queried by the documentation engine. This repository is updated and maintained by the manufacturer and contains all of the relevant information they need to assemble and distribute custom product. This repository has also been translated into the languages (e.g. Chinese, Vietnamese, Spanish) that will used during manufacturing and fulfilment and these translations are indexed so they may be retrieved during document assembly. The update system receives messages from a Message Queue that indicate changes in status. These messages contain small XML data messages that indicate such things as when raw materials have been delivered to the assembly shop floor, when assembly has been completed, when customs formalities have been dealt with, and updates about progress during the shipping of finished goods. These XML messages are read into the Digital Bill of Goods, which takes the original XML Digital Bill of Goods and updates it with this new information. If necessary, the process of building templated documents is then run once again; this is determined by rules the manufacturer specifies. Then these updated documents are stored within the repository as well as distributed to a list of recipients specified by the manufacturer.

Turning to Figure 7, there is shown a block diagram of modules for a digital bill of goods of Figure 4. Presentation receives requests from the configurator and services the request through calls to Order Processing Engine module. The Order Processing Engine gets the order information from the XML Order Reader module and sends relevant information from Product Component modules (the repositories) to PDF Generator. The PDF Generator generates the relevant PDF/RTF/HTML file (end user readable documents) based on the information and request from the Order Processing Engine. Product Components contains complete information and instructions about the all the product components. XML Order Reader is responsible for reading the order information from the order XML.

Embodiments and variations of the invention are possible, as set forth above. All such changes and modifications may be made without departing from the sphere and scope of the invention as defined by the claims appended hereto.

Claims

WHAT IS CLAIMED IS:

1. A method of ordering on-line merchandise, comprising: (a) establishing an on-line session with a user; (b) presenting a selection of merchandise for the user to select a product;

(c) receiving the product selected by the user;

(d) presenting configuration options of the product to the user for selecting the options to customize the product;

(e) receiving selections of the configuration options from the user; (f) presenting further configuration options based on the selection received and receiving further selections until customization is completed; and

(g) receiving an order for the product as customized from the user.

2. The method of claim 1 , wherein the further configuration options are limited by constraints due to the selections.

3. The method of claim 1 , wherein the product is presented visually to the user as each of the configuration options is selected.

4. An apparatus for ordering on-line merchandise, comprising a connection to a communication system for communicating with a user; and an application server connected over the connection to the communication system for establishing an on-line session with the user, presenting a selection of merchandise for the user to select a product, receiving the product selected by the user, presenting configuration options of the product to the user for selecting the options to customize the product, receiving selections of the configuration options from the user, presenting further configuration options based on the selection received and receiving further selections until customization is completed, and receiving an order for the product as customized from the user.

5. The apparatus of claim 4, wherein the further configuration options are limited by constraints due the selections and the further selection

6. The apparatus of claim 5, wherein the product is presented visually to the user as each of the configuration options is selected.

7. A digital bill of goods to fulfill an order for customized merchandise, comprising a documentation means for producing documents to facilitate manufacture of the merchandise at each stage of a supply chain; a repository means for providing instructions to assist with fulfillment of the order; and an update means for receiving messages to update the status of the order.

8. The digital bill of goods of claim 7, wherein the documentation means, the repository means, and the update means are generated as an XML object.

9. The digital bill of goods of claim 7, wherein the instructions further comprises instructions on how to manufacture the merchandise with geographic constraints.

10. The digital bill of goods of claim 7, further comprising a translation means for translating the documents, the instructions, the messages, and the status of the order to the language of a party accessing the digital bill of goods.