SCN : Blog List - SAP ERP Financials

Over the last few months, I have been facing an issue whenever I try to create a TR request. All of us know that for most of our SAP configurations, SAP automatically prompts for a TR number and includes all the relevant data on the TR request.

SAP best practice says that we should not tamper with the TR request contents, meaning, no manual changes to be done to the TR. But, I have seen people have issues with this. They are never ready to leave the poor TR request contents alone, the reasons may be different.

SAP expects that the configuration in our Production client is the same as the one in our Configuration client. This is to be 100% adhered and so does not encourage manual tampering of TR’s. The reason being, when the set up is same, irrespective of the TR contents, the config remains same throughout the landscape once the TR reaches production.

People have reservations because, they are not sure that Prod and Dev configuration is the same or in case of substitutions and validations, where a whole lot of other data along with your changes are also included in the TR (since TR is not created at the step level).

There may be other reasons for manual TR need. Say, a Z table does not prompt for TR when changed. In such a case also you would need a manual TR.

I have heard different approaches for creating this manual TR with the desired entries only. But, recently I came across the easiest one.

In case of say transporting fields to be restricted to be not used in Validation or substitution creation as explained in my document (Restricting/Unrestricting Fields for Substitutions and Validations), the TR SAP prompts for has only the changed entries. So, if we say we have changed or created 2 entries in the table, even if the table has 100 entries, only the 2 are included in the TR.

But, in some cases like OBYC settings, the TR created by SAP tends to include all the entries present for that transaction. Say, for BSX, we have 20 entries and we have added 2 more, all the 22 entries are included in the TR which SAP creates. In such cases, to get people off your back who are concerned about the TR contents, you can easily create a manual TR using SE16 or SE16N.

CATCH: To create a manual TR, you should be aware of all the underlying tables for the config to move correctly. Also, you need to take a call which tables are required and which are not. For OBYC, both T030 and T030R are included in an SAP TR. But, T030R is not required unless you make changes in rules for that transaction. To know the underlying tables, one way is to let SAP create a TR and then you can look at what tables are being included and take the call.

Go to SE16 transaction code and enter the table name.

Hit enter. Then input the relevant criteria to get the desired entries.

In the output screen, select the required entries by clicking on the first column(Use Ctrl + Click for multiple separate entries as shown in the screenshot or use select all button). Go to Table Entry -> Transport Entries

The next screen prompts you for a TR number. Create a TR from here or enter an already existing TR number.

The resulting TR from here has only the 4 entries we selected from the table to transport.

The same process can be done from SE16N as well.

Go to SE16N transaction code and enter the table name.

Hit enter. Then input the relevant criteria to get the desired entries.

In the output screen, select the required entries by clicking on checkbox in the first column (Use Ctrl + Click for multiple separate entries as shown in the screenshot or use select all button). Go to Table Entry -> Transport

The next screen prompts you for a TR number. Create a TR from here or enter an already existing TR number.

The resulting TR from here has only the entries we selected from the table to transport.

P.S: The intent of this blog was to make aware if someone is not aware of the process. I still recommend SAP created TR’s without manual intervention wherever possible

Hi all,

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

Two mainstream notes are available:

2074358 - US TAX REPORTS - PRINT FORMS LAYOUTS 1099-MISC, 1099-G, 1099-INT, 1099-K, 1042-S

and

2074359 - US TAX REPORTS - PRINT FORMS LAYOUTS 1099-MISC, 1099-G, 1099-INT, 1099-K, 1042-S

for customers who are in releases 46C, 470 and 500.

According to those notes which are announcements, it will be updated by the time final notes with corrections and updated forms and files would be released.

Those would be the main channel where new corrections and notes related to 1099 that are released will be maintained.

Please follow up on those notes for latest updates about 1099 Print Form layout updates for the Tax Year 2014 to be submitted in 2015.

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

Danton Prestes

Hello everyone,

In the last few weeks was released notes 2092366 and 2083799 which might be important for the parking using BAPI scenario.

Document parking with accounting BAPIs could only be achieved using a custom enhancement (BTE or BAdI implementation).

With note 2092366 SAP now officially support the functionality of parking documents using the accounting BAPI, but only under the restrictions listed in the notes 2092366 and 2021422 With this scenario no manipulation of TCODE allowed and only for object type BKPFF.

The official solution in note 2092366 will only be delivered in support packages! A manual implementation using SNOTE is not intended to guarantee that all previous notes regarding this functionality are available in the customer system.

