Hi all,




We already have new notes just released for 1099 reporting, where Print Forms Layouts in Smartforms and PDF format are available.


Two notes are available:

2227185 - US Legal Change 2015 - 1099 and 1042 Smartforms and Adobe Forms (600 and above)

2227186 - US Legal Change 2015 - 1099 and 1042 Smartforms and Adobe Forms (current releases).


Those notes are the main notes which will contain the relevant details to be adjusted in order to correct and update 1099 and 1042 report including Smartform and Adobe Forms.




The major changes include:

1. 1099INT - Box 13 "Bond Premium on tax-exempt bond", "FATCA filling requirement" checkbox introduced and year changed to 2015;

2. 1099MISC/MISC1- "FATCA filling requirement" checkbox introduced and year changed to 2015;

3. 1042S - Numbering of the boxes are changed and year changed to 2015;

4  1099G - year changed to 2015;

5. 1099K - Box 1b is renamed and year changed to 2015.


Also notes containing the newest changes for 1099 Files were released:
2250865 - US 2015 LC - 1099 File Changes
2250866 - US 2015 LC - 1099 File Changes ( for lower releases).



Please follow up on those notes for latest updates about 1099 and 1042 updates for the Tax Year 2015 to be submitted in 2016.


I hope it helps to address you your concern about this subject.


Danton Prestes.

Probably we may have noticed that all FI documents for corresponding controlling document that are generated from the controlling application component is most of the times same i.e. AB or any other document type that we might have configured.


However there might be a Business Requirement that we should be able to distinguish the FI documents that are generated because of the corresponding controlling document from other FI documents generated out of non-controlling application component.


How to address this Business Requirement

  • First: We can definitely look at the business transaction from FI Table – BKPF & BSEG and Text field in BSEG in order to check if the FI document is related to a Controlling Document however this may not be very handy as more analysis might be required.


  • Second: We can create & designate a different document type for the FI postings that are generated because of corresponding controlling document posting and in that way only by referring the document type it is quite easier to identify instead of depending on text or business transactions.


Now the question comes where we configure the Document Type that is used for FI posting for a controlling document:

Classic GL Design: We used to set the document type in the posting parameters during the reconciliation posting execution through the SAP Standard Transaction Code – KALC.


New GL Design: With the blessing of New GL we can’t use the transaction code - KALC anymore however CO-FI Real Time Integration is playing the role so we need to set up the appropriate variant for the CO-FI Real Time Integration. - Refer Transaction Code : S_ELN_06000002


CO-FI Real Time Integration Variant.jpg


Also we have one more configuration where we can consider to provide the document type is the settlement profile (this is being there in Old as well as

New GL). Refer Transaction Code - IW33 (as in this case its PM Order) & OKO7 for Settlement Profile.


Settlement Profile Document Type.jpg


Q: Why using the document type – AB does not help:

  • Document Type - ‘AB’ is the generic accounting document type used to post FI documents and also reversal for many other document types used in FI i.e. EX (External Document), SB (GL Account Posting), SA (G/L Account Document), RV (Billing Doc.Transfer), DA (Customer Document) etc.

  • Also we use Document Type – AB in the CO-FI Real Time Integration variant or Reconciliation posting screen in Classic GL.

  • Again most of the time I have seen client use same document type – AB in respective settlement profile.




Now the following question pops up to our mind:


Q. Can we use different Document Type in the CO-FI Real Time Integration Variant than AB?

Ans:  Yes, we can definitely achieve that with the sap standard configuration i.e. create a new different custom document type altogether for this purpose for example – we have created custom document type – ZX for this purpose. Refer Transaction Code - OBA7.


Creating a New Document Type.jpg


If we create a new document type and if the document splitting is turned on then we need to configure the FI Document Type for the document splitting as well:

Refer Transaction Code - S_ALR_87008944


Document Splitting for Document Type.jpg


Q. When the document type is used from CO-FI Real Time Integration Variant and when does it come from the Settlement Profile?

