SAP FICO Corner

COPA Top-Down Distribution using the new Fiori app "Manage Allocations"

2025-12-27T15:16:00.000-05:00

A few months ago, I started working on a client business requirement to do Allocations in Margin Analysis (formerly known as COPA or Profitability Analysis) to allocate certain overhead costs using the COPA Top-Down Distribution functionality. I worked with it several times in the past with the old KE28 and lately with the new "Universal Allocation" functionality using the new Fiori App "Manage Allocations".

The business requirement that I had was a bit unique that I did not know if it was even possible to achieve it. Finally I was able to make it work, so I decided to make a post out of it since, as usual, I like to post things that I did not find on the Internet so the community can benefit from it.

We will start from the beginning with a bit of details about it ...

As a previous step for this Top-Down Distribution Allocation (TDD), we did a Margin Analysis - Overhead Allocation from Cost Centers into a high level Profitability Segment like Company Code and Profit Center using an Assessment Allocation Cost Elements (In our case, an account starting with 942xxx). Once we had executed this Overhead Allocation, that will leave us the postings in a high level Profitability Segment that will then be picked up by the TDD.

The TDD will spread (re-post) the values on a proportional basis based on Ex. Sales Qty (KG in our case). This reposting is done within the same Allocation Cost Element / GL Account (Ex. 94200200 – Distribution Costs). At the end resulting in a reclass within the same account. So, each Sale transaction record will be used to have its proportional / fair share of those Overhead costs being allocated.

We had 2 different type of business requirement that we can summarize like this.

2 different types of TDD,

• Simple (Cost from Cost Center are Allocated / Spread based on the Sales of the same Company / Legal Entity)

• Complex (Cost from Cost Center reside on Legal Entity A but are Allocated / Spread based on the Sales of the Legal Entity B)

Note: the term Simple and Complex are not SAP terms.

The Complex TDD was the one that was quite unique and the 1st time I faced such a requirement, so I was not even sure it was possible nor I was able to find anything online that would indicate that. Thus, the reason for my Blog today.

Simple TDD

This is how we will build a TDD Allocation cycle for a "simple TDD".

Will create the Cycle with code, description and a Valid to date.

A TDD Cycle can only have 1 Segment, different to the other types of Allocations that allow for multiple segments.

Based on “posted amounts” (actuals) and variable proportions.

Senders we leave it as-is, no changes required.

Here we need just a few dimensions, not all the ones available for Sender Basis. So, we will need to remove a few of them and leave the ones above.

Account number: We will use the specific group called TTD_CE created for this that contains all our Allocation Cost Elements type 42, since we used more than one Assessment account starting with 942xxx. By doing a group, we can re-use it for other cycles easily and we don't need to enter all accounts manually.

Our Company Code is 1000.

Remember ... prior to this, we had our postings already done at a high Level Company Code and Profit Center.

Receiver we leave it as-is.

This is where we will match the “Sender” data with the “Reference data” (our Sales).

Variable Portion Type: QUANT1 – Quantity 1, so based on our Sales Qty.

Profit Center: ALL VALUES , to take into account all Profit Centers

Same for Functional Area and Segment.

Account Number: will put our Sales Account. In our example 41000009

Now at the far right, each Selection Criteria characteristic has an icon that we need to click to expand our input for the "Reference Base" (Our Sales data matching).

Profit Center Mapping, we need to do a 1:1 for all Profit Centers involved on the Sender and Reference side.

For Accounts, we will map every account that is part of the TDD_CE against our Revenue account (like above)

If we have more than 1 Revenue Account, then we can create an Account group that will include the several revenue Accounts. This will be used in the “Selection Criteria” and in the “Reference Base Mapping”.

Company Code 1:1

Functional Area, Segment, etc. ALL to ALL.

Complex TDD

In the “complex TDD” scenario, we want to Allocate (spread) the Expenses / Costs of one CoCode, but based on the Sales of another CoCode. Ex. Allocate Compay Code A Expenses, but based on Company Code B Sales.

The creation of the Cycle is the same as before for simple TDD scenario, with minor tweaks.

Sender Basis in this case is for the Expenses of Company code 2000.

Receivers stay the same.

Receiver Basis stay the same as in the Simple TDD scenario, being the Company Code 1000 (the one with the Sales).

With this Reference Base Mapping setup 2000 Sender and 1000 Reference Data, we are telling the Allocation to use the Costs of Company Code 2000 and reference it with the Sales of 1000. Just this little tweak in the Reference Base Mapping is key for this cross Company Code Reference Data to work.

Note: the Allocation postings will still remain in the same Legal Entity / Company Code, in our case 2000 and will not be generating any Cross Company Code postings. It is just for the reference calculation the Cross Company Code specification.

All the other Reference Base mapping still apply the same as in the Simple TDD scenario. The only one that is different is the Company Code one (like above).

Note: Margin Analysis Top-Down Distribution Cycles CANNOT be downloaded and/or uploaded using an XLS Template like the other Allocation Cycles. Instead, they will have to be created manually in each environment (Ex. QA and PROD). But, once 1 Cycle is created, a COPY function is available and then you can modify the parameters for that cycle accelerating the creation.

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or need advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com

Creating a Mass report for Actual Costing CKM3n beloved transaction

2025-06-27T09:57:00.000-04:00

For those of you that work or have worked with Actual Costing, I am sure that you have used, and continue using every day, Transaction CKM3n - Material Price Analysis. This is the go-to report / transaction to analyze the costs and actual costs of a given material during an accounting period. This is "the bible" for Actual Costing information on Materials.

The transaction is really nice, it gives you a lot of information on Receipts, Production, Consumptions, Deliveries, Revaluations on a Standard basis as well as including Actual Costs. There is "almost" nothing better out there in standard SAP Actual Costing than this transaction. But ... it has a very big limitation, you can only display 1 Material at a time in 1 Plant and for 1 Accounting period at a time. There is no other good transaction for many Materials. If you are dealing with multiple plants and multiple materials, then it is going to be hard to do multiple analysis. (some would mention KKML0 as an alternative, will there shortly ...)

Another good piece of information that this report provides you, is the breakdown of the figures by Cost Component (considering you have activated Actual Cost Component Split in your system).

As you can see above, you get a lot of valuable information like Beginning Inventory, Revaluation, Receipts, Consumption and finally Ending Inventory; which is also something really nice that many Cost Accountants would need (All the In's & Out's during the period).

Note: To be able to obtain all these calculations in CKM3n, you need to be using Actual Costing and running it on a monthly basis. Otherwise, this transaction will show you only "Price History" information which is line by line each transaction, the standard cost, quantity, etc. Only with actual costing you will have calculated beginning and ending inventory and their corresponding "price difference" (Actual costing).

Now if you want to do a Mass report for the information in CKM3n, you will have to build a custom report for it; which I will explain you what will be your source tables for this information.

In the picture below you will have a more detailed and exploded view of the different categories in CKM3n

You can easily reproduce these with the 3 Tables below, which I will explain each of them:

FCML_MAT_V

FCML_REP_V

FCML_CCS_REP_V

Will start with the 1st Table FCML_MAT_V

