Skip to Content

Overview

SAP SD provides very dynamic approach to determine the sales document screen sequence. The user interface picks up different sub-screens to work with different business processes. The various user interface components are controlled by the function codes which are defined in the screen sequence group.

Let’s go to system to explore how screen sequence control works.

Sales Document Type

First of all, the screen sequence group as well as overview screen function code are defined in the sales document type:

In this example, the screen sequence group “LL” is defined for sales document type “LZ”, and the overview screen function code is defined as “UER2”.

How are those settings functioning in controlling user interface can be found several tables which are defined in transaction code “VFBS”.

Screen Sequence Control

The transaction code “VFBS” is used to control the screen determination for sales document.

Here we need to find out what program ID should be used on this transaction. This can be done by checking technical detail of any SD transaction (e.g.T-code VA01). It is not so difficult to find screen number of VA01 and the relevant program name:

In program logic, the program ID of sequence control is routed to “SAPMV45B” when transaction triggers to the main page of sales document.

So the program ID “SAPMV45B” will be used to control screen sequence determination:

Now let’s see how function code controls screen sequence in detail.

T185F

What kind of function is triggered in the screen will be defined in the table T185F. For example, generally we will press button ENTER to navigate from initial screen of sales document to the main screen. So the ENTER will be registered as a function code in table T185F:

In the same table, the second column defines transaction types. There are following transaction types available:

In our example, the default overview screen function code “UER2” was defined in the sales document type. The relevant entry can be found in the table “T185F”:

Settings in table T185F will be used to control what information is required in table T185.

T185

This table is used to define the paths between current location and next location. For example, from the initial screen of sales document, the current screen group is “A0”, and the function code is “UER2”.

So in the table T185, the next screen of initial screen is defined below:


The screen sequence group “LL” which was specified in the sales document type is defined here. Double click the item to check the detail:


Settings in the detail view represents that the current function and screen group are “USR2” and “A0”. The next location is defined as:

  • Subsequent screen group: U0 (TAXI_TABSTRIP_OVERVIEW)
  • Subsequent panel: ERFI – this will be used in the next step
  • Function code: ENT1

T185V

This table is used to define the technical detail, such as screen number.


By using the program ID, screen group “U0”, and panel “ERFI” which were determined in the previous step to locate the entry in this table:


Here field “Panel” was defined in table T185 according to previous step, and main screen number “4001” is defined here.

Double click the item to go to detail:


In the detail view, it is very clear that main screen “4001” has two sub-screens in tab control. To be precise, the sub-screen “4021” represents overview header:


And sub-screen “4419” represents item overview tab which was set by default on screen group “USR2”:


TAXITABS

This table is used to define tabs in the table control of sales document. Based on unknown reason, the program ID for table control definition is “SAPMV45A”:


In the table, there are many function codes defined to represent different tabs in the table control:


The screen group defines tab control. For example, “U0” represents overview table control.

There are following tabs (function codes) with their sequence defined in this table:


The column number defines sequence of overview tab. The function code “UER1” and “UER2” which were assigned in the sales document type will put the default active tab. For example, the first tab “Sales” is set as default tab if creating sales order (document type “OR”) and the tab “Item overview” is set as default tab when creating scheduling agreement (document type “LZ”).

Technical Detail

Screen Number Determination

PBO

In the PBO of initial screen the default values are prepared:


In step 1 the transaction VA01, system will prepare some default value based on transaction code. For example, the table T180 is used to store the screen sequence default value by transaction code.

The screen groups are hard coded in the form “TAXI_SCREEN_GROUPS_INIT”


The screen group will be used to determine the table control tabs and their function codes:


PAI

The screen sequence control information is determined in the PAI module of screen 101, which is the initial screen for sales document creation.


The screen number of main screen will be determined via screen sequence control in following module:


In above modules, following function modules are called:

  • FUNCTION_EXECUTE
  • SCREEN_SEQUENCE_CONTROL


Tab Control Determination