Answer: Let’s test some of the main scenarios and then we would be in a position to conclude what should be the answer:

  1. Manual Cost Allocation (Transaction Code - KB15N)
  2. Direct Activity Allocation (Transaction Code - KB21N)
  3. Manual Reposting of Primary Costs (Transaction Code - KB11N)
  4. Assessment (Transaction Code - KSU5 or GJF5 based on if it belongs to application component Controlling or Joint Venture Accounting)
  5. Distribution (Transaction Code - KSV5 or GJG5 based on if it belongs to application component Controlling or Joint Venture Accounting)
  6. Work Order Settlement to GL Account (Transaction Code - KO88 or KO8G)
  7. Work Order Settlement to Cost Center (Transaction Code - KO88 or KO8G)
  8. Work Order Settlement to WBS (Transaction Code - KO88 or KO8G)
  9. Work Order Settlement to Asset (Transaction Code - KO88 or KO8G)


  • Testing Scenario: Manual Cost Allocation (Transaction Code - KB15N)


Manual Cost Allocation.jpg


Manual Cost Allocation1.jpg

Manual Cost Allocation2.jpg

Comment: Document Type in FI Document derived from CO-FI Real Time Integration Variant and not from Settlement Profile.

  • Testing Scenario: Direct Activity Allocation (Transaction Code - KB21N)


Direct Activity Allocation.jpg


Direct Activity Allocation1.jpg


Comment: Document Type in FI Document derived from CO-FI Real Time Integration Variant and not from Settlement Profile.



  • Testing Scenario: Manual Reposting of Primary Costs (Transaction Code - KB11N)


Manual Reposting of Primary Costs.jpg


Manual Reposting of Primary Costs1.jpg


Comment: Document Type in FI Document derived from CO-FI Real Time Integration Variant and not from Settlement Profile.



Testing Scenario: Execution of JVA Assessment (In this case we are referring to Assessment Cycle from JVA application component and that’s why you can see JV Assessment Business Transaction instead of CO Assessment Business Transaction) - Transaction Code - GJF5

JVA Assessment Cycle.jpg


JVA Assessment Cycle1.jpg


Comment: Document Type in FI Document derived from CO-FI Real Time Integration Variant and not from Settlement Profile.



Testing Scenario: Execution of Distribution for CO Distribution Business Transaction (Transaction Code - KSV5)

CO Distribution Cycle.jpg


CO Distribution Cycle1.jpg


Comment: Document Type in FI Document derived from CO-FI Real Time Integration Variant and not from Settlement Profile.



  • Testing Scenario: Work Order Settlement to GL Account (Transaction Code - KO88)


Work Order Settlement to GL Account.jpg


Comment: Now the document type of the corresponding FI Document generated out of this settlement is from the Settlement Profile used in the Work Order and not from CO-FI Real Time Integration.



  • Testing Scenario: Work Order Settlement to Cost Center (Transaction Code - KO88)

Work Order Settlement to Cost Centers.jpg

Comment: Document Type in FI Document derived from CO-FI Real Time Integration Variant and not from Settlement Profile.

  • Testing Scenario: Work Order Settlement to WBS (Transaction Code - KO88)

Work Order Settlement to WBS.jpg

Comment: Document Type in FI Document derived from CO-FI Real Time Integration Variant and not from Settlement Profile.

Testing Scenario: Work Order Settlement to Fixed Asset (Transaction Code - KO88)

Work Order Settlement to Fixed Asset.jpg

Comment: Now the document type of the corresponding FI Document generated out of this settlement is from the Settlement Profile used in the Work Order and not from CO-FI Real Time Integration.


Document Type used in the settlement profile are only taken by the FI Documents that are generated out of either settlement to Fixed Assets or GL Account and in all other scenarios generated out of controlling, the FI document types are taken only from CO-FI Real Time Integration Variant.



Still we have the question why Document Type is taken from CO-FI Real Time Integration Variant:


  • This is standard sap behavior for any FI Document that is generated because of original document sourced in controlling component.

  • The document type used in the settlement profile is actually relevant only for the settlement runs for accounting and balance sheet as a settlement receiver. For example settlement to GL Account or AUC.


