Action Logs in Manufacturing

Outcome

Understanding action logs in manufacturing can help you when working with planning related manufacturing in M3 BE and M3Planning Workbench.

What is an action log?

An action log is a log that contains either of these components:

• Decisions that were made in an external planning system, such as M3 Planning Workbench, that must 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 M3 Planning Workbench and M3 BE.

Benefits

You can use the action log in these cases:

• Transferring only the decisions made in the external planning system, instead of the actual orders and supply chains, minimizes the volume of data that needs to be transferred.
• 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 manual steps that you must perform in M3 BE to reflect decisions made in the external system.
• 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

You can use the action log in these cases:

• When a planning session occurs in the external system, and the decisions are transferred to M3BE.
• When new data is transferred from M3 BE to the external planning system to serve as a basis for a new planning session.

All communication related to the action log is performed 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 this 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. These are the 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

In 'Actions. Open' (CMS051), these fields are displayed, which are useful when working with the implementation:

• 'Decision Type': The decision type indicates the type of decision that generated the action. The decision type and the originating system determine the action.
• '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': When a decision in the external system generates multiple actions, the type of decision references groups these actions into main actions and sub-actions. A main action, such as splitting a macro order, is defined to always be implemented. On the other hand, a sub-action, such as moving an order to a new macro order, is defined as unimplemented if the implementation of the main action failed.

  See Implementation Error Control

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 by copying the existing macro order header. The new header is 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 Infor Advanced Scheduler (M3 IAS)

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

  Specify either the start date or the finish date.

  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.

  These are the required fields:

  • 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.

  Specify the end items and the manufacturing order for the process item. Then, use the implement transaction to trigger the 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.

Other defined sections