This document explains the concept of action logs in M3 Manufacturing Operations and M3 Supply Chain Planning, as well as how the actions in the log are implemented in M3 Business Engine (BE). The document also contains a list with all actions available in the current version of the system.
Understanding action logs in manufacturing can help you working with planning related manufacturing in M3 BE and external planning systems, such as M3 Planning Workbench and M3 Assortment Replenishment Planner.
An action log is a log containing either of the following:
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.
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.
The advantages of using action logs include:
The action log is used in the following cases:
All communication related to the action log is done through API transactions, via the API program CMS051MI.
The action log consists of:
The action log header is automatically created by the API transaction 'Create header' in API program CMS051MI. 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).
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.
There are two main kinds of actions, defined actions and open actions:
Each action contains the following information:
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).
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.
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.
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.
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:
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.
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'.
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.
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.
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 subactions. A main action (for example to split a macro order) is usually defined to always be implemented, while a subaction (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.
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 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.
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 subaction '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 subaction to the main action 'Split macro order'.
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 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.
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.
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.
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.
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.
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.
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.
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 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 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.