Hello Folks (Incl. SAP ERP Financials - Controlling, SAP ERP Financials  - Asset Accounting)

Good day to all of you!!

I always wondered on what topic one can write a blog in the SAP Financials forum, though I have written some of them in the Career Center. So, a big thanks to SAP for giving me a reason to write a blog in this favorite space of mine. And a even bigger thanks for taking this wonderful initiative to simplify the way ERP Financials are looked at.

We have been hearing a lot of buzz since later part of 2014 about Smart Finance, Simple Finance, Simple Finance Add-on, etc. I was as curious as you all to know about it and was putting efforts towards that. But to come up with a knowledge-sharing document without understanding the subject myself is something very difficult for me. Today, I feel, I am somewhat equipped to do this. Hence, would like to take this initiative.

First lets understand what  these new terms are. I personally feel this whole initiative as a backward integration of SAP ERP Financials with the HANA capability, with the ultimate objective of reducing the database footprint, faster close, faster and better reporting, improved cash management, ever-reconciled data and Integrated planning. As of now, I see more of the structural /  architectural changes than the changes in the functionalityper se. I would intentionally stop short of quantifying the  both in terms of a %, because that's not the objective of this blog

This initiative was earlier termed as SMART FINANCE. However, later renamed as SIMPLE FINANCE. I attended one of the SAP's Boot Camps on Simple Finance and the convincing reason that was offered was that naming the new version as Smart Finance would mean that the earlier one was dumb. So, that's how Simple Finance was born.

Now lets understand the terms Simple Finance and Simple Finance Add-on.

     SAP Simple Finance: is a managed service in the SAP HANA Enterprise Cloud. To make it a simple, it is a cloud based solution, that includes a new financials core as part of SAP Business Suite powered by SAP HANA.

     SAP Simple Finance Add-on: For those customers who don't want to be on Cloud, but prefer an On-Premise solution, SAP offers the Simple Finance Add-on, so that they too can benefit from the related innovations to facilitate a financials transformation.

SAP suggests the Cloud based solution as the preferred deployment option. But nevertheless, one can have SAP HANA On-Premise as well.

Lets now move on to the next aspect of the blog.

There would be the typical Qs in every mind. Is the new solution stable? Is it going to be the future-next? What is the road-map for future? Do we get all of the existing functionality in the new offering?

      To answer some of them, fully or partially, SAP has taken a bold decision to be the first live customer of this initiative. YES!! You heard it right!! SAP itself has migrated to the new offering before offering it to SAP Partners and Customers

     One need not doubt SAP's capability to offer stable & integrated solutions. Like any other software, this might have its own teething issues, but surely seems to be a promising one. Some of the existing functionality might not be present in the new offering whereas there might be some awesome improvements as well.

     As of now, I see good amount of changes in the Asset Accounting (one of my favorite topics in SAP). For those functionalities which are not present as of now in the new offering, I am very hopeful that they will be added sooner or later

Lets now understand the scope of Simple Finance and Simple Finance Add-on

The scope of Simple Finance (the cloud based solution) looks like this:

And the scope of Simple Finance Add-on (version 1.0) looks like this.

Version 1.0 of the Simple Finance Add-on was launched in 2014 and the version 2.0 is launched in 2015 very recently. This should again put to rest some of the concerns about the future road-map of this new offering.

This blog and the next in series will primarily focus on the Simple Finance Add-on 1.0 to demystify what it offers, what's new, what's missing and how does it benefit a SAP customer.

Some of the highlights of the add-on 1.0 are listed below

a. Revamped Asset Accounting: Simplifies the concept of depreciation areas, parallel valuation in asset accounting and facilitates parallel reporting by means of ledger approach as well as accounts approach

b. New GL mandatory: Classic GL no longer supported in Simple Finance. One has to be on New GL. (Need not be full fledged New GL. Lite version of New GL would suffice)

c. Concept of Data Archiving replaced with Data Aging (Hot / Cold Partitions of the Database)

d. A brand new Cash Management Solution, powered by SAP HANA

e. New Asset Accounting is mandatory. Classic AA no longer possible in the  new offering

f. On-the fly summarization reports (from line items)

g. Good amount of overhaul in the Key SAP tables.

h. Option to split COGS in the FI-GL as per the Cost Component Split, etc

Simple Finance Add-on 2.0 will unleash some new changes. Material Ledger is covered in the add-on 2.0 and it is expected to change the way GL / Cost Element master is looked at.

Hope you find this blog useful and it awakens the interest in you to know more about the new SAP offering.

Do share your feedback about the blog at the end of your reading. Do leave your comments / Qs which might help in structuring the documents next in-series.

Yours enthusiastically,

Ajay Maheshwari

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:

1. Transaction se24
2. cl_xtax_rules_rfc
3. double click on method RFC_CALCULATE_TAXES_DOC
4. and scroll down till you see where the RFC_CALCULATE_TAXES_DOC function call is made
5. 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)
6. and do the transaction again
7. 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

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:

Secondary Cost Example:

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

Hello,

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: BUFFERS (Blog)

NUMBER RANGE : Buffering

NUMBER RANGE : Gaps in Number Range

NUMBER RANGE : General Information

NUMBER RANGE: DEBUG and CREATION

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!

Regards,

Raquel

Hello,

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!

Regards,

Raquel

Hello,

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:

FUNCTION FI_DOCUMENT_CHECK
FORM  CHECK_ACCIT
FORM  SUBST_CLEARING (here the company code clearing line items are generated)
FORM  DISTR_DIFFERENCES_BUV

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

FUNCTION  FI_DOCUMENT_CLOSE
FORM   CLOSE_ACCCR
FORM  DISTR_DIFFERENCES
or (depending on the AWTYP)
FORM  DISTR_DIFFERENCES_LOGVO

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!

Regards,
Raquel

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!

Regards,
Raquel

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.

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.

Reason

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.

Improvement

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.

Benefit

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.

Delivery

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.

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.

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).

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.

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:

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
2. Direct Activity Allocation
3. Manual Reposting of Primary Costs
4. Assessment
5. Distribution
6. Work Order Settlement to GL Account
7. Work Order Settlement to Cost Center
8. Work Order Settlement to WBS
9. Work Order Settlement to Asset

• Testing Scenario: Manual Cost Allocation

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

• Testing Scenario: Direct Activity Allocation

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

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)

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

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

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

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

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

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.

So what do we conclude?

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..

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.

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.

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.

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.

Frequently many companies in Brazil are implementing SAP or doing roll outs on their current ERP migrating to SAP or even adding new companies to their existing SAP and etc.

There are so many details to take care that are more related to the business, if the existing process will work properly on SAP or how to handle something that company that is being rolling out is doing that the existing company on SAP does completely different.

There are also all the legal requirements already in progress such as NFe, SPED, Incoming NFe, Social SPED, FCI, Federal, State and Municipal obligations, CTe and etc.

Even with all the planning, some customers don’t think about the core of all the Brazilian Tax Calculation, the Tax Schema (TAXBRJ x TAXBRA).

Some companies doesn’t see the importance on updating their Tax Schema Calculation and they think that they will save money and time if they just don’t update to the TAXBRA and keep using TAXBRJ. This is a terrible mistake and I will tell you why: In 2005 SAP started introducing the usage of the TAXBRA recommending that new customers on new implementations use the TAXBRA instead implementing TAXBRJ and also, recommended customers start considering upgrade their tax schema.

There are several reasons why SAP recommend your company use TAXBRA: It is more robust, easy to handle and meet taxes requirements, designed to meet the MP135, ISS and WHT cumulative, but more important than that, SAP giver priority releasing standard solution to the law changes and new legal requirements released by the government frequently. Besides that, SAP will discontinue the support to the TAXBRJ sooner or later.

Soon companies will realize that saving costs and time wasn’t worth, since they will have to spend lot time adapting TAXBRJ to the new legal requirements that are not standard released by SAP. And it will be worse when the support is discontinued. Companies will have to handle taxes issues without counting on SAP support.

One other terrible mistake that companies do is not choosing the right resources for upgrading or implement TAXBRA, this happens more often with foreign countries, where they have a centralized support team that still thinks that the Tax Calculation Schema in Brazil is maintained by FICO team. This is easy to understand since Brazil is the only country in Americas where the taxes are maintained by SD and MM.

Upgrading or even implementing TAXBRA could take from 1 to 4 months usually; it depends on the size of the company, resources focused to the project, existing processes, number of different tax codes, number of pricings, taxes exceptions and etc.

Even though implementing TAXBRA is 80% on SD/MM, a perfect team for this job should consider: MM, SD, FI, CO, ABAP, BASIS and a Project Manager.

Tasks related to the TAXBRA are:

CBT activation, Configure Tax Codes, Tax Groups, Dynamic Exceptions, Tax Rates, Condition Types, Account Keys, Condition Records, Access Sequences, Condition Codes, Tax Jurisdiction, Screen Controls, Conditions Mappings, Tax Posting Strings, internal codes, Price conditions, TAXBRA/RVABRA pricing adjustments, MP135, ISS, WHT, all this maintained by MM and SD consultant, and it is always good to check CFOP, Jurisdiction Codes, Tax Laws, Tax Situations, and etc.

A FICO consultant must setup the Withholding taxes on payment (since the WHT on Invoice is maintained by MM) and must configure the taxes account determination (OB40) and the conditions relevant for CO-PA, CO-PC and etc.

The secret of success is always experienced consultants working with experienced key users from fiscal department. Tests and users acceptance tests must be done carefully and include all the different processes and situation current in use.

FI/CO/ABAP/BASIS and PM can be part time for a project like this while MM and SD must be full time assigned to this job.

Security must be checked since there are new conditions and accesses on J1BTAX that must be considered.

For general information about the SAP strategy on TAXBRA condition-based tax calculation for Brazil and SAP recommendations, refer to the note 1538088

TAXBRA additional information:

• FTXP is no longer used. Maintain existing tax codes or creating new tax codes must be done via J1BTAX only

• Conditions are activated via FV11/FV12 with amount 100%

• Maintaining J1BTAX tax tables or tax codes conditions the system generates automatically condition records for these data

• The generation of condition records occurs during maintenance of tables J_1BTX*

• Main notes: 664855, 727475, 747607, 916003, 947670

• Using the method of Tax Calculating via condition based technique (CBT), every time a new tax group is created, it must be added in a certain access sequence, automatically by the system through the transaction J1BTAX. The same should occur whenever changes are performed in the tax groups, or even it is deleted

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.

CFOP – Código Fiscal de Operação e Prestação (Fiscal Code of Operations and Services)

Before I show you some hints on the CFOP configuration on SAP, let me introduce first a little bit about the CFOP concept.

The Brazilian Tax System is formed by several codes that are used to organize and facilitate the companies' statements. CFOP is one of them.

The CFOP is a code defined by the Brazilian authorities that describes the type of business transaction.

A CFOP code contains information on the good’s origin as well as the type of operation, such as sales, returns, stock transfers, or services.

The CFOP code must be printed on most notas fiscais and is included in most forms of legal reporting. The CFOP code will define if taxes are involved or noto n the operation and what are the tax rules applied.

You will find below a list of the main CFOP codes categories. Other than these codes there are several other codes with different suffixes that describe subgroups between the categories described below:

1.000 – Entry of goods or acquisition of services within the state:

Are classified in this group, operations or services in which the establishment sender is located in the same unit of the Federation of the recipient.

1.100 - Purchase for industrialization, commercialization or provision of services

1.150 - Transference for industrialization, commercialization or provision of services

1.200 - Sales returns of own production, third party or cancellations of values

1.250 - Purchase of electric energy

1.300 – Acquisition of communication services

1.350 – Acquisition of transportation services

1.400 - Entries of goods subject to tax replacement regime (regime de substituição tributária)

1.450 – Integration systems

1.550 – Operations involving fixed assets and materials for usage or consumption

1.600 – Credit or refunds of ICMS

1.650 - Entries for fuel, oil or no-oil products, and lubricants

1.900 - Other entries for purchases of goods or services

2.000 - Entry of goods or acquisition of services outside the state:

Are classified in this group, operations or services in which the establishment sender is located in a different state than the recipient.

2.100 - Purchase for industrialization, commercialization or provision of services

2.150 - Transference for industrialization, commercialization or provision of services

2.200 - Sales returns of own production, third party or cancellations of values

2.250 - Purchase of electric energy

2.300 – Acquisition of communication services

2.350 – Acquisition of transportation services

2.400 - Entries of goods subject to tax replacement regime (regime de substituição tributária)

2.500 – Entry of goods destined to exportation or devolution

2.550 – Operations involving fixed assets and materials for usage or consumption

2.600 – Credit or refunds of ICMS

2.650 - Entries for fuel, oil or no-oil products, and lubricants

2.900 - Other entries for purchases of goods or services

3.000 - Entry of goods or acquisitions of services from abroad:

Are classified in this group, the entries of goods coming from another country, including those resulting from the acquisition by auction, competition or any other form of alienation promoted by the government. Are also included services that were started abroad.

3.100 - Purchase for industrialization, commercialization or provision of services

3.150 - Transference for industrialization, commercialization or provision of services

3.200 - Sales returns of own production, third party or cancellations of values

3.250 - Purchase of electric energy

3.300 – Acquisition of communication services

3.350 – Acquisition of transportation services

3.400 - Entries of goods subject to tax replacement regime (regime de substituição tributária)

3.500 – Entry of goods destined to exportation or devolution

3.550 – Operations involving fixed assets and materials for usage or consumption

3.600 – Credit or refunds of ICMS

3.650 - Entries of fuel, (oil or no-oil derivatives), and lubricants

3.900 - Other entries for purchases of goods or services

Da saída de mercadorias, bens ou prestação de serviços – states about the output of goods, assets and services redered

5.000 - Output of goods and provision of services within the state:

Are classified in this group, operations or services in which the establishment sender is located in the same unit of the Federation of the recipient.

5.100 – Sales of own production or by third party

5.150 – Transference of own production or by third party

5.200 - Sales returns of own production, third party or cancellations of values

5.250 - Sales of electric energy

5.300 – Provision of communication services

5.350 – Provision of transportation services

5.400 - Exit of goods subject to tax replacement regime (regime de substituição tributária)

5.450 – Integration systems

5.500 – Consignment of goods destined to exportation or devolution

5.550 - Operations involving fixed assets and materials for usage or consumption

5.600 – Credit or fund of ICMS

5.650 – Exits of fuel, (oil or no-oil derivatives), and lubricants

5.900 - Other exits for purchases of goods or services

6000 - Output of goods or acquisition of services outside the state:

Are classified in this group, operations or services in which the establishment sender is located in a different state than the recipient.

6.100 – Sales of own production or by third party

6.150 – Transference of own production or by third party

6.200 - Sales returns of own production, third party or cancellations of values

6.250 - Sales of electric energy

6.300 – Provision of communication services

6.350 – Provision of transportation services

6.400 - Exit of goods subject to tax replacement regime (regime de substituição tributária)

6.500 – Consignment of goods destined to exportation or devolution

6.550 - Operations involving fixed assets and materials for usage or consumption

6.600 – Credit or fund of ICMS

6.650 – Exits of fuel, (oil or no-oil derivatives), and lubricants

6.900 - Other exits for purchases of goods or services

7000 - Output of goods or acquisitions of services from abroad:

Are classified in this group, operations or services in which the customer is located in another country.

7.100 – Sales of own production or by third party

7.150 – Transference of own production or by third party

7.200 - Sales returns of own production, third party or cancellations of values

7.250 - Sales of electric energy

7.300 – Provision of communication services

7.350 – Provision of transportation services

7.400 - Exit of goods subject to tax replacement regime (regime de substituição tributária)

7.500 – Consignment of goods destined to exportation

7.550 - Operations involving fixed assets and materials for usage or consumption

7.600 – Credit or fund of ICMS

7.650 – Exits of fuel (oil or no-oil derivatives) and lubricants

7.900 - Other exits for purchases of goods or services

You will see on my next posting how to configure the CFOP on SAP and how to get it automatically determined on incoming and outgoing operations.

This blog post is a sequence of CFOP – Fiscal Code of Operations and Services

Now that you know what does CFOP means and what is used for, it is time to know how to configure the CFOP on SAP in 5 steps:

1 – Define CFOP Version

The first activity necessary is “DEFINE CFOP VERSIONS” and you can do that either maintaining the table/view J_1BCFOPVERV or via IMG path “Cross-Application Components > General Application Functions > Nota fiscal > CFOP Codes > Define CFOP Versions”.

Now a days it is not necessary to maintain the old CFOP length version anymore, then, enter the following data:

• Version: 1
• Description for CFOP Version: NEW CFOP 4 DIGITS
• Redeterm.: Considering your SAP installation is new, you don’t have the old CFOP format (replaced in 2003), then, it is not necessary to activate this check.
• CFOP Lngth: 4 CFOP Length
• Ext. Lngth: 0 No Extention
• Text ID: AA (or anything such as: A, 01, etc)

2 – Assign validity date to CFOP Versions

Once you have created the CFOP version, it is time to assign the validity date to the version created. Here you can also assign a version to a region (state) if required.

Follow the path “IMG > Cross-Application Components > General Application Functions > Nota fiscal > CFOP Codes > Assign Validity Date to CFOP Versions” or use the SM30 to maintain the table/view J_1BCFOP_XREGNV.

Type Valid-From, Country, Version.

3 – Define CFOP Codes and Assign Version

You can maintain the view J_1BAGNV or follow the customizing path: IMG > Cross-Application Components > General Application Functions > Nota fiscal > CFOP Codes > Define CFOP Codes and Assign Version

The CFOP codes and respective descriptions are part of a legal system to define the exactly operation for every goods movement going from or coming to the plant or company in Brazil.

You should ask for a full list of CFOP codes and description to the company Taxes and Fiscal department. You may want to ask me adding a comment here and I will forward it to you.

Check a sample below:

4 – Define CFOP Determination for Goods Receipts and returns

In this activity, you define the entries in the CFOP determination table for incoming movements (goods receipts) and their returns. The system uses these entries in the Materials Management components Logistics Invoice Verification and Inventory Management. The rules from this table will define automatically the correct CFOP for that specific operation during the goods incoming.

You can use the view J_1BAONV or the path IMG > Cross-Application Components > General Application Functions > Nota fiscal > CFOP Codes > Define CFOP Determination for Goods Receipts and Returns (Versioned)

See below an example:

5 – Define CFOP Determination for Goods Issue and returns

You define the entries in the CFOP determination table for outgoing movements (goods issues) and their returns. The system uses these entries in Sales and Distribution and Materials Management – Inventory Management. The rules from this table will define automatically the correct CFOP for that specific operation during the goods incoming.

You can do it maintain the view J_1BAPNV or via customizing menu: IMG > Cross-Application Components > General Application Functions > Nota fiscal > CFOP Codes > Define CFOP Determination for Goods Issues and Returns (Versioned)

See an example below:

You can find more details about CFOP checking SAP OSS Note 571848.

This post is a sequence of: Configuring CFOP on SAP

Now that you know what a CFOP stands for, it is time to understand how CFOP get automatically assigns to an Incoming or Outgoing Nota Fiscal.

CFOP Automatic Determination Parameters

The following parameters are relevant for CFOP determination:

1) Direction of the Movement

• 1 – Incoming (same state)
• 2 – Incoming (different state)
• 3 – Incoming (different Country)
• 5 – Outgoing (same state)
• 6 – Outgoing (different state)
• 7 – Outgoing (different country)

2) Material Usage (assigned at the Material Master Records)

• 0 – Resale
• 1 – Industrialization
• 2 – Consumption
• 3 – Fixed Asset

3) Material CFOP Category (assigned at the Material Master Records)

• 0 – Material (goods)
• 1 – Electricity
• 2 – Communication
• 3 – Transportation
• 4 – Animals

4) Nota Fiscal Item Type (assigned at J_1BSDICA, NF Integration Into IM, NF Type, LIV NF assignment)

• 01 – Standard Item
• 02 – Stock Transfer Item
• 21 – Returnable Packaging Shipment Item
• 31 – Subcontracting Invoicing Item
• 32 – Subcontracting Component Shipment Item
• 33 – Subcontracting Component Symbolic Shipment Item
• 41 – Future delivery invoice item without ICMS
• 42 – Future delivery invoice item with IPI
• 43 – Future delivery invoice item without ICMS/IPI
• 44 - Future delivery invoice item with ICMS/IPI
• 51 - Consignment invoice item
• 52 - Consignment shipment item
• 61 – Third party invoice item from vendor
• 62 – Third party invoice item from supplier
• 63 – Third party shipment item from supplier
• 64 – Third party future delivery invoice item from supplier
• 65 – Third party future delivery symbolic shipment item from supplier

5) Produced In House Indicator (assigned at the Material Master Records)

• x – Produced in-house / Manufactured at the plant
•    – non manufactured at the plant

6) Customer CFOP Category (only for SD)

• 0 Industry (cooperative)
• 1 electric co.
• 2 communication co.
• 3 transport co.
• 4 service co.
• 5 consumer industry (cooperative)
• 6 non-contributing customer
• 7 agricultural customer
• 8 trading company
• 9 producer establishment

7) NF Special Case for CFOP Determination

•    - CFOP Determination Without Substituicao Tributaria
• 1 - CFOP Determination with Substituicao Tributaria
• 2 - CFOP for Services That Are Subject to ISS Tax

NF Item Types

Even with all these possible standard delivered parameters for combinations, it is not enough to cover all possible scenarios in Brazil, then it is necessary add new entries to the existing parameters such as: Nota Fiscal Item Types, Material CFOP Category and etc.

Here I will explain you how to use the NF Item type to help you getting the CFOP code automatically determined at the Incoming and Outgoing Nota Fiscal

The Nota Fiscal Item type is assigned at:

1 – SD Item Category table (J_1BSDICA)

2 – MM-IV Nota Fiscal Relevance (J_1BIM02V)

3 – NF Type

4 - LIV NF assignment

Once your process finds the NF Item Type assignment in one of these 4 possible places, you will be able to add a CFOP combination containing all the parameters above, including the NF Item Type.

1 – SD Item Category table (J_1BSDICA) – This table is used to assign an item type and a main partner function (for example, ship-to party) to a combination of sales order type, item category including the NF Item Type. You can also assign SD tax codes and specify whether the system is to calculate statistically the ICMS and IPI taxes.

2 – MM-IV Nota Fiscal Relevance (J_1BIM02V)

Here it is possible to assign to each MM-IV movement type if it is relevant for Nota Fiscal, the Nota Fiscal type and also the Nota Fiscal Item Type.

3 – NF Type

4 – Logistics Invoice Verification

Here the values from the Nota Fiscal item types are maintained depending on the item category of the purchase order

Once the NF Item type is assigned to your process as above, if a combination exists for tables J_1BAPN or J_1BAON, the CFOP code will automatically be assigned to your process:

On the next posting you will see how to create new NF Item Types...

If you still have questions, please, contact me writing a comment on this post.

Copyright Notice: © Leandro da Pia Nascimento and SAPBR.COM (SAP BRAZIL) Wordpress Blog, 2013. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Leandro da Pia Nascimento and SAPBR.COM with appropriate and specific direction to the original content.

Since the companies in Brazil must not have 2 partners to the same CNPJ and/or State Inscription (IE), or CPF, you can prevent that 2 customer master records or 2 vendors created to the same Tax ID using SAP Standard (Configuration). Some time ago, this was only possible with coding / user exit.

First, let me explain about the TAX IDs in Brazil:

-Tax Number 1 (STCD1) – CNPJ -- Only for legal entities (companies)

-Tax Number 2 (STCD2) – CPF -- Only for Natural Person

-Tax Number 3 (STCD3) – State Inscription -- Only for legal entities (companies)
If exempt, must contain word “ISENTO”

-Tax Number 4 (STCD4) – Municipal Inscription -- It can contain RG (ID) if vendor is Natural Person
If exempt, must contain word “ISENTO”

-Sole Proprietr (STKZN) – Natural Person indicator -- Must be active when vendor is not a legal entity but a Natural Person

To activate the duplicity check, first go to transaction BUPA_TAXNUMTYPE and turn on the Tax ID's that you want the validation active:

Then go to transaction OBA5 (Change Message Control) to turn the error message on (you can choose between Warning or Error, but it is strongly recommended that you select as an Error when user goes to XK01 or XD01 for example, to create the customer or vendor). You can also select the message behavior based on an user.

You have to select area 8B and message No. 011, 012, 013, 014

If you enter a specific user, for instance, end users receive the standard error message but a user in the SAP Support group only receives a warning and is able to by pass the error.

You may also check transaction OBMSG to the same area 8B and messages and do the following:

Enter the adjustable message types in the "Allowed" column ("S" = success message, "I" = Information message, "W" = warning message, "E" = error message, "A" = termination message; an example entry could be SIWE).

Once those settings are in place, when someone try to create a record for a partner that already exist, it will look like this:

When you try to create the register, the system will show that a customer/vendor already exist to a given Tax ID:

And then it will issue a message, error or warning, depending on what was configured:

Not having customers and vendors in duplicity is mandatory for SPED Reporting. You can check this information on contributor guide for SPED Fiscal (EFD) and Contributions.

Hi All,

This is my first document in the forum. So please go through this and provide your valuable comments on this.

We create a new tax codes with revised rates and the old tax codes no longer useful for posting. But these tax codes will display in the input help while invoice posting through MIRO,FB60,F-43,FB70 etc. Due to this the users will get confused and also might chance to select the wrong tax code for posting. To over come these type of errors SAP has provided 2 SAP Notes i.e.2074351 & 2095960.

As per note 2074351, first we have to implement the note 2095960. After done this, we have to execute the report NOTE_2095960 as mentioned in the note 2074351. The screen shot of the report execution attached here:

Here you have to run the report step by step as mentioned in the above screen shot. After successfully done this, you have to implement the note 2074351. Then after if we check the t.code FTXP, the new field will appear as mentioned in the below screen shot.

If you select the check box, then it no longer display while posting. For details you go through the above mentioned notes.

BR

Mukthar N

Hello all,

I want to share with you a new scenario that you could face during the SFIN migration.

You are executing SFIN Migration:

a) FINS_MIG_MONITOR_RC0

b) FINS_MIG_MONITOR_RC1

And you are receiving error message F5557 - "Local currencies for company code && cannot be completely determined

If you ignore this message you will receive message FINS_ACDOC_POST002:

The cause for this error is that the currency type of controlling area '20' is assigned to the company code as parallel currency in FI (Tcode OB22) and CO (TCode OKKP).

For this scenario we can have 3 resolution scenarios:

Solution 1) Use currency type 30 for the controlling area. Currency Type 30 is supported by both FI and CO, and you get integrated amounts for both application in your universal journal. (recommended setting).

Solution 2) Use another currency type  - currency type  40 - , which is supported by both applications FI and CO, if the currency key of currency type 30 does not fit to all controlling areas.

Solution 3) Use currency type 20 in the controlling area. But this is then an "CO-only" amounts in the universal journal, which we allow for compatibility reasons. This is not the recommended setting. In all line items, with G/L Accounts, which are is not a cost elements,   the amount in currency type  20 will be 0.

Solution 1) or Solution 2) is the better choice and recommended by SAP. But if you want keep with Solution 3 you should apply the corrections of note 2187380. With this note you can use currency type 20. But the amount will be filled in cost elements only.

For Solution 3 follow the steps:

1)     Apply the corrections of note 2187380.This note will avoid inconsistences in the future.

2)     Check in SE16 the of table T001A. In T001A you should not find any entry which has currency type '20' assigned. All values should be empty (no parallel currency used).

3)     Check it with SE16  table FINSC_LD_CMP, if the record for Ledger 0L and Company Code contains space in field CURPOSK. (Currently there is '2' in this field.)

I hope this content can help you when you are planing your migration. It is important check you CO/FI customizing before the migration.

Kind Regards,

Raquel