Unit effectivity
You can use unit effectivity to engineer exceptions or as a simple configurator (light product configurator).
Engineering of exceptions
In most situations, one standard product configuration exists for a product. In this context, a configuration is the total set of data related to the product, which includes the BOM, routing, routing operations, and so on. This standard configuration is planned and sold to customers, without changing the configuration.
However, many companies sell products in slightly different configurations. For all the various products, the same item code is used. If you define a separate item code for all configurations, too many items and related data must be stored.
In LN, you can use unit effectivity to define exceptions to the standard configuration without the need to define separate items. To define exceptions of the standard configuration, units are used. Every unit represents a separate configuration of the same item. The unit indicates differences in product structure, routing, or other data.
The following example illustrates the standard product structure of a conveyer belt:
If a customer purchases the standard configuration of the conveyer, you must enter an effectivity unit of 0 (zero) on the sales order line. Some customers, however, require an extra thick belt. Others want to have a different length. For those exceptions, units are defined in LN.
For example, unit 1 represents a product structure for the conveyer with a long belt. Unit 2 is the conveyer that consists of a thick belt. You can specify configurations on the BOM line by means of exceptions.
In the example, exceptions are linked to the BOM lines of the conveyer. The BOM lines are therefore, unit effective. Other unit effective entities include, for example, routings and routing operations.
The definition of exceptions is not only restricted to data directly related to the top-level item. An exception represented by unit 1 or 2 can be linked to any unit effective entity. As a result, unit effectivity works multilevel.
In the following example, unit 3 is defined to specify a configuration with a 220V engine. Unit 3 is linked to a component on a lower BOM level:
In the same way as described for BOM lines, you can link exceptions to routings, routing operations, and other entities. In the following example, an additional operation is added to the routing of the conveyer for units 1 and 2. If a motor for one of those units is manufactured, one of the operations is replaced by another operation. In case of unit 3, 12 holes must be drilled instead of 10 holes.
At some places in LN, you can enter a unit that must be planned, produced, and purchased. You can specify a unit on a sales order line, production order, and purchase order line. The unit is taken into account during the MRP explosion in Enterprise Planning. A sales order for a unit can result in a purchase order for that unit, even if the unit-effective item is on a lower level in the product structure.
Requirements
An exception is a statement that determines if the entity for which the exception is defined, for example, a BOM line, is valid or not valid for a specific unit. However, a unit-effective entity such as a BOM line and an operation can be valid or invalid for many units. As a result, multiple exceptions must be defined. The number of exceptions can be huge in situations in which many units exist for the end item. For that reason, requirements are introduced. A requirement is a collection of units, for which an exception can be defined. Therefore, rather than define and link multiple exceptions for every unit separately, you can create a requirement consisting of all units, and define only one exception for that unit.
The term requirement is used because all units that are combined together are introduced for the same requirement.
In the example, you can define the following (customer) requirements:
- LB: Long Belt
- TB: Thick belt
- 220: 220V engine.
Now, in the example, you define exceptions for requirements, rather than define exceptions for units.
The units in the example are linked to the requirements as follows:
| Requirement | Units |
|---|---|
| LB | 1 |
| TB | 2 |
| 220 | 3 |
Next, you must define unit 4. Unit 4 represents the requirements Long Belt and 220V. Unit 5 represents the requirements Thick Belt and 220V.
The following table lists all units:
| Requirement | Units |
|---|---|
| LB | 1,4 |
| TB | 2,5 |
| 220 | 3,4,5 |
In the following figure, the requirements are linked to the BOM lines:
Light product configurator
You can use unit effectivity as a very simple configurator. In some situations, the PCF configurator in Manufacturing is too extensive to use: generic items, features, options, and constraints must be introduced, which requires a lot of work.
If the PCF product configurator is used, a unique number is generated for every configuration. This number is called the product variant.
To use unit effectivity as a configurator, you must select the Generate Effectivity Unit during Demand Entry check box in the Unit Effectivity Parameters (tcuef0100s000) session. If you now enter a sales order line for a unit-effective item, LN generates a new unit. The unit number identifies the configuration in LN. From the sales order line, you can start the configuration process for the generated unit. This configuration process contains the selection of relevant requirements for the item.
Example
Suppose you use unit effectivity as a configurator in the previous example. In that case, you must enter the unit-effective conveyer on the sales order line. A new effectivity unit is generated, for example, 15. After that, you must select the requirements for unit 15.
At the start of the configuration, no requirements are linked to the unit yet:
|
Item: CONVEYER Unit 15 |
|
| - | - |
| - | - |
During the configuration process, you can select units. You can also retrieve a list of default requirements: the requirements that are most often used. After that, you can adjust the default list.
At the end of the configuration process, the requirements are selected:
|
Item: CONVEYER Unit 15 |
|
| LB | Long Belt |
| 220 | 220 V |
The result of the linking process is that unit 15 belongs to requirements LB and 220.
The following table presents an overview of all units that are linked to the requirements, including the previous example:
| Requirement | Units |
|---|---|
| LB | 1,4,15 |
| TB | 2,5 |
| 220 | 3,4,5,15 |
Because the unit is linked to a requirement, all exceptions that are applicable to the requirement are applicable to the unit that was generated. As a result, the correct BOM lines and operations are selected.
Pegging
Unit effectivity provides multilevel pegging functionality. On the sales order line with a unit effective item, you can generate a unit number that is unique to the sales order line. The description of the unit consists of the sales order number and sales order line position. MRP explodes the unit to all levels underneath the item of the sales order line. You can view this unit at all levels in inventory. The unit is stored for production, warehouse, purchase, and service orders. As a result, at all levels, and at many places, a peg exists to the sales order.
The following figure illustrates the pegging concept:
You can view a pegging report. The report displays all orders that are related to a specific unit.
Interchangeability
Inventory for various units of the same item can be interchangeable. MRP explodes the top-level unit to lower levels of the BOM structure. Without interchangeability, you can use only inventory of the requested unit. In the previous example, unit 15 would then be requested at all levels below the conveyer. You can, however, determine interchangeability between items and units.
Suppose that in the previous example item units of the item MOTOR are interchangeable. At the requirement date of MOTOR, unit 15 is not available. However, another unit, unit 16, is available. Instead of unit 15, you can use unit 16 because the units of item MOTOR are interchangeable.
MRP automatically uses interchangeable units if the required units are not in place, and redundant inventory of interchangeable unit exists.
Interchangeability is also used in warehousing. If a required unit is not available, the interchangeability settings are used to check if a different unit can be used.
Sameness
Some levels of product structures are the same for different units. In the previous example, the BOM and routing of the conveyer belt are the same for unit 1 and 4. As a result, unit 1 and 4 of the conveyer can be combined into one production order. For example, a production order with quantity 2 can consist of one item for unit 1 and one item for unit 4.
MRP checks the sameness of units during explosion. If the BOM and routing of an item are the same for different units, and if requirements exist for those units, MRP combines those units, and generates one order with multiple order lines for different units. Note that standard MRP logic, for example, a specific order interval, or a maximum order quantity, is also taken into account to generate the order.
For a production order, you can view all units in the order distribution. You can start the order distribution from the production order header.
Standard cost calculation
For every item, you can calculate a standard cost by unit. You can calculate a standard cost as soon as a unit exists for the item. As a result, you can calculate the standard cost at an early stage. If you use the unit effectivity concept as product configurator, you can also calculate the standard cost when the unit is generated.
The standard cost is provided for information purposes, and cannot be used as standard cost. The standard costs for units are not used in estimated cost- price calculations in JSC and PCS.