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 program called : 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.
