Action Logs in Manufacturing

Outcome

Understanding action logs in manufacturing can help you when working with planning related manufacturing in M3 BE and external planning systems, such as M3 Planning Workbench and M3 Assortment Replenishment Planner.

What is an action log?

An action log is a log containing either of the following:

Decisions that were made in an external planning system (such as M3 Planning Workbench and M3 Assortment Replenishment Planner) and that should be implemented in M3 BE.
Problems identified in the planning system that must be solved in M3 BE.

Examples of decisions are to split a macro order or change a planning date. Problems that need to be solved can refer to an overload of demand for a certain item.

Purpose

The action log is used as the communication channel between an external planning system (such as M3 Planning Workbench and M3 Assortment Replenishment Planner) and M3 BE.

Benefits

The advantages of using action logs include:

By only transferring the decisions that are made in the external planning system, and not the actual orders, supply chains, and so on, the data volumes to be transferred are kept to a minimum.
By storing the decisions in a specific log, a planning history is available when you need it for reference purposes. You will have a clear picture of which data in M3 BE is actually changed based on a decision in the external planning system, and which decisions were not implemented.
Since all valid decisions are defined in a separate function, it is easy to define new decisions whenever needed.
Action logs facilitate the steps that must be performed manually in M3 BE (to reflect decisions made in the external system) by pinpointing what must be done.
The use of statuses enables a life cycle for the decisions. The life cycle stretches from when the decision is made until it has been implemented in M3 BE. It is possible to transfer unimplemented decisions back to the external planning system, thereby letting them affect the new planning session.

Use

The action log is used in the following cases:

When a planning session was performed in the external system and the decisions are transferred to M3 BE
When new data is transferred from M3 BE to the external planning system to be used as a basis for a new planning session.

All communication related to the action log is done through API transactions, using the API CMS050MI.

The building blocks of an action log

The action log consists of:

Action Log Header
The action log header is automatically created by the API transaction CreateHeader in API CMS050MI. This transaction is used when you export the planning decisions from the external system to M3 BE. Normally, one action log is created for each planning session.

The action log header contains general information. This includes who is responsible for the log, the external system from which it originates, when the transfer was made, a general log status, and the number of actions that the log contains.

The action log is displayed in 'Action Log. Open' (CMS050).
Actions
A decision made in the planning session is stored in the form of one or more actions. The action equals a change or an activity that must be performed in M3 BE in order to execute the decision.
- Defined Actions and Open Actions
  There are two main kinds of actions, defined actions and open actions:
  - Defined actions. A defined action includes rules about which record to change in M3 BE, how to perform the change, and which new data the record should receive. Examples of defined actions are splitting or rescheduling a macro order, moving a single order to a new macro order, and changing or closing a demand order.
  - Open actions. An open action indicates a problem that must be solved, but does not include any rules on how to do this. These problems are complex and can be solved in different ways. Examples are when there is a material shortage, when a warehouse customer order line must be changed, or when a work center has insufficient capacity to manufacture an item. In this last case, the capacity problem might be solved by adding an extra shift, outsourcing the production, or delaying the demand.
- Action Information
  Each action contains the following information:
  - The sequence number, decision date/time, and suffix controlling when it will be implemented in M3 BE related to the other actions.
  - Whether it will be implemented automatically or must be manually processed. Note that open actions can only be implemented manually.
  - An error message, in cases where the automatic implementation of the action failed. The error messages shortly describe the first error that occurred during the implementation.
  - The type of decision from which the action originates.
  - A reference to the decision in the external system.
  - Whether the action is regarded as a main action or a sub-action, in cases where several actions were generated from the same decision.
  - The keys used to identify which record in M3 BE should be changed, as well as which new values the records will receive. This information is displayed on the F panel in 'Actions. Open' (CMS051).
Detailed Messages
If the implementation of an action fails, detailed messages for every error are created in 'Detailed Mail Messages. Open' (CMS109), which is accessed from the action log in 'Action Log. Open' (CMS050).

Implementation sequence

When they are exported, all created actions are assigned a sequence number that corresponds to the order in which the decisions were made. The automatic implementation is carried out in the same order in which the decisions were made. This ensures that the actions are not implemented in an incorrect order, for example, that an order is not moved to a new macro order before the new macro order is created.

The order sequence is controlled by the decision date, decision time, and suffix for the action. All these values are set automatically by the external system when the actions are created. The suffix is only used if actions were created at the exact same date and time.

Implementation rules in action type

The action type that is connected to each action controls how the implementation is performed.

Note that the action types are predefined. They are displayed in 'Action Type. Open' (CMS109). It is not possible to change the function that performs the actual implementation. However, it is possible to make other changes, such as whether or not the actions should be automatically implemented.

