- App Store
The Assemble to Order (ATO) Configurator is functionality integrated in the 3.0 and higher releases of xTuple applications in all editions of xTuple ERP. It is designed to facilitate scenarios where goods or services are sold in which attributes about a particular product may change from one sale to another, and where these attributes can affect Bill of Materials, Costing and Pricing. For products, the ATO Configurator is designed to leverage the capabilities of the Manufactured Item Type which is designed for make-to-order environments. The Reference Item Type may also be used for configuration in scenarios where materials and cost are not tracked, but users want to be able configure the pricing of an item sold based on attributes.
The ATO Configurator is best used in conjunction with Items which use the Job Costing method. In that case, the cost of the work accumulated on a Work Order for the configured Item is passed directly to Cost of Sales in the General Ledger--and to the sales history table (found in sales analysis reports, api.saleshistory view or cohist table) for accurate margin reporting. Note that with Job Costing the act of issuing to shipping simultaneously posts production on the Work Order and issues the Item(s) to shipping which is what ensures the cost flows directly to the associated Sales Order. Job Cost Items cannot be put into inventory.
If your configuration options don't have a bearing on cost, then the Average Cost method can be made to work. In this case, you would do your reporting off sales history as described above. Just be aware that if you do this you lose the one-for-one relationship of the cost of work to the sale because Inventory doesn't know the differences between one Item and another. In other words, when you look at your Inventory you'd see you have X quantity on hand but have no idea what configurations X quantity represents. If you must track these things in Inventory, the standard advice in that situation is to create a new Item number for each configuration.
This topic assumes the user has an understanding of the following xTupleERP concepts:
Bill of Materials
Configuration starts at the Item window. Items with type of Manufactured or Reference may be flagged as Configured. Characteristics on configured items may have a price associated with them. Advanced characteristic pricing for configured items is also supported by Pricing Schedules. Associations between Characteristics and Bill of Material Items may be defined for configured Manufactured Items such that a Bill of Material Item is only used when a specific Characteristic value is selected on a Sales Order.
Sales Order line items will recognize and treat configured items differently than other items. If applicable, changes in characteristic selections will affect the pricing and pending availability listings. When a Work Order for a configured line item is exploded, materials added to the Work Order are based on characteristic selection for the line item. After Work Order explosion, Characteristics on the Sales Order line item may no longer be edited unless the Work Order is imploded. Configured items behave in the Manufacturing, Shipping and Billing cycles the same way non configured Manufactured and Reference Items behave.
The Item maintenance window includes a "Configured" check box that is enabled when the Item Type selected is either "Manufactured" or "Reference."
The limitation of Item Types means that configured items may not be stored or tracked in inventory. This limitation exists because as of this writing it would not be possible to distinguish the difference between one item and another for either netting or costing purposes if we were to allow inventory stocking of configured goods. Depending on community involvement, future functionality could be added to allow inventory tracking of configured items by serial number.
When "Configured" is checked, a List Price column becomes visible on the Characteristics tab. Characteristic List Price also appears as an editable field when Characteristics are added or edited for the Item. The normal list price for a configured item will be reflected as the "Base Price" on a Sales Order. Characteristic list prices will be the default prices used when that Characteristic and Value combination are selected on a Sales Order, and will be added to the Base Price to calculate a new Net Unit Price for the Item on the sale.
The usual business logic of characteristic selection values works the same as with any other Item. That means a list of selectable values for Sales can be built by including the same Characteristic multiple times with different values. The Characteristic flagged as "Default" will be the default value on the Sales Order.
Pricing Schedule Item
Pricing of Characteristic Values for Configured Items can also be controlled at a more granular level through Pricing Schedules.
The Pricing Schedule Item screen has a Base tab where over rides to the item list price may be added. For configured items, a Characteristic tab will be enabled that allows over-ride pricing by characteristic to be added. The Sales Order window implements pricing selection logic for Characteristics the same way as Item pricing: the customer receives the lowest price they are eligible for based on Price Schedule assignments and Price Schedule quantity break logic.
Bill of Material Item
Characteristic assignments may be set to affect Bill of Material explosion on Work Orders for configured items. A "Configuration" tab is made visible on the Bill of Material Item window when the parent item is flagged as Configured. To associate a Bill of Material Item with one of its parent's Characteristic values, simply select a Characteristic and value that would be selected on a Sales Order to cause it to be included in the Work Order. The listing of Characteristics and corresponding values on this tab are determined by the Characteristics that have been added to the Parent Item in the Item window.
If no Characteristic information is selected, the Item will be included on all Work Orders.
The Bill of Material Item windows pictured show a set up where YPAINT1 is only included on Work Orders where the parent Sales Order has selected the value Bright Yellow for Characteristic I-COLOR. A separate Bill of Material Item exists for YPAINT2 that specifies it will be only be included if the I-COLOR value selection is Neon Yellow.
Sales Order entry works almost exactly the same way with Configured Items as it does with non-configured Items. The main difference is between how information is calculated and displayed. In the first examples pictured we can see a user is entering an order for a Custom Truck. By default the truck comes with Bright Yellow paint which is identified by the Characteristic Value for I-COLOR being set to Bright Yellow. The Net Unit Price is the item price for CTRUCK1, plus the price of all the Characteristic Values selected. We can see the "Base Price" for the item on the Characteristics tab as $27.00. The price for Bright Yellow paint of $0.90 and the PUSCH Racing Logo of $0.90 is added giving us a total Net Unit Price of $28.80. On the Supply tab when Dependencies is selected we can see Bright Yellow paint (YPAINT1) is listed on the Bill of Materials.
On the following pictures we can see that the user has changed the color selection to Neon Yellow. This changed the characteristic price for I-COLOR to $1.35 which increased the Net Unit Price to $29.25. We can also see on the Supply tab that the Bright Yellow paint has been replaced by Neon Yellow paint.
It is important to note for Manufactured Items that a Work Order will be created when the line item is saved. It is common for users to have xTuple configured to automatically explode Work Orders when they are created, which means that the Bill of Material is copied to the Work Order. Once this happens, the Characteristics on the Sales Order will be set to view only. This is necessary to enforce the integrity of the relationship between the Characteristics on the Sales Order and the Materials on the Work Order. If a user wishes to change Sales Order Characteristic selections on a Sales Order in this state, the Work Order must be manually imploded first. If the Work Order is already in process it will not be possible to implode the Work Order or change Sales Order Characteristics. Any changes to the Work Order at that point would have to be accomplished by manually adding and removing materials through the Work Order Materials window.
If you encounter frequent changes to Sales Order Characteristics on Configured Items before work has begun, it may be best to disable Automatic Work Order explosion so that this is handled manually by the shop floor when they are ready. Automatic Work Order explosion can be enabled and disabled in System > Setup > Module: Manufacture.
Configured Items behave in the Manufacturing, Shipping and Billing Cycles the same way non configured Manufactured and Reference Items behave.
Thu, 07/29/2010 - 05:42#1
The configurator for ATO looks nice but where are the routers? I have used Friedman's ERP system for the past 11 years and their ATO product configurator allowed for routers to vary based on characteristic values. For instance we may route a product to a high speed assy machine for high volume items or based on color (again high volume). Packaging was most frequently used. Packaging could vary and was part of the ATO. Based on packaging selection, we would route the product differently. I see bills and pricing that vary but do not see routers that vary.
Thu, 07/29/2010 - 08:09#2
Yes, your observation that
Yes, your observation that routings are not yet supported is correct. The software is always evolving, usually at the request of our user base. Adding support for ATO to the Bills of Operations would be a logical advancement for the software. Let us know if you are interested in getting behind such an enhancement either via sponsorship or code contribution.
Mon, 08/16/2010 - 09:11#3
The core of our business depends on a similar feature as well. We want to build complicated sales order based only on a few characteristics. For example, assign a color based on a different characteristic (such as model). Depending on cost, we would be interesting in co-sponsoring such a feature. I am here in Norfolk for xTuple classes... will try to talk to someone about it.
Tue, 10/11/2011 - 14:55#4
Item Type : Job
I am using Postooks 3.7.2 and there is no Item type "Job". Is Item Type "Job" available in Postbook 3.7.2. ? I am able to create a configured item if I select "Manufactured" but when I process the Work Order it requires the item to be put into inventory. Is this the only solution?
Thank you, Lynn
Tue, 10/11/2011 - 15:28#5
You can read more about Job Costing in the following document:
You might also be interested in our eBook, "Managing Projects with xTuple" here:
Wed, 10/12/2011 - 13:59#6
Thanks Pierce, what a great document !
Fri, 02/24/2012 - 17:29#7
Item costs are a bit weird here
I have several hundred configured items. Each has a single configurable characteristic, color. Some of the items have up to 32 different colors available. In terms of order entry and work order explosion from the configured bill of materials, and inventory issue, everything works great. The only thing I've just noticed is that if I look at the BOM for one of these items, the rolled up actual cost for the item (we use average costing) includes the cost of all 32 configurable bom-items (at the bom-item's actual cost * the qty-per of the item on the bom). So, in one case I have an item whose list price is $95 but whose actual cost is $340. When that item is ordered or issued, the $340 is stored in the coitem_unitcost or invhist_unitcost field. The $340 is what's returned by the actcost() function for the item. This is making it very difficult to do margin reporting with these items, because I can't use the cost on the coitem record like I can with non-configured items. The only way I can think of to do it is to pull GL transactions for each work order to get the actual COGS for each invoice.
While I've noticed this issue, I can't see a way for the system to determine the rolled up actual cost of the configured item without including all the configurable bom-items, because the system doesn't know which configured components are going to be part of any actual item that's built. I've taken to calculating the total actual cost of the configured components so that I can delete that amount from the value returned by actcost() and then add back an average configured component cost, since the configured components all have about the same actual cost, to come up with a reasonable "actual" actual cost.
I'm posting here to see if anyone else has run into this issue and thought of a different way of handling it then either of the above.
Fri, 02/24/2012 - 19:04#8
You shouldn't use average or
You shouldn't use average or standard cost on configured items unless the configuration has no bearing on cost. In a case like yours it is likely you'll need to use job cost. In that case the cost of the work accumulated on the work order for the item is passed directly to cost of sales on the G/L and to the sales history table (found in sales analysis reports, api.saleshistory view or cohist table) for accurate margin reporting. Note with job costing the act of issuing to shipping simultaneously posts production on the work order and issues the item(s) to shipping which is what ensures the cost flows directly to the associated sales order. Job cost items can not be put into inventory.
If it's true that the your configuration options don't have a bearing on cost then average cost can sort of work. In that case do your reporting off sales history as described above. Just be aware that that if you do this you lose the one for one relationship of the cost of work to the sale because inventory doesn't know the differences between one item and another. That also makes for bad practice in the general sense that when you look at your inventory you'd see you have X quantity on hand but have no idea what configurations X quantity represents. If you must track these things in inventory you're pretty much in a situation where the ATO configuration isn't a viable solution. The standard advice in that situation is to create a new item number for each configuration.
There has long been talk about an Engineer To Order (ETO) configurator that would automatically create item numbers, but so far it's been just that, not enough serious interest to warrant a full development effort.
Fri, 02/24/2012 - 23:14#9
Thanks very much, John
John, I appreciate your feedback, it is very helpful. We do use job cost for the configured items and average cost for the purchased components. What I didn't know until you led me to it was the the cohist table maintains the actual issued cost of the item, so I can use that for my margin reporting as you outlined instead of the slightly crazy alternatives I described above.
Thanks very much for taking the time to outline the process in such a detailed way.