Search The SAP Consultant

Wednesday, September 27, 2017

New reporting possibilities for finance in S4Hana using analysis for office

In this post I would like to show how a typical finance report such as an equity roll forward report for US GAAP reporting can be designed using the capabilities of S4Hana. My intention here is to show the various tools used to generate this kind of finance or non finance reports from a S4Hana system so functional consultants who want to broaden their knowledge on these tools can make use this post as a guidance for further research and learning. The tools used to define this report have been highlighted for easy reference.

Step 1

In this case, the consolidation transaction types in SAP has been used to track the horizontal development of the equity GL accounts. Additional validation and substitution rules are used to tag transaction types on postings. Please note that this is not something new to S4Hana but the existing solution from ECC is enhanced by the real time reporting capabilities on S4Hana using analysis for office excel. Consolidation transaction types are configured using the following menu path.

Financial Accounting (New)  à Consolidation Preparation (New) à Transaction Types à Maintain Transaction Types for Consolidation



Step 2

This step and proceeding steps have been made possible by the OLAP capabilities and integrated analytics of S4Hana. An analytical view ZROLLFORWARD has been created using the Hana modeler perspective of Hana Studio by combining the table ACDOCA and consolidation transaction table T856 with an inner join so only the records with transaction types populated in ACDOCA are pulled into the view.




Step 3


A virtual info provider ZEQTYRF is created using Data Warehouse Workbench (RSA1) to fetch data from the analytical view ZROLLFORWARD created in the previous step. The fields from the analytical view are mapped to the info objects so that the virtual info provider will fetch the data from underlying Hana view.



Step 4

Once the virtual provider is created, Required BW query for the report can be written using BEx Query Designer or the BW modeling perspective of Hana Studio. Query "Rollforward schedule" is created for this post.







Step 5


Query created in the previous step will then be called in the Analysis for office.
Excel worksheet containing the report can then be saved on the application server or on a corporate network drive or on the local PC.



Executing the report

Users will now be able to execute the report by simply opening the excel workbook from either the application server or a corporate network drive or from their own local computer.





I hope this post act as a guide to learn the required tools that will help to generate attractive real time reports for business users which was traditionally considered a weak point in the SAP transactional system. 

Thursday, July 20, 2017

Interactive profitability analysis report using analysis for office

In this post I would like to give an idea about how to write an interactive profitability analysis report using analysis for office and virtual InfoProvider for COPA in S4Hana Finance. Virtual InfoProviders are BW InfoProviders that sit on top of S4Hana tables and obtain the actual data in real time. In this case, the COPA data from universal ledger is directly obtained by the virtual InfoProvider thus eliminates the need to extract and send the data to a BW system like it was done in previous versions of SAP.

As the first step, we need to activate the virtual InfoProvider for COPA using the following configuration menu.

Controlling  à Profitability Analysis  à Information System  à Generation: Virtual InfoProvider


Once the InfoProvider is generated, we can write a BEx query for our COPA report based on the InfoProvider generated using the previous step.


Now the above query will be called using the analysis for office for an interactive profitability analysis report using the favorite tool of finance teams  "The Excel".
                                            It has to be noted that the data on this report is fetched on a real time basis from the transactional system unlike the traditional BW reporting that typically has a time lag due to the ETL process.


The same query can also be called using the analysis for office for PowerPoint to have real time profitability analysis content on presentations.



Hope the information above helps you to further explore the new reporting possibilities with S4Hana.



Wednesday, May 17, 2017

Real time overhead calculation

In this post I would like to talk about the enhancement that's delivered by SAP with regards to the overhead calculation process in SAP. Prior to S4Hana world, finance teams used to run the overhead calculation as a month end process for cost centers, internal orders or production orders. In the manufacturing world, this is a critical process before executing the work in progress, variance and settlement processes during month and year ends. Most finance team members would agree that anything that we take out from the list of items to be done during period end processing is always appreciated.

SAP has introduced the new real time overhead calculation process as part of S4Hana 1610 that calculates and posts the overhead absorption as and when the postings are made to the relevant cost objects. for example if we have a material overhead based on raw material consumption on a production order, as soon the raw materials are issues to the production order, the overhead will also be absorbed and posted to the order and the credit object.

In this post I'm not going to cover the configurations related to costing sheets since there is no changes to this set up because of the real time overhead calculation. Following steps are needed to activate the functionality.