The tabs of the tab control are determined in the PBO of main screen of sales document. For example, assume the main screen of sales document is 4001. In its PBO there are following steps:


Step 1

Initialize the main screen and deactivate all unnecessary function codes.


The first form is used to determine the text (e.g. title) based on transaction group (e.g. order, inquiry, agreement, etc.)

The second one will filter out those unnecessary function codes.

Step 2

Following function modules are triggered to build up table control on the main screen by default:

  • TAXI_CREATE_CAPTIONS: determine the captions on each tab
  • TAXI_INITIALIZE_CARRIERSCREEN: hide unmarked tabs
  • GET_HANDLE_SD_TAB_CUST_H: handle the custom tab settings for sales document header
  • GET_HANDLE_SD_TAB_CUST_I: handle the custom tab settings for sales document item
  • TAXI_ACTIVATE_TAB: it is used to determine the default active tab by function code

Step 3 and Step 4

Call header sub-screen and call body sub-screen.

 

More investigation will be shared later.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Michelle Crapo

    Great Blog – I’ve changed the screen sequence before.   For me – it didn’t work out.   There are just so many dependencies.   Perhaps I’ll be able to do that in the future on higher levels of SAP.

    Love the screen shots.

    Michelle

    (0) 
    1. Yong Zhao Post author

      Thanks Michelle!

      You are right. When I was debugging SD application, there were so many enhancement points and exits which introduced very complex dependency. I had to open Google translator to translate comments from Germany to English. Indeed, it was painful, but worthwhile.

      Best regards,

      Yong

      (0) 
  2. Paul Hardy

    This was a very interesting blog.

    However I have found the effort involved in “wrapping” sales order creation in your own Z code (be it DYNPPRO in the GUI or more recently UI5), and then calling a BAPI,  is far less than battling with the standard SAP code. And it is a battle.

    SAPMV45A despite giving a truly amazing amount of functionality, is a horror on the inside, and a textbook example of monolithic programming, chock full of examples of what you should never do any more e.g. SHARED PART.

    The greatest irony, is that SAP decided to write ME21N in all object orientated code, and they missed the point totally, the point being that well written OO code should be easier to understand, so ME21N is far more difficult to debug than VA01.

    In any event the problem with standard SAP screens is that they had to be all things to all people, which is why there were so many tabs all filled with hundreds of fields, and each company only need about six fields.

    So it does not matter what order those screens appear in, it is still agony. That is why you need some sort of wrapper to radically simplify matters for any given organisation.

    Cheersy Cheers

    Paul

     

    (0) 
    1. Yong Zhao Post author

      Hi Paul,

      Thanks for your comments! It gives me more thoughts on simplifying SAP standard transactions.

      I was curious about how screen sequence group setting was working in the sales document type configuration, so I started to investigate screen sequence controls.

      As the logic inside of SAPMV45A  is so complex, do you see any possibility that this application will be refactored or simplified? Frankly I don’t think it will happen. SAP screen personas would be an option to simplify UI screen of it, but not the backend logic.

      best regards,

      Yong

      (0) 
  3. Ged Hurst

    One fantastic blog.

    We rediscovered this functionality during an ERP upgrade to EhP8. We introduced new fields to SAPMV45A item subscreens in the 4000 range by copying them to screens in the 9000 range and adjusting the copies with the new fields. Of course you still have to create repairs for the objects you create, and you have to modify V_T185V in SM30. The contents of V_185V are reset to standard at upgrade time (which is why we found missing fields) and it gives you a message: ‘Maintenance of this table is not currently permitted’ when you go to update it.

     

    (0) 
    1. Yong Zhao Post author

      Hi Ged,

      Yes. You are correct. I think modify T185 series table is not recommended. This is why there is no official document available about how screen sequence control is working.

      Alternatively we’d better to utilize exits or BAdI to enhance new fields on standard screens. Otherwise, the modification would be overwritten by standard upgrade.

      best regards,

      Yong

      (0) 

Leave a Reply