Enhancements in Web Dynpro ABAP-Part II

In part I , we have seen about enhancing the view and window of the standard web Dynpro ABAP component, in this Part we will be seeing about Enhancement of controller and deleting an Enhancement.

Enhancement of controller:

Enhancement of controller consist of enhancements of Context Nodes, Attributes, methods and actions.

Context Node Enhancement:

Each controller will be having the context assigned to it, Context nodes/attributes can be enhanced or new nodes/Attributes can be assigned to the context.

There will be two kinds of nodes,

• Nodes without Dictionary structure mapping
• Nodes with Dictionary structure mapping

IF the node is without DD mapping then you can add the attributes to it by right click on it -> create – > attribute.

Before to this step enable the enhancement implementation.

IF the node is with DD mapping then you can add the attributes to it by right click on it -> create using wizard- > attributes from components of structure. 

Similarly you can add new nodes or attributes also to the same context by right click on the root context.

Attribute Enhancement:

To enhance the attributes tab go to the required controller, and enable the enhancement implementation.

Then the attributes tab will be enabled with Edit mode hence whatever the new additions are required or Existing attribute Edit( Except standard WD attribute) we can do here.

Enhancements of method and actions:

There will be two possible things we can do in methods, Enhancing the existing method or adding new method

First enable enhancement implementation for the methods tab.

Then the tab will be converted into Edit mode hence we can add new methods here like normal Edit.

Enhancement of the existing methods can be done in any of the following 3 ways.

• Pre Exit
• Post Exit
• Overwrite Exit

We are not going to change the code of the existing method, instead we will select the Exit option & a new method will be created there we can write our business logic’s.

Pre Exit:

This method will be called before the execution of actual method, this will be called by wd_this reference by the controller and later actual method will be called.

Post Exit:

This is just an opposite of Pre Exit, this method will be called after the execution of actual method with wd_this reference by the controller.

Overwrite Exit:

Overwrite method will replace the execution of actual method hence in this case actual method will not even get called.

Similarly if you wants to delete the newly created methods you can use the delete options which will be available just above to the methods.

Deleting Enhancement Implementation

To delete the Enhancement implementation, follow these steps

• Go to transaction SE80
• Select the package which you have saved the Enhancement object
• Select the implementation and delete it like it showed here.

Continue reading

MM-FI integration: Account determination simulator

MM-FI integration: A conceptual understanding

Now we know how MM and FI are integrated and how the account determination happens. If we want to test inventory account determination, neither you need to do actual material posting in the system nor go through master data and customization to identify the accounts. SAP has delivered account determination simulation tool.

This helps to find how an account is determined while posting stock related transactions. We just need to input plant, material, movement type and select the transaction we would like to check say GR for purchase order, GR for process order etc. Based on above inputs, system would read customization, master data and simulate the account determination process. Apart from above, system would also identify missing account assignments for a given transaction. This would further help to analyze issues in an easy manner.

Go to T-code OMWB and close the initial popup. Click on Simulation button.

Fill in plant, material , movement type and enter. Transaction list would be automatically refreshed based on the movement type. Double click on required type of transaction to be checked say GR and click on Account assignments.

In next screen, we can see the list of all available transactions possible for this movement type, plant and material combination. Some fields like material type, valuation class etc. are derived from material master data. Some fields like valuation area, valuation grouping code etc. are derived from customization of the plant.

In this screen, we can see what all accounts are determined for different kind of transactions.

EG: For Inventory posting, you can see Debit/Credit posting keys and respective G/L accounts. If there are any missing account assignment for a given transaction, this is also highlighted with text as “Missing”.

In above example, you can see this happened for Purchase account and purchase offsetting account. We don’t have any account assignments here as we are not using this scenario. By this way, we can clearly identify the gaps in account assignment without even doing the actual posting.

We can change to different movement types and transaction combinations and see how account determination happens and based on what fields it happens. You can try this in your system for various permutations and combinations.

Second feature available with this tool is, to check the MM-FI integration: Account determination simulator. This would help to identify any conflicts in screen layout rules for the inventory G/L account item during material document posting.

Screen layout for the inventory account item is determined at two levels.

1. From field status group of movement type

2. From field status group of inventory G/L account.

Click on “Check screen layout” button. In Next screen, we can see what is the field status set at movement type level and G/L account level. We should ensure that, there is no conflict between these two field status exist.

EG: We can’t have a field mandatory in one FSG and suppressed in other FSG. Posting would fail in such cases.

Sample output:

Just hover on the small ICON to see if a field is Mandatory/Optional/Suppressed/Display only. Any conflicts found should get reported in the error log in tool bar.

In case of conflicts, priority would be given in the sequence below with the exception of Required and suppressed combination which is not allowed.

1. Suppressed

2. Display

3. Required

4. Optional

Third option provided by this tool is, “where used list of G/Ls”. This would help to Identify in what all scenarios a G/L has been configured in the system.

From the main screen of OMWB, click on where used list of G/L.

Enter company code and valuation area in next screen and execute.

Sample output:

This output shows the list of valuation classes and transaction keys a G/L has been assigned to.

Hierarchy is as below.

Chart of accounts

                |-G/L account

                                |-Valuation class

                                                |-Transaction event key

                                                                |-Account grouping code

Continue reading