Quality Management System (QMS) and Its Impact on Manufacturing Order Processing

Outcome

There is a function program (QMS701Fnc) that auto-attaches a specification for the MO output. See the detailed description of the QMS701Fnc program in Auto-attaching Specifications to Orders.

A manufactured item can inherit some specifications from one of its component items. The setup for this inheritance is explained in Inheriting Specifications. As a prerequisite to auto-attaching specifications to the output of an MO, there is a system check to see if there is an item from which specifications have to be inherited.

Another function program (QMS800Fnc) handles the output reporting of both lot controlled and non-lot controlled items.

Based on the MO type and other QMS-related settings including the Quality plan, in the event of incremental quantities being reported of the by-product output, or in the event of newly added output being reported, a new QI request is created or an existing QI request is updated with new sequences for the quality tests in question.

The system refers to the setting of the QI request timing (QIRT) field on the MO type to determine when to generate the QI request (either on release of the order or on reporting output).

Logic for creation of QI requests added upon MO creation

The QI request timing is handled the same way, regardless of whether the MO has a single primary output or has a primary output, co-products and/or by-products. Since the primary product, co-product, and by-product can all be quality controlled and have their own specifications, the QI requests must be made for each output. The system checks through all outputs for a given MO to ensure that the QI requests are generated properly.

A QI request is created for any lot coming from an MO regardless of the assigned MO type. There may be cases where a new lot number is created for an MO which previously had been reported under a different lot number. As such, when any balance ID record is created for a new lot number from an MO, a corresponding QI request is created. If a QI request already exists as a result of an MO release, it will not be replaced.

On 'Manufacturing Order. Open' (PMS100/B), select Related > QI Requests to view the QI requests that have been created for the given MO.

Logic for creation of QI requests added upon MO report receipt

After the product and MO number are specified in 'Manufacturing Order. Report Receipt' (PMS050), the Received quantity value is specified on the E panel. After specifying the lot, received quantity, and location, the system starts the QMS800Fnc function program to create the QI request for the primary output. Upon clicking the Next button, the system validates each test based on its frequency to generate the test sequence.

The system refers to the 'Quality Plan. Open' (QMS009) program, specifically the setting of 'Replace MO QI request' (QIPF) field, to determine how to process any subsequent inventory receipts of a quality-inspected item for a MO. The default selection in the 'Replace MO QI request' field is 2-'Use different location' where each receipt is processed in a different location with a new QI request until such time that the balance identities of the receipts allow the lots to be reclassified into the same location. See Quality Approval Rules and Process for an explanation of each setting option for the 'Replace MO QI request' field on the Quality plan.

In addition, these scenarios describe the processing of QI requests for MO inventory receipts based on the Replace MO QI Request (QIPF) setting:

The Replace MO QI Request (QIPF) field is set to 0-'Use the last QI request created' and the QI request is approved:

• Upon receipt of report in 'Manufacturing Order. Report Receipt’ (PMS050), the system proceeds to receive the inventory. The QI request for balance ID (warehouse/item/lot/location/container) created for this MO remains the same. The new receipt inherits the test results from the previous receipt. The lot status of the balance ID remains unchanged. Inventory merges into the existing lot/location. No additional quality testing for the new receipt is performed.

The Replace MO QI Request (QIPF) field is set to 0-'Use the last QI request created' and the QI request is rejected:

• Upon receipt of report in 'Manufacturing Order. Report Receipt' (PMS050), the system proceeds to receive the inventory. The QI request for balance ID (warehouse/item/lot/location/container) created for this MO remains the same. Because the status is 'Rejected', the QI request origin changes to 1-'Retest of lot' at the balance ID level during the put-away process in'Quality-inspected Item. Put away' (PMS130). For all subsequent receipts, the QI request for the balance ID created for this MO requires a retest. In addition, the system enables the Reset from standard check box on the E panel of 'QI Request. Open' (QMS300).