Would appreciate your comments or suggestions if any..

How many times the question “How to cancel payment run F110?” (reverse F110, mass change F110, you name it) has been raised here on SCN?


The answer has always been: do it manually by FBRA  + F.80. Manual. Painful. Long. Frustrating.


Well it was till now. Because believe it or not, SAP has actually improved F110.


Source: http://www.sapimprovementfinder.com/public/note?n=0002127698

Improvement request

The department can reverse the payment documents of a payment run (F110) only individually using transactions FBRA and FB08. In case of error, it should be possible to reverse all payment documents of a payment run.


If an error occurs (for example, caused by incorrect Customizing settings or incorrect parameter entries), the reversal of all payment documents of a payment run is time-critical because late payments may have negative financial effects. Currently, reversals must be made individually by a user or with the help of a customer program or a consulting program. In the standard SAP system, there is no solution for this exceptional situation.


With the new program RFF110S_REVERSE, the department can reverse all payment documents of a payment run (F110) if there are incorrect clearing postings in the payment run due to an error. Application examples:

  • There is an incorrect grouping of cleared items due to incorrect Customizing settings.
  • There is an incorrect posting date or value date due to incorrect parameter entries.

Subsequently, the payment run can be repeated under a new identification after the correction of the Customizing or the parameters.


With the new program RFF110S_REVERSE, the department can reset and repeat the payment run timely and without support from IT, the support department, or consulting. As a result, the risk of financial damage caused by late payments due to user errors is reduced.


The improvement is delivered as of SAP ERP 6.0 via a correction, and it is also delivered in a Support Package as of SAP ERP 6.0 Enhancement Package 7. For additional information, see SAP Note 2125220.

Hi all,


In my last research I've found that sometimes the substitution at Call-up point 3  is not get triggered for MIRO documents.


I would like to share with you solution according to your release, If you are until 470 system release, please refer note below:

  • 386896 Substitution at call-up point 3 ("Complete document") , as per stated in the note MIRO will not work for substitution with callup point with complete
    document (call-up point 3).



If you are in a higher support package than 470 I kindly ask you to take a look at notes:

  • 42615 Substitution in FI - this note contain valuable information on the FI substitution scenarios.



The note 842318, help you about the frequently asked question about the topics below:

  • How creating, activating and transporting validations and substitutions;
  • Using user exits in validations or substitutions
  • Problem analysis

I Hope the information provided helps you.



Best Regards,

Manuela Valente.

Hello all,



SAP note 2083799 provides a composite scenarios involving posting with Accounting BAPIs. But I want to share with you more details related foreign currencies scenario:


The currencies are maintained in transaction OB22 for each company code. You can also see the 2-digit currency type keys here, which are used in accounting interface as well.

Currency type = 00 (document currency) and Currency type = 10 (local currency) are the only real hard-coded keys. You can also see this in OB22, as you cannot change the currency type key for local currency. For 2nd and 3rd local currency, the value depends on the kind of currency you are using. You can find a complete list of the different currency types in SE11 by checking the value range of the domain CURTP.

You see in currency type that basically it always ends with a 0. So the typical values are 10, 20, 30, 40... You also have a valueation field directly underneath with a single digit. This can indicate legal valuation, profit-center valuation and so on. For FI only legal valuation is relevant. If another valuation is maintained, then this value in valuation field will be added to currency type. So you can have a customizing like this:

2nd LC, Currency Type 30, Valuation 0 – legal valuation, currency USD
3rd LC, currency type 30, valuation 2 – profit-center valuation, currency USD


In this case LC2 would be currency type 30 and LC3 would be currency type 32. Only LC2 would be transferred to FI. LC3 would be relevant for profit-center accounting. Eventhough the amounts in LC3 are not relevant for FI, they are determined in FI-Interface (function FI_DOCUMENT_CHECK) if they have not been passed to accounting interface.


