Search The SAP Consultant

Thursday, March 15, 2018

Charging interest on overdue items from customers

On this post, I would like to share my experience with a request came from my current client regarding the solution in SAP to calculate and charge interest on customer overdue items. The business requirement was to charge interest on overdue items from selected customers with the rational that this would encourage the customers to pay the invoices on time.

The following configurations were done on a S4Hana 1709 system for the purpose of this post and the customer demo that I have done but the solution is similar on older versions of SAP except  that the customer master is created through business partner functionality in 1709.

Step 1 - Define Interest Calculation Types

In this step, we define the interest indicator that will be maintained on customer master data for the customers who are in the scope. Interest calculation type "P" indicates that the interest is calculated per customer open items.

Financial Accounting à Accounts Receivable and Accounts Payable  à Business Transactions  à Interest Calculation  à Interest Calculation Global Settings  à Define Interest Calculation Types


Step 2 - Prepare Item Interest Calculation

In this step, we define various parameters used in the interest calculation and posting. For example, the reference date to be used when the due date is determined for the interest calculation (Select "4" to use the payment baseline date), whether the calculated interest should be posted (Select "Post interest" tick box), the payment term to be used for the interest receivable and whether do we want to post the interest with reference to the original invoice (Select "Postings with invoice Ref").

Financial Accounting à Accounts Receivable and Accounts Payable  à Business Transactions  à Interest Calculation  à Interest Calculation Global Settings  à Prepare Item Interest Calculation


Step 3 - Define Reference Interest Rates

In this step, we define the reference interest rates against which the interest rate percentages will be maintained in later configuration steps.

Financial Accounting à Accounts Receivable and Accounts Payable  à Business Transactions  à Interest Calculation  à Interest Calculation  à Define Reference Interest Rates

Step 4 - Enter Interest Values

In this step, we maintain the interest rate percentage for the reference interest rates maintained in previous configuration step. Rate can be maintained with validity periods.

Financial Accounting  à Accounts Receivable and Accounts Payable  à Business Transactions  à Interest Calculation  à Interest Calculation  à Enter Interest Values

Step 5 - Define Time-Based Terms
In this step, various control parameters such as the amount from which the specific interest rate to be applied "Amount from") or any premium that needs to be applied above the standard interest rate in cases such as high overdue amounts ("Premium") will be configured against the interest indicator. And also select the term as "Debit interest: arrears interest calc".
Financial Accounting  à Accounts Receivable and Accounts Payable  à Business Transactions  à Interest Calculation  à Interest Calculation  à Define Time-Based Terms
Step 6 - A/R: Calculation of Interest on Arrears
GL Accounts are mapped against the account symbols on this step. AR reconciliation account is mapped against account symbol 1000 but the customer sub ledger account will be debited during interest posting.

Financial Accounting  à Accounts Receivable and Accounts Payable  à Business Transactions  à Interest Calculation  à Interest Posting  à A/R: Calculation of Interest on Arrears



Above steps complete the required configurations needed for the AR interest calculation function in SAP. The interest indicator configured above should be maintained on the business partner (Customer master on old versions of SAP) master data. This allows the company to pick and choose the customers who should be part of interest calculation. 


Once the interest indicator is maintain on master data, Transaction FINT will be used to calculate and post the interest for customer over due items.




Hope this post helps you to understand the interest calculation process in SAP for customer over due items. 


Wednesday, January 10, 2018

Journal entry upload in S4Hana using Fiori app.

One of the common requirements that we come across in projects is the requirement to upload journal entries using excel templates. We normally propose third party tools such as ZOption, Winshuttle or a custom development to satisfy this requirement. Each of these third party tools come with their own strengths and weaknesses and importantly license fees to use them. A custom development comes with the cost related to design, development and maintenance.

With S4Hana, SAP has given a standard solution to upload journal entries using Fiori apps. I'm going to talk about this standard solution in S4Hana on this post. There is no need for any customizations except the installation of the Fiori app to make use of this standard functionality.

Please click on the images to enlarge them.

Step 1

We need to install the app F2548 - Upload journal entries. 




Step 2

Once the app is installed launch it using the Fiori launch pad.




Step 3

Click on the "Download Template" link on the lower right corner of the app. This will give the option to download the journal entry template using Excel or CSV formats. I have selected the excel format for the purpose of this post. Save the template on the desired location.



Step 4

Once the template is downloaded, we can populate it with the required journal entry or entries. Following options are provided with the solution.

1. Data elements are validated when the entry is posted. This solution doesn't provide field drop downs on excel template for input fields like some third party tools such as ZOption do.

2. Multiple journal entries can be loaded by adding multiple header records on the same upload file.

3. Ledger specific postings can be loaded by populating the ledger group on header.




Step 5

Once the file is prepared, load it using the upload option available on the Fiori app. Selecting the file will load it into the staging area but the entry is not posted as part of this step.



Step 6

Click on "Post" option located on the bottom right corner of the app. System will display the accounting document numbers once posted.


Any data errors will be displayed using the posting log. Log can be seen by clicking on "Show Log" option located on bottom right corner of the app. We can fix the errors on upload template and reload it by updating the "Batch ID" field on the upload file with the "Batch ID" provided as part of the original load.






I hope this post is helpful to you guys. Please do let me know your feedback.

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.