To be honest, new code line and simplifications brought by S4CORE scared me alot, on the finance and Inventory modules side, there are many major changes including database changes.

So I have decided to realize Inventory postings and to see what will happen. Basically my scenerio has two materials to cover both standard price control and moving avarage price.

If everything goes succesfully, I will see CKM3N will run for the material name S4CORE STANDARD PRICE and I’ll see that compatibility layer works.

1. Create Materials: I have created two materials :

S4CORE_ML_SARHAN_10.jpg

I decided to create another one with standard price because on the Material Ledger side on the database level there are minor changes like :

In table CKMLCR the attributes PVPRS and SALKV are not updated anymore for materials with price control “Standard”. (we’ll check this as well)  In table MLCR the attributes SALKV, SALKV_OLD and PVPRS_OLD are not updated anymore for materials with price control “Standard”.

S4CORE_ML_SARHAN_20.jpg

As it is mentioned in the Simplication Document: MM-IM simplification makes it obligatory to use the Material Ledger in all SAP S/4HANA systems. When a system is converted to SAP S/4HANA the Material Ledger will be activated if not active already.

I have activated Material Ledger, otherwise system does not let you create any Accounting related view. Meanwhile I have run all the tests on a fresh installed S4HANA 1511 system.

2. Goods Receipt by using MIGO:

I have completed all the required customizing steps to post an inventory document, I have decided to use movement type 561 Init.entry of stBal.Here are the documents. Nothing was different, if you are happy with TC MIGO. Here are the created documents listed by TC MB51

S4CORE_ML_SARHAN_30.jpg

3. Check Created Material and Financial Documents

I have tried to use TC MB03 however it is obsolote in S4HANA 1511, system redirects to MIGO, here are the documents that are created:

S4CORE_ML_SARHAN_40.jpg

The most important document is Material ledger document. Let’s deep dive a little bit more. In the simplification document:

Before S/4HANA, the inventory valuation tables xBEW(H) – tables: EBEW, EBEWH, MBEW, MBEWH, OBEW, OBEWH, QBEW, QBEWH – contain transactional as well as master data attributes


With S/4HANA, the inventory valuation tables do still exist as DDIC definition as well as database object. However, they will only be used to store material master data attributes. The transactional fields LBKUM, SALK3 and SALKV will be retrieved from the Material Ledger. Hence, those fields are not updated anymore in the original xBEWH(H) tables. As a consequence, the above mentioned tables need to be updated less often, which leads to a higher throughput due to less database locks.


For compatibility reasons there are Core Data Service (CDS) Views assigned as proxy objects to all those tables ensuring that each read access to one of the mentioned tables still returns the data as before. The CDS views consist of database joins in order to retrieve both master data from the original xBEW(H) table and transactional data from Material Ledger tables.

Let’s pick up MBEW to check the current status in S4CORE of S4HANA:

With the help of TC Se11 I have seen that MBEW is still there but uses a proxy object called MBV_MBEW.

S4CORE_ML_SARHAN_80.jpg

Data provided by using this DDL source, let’s see how: we need to use a programcalled : RUTDDLSSHOW2, so I have sun the program for DDL source MBV_MBEW.


Here is the definition :

S4CORE_ML_SARHAN_90.jpg

It is a little bit long but the important information is visible. There is an other view called Mbv_Mbew_Case : ‘MBEW case for ML integration’, once we go deeper we’ll find the source called Mbv_Mbew_Basis: ‘MBEW basis for ML integration’. In the deep deep detail we have seen that data is provided from ML tables: CKMLPP, CKMLCR as it is told in Simplification document:

S4CORE_ML_SARHAN_100.jpg

Now it is time to check this statement In table CKMLCR the attributes PVPRS and SALKV are not updated anymore for materials with price control “Standard”.

S4CORE_ML_SARHAN_110.jpg

Yes it is not updated for Standard.

Last table that I want to go deeper is MLHD data, Contents of tables MLIT, MLPP, MLPPF, MLCR, MLCRF, MLCD, CKMI1, BSIM are now stored in ACDOCA. MLHD data is stored in BKPF For materials that are not relevant for actual costing (xBEW-MLAST = ‘2’) no ML update documents (MLHD-VGART = ‘UP’) are persisted anymore in the ML document tables MLHD, MLIT, MLPP, MLCR and MLCD. Instead those update document data are being reconstructed by read access compatibility views based on ACDOCA. Hence attributes from ML data model, relevant for a pure inventory subledger functionality, are part of table ACDOCA.


This is made by this DDL source: V_MLHD_UNION:


@AbapCatalog.sqlViewName: ‘V_MLHD_UNION’

@ClientDependent: true

@AbapCatalog.compiler.compareFilter: true

@EndUserText.label: ‘Helper View for MLHD Compatibility View’

define view V_Mlhd_Union_Ddl as

//—————————————————————————————————–

//  Part 1: Read all original ML documents directly from MLHD

//—————————————————————————————————–

    

  select from mlhd as hd

    {

        hd.belnr      as belnr,

        hd.kjahr      as kjahr,

        hd.vgart      as vgart,

        hd.awtyp      as awtyp,

        hd.awref      as awref,

        hd.aworg      as aworg,

        hd.awsys      as awsys,

        hd.storno     as storno,

        hd.umbew      as umbew,

        hd.bldat      as bldat,

        hd.cpudt      as cpudt,

        hd.cputm      as cputm,

        hd.usnam      as usnam,

        hd.tcode      as tcode,

        hd.glvor      as glvor,

        hd.logsys     as logsys,

        hd.pvers      as pvers,

        hd.xcobl_cons as xcobl_cons,

        hd.bktxt      as bktxt,

        hd.kongr      as kongr

        //Extensibility Pattern for Generation additional fields

        //<$VJ>

        //<$JOINS>

        //<$VJ>

    }