You do not have to provide the local currency amounts to accounting interface. Only the document currency is mandatory. But of course you CAN submit local currency to accounting (as MM does for example) then only the missing local currencies are determined in FI-Interface. Only important fact is: IF you submit at least one local currency, you should submit it in all line items and not just at single items. Otherwise a balance issue can occur.


More information on correct setup of OB22 is listed in note 335608.

I hope this helps!





SAP note 2083799 provides a composite scenarios involving posting with Accounting BAPIs. But I want to share with you more details related rounding differences in cross-company scenario using BAPIs.



1) In case of cross-company scenarios the rounding difference is distributed at:

FORM  SUBST_CLEARING (here the company code clearing line items are generated)



2) If the document is not a cross-company posting, the rounding difference is distributed at:

or (depending on the AWTYP)



Important to know is that the rounding difference will always be distributed as described in note 106094 (point 2 is relevant for postings using accounting interface). This means, even on cross-company scenarios the rounding difference is distributed to the first non-tax GL line item – no matter on which company code this item is. The logic in FB01 is equal.


In the form routine get_tolerance the tolerance level is determined, which is (in most cases) basically simply 2 * number of line items of the document. If the rounding difference is higher than this, the rounding difference cannot be distributed by FI-Interface.


If rounding difference is less than tolerance, the first non-tax GL line item is determined at:
loop at accit_fi where koart ca 'MSA'
                         and   taxit <> 'X'


If it cannot be distributed to those items either, it is tried to distribute it to a Customer/Vendor line. If this fails as well, error should be raised. For some countries there is even a legal requirement to create a separate rounding difference line item, which is also done in those form routines. That is done at the very end at insert_rdf_items.


I hope this helps!





Buffering activation for FI documents brings many questions from customers. SAP has various Notes and WIKIs related this topic, but I decided share with you some specific questions that I have already worked.



1 - What kind of GAPS we can have with parallel buffering and how we can document them to the business?


2 - Do we have to run reports RSSNR0S1 and RFVBER00 daily/weekly/yearly?


3 – Can a buffering which has been activated be later deactivated? What is the impact of making this change?


4 - What is the recommendation on the Testing which is required to be performed for this buffering?


5 - Which is the overall impact of activating number range buffering?




1 - What kind of GAPS we can have with parallel buffering and how we can document them to the business?

A: As described in note 1522367 point 3 "gaps" can occur at fiscal year end if number assignment is year dependent and numbers in buffer is more than 1.
Example parallel buffering with numbers in buffer = 10 and 2 instances: both instances draw 10 numbers. instance 1 = number 100010 to 100019 and instance 2 = number 100020 to 100029. Till year end close 7 documents are posted on instance 1 and 3 documents are posted on instance 2.   So for instance 1 no. from 100017 to 10019 and for instance 2 no. from 100023 to 100029 will not be used. But again these are not real gaps and again there is report RSSNR0S1 for documentation.


2 -  Q: Do we have to run reports RSSNR0S1 and RFVBER00 daily/weekly/yearly?

A: As answers above may have illustrated neither parallel buffering not buffering in ascending order will cause more real gaps than buffered number range object. But of course as developer I cannot give you a recommendation how often reports  RSSNR0S1 and RFVBER00 should be executed. This depends on your system administration and reporting requirements. As said buffering does not cause more update terminations. So there is no need to execute RFVBER00 more often only because of activated buffering. But of course RFVBER00 has to be executed before update terminations will be deleted by your
system administration.


3 – Q: Can a buffering which has been activated be later deactivated? What is the impact of making this change?

A - Yes, number range buffering can be deactivated later. But sure, postings created while number range buffering was activated will show the document numbers derived in the logic of the individual number ranges buffering type.

One possible setting in number range buffering is e.g. SNRO -> RF_Beleg to activate the flag 'parallel buffering' and to set the numbers of buffers to 1.