This table has the "Master Data" type of information (Ex. Plant, Material #, Description, Valuation Class, Profit Center, Company Code and the most important one "Cost Estimate number", among some.

If you are also dealing with Customer Stock or Project Stock, you also have the Stock Type, Sales Document and line item number as well. Same as you would need to enter in CKM3n.

Next Table FCML_REP_V

The link between the 2 Tables is the "Cost Estimate Number". Here you also have a way to restrict by Posting Period, Fiscal Year and Currency Type (10 for Company Code, 30 for Group this will depend on your Material Ledger currency setup). If you do not restrict the data, you will get for that same material all accounting periods out there for all your ML currencies.

These should be part of the available selection criteria in your future query.

Once you restrict your data, you will see that this table shows the different Categories that you get in CKM3n (Ex. Category AB will represent your Beginning Inventory, ZU - Receipts, ... and EB - Ending Inventory).

Note: Unfortunately there is no check table for the Category list of values as this is a Domain with a list of values. These are the different values

Each Material / Plant combination will have many records for a given period because of the multiple categories. (so eventually they need to be aggregated)

In the example below, you will see side-by-side CKM3n and the corresponding FCML_REP_V record.

You could clearly see the "Total Stock BUn" column representing the Quantity for Beginning Inventory (Category = AB), and the "Total Val" representing the $ amount. Then you can continue with the other Categories like VN - Consumption and EB - for Ending Inventory.

For Ending Inventory (EB) you will need to aggregate (sum) multiple EB records to obtain the Total Value, Quantity and in this case the CKM3n Settlement line (Actual Costing) for ending inventory value, is represented by column "1LvLPrDif". Which it will apply for Beginning inventory for next period. (In my records, I did not have a settlement for beginning as it was my 1st data period).

For Consumption (VN), you will also need to aggregate more than 1 VN record. Again, the Price Difference column or in this case what would show in CKM3n as a revaluation line, will be represented in column "1LvLPrDif".

Finally, the 3rd and last Table FCML_CCS_REP_V

This table represents a deeper level in our CKM3n information. This will give you each of the prior inventory movements categories broken down by Cost Component.

Same as before, the link is Cost Estimate Number. Of course, this table also needs to be filtered by Posting Period, Fiscal Year, Currency type, etc.

You most likely need to aggregate records as you might have several for the same Cost Component and category.

Here you will have in the field "Cost Component" the component code and then you will also have the Cost Component text description already.

This Component breakdown is what you will normally see in the far right of your screen within CKM3n transaction.

In the image below, you will see how in this example the records in Table FCML_CCS_REP_V match the consumption line of the Cost Component 20 (see Table and CKM3n side by side and highlighted).

The Cost component amount is the sum of either PRCDIF_VAR Crcy field or PRCDIF_VAR_S field.

In the case of another Cost Component like 110, is the sum of 2 fields, so you need to include Fxd Value as well. So, at the end, it is better to aggregate and sum both fields for any of the scenarios. This one has a value for Fxd Value (because this component is about fix costs, and the prior example CC 20 was about variable costs).

Now that you have all the necessary Tables that provide CKM3n equivalent numbers, you are ready to build your query. With the help of a good Abaper, he can easily join these 3 Tables and turn them into a new CDS view that ultimately can be turned into an Analysis for Office (AfO) query or he can even encapsulate this into a Fiori App using SAP Web Dynpro. I personally prefer AfO or the old Design Studio that would be easier to drag & drop on a pivot table like navigation. Web Dynpro has replaced it, but I prefer the old one that uses less square footage in your screen.

Not sure if you realize, but all these 3 FCML* tables are also standard CDS views that SAP has built. I just don't understand why SAP has not turned them into a proper report and/or Fiori App yet for Material Ledger reporting. They should do it already !

Note: I said before that one alternative to this could be to use Transaction KKML0. In my personal opinion, should not be something to be used now a days in S/4 HANA (but there is nothing better yet). This uses a really old SAP technology, "Drill-down reporting" which also uses Report Painter behind the scenes (even older ... 😠 ). You could obtain part of the same information, but not with Cost Component. Then when you will try to export it, it results in a tremendous amount of columns because every combination of CKM3n (row & column intersection) will end up as a column. Not really nice at the end.

What needs to be activated for the FCML* tables to work ?

Oss Note "2441212 - ML Drilldown Reporting - use CDS views FCML_MAT_V, FCML_REP_V" explains it. It also mentions that this is only available on S/4 HANA versions 1610 and higher for Plants with Activated Material Ledger Actual Costing.

What the Note also says, is that once that in place, KKML0 (Material Ledger drill-down reporting) will be using these series of CDS views. So at the end, my solution is tapping into the same set of Tables. But, if we encapsulate or expose these CDS views to be used in AfO or in a Fiori App, you end up having a way better front-end than the classic Drill-down reporting.

There are quite a few Oss Notes talking about these series of ML tables too.

www.dnabusinessconsulting.com

Using S/4 COGS Split when shipping to customers out of non-Manufacturing Plants

2025-03-27T15:07:00.004-04:00

Starting from S/4 HANA version 1709 and upwards, SAP introduced a new functionality for COGS (Cost of Goods Sold) split when posting your a PGI (Post Goods Issue) automatic journal entry.

Up until this version and traditionally in SAP ECC version, we would post a 1 liner COGS entry for the total standard cost of the material (* Qty) of the product being delivered to the customer. This was the standard in SAP and has been like that since SAP existed. Many other ERP systems do the same, posting of the Cost of Good Sold entry is done with just 1 line to represent the COGS. Also, when we were using Costing based COPA, we would create as many Value Fields as Cost Components we had and when performing the Billing the system will post into COPA this sort of COGS Split among the different value fields. But from a pure GL posting perspective, this was not yet possible.

Our Journal Entry used to be like below:

Debit - Cost of Good sold (PL)

Credit - Inventory (BS)

Now a days, the recommended approach with S/4 is to use Account based COPA and not Costing based COPA anymore. Account based is the way to go today.

(Note: you can still use Costing based, but it is not the recommended approach anymore for new S/4 greenfield implementations. For the old SAP guys, like me, we grew some grey hair trying to explain the "unbalanced" situations of FI vs. COPA. So, we don't want go back to those days anymore).

By using this new functionality, the system would create a 2nd Accounting Document right after your PGI posting that would offset the original COGS account and Debit your different COGS Splitting accounts that you would have configured to show your different Cost Components that you defined in Product Costing configuration (OKTZ).

Example:

Debit - COGS Cost Component 1

Debit - COGS Cost Component 2

Debit - COGS Cost Component 3

Debit - COGS Cost Component NN

Credit - Cost of Good sold (PL)

Now, the purpose of my posting is not to talk about how to configure this specific functionality. For this, you can find other nice posts that have been written on this topic by colleagues of mine.

I can recommend this one from SAP Press

https://blog.sap-press.com/how-to-split-cost-of-goods-sold-cogs-with-sap-s/4hana-finance

The purpose of this post is how to make COGS Split happen when you ship to your customers out of downstream Distribution Centers and/or 3PLs Plants / Warehouses.

When you ship to your customer from your Manufacturing Plant, and you activated COGS Split, it will naturally post your COGS Split.

But, many companies, have a downstream series of Warehouses, Distribution Centers and/or 3PLs that receive their goods from the Manufacturing Plants via Intra Company STO's (Stock Transfer Orders). And, only from there they ship to their customers.

Since these Warehouses were not the ones that manufactured the goods, you would normally don't have Cost Estimates there that would allow you the possibility of having calculated Cost Components to eventually derive that. In that case, you will have to use another Product Costing functionality that will be used when setting up your materials at these Warehouses. This functionality is called "Special Procurement Key for Costing".

With the setup of these key/s, you will specify, from which Manufacturing Plant the Warehouse will pull his costs and with that, it will also inherit the Cost Components Split. So then, when doing the PGI from the Warehouse, the system will have a Cost Component Split in that warehouse and will be able to post accordingly.

This is how you would configure this Special Procurement Key:

IMG > Controlling > Product Cost Controlling > Material Cost Estimate with Quantity Structure > Settings for Quantity Structure Control > Material Data > Check Special Procurement Types (Tcode OMD9)

Here you will define a new "Key" where you will specify:

Procurement Type = "F" for External Procurement (Plant P001 will get its cost externally from another Plant. By externally, it does not meant from an outside Vendor).

Special Procurement = "U" for Stock Transfer (via STO).

Plant = Ex "CD00" the Plant that it will be getting its cost passed from.

Note: that 1 Special Procurement key will be needed per Plant. So if you have 10/20 Plants retrieving its costs from CD00, you have to configurate this 10x/20x. The good thing is that since it is Plant specific, you can name them all with the same code / key. Ex. each of the 20 Plants will have its own Z1, easier for organization purposes.

One Material, can have its costs derived like this from 1 Plant at a time since this key is assigned in the Material Master at the Plant level. In our case at P001 we will assign ZD.

Once you have this, you will be able to create / assign to your Material Master record this Special Procurement Key in the Costing 1 Tab.

After setting up your Material Master record, the last step you will have to do from now on, is to include in your Costing Run all the downstream Plants for which you configured and assigned Materials to this Special Procurement Costing keys.

When you calculate your Cost Estimate for a Material, you will clearly see (below in yellow) that Plant P001 is deriving its cost from Plant CD00 (same Material number).

Note 1: You do not need to setup BOM and/or Routings in these downstream Plants to achieve this, just the Special Procurement Key for Costing. BOM and Routing remain necessary only for Manufacturing Plants.

Note 2: In this model, we are not considering any value added like Freight and/or Customs to the inventory value when moving from one Plant to the other, we are staying at the same cost. This can be achieved with other functionalities that are not part of this post.

Now when posting a PGI from Plant P00, you will have exactly the same effect and type of postings that you would achieve as if you were PGI'ing from a Manufacturing Plant and will show the Cost Component Split posting

Material Document for Movement Type 601 - Delivery to Customer will create 2 Accounting Documents.

First Document, posts the traditional COGS posting.

Second Document, posts the COGS Split posting as you defined in your COGS Split configuration but in this case from Plant P001 which is Distribution Plant and not a Manufacturing Plant.

Note: the COGS split configuration is done at the Company Code level, no configuration is required on a per Plant basis. Once done, it will apply to all Plants within that Company Code.

If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

www.dnabusinessconsulting.com

SAP Inventory valuation - Working with MTO but valuating as MTS

2025-01-16T07:30:00.012-05:00

Glossary acronyms :
MTO - Make to Order
MTS - Make to Stock
SO - Sales Order
BOM - Bill of Materials

When working with MTO -Sales Order stock, the inventory is held specifically for that Sales Order and valuated as per the original Sales Order costing that happened when you created the Sales Order and Costed it.

Now, if you are working with MTS materials that can become MTO and vice versa all the time indistinctively, this could create a challenge. Why ?

Imagine a Sales Order created 3 months ago in September with certain costing (Ex. $100 /tn) , now you are getting into a new Fiscal Year and preparing your Standard Costing for the next year to come. The result of your new Costing calculation (CK11N/CK40N) gives you $105/tn for the same material.

Once you finish your Mass Costing run and you "release" the new standard, it will revalue your Inventory. But this will only apply to your MTS stock and will not revalue your MTO Inventory "held" inside the Sales Order.

Many of you will tell me that CK55 - Mass Sales Order Cost and CK51N - Sales Order Cost exist, yes indeed they do. But, they will ONLY cost your Sales Order (the document) and you will only see the update after doing the costing in the condition type EK02 of your pricing procedure for that SO line item. But what none of these 2 transactions will do is re-cost the inventory on-hand that you have for that specific Sales Order.

In standard SAP, MTO inventory is supposed to last for a "finite" amount of time and the assumption is that as soon as you produce it you ship it (or shortly after). That way you are not supposed to have on-hand inventory for too long that would require to re-cost this in the event of a Mass recosting exercise (Ex. for a new Fiscal Year to come). So SAP, does not contemplate the possibility of revaluing MTO inventory on hand.

*** This solution will not be applicable for all types of MTO situations, only to customers that move around their products between MTS to MTO and viceversa constantly, which we know it is not the true spirit of an MTO ***

Standard SAP MTO configuration uses Requirement Calss 046 - MMTO config value.

This Requirement class uses Account assignment category M and Valuation M - Separate valuation with ref. to sales document/project. This Valuation M is the key one here that indicates that the valuation is in reference to a Sales Document (Sales Order) or a Project. It also uses Costing ID = B - Automatic costing and marking which makes that your Sales order gets costed and marked automatically behind the scenes when you save it. Costing Variant, specify your specific Sales Order costing variant that you use or configured for Sales Order costing (not the object of this post to talk about Costing variants). In case you use Costing Sheet in your design, you will put it here too .

Finally Costing Method = 1 is for Product costing (based on a BOM) in contrast to 2 Unit Costing.

The rest of the fields are not really relevant for my example and scenario.

Now, with a few tweaks and changes, we can create a new Requirement Class that will make the system behave and valuate your MTO inventory as if you were in MTS. (Needless to say that you will not modify the standard delivered 046 Req Class and you will create a Z or Y one. Golden rule in SAP that you should never break).

This will be the new Req Class for MTO as MTS. (see below in next image)

As you can clearly see, it has been decluttered quite a bit and we do not need many of the prior options.

The key field change here is the Valuation that went from M (Separate valuation with ref. to sales document/project) to A (Valuation without reference to sales document).

Without Val. Strategy also needs to be flagged which will also make the valuation work as MTS.

The rest of the fields are not needed Costing ID, will not cost within the Sales Order anymore as you are using MTS Materials. Costing method, not needed too, can be left blank. Costing Sheet and Costing Variant, either

Now that you have that configured, all your Logistics processes will still behave as if you were in MTO. Your Inventory movements will still need to be done at Material, Sales Order and Sales Order line item as before. But, from a Financial valuation point of view, these will be handled from now on as MTS.

When you will display your Material Price Analysis (CKM3), in case you are using Actual Costing it is more relevant this Tcode, you will not have to enter the Sales Order stock option to display your inventory value, as the inventory is all handled as if it were an MTS from the Accounting point of view. Logistics wise you will still see it as MTO (Ex. in Material Documents and MM related reports).

Material valuated as MTO with Special Sales Order stock (before)

Material valuated as MTS but for MTO Sales Order (after)

Below you will see the line item of the Sales Order displaying my new Requirement Type ZKEM on the line item of the "Procurement" tab.

Remember, your Material Documents and movements will still need to be done and reference a Sales Order Line Item, but Financially it will not and all the inventory is going to be bundled together with your MTS stock from a Finance valuation point of view.

www.dnabusinessconsulting.com

Actual activity rate calculation with Cost Splitting

2024-02-03T11:41:00.000-05:00

I decided to publish this Blog post because I could not find anywhere else on the Internet any other post for a scenario like the one that I will describe here.

There are several posts on Activity rate Actual calculation out there, but none of them is using an "Splitting Structure" for multiple activity types withing the same Cost Center. All of them are based on the assumption that 100% of the Cost (rate) of the Activity type covers 100% of the Costs incurred in the Cost Center.

This post is going to describe how you setup an Splitting Structure when the incurred costs of a Cost Center are represented by several Activity Types at the same time.

Ex. If you look at the "T" Account or a Cost Center report for a given Cost Center and you have 30 different Cost Elements (GLs) expenses being posted in that Cost Center.

Normally, you would have 1 Activity Type (& rate) that will represent the entire 30 expense accounts and that will offset 100% of those costs when doing Activity confirmation. That Cost Center will receive credits from it that should offset the entire Cost Center costs.

But ... in certain cases, business do not want to have 1 Activity Type (rate) to offset those 30 different expenses, they want several ones 2, 3, or even more Activity Types within the same Cost Center. In that case, the usage of the Activity rate actual calculation, would require you to setup a "Splitting Structure" to be able to achieve this and have the actual activity rate calculated properly within that Cost Center.

You will start by defining a "Splitting Structure", follow the IMG path above.

First, create "Splitting rules" where in this case we will split based on "Activity quantity".

Then create a "Splitting Structure", Ex. Z1 too.

Note: Part of the descriptions are masked for confidentiality reasons.

Then create 1 line per Activity Type that you will have within that Cost Center. In my example above, I had up to 7 Activity Types within the same Cost Center that I needed to split and take into consideration for my Actual Activity rate calculation.

When you create each line, you assign them the Splitting rule that we created before that was based on Activity Quantity.

Once the line created, you go one level deep and create the "Selection for assignment".

This is where you will establish which Cost Element/s range or group will represent a given Activity Type. You also need to specify which Activity Type goes with for this assignment combination.

In this example, I had a CE group ZS_LUNLAB that goes with LUNLAB Activity Type.

By doing this, when running the calculation, the system will "pair up" the Actual expenses of those CE's in that group with the total costs posted / offset of that Activity Type to be able to later calculate the actual.

Once you have this configuration completed for the several Activity Types, your Splitting Structure configuration is completed.

Activity Type Setup

The Activity Type needs to be setup in a specific way for actual calculation

Tcode KL1, 2, 3

The Activity Type needs to be setup with "5" to be able to calculate the price automatically.

Version configuration

You need to configure your CO - Version accordingly per Fiscal Year (FY) to be able to have the Actual Activity price working as well.

"Revaluation" fields needs to be setup with either 1 or 2 option, 0 will not revalue.

1 - The differences between allocations valuated with plan and actual prices are posted under a separate transaction (actual price calculation). - Like a Delta posting

2 - All actual activities revaluated with the actual price; original allocation changed. The differences between allocations valuated with actual and plan prices are not shown with this option.

Execution

We will start by running a Cost Center report to understand what Actual debit expenses where posted during the month at my specific Cost Center and what were the Activity Type credits that were posted as a result of the Activity confirmations derived from my Production execution.

Because of given business reason, we had 1 Cost Center that "concentrated" all the expenses and with allocations from many different Cost Centers we were posting the Debits into this one Concentration Cost Center. All the Activity Types were also assigned to these 1 Cost Center too. Thus, 1:1 relationship that you can easily see here in my Cost Center report. This is only an example, and it is not always that straight. In many cases, you will have 5/6/7 Cost Elements, for a given Activity Type offset.

As per the Cost Center report, you could see that the total expenses posted were $34,273.33 while the Absorption Credits posted by the Activity Types confirmations, where $33,623.33 and were not able to 100% offset the actuals (by $650).

For this, we will calculate Actual Activity rate calculation that will recalculate all the Activity rates to be able to fully offset those actuals and end up with the Debits equal to Credits on the Cost Center report.

1st step before doing the calculation, we need to do a 1 time (per Fiscal Year) setup to assign the previously configured Splitting Structure to my CN599 Cost Center, so the system knows to which Cost Center this Splitting Structure will apply (it can be more than 1 Cost Center too if it applies).

Execute Tcode OKEW and assign it.

It says "All versions" but we are only doing it for version 0

Once done, SAVE and the assignment is completed. You need to repeat this every FY.

The Actual Activity Type calculation is a 2 step process. First, you calculate and second you post the newly calculated transactions with the new rates.

1st step - Tcode KSS2

Enter the Cost Center that you want to split & recalculate, period, fiscal year for calculation and execute.

If you look at the total results, you will easily recognize those numbers from the previously executed Cost Center report.

Control Cost & Actual Costs columns represent all my Cost Center Debits.

The Actual Cost Balance column, represents the Total Credits done by the activity type postings.

Allocated Actual column, represents the difference that I still need to allocate.

Then within the lines of this report, you will find all the different Activity Types that were posted during the month with their corresponding actual quantities. If your Splitting Structure was properly mounted, your Allocated Costs will properly reflect the right proportional amounts on each line.

Make sure your Structure covers 100% of Cost Elements involved in the Cost Center and 100% of the Activity Types that credited that Cost Center. If for any reason, the structure has a "hole" and does not covers 100% of any of these 2, then your numbers are not going to be properly calculated for all the Activity Types, not just 1. So this is really important.

As a suggestion, in the Splitting Structure when doing the assignment configuration, I strongly recommend you to work with a CE group. This way, you can easily add new CE's in the group without the need of a configuration, transport, testing and the whole bureaucracy of changing configuration on a Production system.

Once this step executed (without test mode), you are ready for the next step which is the Posting.

2nd step - Tcode: KSII

Actual Cost Center postings showing that during the month we only had 0.144 Qty for this LUNLAB Activity Type.

Note: If you are using Actual Costing, the allocation cost element from an Assessment like 9042119 needs to be added to the corresponding Cost Components Structure (OKTZ) even if they are not being used for Costing. (This is only applicable in case you are using Actual Cost Component Split, like in my case)

Calculation Result of KSII (done in test mode in my case)

New determined rate for LUNLAB is $ 73,321.74

Total Costs in the Cost Center to offset $ 10,558.33 (show in prior reports)

Total Activity Qty occurred in period 0.144 hr.

10,558.33 / 0.144 = 73,321.74 is (will be) the new rate calculated by the system for LUNLAB

Note: My numbers are really odd because I did not a lot of activity type quantities posted to be able to end up having a rate that would make sense, but you have to follow the math.

Now If I were to remove the "test mode" the system will go back to every single Production Order that had this LUNLAB (and other Activity Types too) and repost everything at the new rate instead of the standard rate that I had from KP06.

To be able to properly determine Actual Activity Type rates, having 7 different Activity Types within the same Cost Center and them being covered by a series of different Cost Elements, is only possible by setting up the Splitting Structure in the way that I described before; otherwise it will not be able to "split" your costs properly among the different activity types.

www.dnabusinessconsulting.com

Fiori App "Production Cost Analysis" status mismatch versus SAP GUI

2023-09-11T16:25:00.001-04:00

I recently run into this while testing the new Fiori App "Production Cost Analysis" and wanted to share it with the community.

This new Fiori App, has a somewhat "weird" or new way to deal with Order statuses as we were used to in the past when we would display them in GUI (Ex. CO03).

If you see my 1st screen capture, my Production Order 10004582, shows with status "Closed" in the Fiori App. Which for me it was an issue right away when I saw it, because I knew I did not Closed (CLSD) this Order yet.

If you display this same Order number in GUI Tcode CO03 (2nd screen capture), you can clearly see the highlighted Order statuses as being REL - Released and DLV for Delivered. But nowhere in the Order statuses you will see CLSD - Closed.

Is the Fiori App working properly ? YES

Is this some sort of bug in the App that needs to be reported and fix ? NO

Is there any OSS Note that fixes this issue ? NO

No, this is not a bug and the Fiori App is working properly (as per SAP design).

According to OSS Note 3295371 ( APP F1780 "production cost analysis" doesn’t show correct order status ), this works as intended. It considers the status DLV - Delivered that the order has been completed and therefore is Closed as in the Fiori App.

Being used to the traditional Order statuses, this makes me a lot of noise and is a bit misleading as in the backend the order is not even TECO - Technically Complete yet, and the Fiori App already shows it as Closed.

This could lead to several issues and impacts if not understood properly.

No TECO in the orders. Orders could remain in those statuses for ever. You will need to use other reports to make sure the shop floor people TECO them. (I know you should not use this report to analyze order statuses, but still the mismatch is what bugs me ...)

Same case for real CLSD - Close that should be put in the Orders after a period of time.

I find it weird, but I guess that only for the purpose of analyzing "Production Variances" a DLV status means no more work on the order. But from a technical point of view, this status will not prevent the shop floor from continuing using the order and book costs against it if they want.

Below is the OSS Note and an extract of it where it explains this situation.

OSS Note 3295371 - APP F1780 "production cost analysis" doesn’t show correct order status

https://me.sap.com/notes/3295371

Please compare order number XXXXXX (Status ID = REL) in the system. In SAP GUI (t-code COOIS, CO02/3, COR2/3, etc.), the manufacturing order has more statuses which some are relevant and others aren't relevant for the FIORI app (usually CRTD->REL->PCNF->CNF->DLV->TECO->CLSD etc.).

In the Fiori app, the manufacturing orders with the 'Released' status [REL] (or partially released [PREL]) but not 'Delivered' [DLV] or 'Technically Completed' [TECO] or 'Closed' [CLSD] statuses are considered as 'OPEN.' The orders with DLV, TECO, and CLSD statuses are considered CLOSED in the Fiori apps.

The order gets OPEN since it's released, and later it gets status CLOSED once TECO, DLV or CLSD status is set. These two statuses: OPEN and CLOSED, are available for selection in the smart filter dropdown box (Open, Closed, Open and Closed).

www.dnabusinessconsulting.com

Practical use case of SE16H with a quick Query to understand Material account determination (FI-MM)

2023-07-29T16:06:00.002-04:00

INTRO

The days of using SE16N (or even the old SE16) should be over now and you should now embrace the new evolution of it. The new SE16H !!! "H" for the HANA database era and capabilities.

This new version (SE16H) offers grouping capabilities, sorting, aggregation (like COUNT for counting records) and one of the most important one, JOIN capabilities. Now you can JOIN other tables to retrieve the content or descriptions that you can find in other satellite tables or Header to Line items relationships in one big Query / Result instead of jumping from one to another.

In the past we used to execute several Queries with SE16N (or SE16 for the old folks), download to Excel and then VLOOKUP those values to join them and or get descriptions. Now you can do all of that directly in SAP with SE16H in one step.

QUERY

This Query will allow you to quickly understand and give you more information about all your FI-MM account determination from your system by providing GL account descriptions and Valuation Classes names,

FI-MM Account determination configuration can be found in Table T030.

Once in SE16H, go to "Outer Join Definition" and create a new one. Provide a Name and a Name / Description.

Then add Table SKAT - GL Account Master record descriptions by clicking the green add icon with the "+" on the 1st table for "Definition of Secondary Tables".

Once added click on the "Output" icon (same as the Multiple selection icon for reports). This will allow you to select which fields you want to output from your "joined" SKAT table in your final query results. Accept and you will go back to the prior screen.

Then on the 2nd part of the screen (Selected Secondary Table) you have to enter the different fields that you need to join both tables. In our case, I am looking to display the GL accounts descriptions / names that I have in Table T030 as there is no way that I would know them by hard by just looking at T030 directly, and there are quite a few of them.

Enter SAKNR on Table field, select Method "Reference" (as you will reference / join it with the value of table T030), Reference field KONTS (GL account) from Table T030 then Table T030.

Add 2 other lines for KTOPL (Chart of accounts code), but in this case it will be as a "Constant" and value 0001 as my Chart of Accounts is 0001. Note: don't put this value as '0001' or you will get an error in your query, you do not need the colons for a constant as you would do while writing code.

Then add SPRAS (Language) as you are bring Text descriptions from a Table (SKAT) that is language dependent. In this case E for English and not EN. E for the technical unconverted value for English language. If you are not sure of your language technical value, display SKAT first in a separate SE16H window to know yours.

Finally, I want to add a 2nd table that will show me the Valuation Classes descriptions, as there are several and you do not always know them all by hard. Follow the same process but in this case for Table T025T (T for Text table for original table T025 Valuation classes).

Save your "Join Conditions" and then go back to SE16H main screen and select your "Outer Join Definition" name that you just created and Execute.

You can also select which fields you want to output from T030 in this main screen too. Then you can save your "layout" and re-use it next time in conjunction with your Outer Join definition.

At the end, after adding the 2 tables for GL account and Valuation Classes descriptions, your end result will show you all the T030 records with their corresponding descriptions for GL and Valuation classes. This will help you understand your FI-MM Account determination in a better way.

PS.: It is a shame that we do not have a table to get the descriptions for the field "Transactions" / KTOSL that would tell us what BSX, GBB, PRD, WRX, etc mean that we could add here too. But as an SAP Consultant, we need to know them or have proper notes / documentation with their meaning and usage.

Addition:

Table T030W - For Transaction key (Ex. GBB, BSX, AUM, etc)

Table T025T - For Valuation Classes descriptions

www.dnabusinessconsulting.com

Some banks can't deal with characters with accents and special characters, how to remove them with no-code ...

2023-04-11T12:00:00.006-04:00

Recently, while doing a banking implementation with a US bank, I run into an issue that never had before. It caught my attention and thought it was worth sharing it because it is quite specific that I am sure it is going to benefit someone.

I was doing payment files testing with a US Bank (a really big one) for my client's US and Canadian operations and because my client also operates in the province of Quebec, Canada (where we also speak French); we run into some particular issue because we have data with French accented characters.

It is really common in the French language to have accents on people's name, streets and companies too. But this bank's systems where not able to handle and read our files because of this "special characters / strange characters". Many times bank's systems are so antiquated that they are still running mainframe servers that were conceived in the 80's easily. Many of this servers and operating systems do not have the ability to handle some of this characters and even had a complete different code page too. In some of this cases, since we were passing them ASCII files (as per their request), their systems were not interpreting these characters and adding an extra space to the line record. This was making the record longer and therefore failing.

These are some of these "special characters" (Ex, À Á Ã È É Ê Ì Í Ò Ó Ô Ù Ú Û à á â è é ê ì í î ò ó ô ù ú û ).

Now there are 2 different scenarios that I had where I needed to remove this special characters, one without code and another one with.

# 1 - DME file creation (Ex. Electronic Payments, Positive Pay or any type of Banking file)

#2 - Check printing

# 1 - DME file creation

In this scenario we were creating 2 different types of files for this bank, an ASCII Positive Pay file and an XML ISO 20022 payment file. The ASCII one was the one that the bank was not able to process properly.

In order to remove the 'special characters' on the DME file, you just need to flag one option on the corresponding field and the DME engine will take care of the rest.

Ex. I want to remove the 'special characters' from the Vendor Name (PayeeName1 field in my DME) that is part of the output file.

Select the Field name (Element or Atom) and click on the "Conv.Function" icon. You will get a pop-up like this one (see below).

Here you have a series of options to right justify or left justify your characters. Then on the 2nd part, you have the option "Replace National Chars". This option will allow you to replace these series of "accented" characters by no accented ones by executing a standard FM behind the scenes. (which opens the door to talk about my option #2).

#2 - Check printing

I mentioned that the output file was related to Positive Pay, so in this case, we needed to have a exact match file vs. printed check otherwise the bank was going to reject our checks. So, we also needed to adjust our check forms so that the printed names do not have these accented characters either.

To do this, we will be using the exact same Function Module that is available in the DME engine, but in this case calling it via code.

FM SCP_REPLACE_STRANGE_CHARS

You can test it here to see the results before incorporating it in your code.

Here you will see how in the Input text I put all sort of accented characters and the FM returned all the same characters but without accents. The same can be executed in your forms or any other Abap program to remove these characters.

Bonus track ...

You can also use program RSCP0155 that has a selection screen where you can play with more sophisticated options like input and output code page and range of Unicode characters. Then this selection screen will end up executing this same FM and returning all the input characters and converted characters for the whole ASCII code. So you can see upfront what your characters will look like after conversion.

Part of this Post is based on OSS Note

1062237 - Transliteration of characters with SCP_REPLACE_STRANGE_CHARS

https://launchpad.support.sap.com/#/notes/1062237

(requires a valid SAP Marketplace ID to display the Note)

www.dnabusinessconsulting.com

SAP Bank keys for North America - Implementing banking & electronic payments

2022-12-04T17:56:00.147-05:00

I decided to write this blog post because over the last 2 years or more, I have been working on a number of projects / clients where I had to take over or use North America SAP Banking configuration of prior SAP consultants (in many cases "just configurators"). Unfortunately, I have seen a series of recurring mistakes being done by the majority of them because of the lack of knowledge of the North American banking system and common practices (for USA and Canada). Many of these consultants were either local or offshore and from different Big 5 consulting / implementation partners and some smaller SI's as well.

These series of recurring mistakes are due to the lack of knowledge of what it is a "Bank Key" in SAP or what it should be and what it is used for.

Bank Keys in SAP are used for two different things and places:

Identify our own House banks where our own (Company's) bank accounts are registered / created
Pre-requisite piece of Master Data information to be able to register Banking information for either Vendors and/or Customers to be used for Electronic Payments.

Bank Keys in SAP are created by country and their number will depend on certain rules and conventions that are specific to that particular country that you are creating the bank key for. One country will not use the same Bank Key and naming convention than another country. It will all depend on that country's Financial System. The Bank Keys are then going to be used to be able to perform and route electronic payments, if you do not create your bank keys properly, your electronic payments will not be routed properly or will be rejected by your bank because you are not providing the right and expected information to your bank.

Canada Bank Keys

Canadian Bank keys, look similar to US bank keys, but are completely different one to another. Canadian Bank keys are made of 2 different pieces of information, the first 4 digits represent the Financial Institution number assigned in the Canadian Banking / Financial system with a leading zero.

Ex.

0003 - Royal Bank of Canada
0004 - TD Canada Trust
0001 - Bank of Montreal
0010 - CICB - Canadian Imperial Bank of Commerce
0002 - Scotia Bank
0006 - National Bank of Canada

What is a Routing Number?

A routing number identifies the financial institution and the branch to which a payment item is directed. Along with the account number, it is essential for delivering payments through the clearing system.

EFT Routing Number

An Electronic Fund Transactions (EFT) routing number is comprised of a three-digit financial institution number and a five-digit branch number, preceded by a "leading zero".

Example : 0XXXYYYYY

0 : Leading zero
YYY : Institution Number
XXXXX : Transit / Branch Number

The electronic routing number is used for routing electronic payment items, such as direct deposits and wire transfers.

Example of an SAP Bank Key record for Canada

As you can see, they are created by Country Code (Ex. CA, US or MX). Then the Bank Key is numeric for Canada as described above.

Then you have the Bank Name and address information, SWIFT Code (8 or 11 long) and the Bank Number for Canada is equal to the Bank key number entered.

The Bank Key should never be defined as the "SWIFT Code", there is another field to define the SWIFT code.

Below is a Void cheque image for a Canadian type of cheque where from there you will be able to pick the right routing information for a given Bank Account or Vendor information for you to properly create in SAP to ultimately execute electronic payments.

USA Bank Keys

The routing number (a.k.a. RTN or routing transit number) is a 9-digit number that serves to identify the specific financial institution responsible for the payment of a negotiable instrument.

In same cases in the US it is also called ABA routing number (American Bankers Association #).

Where is the routing number on my check?

The sample graphic below shows where the routing number can be found in the bottom left corner of your checks.

Routing number format

The routing number consists of 9 digits:

The ABA Routing Number is of the form XXXXYYYYC

XXXX is Federal Reserve Routing Symbol
YYYY is ABA Institution Identifier
C is the Check Digit

Read more about the Routing number at Wikipedia website.

Example of an SAP Bank Key record for USA

What is a SWIFT Code?

SWIFT code (also known as ISO 9362, SWIFT-BIC, BIC code, SWIFT ID or SWIFT code) is a standard format of Business Identifier Codes approved by the International Organization for Standardization (ISO). It is a unique identification code for both financial and non-financial institutions. (When assigned to a non-financial institution, a code may also be known as a Business Entity Identifier or BEI.) These codes are used when transferring money between banks, particularly for international wire transfers, and also for the exchange of other messages between banks. The codes can sometimes be found on account statements.

The SWIFT code is 8 or 11 characters, made up of:

4 letters: Institution Code or bank code.
2 letters: ISO 3166-1 alpha-2 country code
2 letters or digits: location code

if the second character is "0", then it is typically a test BIC as opposed to a BIC used on the live network.
if the second character is "1", then it denotes a passive participant in the SWIFT network
if the second character is "2", then it typically indicates a reverse billing BIC, where the recipient pays for the message as opposed to the more usual mode whereby the sender pays for the message.

3 letters or digits: branch code, optional ('XXX' for primary office)

Where an 8-digit code is given, it may be assumed that it refers to the primary office.

Business Partner

Once the Bank Keys have been created in Tcode FI01 (Create) 02 (Change) 03 (Display) or in Fiori App "Manage Banks", they can be used in the assignment and definition of our own House Banks and also for Business Partner (Vendor / Customer) Banking data under the "Payment Transactions" BP tab.

A given Business Partner can easily use the same Bank Key as our own House Bank if this BP also has a Bank Account at our own same Bank branch. In that case, you do not need to create a 2nd bank key, as we are talking about the same record that will be used in both scenarios.

As you can see in the image below, Bank Key CA - 000300002 needs to be previously created before being able to assign it to Business Partner 1000009. (In some cases, it can be created while doing the BP creation but you still need to provide all the same Data (Ex. Country, Key, address, SWIFT, Bank Number).

Common Mistakes done creating Bank Keys

When defining Bank Keys, I have seen several mistakes done by SAP resources that have all sort of downstream impacts in the system configuration and later on while interacting with the Banks:

Defining the Bank Key using a SWIFT code
Defining the Bank Key as consecutive numbers
Thinking that the Bank Key that is used by the House Bank is different from a Business Partner Bank Key
Modifying SAP standard country settings to force bank key of a different length or type (alfa or numeric)

Defining the Bank Key using a SWIFT code - A NO, NO !!!

Not knowing what should be the Bank key or what a bank key looks like for a given country, has led to many SAP Finance resources to define them using the SWIFT codes as if it were the Bank Key. This in most, if not 100%, of the cases is never correct. The Bank Key is normally used as a key piece of routing information by the banks to execute payments and most of the standard DMEE's (Electronic Payment files) map and use them at a certain point inside the DMEE.

If instead of providing a numeric Bank Key, we provide the SWIFT code, then the bank will reject our payments and we will not be able to pay vendors.

Below you will see a screenshot of a configuration done by a Consultant from a Big SI (really big) that because he/she did not know how to define properly a Bank Key for our own House Banks, he/she had to end up hardcoding in the DME config the Bank Key because the Bank was rejecting their payment files. Standard SAP DME config passes the Bank Key created in Tcode FI01 (Table BNKA), this was due to him/her using the SWIFT as Bank Key for the House Bank, which is absolutely wrong.

He/She ended up harcoding and putting a DME condition (IF) based on the country, to pass a constant. That should have been the Bank Key that is is "hardcoding here" if he/she should have done it properly from the get go.

Defining the Bank Key as consecutive numbers

At another client, I have seen Bank Keys being defined as consecutive numbers (Ex. 1, 2, 3, 4 ...) without any logic and without respecting what it should be used for that Country as per the Bank Financial System. This will also generate an issue like in the above previous example when passing routing information to the bank in the DME files resulting in payments being rejected.

Thinking that the Bank Key that is used by the House Bank is different from a Business Partner Bank Key

As mentioned before, Bank Keys for House Banks and Business Partners (Vendors / Customer) are and should not be different from one another. They are a piece of Master Data (Bank Master) that can be used by either of them.

At this other customer, the consultants did not advise the client properly, and the client was defining a series of Bank Keys for own House Banks and another one completely differently for Business Partners. This is another big mistake, also done by the same Big SI.

Modifying SAP standard country settings to force bank key of a different length or type (alfa or numeric)

I have also seen in some of these prior customers, that these SAP resources have modified standard SAP delivered country settings (Table T005) to force and allow them to entry Bank Keys that are different in length to the one that is supposed to be entered for a given country or to enter alphanumeric Bank keys when the Key should be numeric.

Modifying SAP standard delivered country settings should be a "NO-NO !", unless you really have a compelling reason to do so. While working with some Banking Directory Services, you might have to do it, but in most cases it is part of the instructions that they provide you; so you have proper justification for it.

Data Migration for Bank Keys

Bank Keys are a pre-requisite Master Data object before being able to create Business Partners, in that you are planning to perform electronic payments to Vendors / Customers (BP's). You need to build and have this data prepared and loaded before starting to create Business Partners.

Also, our own House Banks will need to have these specific Bank Keys created previously so then you can configure the House Bank/s (in Tcode FI12_HBANK). So you will need them as part of your configuration. Normally these are just a few (3, 4 or 7, 8 records) that you can create them manually or you can build yourself a small LTMC file just for your configuration.

S/4 HANA Data Migration Cockpit has a standard Data Migration object called "Bank Master" that can be used to migrate these Bank keys, either for your configuration or for your BP's. In most of the cases, you will end up with 2 different files. 1 small one for your config that you will also have to upload before you transport your House Bank and migrate (upload in S4) your Bank Accounts and then a 2nd file which should be bigger that will contain all the Bank Keys needed for your BPs, as they are a pre-requisite.

Understanding this is really key to have a successful Data Migration approach for Business Partner Bank Keys that should be completely different for the Bank Keys associated to your House Banks. Unfortunately, I have also seen a lot of people confusing them.

Banking Directory Data services

Dealing with Bank Key Master Data and having clean Bank Keys data is key in case you want to implement Electronic Payments in SAP and avoid payments being rejected. Collecting these info from your Vendor (or Customers) should be part of your Business Partner creation process, but if you are doing it for the 1st time, collecting the data from them and also having the Bank Keys uploaded in the system could be quite an effort.

Having payments being rejected by your bank, will cost you money as banks charge you for rejected payments and also could create issues with your vendors because they will not receive your payments on time and eventually they could cut services or goods delivery if you do not pay promptly.

There are certain companies and services out there in the market that can sell you Bank Directories that can be uploaded in SAP and will be ready to consume. Same as you would upload the Data with the Data Migration cockpit or maintain it manually.

Some of these services, are quite costly, but really convenient.

SWIFT Bank Directory: quite expensive but so far the best one and easy one that I have used. Comes with a file ready to load in SAP with standard SAP Bank directory upload program. They provide Worldwide financial institutions information, not just for 1 country.

Accuity Bank Directory: expensive as well but require the installation of custom Abap programs to upload in SAP (provided as transports by them). Their information is not that easy to deal and upload compared to SWIFT. They also provide Worldwide financial institutions information.

Canadian Payment Association (CPA): Their service is called "Financial Institution branch directory". I have not used it for a while, but they used to have a file ready to be uploaded in SAP with standard programs, same as SWIFT. They seem to only provide Canadian banks info, not worldwide as SWIFT or Accuity.

If you are looking to find some individual Bank Routing information for free out there on the Internet, there are some pages that give you (one at a time) information that you could use as Bank Keys info for Canada and US.

http://canada-banks-info.com/

https://us-banks-info.com/

Defining your Bank Keys properly is KEY for your House Bank configuration and your Electronic Payment setup in SAP and ultimately for a successful banking implementation.

Consultants that have the right banking knowledge for the country and market that you are trying to implement is vital for this. Not all consultants know about this and end up taking the wrong decisions that have many ripple effects down the road. In the majority of those cases, those consultants never stick around long enough to see the unintended consequences of their lack of knowledge and experience in the subject.

www.dnabusinessconsulting.com

From customization to standardization in SAP, how to avoid falling again into traps from the past

2022-08-24T15:19:00.002-04:00

The world of large ERP implementations where we were starting from a blank page and doing several months of blueprinting sessions are far gone. Organizations do not have that luxury and those types of budgets anymore. Now we need to focus on Rapid deployment, lean and standard processes.

How were we used to do SAP implementations in the past?

We used to do large implementation projects with 7, 8 or 10 Consultants for Finance, another similar number for Materials, Sales and so on. At the end all adding up close to 100 hundred SAP Consultants easily. And we were not implementing SAP at Walmart, just at a normal company …

We would do 4 to 6 months of Blueprint sessions where we would look into every single thing out there in a process and configure SAP accordingly and mimicking the legacy process into SAP configuration. We would configure even the smallest things that SAP allows us to configure (Ex. Optional or required fields on Finance Posting Keys, changeable fields on a posted Finance document, just to name a few of those ones out there, but the list could be big). All because we had the time and budget to do it and an “open bar” policy for these type of things. And these were the standard things that SAP configuration allowed us to do.

Then we would look into all sort of business requirements that were not standard SAP and we would do custom developments for them. Tons and tons of lines of Abap code for custom reports, custom Transactions, customize SAP standard delivered screens and even customize and append Standard SAP Tables because the business had a requirement.

(Before you jump, I would never, ever recommend customizing an SAP screen or appending a standard SAP table …)

This would lead to months of development and testing and re-testing, many times even all the way up to the cut-over weekend because some of those developments were complex and intricate. In some cases putting more than one go-live at risk ( … I am sure you can relate to some of these examples and you are now remembering some cases in your mind …)

Then after go-live, you would continue doing new developments over the subsequent years whenever the business would come up with a new requirement. Instead of analyzing the situation, trying to find solutions within standard SAP and adapt the process; NO we would develop something new. A new “Z” Transaction and new “Z” field and new Z something.

You end up after a couple of years of following this approach in a complete ZAP environment (SAP with Z), where you do not recognize the system anymore. Everything that the users do starts with a Z, transactional or reports, all would start with a Z.

Several years ago, I remember working for a customer; where it took me a while to adapt to their SAP system. You would click SAVE and a bunch of things were happening in the past that would change the complete behavior of the system. Screens that had extra fields that you would not recognize because there were not part of SAP standard. And the worst thing is that most of this was not documented anywhere because it was done many years ago and they did not have a lot of discipline. It was in someone’s head that luckily could still be around or not. This client had been in SAP for 15 years at the time. Coming easily from SAP versions 3 or 4. The amount of custom at this client was insane. (And it is still that way because they are still using their old ECC).

Another client, in complete different industry…. We went to do an assessment to implement S/4. They too have been using SAP for ages … We were analyzing their processes and we asked them to provide us the list of Z Tcodes and Z reports to analyze them and see which ones we could replace with standard SAP. They came up with more than 150 just for Finance, Materials and Sales. 150 custom developments are a lot. Someone would say, I have seen more than that. Oh yes, I have seen more than that too. But it is still a lot …

Some of these clients they have even customized and created their own entries in the IMG, with custom IMG options to maintain all these extra customizing that they have created over the years. Customized the IMG !!! A bit too much.

And I have a couple of other similar examples too of big companies but not as big as a Boeing or Walmart.

How much does it cost to maintain all of that? A lot !!

What is the impact of having all of these undocumented solutions? It cannot be measured

Then you bring outside people (like me at one of these clients) and for someone that knows SAP, all of a sudden, he needs to learn it all again. That has a cost for organizations too that have to pay for that long ramp-up period.

These has other consequences too. All of these clients cannot do upgrades anymore because it would cost them a fortune; more than doing a brand new implementation. Some are still stuck in versions 4.6 or 4.7 that are way out of maintenance from SAP. This client even ended-up hiring a company from India that provides support for SAP environments that are out of maintenance. Like a generic aftermarket auto-parts manufacturer but for SAP solutions.

These customers cannot comply with new legal requirements delivered by SAP via OSS Notes and for sure they cannot benefit from new developments or new technologies as well.

Now, what can we / you do to change that?

Not easy and definitively it takes time …

Over the years, SAP has run out of opportunities to sell new implementations to the Walmarts, Boeings, Airbus of the world (just to name a few). All the big guys and not so big too they were already in SAP. Those big ones are the ones who, “to some point”, they can still afford to have big implementations. But the others, no. So, they started looking some levels down in the pyramid to sell projects. But those companies did not have the same budgets and luxury that the big guys had. They needed to find a new approach for that market.

That is when we started seeing more and more implementations in the market using the Best Practices packages from SAP, with pre-delivered configuration for different scenarios, with pre-built configuration guides, process flows and testing scripts. All this pre-built material helped reduce the costs and accelerate the delivery. Many of the Consulting companies had picked up these documents, added their own logo, fonts, colors, added some of their own flavor and would sell them to customers as “accelerators”. Many are still doing it with every version.

We were starting from a good base, and we did not need to configure everything from the ground up.

But this was fixing some part, but we were still doing a lot of custom developments.

Some companies started seeing and putting all these variables together:

high or impossible to upgrade costs,
high maintenance costs of their own customization developments and
lack of standardization

In the meantime, SAP launched SAP Simple Finance which later turned into S/4 HANA with their In-Memory Database. Promoting digital Transformation, Machine Learning technologies and a completely new UI like Fiori that would simplify the user experience making it in line with the type of intuitive user interfaces that we have today in our cell phones.

They also replaced their ASAP Methodology by their new “SAP Activate Methodology”. This new methodology got away from the traditional waterfall approach and got closer to Agile but still with certain reminiscences from waterfall.

For these clients something needed to be done, they wanted to be able to adopt new technologies. They were in outdated platforms too at risk with the OS and their Databases too.

As I mentioned before, some of these clients were (and a lot still are); in systems that are way beyond salvation, there is no “brownfield” option for an upgrade … So a new “greenfield” implementation was the only way out for them. Complete re-design from scratch.

This was the tipping point for them.

So they said, “… Let’s do a “greenfield” implementation … but how can we avoid falling into the same traps and making the same mistakes we did 20 years ago?. The industry has changed and those big & gigantic SAP programs where everything could be customized cannot be executed anymore. There is no more money and time for all of that.

As I mentioned, SAP Activate is Agile with a flavor of waterfall (a mix of the best of both worlds).

Within the methodology, as key part of this Standard vs. Custom approach is in the “Fit to Standard Analysis”.

We stopped doing detailed Blueprint workshops and started to do “Fit to standard” workshops.

The business users would explore the SAP best practices and standard business processes such as order-to-cash, procure-to-pay or hire-to-retire that are mapped for S/4HANA

We would show them the standard SAP delivered processes, show the fit on the client processes or see where their processes could fit in regards to standard and then question and challenge the parts that were not a fit.

In plain words we would ask “… Mr. Customer, tell us why you cannot use this standard process to do “xyz” and you need to customize it. Please justify it … ”

Out of those “Fit to standard” exercises a list of gaps would emerge. There are 2 possible solutions for them Adopt or Adapt.

· Adopt the SAP process and become standard.

· Adapt but using SAP standard configuration and still remain standard.

These last 2 would have some process reengineering and change management to do.

OR …

· Adapt the system and customize / develop a tailor-made solution.

A complete fit-gap exercise ensures greater visibility of the gaps that the standard S/4HANA is unable to offer. In such cases, a fit-gap strategy decides if a system’s enhancement, a customized application, or activating a business add-in will address the identified gaps.

This is where companies should make a shift on their approach.

These companies implemented rigorous revision processes before approving any custom developments.

They created “design review committees” where they would scrutinize each and every single development asking Why is it needed? How will it be done? And most importantly, What happens if we don’t do it? What is the monetary impact? What is the business impact if not done? Is there a standard workaround that could be used instead?

Custom developments like some of the ones that used to be done in the past by some reckless consultants that would modify standard SAP code, are completely out of question. Even putting enhancement spots.

Some are going even further these days and the moment they hear something starting with Z, they shut it down right away. I personally faced this to address a business requirement where we would use a series of standard function modules and BAPIs but all wrapped up in a Z program. I was not even allowed to present it to the committee.

This process needs to have rigorousity and needs to be unbiassed for at least 2 main reasons.

1. Keep your project budget under control, otherwise you end up with an endless list of custom developments that put you at risk to meet your go-live date. AND

2. Avoid over customizing your system beyond the point of no return, like I described earlier where some systems become ZAP (SAP with a Z) and you cannot upgrade them anymore unless you are willing to invest a fortune on it.

These “design review or design authority committees” are made of different technical and non-technical people such as Solution Architects, Development Team Lead, System Integrator executives, Integration Managers, some line of Business executives and other individuals with many years of experience too. Another member of this committee is SAP itself. Clients would hire SAP Max Attention services to be part of this decision making process of reviewing these developments to add another level of scrutiny and legitimacy.

In some cases, during an S/4 HANA assessment project we had SAP Max Attention within this committee early on when we were doing the proposal for a future project, and we had to justify every custom development in front of them for them to provide an opinion to the customer if the development was justified or not.

In other cases, Max Attention was an integral part of the project on an ongoing basis and was a permanent member of this committee.

The committee will act as the guardian of your solution, protecting you from yourself, protecting you from falling into the old habits of deviating from standard SAP solutions and overly customizing your system.

In many cases, this will get a lot of business people upset and feeling that they are losing functionalities and information. This is where you will have to work redesigning your process and in change management with your people.

But this strategy will pay off in the long run as you will stay within standard SAP, and allow yourself the possibility of doing upgrades and adopting new technologies as they are released by SAP.

S/4 HANA on-premise is a system that has been constantly evolving since its launch in 2015, every year there is a new release with new features and functionalities. Staying standard will allow you to adopt them faster and reduce maintenance costs too.

Remember:

You have a decision to make …

Do you want to address every single business requirement not matter if it requires doing custom development, making you spend a fortune, increasing your maintenance costs and putting you at a disadvantage for an SAP upgrade? This should be part of the past way of doing business.

You prefer to reduce implementation costs, reduce your maintenance costs while staying standard, invest in change management and process reengineering and allow you to adopt new functionalities and technologies faster whenever they are released? This should be your future vision and approach. Today this should be a no brainer decision for all organizations.

www.dnabusinessconsulting.com

Understanding S/4 HANA Adobe Forms for Functional Consultants

2022-07-06T15:59:00.001-04:00

SAP has used over the past (many) years different technologies and development languages to build outputs / printouts for different processes (Ex. PO printout, Customer Invoice and/or Check printing and many more too). Some of these technologies can still be used if you want, but now a days you have better, easier and a more robust technology that can be used. This is Adobe Lifecycle Forms in S/4 HANA or some call them Adobe forms.

In the past, we used to do many of these mentioned outputs with SAPScript technology. These was ok for that time, but it is a little bit of a tedious language and adjusting drawings and positions takes a lot of try & error and definitively not really user friendly. Also, if you needed extra information that was not part or accessible in the original SAP delivered form; you most likely needed to create a "custom print program" to be able to accommodate the extra info or logic needed. We all know by know what custom means in terms of future upgrades and maintenance costs ...

Then after SAPScript came Smartforms, which it was the 1st possibility of dealing and producing Adobe PDF type of outputs. I worked with it a bit, but unfortunately being a Finance consultant I still had to deal with SAPScript as Smartforms was not widely available or used in Finance. It was more available for modules like SD for their Customer Invoices and related outputs.

But today since the inception of S/4 HANA, SAP has introduced a newer, better and more user friendly technology called "Adobe Forms".

Before being able to use this technology, some technical pre-requisites need to be in place in your S/4 HANA environment which your Basis and infrastructure team will have to work on it first. For this to work, you will an ADS Server (Adobe Document Server) to be installed in your landscape. And this runs in JAVA, so you will need to install it in a JAVA based server. I know from the past that the PI/PO server was JAVA based, so a couple of clients were sharing it for both technologies. Once that is in place, then they will have to connect them and after that you will be able to start using it. If you try to use it without this being in place, you will get a lot of errors and you will not even be able to display a form nor create one.

It is funny that I have to highlight that, as one would think this should be standard out of the box for any S/4 implementation; but apparently it is not ... This year, I went into a client where another SI was kicked out for doing a terrible job, and among many of my findings were that these guys designed all the outputs by still using the old SAPScript technology and the ADS server was non-existent in the client landscape.

Note: Don't ask me more technical questions about the ADS server as I am just a Functional guy, not a Basis resource.

How do we use and deal with these forms in S/4 HANA ?

As we were used to before with SAP, they have delivered a series of standard forms for each of the available outputs for the different processes that we can always leverage to start from them and add / remove / modify them as we see fit as per client requirements. Like adding a logo, changing columns or adding extra information that is not standard delivered.

As usual and in proper development practices, you should "never" modify an SAP standard form. You should ALWAYS create a copy and work with your own custom form.

To access these forms, you can use Tcode SFP and enter (or search) the form name that you want to work with.

In my example, I will be working with the Vendor Payment Advice form which is a typical form that we use in Finance for payments.

Then you go Display and you will start looking at the definition and design of the Form.

Within the Context tab, you will see a lot of the Structures that the form deals with and their individual fields that are available for the form to be added in the output.

Here you can browse through the different Structures and fields and can take note of any extra fields that you might want to include in your customized form to add it to you Functional Specification document so then your Abaper can add them.

From my example (Payment Advice), you can clearly identify these structures as being the ones that are also available when we execute payments or when we build or deal with DMEE's. So any field that you want from those structures can be added to your form. There are fields at the header level and line item as usual. Same for any other forms for any other processes.

If for example, I want to add to my form "Payee Bank account #" and "Payee Bank Name", I just need to provide those technical field names (ZBNKN and ZBNKA) to be added to the form.

Another possibility that you have, is to go to the Properties Tab and double click in the Interface name (Ex. FI_FPAYM_DATA). These will bring you another screen where you can then display the Structures definitions that we were seeing in the prior step in a more technical way as if you were displaying them in SE12.

Or, you can copy the Interface name and paste it right when you call Tcode SFP in the Interface field and display it. (Same result).

After you double click in any of the Type Name's for the Import Form Interface, you will see that structure the same way as you would see it in SE12 with all its technical definition, data type, length and so on ... Very useful when you want to see how big is the information you will be adding / removing to/from your form.

Next ... If you want to take a look at a draft layout of the final output form, you need to go back to the beginning to the "Layout" tab.

Before you are able to display the form layout in a PDF like way, you need to install Adobe Lifecycle Designer in your computer. In your own PC, not in the SAP server. Without that, you will not be able to display the form here in SFP. You can download it from the SAP Marketplace and then install it.

Then you will see in the center of your screen, a little bit of a PDF display that also contains some technical information about the fields mapping (see below).

When you move to the left pane and drill down in parts of that hierarchy, the part that you are clicking on will get highlighted in the form just beside it in the central part of your screen.

Also, if you see the right bottom pane, you will be able to see the field "binding" (field that is assigned to) for that field too.

All of these information will help you navigate through the form for you to do your analysis on which fields you need to add or remove from your form and provide a better Functional Specification Document (FSD) with detailed information and not just screen fields like I have seen many Functional consultants doing in the past (and still today ...).

Once your Developer finishes doing the changes in the form, you will just need to update the configuration for the process to include the new form name and it will be ready to be called by the system

Finally ...

What if I need to add fields that are not part of the structures that are available already in the form ?

What if I need to add custom logics to derive those fields or read other tables from other modules (Ex. SD or MM) ? How can I do that ?

In the past, to achieve this we needed to end up doing a Z / Custom program. Take a copy of the standard program and modify it as I mentioned earlier on.

Today with Adobe forms, there is NO MORE NEED TO CREATE A CUSTOM PRINT PROGRAM. If you see someone (Abap or functional) trying to repeat those old habits from the past. STOP HIM right away !!! That person has not updated his skills to S/4 HANA.

There is absolutely no need for a Custom print program anymore. ZERO !!!

Any custom logics, fields, calculations, Abap code can be accommodated inside of the form where there is a section for you to put your own code, Form Routines and Data Definitions. I will not tell you how to do this part exactly because I am not an Abaper, but he should go back and investigate that as it is pretty simple to do in Adobe Forms.

Once he added the custom code to the form, you will be able to obtain the expected results and no SAP code would have been modified and this form will continue to be called by standard SAP programs.

This last part is really important, as I have passed through S/4 clients in the last years and I have seen Functional consultants that still asked for a custom print program and also delivered a form by using SAPScript. That should not be the approach for S/4 HANA anymore !

The technology stills exists and is still available for you to use it if you want. But you should not use it as you will be using old technology and not benefiting from the latest innovations. (Can you still work with a Monochrome amber or green screen ? for certain things probably yes. But there are better monitors now a days. So this is the same ...).

www.dnabusinessconsulting.com

Planning in S/4 HANA without breaking the bank ($$$)

2022-03-29T07:53:00.001-04:00

How to do Planning in SAP has changed who knows how many times in the last 15 years. From Classic Planning using the CO Tables in ECC, then adding some sort of planning in BI with NWBC, SAP recommending BPC (Business Planning and Consolidation) and some other variations. Once S/4 HANA was launched, they started pushing for BPC Embedded for S/4 (around S/4 1610 version). Then "cloud season" started and they came up with SAC (SAP Analytics Cloud) which is the latest one that they want you to adopt. But for sure it does not come for free and you have to pay an extra fee / subscription to use this Cloud solution.

Now, if you do not want to break the bank and pay extra for a Cloud solution that you might not want. How do you do planning in S/4 HANA ?

Classic Planning using the old totals tables (Ex. CO Planning, Profit Center Planning, COPA KEPM Planning), it is not the preferred option for S/4. It comes already deactivated out of the box and you have to follow a couple of OSS Notes to re-activate that. Also the new series of Actual vs. Plan Fiori Apps, do not read those tables. So if you try to use them for reporting, they will not show you Plan data. There is a way around it to transfer the Classic planning figures so the Apps can report that data, but not the preferred one either (at least for me).

BPC Embedded for S/4 HANA, could be an option. SAP has recommended it at the time of S/4 version 1610 or 1709 but has moved away from it since and it is not recommending it anymore. In fact they have plan to sunset this one too. Also in order to use this option, you need to have an extra license for BPC Embedded ($$$). Not my preferred one either.

Finally, SAC - SAP Analytics Cloud for planning. It is the new kid on the block from SAP for Planning. More and more "planning stories" are being developed and released every year for it and it became a world on its own. SAP wants you to adopt it. For sure, it is extra ($$$) and you have to pay a subscription to be able to use it.

Now ... I have a solution that is hidden out there that is none of these 3 and will not cost you a penny and comes included as part of your S/4 HANA package and license. It is just a small configuration / activation change and it will become available for you.

The solution

The solution is based on the below 2 OSS Notes and an SAP Help link.

https://launchpad.support.sap.com/#/notes/2503495

https://launchpad.support.sap.com/#/notes/3033876

SAP Help Procedure to EDIT the variable INFOPROV

https://help.sap.com/viewer/74785309615c47a1b7497b1f8942ebd1/1809.001/en-US/3ceafc57bde70f70e10000000a44147b.html

From the Notes

1. The customer could – at system setup – set the default value for the variable /ERP/P_0INFOPROV to Info Cube or ACDOCP.

S/4 HANA out of the box, comes configured with the Info Cube option; which it translates into using BPC Embedded for planning. This is not an option that you would prefer, as it will require you to have an extra license.

If you set it up for ACDOCP, all the Actual vs. Plan Fiori Apps will work correctly and report Plan data.

Also you will be able to upload your Plan data using the Fiori App "Upload Plan Financial Data". This will store the data directly in Table ACDOCP. This applies for COPA Market Segments plan data, Cost Center, Profit Center, P&L, Balance Sheet Planning, Internal Orders, etc.

This App will allow you to plan outside (like in Excel), populate the loading template and then upload it in the App.

Step-by-step setup

Tcode RSPLAN

Click in "Filter" and then in the Filter field, enter any filter which uses the variable /ERP/P_0INFOPROV, for example, any filter starting with /ERP/SFIN_xxxxx and select "Display"

Locate the InfoObject 0INFOPROV (InfoProvider) in the Selections screen area. Choose right next to the Restriction column the "puzzle" icon.
In the View field, choose Variables from the dropdown list

Choose the /ERP/P_0INFOPROV variable in the Variables of Single Values table. Then choose the "pencil" icon to modify.

Note: You are finally in the editing dialog of the /ERP/P_0INFOPROV variable.

Click in the "footprint and yellow arrow" icon twice to get to the Default Value(s) field.

Choose the InfoProvider of your choice and confirm it

InfoProviders for Plan Data

You can use the following InfoProviders for storing plan data:

/ERP/SFIN_R01 S/4HANA Financials: InfoCube for Plan Data (this is S/4 out of the box and will use BPC Embedded for S/4, which we do not want to)
/ERP/SFIN_V20 S/4HANA Financials: Plan Data from ACDOCP
Virtual InfoProvider which stores plan data records in the ACDOCP table, which has almost the same structure as the ACDOCA table. (this is the one we want and that costs nothing ($$$) and does not require an extra license)

This solution will allow you to load data using Fiori App "Import Financial Plan Data" and execute all the reporting Fiori Apps that give you Actual vs. Plan data that will retrieve the uploaded data. If you do not modify this system variable, you Fiori Apps will show NO Plan data figures.

Note: This solution is not Transportable, it has to be done manually in each environment and you need the config to be open to do it.

www.dnabusinessconsulting.com

How to create a Fiori Tile for any traditional Tcode ?

2022-01-09T15:28:00.001-05:00

Something funny happened to me last week ... I thought I have seen it all in terms of "bad SAP resources" but I keep on getting surprised everyday. I had to teach a "Fiori Consultant" how to create a Fiori tile for a standard traditional SAP GUI Tcode so we could execute it directly in Fiori. He/she should know that by hard as this is the bread & butter of Fiori ...

Creating a Fiori tile out of a standard Tcode is something easy if you have the accesses and permissions. In some cases, SAP has not delivered standard Catalogs and Security roles that will contain the Tcode that you are looking for and you will have to create a Custom Tile. Now a days, more and more projects get delivered with Fiori only accesses, which it should be the way to do it now. So, in those cases, you will need to create a Fiori Tile capable of executing a traditional SAP Tcode.

First thing you need to check, is how the Tcode is defined by SAP in its standard.

Execute Tcode SE91, enter the Tcode you want to convert into a Tile and click "Display" (Ex. F-29)

Down below in the "GUI Support" section, you need to check if your desired Tcode has activated the "SAP GUI for HTML" option. If it has, you will be able to call if from Fiori.

Then you will have to open the Fiori App Library and look for your Tcode as you will need to get certain information from there that it will be needed in subsequent steps.

https://fioriappslibrary.hana.ondemand.com/

Going back to your system, open your Fiori Launchpad Designer (not your regular Fiori Launchpad FLP link, this is the "Designer")

Click in "Catalogs" and click in "+" to add a new Catalog.

Assign a Title for your Custom Catalog and an ID, recommendation is to start with Z*. Then <Save>.

After that, click on "+" in the square to Add a Tile to the Catalog that you just created.

Here we will have to enter different information and parameters, some of them will be ones corresponding to your Tcode information from the Fiori App Library.

From the searched Tcode in the Library, go to "Implementation Information" then "Configuration"

From there we will need to use "Semantic Object", "Semantic Action", "Parameters".

Now you will start completing the information in the Tile that you want to add.

Enter your desired Title for your Tcode, subtitle you can put the Tcode so you keep reference, keywords too. Icon you can give any icon you want from the list. Then enter the Semantic Object and Semantic Action from the Fiori App Library and the Parameters-value in Parameters. Once completed, click <Save>.

Next is to "Create the Target Mapping", On the top click in "Target Mapping" then at the Bottom part of the screen click on "Create the Target Mapping".

Here you will have to enter similar information that you collected from the Fiori App Library.

Semantic Object, Action, System Alias and Title. On Application Type, select "Transaction" and then on Transaction, enter your Tcode (Ex. F-29). You can also decide if you want this tile to be called on Desktop mode, tablet or even Phone. Then <Save>.

So in the 1st step you are assigning some information and in the 2nd you end up assigning the real Tcode. I know ... it seems repetitive, but it might have a reason, but I am not that much of a Fiori expert to tell you the difference. I just know enough to get around.

Once the Catalog has been created, we will create a Group where we can include this Tile or any other tile that exists out there from any other Catalog.

Click in "Groups" on top of the screen. Then "+" to add a Group.

Assign a Group Name and ID, in this case I kept it equal to the Catalog but it can be different. This Title is the one that will show in your Fiori Groups assigned to you when you will be navigating.

Click in the square "+" to add a new Group

Then look for your Group name created in prior steps. (Ex Z_AR... )

Once selected it will show you Tiles from that group and you just need to confirm / add them by clicking in the "+" underneath each Tile. Once it turns green, it means you added to the Group.

If you added one by mistake, you cannot unclick it. You need to drag and drop to the bottom right corner to delete it.

Now we have completed the Custom Catalog and Group creation. Next step is to create a Security role that will call them. You might not have enough Security accesses in your organization to create this and you might have to work with your Security person.

Execute Transaction PFCG, enter a Role Name (Ex. Z_AR_TEST_AD) and click in Single role.

Assign a description and <Save> the role. Then go to "Menu" tab, click on "Transaction" -> SAP Fiori Launchpad" and Catalog and Group. Assign the names of the Catalogs and Group you created in the prior steps in the Launchpad Designer. Save the role and get the role assigned to your SAP username.

The result will be that you have the Group "Customer - TEST AD" available within the Group lists in your Fiori Launchpad

Then the only Tile that I had added to my group (Ex. F-29) will appear.

Finally your F-29 Tcode can be executed as a GUI HTML from Fiori.

www.dnabusinessconsulting.com

Edit SAP Finance Accounting period (OB52) in DEV and QA

2021-12-29T11:43:00.002-05:00

Many, many times over the years during my numerous SAP implementation projects I faced this constraint that in non-Productive SAP environments like DEV or QA; the Accounting Period (Transaction OB52) cannot be edited in DEV or QA and those records have to be transported.

Similar to some other tables like Currency rates (TCURR), the Accounting period; is part of a group of tables that are denominated "current settings". This means that even though these Tables are transportable, once you are in Production, these tables content will be allowed to be maintained directly without the need for a new configuration transport all the way from DEV.

Of course this would not make any sense. These tables like Accounting period, Exchange rates, Costing Sheet rates and many more, are key and central to the Financial operations. How would you be able to operate if any time you need to change these tables, you would need a new configuration transport. It would be insane !

For this reason, tables that are part of "current settings" can be updated in Production directly.

But now ... during an SAP Implemenation project, us Consultants and people doing testing in DEV and QA would also need to maintain and change values in these tables. You will need new exchange rates and to close and open your Accounting periods; among many other things. But if you try to do this in an out of the box DEV or QA environment, you will not be able to do it because you cannot do configuration directly in those environments. You will need to do it via a Transport request.

But it does not make any sense either. For this, with a simple small change in the configuration of the Table, you will be able to allow changes in DEV and QA without the need for a transport.

** Attention: this is a Table change, it will require a Workbench transport. If you are not sure what you are doing, please get it done by an Abap developer or Basis Consultant that will understand what he is doing.

Access Tcode: SE54

Table/View: V_T001B_COFIB (for the OB52 Accounting period table. This is your table in case you are in S/4 HANA with New/GL active).

Select "Generated Objects" then "Create / Change"

Once in this screen change from "Standard recording routine" to "no, or user, recording routine". Then save it and assign a Transport number.

Source for this Blog post was: OSS Note "2269677 - OB52 TK430 Client XXX has status 'not modifiable' in test system"

www.dnabusinessconsulting.com

New S/4 HANA 2020 Bank Sub-Ledger functionality config for Electronic Bank Statement

2021-12-05T14:05:00.003-05:00

In S/4 HANA 2020, SAP has released a new functionality called "Bank Sub-Ledger" that will allow companies with a large number of Bank Accounts to reduce their number GL Accounts in their Chart of Accounts significantly and manage them with just a few GL accounts.

Traditionally, in SAP we would have one GL Main Bank Account representing each House Bank and Bank account number (Account ID) combination that you have open with a given bank, plus a series of outgoing and incoming Bank clearing accounts for this combination. These accounts represent your issued checks not cashed by a vendor or Payments that you have received that you have not deposited yet or cleared with the bank. Depending on your business requirements, the different payments methods you have and other situations, you could end up with 4, 5 or 6 of these Bank clearing accounts. We also called them bank sub-accounts. Finally if your account is held in foreign currency, you will also need a Bank adjustment GL Account to post your foreign currency valuation at Month End.

It will look like this

105100 Bank Main account (House Bank)
   105101 Bank outgoing checks
   105102 Bank Incoming payments
   105103 Bank Lockbox clearing
   105104 Bank outgoing electronic payments
   105109 Bank adjustment account

At the end, you will have something that looks similar to this for each bank account that you have on a given Company Code. You might not have Lockbox or checks in some regions, but you will need several of this accounts to have a proper design and flexibility.

Now ... if your Company (Company Code) has many Bank accounts scattered all over the place among different banks you will end up with a large number of GL accounts within your Chart of Accounts dedicated only for your Banks. Total number of Bank Accounts x6. If you have 10 Bank Accounts, you will end up with 60 G/L Accounts only dedicated to this.

With the new S/4 HANA 2020 Bank Sub-Ledger Account, you can reduce this from 60 GL accounts to GL 6 accounts.

There are already several people that have done Blogs about how to configure and use this functionality in SCN and other sites as well. But ... Nobody has posted anything yet on how to configure the Electronic Bank Statement for this Bank Sub-Ledger functionality.

The traditional way of configuring the EBS when assigning GL Accounts to Accounting symbols and using the masking approach, WILL NOT WORK ! It will give you an error when you try to process an EBS file since the system is not able to do the account determination correctly. Your EBS posting rules will just fail.

This was the way to configure your Account assignment to your Account Symbols in the past when we did not have the Bank Sub-Ledger.

As I mentioned, if you do it like this; the system will not find the GL Accounts, the Account determination will fail and you will not be able to do any postings.

Now with the New Bank Sub-Ledger functionality, instead of doing the traditional masking setup, you need to configure it by putting the full GL Account number instead of masking the beginning of the string.

Configuration for EBS with Bank Sub-Leger

Once you set it up like this, the system will start doing the Account determination properly once again.

A few notes:

#1 - There is a possibility to do a Migration from the old way to the new Bank Sub-Ledger. So, if you are Migrating to Bank Sub-Ledger, you will also need to adjust your EBS configuration. Because, most likely the migration program will not migrate and adapt this config it just changes the GL Master Data setup and other transactional tables.

#2 - OSS Note 3007105 from SAP has stated some restrictions and exceptions for this functionality. It cannot be used with Bill of Exchange Banks/Accounts and it does not work with the Foreign Exchange currency valuation process (FAGL-FCV).

This last statement is not 100% accurate to a certain point. FAGL_FCV is still able to take into consideration the Bank Sub-Ledger Open Item accounts and the Main Bank accounts balances to calculate and valuate them. But what it does not give you is a detailed posting that will specify which House Bank and Bank Account ID has valuated, but it will still valuate those amounts properly. So one of the main restrictions might not be that important at all.

I reached out to SAP with an OSS Support message asking if S/4 HANA 2021 had remediated this situation and FAGL_FCV was now working properly and they told me that they have not modified this program yet and that they will not modify it for future versions. Instead, they told me they are planning on releasing an "Advance Valuation program" that will handle it properly. But there is no timeline for that release yet.

www.dnabusinessconsulting.com

How to manage Company Code Registration numbers that belong to other Country different than the one in your Company Code ?

2021-11-12T16:49:00.003-05:00

When you create a Company Code in SAP for a specific country (Ex. US), the Company Code will allow you enter certain additional parameters for that Company Code that are typical for a Country US to have them. (Ex. TIN - Tax Identification Number, and some other registration numbers that are typically required for companies doing business in the US).

For example, for Canada you will need to enter the GST Registration number, PST or QST numbers as well since your Company Code will be in country CA.

This is an important piece of information that is typically needed for Legal requirements in many countries to issue invoices showing your Registration number when you print an invoice or send information to the banks, Tax agencies or other regulatory entities. So this becomes a MUST HAVE to have it available in the system ready to be used by any of these processes.

But now, what happens if you have a US Company Code, that is registered in Canada and you need to enter the GST Number for it ?

In standard SAP configuration, you will not be able to do it within the Company Code Global settings (or Maintain Additional Parameters as of S/4 HAHA 1709), those fields for GST number will not be available since your Company is in country US and that is not required in the US.

How do you enter this in your US Company Code ?

There are 2 options

This configuration to allow you to enter this parameters is based on "Parameters Types" that are preconfigured for certain countries. In the case of GST Number, it is Parameter Type F29T01. You can look for your specific Parameter Type in Table T001I

Option # 1

SM30 on Table V_T001I

Remove country CA for this record "Parameter Type" = F29T01

If you do that, this will make type F29T01 available for any Company Code regardless of the Country. So all Company Codes all of a sudden will have available the GST Number to be entered even belonging to any country in the world. (For me this is not the preferred approach).

Option # 2

SM30 on Table V_T001S4H

Enter a new entry for F29T01 record and assign it to country US. If you look for F29T01, it is already assigned to Country CA as well.

This will allow to enter the GST Number for all US CoCodes. For me, this should be the preferred approach as it only affects Country US and not all countries.

Be aware that this could be overwritten by an SAP upgrade, so it might need to be redone later.

Once you are done with the configuration, you will be able to enter the foreign registration numbers in your Company Code within Company Code Global Parameters or Additional Parameters.

www.dnabusinessconsulting.com

How to send the different Finance outputs via email ?

2021-08-05T13:35:00.004-04:00

A typical Business requirement now a days in today's world is to send certain Finance Outputs via email automatically from SAP as soon as you generate them. In S/4 HANA on-premise (and ECC as well), to be able to achieve this you need to deal with a little bit of custom code that needs to be added and managed in BTE's (Business Transaction Events). These ones are similar to any other User Exit.

As you might know already, there are different automatic processes in SAP that trigger outputs and when these are created, these BTEs will be called and eventually the generated outputs will be sent via email by SAP automatically if you put the appropriate code on them.

I will be talking in these post about 4 different important and key Finance Outputs:

Vendor Payment Advice
Customer Statement
Dunning Notice
Interest

In this post I will NOT explain you how to execute the programs that generate them, what options and/or values to put in the screens. As a Consultant you should know how to run these "user" steps already. There are plenty of content about this on the Internet already. This Blog post is not for that, is to explain you the technical side of what you need to do to achieve sending these Outputs via email.

Each one of these Outputs have at least 1 (some even 2) Function Modules that need to be coded to be able to control if the output goes to the Spool, Email / Internet or Fax (nobody uses a Fax anymore). Other things that you can control too are the Sender email, Recipient email, email Subject and email body text. All of these can be managed as part of your custom code.

These FMs get assigned in Tcode FIBF and are based on a Transaction Event number that corresponds to each one of these different outputs. You cannot reuse the same code for all of them, but the idea and logic can be replicated for all of them.

1st you need to start by "registering" your Product / Output for the ones you will be dealing with. In my case, ZDUN, ZPADV_EM, ZPADV_SJ. But you can put any Product name / code that you want, then you need to flag the "Active" field as well; otherwise it will not be called.

Then once you have your Function Modules with your Custom code, you need to enter the FMs.

You go into Process Modules -> of a customer to assign them.

You make entries in this table to assign here the FMs that you have coded to manage the different options like (sender / receiver email, subject and body text). As you can see, the Process numbers represent the individual outputs.

Payment Advice

Payment Advice has 2 processes 2040 and 2050.

Process 2040, allows you to manage Sender email address, Recipient email address, Mail Body Text and the type of Transmission Method

c_finaa-nacha = '1' - Spool
c_finaa-nacha = 'I' - Internet / Email

For this SAP gives you a "Sample" FM that you can use as a base to copy and insert you own custom code. This is SAMPLE_PROCESS_00002040.

Process 2050, allows you to manage email Subject

For this SAP gives you a "Sample" FM that you can use as a base to copy and insert you own custom code. This is SAMPLE_PROCESS_00002050.

Customer Statement

Process 2310. This one allows you to manage Transmission method, Format (PDF), Mail Body, Mail Subject, Sender and Recipient email address.

For this SAP gives you a "Sample" FM that you can use as a base to copy and insert you own custom code. This is SAMPLE_PROCESS_00002310.

Dunning Letter

Process 1040. This one allows you to manage Transmission method, Format (PDF), Mail Body, Mail Subject, Sender and Recipient email address.

For this SAP gives you a "Sample" FM that you can use as a base to copy and insert you own custom code. This is SAMPLE_PROCESS_00001040.

Interest Output

For the Interest Calculation done out of FINT Tcode, I will refer you to the below Blog post where it explains Badi FI_INT_CUS01 that needs to be implemented to manage all the same things that we did for the other Outputs.

http://sapabapcentral.blogspot.com/2018/12/sending-email-from-fint.html

By the way, excellent Blog this one for Abap resources.

The specific Abap code of each one of these Function Modules need to be done based on your particular case. I am not providing you the code in this Posting. Maybe this will be the subject of a subsequent Post.

** Note: This process applies to S/4 HANA On-Premise (ECC as well) only. For S/4 HANA Cloud the solution is completely different and based on the new Output Management Solution that works with BRF+ technology. I am not aware that this has changed for S/4 HANA 2020 version either. If you know, please let me know ...

Some Reference OSS Notes:

◈ Payment Advice: OSS 1033893, 836169
◈ Dunning: OSS 1042992
◈ Customer correspondence (Ex. Statement): OSS 1360070

◈ Interest : OSS 956981

www.dnabusinessconsulting.com

Send any Material price from one Plant to another without any custom development

2021-05-03T20:57:00.004-04:00

A typical requirement from multiple clients that I had in the past, was to be able to send, copy or propagate Material prices (costs) from one Plant to another. In certain manufacturing scenarios that is not a problem, because one Plant might be manufacturing one product to a certain stage and the other Plant picks it up and continues manufacturing this Material. In this case, the 2nd Plant has a BOM (Bill of Material) that includes the Supplying Plant. This way when you do the Cost calculation, everything flows automatically.

But ...

What happens when you reach the final Production Plant and then you send it to other Plants that are just Warehouses or Distribution Centers ? (with no transformation here)
How do you update the prices in those DCs when your standard costs changes in the Manufacturing Plants, so you can revalue your inventory ?
Is there a way to do it for hundreds or thousands of Materials and multiple Plants without having to develop a mass upload program ? (There is a new Fiori App to upload Material prices from XLS, maybe I can talk about it on another post. But it is not the same as this solution and it requires manual work and to build one XLS per Currency Type that you might have).
How can you avoid doing manual MR21 price changes and tons of copy & paste in that screen ?
How can you avoid doing a custom program development to do this ?
How can you avoid doing an LSMW out of MR21 to automate this ?

Well ... There is a way that I found a few months ago, that works like a charm and does not require any custom developments !!! zero !!!

The Solution

Transaction CKML_PRICES_SEND could do that for you with some extra tweaks ... !

First reaction someone that knows FICO would tell me ... "well it starts by CKML, it is a Material Ledger Tcode, I don't have Material Ledger or I don't want to deal with Material Ledger ...". Even if it starts by CKML, it is not Material Ledger exclusive, it can be used without Material Ledger being active too.

Note: As per OSS Note 646630 - Send Material Prices and BAPI_MATVAL_PRICE_CHANGE usage, this solution has been arround since R/3 4.7 and it is part of the Enterprise Extension EA-FIN. So you can use it in ECC and S/4 HANA any version as well. I am using it in S/4 HANA 1909.

This Transaction is designed to be used with Distributed Systems where you need to send Material Prices to other SAP systems, but with a few 100% standard tricks, no code modification, you could use it within your same system.

This Transaction triggers and Outbound Idoc (Message Type MATERIALVALUATION_PRICECHANGE) that contains all the necessary info for price changes. The Idoc will go out from your system and come back right into as an Inbound Idoc. Once successfully posted, your Target Plant will have its Price updated. It will trigger one Idoc per Material. You have to execute it individually per Target Plant. You could do it for all Materials, or for certain ones, Valuation types, Stock Type, Material Type and many other filtering options.

How ?

Step #1 - Do config in Table VCKML_PRICE_SEND (SM30)

The Target Plant needs to have an entry in this Table, so you need to add it here manually and save it in a Transport. This is the only step that needs to be done in your Golden configuration Client. All the other Steps need to be done individually in the all the Transactional environments (Unit Testing, QA, pre-PROD and PROD).

Step # 2 - Define a Logical System

Tcode SALE or BD54 directly, to create a "fake" Logical System. (This depending on your environment you might be able to do it yourself as an SAP Finance Consultant or you will have to ask your Basis Team to do it for you).

This fake Logical System will be used later in the Distribution Model. We need a "fake" one because within the Model, you could not use as Source and Target the same Logical System, so that is why we have to fake it. If you understand what I am talking about, you might be guessing already how this all ends .... If not, keep on reading ...

In my case my real Logical System is SX4CLNT050, so I created a fake Logical System called SX4CLNTX50.

Step # 3 - Create an ALE Distribution Model

As I mentioned, this needs to be done on each environment as it is specific to the Logical System names that you will have on each environment.

Tcode SALE

Create the Distribution Model

Add a BAPI

BAPI MaterialValuation
Method PriceChange

End result will be like this, where the Receiver server will be your dummy / fake Logical System.

Step # 4 - Create a Port that calls the RFC of your own Client

Tcode: WE21. Before creating the Partner Profiles, you need to define a Port that will be used by the Outbound Idoc. In this case, the Port needs to be pointing to an RFC for the same Client that you are in. In my case SX4CLNT050. By doing this, you will trick the system to send the Idoc to a Port that it is also within the same system (go out, to come back in within itself). This is the KEY part of this whole Solution to make it work.

Step # 5 - Maintain Outbound Partner Profile for Logical System

Tcode: WE20. Here the Partner System (LS) will be the same I input in my Distribution Model and fake Logical System "SX4CLNTX50" as Receiver with the Port that I just created that points to an RFC of the same Client.

Step # 6 - Create Inbound Partner Profile
Now we will create the Inbound Partner Profile for the real Logical System (SX4CLNT050).

Process Code It could be BAPI or BAPP

Make sure this is ACTIVE, because it could become INACTIVE in some cases.

Once you completed the Setup and different steps, you are ready to Send your Material Prices with CKML_PRICES_SEND

An Outbound IDOC will be created and then another Inbound IDOC will be created as well. The Inbound will end up posting the PRICE CHANGE Document.

Note:

This process will still work if the Sending Plant Material has Price Control S - Standard (or V - Moving avg.) and the Target Plant Material has S or V. It will still update it. For sure, this does not apply to a Target S Price where it is a Costed Material with a Cost Component split. In that case you still need to execute a Cost Estimate calculation.
Each MATVAL_PRICES IDoc segment will represent the Different Material Valuations / Currency Types active in the system (Ex. In my case 10, 30, 31)
This process only works within CoCodes that have the same currencies. You cannot transfer a price from one CoCode that has Currency 10 = CAD to Currency 10 = 10 USD. It will not work, you will get a currency error because the Outbound Idoc contains CAD and the Inbound Idoc too while it should have 10 - USD, there is no transformation in between. So the only way for you would be to pass it through a Middleware, and recalculate with the new Currency, if needed.
For an unknown reason, my Inbound IDOCs are not getting process automatically, instead I have to go and trigger the process to post them manually based on their actual status. So you can always schedule the program that posts them periodically to remediate this situation.

Once the Document has been posted, you could verify it by Displaying the Material Document (CKMPCD) or the Material Master Accounting View or the FI Document too.

www.dnabusinessconsulting.com

SAP Finance conversion objects, all about them

2021-02-12T08:08:00.002-05:00

This post is the continuation of my previous post "What is the Data Migration process about ? (Data Migration 101)? where I was explaining the process of Data Migration.

In this post, I will talk about the SAP Finance Migration objects which is my key area of expertise. I will describe the specifics of each objects, its strategy, dependencies and how they fit together in this whole big puzzle.

I will describe them in order, sequence how they need to be created. Some could be created in parallel and some need to be created after others have been created.

The first pre-requiste to start doing Data Migration is that your whole configuration has been transported into Production or your Target environment that you are migrating too.

Extracted Data from the Legacy system should be done all at the last day of the closing period prior to the go-live date. If the go-live is March 1st, then data should be extracted as of the books being closed on February 28th (or 29th for a leap year).

The ideal time of the year for a go-live from a Finance perspective is the 1st day of the new Fiscal year as it simplifies several of these conversion objects, specially GL Balances and Fixed Assets with its values.

Bank Master (Bank Keys)

This is the whole list of Bank numbers, with its names and in some cases their addresses too. This is needed in SAP to be able to perform electronic payments (or Direct Debits too) and register Vendors / Customer Bank account details. SAP normalizes all these data in order to avoid issues while generating payments that could result in payments being rejected by Financial Institutions. If you have a small volume, this information could easily be validated online in many web pages and also in each Bank list of branches. If you have a large volume or anticipate it, there are companies that provide this Bank Directory for specific countries or worldwide ($$$). Ex. Accuity or SWIFT. Bank Keys is a pre-requisite to load Business Partner Vendor / Customer.

Bank Keys Master Data can be migrated using a standard SAP delivered object in the new S/4 HANA Data Migration Cockpit in case you did not purchase the services to obtain Bank Directory Data.

My personal preference: SWIFT Service

Chart of Accounts

This is the heart of the Finance Module in SAP. Without it almost nothing can happen. This contains every single General Ledger account. It can be loaded with the old LSMW, it can be Transported (see this post post that I did in the past) or it can be replicated from your Golden environment into other environments through ALE (this other post too). The chart of accounts is a MUST for all Finance transactional data that will come after, like Fixed Assets values, AR/AP Open Items, GL Balances, Standard Cost calculation and Inventory load.

For S/4 HANA 1909 version, SAP has finally delivered a Migration object for GL Account within the Data Migration cockpit. This is something much awaited since the 1st S/4 HANA version.

My personal preference: create everything in the Golden configuration environment with LSMW or Cockpit and then ALE to other environments.

Profit Center

Another Finance object that is key for SAP Finance. Depending the size of the company and operations they have, this could be a small number of Profit Centers Centers or a large number of records. Based on that if we are talking about a handful of records they can easily be created manually; but it is almost never the case. For a large volume of data, we could always use LSMW or the new S/4 HANA Data Migration Cockpit which it comes out of the box with a Migration Object ready to use. Also another alternative to keep all your environments in synch., you could use ALE to Distribute the Profit Center Master Data (see this post that I did in the past). Profit Centers are a pre-requisite for Cost Centers as Cost Centers need to be assigned to a Profit Center.

My personal preference: create everything in the Golden configuration environment with the Cockpit and the ALE.

Cost Center

Another Finance object that is key for SAP Finance. Depending on the size of the company and operations they have, this could be a small number of Cost Centers or a large number of records. Based on that if we are talking about a handful of records they can easily be created manually; but it is almost never the case. For a large volume of data, we could always use LSMW or the new S/4 HANA Data Migration Cockpit which it comes out of the box with a Migration Object ready to use. Also another alternative to keep all your environments in synch, you could use ALE to Distribute the Cost Centers Master Data (see this post that I did in the past).

My personal preference: create everything in the Golden with the Cockpit and then ALE

Fixed Assets (Master Data & Values)

This will contain all your Fixed Asset Master records for the entire company with its acquisition values, accumulated depreciation, useful life and depreciation method (Key) among some other data too. There will be many companies that will have assets that are fully depreciated (Acquisition value = Accumulated Depreciation) and that they are still migrating. This is totally normal as they are needed for tracking purposes.

Now a days in S/4 HANA, the Migration of Fixed Assets has been simplified (see this post that I did in the past to learn about the different migration methods) .

When loading the Fixed Assets values, the system will do the following Journal Entries:

Debit Fixed Asset Balance Sheet account for Asset Class

Credit Accumulated Depreciation Balance Sheet account for Asset Class

Credit Fixed Asset conversion account *

* This account is a Balance Sheet Account (Ex. 399998) that after loading your GL Balances, its balance will be zero.

Pre-requisite for Fixed Assets Master data are the Cost Centers and the Chart of Accounts.

My personal preference: LSMW with BAPI as described in my previous post

Projects & WBS

This will create all your Projects and their WBSs underneath them so later on you can load the project accumulated values for the ongoing projects. As a pre-requisite you will need Profit Centers and Cost Centers.

Make sure your projects are in status release otherwise you will not be able to post values to them later on when you load your balances. You should not migrate projects and its values if they are already closed or completed.

For ongoing Capital projects, you will post their values when you will be loading GL Balances. Instead of loading Balances to your Balance Sheet Fixed Asset AuC account, you will post all the details to each WBS into a P&L account (or many). After loading the GL Balances and having posted to WBS, you will run period settlement for those projects.

Posting through GL Balances upload

Debit P&L Expense account with Cost Object WBSs

Credit/Credit All the rest of your Trial Balance

On Project Settlement

Credit Project Settlement Account or Original Account (depending on config) with Cost Object WBS

Debit Balance Sheet Fixed AuC account *

* The total of all your loaded project values should be equal to your Balance Sheet AuC, if not you have an issue that need to investigate and reconcile.

For Expense Type projects, you should only load the Master Data and not the GL values as your project values settle to Cost Centers and your P&L will already contain those Settled Values. Unless you can easily strip those values from the Cost Center expenses, you should not post values to it. In case you do, you will repeat the same process as with the Project Settlement for Capital projects but for Expense projects.

Project / WBS Master Data can be migrated using a standard SAP delivered objects in the new S/4 HANA Data Migration Cockpit.

My personal preference: Migration Cockpit, as it could get complicated with an LSMW.

Internal Orders

Here you will create this Master Data that will have as a pre-requisite Cost Centers and Profit Centers too. The rest of the process is exactly the same as with Projects & WBSs for its values.

Internal Orders Master Data can be migrated using a standard SAP delivered object in the new S/4 HANA Data Migration Cockpit.

My personal preference: Migration Cockpit but it depends on the Order Type as the Cockpit did not cover certain types. Not sure if they have improved that now in newer versions, I hope so.

Business Partner - Vendor and Customer

This will create the Master Data of your Business Partners with all the different BP roles required for them to fully operate (Sales, Purchasing, FSCM, etc.). There are several standard SAP delivered objects for both of them within the Data Migration Cockpit that cover the different situations, including Credit. Before 1909, Credit was not covered and you had to develop your own custom object to be able to load Credit limits.

Once you have your BPs loaded, with their corresponding roles and extended to the different Company Codes, you will be able to load your AR / AP Open Items.

My personal preference: Migration Cockpit, no other way. Worst case an API could be used if your System of record for BPs is other than SAP.

AP / AR Open Items

This will contain the detail of every single unpaid Vendor and Customer invoice with its corresponding invoice number, document date (the invoice original date), payment term, original value in original currency and original currency. Posting date for this MUST be the last day of the month prior to go-live. Value in Company Code currency should be already re-valuated at month end rate in case it is a foreign currency document.

When loading the AP / AR Open Items, the system will do the following Journal Entries:

Debit AR Subledger / AR individual Customer Account

Credit AR Conversion Account (Ex GL BS 399997)

Debit AP Conversion Account (Ex GL BS 399996)

Credit AP Subledger / AP individual Vendor Account

* One entry per Document / Invoice loaded.

The total of your AP Subledger in your Legacy System should be equal to the Sum of all migrated invoices. I know it sounds obvious, but not all legacy systems are good in terms of reconciliation, data consistency and accuracy. I have seen this several times in the past. In this case, as part of your data cleansing exercise, you should eliminate and adjust these inconsistencies. The same applies for AR.

AP / AR Open items can be migrated using a standard SAP delivered objects in the new S/4 HANA Data Migration Cockpit.

My personal preference: LSMW with an IDOC for FI Document. I have developed a really good one over the years and still works like a charm.

Inventory related Objects

In case you are using Product Costing and doing Manufacturing execution in SAP, you will need these series of objects that are related to Inventory values.

Activity Types

Activity Types are created prior to the creation of Production Work Centers and created in conjunction by your Production Team / Consultant. They can easily be created using the standard delivered S/4 Migration object for Activity Types or manually if they are just a few.

Activity Types rates

After having created the Activity Types, Finance has the responsibility of assigning rates to it. This is done through Tcode KP26. This could be done manually or within the config of KP26 you could create an Excel loading template so you could have a large number of records to load. After this, Production will be able to create their Costing Tab of their Work Centers, otherwise if there is no rate, they will get an error.

Material Prices (moving average)

During the load of your Material Master records and the creation of the Accounting Views of them, you need to assign a Material Price to those materials that have Price Control indicator V - Moving average. If you do not do that, when you load inventory quantity or try to calculate Standard Cost, you will get errors or Inventory with no value on it.

This should be done by and in conjunction to your Material Master Team and within their Data Migration object (Ex. it could be an LSMW, or a new Data Migration Cockpit object, or another method that they could have decided like a BAPI or API).

Reconcile this with your Legacy system values and be ready to explain if there are any differences.

Material Prices (standard)

As part of the creation of the Material Master Accounting views, for Material that will have Price Control Indicator S - Standard; you need to at least put a value during the Material record creation. This value will be overwritten by the standard cost calculation process later on. In this case I always suggest putting a penny (0.01), just to get by and be able to save the record.

Standard Cost Calculation

Many people consider this as a conversion object, I don't. From my point of view, this is more a process than a conversion object, as you do not develop any program or conversion object for it. You just need to run the Standard Cost Calculation process (Tcode CK11N individual or CK40 mass). Once you obtained a suitable Standard Cost, you will release it and your Material Master records will have a Cost for those with Price Control Indicator S - Standard. If you do not do that, when loading inventory quantities you will get Inventory with no value on it or a penny as described before, which is almost the same as no value.

Reconcile this with your Legacy system values and be ready to explain if there are any differences which there are high chances there will be. In many Companies some sort of dollar threshold is established prior to this exercise to accept differences. In some other cases, there are Management calls right after to discuss these differences and sign-off on them.

Inventory Qty load

This is where it all ends for Inventory. Your MM or WM Team will load their Inventory Quantities and based on the Material Master Cost assigned in prior steps for the different materials (S or V), the system will do Qty * Cost and post a Journal Entry for that Inventory Initial load process.

Initial Inventory load Movement Type 561 will trigger FI-MM Account Determination GBB-BSA.

When loading Inventory, the system will do the following Journal Entries:

Debit Inventory Balance Sheet Account (as per Valuation Class of the Material record) (BSX)
Credit Inventory Balance Sheet Initial load / Conversion Account (Ex 399999) GBB-BSA

The total of your Inventory load resulting from the Quantity load should be equal to the Sum of all Inventory Balance Sheet accounts that you will load in your GL Balances. If not you have an issue and should reconcile it.

As a suggestion, I strongly recommend this approach before loading inventory quantities... Once you have Moving AVGs and Standards in your system, you should extract them and put them in Excel. Then before loading the Inventory Quantities, ask for that file and dump it in Excel. Do a quick Vlookup to populate all Materials with prices. Then do Qty * Cost and do the full sum. If it Balances to your GL, you should go buy yourself a lottery ticket. If it does not balance, which is most likely the situation, start a reconciliation process Material by Material. As said before, in many Companies some sort of dollar threshold is established prior to this exercise to accept differences. In some other cases, there are Management calls right after to discuss these differences and sign-off on them.

GL Balances

Now we reached the last of the SAP Finance Conversion objects, the most important one and the one that closes the whole loop and series of conversion accounts. After posting the GL Balances, all your 39999x Conversion accounts will go down to zero. If not, you have an issue derived from any of the previous conversion objects that you need to analyze and reconcile.

As previously described in each individual object, you cannot map your GL Balances for the different subledgers and/or modules (AR, AP, Inventory, Assets, Projects and Internal Orders) directly to the subledger accounts, instead you need to map those GLs to the 39999x Conversion accounts. Each subledger loaded have posted the offset to the conversion account. Then the GL Balance upload will come to offset those GL Conversion Accounts (39999x).

Remember, GL Balances needs to be done with a posting date as of Dec-31st (in case your go-live is Jan 1st).

Note: always pay attention to your Parallel Currencies amounts, not just your Local / Company Code currency amounts. This is normally a challenge because not many Legacy systems have Parallel Currencies capabilities like SAP.

My personal preference: Migration Cockpit object delivered by SAP.

Timings

Inventory load will happen right during the go-live weekend as Inventory quantities are crucial to be able to start Producing and Shipping in the new system after go-live.

Fixed Assets load will most likely happen during the 1st days after the go-live as the company still needs to close their Fixed Assets in their Legacy System, then Extract, Transform and get ready to load into SAP. So expect to receive that info a couple of days after. And this is totally normal.

AR/AP Open Items load, will most likely happen during the go-live weekend. These Open items are needed right after you start operating in the new system so you can pay your Vendors and apply cash received from Customers. There could be a minor delay of 1 or 2 days max, but more than that will have an impact on the business.

Project and Internal Order values will happen with the load of the GL Balances.

The load of your GL Balances (or the whole Trial Balance), cannot happen during the go-live weekend. No Accounting / Finance department closes their books in a weekend or during the go-live. So, information to load the balances will come no sooner than mid-month after the go-live date. Only once the books have been closed, all JEs posted, everything reconciled; then Finance will be able to produce a file ready to upload the whole Trial Balance. This needs to happen before you start your 1st Month End exercise in SAP, otherwise you will not be able to produce proper Financial Statements.

Note on LSMW

Before people start jumping at me ... I want to clarify something on this.

SAP has released notes that LSMW is not the preferred Migration tool for S/4 HANA, that they will not support it anymore, it is at your own risk and you should use instead the new S/4 Migration Cockpit. All good with that. But .... Where I see an issue is in trying to use LSMW in Objects like BP where you cannot use recordings in those screens and some other screens (like ABLDT for Fixed Assets values) where you have tables and you cannot manage that properly with recordings.

But LSMW is not only about recordings. You can use BAPIs and IDOCs with it and still be 100% S/4 HANA compliant, as those BAPIs and IDOCs have (most likely) been updated to be used in S/4 HANA. So using them will not break anything and data will still be properly created. LSMW with BAPIs and IDOCs is still way more performant than the Migration Cockpit, way faster. I have lived that 1st hand. The only thing that you need is people like us (old SAP Consultants) that know how to use it for each an every single object.

www.dnabusinessconsulting.com

What is the Data Migration process about ? (Data Migration 101)

2021-01-19T12:04:00.003-05:00

I decided to write this post as many times during the many projects that I have done over the last years, I keep on receiving the same questions over and over about what is the information that needs to be converted from a Legacy System into SAP, what is the strategy that we should follow and how to approach the different objects.

I haven't read anything on the subject out there, so I decided to write a Post about it.

Data conversion is the process of moving and translating the data from your Legacy System (any type or brand of legacy system) into your Target system during a system implementation so the new System can take over the operations and have the data ready and loaded for it. This process is called ETL (Extract, Transform, Load).

Process

You will Extract all the different data objects from your Legacy System Database. This extraction could be done into multiple formats. It could be flat files (ASCII or Text), it could be into Excel Files, Access or SQL Database, into any other type of Database, you could use SAP Data Services (SAP's product for Data transformation and loading into SAP), or it could be into Staging Tables. Your data source might not be necessary a database, it could be Excel spreadsheets too.

Once the Data has been extracted, you will start the Transformation of it. This is the process where you will build your Dictionary that will help you understand / translate your Data Values and records between your Legacy System and your New System. Why ? Because your new system will have different fields, new fields and fields that do not mean the same and/or are not used the same way as in your old system. So for that you will have to build correspondence tables between one value in the old and the new value. There could be values that will have a 1:1 relationship, n:1 or 1:n, so you have to build all those mapping rules.

Ex. Your Customer or Vendor Numbers might need to be changed from one system to the other, Your General Ledger Accounts numbers might be different, or your old system might not have Cost Centers and your new System does.

Like this you could have hundreds of examples within the different areas / modules of the system where you will have values that will need to be replaced by new values.

Now these mapping tables, are not static; some of them will evolve during the course of your implementation project so you need to instrument a mechanism to maintain them updated to prevent any records being rejected by your new system because you did not maintain the mapping. Some will even need to be maintained up until the very last minute. Ex. Customers and Vendors.

Once you have all the data mapped, you will be ready to start your Load process. This is where you start Migrating and saving (loading) the data into your new System. This is an extremely important process that will impact the data quality and accuracy of your new system. There is a say that we repeat over and over on projects ... "garbage in, garbage out". What does it mean ? If you load garbage into your system, you will output or have garbage results. And of course you do not want this to happen after having spent several millions dollars and several months in the implementation of a new system.

Data Cleansing

One of the most important aspects that needs to be taken into consideration all along this process that will work towards the success is Data Cleansing. All Legacy Systems, with no exceptions (even an old SAP one), will have garbage data or data that you do not want it to make it into your new system because you do not need it anymore. You will have duplicate records, incomplete records or records that have been created by mistake. In some systems you might even have corrupted data that cannot be used or even repaired anymore. All this data needs to be looked at and cleaned. If possible, this data should be removed from the Legacy System prior to its extraction, should not be extracted at all or should be cleaned up after extracted. But it should never make it into your new system. This should not be negotiable.

Going back in time

You will also need to establish certain cut-off criteria and decide how far do you want to go back in time to bring your data over. As a rule you could establish that you will not transfer Customers or Vendors that you have not done business with over the last 24 or 18 months. Any one beyond that point, should be disregarded and not transferred into the new system. Same applies for any other data objects that you will be migrating. This decision will be influenced by the type of business and industry that you are in. It is not the same for someone that it is in the retail business and sells through POS (Point of Sale) machines and does not manages his Customers by name versus being a Utility company or the Government that manage millions of Customer records and might even be subject to strict regulations on data retention periods.

This cut-off criteria will also be managed on an object by object basis, as it might be different for Customers, Vendors, Materials and so on.

These are all ground rules that need to be established as part of your Data Migration Strategy.

Reconciliation

During each of the steps of the E-T-L process, you will also need to establish reconciliation processes to ensure data consistency and accuracy to avoid "losing" records in between each of the steps and overall during the process. Ex. If you are transferring all your Vendor Invoices you need to be able to know what is the actual total amount of it in your Legacy System, what is the total after extraction, total before loading and finally the total after loading it into the new system. They should all be the same, if they are not, you should reconcile the differences, be able to explain and/or remediate them. Each and every single converted object should be subject to the same reconciliation process.

Depending on the number of records and type of records that you are converting, you might want to establish different approaches like random checks, spot checks, statistical samples or 100% record check. The first that should be applied is based on number of records. Then, if you are dealing with Quantities or Currency amounts, those should (or must) all balance to the penny.

Mock loads

This process will and should not be done only once. This is an iterative process that will take several attempts with different targeted accuracy until you reach 100% (or almost). During the course of your project you will repeat this end-to-end process several times. Depending on the size of the project it could be 2, 3 or even up to 4 times where you will have to establish different and increasing accuracy levels. This attempts are called "Mock data loading" (Mock 1, 2, 3, 4). These will be really big milestones in your project.

Build

Individually the ETL process steps while your are working and building them, you will have many individual tries and attempts isolated from the whole process.

You will build your Extraction program or query and while at it, you will tweak it and refine it until it meets all the requirements that you established for it.

You will work on your Transformation process, build it, map the data from the source to the target data structure. Test the transformation process.

And finally you will work on your loading program/s. You will attempt to load 1 record (happy path or sunny day), clean all the data errors and solve any issues that your program might have. Then attempt to load 5 or 10 records, analyze the issues, rejections and fix it and load again. Then you will attempt to load specific and complex data scenarios (rainy day). Repeat until is working correctly. Finally you will go for the volume. This is were you will expect that everything is going to blow up in the air and have tons of errors. It could be expected. You have to work on them until every single record passes.

Once you have all of that, you would think you have a solid process. At that point is where you would have planned to run the whole ETL process for the specific object that you are working with. And of course adjust and fix.

Finally, you will attempt to load all the different conversion objects (Customer, Vendors, Material, GL Accounts, Inventory, etc, etc). All the previous described steps are all cogs of a big and complex machine that is your whole data migration project.

As mentioned before, you will do several Mock runs, which are nothing more that a play rehearsal. All pointing towards the big event that will be your final cut-over event which is when you will go from your Legacy System to your new System.

Environments

During this iterative process of building your whole ETL, you will generate a lot of throw away data, as you are building your ETL process. This will pollute your Database and you could be impacting other people that want to test programs, processes and reports that could be distorted by your data. So that is why, all these attempts should be done in parallel environments, instances and/or databases to the ones used by the rest of the project team.

For this you will have to plan to have separate instances and/or Databases that will need to be refreshed / wiped out several times during the course of the project.

Dependencies

In the overall plan of this Data Conversion work, you need to work on scheduling and putting each conversion object in the right order of execution. This cannot be done on the day of the cut-over, this needs to be done early on in the project. You need to establish the right sequence of events and loads. For this you will build something like an Ms Project Plan, Gantt Chart or Perth Diagram, establish relationships and dependencies (Start-Start, Start-Finish, Finish-Start, etc).

Examples

If you want to load your GL Balances, you will need to have previously loaded your Chart of Accounts that contains the list of GL Accounts. Otherwise your system will not have your GL accounts to load your Balances.
If you want to load your Bill of Materials (BOM), a pre-requisite (dependency) will be to have loaded your Material Master records.

Every single conversion object could have a predecessor/s and a successor/s.

Data Snapshot

When doing your Mock rehearsal exercises it is extremely important that the data that you extract be taken out of the Legacy System (or Systems in there are more than one) all at the same time (or almost). Why ? For consistency and reconciliation purposes. If your Data Extraction (snapshot) for one module or system has a time gap in between, and new records are created or updated in the other system that uses related data; you risk having inconsistencies that make your reconciliation efforts much harder or in some cases almost impossible.

Example

Inventory values are handled in your Finance system that has an interface with your Warehouse system that handles Quantity. If you do not extract both at the same time and you have days in between, your Amounts will not balance with your Quantities.

History

During many of the projects that I have done in the past, a lot of clients wants us to Migrate historical transactional data into the system. In 99% of the cases this is not possible. In an integrated system, posting transactional data has consequences and impacts that cannot be avoided. Ex. If I want to post all historical inventory movements, any inventory transaction that I post will have its corresponding accounting impact that then will reflect in my Balance Sheet and/or P&L. So If do that, I will have to find a way to counteract the effect of having posted many inventory transactions that impacted my Accounting books. So for that reason, it is almost impossible to post many of the historical transactions and we can only Migrate an snapshot at a given time and date.

For this reason, companies will have to take this into consideration and provide access in read-only mode to their old Legacy Systems for a certain period of time for traceability, investigation, reference and audit purposes. In the majority of the countries, tax authorities and governments can go back in time "X" number of years and ask you for information. So that is why you might have to keep those systems alive, dump the information in Tables or any other method that would allow you to trace back information and provide it to the authorities.

In my next Post, I will be talking about individual conversion objects in SAP Finance with its particularities and strategy.

SAP Finance conversion objects, all about them

www.dnabusinessconsulting.com

Electronic Payment standards in SAP

2020-12-15T20:00:00.039-05:00

In this article, I will explain how the Electronic Payment Process works, how you can configure it in SAP and what are the different electronic payment file standards used in North America and Europe.

First we will start by explaining what the Electronic Payment Process is about.

Some countries, banks and/or companies would call this Electronic Funds Transfers (EFT), some Electronic Payments, Electronic Payment Orders, Payment Initiation and so on ... But they all refer to the same process.

Now a days, companies instead of issuing a physical check to pay their bills, they have the possibility of issuing Electronic Payments. The process starts when a company executes a payment, with that payment their ERP system (SAP, Oracle, MS Dynamics, Netsuite, etc.) creates a file that contains all the necessary information for the bank to process it and issue a payment to their vendor. The Bank receives this file, reads it and selects all the payments contained inside and sends it to the Clearing / Settlement Entity for its processing. This entity works exactly the same as in the past for check clearing, but process electronic payments instead. Then the payments are sent to the Payee/s bank/s which process them and deposits the funds in the Payee/s / Vendor accounts.

Depending on the country you are in, the country's Banking System will operate differently in terms of Electronic Payment file standards. And even within the same country, banks could be using different standards as well or adapt / tweak them to their own needs. Some could still be using old file format standards or some could have implemented newer and more technological advanced standards already. Requirement need to be analyzed on bank by bank basis.

SAP covers the majority of the main electronic file formats in an standard way. That does not mean they fit 100% as per your bank's requirements. But normally 90% of the standard is covered and you are left with some tweaking to do and be 100% compliant with your bank. The problem is that Banks rarely adhere 100% to the standard and they modify it to suit their own needs. SAP delivers the standard as per the industry.

For example, in the case of SWIFT ISO 20022 standards, SAP is one of the founding members of the board that designed the standards for the industry. So compliance with the standard is guaranteed.

These are some of the most important electronic file standards in different countries / markets:

You will be able to use each of these standards by selecting them in the Payment Medium Workbench field in the Automatic Payment Program configuration (FBZP) for "Payment Method in country".

Each of these standards have their own particularities and minor extra configs that might be needed and could easily be the subject of a Blog posting on its own.

Contrary to what we used to do in the past, you do not need to use the "classic payment medium programs" RFFO* anymore, all of the standards are now present via the PMW. (See my previous Blog posting on the subject for the explanation).

After this you will do your config for "Payment methods in Company Code" and "Bank determination". Finally, you have to complete your config in OBPM4 (As described too in the previous posting).

Now depending on your bank's requirements, you might have to do some modifications by using the DMEE or DMEEX, which requires you to have a prior expertise using this tool. In my experience, execpt for ACH in the US, one way or the other I always ended having to do tweakins and adapting it to my bank specific requirements. But always starting from SAP standard delivered formats.

Once the configuration completed you will start your testing. For this purpose you can use Fiori Apps "Manage Automatic Payments" which is the equivalent of F110 and if you need to access and download the created file, you can use "Manage Payment Media" Fiori App that replaced FDTA.

At this point, testing with the bank can start as your main configuration is completed. Testing with the banks is a complex, long and bureaucratic process that by no means you should underestimate how long it will take you. In my experience, this is something that should be started as early as possible in any implementation process.

www.dnabusinessconsulting.com

Some sites for references:

https://en.wikipedia.org/wiki/Single_Euro_Payments_Area

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/swift/

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/sap-idoc/

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/ansi-x-12-edi/

https://www.corporatetobank.com/resources/financial-services-file-formats-and-document-standards/edifact/

https://www.iso20022.org/iso-20022-message-definitions

My SAP WIP Calculation is not working properly ? Common mistake

2020-11-12T07:30:00.074-05:00

If you are an SAP Consultant working in CO - Controlling, you probably worked or will work eventually in a Production / Manufacturing environment where at Month End you will have to Calculate WIP (Result Analysis in SAP language) either in Production Orders or in Cost Collectors.

So for that you will have to configure the whole Result Analysis functionality and the whole nine-yard. You also need to make sure that your Cost Objects (Production Orders and/or Cost Collectors) are getting assigned the proper configured Result Analysis Key.

But ... even with all of that, your WIP calculation might not work correctly.

I have been called in the past by several clients to help solve WIP Calculation issues in SAP and was surprised with what I found.

I went to a client once (Dairy products manufacturer) that every month they would do a Journal Entry of around $ 1.5 million to reverse WIP from their Balance Sheet on a constant basis. They were desperate because that JE was taking them a lot of time and also month by month was constantly growing and never going down. It was a snow ball out of control.

After that client, I went to another one (Pharma) that had a similar situation, but their numbers were so big that they never realized of the situation and they never did anything like the other trying to offset it with a manual JE.

Some consultants (or most) configure the functionality, do a little bit of testing and integrated testing during the course of the project and they stick around for 1 or 2 months after the go-live. But the real effect of this issue is not known and seen until a couple of months down the road and by that time the consultant is long gone to his next project / client.

To calculate WIP the system uses the Cost Object Status to determine if it has to calculate WIP or not. All costs accumulated in a Production Order at month end, will be considered WIP if the order has not been set to TECO - Technically Completed or DLV - Delivered. If the order is in one of those 2 statuses, then the system will cancel / reverse the WIP calculation or not calculate WIP at all and that will create a JE posting at the time of Settlement.

So, What was wrong with the WIP Calculation of this clients ???

It was something so simple but at the end something that not a lot of consultants knew.

For you to know all the necessary Month-End steps that need to be done, it is always recommended to explore the SAP Menu in case you do not know all the steps by hard or have them properly documented.

Within the Month End functions for WIP, the very 1st one is the establishment of the Cutoff Period. If you do not do this one properly, then your whole WIP calculation will not be accurate and you will end up in the same situation that I described for some of my past clients.

The Cutoff period is key for the WIP calculation, as it establishes the period until WIP should consider the Orders in an open or close period. Consider it like the FI period (OB52) but for WIP, not literary.

The Cutoff should be defined as the period preceding the results analysis period. Ex. If you are doing the Month-End close for 2020-07 (July), then your Cutoff period should be 2020-06. In a sense, is closing period minus 1.

The Cutoff period should always be for RA Version 0, which is the one that is used for Accounting purposes.

Once you set this value properly, your WIP calculation will work well and reverse WIP when it should. This needs to be done every month before starting to run any of the month end closing activities.

In the case of my clients, I was astonished with what I found because they had values like 1990-01, which is the value that comes out-of-the-box with SAP when you 1st installed it. That showed me that no one ever opened and changed this value. Therefore their WIP calculation never worked to reverse WIP. It accumulates in the Balance Sheet but it never reverses it. For one of them, this Transaction was not even part of their Security roles, which shows me nobody knew and thought about it during the project.

After setting up the proper Cutoff period value, you will continue with the normal steps WIP, Variances and finally Settlement.

*** On a side note about this subject, now in S/4 HANA we do not have the SAP Menu as we used to have were you would find all the steps. Instead, we have the Fiori Tiles and we need to know the right steps and order of execution. But for unknown reasons, SAP has not delivered any Fiori Tile for this Cutoff period (Tcode KKA0) nor is included in any standard catalog. So you will have to ask your Security team to build a Fiori Tile out of a GUI Transaction so then can be added to a Catalog and a Role for execution within the Fiori Launchpad.

If someone knows this reason, please let me know. I am curious to know why. Is it related to S/4 changes that they have done ? Never read anything in the Simplification Notes about it. Also researched OSS Notes before writing this and did not find anything on the subject.

Unfortunately, there is no quick way of scheduling and automating this Tcode so it would change the period automatically. It has to be done manually prior to Month End.

www.dnabusinessconsulting.com

How SAP S/4 HANA calculates GL Balances with the New Simplified Data Model ?

2020-09-28T20:00:00.004-04:00

SAP has been around for a lot of years now and it has seen its core ERP product evolve over the last 40+ years. With it, its Data Model has been evolving too. SAP, like any other ERP and traditional Finance system, has used Total Tables to be able to calculate and provide GL Balances in the FI - Finance Module since the beginning as there was no other way to achieve this without damaging performance with the Databases that we had. Other systems have been using that approach and are still using it nowadays. Up until S/4 and the utilization of the HANA Database, the only way to obtain GL Balances was by reading Total Tables that had summarized information.

These Total Tables would be updated every time a new GL Posting happens updating not only Line Items Tables (like BSEG or FAGLFLEXA) but also Total Tables (like GLT0 or FAGLFLEXT and others too) and recalculating the corresponding total for the specific GL and Object / Dimension (like Internal Order, Profit Center, Functional Area, Cost Center, etc. ).

Then once we would run a report that would require a GL Balance (Total), the system would go directly to those Total Tables and read them from there as they were already calculated.

For Classic GL these were the Total Tables:

GLT0 - General Ledger: Totals
GLPCT - EC-PCA: Totals Table

For New GL this was the Total Table:

FAGLFLEXT - New General Ledger: Totals

On top of those Tables you would also have CO Total Tables like

COSS - Cost Totals for Internal Postings
COSP - Cost Totals for External Postings

Now with the changes brought by S/4 HANA all those Tables have been eliminated.

A typical Business requirement that I have seen over and over in many projects, is to build and Interface or Custom Extraction program to Extract GL Balances at the end of the month and feed an external reporting and/or Consolidation System (Ex. Longview, Oracle Hyperion, Cognos and many more). In that case, we would build a custom program to go and extract GL Balances from the Classic or New GL Total Tables.

So, if the new Data Model introduced by S/4 HANA in Finance has eliminated these Total Tables, how is SAP providing GL Balances now ?

The 1st answer that somebody would say

"... with the New and super performant HANA Database, it will read all the line items and calculate the Totals "on the fly ..."

Well that is not 100% accurate. It is true that SAP would read all the line items that now are part of the Universal Journal Table ACDOCA but it cannot read "all of them" ...

Imagine a system that has 5, 10 or more years worth of data. Each year could have millions of line items records. It would not be really efficient to read all those millions of line items since the beginning of time just to calculate a Total. This is something that could present as a challenge in the case of a Balance Sheet account, as their Balances are always an accumulated balance since the beginning of time. In the case of a P&L account, it is easy as their Balance are always made up of the current Fiscal Year postings only.

It is fair to say that in the case of a Balance Sheet account there is a Technical challenge in front of us as we should not be reading all line items since the beginning of time, but we still need to be able to obtain a balance without, reading all records, impacting the performance and doing it in an efficient way.

For this, SAP at year end writes initial Balance postings in the Universal Journal Table ACDOCA but with "Period 0 - zero (ACDOCA-POPER = 0)". Yes, it is a period that does not exists from an Accounting point of view, but S/4 HANA Finance uses this Period Zero as the starting point to have a "marker" to know where those balances start and not having to go back to the beginning of time to rebuild that balance every time. Period zero postings are done by the Balance Carry forward process (Tcode FAGLGVTR) when closing the Fiscal Year.

So with this Period zero being used as a starting point, then S/4 HANA Finance, reads all the current Fiscal Year line items and provides a GL Balance for those Balance Sheet accounts in an efficient way without the need to read all Balance Sheet postings since the beginning of time.

As mentioned already, any P&L balance is easy to obtain by just reading all lines items for the current Fiscal Year.

ACDOCA-POPER (Period) = 0 and

ACDOCA-BTTYPE (Business Transaction Type) = RFBC - Balance Carry Forward

www.dnabusinessconsulting.com

Payments Advice in S/4 HANA (On-premise)

2020-09-09T07:30:00.008-04:00

In a recent post, I was talking about how to do physical checks payments the right way in S/4. Now in this one, I will show you how to generate Payment Advices in S/4 HANA. If you read my previous post, if not you should, you will know that the Tab "printout / data medium" has been removed and it just does not exists in the Fiori App "Manage Automatic Payments" which replaces Tcode F110. So another drawback of this, is the lack of possibility to select your Program Variant to issue your Payment Advice.

But ... there is no PMW (Payment Medium Workbench) solution for this as we have for Checks. In this case SAP has "hardcoded" it (literally) in the Fiori App "Manage Automatic Payments" to look for a specific Variant Name under program RFFOAVIS_FPAYM. If you do not have this Variant in your system, no matter what you do and try, your Payment Advices will not be generated.

Up until version 1809 FPS01, you needed to create this Program Variant manually. Now they woke up and they included it out-of-the-box. So if you are working on 1610, 1709 or initial 1809 chances are that you were (or are) missing this Variant. If you have it, it might mean that someone created it already.

Variant name required and "hardcoded" is: PAYM_LC

There is even an OSS Note (2690678 - Manage Automatic Payments: Cannot Print or Send Payment Advices) that SAP released that explains the issue and what you have to do.

Reference OSS Note:

2690678 - Manage Automatic Payments: Cannot Print or Send Payment Advices

https://launchpad.support.sap.com/#/notes/2690678

www.dnabusinessconsulting.com

How to do (print) physical Checks with SAP S/4 HANA the new / right way !

2020-08-12T07:30:00.007-04:00

For many of us that have been around for a while in the SAP Finance world, designing Checks is a constant on every project. I lost count how many Checks I have designed and implemented over the last 11 years, but I can tell you, I know quite a bit about it and have done it many times. I have designed Checks for Small, Medium and Large companies in Canada and in the US too. (For you guys in Europe, Checks are something of the past since 2014 and the introduction of SEPA, lucky you !).

I am also writing this as I have been asked several times by different colleagues on how this should be done in S/4 HANA as not a lot of Consultants know this already and have upgraded their skills to S/4.

So ... As many of you know by now (if not you should not be doing SAP anymore), things have changed in S/4 HANA (for the better) compared to the tools and ways of implementing Checks in ECC6.0 and before.

Developers have new tools to design FORMs like Adobe Forms with Adobe Lifecycle Designer that you should use instead of the old SAPScript. It is lot easier, faster, more user friendly and gives you a lot of flexibility to implement custom code.

So ... now, How should you be doing checks in S/4 HANA the new and right way ?

There are a couple of things that you should consider now in S/4 HANA. By now, you should not be deploying anymore the old SAP GUI logon Pad. There are certain exceptions, but you should deliver the new UI which is SAP Fiori. With that it comes a lot of new Apps that have been built for Finance. Among those you will find "Manage Automatic Payments" that replaces to old Automatic Payment Program Tcode F110.

The new "Manage Automatic Payments" App is more user friendly, more intuitive and have lost several of the technical non-sense things that an end-user needed to select in order to issue Payments in SAP. I never understood why they made it so complicated for the end user (well it's SAP ...).

Now the Tab "Printout/data medium" is gone from the Fiori App, you do not have access anymore to that Tab. It just does not exist in Fiori such an option to select what variants you will be using for each program. Instead you should be using the new Standard delivered Payment Medium Workbench (PMW) CHECK.

You cannot use anymore the old and traditional program RFFOUS_C (or any similar variant of it). Also, you cannot use the traditional Funds Transfer / Electronic payment program RFFOUS_T and you should be using the PMW and build a DMEE for Electronic Funds Transfer instead. This is "IF" you want to use the new Fiori App, if you don't and you still want to use the old F110, then those programs will still work in S/4 HANA. But why would you want to keep on using it if you have a new one ? Would you keep driving your old car with no AC, no power windows and no power steering wheel ? Well, I don't !!!

Not long ago, I went into a client who was running S/4 (greenfield implementation) and saw that they were using the traditional RFFOUS_C Print program. In fact, they took a copy of the program and they customized and put their own code inside it. This is something that we all used to do in the old ECC days, but we should not do this anymore. (See below what we should not do anymore).

Unless you have a compelling technical reason for using the old Print Program, then I see this as poor knowledge and lack of skills from the Consultant that implemented this solution. Which it wouldn't be the first time I see someone that lacks the technical knowledge doing something like this ...

As I mentioned before, YOU SHOULD STOP USING RFFOUS_C and start using the new SAP Standard delivered Payment Medium Workbench CHECK to be able to print Checks.

Another thing you should STOP doing is using SAPScript to design your Check Form layout. The new way in S/4 and new tool is Adobe Forms (not Smartforms). SAP Delivers a Standard form that you should take as a reference and design your own as per your business requirements.

Adobe Lifecycle Designer will allow your Developer to meet 100% of your Business requirements Layout and add any type of custom code needed to retrieve any extra information that could be required to be printed in the form that is not yet available . No more copying the Standard program and modifying it so then the SAPScript form has access to new information. That is not needed anymore with this new technology. A good and up-to-date Abaper will know what I am talking about. (It is not the purpose of this post to explain that and I am not an Abaper either).

After you have configured the use of the Payment Medium Workbench CHECK and have developed your custom Adobe Form, you should add it in the configuration. After that your config should not have this setup anymore.

In the line "Form for the Payment Medium" you should select PDF and enter your PDF Form name there instead of SAPScript.

After that you need to configure your Variants in Transaction OBPM4.

There you will create a Variant which will allow you to select your Check Printer among some other things.

As you can see, it is not complicated, you just have to know how to do it and your SAP Finance Consultant should have up to date knowledge too.

I am putting as a reference 2 OSS Notes that explain part of this new setup and gives you a possibility of using the Old programs if you still want. But I would not recommend it, it is not the way to go these days and I suspect that eventually SAP could close that door in subsequent versions.

Note: The described procedure and screens belong to S/4 HANA On-premise.

www.dnabusinessconsulting.com

Reference OSS Notes:

2794915 - No "Printout/data medium" tab in "Manage Automatic Payments"

https://launchpad.support.sap.com/#/notes/2794915

2418837 - Manage Automatic Payments: Add Support for Classic Payment Medium Programs

https://launchpad.support.sap.com/#/notes/2418837