The more important note for you might be 2083799. This SAP Note describes various posting processes and specifies which data must be transferred to the
BAPI to post the relevant process. The idea is document all possible posting scenarios supported by the BAPIs in this note. The developers still working in this note so if a customer wants to post another scenario which is not yet documented in the note, it does not mean the BAPI does not support this.

Related notes:

2092366 Parking with BAPI_ACC_DOCUMENT_POST

2083799 Composite SAP Note: Postings with Accounting BAPIs

2021422 Vorerfassung über RWIN mit unerlaubtem TCODE oder AWTYP (not translated yet)

I hope it helps! Any sugestions please let we know!

Regards,

Raquel

Hi guys,

Just a tip about this posting where I was having some doubts why the post was not going through the BADI.

If the post is a Down payment request or a Noted item, you must complement the BAPI_ACC_DOCUMENT_POST using:

WHEN 'DP'.

ls_bapiache09-obj_type = 'BKPFF'.

ls_extension2-structure = space.

ls_extension2-valuepart1 = 'BUS_ACT'.

ls_extension2-valuepart2 = 'RFST'.

Implement the BADI_ACC_DOCUMENT:

The BADI_ACC_DOCUMENT has to have the following filter:

And the Method CHANGE should be like:

METHOD if_ex_acc_document~change.

FIELD-SYMBOLS <accit> TYPE accit.

DATA ls_extension2 TYPE bapiparex.

IF c_extension2 IS NOT INITIAL.

READ TABLE c_extension2 INDEX 1 INTO ls_extension2.

IF ls_extension2-valuepart1 = 'BUS_ACT' AND ls_extension2-valuepart2 = 'RFST'.

c_acchd-glvor = 'RFST'.

LOOP AT c_accit ASSIGNING <accit>.

<accit>-bstat = 'S'.

ENDLOOP.

ENDIF.

ENDMETHOD.

Hello Everyone,

The idea of this blog is summarize the most commun actions to improve the performance in FBRA as well as the SAP notes related with each topic suggested.

-> The first point to check is the selection parameters.The most basic actions to improve the performance in FBRA.

1) Specify the reporting data selection range in customizing : you can do this by transaction SM30 go to view V_T059ID01 click maint/change select the processing type and double click to go inside reported data selection.
Tick open item (if only open item otherwise cleared iteams are also considered, ) and also tick 'no exemption data'/'no tax data' if applicable.

2) You can also improve the performance by entering the "specific" selection parameters for example:
-Main criteria.. company, year, country, Posting date...or by restricting the selection using:
- a vendor and customer range accounts pt splitting the run of the report in many runs.

-> If change selection parameters does not solve the issue you can use FBRA_LOC transaction as described in SAP note 487347:

487347 - FBRA: Overflow of the lock table

This note suggests to use transaction FBRA_LOAC as a workaround for problematic cases.

For avioding the lock table overflow, there are these possibilities:

1. Extend the profile-parameter "enqueue/table_size", as per note 13907

2. Reduce BKORM entries as much as possible, i.d. for all company codes
The less entries in table BKORM exist the more faster is FBRA or
FBRA_LOAC. Please refer to steps 2. and 3. of note 487347.

Additonally, please review the following recommendations

1. Use Note 1320810 Z_ENQUEUE_PERF during both high and low load.

2. Test changing the following parameters enque/server/threadcount and enque/server/use_spinning to true.

3. Run niping during both high and low load.

4. Use test in okcode in sm12 and set logging on for 15 seconds and run mass calls, starting with a thousand during load and check stad record for enq performance.

5. During problem time check for rejects in sm12. If refresh shows increases of hundreds, points more to an application issue.

6. Consider moving the standalone enqueue server to a dedicated system.

7. Continue application analysis.

-> If you are receiving runtime error TSV_TNEW_PAGE_ALLOC_FAILED in transaction FBRA can be that table BKORM has too many entries.

This table could contains millions of old and very old correspondence requests, which never have been printed and therefore never been deleted from this table.

If you don't print your correspondence requests, you have to reorganize table BKORM from time to time by means of report SAPF140D. This
report can be reached for each user via transaction F.63. The BKORM should contain normally only current correspondence requirements which were not printed yet and possibly already printed, which are not older than 14 days, for a possible reprint. There is no need to keep printed correspondence in BKORM for a long time.
Many of these correspondence requests were created a long time ago and you do not intend to print and to send these correspondences. Such correspondences requests can be safely deleted. Please take the following precautions:
1. You should run SAPF140D according to note 17831 on a regular basis (every two days or at least weekly) to delete all accounting
correspondence requests out of BKORM that are finished since (e.g. one week).
2. The same report should be used to delete all accounting correspondence requests that have no expiry date at all('entries
withoutprint date under 'Further selections'). There is also a possibility to run the report in test mode.
3. In the future, you should use SAPF140 as follows: On the selection screen, under 'Program Control' there is a field called 'Delete if
finished since'. This field has to be filled with a certain number of days (e.g. 7). You could create a variant and then always use this
variant for SAPF140 for which this field is set.
If entries in BKORM are deleted to correct size, FBRA should work fine.

I hope that I could help!

Kind Regards,

Raquel

I attended this SAP webcast this morning and was surprised at the low attendance. There are many improvements in FI-CO and no, I am not talking "Simple Finance" but the core FI-CO modules.

See below:

Customer Connection for Financials started last December

The usual Legal Disclaimer applies

Figure 1: Source: SAP

This customer connect started last December and closed workspace in February

SAP checked ideas which had the most subscriptions

They evaluated during the select phase

In April they held selection call

Subscribe means you will use improvements productively

Figure 2: Source: SAP

Figure 2 shows 17 improvement requests are delivered in CO

2 are in progress

2 are in handover

11 has FI delivered with 1 improvement request rejected

Figure 3: Source: SAP

Figure 3 shows one of the most popular requests, display controlling area

Figure 4: Source: SAP

Some of the more interesting notes (to me) listed in Figure 4 are below:

Expand number of hits on CO line item reports over 5K http://service.sap.com/sap/support/notes/2036486 -
KBA for default display variants: http://service.sap.com/sap/support/notes/2036758
Drill down to original document http://service.sap.com/sap/support/notes/2017607
Controlling period OKP1 automation http://service.sap.com/sap/support/notes/2016546

Figure 5: Source: SAP

Figure 5 shows an improvement for KOK5

Figure 6: Source: SAP

More CO improvements are listed in Figure 6

Figure 7: Source: SAP

I’m surprised at Figure 7, exporting to Excel from background jobs, but I understand it at the same time too, having done this many times myself.

http://service.sap.com/sap/support/notes/1991518

This note was just released

Figure 8: Source: SAP

I think the most interesting improvement includes all the notes listed with OB52 posting period automation – I only list a few below:

OB52 http://service.sap.com/sap/support/notes/1993365

Parallel opening of periods http://service.sap.com/sap/support/notes/1993365

Figure 9: Source: SAP

Figure 9 shows “display full user name” but looking at the note it says “Branch to user data” http://service.sap.com/sap/support/notes/2073896

Visit www.sapimprovementfinder.com to find delivered improvements

Hi Colleagues,

Running NGLM tcode, is displayed many settings for GL to analyze, like screen shots below. You find detailed information on the organizational units ledger, company code, controlling area, and operating concern. Also, about the Document Splitting: In this area, you find options for the detailed analysis of the document splitting settings.

In the Data Analysis area, the monitor offers functions for the quantitative analysis of the transaction data updated in the line item tables, totals record tables, and document splitting tables of General Ledger Accounting. First start the Run Data Analysis function as a background job. The analysis data is stored automatically in a data file. You can then use various criteria to analyze.

This helps, e.g when you wants to check what characteristics of Document Splitting, what chart of accounts is assigned, fiscal variant, scenarios from Document Splitting, what total table is active per ledger, CO details and many other functions.

Follow, there're some steps:

SPRO

Execute

The tcode allows to you run other transactions related, like Maintain Company Code (OBY6) and many other.

To view Document Splitting characteristics

Execute

And again you can run transactions to maintain Document Splitting

Also, is possible to check CO details

JPA

Hi Colleagues,

Through the transaction or program, you can discover the number of customers, vendors, GL accounts, assets or normal FI documents in a client, company, by period, chart of accounts, etc. Basically the program research the data master tables with company codes, chart of accounts and so on.

RFAUDI01 - Number of Customer Master Records - S_ALR_87101051

The screenshot above indicates the number of customers according the KNA1 table and KNB1 table per company code.

RFAUDI02 - Number of Vendor Master Records - S_ALR_87101052

The program above check all the vendos by LFA1 and/or can separate by company code.

RFAUDI03 - Number of G/L Master Records - S_ALR_87101049

The screenshot above indicates how many items there are in SKA1 table per chart of accounts. And below, indicates how many items there are in the SKB1 table per company in each chart of accounts. This is very useful when the client has many company codes assigned to a chart of accounts. There aren't a option to select parameters.

RFAUDI04 - Number of Asset Master Records - S_ALR_87101050

Technically, the program check ANLH table. You do not have access to selection parameters like a research by company code.

RFAUDI07 - Number of Standard FI Documents - S_ALR_87101054 is shown below:

In this case, the program will check the BKPF table by company, ledger, type of document, period and year, but you can insert posting date to research in a specific period. Remeber that normal documents are all documents that aren't special GL items, parked items or noted items.

Also, you can run these transactions in backgorund mode and get the list in the SM37.

JPA

Hello everyone,

The purpose of this blog is help to identify the root cause of error FS 861 in External Tax System (SABRIX, VERTEX and TAXWARE).

Error FS 861 can be a generic error resulted from RFC_CALCULATE_TAXES_DOC when external tax calculation is used. The cause can be wrong jurisdiction code, jurisdiction code structure, country not supported and so on.

The steps bellow should be followed to identify the root cause of error FS 861.

1. Check if company code is US,CA,PR:

According with SAP Note 1738657, SAP supports external tax systems only for the country codes US, CA and PR (Puerto Rico). This means the country of the company code must be one of these countries so that taxes are calculated using the external tax system and are also updated there.

2. Check jurisdiction code structure defined in transaction OBCO:

The default jurisdiction structure is:

Sabrix = 2,2,5,5

Taxware = 2,5,2

Vertex = 2,3,4,1

3.For non-taxable scenarios check the default jurisdiction code defined in transaction OBCL:

Enter I0 (for input tax), O0 (for output tax) and a dummy jurisdiction code for the relevant company code(s) using TAXUSX. The system uses this dummy jurisdiction code also for export business transactions. (If you create a billing document in a country with tax jurisdiction code, when the goods recipient is in a different country with or without tax jurisdiction code.) Please have a look at note 419124 where the suggested export jurisdiction codes used by the different External Tax Interface Partners are listed.

4. For exporting scenario you have assigned for jurisdiction code in customer master data.:

As informed in SAP Note 419124the Vertex jurisdiction code for export transactions is '770000000'. For Taxware, the jurisdiction code is IT0000000.

Please check if all new released notes are implemented:

2016990 - Export between United States and Canada

1628962 - Export with invalid tax jurisdiction

1768395 - Export with invalid tax jurisdiction (1)

1809374 - Export with invalid tax jurisdiction (2)

1899214 - Export with invalid tax jurisdiction (3)

2016058 - Export with invalid tax jurisdiction (4)

5. Check the Condition used in SD:

Trigger conditions UTXD and UTXE are used in external tax calculation. Both conditions must be used together in the pricing
procedure (for technical reasons). Condition UTXD has value formula 500 and condition UTXE has value formula 501. They are triggered only by FM
PRICING_COMPLETE. The RFC is called only once per document. This is called the MaxTax procedure (developed by FI), and it is supposed to be faster. For more details related SD customizing please check SAP WIKI Tax jurisdiction - ERP SD - SCN Wiki

6. If the above customizing is correct check the parameters passed to external tax system and received in debug mode:

Transaction se24
cl_xtax_rules_rfc
double click on method RFC_CALCULATE_TAXES_DOC
and scroll down till you see where the RFC_CALCULATE_TAXES_DOC function call is made
set a break point at the break point call function 'RFC_CALCULATE_TAXES_DOC (to check the input parameters) and one after the call function (to check the output parameters)
and do the transaction again
inspect the input structures: tax_cal_item_inxx: outgoing document values to tax system -->>> If you see some wrong information this is caused by wrong customizing. In this case please review in detail the configuration guide attached on SAP Note 392696 - R/3 Tax Interface Configuration Guide.

8. and do F6

9. now inspect the error structure and output structure:

tax_cal_item_outxx: incoming values from tax system

tax_cal_jur_level_outxx: jurisdiction level --->>> if you see an error, this has to be analyzed by company responsible for the External tax system

I hope this helps!

Regards,

Raquel

toonpool.com

How do you decide upon the best approach to clear your check register in SAP for your company? Let me help to demystify this question and others over the next three weeks of postings. Stay tuned to find out that keeping the check register up to date doesn’t need to be a difficult exercise.I will provide three different options on how you can do this within your company. But how do you decide which option makes the most sense for you? Every company will have a different perspective, but here are some considerations for your project approach to managing the check register:

1. Volume and Timing: How many checks are being issued being issued from this account each month?Is receiving an encashment file once per month sufficient?At what point would potential error corrections be too large?Does the volume become too large by having a file only once a month to manage errors?Perhaps it is easier to receive activity each day for reconciliation purposes.

2. Cost: Do you have to pay additional to have the individual checks included on your bank statement file?What is the additional charge?Could you use the bank statement and eliminate the need to have a separate interface for only cashed checks?

3. Monitoring: Who will perform the ongoing monitoring to ensure checks are being updated in the register?Will this be done as part of your bank reconciliation process, by your team supporting payments, or someone else?Who will make sure that either solution continues to work properly?Will this person participate in regression testing for the solution once it is live?

4. Knowledge and Know-how: Does your technical team understand how to set up the different solutions?Do they understand the potential failure points?What will be your processes for ongoing monitoring?

5. Staffing availability: Does your internal project team have the capacity to set up these interfaces?Often project teams have competing priorities with everything demanding top position in the project scope.If there is a constraint on internal staffing from either the business function or IT, perhaps it is best to update checks manually while other priorities are completed.

6. Cost of compliance: In cases where the processes are completely manual, what is it costing you to comply with the various state escheatment laws?Would an automated interface make your compliance efforts easier and less expensive?

Now that the stage is set, over the next few weeks I will post how you can actually do this in SAP.

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

Dasaradh

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.

Concept

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.

Steps

Configure a Data Medium Exchange format tree
Configure a Payment Medium Format that calls the DME format tree
Configure a variant in the standard program
Associate the new payment method with some vendors
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.

References

SAP Help
SAP - DME Blog
Mark Chelfen's gracious assistance on Twitter and in this thread.

Hi all,

Before Implementing the 1042s note regarding US Legal Change 2014, please implement the note2095167 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.

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.

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.

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:

Financial (FI). For external entities. Main reports are balance sheet and P&L statements.
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.

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.

What are Recurring
entries?

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

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.

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.

I noticed already some questions regarding Field Status maintenance. Hence, I come to share some findings from different incidents I have worked on.

First it is important to mention that system validates field status settings maintained in posting key and also in G/L account. Hence, field status must be efined by G/L account (OB14) and by posting key (OB41).

Let's take as an example field "Payment currency" (BSEG-PYCUR):

You set field status "Payment currency" as Opt. entry in relevant posting keys (transaction OB41), but when you use this posting key field "Payment currency" is still not displayed in the transaction screen.

In this case please check the settings maintained for the G/L account used as it is also necessary to set same field status in the needed G/L accounts.

So setting field status "Payment currency" in posting keys and related G/L accounts as Optional Entries will make the field Payment Currency available in all screens that use this field, meaning users will see the field and be able to insert data for the payment currency in any Company Code that uses the changed posting keys and G/L accounts.

As system crosses the information between Posting Keys and G/L accounts; if the field status is set as "Suppressed" in one of them system will assume this setting and not show the field.

Hence, you may set the field as optional entry only for the needed G/L accounts and as suppressed for any other G/L account, this will restrict a bit the field
display.

Posting key is unique for all the company codes. For example: if you set a field to be optional in OB41, all company codes will have this configuration.

However, if you set a field to be optional in OB14, you will need to inform a field status variant (which is defined by company code) and a field status group (which is defined by G/L account).

So if you have a different field status variant for one company and you change the filed status related for this unique status variant, this change will not affect the other companies.

There are three possible field statuses to be maintained:

Suppress: Fields are hidden

Required Entry: Fields must be entered (mandatory, error message requesting to fill the field is raised)

Optional Entry: Fields may be entered (not mandatory, warning message requesting to fill the field is raised)

In this case the same field status is supposed to be maintained in OB14 and OB41 as field status is always a combination between posting key and G/L account.

Many a times we gets stuck while troubleshooting any particular sap issues irrespective of any module and after checking all possible angle we come to conclusion that respective SAP Notes might help and we start to find the SAP Notes. So I thought of writing this blog on overview of SAP Notes.

SAP Versioning

Before understanding the SAP Notes, it important to understand SAP versioning strategy and how upgrades are made.

Each SAP product, including SAP ECC which is the scope of this blog post, has a version (usually represented by a number).
The bigger this number is, the more up-to-date the software is.
Many years ago companies were using SAP ERP known as R/3 (Versions 4.0B, 4.5B, 4.6C, 4.70).

At that time, SAP developers where making its software better by doing two different activities:

Creating new functionality (for example, creating a new transaction responsible for filling a business gap).
Fixing bugs

Systems Upgrade

As the software is changed, we have to test it again to ensure our business keep operating without any major issue. A lot of effort is required from different people (BASIS, ABAP, Functionals and users as well).
An upgrade projects usually takes some months and in some companies it might take more than 1 year. And SAP knows that since its early years.
With the advent of SAP ECC 5.0 (no more "R/3" in the product name from now on) SAP deliveries new functionality with something called Enhancement Packages and deliveries bug fixes in 2 ways:
1. A mass bug fixes - using Support Packages
2. A single bug fixes - using SAP Note

Enhancement Packages

An Enhancement Package (EHP) is a set of new functionalities SAP delivers since SAP ECC 5.

An EHP is represented with a number as well and this number is usually part of the product version. For example:
- SAP ECC 6.01 means SAP ECC version 6 EHP1
- SAP ECC 6.02 means SAP ECC version 6 EHP2……
- SAP ECC 6.07 means SAP ECC version 6 EHP7
- When SAP releases a new EHP it explains to the community the new functionalities using some examples.
- Though the documentation of each business function is not ideal but its very important to understand that before any decision to apply them.

Support Packages

An EHP provides a set of new functionalities (Business Functions).
A Support Package isa set of bug fixes (SAP Notes).
Each Support Package is represented by a number and usually it is mentioned after SAP version + EHP, for example:
- SAP ECC 6.04 SP8 means SAP ECC version 6 EHP 4 SP8
- SAP ECC 6.04 SP11 means SAP ECC version 6 EHP 4 SP 11
- SAP ECC 6.05 SP8 means SAP ECC version 6 EHP 5 SP 8

What is OSS

OSS stands for Online Service System.
SAP notes are part of SAP service portal.
In simple terms, it is SAP’s Knowledge Base that specifically addresses known issues in SAP system.
OSS Notes is an online SAP service and the portal that provides updates on patches in different modules of SAP and up-to-date information on SAP notes.
SAP notes are correction instructions for the bugs or issues found in standard SAP programs.

How OSS Helps

OSS notes are online documents published by SAP and aimed to take care of the following:

Product Errors
Product Modifications
Product Upgrades
FAQs
Consulting Notes
Customizing Notes

SAP OSS also helps for:

Program corrections
Methods for Table/Field additions
Deletions /Corrections
Customization Changes etc.

When to Look for OSS Notes

OSS Notes provide either information or corrections to the customer:

Some notes contain critical information about the component and have to be used in addition to the component guides that are delivered to the customer.
Some other notes provide corrections to the code as a fix before a support package is released.
The subsequent SPs contain the corrections that were delivered through notes before.
Hence it is important to check the current SP level of your system and the SP level with which the corrections come before applying the notes.
Some notes provide just manual corrections (in which case the procedure to make the manual corrections also need to be specified in the notes) and other provide automatic corrections (which are applied through SNOTE).

How to Understand a SAP Note

An SAP note is available on SAP support portal but more often downloaded by consultants as PDF file either from SAP Portal or from SAP Transaction SNOTE.
The Note has the issue details followed by the fix to it.
Further it has certain header level info provided which, though appears trivial, is the first info that a consultant should look for before getting deep into it.

Important points about a SAP Notes are as follows:

Overview
– SAP Note No/Description/Version/Validity/Language
Header Data- Released On/Released Status/Component/Other Component/Priority/Category/Impln Status/Processing Status
Symptom
Other Terms
Reasons & Prerequisites
Solution
Validity
Correction Instructions

How to Find Out SAP Version

We can find out the SAP Version in the system by navigating in the following way:

1. Log in to SAP

2. Cick on System with the session that is opened

3. Select and click on Status

4. Now you can check the Component Version in the SAP Systems Data on your right side within the system status screen that pops up.

5. Click on the magnifying glass icon and you will be able to see component wise support package, Release & SP-Level details.

Best Practices While Applying a SAP Note

Applying is SAP note is an easy task but there are certain best practices that can keep us safe and revert system in case the note doesn’t work or issues occur:

Ensure note applies to the current version of system
Prefer SNOTE application than manual application
Create a backup copy of the code before applying note
When applying manual note changes, clearly document the code changes so that it can be reverted if issues occur
Never attempt to add any code other than what is in note when applying note manually.
Never attempt to alter code / write code in own naming convention etc. than what is mentioned in note.
When applying note automatically, ensure that the TRs (Transport Requests) are ready or the ID through which note is being applied has sufficient rights to create TRs.