This means each application server picks one document number of the number range and buffers this one locally. In this way between parallel Application Servers parallel postings are possible. With this setting postings executed within each application server will be serial and chronological, only within different application servers the document numbers will not be derived chronological. In some countries it is said by law, that document numbering needs to be serial, but it is not said if this is related to a complete system and in such cases parallel buffering is an option. This means the local law must be studied carefully
before choosing one of the different buffering types.


4 - Q : What is the recommendation on the Testing which is required to be performed for this buffering?

In case a decision is made, testing is not necessary as this is a common setting which is used by nearly all customers.
You just need to choose a way of buffering, which is allowed by the country specific law of your Company Codes.


5 - Q – Which is the overall impact of activating number range buffering?

A - Depends on the way of buffering. E.g. in case you choose in SNRO the number of buffers with 100, this would mean that your application server will pick 100 document numbers and 100 postings of each number range could be done locally on this application server in parallel. But in case until the next application servers shout down only 70 postings are done, 30 document numbers will be unused, which means you would have a number range gap of 30 document numbers as after booting the application server again this one will increase the actual document numbers setting by 100 and store 100 new document numbers locally. -> but sure you need't choose  100, it is also possible to choose 10 or even 1. The advantages and disadvantages are described in note 1398444 and mentioned notes.


I hope this helps!







Frequently I receive questions related to difference between standard parallel buffering and pseudo ascending in FI. So I decided to share with you some findings related this topic:




There are 2 differences.



1.a) Parallel buffering uses number of numbers in buffer as maintained in transaction SNRO.

1.b) Buffering in Pseudo ascending order is using always number in buffer = 1. This is hard coded for buffering in pseudo ascending order.





Usually parallel buffering with numbers in buffer = 1 solves performance / lock waits issue for RF_BELEG.



2.a) Parallel buffering: In case of rollback number(s) will be reused.

2.b) Buffering in Pseudo ascending order: In case of rollback number(s) will not be used again. Otherwise the number assignment would not be chronological anymore.
Numbers which were not used again are transferred to table NRIV_RESTE. So in case of Pseudo ascending order you may have gaps in BKPF. But these gaps are not real gaps as there is report RSSNR0S1 for documentation.




For an overall explanation related to Number Range in FI, I usually check the following WIKIs. They link the most relevant notes for each specific topic:



NUMBER RANGE : Buffering

NUMBER RANGE : Gaps in Number Range

NUMBER RANGE : General Information





The below SAP note is a FAQ note and very useful also:

1398444 - Buffering the document number assignment for RF_BELEG




I hope this can help!





In this post we will look at the convergence of long standing pieces SAP ERP finance master data, the GL Account and the Cost Element. As anyone that has worked with SAP CO in the past knows the cost element is key to the controlling side of SAP. It in an object that allows you to identify the type of activities that can be done within controlling with that account. They are generally divided into Primary and Secondary cost elements.


  • Primary cost elements have an associated GL account and are generally expense or revenue accounts.
  • Secondary cost elements exist only in CO and are used for internal settlements, assessments, and allocations. 


When creating a new revenue or expense account in the GL you have to create a corresponding cost element in CO and typically all you were doing was selecting a Cost Element Category.


With the Simple Finance Add-on 2.0 (now called On Prem 1503) the traditional cost element create, change and display transactions are gone. The functions have been combined in FS00 - Manage G/L Account Centrally. This greatly simplifies the act of creating a new account and eliminated the need to maintain separate masters.


On the Type/Description screen there is a new field called account type. If you select either "Primary Costs or Revenue" or "Secondary Costs" a new field will appear on the Control Data tab for you to enter the Cost element type.


Primary Cost Example:


FS00 screen 1.jpg


FS00 screen 2.jpg

Secondary Cost Example:



FS00 screen 3.jpg

FS00 screen 4.jpg


I think this is a good step forward in simplifying the SAP finance master data and driving the convergence of FI and CO.


Recurring Entries

Posted by SUMIT MISHRA Mar 12, 2015

What are Recurring



Recurring entries allows the business a function for automatic
creation of accounting entries based on the predefined parameters.