The Replace MO QI Request (QIPF) field is set to 1-'Manually reclassify lot' and the QI request is approved:

• Upon receipt of report in 'Manufacturing Order. Report Receipt' (PMS050), the system prevents the receipt and provides a warning message that the existing lot should be reclassified to 'Under inspection' to merge inventory for MO receipts. The system automatically navigates to 'Balance Identity. Reclassify' (MMS130). Using this program, update the status of the existing balance ID for the item being received to 'Under inspection.' Once the status of the balance ID for the item has been updated accordingly, return to 'Manufact Order. Report Receipt' (PMS050) to report the MO receipt.

The Replace MO QI Request (QIPF) field is set to 1-'Manually reclassify lot' and the QI request is rejected:

• Upon receipt of report in 'Manufacturing Order. Report Receipt' (PMS050), the system prevents the receipt and provides a warning message explaining that the existing lot must be reclassified to 'Under inspection' to merge inventory for MO receipts. Because the status is 'Rejected', the QI request origin changes to 1-'Retest of lot' at the balance ID level during the put-away process in 'Quality-inspected Item. Put away' (PMS130). For all subsequent receipts, the QI request for the balance ID created for this MO will require a retest. In addition, the system enables the Reset from standard check box on the E panel of 'QI Request. Open' (QMS300). For each receipt, the system automatically navigates to 'Balance Identity. Reclassify' (MMS130). Using this program, you must update the status of the existing balance ID for the item being received to 'Under inspection.' Once the status of the balance ID for the item has been updated accordingly, return to (PMS050) to report the MO receipt.

The Replace MO QI Request (QIPF) field is set to 2-'Use different location' and the QI request is approved:

• This option prevents the receipt and prompts an error message indicating that the balance ID specified already exists with either an approved or rejected status. The receipt is not allowed because the balance ID in the inventory and the current item being received have different statuses. Thus, you must receive the new receipt quantity in a separate location to create a different balance ID. Once the new receipt has been inspected and test results have been reported, the lot can be approved or rejected. The lot must be reclassified manually when both receipts have the same status in order to merge the inventory for MO receipts.

The Replace MO QI Request (QIPF) field is set to 2-'Use different location' and the QI request is rejected:

• This option prevents the receipt and prompts an error message indicating that the balance ID specified already exists with either an approved or rejected status. The receipt is not allowed, as the balance ID in the inventory and the current item being received have different statuses. Because the status is 'Rejected', the QI request origin changes to 1-'Retest of lot' at the balance ID level during the put-away process in 'Quality-inspected Item. Put away' (PMS130). For all subsequent receipts, the QI request for the balance ID created for this MO requires a retest. In addition, the system enables the Reset from standard check box on the E panel of 'QI Request. Open' (QMS300). After the new receipt has been inspected and test results have been reported, the lot can be approved or rejected. The lot must be reclassified manually once both receipts have the same status.
• When the first receipt is rejected, the system performs a stock transfer through 'Movement. Change Location – Item' (MMS175). The QI request Balance ID for the location is updated with the final storage location. The Replace MO QI Request logic is triggered and the QI request ID is retained from one location to another.

Logic for creation of QI requests for output reporting of co-products

Output reporting of co-products requires that the product structure is set up to include a co-product. Based on the MO type and other settings including the Quality plan, if incremental quantities are reported for the co-product output, either a new QI request is created or an existing QI request is updated with new sequences for the quality tests in question.

Aging setup for manufactured items

To allow for scenarios where the default aging time must be changed during manufacturing, the MO must be created with a type that has the Aging parameter (AGIG) in the MO type (hyperlink to (PMS120)) set to 2-‘Dynamic aging'.

For such an MO, a manual reclass date (MREC) and time (MRCT) can be specified upon MO creation. A default of either now (if item has no aging parameters) or an aging date and time based on the aging parameters in the warehouse where the MO is received is populated. This date and time can be updated on the MO until the first receipt of a lot for that MO.