Implementation Method

The implementation method controls whether the action should be implemented automatically in M3 BE or manually.

Normally, defined actions are implemented automatically. Open actions must always be implemented manually.

Implementation Function

If the action is automatically implemented, this is the function that performs the implementation.

Implementation Error Control

The error control determines what happens if the automatic implementation of an action fails. There are three valid alternatives:

Stop implementation.
Stop implementation for all actions that are related to the same decision, but continue with next unrelated action.
Continue with next action, regardless of whether it is connected to the action that failed.

Normally, this field is always set to stop implementing all actions that are related to the same decision. A practical example of why this is normally the recommended alternative is the decision to split a macro order. This decision consists of the action to create a new macro order and actions for moving existing orders to the newly created macro order. If the action to create a new macro order fails, the actions to move orders should not be implemented since they will also result in errors.

Decision information in actions

Some fields displayed for the action in 'Actions. Open' (CMS051) can be useful when working with the implementation. These fields are 'Decision type', 'Decision reference' and 'Decision reference type'.

Decision Type
The decision type indicates the type of decision that generated the action. The decision type together with the specified originating system control what the action will do.
Decision Reference
The decision reference is a unique ID that refers to the decision that was made in the external system and that generated the action. One decision can generate several actions.
Decision Reference Type
If a decision made in the external system generated several actions, the decision reference type is used to group these actions into main actions and sub-actions. A main action (for example to split a macro order) is usually defined to always be implemented, while a sub-action (for example to move an order to a new macro order) is usually defined not to be implemented if the implementation of the main action failed. Refer to 'Implementation Error Control' above.

Defined actions for M3 Planning Workbench

Reschedule Date – Macro Order (RESCHDATEH)
Reschedule all supply chains and/or orders connected to the macro order, to a new planning date and time that have been set in M3 Planning Workbench.

This action is used when the manufacturing cannot take place at the scheduled time for different reasons.
Reschedule Date – Macro Order Operations (RESCHDATEO)
Reschedule the pin-pointed operation to the planning date and time that have been set in M3 Planning Workbench. This applies for all operations on the supply chains and/or orders that are aggregated into the indicated macro order operation.

This action is used when the operation cannot be performed at the scheduled time, for example if the work center performing the work is fully booked.
Split Macro Order (SPLITMACRO)
Create a new macro order header. This is done by copying the existing macro order header to create a new header. The new header will be identical to the existing one, except for the bucket start and stop.

This action is used when the macro order data is too large to be used as an entity when planning, or when there is a capacity problem. The action is used as a main action together with the sub-action 'Move order to new macro order' (MOVEORDER).
Move Order to New Macro Order (MOVEORDER)
Move a supply chain or order from one existing macro order to a new macro order.

This action is used as a sub-action to the main action 'Split macro order'.
Sequence Status/Forced Start for Macro Order Operation (OPRSTATUS)
Change the sequence status and forced start date/time for the macro order operation in M3 Planning Workbench.

This action is used together with the main action 'Reschedule date on macro order operations' (RESCHDATEO).
Change Work Center Type 1 (CHGWC1)
Change the resource (work center type 1) for the indicated operation to the resource (work center type 1) that has been set in M3 Planning Workbench. This applies for all operations on the supply chains and/or orders that are aggregated into the indicated macro order operation.

This action is used when the work center that was originally planned to perform the work cannot do it, for example due to overload.

Open actions for M3 Planning Workbench

Allow Overload on Work Center Type 1 (ALLOEOVRL)
Problem: There is overload at the work center, and so the manufacturing demand cannot be met.

Possible solutions: Move supply chains and/or orders (thereby delaying the demand), add extra shifts for the work center to increase the capacity, or outsource the manufacture of the item.
Allow Material Shortage (ALLOWSHORT)
Problem: There is a material shortage when an item is manufactured.

Possible solutions: Move supply chain and/or orders (thereby delaying the demand), or ask the delivering company to send the required material earlier than planned.
Change Warehouse – Customer Order Line (CHGCOLWHS)
Problem: The warehouse on the customer order lines must be changed, since the goods will be delivered from another warehouse than originally planned.

Solution: Manually change the warehouse on the customer order lines.
Change Warehouse – Purchase Order Line (CHGPOLWHS)
Problem: The warehouse on the purchase order lines must be changed, since goods receipt will take place at another warehouse than originally planned.

Solution: Manually change the warehouse on the customer order lines.
Split Macro Order Quantity (QTYSPLITM)
Problem: The quantity on the macro order is too large to be managed as an entity when planning.

Solution: Split the quantity and possibly create a new macro order. Manufacturing can then take place at different times and possibly at different work centers.