Once the Recurring entries are created they get posted into
the SAP system as per the defined schedule by the business.



Use of this functionality is only recommended to be used
only if the account assignments objects, General ledger accounts don’t change
when the document is posted.



Recurring entries can be used in General Ledger, Accounts
Payables and Accounts Receivables postings and thus this functionality of SAP
can be used for various requirements of recurring documents postings



For Example if the Business requires the rent payments
executed each month of $1000 then we can create the recurring entries to post
those particular expenses.



Also if there are any changes we can do so and recurring
entry functionality tracks all these changes and we can see all the changes
which have been done.



How we can set up
Recurring entries in SAP?



The process to create recurring entries in SAP is pretty
straight forward and simple and this process can be used for variety of purposes.



Example shown in this document is just an reference to show how
to proceed with the process .



You can create recurring document for anything like GL posting,
AP posting or AR postings however the process will be similar as displayed in
the below screen shots.



Create the recurring document ( Please note that
recurring document number range is X1)

Transaction code FBD1











To Display Recurring Documents Transaction code FBD3





Create Recurring Documents in Books Transaction code F.14

You need to fill the details of the recurring document earlier created.

If the schedule have been defined then the recurring documents will be created as per the schedule.

Press Execute as shown in below screen shot and the Session will be created.



You can see the session of the recurring document using the transaction code SM35



Once the session is completed the Recurring document is
created in the General Ledger.  You can display usingTransaction code FB03


Recurring 8.png

Changes In Recurring document


For example if the situation arises that we need to change the recurring documents

Execute the T code
FBD2 and here we changed the payment terms from ZK26 to ZK25 and Saved it




Please note-

Some times there are requirements to see the change log  by the Business of the recurring documents we can see using the transaction code FBD4 and please notice it tracks all the frequent changes done in the past for the recurring document.

Below Screen shows the changes done in the other recurring document not shown in the above example for reference.



Recurring 10.png

Conclusion- Recurring entries is a very helpful process to post the repitative Accounting/Invoice postings in a easier and accurate way and it saves times of the end users in doing this activity every month.

Mostly this functionality can be used for booking accruals it they are same each month, Rent or Lease rental payments, Utility Bills etc.

By deploying Simple Finance, IT can bring transformation to finance. In the introduction to this series, we learned the need for simplification and the role HANA plays.


Simple Finance is our industry-leading financial solution re-built to take advantage of SAP HANA. Perhaps the most significant change from this re-build is with reconciliation. If we understand reconciliation and how Simple Finance eliminates it, we can communicate Simple Finance benefits with our colleagues in finance using an example that make sense to them.


There are two general areas of accounting:


  1. Financial (FI). For external entities. Main reports are balance sheet and P&L statements.
  2. Controlling (CO). For internal reports to management, mainly focused on cost.


In software today, FI and CO are separate components or systems, historically thought to be independent areas. Certainly they have different structures and key figures. Executives, though, wanted a holistic view, and this meant a huge reconciliation challenge to understand the differences between systems, and bring them together in a single ledger. Reconciliation is a massive, time-consuming effort that has to occur often:


  • Within components. Ensuring totals match up with underlying line-items.
  • Between components. Comparing figures between functions, like results in the P&L module to the cost-based profitability analysis module (CO-PA).


There have been improvements to make reconciliation easier, notably the New G/L (General Ledger) in ERP 2004. Ultimately, though, none of the improvements solved the underlying issue: detail is stored separately by all components (such as General Ledger, Controlling, Asset Accounting, Material Ledger, Profitability Analysis).


HANA’s most important capability is aggregating within seconds hundreds of millions of items in one table in memory. Thus, it is the ideal architecture to solve reconciliation. In Simple Finance, we combine all the data structures of the different components into one table: the Universal Journal. HANA’s columnar store with superior compression make this possible.


We can’t adequately describe the structure of the Universal Journal in a short article. The important thing for now is that HANA and the Universal Journal solve both reconciliation problems. Recall that with HANA, we no longer need redundant data (aggregates and indices) to do analysis, so the first issue of reconciliation within components is solved. All totals are derived on-the-fly from the line-items directly.