Upon MO receipt, the manual reclass date and time is saved on the corresponding Lot master record (MILOMA) as the planned reclass date and time. Through the putaway program 'Quality-Inspected Item. Put-away' (PMS130), the reclass date and time are extended or changed to a value before 'now' for an item-lot manufactured through an MO that is created with an MO type with dynamic aging. If the reclass date and time are changed, the status of the balance ID must remain as 1.

To continuously monitor the aging status of balance identities, there is an autojob mechanism with the purpose of polling the items' reclassification dates and updating their status as the items complete the aging process. In 'Subsystem Job. Open' (MMS975), the Subsystem is 'ASJ' with the Job name of (MMS975). The default delay for this job is 180 seconds.

It is important to note that, depending on the Inspection code and whether the aging parameters have been defined for a particular manufactured item, the balance identity status of the item is impacted when the item is reported through 'Manufacturing Order. Report Receipt' (PMS050).

• For manufactured items with an Inspection code of 0, when the item is reported, the balance identity of the reported item-lot is approved.
  Note: An exception would be if the MO is being executed with an MO type that includes aging and the manufactured item has non-zero aging parameters set up in 'Item. Connect Warehouse' (MMS002), the resultant balance identity results to 'Under Inspection.' The lot is set to 1-'Under inspection' when reporting through 'Manufacturing Order. Report Receipt' (PMS050). It is then reclassified to status 2-'Approved' by the autojob after the aging time has passed.
• For manufactured items with an Inspection code of 1, when the item is reported, the balance identity of the reported item-lot results to 1-'Under Inspection' status.

  For the autojob to change the status of the balance identity, the status of the corresponding MO should be 90. To achieve this status, the ingredients for the MO should be issued using 'Manufact Order. Report Issue' (PMS060) and all the operations reported using 'MO Operation. Report' (PMS070). The item-lot should be put-away through 'Quality-inspected Item. Put away' (PMS130). When the MO is in status 90 and the aging time has passed, the autojob changes the status of the balance identity to 2-' Approved'.

  Note: You can change the status of the balance identity to be 'Approved' when you use the 'Quality-inspected Item. Put away' (PMS130) program for this item-lot. In this scenario, the Aging logic is disregarded. As a result, the autojob ignores the balance identity because it is already 'Approved.'
• For manufactured items with an Inspection code of '2', when the item is reported, the balance identity of the reported item-lot is set to 1-'Under Inspection' status.

  For the autojob to change the status of the balance identity, the status of the corresponding MO should be 90. To achieve this status, the ingredients for the MO should be issued using 'Manufact Order. Report Issue' (PMS060) and all the operations reported using 'MO Operation. Report' (PMS070). The item-lot should be put-away through 'Quality-inspected Item. Put away' (PMS130). As a result, for this item, a quality request is created on the reporting of output, and an additional condition should be satisfied for the autojob to make an impact. Test results should be specified and the quality request should be in a status of at least 70 for the autojob to take over. When the MO is in status 90, the quality spec status is at least 70 and the aging time has passed, the autojob changes the status of the balance identity to 2-'Approved.'

Aging functionality's impact on QMS logic

As part of the MO processing, if an item has one or more QI requests created, the auto-approval rules dictate the status of the balance identity as the quality test results are specified in 'QI Test Results. Open' (QMS400) for this item and lot combination.

