Saturday, 26 November 2016

Automatic Account Determination

Inventory Management


Simply explanation: Managing the stock of material on qty and value basis is known as Inventory Management.

Whether Inventory is required or not for the material is controlled at material type and valuation area (plant) level.

In OMS2, Configuration required for each material type qty and value updating at valuation area level.

Case 1: If both Qty and Value update indicators are selected then PO can be raise for stock purpose and at GR material can be placed in store on qty basis and this Qty means stock value will be updated in inventory or stock G/L account.

Case 2: If qty update selected and value update not selected for material type at valuation area level, These material type related materials must procure for consumption Purpose. Means you should select account assignment category in PR and PO. At GR, received material is placed in store on qty basis but material value will be booked in relevant consumption G/L account but not in stock or inventory g/l account.

Inventory Management scenario’s can be defined as 1) Goods Receipt 2) Goods Issue 3) Stock Transfer 4)Transfer Posting

Characteristics of Goods Movements:


1) At least one material document will be generated and if goods movement is relevant to FI then accounting document to be generate.

2) Stock and Stock Value and Consumption Value may increase or decrease based on the goods movement.

3) If GR is entered against PO then PO history to be updated in Display PO.

4) Total value and Total stock, Moving average price to be updated (may be increase or decrease) in Material Master.

5) If Quality Management views are maintained with required fields, then when you completed the GR or GI, inspection lot to be generated when you run in QA32 , Based on Usage decision stock to be accepted or Rejected.

Sample process for Goods Receipt, Goods Issue, Stock Transfer, Transfer Posting.

Goods Receipts: 1) GR w.r.t Po for raw material

                               2) GR w.r.t Production order for finished Product.

                               3) GR With out for Production order

                               4) GR with out Purchase Order.

Goods Issue:      1) GI w.r.t Production order for raw material.

                              2) GI w.r.t sales order for finished product

                              3) GI to cost center or to plant maintenance.

                              4) GI to Scrap.

Stock Transfer:   1) Plant to plant stock transfer with in the company code.

                                2)From plant to plant across company code.

                                3)Store to Store stock transfer

Transfer Posting:  1) Unrestricted ⟺ QI ⟺ Blocked

Account Determination: (MM & FI Integration)

With this account determination Configuration settings,system will determine a suitable G/L account while posting GR (or) GI etc.

1) Account Determination with out wizard

I explained simply in one diagram, it is use full to remember the Process. Below I explained step by step.

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

1st Part:


Chart of account includes G/L accounts. This chart of account to be assigned to one company code or multiple company codes.

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

Note: Similar account determination required plants are grouped together and assigned to a valuation grouping code and then account determination will be configured at valuation grouping code level.

Step 1: Define Valuation Control (OMWM)

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

Here need to activate valuation grouping code.

For account determination, you can group together valuation area by activating the valuation grouping code.

Step 2: Group together valuation area.(OMWD)

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

here you assigned the valuation grouping code with combination of company code and chart of account and valuation area (plant) combination. If suppose similar account determination required plants are grouped together , here you can assign same valuation grouping code to multiple plants (or) multiple valuation areas.

2nd Part:


Material type and Account category reference and Valuation class.

Step 3: Define Valuation Classes.(OMSK)

In this step, you define which valuation classes are allowed for a material type.

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

So I am not going to this detailed. As account category reference is main controller and Mediator for material type and valuation class.

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

There is no direct configuration between material type and valuation class. Account category elaborates which material types related materials can be choose the which valuation classes.

You should enter this valuation class in material master.

3rd Part:


SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

Step 4: Define Account Grouping for Movement types (OMWN)

Note: It is not possible to define new valuation string and new transaction event keys but account modifiers are editable with any movement type, for GBB or PRD or KON transaction keys are triggering then only account modifier also triggers.

Based on movement type system is triggering a valuation string and this valuation string is again triggers several transaction keys. but few transaction keys again triggers account modifiers or account grouping code also.

Below are the transaction event keys relevant account modifiers

GBB ⇨ BSA,INV,VBO,VBR,VNG,ZOB

PRD  ⇨ PRA,PRE,PRU

KON ⇨ PIP

Step 5: Configure Automatic Postings (OBYC)

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

SAP Learning, SAP Module, SAP All Modules, SAP Live, SAP Guides, SAP Certifications, SAP All Modules List, SAP Materials

In this step, you enter the system settings for inventory management and invoice verification transactions for automatic postings to G/L account.

Saturday, 12 November 2016

Web Dynpro ALV Configurator

Messy code replaced by Config Step


Anybody who has developed applications using SAP WD ALV component SALV_WD_TABLE, know’s how many lines of code is required to configure ALV to specific requirements. There’s getting instance of ALV model and then calling all sort of API methods to fine tune standard ALV like- sequence the columns, hide, rename the column header, set lead selection behaviors, set column width, editable ALV or not, set cell editors and many more. For complex scenarios – set cell variant, map column properties with other field value(from context).

Now think of a solution which provides an ALV configurator which can be used to do all the above configurations so that developer doesn’t have to write that boilerplate code. The whole functionality is delegated to an external application. Your ALV instance automatically adjusts itself to the values set in the configurator.

Let’s say during UAT phase of your project – user wants to re-sequence the columns and also update column headings – you just have to make changes in the configurator. This can be done by functional consultant on the project – no developer involved – no source code change.

The architecture of this solution supports abstracting the common ALV functions like – showing record count, custom excel export, etc so that they can be easily provisioned.

Here’s the overview diagram of the solution.

UI Web Dynpro ABAP, All SAP Modules, SAP Tutorials, SAP Certifications

Maintenance Cycle

UI Web Dynpro ABAP, All SAP Modules, SAP Tutorials, SAP Certifications

  1. Add ALV Usage to the business application
  2. Add ZALV Usage for every ALV usage in the application
  3. Execute the application once to update Z tables with original config values
  4. Run the ZALV configurator app to override the original config values with wrapper values
  5. Transport business application components and wrapper records to UT/IT/PD

Supported Features

  • Almost all the ALV config properties mapped
  • Supports all ALV column properties
  • Supports screen resolution based adaptation ( details in next point )
  • Supports config variants that can be selected based on qualifiers – eg – role name, screen size etc. So columns shown to ROLE_A can be different from ROLE_B. Similarly, more columns can be shown for higher resolution display.
  • Supports overriding wrapper config value by run time value. Eg – retain the dynamic control of column visibility
  • Custom ALV functions (ALV Buttons) can be built in ZALV component and provisioned to consumer apps
  • ‘Record Count’, ‘Full Screen’  and ‘Custom Export’ functions are currently available

Design Consideration

  • Non-invasive: Original component and its ALV config code is untouched
  • Fallback: Just remove ZALV usage for easy fallback
  • Usability
    • Configurator lists the applications which uses ZALV with easy search mechanism.
    • Drop Down selectors used for the properties. Value descriptions used instead of internal values.
    • Property names are same as the one used in code for easy reference
  • Z Tables
    • Separate tables used for config, columns and functions.
    • CONFIG_SOURCE field is used to easily identify source of config record
    • CONFIG_SOURCE = 01 : Original Config
    • CONFIG_SOURCE = 02 : Wrapper Config
With all said – the implementation is of proto-type (beta) quality and not any where near to production quality. I am making this open source on GITHUB so as to involve WD ABAP community to contribute, provide feedback/suggestions and use freely.

You can find more details in the github repository.