HANA before after.jpg


The more difficult reconciliation between components is solved as well. We merge the components in the Universal Journal to guarantee real-time integration. For example, with FI and CO combined logically in the Universal Journal, users drill down to the same line items from the key figures and reports of either component.


Since HANA provides unprecedented speed for multidimensional analysis, it is no longer necessary to replicate data to OLAP. Even should OLAP be needed, ETL is much simpler from the Universal Journal instead of multiple components.


All of this means dramatic simplification. In one case, a Fortune 500 early adopter cut 120 person-days per month from reconciliation efforts. This is time that can be spent on more strategic planning and analysis tasks.

Are you thinking about the next big accomplishment IT can provide for our colleagues in the finance department? You should be, because now with SAP Simple Finance, we have a great opportunity to transform how finance operates.


CFO.com reported recently that 76% of finance executives think strategic planning will be the biggest area of new demand. You can’t act strategically, however, when so much time is spent on the tactical. Consider:


  • 70% of analytics effort is preparing data (IDC, Feb 2013)
  • 76% of global companies do not have financial performance data at the ready (Harvard Business Review, 2014)
  • 73% of executives think complexity is their biggest IT challenge (Forrester, 2013)


At SAP, we want to attack complexity in finance systems. That is why we took our industry-leading finance solution and re-built it to take full advantage of HANA. The result is Simple Finance. From an IT deployment point-of-view, you can think of Simple Finance as the next version of our finance solution.


I hear all the time from our customers: “What exactly makes Simple Finance simple? What have you simplified? Will it be worth the effort to upgrade?”


This is the first in a series of articles where I will answer these questions. Each article will describe how Simple Finance transforms a key tactical process like reconciliation, analysis, and closing. Simple Finance makes these processes simpler, freeing up finance to focus on the strategic. If you know about these processes, you can explain the benefits of Simple Finance to your finance colleagues in examples that are meaningful to them.


Before we look at specific finance problems, we must first understand the foundation of Simple Finance: HANA. You probably know that HANA at its core is an in-memory database engine. In-memory means that queries run exceedingly fast. But speed alone isn’t good enough. In some cases, it may be worth the upgrade to get queries to run faster. But we want to go further and use the speed to simplify the underlying architecture. How do we do this?


The simplest way to explain it is this: we put everything into one database engine in memory. Queries, transactions—all of it. Because HANA is so fast, and the column store lends itself to excellent compression, we can finally do this. Previously, database architects needed to separate transactions carefully from queries and design redundant data (indices, subtotals) to handle the query workload. Not anymore.


HANA one source.jpg


This has a profound impact on finance systems. First, the database footprint is reduced dramatically since we no longer need redundant data. But more importantly for finance, it means we can combine data for two different tasks—transactions and queries—into one data store. This is the beginning of the simplification of finance systems. I hope you’ll read on in the series to see the specific examples. Part 2.

Hi all,

Before Implementing the 1042s note regarding US Legal Change 2014, please implement the note 2095167 for DDIC changes.

2095204 - US Legal Change 2014 - 1042S Form Reporting


At note 2095204 you have 'adobeform_upload.pdf' with instructions to change the interface 'GS_IDWTCERT_US_1042'.

If you don't have the 2013 interface, Please apply notes:

1949019 and 1949020 -> Smart forms
1949021 and 1949022 -> Adobe forms


I hope it helps to address your concern about this subject.


Best Regards,

Manuela Valente.

Business need


Our finance department engaged with a local bank to accelerate vendor payments with a p-card program. Once set up on the bank's website, they would just need a simple comma-separated text file (CSV) with some basic data like our vendor number, the vendor's invoice number, the payment date, and the amount. This was the minimum requirement; there were several other optional fields, but for this pilot project, just these four were needed. Finance asked us to configure the new payment program and help them get a test file to the bank.



