Configuring products at order entry

At its most basic the M3 configurator (PDS600) allows for changing slightly the nature of a product - for example selecting embroidery on a T-Shirt.  At its most complex the configurator can be used to create completely unique products to match customers' requirements.
In the next few weeks I will build a complex product structure in M3, but for today I'll start with the simple example of a T-Shirt that we want to be able to specify the embriodery on at point of order entry.

M3 programs that we make use of when building the configurable T-Shirt are:

• PDS002 - this is where the bill of materials for products is defined, consisting of Material and Operation lines.
• PDS055 - Features are defined here.  These are questions that may be answered when configuring a product.
• PDS050 - The potential answers to the questions asked by features.
  

I'll assume familiarity with MMS001, MMS002, MMS003 and a flat bill of materials in PDS001/2.

The basic BoM we'll start with is as follows:

We have a single material line (5000) which is our black T-Shirt cloth and a single operation line (9000) which is our subcontract manufacture.

What we're now going to do is add two embroidery options as additional material lines:

We now have two additional materials YB1050-59 and YB1362-89 which are the two embroidery options we are offering on this T-Shirt.  However, if we take an order for this item now we will not be prompted for which embroidery option we want and the resultant BoM in PMS100 will include both items.  To address this we have to add questions to the material lines 5001 and 5002.

Firstly we set up the possible options in PDS050

We'll now define a feature Embroidery in PDS055 and add the selectable options to it.

On the material lines 5001 and 5002 we then add option to each line

This has the effect of including the material line (5001) only when the answer to the Embroidery question is LOGO-1.  An option on line 5002 for LOGO-2 is also set up.

Once both material lines have had options applied we can see an asterisk on the end of the line in PDS002.  This tells us that the line is optional and its inclusion in the resultant BoM is dependent on (in this case) the answer to a question.

When we now place an order for the item we will be prompted to specify the type of embroidery we want on the T-Shirt.

Note that PDS600 tells us the product structure (TSHIRT1) and line (5001) that the question is being asked on.  This will be very important later on for following branching product structures.

We select the embroidery option we want (LOGO-2) and then we are returned to OIS101.  Note that while M3 also processes the question on line 5002, we are not prompted to provide an answer as the features specified on 5001 and 5002 are the same, so the answer we supplied for line 5001 will also be applied to line 5002.

From the order line we can examine the Options/Config to see the answer that has been stored against the feature embroidery feature EMBR

Finally when we look at the the associated manufacturing order in PMS100 we can see that only the BoM line we associated with the answer LOGO-2 is included in the resultant BoM.

In later posts I'll show how we can specify default answers to questions, create branching product structures and make use of formulas to adjust operation costs based on answers to questions.

Managing master data mapping between disparate systems with CRS881

I've recently rediscovered CRS881which is M3's tool to manage the mapping of master data between disparate systems.  The example shown here is a map between a POS system and a cost centre in M3 - when we see the POS branch ID 1 we want to post the transactions to cost centre 101 and so forth.

The process to create a CRS881 map is not obvious as the Create function in the M3 interface is greyed out.  Rather you need to use the API CRS881MI.AddTranslation call.

From there you can add your mapping information using the M3 client.

While Lawson's MeC tool can access the CRS881 information natively I've recently been using SQL to access this data for interfaces that bypass MeC (e.g. GLS850) - essentially using M3 as a convenient repository for the mapping data and moving it out of the interface code.  The SQL tables where the CRS881 information are stored are as follows:

--CRS881 Headers   
select * from MBMTRN

--CRS881 Details
select * from MBMTRD

I'm now working back through our old interfaces moving the (hard coded!) business logic into CRS881 so end users can manage this data.  I'm also beginning to think of ways of (mis)using this program to store data we use for (for example) data warehouse aggregations that are not specified within item / customer master data etc.