• If the 'QI request timing' (QIRT) field in the Manufacturing Order Type (MWORDT) table has a value of '1' (the QI request is created upon MO release), the result is that no balance ID will be available.
• If 'QI request timing' (QIRT) field on the Manufacturing Order Type has a value of 2 (the QI request is created upon reporting of MO receipt), a balance ID is created with status 1-'Under Inspection.' At this point, the item-lot-quantity or item-quantity can be tested. On the entry of test results and with the logic built for the approval rules, the lot can either be 'Approved' or 'Rejected.'
• Assuming a lot-controlled item has Aging properties enabled, when a lot is approved or rejected due to entry of quality test results, the corresponding lot master (MILOMA) record will have a populated 'Planned reclassification date' (RCLS) field. The auto-approval logic is not started for the corresponding Lot record if 'Planned Reclassification date' is populated.
• If the MO order type supports Dynamic aging (AGIG = 2), the planned reclassification date and time are populated from the MO receipt transaction where the manual reclass date (MREC) and time (MRCT) are populated into the planned reclassification date (RCLS) and time (TIHM), respectively. Each lot can have a unique planned reclass date and time. Thus, multiple lot receipts for a single MO can result in multiple lots, each with its own reclass date and time. The reclass date and time of a lot cannot be updated directly in the lot master.

Before you start

The setup conditions outlined in Managing Quality Control must be met.

Process for adding/updating a QI request

The QMS800Fnc function program has this operation:

• The MOQIReqCreation operation calculates the test frequencies and determines the number of QI requests and test sequences that are necessary based on the item’s Quality plan values.

  Based on the value of the MO test frequency basis in the Item’s Quality plan, 2 alternatives can occur:

  • A new Test Sequence is created on an existing QI Request.
  • A new QI Request is created when a frequency needs to be generated.

Process for deleting QI requests upon deletion of manufacturing orders

Manufacturing orders (MO) are deleted when no transactions are associated with them. The MO is also created for an output that is set up as a quality inspected item in a facility that has QMS enabled. If such an MO is created with an MO type where the QI requests are created on release, then upon deletion of the MO, the corresponding QI requests are also deleted.

As an MO that can be created with a co-product and by-product, both of which can be set up as QMS items, you can have QI requests generated for all of these products. If no transactions have occurred for this MO and the MO is deleted, all QI requests are also deleted.

The DeleteQIReq operation of the QMS300Fnc program is started from the Lot master to delete all the tables associated with a QI request.

API transactions

QI requests related to MO creation and reporting include these API transactions:

• API PDS002MI (Product Structure Interface)
  • AddComponent - This transaction includes the 'Item to inherit from' (INHI) setting which determines if a particular component item will be used as the source of quality specifications for its related manufactured item.
  • UpdComponent - This transaction includes the 'Item to inherit from' (INHI) setting which determines if a particular component item will be used as the source of quality specifications for its related manufactured item.
  • GetComponent - When the component details are retrieved, the 'Item to inherit from' (INHI) setting will be included.
  • LstComponent - When the component details are listed, the 'Item to inherit from' (INHI) setting will be included.
• API PMS120MI (MO Type)
  • GetOrderType - retrieves the manufacturing order types and includes the 'QI request timing' (QIRT) setting and 'MO test frequency basis' (MTFB) value.
  • LstOrderType - lists the manufacturing order types and includes the 'QI request timing' (QIRT) setting and 'MO test frequency basis' (MTFB) value.
• API PMS100MI (Manufacturing Order Interface)
  • CrtMO - During the execution of this transaction, the logic for adding QI requests upon MO creation is invoked.
  • DltMO - This transaction results in the deletion of the MO referenced and also in the deletion of any QI requests or auto-attached specs that were created previously.
• API PMS050MI (Manufacturing Order, Report receipt)
  • RptReceipt - During the execution of this transaction, the logic for MO receipt reporting is invoked.
  • ConfirmAll - This transaction triggers the generation of the QI request with the receipt quantity being reported.
• API PMS080MI (Manufacturing Order, Report by-product)
  • RptByProduct- During the execution of this transaction, the logic for output reporting of by-products is invoked.
  • Confirm - This transaction, which updates the quantity of by-product reported, triggers the generation of the QI request with the by-product quantity being reported.
• API PMS090MI (Manufacturing Order Interface)
  • UpdCoProdReport - During the execution of this transaction, the logic for output reporting of co-products is invoked.
  • ConfirmReport - This transaction, which updates the quantity of co-product reported, triggers the generation of the QI request with the co-product quantity being reported.