Step 1

As the first step we need to activate the functionality per  controlling area. I'm showing the SPRO menu path under internal orders but the same configuration menu can be found under cost centers and production orders.

Internal Orders  à Actual Postings  à Overhead Rates à Maintain Real-Time Overhead Calculation  à Activate Realtime Overhead Calculation


Step 2

Next step is to activate the business transactions that trigger the real time overhead calculation.

Internal Orders  à Actual Postings  à Overhead Rates  à Maintain Real-Time Overhead Calculation  à Activate Overheads for Controlling Area and Business Transaction
There are five business transactions that can trigger this new functionality and we can selectively activate the required ones. For example if we want an overhead to be calculated based on raw material consumption on the production order then the business transaction COIN should be activated, if we want an overhead to be posted based on activity allocation on the production order or a cost center then business transaction RKL needs to be activated. Following are the available business transactions.
COIN  - CO Through-postings from FI
KAMV  - Manual cost allocation
RKL - Actual activity allocation
RKU1 - Repost costs
RKU2 - Repost revenue

With these settings, the new functionality is turned on for the controlling area. We need to note that the traditional month end process of calculating the overheads is still available if an organization wants to use it instead of real time calculation.
Lets see how this works using a costing sheet assigned to a cost center. An overhead costing sheet was created to absorb 5% overhead based on the expenses posted to the assigned cost center.

A journal entry is posted to the cost center against the expense account that was defined as the base for overhead calculation.

When the above document was posted, a separate document was posted for the calculated overhead amount.

Thursday, April 13, 2017

S4Hana Finance Improvements - Profitability analysis

On the next few posts, I would like to discuss the improvements made as part of S4Hana finance. As the first topic on this series, lets take a look at the improvements made to profitability analysis.

S4Hana finance introduces a new type of profitability analysis called profitability analysis on universal ledger. This new type of profitability analysis is similar to accounting based COPA but includes some of the functionalities that were only available in costing based COPA in previous versions. It has to be noted that costing based COPA is still in play since some of the functionalities such as multiple valuations using COPA costing sheets, user exits etc. are only available in costing based COPA even after the introduction of COPA on universal ledger.


1. Splitting of cost of goods sold by cost components.

This was one of the compelling reasons for the selection of costing base COPA by most of my clients. This is where we could map the cost components of the standard cost of a material to separate value fields in costing based COPA while the accounting based COPA was posted with one cost of goods sold account. But this came with a major draw back where the cost of goods sold was posted in costing based COPA when the customer billing document is posted while the cost of goods sold is recognized in general ledger during post goods issue. This resulted in timing differences between GL reports and costing based COPA reports. Anyone who implemented costing based COPA would agree that this is one of the biggest complaints from the finance teams who try to reconcile costing based COPA reports to their general ledger based P&L.

SAP has given a simple solution as part of S4Hana finance to address this long standing issue.

As a first step we need to create and assign a cost splitting profile to the combination of controlling area and cost component structure. Splitting profile will then be assigned to company codes.

Financial Accounting (New) à General Ledger Accounting (New) à Periodic Processing à Integration  à Materials Management  à Define Accounts for Splitting the Cost of Goods Sold



Then separate GL accounts could be mapped to each cost component and cost of sales account.



Lets see the result of this in the cost of goods sold posting during post goods issue.


As it can be seen above, system have reclassified the cost of goods sold into respective cost components during post goods issue posting.


2. Splitting of production variances by variance category

Another short coming in the traditional accounts based COPA was that we could not analyze production variances by the variance categories since different variance accounts couldn't be mapped by variance category. This was possible in the costing based COPA using PA transfer structure. There were no timing differences between costing based COPA and accounting based COPA for production variance postings since both were updated during production order settlements but having this improvement to be able to map separate GL accounts by variance category is definitely a welcoming addition in SAP.

To activate this we need to define a price differences splitting profile and assign to company codes.

Financial Accounting (New)  à General Ledger Accounting (New)  à Periodic Processing  à Integration  à Materials Management  à Define Accounts for Splitting Price Differences

once the splitting profile is defined, you can map separate GL accounts for each production variance category.

In addition to the two improvements mentioned above, profitability analysis on universal ledger allows three additional unit of measures to be captures during COPA postings

