Field selection in Purchasing

Default field selection settings on ME53N

Issue:
Relevant fields should not be displayed according to default settings ("Choose layout... > change
layout...") in T-code ME53N.

Steps:

1. Set a field (For example, "Release Date") as nondisplay column via "Choose layout... > change
layout..." in T-code ME53N.
2. Run T-code ME51N to create two Purchase Requisitions (PRs -For example, PR1 and PR2).
3. Run T-code ME53N to display PR 1, and find the field (For example, "Release Date") does not display.
4. Click "Other Purchase Requisition" button and enter the number of PR 2.
5. Click "Other Purchase Requisition" button and enter the number of PR 1.
6. The field (For example, "Release Date") displays.

Solution:

The default setting (in T-code ME53N) is considered by system only for the first run of T-code
ME53N.

Please consider to set the field as "optional" or "hidden" in customizing (T-code OLME > Purchase
Requisition > Define Screen Layout at Document Level).

Related notes / content:

1893044 ME53N : The field should not display according to default settings

Field Selection in Contract and Scheduling Agreement - Debugging Guide

Field Selection determines whether a field should be editable/disabled, visible/hidden,

mandatory/optional, when users display, edit or create the Contract or Scheduling Agreement.

The Field Selection Customizing can be found in the following OLME paths:

• General: Contract (or Scheduling Agreement) -> Define Screen Layout at Document Level,
• Account Assignment related: Account Assignment -> Maintain Account Assignment Categories.
 The general customizing contains many different field selections and it is not always easy to
determine, which one is used in different cases. Moreover, there are also different logic, which can
overwrite the customizing dynamically.

By following the Debugging Guide, you can determine, which Field Selection is used and why the
field is displayed as system displays it. The guide is prepared for the most common screens such
as header details, item details, item additional data, item overview table and account assignment.

Initial steps
Before starting the debugging, press F1 on the relevant field that you would like to debug and click
button Technical Information (hammer icon). Here copy the table and field name such as [table
name]-[field name]. If this is an accounting field, the field name is enough.

In case of field Validity end, this will look like as EKKO-KDATE.

On the same screen, you can also find the screen you are on.

In this example, we are on the header screen (0201).

Now click on the link that contains the screen you are on (page will jump to the clicked section):

• Header details (0201), item details (0211), item additional data (0212),
• Item overview (0220),
• Account Assignment (0511).

Header details (0201), item details (0211), item additional data

(0212)
Start debugging in FM MEX_MODIFY_FELDAUSWAHL. To avoid irrelevant stops, set the breakpoint
right before you navigate to the relevant screen. Depending on the navigation, it can be that the FM
is called more than once.
• When you would like to debug the header details (0201), make sure that the PBO SCREEN is 0201 in
call stack.

• When you would like to debug the item details (0211), make sure that the PBO SCREEN is 0211 in call
stack.

• When you would like to debug the item additional data (0212), make sure that the PBO SCREEN is
0212 in call stack.

In FM MEX_MODIFY_FELDAUSWAHL system loops at the screen elements and changes the field
selection based on customizing that can be found in structure I_ENDMASKE. In this structure each
character represents the customizing for each field. This is the static field selection, which changes
the fields based on static customizing.
 SCREEN is not an internal table that you can display and search for the index of the relevant entry.
Therefore, to debug only the relevant field, at the beginning of the LOOP, set a Watchpoint for
field SCREEN-NAME based on the previously copied table and field name (e.g.: EKKO-KDATE).

After the watchpoint was created, press F8. System will go into the relevant LOOP step. In this LOOP
step on line "CASE <AUSW>." check the value of variable <AUSW>. Below you can find the meaning
of the value:

• . = Optional
• + = Required
• * = Display
• - = Hidden

If the value is not expected, it means that the issue occurs due to incorrect customizing. To find the
used Field Selection keys press F7 and display
variables AUSWAHL0, AUSWAHL1, AUSWAHL2, AUSWAHL3, AUSWAHL4, AUSWAHL5, AUSWAHL6.

In the example below four field selection keys are used.

Then go into OLME path Contract (or Scheduling Agreement) -> Define Screen Layout at Document
Level and verify the previously found field selection keys.

If the value is correct until this point, it means that the customizing is correct. Press F7 to return into
Include MM06EO0M_MODIFY_SCREEN.

Here system loops at the screen elements again and overwrites the SCREEN parameters based on
document values, follow-on documents, switches etc. This is the dynamic field selection.

You can debug the relevant field with the same Watchpoint method mentioned previously. Check
where system sets the SCREEN parameters unexpectedly:

• SCREEN-INPUT: 0 – read only, 1 - editable,

• SCREEN-REQUIRED: 0 – not mandatory, 1 - mandatory,
• SCREEN-INVISIBLE: 0 – visible, 1 – not visible.
Item overview (0220)
Start debugging in MEX_MODIFY_LOOP.

This is called as many times as many lines exist in over overview table (including blank lines).

In FM MEX_MODIFY_LOOP system loops at the screen elements and changes the field selection
based on customizing that can be found in structure I_ENDMASKE. In this structure each character
represents the customizing for each field. This is the static field selection, which changes the fields
based on static customizing.
 SCREEN is not an internal table that you can display and search for the index of the relevant entry.
Therefore, to debug only the relevant field, at the beginning of the LOOP, set a Watchpoint for
field SCREEN-NAME based on the previously copied table and field name (e.g.: EKPO-MENGE).

After the Watchpoint was created, press F8. System will go into the relevant LOOP step. In this LOOP
step on line "CASE <AUSW>." check the value of variable <AUSW>. Below you can find the meaning
of the value:

• . = Optional,
• + = Required,
• * = Display,
• - = Hidden.

If the value is not expected, it means that the issue occurs due to incorrect customizing. To find the
used Field Selection keys press F7 and display
variables AUSWAHL0, AUSWAHL1, AUSWAHL2, AUSWAHL3, AUSWAHL4, AUSWAHL5, AUSWAHL6.

In the example below four field selection keys are used.

 Then go into OLME path Contract (or Scheduling Agreement) -> Define Screen Layout at Document
Level and verify the previous found field selection keys.

If the value is correct until this point, it means that the customizing is correct.

By pressing F7 you will

reach MM06EO0M_MODIFY_LOOP and MM06EO0M_MODIFY_LOOP_4 (MODULE MODIFY_1)
where you can find product and info record specific logic to change field selection. Check, whether
system calls the logic at all and if yes, verify if the SCREEN parameters are changed using the same
Watchpoint method described previously.

Continue pressing F7 until you reach

Include MM06EO0M_MODIFY_LOOP_4 Module MODIFY_LOOP_4.

Go into MODIFY_LOOP_4, because this is where the general dynamic logic occurs. Here system
loops at the screen elements again and overwrites the SCREEN parameters based on document
values, follow-on documents, switches etc. This is the dynamic field selection.

You can debug the relevant field with the same Watchpoint method mentioned previously. Check
where system sets the SCREEN parameters unexpectedly:

• SCREEN-INPUT: 0 – read only, 1 - editable,

• SCREEN-REQUIRED: 0 – not mandatory, 1 - mandatory,
• SCREEN-INVISIBLE: 0 – visible, 1 – not visible.
 Account Assignment (0511)
Set breakpoint in:

• FM ME_COBLF_FUELLEN,
• FM COBL_EX_SEND_PBO.

When the accounting screen is opened, the breakpoint will stop in FM ME_COBLF_FUELLEN.

First, system fetches the relevant customizing.

After this step, check if table I_TCOBM[] contains the relevant field. If not, check whether the field is
available in SPRO path Financial Accounting (New) -> Financial Accounting Global Settings (New) ->
Ledgers -> Fields -> Customer Fields -> Edit Coding Block.

In a DO cycle, system loops at the account assignment fields of table I_TCOBM[] and sets them based
on field selection customizing. There are other fields, which have separate logic and are processed
after the loop cycles.

To debug only the relevant field, at the beginning of the DO cycle, set a Watchpoint for
field FNAME based on the previously copied field name (section Initial steps).
 After the watchpoint was created, press F8. System will stop in the first line where the processing of
the desired field starts.

First, check if the customizing is correct. You can find the customizing value in variable L1:

• . = Optional
• + = Required
• * = Display
• - = Hidden
 If the customizing is not correct, copy the value of field KNTTP of structure T162K (this shows the
used account assignment category) and open OLME path Account Assignment -> Maintain Account
Assignment Categories. Double-click the previously copied value and change the customizing as
desired.

If the customizing is correct, follow the program into FORM COBLF_FUELLEN_*.

In that FORM, system sets the REQUIRED and INPUT attributes of the field based on the customizing.

The meaning of values of field REQUIRED and INPUT:

• ICOBLF-INPUT: 0 – read only, 1 - editable

• ICOBLF-REQUIRED: 0 – not mandatory, 1 – mandatory

Press F7 to return Include MM06EFKN_KNT_INT_COBLF_FUELLEN.

Here system checks if flag Acct.assg.changable is set in transaction OME9 for the Account Assignment
category and if yes, system disables the account assignment fields, if GR or Invoice were already
created for the Agreement. In case GR non-valuated flag is set, system only does this, if Invoice was
already created.

Press F8. The breakpoint in FM COBL_EX_SEND_PBO will stop.

Here system deletes fields based on switch activation status.

 Finally, system fills the set field selection values into buffer table GT_COBLF.

Field Selection in Purchase Order - Debugging Guide

Field Selection determines whether a field should be editable/disabled, visible/hidden,

mandatory/optional, when users display, edit or create the Purchase Order.

The Field Selection Customizing can be found in the following OLME paths:

• General: Purchase Order -> Define Screen Layout at Document Level,

• Account Assignment related: Account Assignment -> Maintain Account Assignment Categories.

The general customizing contains many different field selections and it is not always easy to
determine, which one is used in different cases. Moreover, there are also different logic, which can
overwrite the customizing dynamically.

By following the Debugging Guide, you can determine, which Field Selection is used and why the
field is displayed as system displays it.

Initial steps
Before starting the debugging, press F1 on the relevant field that you would like to debug and click
button Technical Information (hammer icon). Here copy the table and field name such as [table
name]-[field name].
 In case of Purchasing Organization field, it will look like MEPO1222-EKORG.

Preparation for debugging

The steps differ based on the screen you would like to debug. Click the link of the relevant screen:

• Header top line (PO number, Supplier, PO date)

• Header tabs:
• Delivery/Invoice, Conditions, Texts, Address, Communication, Partners, Additional Data, Org.
Data, Payment Processing
• Item Overview table
• Item tabs:
• Material Data, Quantities/Weights, Delivery
Schedule, Delivery, Invoice, Conditions, Confirmations, Custom fields, Account
Assignment, Texts, Delivery Address, Shipping, Condition Control, Retail, Additional DFPS
Fields, Public Sector

Header top line (PO number, Supplier, PO date)

Header tabs: Delivery/Invoice, Communication, Additional Data, Org. Data, Payment
Processing
Item tabs: Material Data, Quantities/Weights, Delivery Schedule, Delivery, Invoice,
Confirmations, Custom fields, Shipping, Condition Control, Retail, Additional DFPS Fields,
Public Sector
Set breakpoint in Method FS_GET of class CL_MODEL_VIEW_MM. Then close ME21N or ME22N and
start it again, because the field selection values are buffered and you can only debug the relevant
logic once upon opening the transaction.

When the transaction is opening, the breakpoint will stop. In the following logic double click
table MY_DYNPRO_FIELDS.
In Variables section, double click the table again to show the table entries. In the list, search for the
table and field name that you determined in Initial steps section. Keep pressing F8 until you find the
field. If you found it, copy the value in column METAFIELD for the found field, and leave the
debugging running and in a new session, set a breakpoint in Method FIELD_SELECTION_2 of
Include LMEPOF2S (or you can also set the breakpoint in debugger via pressing F9). After you set
the breakpoint in Method FIELD_SELECTION_2, press F8. The breakpoint will stop in
Method FIELD_SELECTION_2. Now you can continue the analysis via section Debugging Guide.

Header tabs Texts, Address, Item tabs Account Assignment, Texts, Delivery Address
Set a breakpoint in FIELD_SELECTION_2 of Include LMEPOF2S. When you open the tab, the
breakpoint will stop. Now you can continue the analysis via section Debugging Guide.

Item Overview table

Set a breakpoint in FIELD_SELECTION_2 of Include LMEPOF2S. To trigger the breakpoint, change
any irrelevant value in Item Overview table and press Enter. The breakpoint will stop. Add the
following variable to Variables section: IM_EKPO-EBELP. Then press F8 until you see PBO SUBCREEN
1211 in call stack and you can find the relevant item number in IM_EKPO-EBELP.

In call stack open Method FS_GET of Class CL_MODEL_VIEW_MM (call 19 on this screenshot) and
add MY_DYNPRO_FIELDS into variables. Open it and search for the table and field name that you
determined in Initial steps section. If you found it, copy the METAFIELD value for the found entry.

Go back to the call where the breakpoint initially stopped (FORM FIELD_SELECTION_2) and continue
the analysis via section Debugging Guide.

Header / Item tab Condition

Set a breakpoint in Module FELDAUSWAHL of Include LV69AO03. When you open the tab, the
breakpoint will stop. This logic is called as many times as many lines are visible in Condition tab. So
press F8 until you reach the desired number of line. You can also use structures KOMK or KOMP to
 identify, which line you are at. If you found the relevant line, you can continue the analysis via
section Debugging Guide.

Header tab Partners

Set a breakpoint in Modules FILL_LOOP_PARTNERS and MODIFY_SCREEN of Include LEKPAO01.

When you open the tab, the breakpoint will stop. This logic is called as many times as many lines are
visible in Partners tab. So press F8 until you reach the desired number of line. You can also use
structure MMPA to identify, which line you are at. If you found the relevant line, you can continue the
analysis via section Debugging Guide.

Debugging Guide
The further debugging steps also differ based on the relevant screen. To continue, click the relevant
screen:

• Header top line (PO number, Supplier, PO date)

• Header tabs:
• Delivery/Invoice, Conditions, Texts, Address, Communication, Partners, Additional Data, Org.
Data, Payment Processing
• Item Overview table
• Item tabs:
• Material Data, Quantities/Weights, Delivery
Schedule, Delivery, Invoice, Conditions, Confirmations, Custom fields, Account
Assignment, Texts, Delivery Address, Shipping, Condition Control, Retail, Additional DFPS
Fields, Public Sector

Header tabs Delivery/Invoice, Texts, Address, Communication, Additional Data, Org. Data,
Payment Processing

Item Overview, Header top line

Item tabs Material Data, Quantities/Weights, Delivery Schedule, Delivery, Invoice,

Confirmations, Custom fields, Texts, Delivery Address, Shipping, Condition Control, Retail,
Additional DFPS Fields, Public Sector
At this point, we stopped the program in Method FIELD_SELECTION_2 for the relevant screen.

At the beginning of Method, system gathers some customizing data based on document, item type,
accounting, release strategy data, then it populates the field selection keys (LS_LOCAL-KEY0 –
LS_LOCAL-KEY6).

Afterwards, system calls BAdI that can modify the standard field selection keys on both header and
item levels.
Here check, if the BAdI changes the field selection keys, because these will be used in the next call,
where system gathers the field selection customizing.

System fills the data in LS_LOCAL-MASK structure, but it is not yet in readable form, so we can ignore
it at this point.

Afterwards, system loops at all fields that are available in table CH_FIELDSELECTION and sets the
found field selection configuration for each (for custom fields no customizing exists).
 You can continue at the end of the LOOP.

Now open table CH_FIELDSELECTION. Based on the METAFIELD value that we copied at the
beginning of the debugging, gather the value of FIELDSTATUS column. In case of
tab Texts and Address, you will only find one entry with METAFIELD 120 and 39 respectively, so you
need to gather the FIELDSTATUS for those entries.

You can find the meaning of the FIELDSTATUS value below:

• . = Optional
• + = Required
• * = Display
• - = Hidden

If the value is not expected, it means that the issue occurs due to incorrect customizing. Show the
field selection keys by adding the variables LS_LOCAL-KEY0 – LS_LOCAL-KEY6 in the variables section.

Then go into OLME path Purchase Order -> Define Screen Layout at Document Level and verify the
previously found field selection keys.

If the value is correct until this point, it means that the customizing is correct. Besides the field
selection customizing, there are can be special rules for each field that overwrites the customizing
dynamically.

To review the dynamic logic, continue the debugging. There will be another loop on
table CH_FIELDSELECTION and system will call the dynamic logic (Method EXECUTE), if exists.
 Open table CH_FIELDSELECTION again and based on the METAFIELD value that we copied at the
beginning of the debugging, check the index of relevant line (first column). In case of
tab Texts and Address, only one entry will be, so the index is 1. Continue to the LOOP step that has
the same index as the index of the line in CH_FIELDSELECTION and go into (F5) Method EXECUTE.

In Method EXECUTE you will find individual logic that can change the previously
checked FIELDSTATUS value with statement switch_field_to. You can find the new value next to
the switch_field_to statement like below:

You can find the meaning of the new value below:

• . = Optional
• + = Required
• * = Display
• - = Hidden

Review whether the coding sets a new value unexpectedly.

If the value is still correct, press F7 until you return into Method IF_FIELDSELECTION_MM~FS_GET.
Here system calls the BAdI that can be used to implement custom dynamic logic to overwrite the
field selection for custom fields (FM MEPOBADI_FS_HEADER for header,
FM MEPOBADI_FS_ITEM for item).

After the BAdI is called, verify if the field status was changed in CH_FIELDSELECTION based on
the METAFIELD value, because this is the last logic that can modify the field selection.
 Header / Item tab Condition
At this point, we stopped the program in Module FELDAUSWAHL of Include LV69AO03.

In this logic system loops at the screen elements of the condition line.

SCREEN is not an internal table that you can display and search for the index of the relevant entry.
Therefore, to debug only the relevant field, at the beginning of the LOOP, set a Watchpoint for
field SCREEN-NAME based on the copied table and field name in the Initial steps section (e.g.: KOMV-
KWERT).

After the watchpoint was created, press F8. System will go into the relevant LOOP step.

As there are many cases and separate logic can be called for each fields, it is not possible to provide
a guide from now on. You need to continue debugging, follow the program and check, whether the
relevant SCREEN attributes are changed unexpectedly. You can find the relevant attributes and their
meanings below:

• SCREEN-INPUT: 0 – read only, 1 - editable,

• SCREEN-REQUIRED: 0 – not mandatory, 1 - mandatory,
• SCREEN-INVISIBLE: 0 – visible, 1 – not visible.
Header tab Partner
At this point, we stopped the program in Module FILL_LOOP_PARTNERS of Include LEKPAO01.

In this logic system checks whether the partner type is changeable based on partner customizing
(OLME path Partner Determination -> Partner Settings in Purchasing Documents -> Define Partner
Schemas ) and if not, it disables the fields for that partner line (SCREEN-INPUT is set to 0).

Afterwards, press F8. The breakpoint will stop in Module MODIFY_SCREEN. The logic changes the
field selection rarely. To check whether it does, set a Watchpoint for field SCREEN-NAME based on
the copied table and field name in the Initial steps section (e.g.: WRF02K-GPARN).

Then press F8. If the watchpoint doesn't stop, it means that no changes were made to the field
selection by this logic. If the watchpoint stops, continue debugging and check, whether the
 relevant SCREEN attributes are changed unexpectedly. You can find the relevant attributes and their
meanings below:

• SCREEN-INPUT: 0 – read only, 1 - editable,

• SCREEN-REQUIRED: 0 – not mandatory, 1 - mandatory,
• SCREEN-INVISIBLE: 0 – visible, 1 – not visible.

Item tab Account Assignment

At this point, we stopped the program in Method FIELD_SELECTION_2 for accounting screen.

First, in the call stack double click Event FS_GET of

Program CL_MODEL_VIEW_MM==============CP. In this Method double click
table MY_DYNPRO_FIELDS.

In Variables section, double click the table again to show the table entries. In the list, search for the
table and field name that you determined in Initial steps section and copy the value in
column METAFIELD, because we will need it later.

Now go back to Event FIELD_SELECTION_2 in call stack and search for the logic below, which is
responsible to gather the Account Assignment field selection customizing:

Afterwards, system loops at all fields that are available in table CH_FIELDSELECTION and sets the
found field selection configuration for each.

You can continue at the end of the LOOP.

Now open table CH_FIELDSELECTION. Based on the METAFIELD value that we copied at the
beginning of the debugging, gather the value of FIELDSTATUS column.

You can find the meaning of the FIELDSTATUS value below:

• . = Optional
• + = Required
• * = Display
• - = Hidden

If the value is not expected, it means that the issue occurs due to incorrect customizing.

To check the customizing, execute transaction OME9 and double click the item account assignment
type (EKPO-KNTTP).

If the value is correct until this point, it means that the customizing is correct. Besides the field
selection customizing, there are can be special rules for each field that overwrites the customizing
dynamically.

To review the dynamic logic, continue the debugging. There will be another loop on
table CH_FIELDSELECTION and system will call the dynamic logic (Method EXECUTE), if exists.

Open table CH_FIELDSELECTION again and based on the METAFIELD value that we copied at the
beginning of the debugging, check the index of relevant line (first column). Continue to the LOOP
step that has the same index as the index of the line in CH_FIELDSELECTION and go into (F5)
Method EXECUTE.

In Method EXECUTE you will find individual logic that can change the previously
checked FIELDSTATUS value with statement switch_field_to. You can find the new value next to
the switch_field_to statement like below:

You can find the meaning of the new value below:

• . = Optional
• + = Required
• * = Display
• - = Hidden

Review whether the coding sets a new value unexpectedly.

If the value is still correct, press F7 until you return into FM MEPO_KNT_FIELD_SELECTION. Here
system calls the standard BAdI implementations only for multi account assignment screen.
 After the BAdI is called, verify if the field status was changed in CH_FIELDSELECTION based on
the METAFIELD value.

Then press F7 again until you return into Method FS_GET of Include LMEACCTVICI5. Here system
disables all fields, if it doesn't determine the item accounting-relevant.

Check, if the values remain correct, because this is the last logic that can modify the field selection.

Field Selection in Purchase Requisition - Debugging Guide

Field Selection determines whether a field should be editable/disabled, visible/hidden,

mandatory/optional, when users display, edit or create the Purchase Requisition.

The Field Selection Customizing can be found in the following OLME paths:

• General: Purchase Requisition -> Define Screen Layout at Document Level,

• Account Assignment related: Account Assignment -> Maintain Account Assignment Categories.

The general customizing contains many different field selections and it is not always easy to
determine, which one is used in different cases. Moreover, there are also different logic, which can
overwrite the customizing dynamically.
 By following the Debugging Guide, you can determine, which Field Selection is used and why the
field is displayed as system displays it.

Initial steps
Before starting the debugging, press F1 on the relevant field that you would like to debug and click
button Technical Information (hammer icon). Here copy the table and field name such as [table
name]-[field name].

In case of Material field, it will look like MEREQ3319-MATNR.

Starting debugging
The next steps will differ, if you would like to debug a tab or the item overview table.

• In case tab debugging, set a breakpoint in Include LMEREQF05 Method GET_FIELDSELECTION.

When you display a tab, the breakpoint will stop. At this point you can skip to section Debugging
Guide.
• In case of overview table, set a breakpoint in Method BUILD_GRID_LAYOUT of
class CL_GRID_VIEW_MM. When you display the overview table or change a value in it, the
breakpoint will stop. At the middle of this Method you can find a LOOP statement.

This loop is responsible to gather the field selection for each line of the overview table (blanks too).
Continue to the LOOP step, which has the same index as the index of the relevant row in overview
table (in case you would like to debug the first row, you need the first loop step). When you reached
the relevant LOOP step, set a breakpoint in Include LMEREQF05 Method GET_FIELDSELECTION. For
further steps refer to the next section (Debugging Guide).
Debugging Guide
At this point you are in debugging mode in Method GET_FIELDSELECTION. Before continuing with
debugging, in the call stack double-click event FS_GET.

Then add MY_DYNPRO_FIELDS in Variables section and double-click it.

In the table, in column SCREENNAME locate the field name that you copied at the beginning and
copy the value in METAFIELD column. We will need this value later. If you got the value, in call stack
go back to event GET_FIELDSELECTION and make sure you see the below coding logic.

At the beginning of the Method, system gathers some customizing data based on document, item
type, accounting field selection, release strategy data, then it populates the field selection keys
(l_key0 - l_key6).

Afterwards, system calls BAdI that can modify the standard field selection keys.
Here check, if the BAdI changes the field selection keys, because these will be used in the next call,
where system gathers the field selection customizing.

System fills the data in L_MASK structure, but it is not yet in readable form, so we can ignore it at this
point.

Afterwards, system loops at all fields that are available in table CH_FIELDSELECTION and sets the
found field selection configuration for each.

You can continue at the end of the LOOP.

Now open table CH_FIELDSELECTION. Based on the METAFIELD value that we copied at the
beginning of the debugging, gather the value of FIELDSTATUS column. You can find the meaning of
the value below:
• . = Optional
• + = Required
• * = Display
• - = Hidden

If the value is not expected, it means that the issue occurs due to incorrect customizing. Show the
field selection keys by adding the variables (l_key0 – l_key6) in the variables section.

Then go into OLME path Purchase Requisition -> Define Screen Layout at Document Level and verify
the previously found field selection keys. Or if you debugging account assignment fields, execute
transaction OME9 and double click the used account assignment category to review the relevant field
selection customizing.

If the value is correct until this point, it means that the customizing is correct. Besides the field
selection customizing, there can be special rules for each field that overwrites the customizing
dynamically. To review the dynamic logic, continue the debugging. There will be another loop on
table CH_FIELDSELECTION and system will call the dynamic logic
(Method COMPUTE_FIELDSTATUS), if exists.
 Open table CH_FIELDSELECTION again and based on the METAFIELD value that we copied at the
beginning of the debugging, check the index of relevant line (first column). Continue to the LOOP
step that has the same index as the index of the line in CH_FIELDSELECTION and go into (F5)
Method COMPUTE_FIELDSTATUS.

In Method COMPUTE_FIELDSTATUS you will find individual logic that populates l_ctxt->fs-
fieldstatus with the following values:

• . = Optional
• + = Required
• * = Display
• - = Hidden

Review whether the coding changes FIELDSTATUS unexpectedly.

If the value is still correct, press F7 to return into Method FS_GET. Here system calls the BAdI that can
be used to implement custom dynamic logic to determine the field selection for custom fields.

After the BAdI is called, verify if the field status was changed in CH_FIELDSELECTION based on
the METAFIELD value, because this is the last logic that can modify the field selection.

ME52N Field is not editable

ME52N field is not editable.

Solution:

The field is set as "Display" in relevant "Field Selection Key" in customizing (T-code OLME > Purchase
Requisition > Define Screen Layout at Document Level). Please refer to SAP Note 30316 for more
detailed information.

Field "Purchase order price" (EBAN-BPUEB) is set in the Purchase Requisition (PR). (Can be
checked via T-code SE16).

Related notes / content:

1910199 ME52N : Field is not editable

 30316 Problems with fields that are not ready for input in purch.

Service Purchase Order - Fields in display mode

The procurement of services differs slightly from the procurement of material because for services no
inventory has to be managed. First the purchase order is created and sent to the service provider.
Now instead of a goods receipt an entry of services is maintained after the services are provided by
the vendor. Because of these differences, there is a few validations that system executes in order to
keep the document consistent.

SAP ERP MM differentiates between a Service and non-service document by the Item category:

• Planned services or services whose nature and scope is defined at the time of procurement (item
category D).
• Unplanned services whose nature is not known at the time of procurement but known only after the
service is performed by the vendor (item category B). Unplanned services are also called limits as the
procurement of these services is restricted by a value limit. Limits are also used in scenarios where
the services are of trivial or minor value or for services which are provided over a longer period of
time (validity period).

Once the service items are entered in the Purchase Order, vendor field, along with other fields, are
greyed out and no longer open for input. The reason for this is that in service PO's there is an
internal table named COMSRV that is build when a service line is added to a position. This internal
table then holds important PO data like vendor, purchasing organisation, plant etc. and information
about the added service. Those information are linked to each other and cannot be changed once all
entries have been made, because due to performance reasons table COMSRV cannot be rebuild
every time the user changes vendor or plant after having added service lines.

Hence the following fields are not ready to be changed:

• Document type (BSART)

• Vendor (LIFNR or SUPERFIELD)
• Document date (BEDAT)
• Purchasing organization (EKORG)
• Company code (BUKRS)
• Language (SPRAS)
• Item category (EPSTP or PSTYP)
• Plant (WERKS)

Related notes / content:

634395 FAQ: Purchase orders in the service, Question 15

The fields in item overview of T-code ME2*N cannot be customized in T-code
SHD0

Issue:

When try run to T-code SHD0 to create/change Transaction Variant of ME2*N (ME21N, ME22N,
ME23N), find the fields in item overview cannot be customized.

Solution:

Cause: "Item overview as grid control" flag is set in Personal Settings of ME2*N (ME21N, ME22N,
ME23N). Since only the predefined fields can be displayed in the table control (not grid control).
Please un-select "Item overview as grid control" flag in Personal Settings of ME2*N.

Related notes / content:

1885057 SHD0 : The fields in item overview of T-code ME5*N (or ME2*N) cannot be customized

The fields in item overview of T-code ME5*N cannot be customized in T-code

SHD0

Issue:

When try to run T-code SHD0 to create/change Transaction Variant of ME5*N (ME51N, ME52N,
ME53N), find the fields in item overview cannot be customized.

Solution:

"Item overview as grid control" flag is set in Personal Settings of ME5*N (ME51N, ME52N, ME53N).
Since only the predefined fields can display in the table control (not grid control).
Please un-select "Item overview as grid control" flag in Personal Settings of ME5*N.

Related notes / content:

1885057 SHD0 : The fields in item overview of T-code ME5*N (or ME2*N) cannot be customized