After Purchase Order been created at the system, the relevant users should get notice email if any important fields been changed like net price, delivery address, items, etc. SAP System already provides an excellent solution with transaction OMFS, where you can maintain a combination of table name and table fields along with control flags to control whether PO printout should be triggered or not. But customer demand never stops: what if some organization wants to get email notifications for specific changes while other organizations don’t? This article will try to introduce the mechanism of print-relevant PO document changes and some tips when extending it to the organization level. SAP Standard: Fields Relevant to Printouts of Changes (TCODE: OMFS) Customized settings of Fields Relevant to Printouts of Changes are stored at the T166C table. T166C is the key table to control print-relevant PO changes, it’s been used to check changes at field level include header level/item level/schedule line item level against table EKKO/EKPO/EKET, etc. accordingly, as well as address table ADRC. And field XBEST is the indicator of whether active this field for printout. Besides, there’re several aspects that determine whether to trigger PO printout (include email been send out). 1. The first thing is the mode of Print Operation of PO: new PO creation, PO changes or PO display/preview will function differently. Obviously, new PO creation, PO display/print preview shouldn’t trigger printout. 2. Second is whether the changes of PO been regards as PO changes or not (for example, PO items field changes are captured using change document object EINKBELEG). 3. Except for the T166C control PO header/item field level, table T166A/T166K/T166P table is been used to validate the changes of header/item at text level based on the combination of Print Operation, Purchasing Document Category, Purchasing Document Type. One example of how print-relevant PO document changes been triggered First, look up why the output for PO 5504023487 at PO messages was triggered at 02-14-2019 22:06:03. Check the PO header/item changes at the triggered time inside ME23N, which change document object is EINKBELEG. Goto TCODE: SCDO with this object name: EINKBELEG. Here PO important tables like EKKO/EKPO/EKET been assigned to this object. This means changes in those tables will be saved linked to this object. Get the changer number 0716567251 by using PO number, change date/time, and object EINKBELEG at Change document header table CDHDR: Then go to Change document items table CDPOS using key: object EINKBELEG, PO number plus changer number 0716567251 fetched from the above step. At the T166C entry list, we can see the Item Delivery Date(EKET-EINDT) is a print-relevant field with XBEST = ‘X’. That’s why the print-relevant output been triggered. ◉ PO header/item fields have been changed which will be saved at history table CDHDR/CDPOS with object EINKBELEG. And if those changed fields belong to T166C, it’ll trigger print-relevant printout. ◉ For PO text changes, usually, the driver program will use FUNCTION ‘SELECT_TEXT’ to get all the text objects and compared with entries maintained at T166A/T166K/T166P table. If matched, will trigger printout. ◉ For PO header/item fields been changed which not belong to object EINKBELEG will not trigger printout. Especially for object ‘ADRESSE’ which relevant to address texts changes (not the same as ADRC! ADRC table field can be maintained at T166C table) Make ‘Fields Relevant to Printouts of Changes’ works at Organization level If we need to let some organizations get email notifications for specific field changes while others don’t, have to extend T166C to the organization level. The idea is simple, just insert purchasing organization as key fields and create new customized table Z166C, then replace all validation depends on table T166C with this new Z166C. Sounds quite straight forward, but still some points need to pay attention to. This new table Z166C will be checked &used only at PO printout driver programs and no usage at any other places so no impact for all other standard processing. As purchase order form is highly customized, most of the company will use their own forms and driver programs for PO printout, but SAP provided driver program SAPLMEDRUCK is a good reference (SAPFM06P is the previous version). Key Field: DRUVO It’s a local variable for Print Operation which comes from NAST-AENDE, could be different name per driver program which refer to T166K-DRUVO. If it’s ‘1’ means the PO has no changes; if it’s ‘2’ means the PO has changed. Here the change means PO been changed including but not limited to print-relevant changes. Key Function Module: ‘ME_READ_PO_FOR_PRINTING’ It is used to read the relevant purchasing document data during the print preparation of purchasing documents (The subsequent printout takes place with the help of the function module ‘ME_PRINT_PO’). This FM will check using T166C and return deep structure DOC which mandatory for the following processing. As we’re going to replace T166C by Z166C with a purchase organization and don’t want to enhance this standard FM or create a new one, so use DRUVO = ‘1’ to skip T166C’s impacts. The return code of this FM must be set back to 0, otherwise, further printout process will be skipped as well. And the standard error message ME140 here for ‘No print-relevant changes to document & exist’ must be checked and skipped if exists. ‘ME_CHANGES_PRINTOUT’ is the standard function module to collect PO changes at text level by check table T166A/ T166K/ T166P and at field level by check table T166C. Find the subroutine which read change document headers and fetch those 4 indicators and text number of change text from T166C, we need replacing with Z166C to make it run at the purchase organization level. Still use the standard ME140 if no print-relevant changes to document exist to avoid unnecessary queries. NAST and message logs are clear as well.