Controlling  à General Controlling  à Additional Quantities  à Define Additional Quantity Fields
SAP provides the BADI "FCO_COEP_QUANTITY" to convert quantities and update universal ledger.

Hope this post helps you guys and please note that this is based on S4Hana finance add-on version 1605 or S4Hana version 1610 and this may change with the future releases.

Friday, December 30, 2011

Solution for outsourced checks

On this post I would like to talk about a solution that could be implemented to facilitate outsourced check printing. This solution assumes that the bank prints the check using the check number generated by SAP and transmitted to bank using an XML file.  Bank communication management is used to facilitate the internal approvals. But the detailed configuration steps needed for BCM would be discussed in a future post.

Step 1
Create a payment method for outsourced check using payment medium workbench.

 





Step 2
Map the Payment medium format to DME engine.

 















Step 3
Crete the DME tree for XML format.




















Step 4
Create a check lot number range and assign the payment method to the lot as shown below.


 























This concludes the necessary configuration steps. (BCM configuration would be discussed later)
Now let’s see how the payment process for an outsourced check would be done using this setup.

Step 1
Execute the automatic payment run.


















Step 2
Approve the payment using BCM. I will write about BCM in a future post.










Once the payment is approved, SAP would generate the XML file using DME. This file would contain the check number and other payment information to be sent to bank.



 



















This would also update the check registry in SAP. Subsequent electronic bank statements could be used to update cleared checks.

Hope this helps you guys. See you next time.

Sunday, May 01, 2011

Mix costing on SAP

On this post I would like to have a look at the mix costing functionality offered by SAP. This functionality could be used to calculate the average standard cost for a material that is procured/produced using multiple sources. Lets look at it step by step.

Step 1 – Define Quantity Structure (Configuration)

Define a quantity structure type as stated below.

Menu path on SPRO - Controlling → Product Cost Controlling → Product Cost Planning → Selected Functions in Material Costing → Define Quantity Structure Types

NewImage

Step 2 - Define Costing Versions (Configuration)

Assign the quantity structure type to the costing version.

Menu path on SPRO - Controlling → Product Cost Controlling → Product Cost Planning → Selected Functions in Material Costing → Define Costing Versions

NewImage

Step 3 - Maintain Procurement Alternatives for the material (Master data)

Maintain the procurement alternatives for the selected material using the transaction code CK91N. These would later be used to maintain the mixing ratios.

NewImage

Step 4 – Maintain the mixing ratio for the selected material (Master data)

Maintain the mixing ratio for the material using the transaction code CK94.

NewImage

Step 5 – Execute the costing run

Execute the costing run using either CK11N or CK40N. Now the costing run would calculate the standard cost based on mix ratio.

NewImage

Hope this post helps you guys. Please don't hesitate to drop your comments.

Saturday, November 20, 2010

Dual control on GL postings

On this post I would like to share a simple solution that would enable the companies to implement dual control on journal postings. In other words this solution would make sure that two users are involved on each journal posting where one person parks the document and another one posts it. Unlike the traditional authorization based solutions, none of the users are restricted at the transaction code level. This is how the solution works.

1. First user parks the document using FB50. If the user attempts to post, system throws an error message.
2. Second user posts the document using FBV0. If the second user attempts to post his own-parked document, system throws an error message.

Now lets see how this solution is implemented.

Step 1

Create a validation rule at complete document level with userexit.


Step 2

Implement the following logic in the validation userexit.


FORM us007 USING b_result.

* Enhancement by Shathees Loganathan.

select single * from VBKPF where BELNR = BKPF-BELNR and BUKRS= BKPF-BUKRS and BSTAT = 'V'.

if sy-subrc = 0.

if VBKPF-USNAM = SYST-UNAME.

Message e019(ZLF01).

b_result = B_FALSE.

endif.

else.

Message e018(ZLF01).

b_result = B_FALSE.

endif.

ENDFORM.

Now lets see how would this affect the journal entries.

Step 1

First user parks the document using FB50. If the user tries to post the document, the following error message is shown.

First user parks the document.

Second user posts the document using FBV0. If the second user tries to post a document parked by him, the following message is shown.

If the second user posts a document parked by another user, system allows the document to be posted.

This solution could be further enhanced. For example we could allow certain managers to post the document directly through an exception process or we can implement this dual control to certain GL accounts or document types.

Hope this is useful. See you all next time.