Defined actions for M3 Assortment Replenishment Planner (M3 ARP)

Create Demand Order (CRTDEO)
Create a demand order and possibly, depending on the settings on the valid demand order type, automatically create a supply order.

This action is used when a buy plan (meeting a purchase need) has been created in M3 Assortment Replenishment Planner (M3 ARP) as the result of a planning session.
Change Demand Order (CHGDEO)
Delete the supply proposals connected to the demand order, as long as the demand order is not connected to any released supply orders or agreement.

If the demand order has such a connection, then the action will not be implemented. The user must then manually update the released supply order in M3 BE.
Close Demand Order (CLSDEO)
Close the demand order by setting the status to 90 (Closed). Before you can do this, the demand order must already have status 80 (Finished).

This action is used when you no longer want the demand order to appear in the statistics.
Delete Demand Order (DLTDEO)
Delete the demand order and all related supply proposals, as long as the demand order is not connected to any released supply orders or agreements.

If the demand order has such a connection, then the action will not be implemented. The user must then manually close the demand order and possibly delete the released supply orders in M3 BE.

Defined actions for M3 Infor Advanced Scheduler (M3 IAS)

Create Manufacturing Order (CRTMO)
Creates manufacturing orders according to key field values specified. The key fields are based on required input in creating manufacturing orders.
This action has the implementation method set to 2-‘Automatic’ by default which triggers creation of MO upon implementation.
The action can be used in combination with a REPWC action type to implement work center replacements on the manufacturing orders to be created. The key fields 'External Reference Number' (EXRN) and' External Reference Description' (EXD2) are used to relate the corresponding REPWC actions.
Replace Work Center (REPWC)
This action is used to replace work centers on manufacturing orders during implementation.
The action uses implementation method 3-‘Auto - Dependent’ which is dependent on an action type using method 2-‘Automatic’, such as CRTMO. It is only implemented if a corresponding automatic action type has the same key fields 'External Reference ID' (EXRN) and 'External Reference Description' (EXD2) specified. Otherwise, the REPWC action cannot be implemented.

Defined actions for M3 BE manufacturing using reverse bill of materials (M3 STD)

Create Manufacturing Order (CRTMO)
Creates manufacturing orders for the process items according to key field values specified. The key fields are based on required input in creating manufacturing orders.
This action has the implementation method set to 2-‘Automatic’ by default which triggers creation of MO upon implementation.
Input fields to the transaction are:
- KR01 = Company (mandatory)
- KR02 = Facility (mandatory)
- KR03 = Product (mandatory)
- KR04 = Structure type (mandatory)
- KR05 = Quantity (mandatory)
- KR06 = Status (mandatory)
- KR07 = Start date
- KR08 = Start time
- KR09 = Finish date
- KR10 = Finish time
- KR11 = Explosion
- KR12 = Responsible (mandatory)
- KR13 = Warehouse (mandatory)
- KR14 = Order type (mandatory)
- KR15 = Project
- KR16 = Production line
- KR17 = Lot number
- KR18 = Priority
- KR19 = Project element
- KR20 = Schedule number
- KR21 = Manufacturing U/M (mandatory)
- KR22 = Alternate routing
- KR23 = Manual expiration date
- KR24 = Process
- KR25 = Location
- KR26 = Process code
- KR27 = User
- KR28 = Manual reclassification time
- KR29 = External reference number
Either start date or finish date must be specified.
This action can be used in combination with a CRTENDMO action type to implement creation of process orders where a specific set of end product manufacturing orders need to be created.
Once the transaction is created using CRTMO it can be implemented (transaction IMPLEMENT). Then the manufacturing order is created with all default end items associated to the process item in 'Product. Update End Products' (PDS021).
Create End product Manufacturing Order (CRTENDMO)
This action is used to provide details on what specific end-products to be connected to a process manufacturing order. This action also overrides the creation of the standard end product orders based on the product structure. Only those manufacturing orders will be created for end products specified through this action.
The key fields required are as follows:
- KR01 = Company
- KR02 = Facility
- KR03 = End product
- KR04 = Quantity
- KR05 = Unit of measure
- KR06 = Cost percentage (optional)
All fields except the cost percentage are mandatory in this transaction.
Once manufacturing order (process items) and end items have been specified, use transaction Implement to trigger creation of orders. It is essential that the CRTMO be specified first in the sequence after which CRTENDMO transactions can be specified. For example, to create a process manufacturing order with two end items, first perform a CreateLines transaction with the CRTMO Action type, then add two CreateLines transactions with the CRTENDMO action type. If all validations pass, the Implement transaction creates the parent and two end item manufacturing orders.