union all

//—————————————————————————————————————–

//  Part 2: Add now all UP-parts, but only for non-actual costing materials (MLAST = 2)

//          and only if there are postings in BSX lines

//

//          The rule is:

//          Non actual cost materials with transaction type UP (Material Ledger Update) have

//          no items in the original ML-document any longer

//          Therefore we have to reconstruct these from the ACDOCA

//          But we reconstruct only the BSX fieldgroup for the non-actual cost materials

//          e.g.: Debit/Credit (MR22) for a 2,S material:

//          The UP part is: PRD <–> UMB, as this is an S-material we have no BSX line but a PRD line

//          and hence we will not reconstruct the MLHD, MLIT

//—————————————————————————————————————–

  select from  acdoca as it

         left outer join finsc_ledger as ledger on  ledger.rldnr    = it.rldnr

                                                and ledger.xleading = ‘X’

                                                and ledger.appl     = ‘FI’

         left outer join bkpf as bkpf on  bkpf.bukrs = it.rbukrs

                                      and bkpf.belnr = it.belnr

                                      and bkpf.gjahr = it.gjahr

                                

//       Connect ADOCA entry with probably existing MLHD (UP entry) for using MLHD-BELNR as BELNR of CompatView                                   

         left outer join mlhd as mlhd on  mlhd.awtyp = it.awtyp

                                      and mlhd.awsys = it.awsys

                                      and mlhd.aworg = it.aworg

                                      and mlhd.awref = it.awref

                                      and mlhd.vgart = ‘UP’

  {

//      if an MLHD-entry has been posted use its document number, otherwise use the CO_BELNR from ACDOCA

        key case

          when mlhd.belnr is null then concat( substring(it.co_belnr, 1,8), ’00’)

          else mlhd.belnr

        end as belnr,

        key cast(substring(bkpf.cpudt, 1, 4) as abap.numc( 4 ) ) as kjahr,

  

        ‘UP’            as vgart,

        it.awtyp        as awtyp,

        it.awref        as awref,

        it.aworg        as aworg,

        it.awsys        as awsys,

        ‘ ‘             as storno,

        ‘ ‘             as umbew,

        it.bldat        as bldat,

        bkpf.cpudt      as cpudt,

        bkpf.cputm      as cputm,

        it.usnam        as usnam,

        bkpf.tcode      as tcode,

        bkpf.glvor      as glvor,

        it.logsyso      as logsys,

        ‘    ‘          as pvers,

        ‘ ‘             as xcobl_cons,

        bkpf.bktxt      as bktxt,

        ‘   ‘           as kongr

        //Extensibility Pattern for Generation additional fields

        //<$VF>

        //<$FIELDS>

        //<$VF>

}

//      take only postings materials with ML active and MLAST = 2

//      actual costing materials (MLAST = 3) are contained in part 1      

        where it.matnr <> ”

        and   it.mlast =  ‘2’

  

//      only BSX postings are relevant

        and  it.ktosl = ‘BSX’

          

//      Ignore ACDOCA records of price change transaction:

//      For the compatview of all ML documents: Price Change ML Docuemnts are taken from part 1 of the union (MLHD) directly

//      Because MR21 (price change) has only one ML document with VGART = PC

//      while MR22 (debit/creadit) has two ML documents (VGART = PC => Unition Part 1 ) and (VGART = UP; AWTYP = PRCHG => Union Part 2)

//      And same logic for MR23 like MR21, because also MR23 has only one ML document, it is its own Prima Nota like MR21

//      MR21  ==> BTTYPE = RMPR

//      MR23  ==> BTTYPE = RMBK 

        and it.bttype <> ‘RMPR’

        and it.bttype <> ‘RMBK’     

    

//      List of all prima nota categories that are ML relevant          

        and ( it.awtyp = ‘RMRP’  or

              it.awtyp = ‘BKPF’  or

              it.awtyp = ‘WBRK’  or

              it.awtyp = ‘MKPF’  or

              it.awtyp = ‘AUAK’  or

              it.awtyp = ‘PRCHG’ or

              it.awtyp = ‘MLDUV’ )

                   

//      take all fields of the select clause in the group by    

        group by mlhd.belnr, it.co_belnr, it.awtyp, it.awref, it.aworg, it.awsys, it.xreversing,

                 it.bldat,bkpf.cpudt,bkpf.cputm,it.usnam,bkpf.tcode,bkpf.glvor,it.logsyso,bkpf.bktxt

4. Run CKM3N

Despite all changes happened in Material Ledger, CKM3N runs without any problem and issue, this is great. Compatible layer works for ML..

S4CORE_ML_SARHAN_120.jpg

In order to reflect all actions I have consumed 5 peices to a costcenter by using Movement Type 201.

Conclusion

SAP is re-designing Financial and Logistics, S4CORE contains all these changes: new code line and new database structure. But Congrats to SAP that all these changes are runs smoothly and existing  transactions (I have tested limited scope, but covers some important cases)  runs as they run before, despite all these simplifications.

These deep dive sessions will be continued…

Cheers,

Sarhan.

To report this post you need to login first.

3 Comments

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

  1. Prabhat Kumar

    Hi, When you say ” I have activated Material Ledger, otherwise system does not let you create any Accounting related view” , just wanted to know whether you need to run CKMSTART also after activating ML as usual or just ML activation in OMX1, system allows you to create Accounting view.

    Thank you..

    (0) 

Leave a Reply