Up to this point, we had been using mainly paper checks. A few vendors were accepting ACH payments, but not many. Both of these payment methods relied on the classic payment programs (RFFOUS_T and RFFOUS_C.) As this would not be printing data to a form, nor would it be outputting a standard file format like ACH, we would have to come up with a custom DME solution.


  1. Configure a Data Medium Exchange format tree
  2. Configure a Payment Medium Format that calls the DME format tree
  3. Configure a variant in the standard program
  4. Associate the new payment method with some vendors
  5. Test


Create DME format tree

This was by far the easiest thing. Using transaction code DMEE, I created a flat file format. The DME Blog and SAP Help were surprisingly helpful in this (see links below.) Some of the key things to remember were the following:

  • Remember your format tree name because your Payment Medium Format has to be named the same thing. This hung me up for the longest time.
  • Set your field type to 1 and your segment delimiter to a comma to get a CSV output.
  • Don't forget to set the carriage return and line feed check boxes on the File Data tab. Whereas the comma was your field delimiter, the CR-LF will be your record delimiter.
  • A segment is like a row.
  • An element is the equivalent to a field. These elements are mapped to specific fields in the various payment structures (FPAYP, FPAYH, etc.)
  • A technical node is similar to an element, but it does not get output into the file. In my case, I had to create a technical node for the currency code so SAP would configure my amounts correctly.
  • Conversion functions are available for elements to format currencies, dates, and other strings of text in any way you might need. Need to get rid of leading zeroes in a cost center field? There's a conversion function for that, and there's even a handy wizard to walk you through getting the correct one in plain English.


Configuring the payment medium format

This was a challenge before I carefully read the DME blog. I cannot overstate how helpful this blog was. Since I was going into this effort without much formal training in configuring the payment program, this no-nonsense, plain-language blog was much more useful to me than SAP's documentation, which I found cryptic at times. Some of the key lessons I learned were the following:

  • Create New Entries rather than copying from an existing format if your format is non-standard. If you are tweaking an existing format, copying makes sense. My first attempt was a disaster because I copied an ACH format and wondered why my output looked like an ACH file.
  • Your format name must be the same as your DME format tree name. This caused me no end of pain, too, when the payment program either produced nothing (without errors) or produced error messages that weren't very helpful. When you name both things the same, everything just falls into place.
  • Step through everything in FBZP so you don't miss anything. Every button; every setting -- check and recheck that you configured everything you needed to. If you miss a setting in FBZP, you won't get the output you want. Trust me.


Configure a variant in the standard program

Once SAP sees that you are trying to pay using the Payment Medium Workbench and DME, it's going to steer clear of the classic RFFOUS* programs and use SAPFPAYM instead. The variant you create will reference the payment medium format you configured in the previous step, tell the program to use DME to create the output, and specify a default directory and file name. This is just like setting up any other variant in SAP, but you have to take another step after this.


You must go to transaction OBPM4 and associate the variant with your payment medium format. You must or you will bang your head on your desk as much as I did, even though it doesn't help get you your output file at all. Only configuring OBPM4 does that.


Associate the payment method with vendors and test

Here is where you engage your business users and start testing. Once you start using the new payment method (for instance putting it on the vendor master record,) then when you run F110, the DME magic happens.


Now what?

I have written here in very general terms about the configuration steps required to configure a custom, non-standard payment method. I have tried to identify the painful lessons I learned trying to do it myself. There are many details and nuances I did not cover, but that the DME blog covers exhaustively. I look forward to your questions and comments below.






From a standard SAP process, the instruction key that is updated in vendor master (LFA1-DTAWS) is captured in to REGUH-DTAWS when F110 or RFF110S is executed. As a next step when SAPFPAYM ( t code FBPM) is executed, this gets populated in the XML file.


For some reasons that does not seem to happen for me. I have identified SAP notes 2106391 ( includes 1574937 &1779966) for this issue.


Did some one come across a similar issue like this. Does this notes fix the issue?


Best regards




Filter Blog

By author:
By date:
By tag: