Skip to Content
Author's profile photo Former Member

Suppress Triggering of Purchase Order Outputs during mass changes

How to Suppress PO Outputs :

There may be scenarios in which mass change is required in multiple Purchase Orders, for fields such as material group, Purchasing Group, taxcode, activating delivery complete or invoice complete flags, etc which are sensitive to triggering of PO output.  But we may need to suppress the outputs in order to avoid confusion among vendors.

In such scenarios, an Utility can be used in order to suppress PO outputs, even if mass change is performed using BDC or any batch program.

The Utility can be used to suppress the following fields in database table NAST (DB table to store message status information) for performing mass changes in POs.

  • Output type
  • Language
  • Medium
  • Dispatch time
  • Processing Status
  • Activity flag
  • Time of print
  • Destination.

A custom program needs to be created with the following entry screen :

The necessary selection options/parameters need to be passed for the relevant mass change.

The Processing Status is to be selected as per the PO’s for which update is to be performed –

0 – not processed,

1 – successfully processed,

2 – Incorrectly processed

These needs to be checked from the NAST table beforehand .

The Activity Flag (this flag determines whether output is triggered or not) is to be updated to blank

Checkbox for Update NAST Table needs to be checked.

This program needs to be executed with above parameters before the mass change is performed.

Once mass change is performed, the custom program needs to be executed once again so that the original values of Processing Flag and Activity Flag  are restored by making appropriate entries in “Convert to new values” section.

Similarly, this Utility can be used for performing mass changes to the fields as mentioned above.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jürgen Lins
      Jürgen Lins

      Your example fields are all field that do not needed to be communicated to the vendor. For such fields you have actually the customizing of print relevant fields.

      Nevertheless a message is created (but not processed) as this customizing is only checked in the print program and not in the the message determination,  see the explanation in OSS note 28869 - Printout of changes although field not print-relevant

      Beside of these facts it is not clear what your Z-program really does, at least it left me confused without a clear picture)

      You wrote that you start your Z-program before doing the mass change, but what do you do in detail? Updating NAST just means modifying existing message records. What exactly stops triggering new messages? Are you changing old NAST records temporarily to "not processed" which might stop creation of new messages?

      How do make sure that the user uses the same selection criteria in your Z-program and in the mass change? How do you make sure that you get the same old values back (in case you changed old NAST records which is not yet clear)?


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Thanks for your response Juergen.

      I will explain what exactly would be the functionality of the custom program.

      Before running the custom program, we would need to extract from NAST table , the current processing Status of the P.O. s  and update their activity status to blank, so that outputs do not get processed while performing mass change of the print sensitive fields.

      Then, after performing the mass change, we can revert back the actual processing Status of the POs that we had taken a dump of, and even update their activity status to 'X'.

      Please do let me know if you find any discrepancies in this.




      Author's profile photo Jürgen Lins
      Jürgen Lins

      This would never get approved in our organization

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hello Jurgen,

      Do you see any risk in this process ?




      Author's profile photo Jürgen Lins
      Jürgen Lins

      Actually yes, but it may just be caused by insufficient explanation.

      You are hard updating historic records. And I see nothing which controls that this change is really reversed after a change (or even  in case no mass was executed).

      I see just one selection screen, no field that gives me an indication that I perform step 1 (before mass update) or step 2 (reversal of NAST after the mass changes). From my imagination it is only a screen which allows me to hard update and manipulate  NAST records, and it is up to the user to what new value he actually sets. I see no indication that would allow me to return to the old values with a single click, which would be my expectation instead of filling the selection screen again equally to the initial selection.