Hi,

To Correct Accounting in Wrong Tax posting below Scenarios will help to satisfy your Requirement.

Below procedure explain you how to rectify the tax Posting within Tax codes like Input to Output or Vice Versa.

Reverse Charge Mechanism also will work here as like below scenarios. ( Example Scenarios with Screen shot provided).

We will post such kind of posting using the JV solution Document Type SA and Transaction Code F-02

Over 1st Screens says that we are selecting the Output Tax GL debiting and with the Ref and header Text Information.

2nd Screens we are filling like the provided input and posting key 50 with the other GL posting ( here we are putting the Input tax GL for RCM posting )

3rd Screen also we are filling as per information provided. and after updating the all fields are stimulates we will have below inputs.

Here you can see system only taken the Amount values for posting and base values for checking the Tax code posting values.

Only Tax values are considering this kind of entries to tax reporting and adjustments.

Thanks !!

Milind Joshi

Team,

While checking the Requirement of Deemed Supply Scenarios in Malaysia, according to Solution Design we can use the below configuration steps to achieve the requirement.

Here we are creating the Tax code Z7 for Deemed Supplies (e.g. transfer or disposal of business assets without considerations) 6%

We are creating the Tax code under The Tax procedure TAXMY

Then Once enter we are following below assignment

after entering the details we will update the Tax % as like RCM ( Reverse Charge Mechanism)

Once we update the Tax code % and information we will save this tax code.

Here we are ready to use the tax code for Deemed supply posting.

test Scenarios for FB60 with Z7 Tax code is as bellows;

Here I have picked two GL one is along with Tax code and another without tax code.

With Tax code GL contain Expense account and another GL for Expense out for Deemed Supplies JV scenarios.

with Stimulate the document you will looks that entries like below :

Here you can see the System obtain the results as per Deemed supplies scenarios which is explain by Govt. of Malaysia.

Where Vendor Account .. CR

Exp. Account ... Dr

Vat Input A/c.. .. Dr

Deemed Supplies says that you need to self declare that Input tax = output tax then JV is as below;

Output Tax A/c ........ CR

Exp. Deemed Supply... Dr

Thanks !!

Milind Joshi

The field REGUP-BVTYP is only filled if the field was filled in the paid item (see BSEG-BVTYP, visible e.g. in the item list or in the document display transactions, FB03).

This field, REGUP-BVTYP, is only used for the partner bank determination during the payment run. Hence, there is no other purpose of this field in subsequent process steps. This is the system standard behavior.

The system only transfers the bank details ID if the indicator T042Z-XBKKT (bank details are required entry in master record) or

T042Z-XPGIR (indicator that the payment method is the post office bank current account method or postal check current account method) are set in Customizing of the payment program (FBZP transaction) when you enter the payment methods or country.

Additionally with the modification notes 524942 and 390740 (not contained in the standard), it is also possible to get Partner Bank

Type filled in.

The flags "Calculate Tax" and "Determine tax base" are just to make online transactions easier. If it would be set also in background the user has no influence to check if the flags are correct or not. They are only in foreground because of security reasons.

Furthermore it could lead to breakdown situations in batch runs. The effect would be that a lot of jobs would not be finished successfully.

The same information is stated in note 124655, point 2:

2.  You cannot carry out tax-relevant postings like telecommunications expenses to bank using the electronic bank statement. If despite this you want to create such postings, you must implement this via the user exit supported (enhancement FEB00001 via Transaction CMOD/SMOD) or by making the corresponding settings in Customizing and carrying out a subsequent processing. In the event that subsequent processing is carried out manually, for example within batch input processing, you may encounter problems with the tax breakdown. In this case consult Note 106271.

In FEBAN in menu 'Edit' -> 'Posting Mode' there are 3 entries:

In Foreground                       -> XTX will be used

In Background                      -> XTX will not be used

After Error in Foreground     -> XTX will not be used

Purchase Price Variance:

In Real Time scenarios, it’s not always the case that the PO Price is in sync with the Standard Product Cost and/or the Vendor invoice amount. That results in Purchase Price Variance. Purchase Price Variance is generally the difference arising out of a GR and/or IR, as compared to the PO price. Let's take an example to make it clearer.

Example: A PO has been raised for, for 1200 USD .Let’s say it has one material in the line item,
whose standard product cost is 1000 USD.

Now let's see, what happens during a GR. Point to note is that, GR generally happens at a standard price and the GR IR clearing always happens at
the PO price. During GR the accounting entries will be as below.

Inventory Dr 1000 (source is OBYC BSX)

GR IR clearing Cr 1200(source is OBYC WRX)

PPV Dr 200(Source is OBYC PRD)

What this means practically is, a goods whose price is 1000 USD in the books of the company, has been purchased at a higher price that is
1200 USD. And hence it amounts to loss of 200 USD, which is booked to the PPV account. If the purchase price would have been less that the standard price of the product, a gain would have been recorded in the books.

Significance and Usage of PPV

As now, we are clear with the PPV, let’s now discuss about its significance. As PPV, is an indicator of the deviation of Purchase Price from the Standard Price of the product, the regular occurrence of PPV, for a particular goods, indicates, that the goods has not been costed properly. Hencethe company may decide to re-cost it.

3rd Party and Intercompany PPV

PPV can be generated from a 3^rd Party transaction or from an intercompany transaction. It is preferable, if the PPV hits separate accounts for these two scenarios. It helps in keeping track of the intercompany ppv easily.

Although with standard SAP, we don't have a configuration catering to this need, we can use custom development or substitution to cater to this need.

Ways of Splitting the PPV in to 3rd Party and Intercompany PPV

This can be achieved in multiple ways. Listed below are 3 such ways to achieve this.

1. through Enhancement

Here during the posting of the PPV the entry will hit the intercompany PPV, if it’s a intercompany transaction.

   2. through Line Item Substitution

Here during the posting of the PPV the entry will hit the intercompany PPV, if it’s a intercompany transaction.

   3. through a stand-alone program

Here, initially, the PPV, will be posted to the same account. Later in Month End, it will be split between the intercompany PPV and the 3^rd Party PPV.

Technical Details

1. Through Enhancement:

In this case, a logic would be written in the enhancement point of the FM MR_ACCOUNT_ASSIGNMENT, so that during the posting of MIGO/MIRO,
the PPV account will be tweaked for the desired criteria. It will need some config steps as well to achieve the needful. Below are the steps to do it.

1. In OBYC, Copy the PRD lines for the required valuation modifier and valuation classes. And assign a General Modifier ZIC.
2. Assign the required GL account in OBYC, for the PRD transaction and the account modifier ZIC.
3. Use the enhancement point of the FM MR_ACCOUNT_ASSIGNMENT, as shown below, to write the logic for replacing the PPV account.

1. Check if it’s an intercompany PO. Same can be
   checked by various criteria as, PO Document type, the IC vendor.
2. And check if, the transaction type (VORGANGSSCHLUESSEL) is “PRD”.
3. If so, change the KONTO_MODIFto ZIC (defined in step a).
4. Then for the Intercompany POS, the PPV picked will
   be the one assigned against transaction PRD and account modifier ZIC.

2. Through Line Item Substitution

Here a substitution step can be created at the line item
level. Prerequisites can be the PO Document type as an intercompany type, and
the vendor as the IC vendor. Then the GL account can be substituted by the
following two ways.

1. By a constant value
2. By writing a logic in one of the exits, to pick
   the value from OBYC, “PRD” and “ZIC” combination. Please note that a
   prerequisite of this step will be to create an account modifier “ZIC” in OBYC
   and assigning a GL account against it.

3. Through stand-alone program:

As we have seen above the entry during GR, with PPV, is as
below.

Inventory Dr 1000 (source is OBYC BSX)

GR IR clearing Cr 1200(source is OBYC WRX)

PPV Dr 200(Source is OBYC PRD)

Say, this account "PPV”, is meant for 3rd Party PPV and, we have created another GL account, "PPV1”, for intercompany PPV. We can store this account (PPV1) in TVARVC table, for convenience, or can maintain this in OBYC, as mentioned in point b in the previous section,

A logic can be written, such that, the program, when run, will pick out the line items for the PPV account, for the period in which it is run. Based on the Vendor/PO Document Type, it will identify the posting as an intercompany PPV. Where ever it finds so, it will make a posting as below.

PPV1 Dr 200 (Intercompany)

PPV Cr 200 (3rd Party)

The above posting, is achievable by the BAPI “BAPI_ACC_DOCUMENT_POST”

Such a custom program can be scheduled as a batch job, during the Month End, so that by Month End, there will be a clear segregation
of intercompany and 3rd party PPV.

These are the various means in which, the 3rd Party PPV and the intercompany ppv can be segregated.Your suggestions and comments on this are most welcome.

Procedure to setup house bank in sFIN system

• Until ECC we (FICO consultants) were created house banks in GUI by using T.Code: FI12,but here in S/4 HANA (sFIN) house bank creation has been split into two part.

1. Create House bank and house bank key in GUI by using T.Code: FI12_HBANK

2. Create and Assign Bank accounts (Current Account1 / 2 etc.) to House Bank in NWBC.

From S/4 HANA we have to options to crate House bank accounts from NWBC.

a) BAM Lite – it is free.

b) BAM (With Cash Management) need separate license.

From BAM we have additional features:

• Standard Workflow triggers for activating accounts.
• Signature approval.
• BCM – Bank Communication Management.
• Liquidity and forecasting & Planning.
• Cash Management functions Etc.

For more details, please check below OSS notes.

Steps to create House bank keys, House banks & Bank accounts.

1. Create Bank Key in ECC: FI01

2. Create House Bank in ECC: FI12_HBANK

3. Login to SAP NetWeaver Business Client with (BAM / BAM Light)

    1) Select Manage Bank Accounts:

    2) Select House Bank Account List:

    3) Select New Bank Account:

    4) Select Save & Active:

    5) Select “EDIT” Button.

    6) Select “Connectivity Path” button.

    7) Select “Add” button.

    8) Select “Save as Active” button.

Here the complete house bank has been crated and you can use this for payments and collection (FBZP etc.)

Following technical steps were you performed for bank account creation:

i) Addition of three roles to the user profile

ii) House bank can be created using transaction FI12_HBANK.

iii) Account have to be created using NWBC using role SAP_SFIN_CASH_MANAGER

iv) First time, you do it, system will give an error message “No configuration done in Bank Account Management”, if BAM is not configured.

v) Navigate to IMG path

(Financial accounting (New) --> Financial supply chain Management --> Cash and liquidity Management --> Bank Account Management --> Basic settings

    a) Define number range for technical id

    b) Define number range for workflow change requests

    c) Map the number range of technical id with workflow change requests

vi) Now create accounts using NWBC.

vii) Check the accounts created using NWBC role “SAP_FI_BL_BANK_MASTER_DATA”.

TABLES:

• FCLM_BAM_ACLINK2
• T012K

OSS Notes:

2138445 - Release Information Note: SAP Cash Management powered by SAP HANA as part of the SAP Simple Finance, on-premise edition 1503

2165520 - Feature Scope Differences between Bank Account Management and Bank Account Management Lite

Note: Download Attached image (JPEG) file and open with Paint (Right click and select EDIT)

When entering the parameters to run F110, you receive error 'Company code XXXX is already contained in another group - F0016'. System may be returning this error due to one of the reasons below:

• You added two lines with the same company code.
  As there is a limit of 10 payment methods per company code per payment run that can be entered in the payment parameters, if you try to enter another line with the same company code and different payment method you will get the error message.

• There is a bug in the system.
  SAP Note ‘2056384 - Error message F0016 displayed while saving parameters, which is incorrect’ was released to correct this error in several releases when it is returned incorrectly. After implementing the note, the error will be fixed for payment runs         created after the note implementation. In this case, you should create a new example (F110 run after the note implementation).

• The problem is not the payment method, but the field 'next payment run date'.
  This field is used to check if the item should be paid in this run or if it can be paid in the next run, this field is independent from the payment method, so having 2 different payment run date how the system would know which one is valid?

• You changed the order of the company code entered in parameters.
  Please check KBA 2196460.

Hello, SAPers!

Here is a small tip on defining tax codes per transaction. For some of you, especially those with wide and long experience in FI module, this post might be trivial, but it might be interesting for consultants that just started on their career path.

Customizing of country’s tax scheme very often involves a lot of tax codes, which can be linked together into so called chains of tax codes (deferred versus target tax codes). Many of these target tax codes are used solely for reporting purposes via different tax grouping versions (OBCH / OBCG) and are not used by users in their daily operations. Nonetheless, these technical tax codes appear in drop-down lists in transactions FB60 / FB70 / MIRO etc. and cause inconveniences for end-users to select the right tax code.

Fortunately, SAP provides standard solution that enables you to manage the visibility of tax codes in financial and logistics transactions. In order to configure the settings go to transaction OBZT. Alternatively, you can use the following menu path:

IMG → Financial Accounting (new) → Accounts Receivable and Accounts Payable → Business Transactions → Outgoing (or Incoming) Invoices/Credit Memos → Outgoing (or Incoming) Invoices/Credit Memos - Enjoy → Define Tax Code per Transaction

Specify the country key in the pop-up windows and press Enter. Once in the transaction press New Entries button.

In this transaction you can configure the tax codes that will be available for end-users in FI-AP (FB60 / FB65) / FI-AR (FB70 / FB75) transactions as well as logistics invoice verification (MIRO). You can also set some tax code as default one in these transactions. Screen-shot of typical tax codes settings can be found below. Note: the visibility of input tax codes can be customized differently for FI-AP accounting and logistics invoice verification (in case, when FI-AP should be used only in certain cases that require specific tax codes). In this example the visibility of input tax codes was customized in the same way for FI-AP and MM-LIV areas.

Thus, when you access transaction FB60 you will see, that the tax code is already specified:

When end-user would like to select another tax code, the choice will be limited to transactions defined in OBZT:

Thus, there are two main benefits of the settings customized in transaction OBZT:

   1) Setting of default tax codes per accounting module (FI-AP / FI-AR / MM-LIV);

   2) Limiting the choice of tax codes to a handful of codes relevant to an area which makes it easy a) to select the appropriate tax code for end-users, and b) prevents end-users from specifying incorrect tax code (especially target tax codes instead of deferred ones).

There are some limitations of the settings in OBZT. For example, you cannot restrict the list of available tax codes for creation of purchase orders (transaction ME21N) or for generic transactions like FB01. But in most cases, especially when integrated invoicing processes are in place, FB01 will be used rarely and primarily for different adjustment postings. This transaction is also not used to manage the visibility of tax codes in SD module. Standard condition techniques in SD (VK11) ensure automatic determination of tax codes for sales documents. Condition technique determines tax codes as a rule based on the combination of tax categories in material’s and customer’s master records.

Update from 12.01.2015

In order to deal with "old" tax codes i.e. tax codes should no longer be used e.g. due to changes in VAT rates or any other changes in VAT legislation that make certain tax codes obsolete, SAP introduced functionality that enables deactivation of tax codes. This functionality is delivered in OSS-notes 2074351 and 2095960. It adds a checkbox "Inaktive" in tax code properties in FTXP, so whenever this checkbox is activated for tax code, it will no longer be available for input via search help. However, it still would be possible to use it in postings and as a selection critaria in tax related reports. However, if you have settings for a certain tax code in OBZT to be displayed e.g. in FI-AP and you marked this tax code as inactive in FTXP, this tax code still would be visibile for postings via search helps, which means that OBZT settings override those in FTXT.

For more information on deactivation of tax codes please refer blog post "Deactive tax codes" by Mukthar Ali Ahamed N.

Best regards,

The Wirtschaftsmann

Hi,

To Correct Accounting in Wrong Tax posting below Scenarios will help to satisfy your Requirement.

Below procedure explain you how to rectify the tax Posting within Tax codes like Input to Output or Vice Versa.

Reverse Charge Mechanism also will work here as like below scenarios. ( Example Scenarios with Screen shot provided).

We will post such kind of posting using the JV solution Document Type SA and Transaction Code F-02

Over 1st Screens says that we are selecting the Output Tax GL debiting and with the Ref and header Text Information.

2nd Screens we are filling like the provided input and posting key 50 with the other GL posting ( here we are putting the Input tax GL for RCM posting )

3rd Screen also we are filling as per information provided. and after updating the all fields are stimulates we will have below inputs.

Here you can see system only taken the Amount values for posting and base values for checking the Tax code posting values.

Only Tax values are considering this kind of entries to tax reporting and adjustments.

Thanks !!

Milind Joshi

Team,

While checking the Requirement of Deemed Supply Scenarios in Malaysia, according to Solution Design we can use the below configuration steps to achieve the requirement.

Here we are creating the Tax code Z7 for Deemed Supplies (e.g. transfer or disposal of business assets without considerations) 6%

We are creating the Tax code under The Tax procedure TAXMY

Then Once enter we are following below assignment

after entering the details we will update the Tax % as like RCM ( Reverse Charge Mechanism)

Once we update the Tax code % and information we will save this tax code.

Here we are ready to use the tax code for Deemed supply posting.

test Scenarios for FB60 with Z7 Tax code is as bellows;

Here I have picked two GL one is along with Tax code and another without tax code.

With Tax code GL contain Expense account and another GL for Expense out for Deemed Supplies JV scenarios.

with Stimulate the document you will looks that entries like below :

Here you can see the System obtain the results as per Deemed supplies scenarios which is explain by Govt. of Malaysia.

Where Vendor Account .. CR

Exp. Account ... Dr

Vat Input A/c.. .. Dr

Deemed Supplies says that you need to self declare that Input tax = output tax then JV is as below;

Output Tax A/c ........ CR

Exp. Deemed Supply... Dr

Thanks !!

Milind Joshi

Hello everybody,

I was having a problem in an XML bank statement where some of the banks were using a different tag for statement number (AZNUM) than others. The mapping of an XML bank statement into FEB* tables is normally done in the transformation FIEB_CAMT053_V2_TO_FEB. I could not find it explained in any of the threads how to work with this transformation. At the first glance you can see that there are conditions for some fields. I finally found out how to use a simple condition so I think someone might find this useful.

Consider this scenario:

Some of the banks are sending statement number in this field:

Other banks in this field:

Standard transformation provided by SAP is mapping the second case into FEBKO-AZNUM. Now I wanted to achieve that both fields can be used without any error in bank statement processing. The condition could look like as follows:

Tcode: STRANS

Now what it all means - if the tag ElctrncSeqNb is in the file the value in this tag will be populated. If it is not there, the value in the tag LglSeqNb will be populated instead. You also have to define ElctrncSeqNb as a variable.

It took me few hours to find out have a simple "when" condition works here so maybe it can save those hours to somebody else.

Regards,

Ondrej Zatopek

Configuring Terms of Payment

Terms of payment is used in SAP to determine the due date and discount calculation. Terms of payment is maintained in vendor master and customer master to default at invoice level however this can be changed at invoice level as well.

• For FI invoices payment terms is defaulted from “Accounting View” for customer and vendor. FB60/FB70
• For Purchasing invoices payment term is defaulted from “Purchasing View” in Purchase Order / MIRO Invoices
• For Customer Invoices from SD side the payment is defaulted from “Sales Data” view.

Let us see the configuration and field explanation for payment term fields in detail –

• Payt Terms: This field contains four characters alphanumeric identifier for payment term key.

• Sales text: Maintain the short text for explanation. The explanation can be maintained up to 30 characters. This field validates the account type “Customer”. If you maintain the text here and account type “Customer” is not “Selected” system will give you an error as below.

• Day limit: This field is used to specify the particular term of payment is valid from which particular date. Example as below –

Example 1 – Payment Term T001

Day Limit   – 20

Discount – 5 %

As per above details system will consider this payment terms for the invoices posted in system ON or BEFORE 20^th date in every month and applies 5% cash discount. The discount won’t be applicable for invoices posted after 20^th in month.

Example 2 – Payment Term T001

Day Limit   – 31

Discount – 2 %

As per above details system will consider the invoices for 21^st to 31^st and applies the 2% discount.

This perfectly suits where the requirement is – the invoices posted upto 20^th should have 5% discount and invoices posted in date range of 21^st to 31^st should apply discount of 2%.

• Own explanation: This field is used to give detail explanation of the payment term. Be careful while using this field because this field overrides the explanation automatically generated by system based on discount percentage and days entered.

Example 1 –

In below example system has updated the explanation as per days and percentage entered in “Explanations” section.

Example 2 –

Now if I maintain the “Own Explanation” system will override the “Systems automatically generated” explanation. Refer below image –

• Account Type –
  • Customer: If payment term is intended to use for “Customer” please select this check box.
  • Vendor: If payment term is intended to use for “Vendor” please select this check box.

• Baseline Date Calculation –
  • Fixed day:  This field signifies the “calendar fix day” for base line date calculation.
  • Additional Months: Value maintained here is used to add the calendar month for base line date calculation.

See below example –

In above case the base line date would be 15^th of the next month.

• Pmnt block/pmnt method default –
  • Block Key: The value maintained in this field signifies the block key for payment. If block key is maintained here the system proposes the block key along with terms of payment.
  • Payment Method: If user wants to maintain the payment method here other than customer/vendor master it can be maintained here as an identifier.

• Default for baseline date –
  • No Default: Selecting “No Default” here means system prompts user to enter baseline date as own.
  • Posting date: Selecting this means posting date mentioned will be same as “Baseline Date”.
  • Document date: Selecting this means document date mentioned will be same as “Baseline Date”.
  • Entry date: Selecting this means “Systems Date” will be same as “Baseline Date”.

• Payment terms –
  • Installment payment: Check this field if user wants to break down the invoice line items with different due dates.Use the installment payment term functionality to achieve this.
  • Rec Entries:Supplement fm Master: Selecting this indicator means, for recurring entries the payment is term is fetched from master record if does not found in line item.
  • Percentage: The percentage rate which will be used to calculate the discount.
  • No. of days: Maintain the number of days for the discount rate is valid. Like if payment received within 10 days 3% discount will be granted. So maintain the 3% in percentage field and 10 days in “No. of days” field.
  • Fixed date: This field is used to determine the fix day of the calendar month as due date.
  • Additional months: Enter the value here if you want to add the months to fix day.

In above example -

• 5% discount will be granted in the same month.
• 2% discount will be granted if payment performed before 15^th of next month
• Full payment is due after this.

• Explanations: This explanation is system automatically generated, unless payment term description maintained in “Own Explanation” field.

Please proivde your valuable comments ! Any suggestions / guidance is welcome !!!

Advantages:

• Number of cash journal business transactions can be created as a part of customizing. Hence it is easy, smooth and fast to make entries in the cash journal.
• In a two-step procedure, you save the entries in the cash journal before they are transferred to Financial Accounting.
• If you have the appropriate authorization, you can delete cash journal entries that have been saved.
• The cash journal is a single-screen transaction. This means that you can enter, display, and change cash journal documents on one screen.
• Cash journal entry (receipt, payment) can be printed easily. Also cash journal printing is possible.
• The system automatically calculates and displays the opening and closing balances, and the receipts and payments totals.
• Cash journal ensures that cash balance cannot go in negative.
• All cash transactions are available at one place.
• Cash position can be viewed at any point of time.
• Cash transactions (receipts, payments) can be easily analysed on daily / weekly / monthly basis.
• Configuration time is also very less.

Notes:

• Separate cash journal has to be created for each currency petty cash.
• Branch-wise separate cash journal can be maintained.

Configuration:

SPRO > Financial Accounting > Bank Accounting > Business Transactions > Cash Journal

• FS00 – Create G/L Account for Cash Journal: Ensure post automatically is on, so that posting can take place automatically.
• OBA7 – Define Document Types for Cash Journal Documents: Standard document type delivered by SAP is SK. New can be created suggest to copy the SK.
• FBCJC0 – Set Up Cash Journal: Give a Cash Journal Code, GL account, currency, document types.
• FBCJC1 – Define Number Range Intervals for Cash Journal Documents
• FBCJC2 – Create, Change, Delete Business Transactions: Enter business transactions based on frequently used postings. E.g. business transaction for Conveyance Expenses. Enter company code, transaction serial number (like 1 or 2). It can be used while posting cash journal transactions in FBCJ. For vendors & Customers GL account need not be given.
• FBCJC3 – Set up print parameters for cash journal: Enter company code, programme RFCASH**, Variant CASH**, Correspondence SAP18

Valuable thoughts / suggestions are always acceptable.

1. Introduction:

Earlier for generating Financial Statement below company code level required manual effort and usually done as month end activity. With New GL, SAP provide a feature name Document Splitting, document splitting provide balance line value for given characteristics (e.g. Profit Center or Segment)

It is also required as Requirement of International Accounting Standards (IAS)

IAS mandate to provide financial Statement Segment wise as in report financial information by lines of business or geographic area.

For e.g. suppose there is a Vendor Invoice of USD 11000 for two purchases

The transaction is taxable (@10%)

Now this document is balanced at Co Code level. But as Purchases belong to different profit center PC1 and PC2, hence document is not balance at Profit Center level.

Now we have to find a base splitting logic to split vendor amount and tax for PC 1 and PC 2.Here it is observed that Purchases are in the ratio of 80% and 20% and also allocated for PC1 and PC 2

So Total Purchases is USD 10000i

For PC 1 = 80% of 10000 = USD 2000, For PC 2 = 20% of 10000 = USD 8000

Same as Tax can also be split

Total Tax amount is USD 1000

For PC 1 = 80% of 1000 = USD 800, For PC 2 = 20% of 1000 = USD 200

We can use the same ratio to split vendor amount and Tax amount.

So now document will be posted as

Now both the documents are balanced at Co Code level also at Profit Center level. Document is balanced with specific characteristics also.

Now with above example we can make two statements:

1.    Line item for Vendor and tax are split on the base of Pre-Defined criteria

2.    The Pre-Defined criteria here is Purchase Amount

So splitting Accounting line item on the basis of Pre-Defined Criteria is Document Splitting

1.2. Example in SAP:

Now New GL do this activity automatically once configuration is done. For user (Entry Ledger view) only single entry required, SAP will create separate line item based on the pre-defined criteria (General Ledger View)

Here the example is based on splitting of Vendor amount based on Profit Center:

Here Vendor 9001 got credited for expense for Postage and Purchased services 

So Accounting Entry Would be:

Now as mention above the document is balanced on co code level but not at Profit Center level

Now before Document Splitting:

Even if we look at general ledger view document is not balanced at profit center level

After Document Splitting:

In case Document Splitting configured for Profit Center level then General Ledger view should be look like below:

Now the document is balanced on both Co Code level and Profit Center level and User need not to manual adjust this, SAP does it automatically as per configuration.

If we look at the accounting Entry:

2.    Type of Document Splitting:

Now Document Splitting can be divided into three parts:

2.1. Passive Split

Passive Split is used when SAP spilt a document line item based on split took place in previous process (While Payment of Vendor, splitting will be done as logic used in vendor invoicing)

For e.g. if a payment is made for earlier discuss example

Now we know for Profit Center Level vendor Amount has been already split, so Bank Amount (Payment) will also split as same pre-defined criteria used for Vendor Invoicing

Now the clearing transaction is also balanced on profit Center level.

This SAP do automatically as per configuration (* the rule for Passive Splitting are already defined in System and cannot be changed)

Example of Passive Splitting:

Now if we make a payment for invoice created earlier

Accounting Entry:

Now from User Perspective (Entry View) it looks normal payment:

But if we look the same document in General Ledger view

SAP automatically split the payment as per ratio of vendor invoice and this is example of Passive Split.

2.2. Active Splitting

SAP split the line items of some pre-defined splitting rules.

In above example vendor and tax amount is split according to expense (purchase) amount across profit center. SAP provide various standard Splitting rules for various business transaction, if required customization can be done for new splitting rules.

Example for active splitting discussed earlier. (Under Basic Concept)

2.3. Splitting for Zero Balancing:

Zero balancing is taking care of document should be balanced also it should be balanced for specific characteristics (e.g. Profit Center)

Characteristics for which Zero Balancing required can be define

Document is balanced but not specific to profit center. Hence an offsetting account defined which is used to make document zero balancing for specific characteristics.

Example:

Now this a normal FI document which is balanced for Co Code level but both balancing line item belongs to different Profit Center.

Now if we draw document on profit center level, it is not balanced. Under Zero balancing account we configure an offset account which generate automatically line item to balance the document for specific characteristics (e.g. Here profit Center)

Now in this example document is balanced from Co Code and Profit Center. As mention in the screen shot Account 194500 Clearing w/ BA 0000 is configured Offset GL account.

3.    Important Element of Document Splitting:

3.1. Splitting Rules

Splitting rules define which line item need to be split and which logic need to be used. For e.g. in above example Vendor line item need to be split with Ratio of Expense item ( 80 % and 20%)

3.2. Item Categories

Item Category is grouping relevant GL account which need to be split, it helps to assign the splitting rule to complete set of GL rather individual one. Item Categories are pre-defined in system.

In order to manage easily, system can apply splitting rule for a Group of Expense Account instead of assigning individually. Item categories are pre-defined in system.

Some of Pre-defined Item categories are below:

3.3. Business Transaction and Variant

Business transaction is part of any business process. For            in Procure to Pay process vendor invoice and vendor payment are Business Transaction. In SAP business transaction can have multiple variant (pre-defined settings).In Accounting Document Type is associated with Business Transaction and Business Transaction Variant

3.4. Splitting Method

It is key element for Document splitting it actually define all the major  of splitting mention above. Example Business Transaction and variant for which splitting will take place.

4.    Implementation of Document Splitting:

Document Splitting need to be activated in SAP.

But in order to activate Document Splitting following Configuration is required:

4.1. Document Splitting Activation

SPRO Path: Financial Accounting (New) -> General Ledger Accounting (New) -> Business Transaction -> Document Splitting -> Activate Document Splitting

When Activation executed

First Document Split Check Box need to be marked and a pre-configured Document Splitting Method need to be choose.

Here it must be noted that Document Splitting activate on client level but it can be deactivated by Co Code.

4.2. Document Splitting Method

Document Splitting Method actually Determine which Business Transaction and Variant will activate split and it is applicable for which GL accounts as base category and accounts which is to be split.

SPRO Path : Financial Accounting(New) -> General Ledger Accounting (New) -> Business Transaction -> Document Splitting -> Extended Document Splitting -> Define Document Splitting Method

First Splitting Method is defined as an identifier

For example here we have choose Method 0000000012 Follow Up Cost line. Next this Method identifier is configured in Splitting Rule.

4.3. Document Splitting Rule

SPRO Path : Financial Accounting(New) -> General Ledger Accounting (New) -> Business Transaction -> Document Splitting -> Extended Document Splitting -> Define Document Splitting Rule

In Splitting Rule first it is define that splitting method will be activated for which Business Transaction and variant.

Next we need to define that this Business transaction will split which type of Account (e.g. Vendor, Customer etc.)

Splitting Method are pre-defined by SAP .In order to implement document splitting following elements need to be configure

In order to Activate Document Splitting we need to Define Splitting Rules. But in order to have correct rule we need to first define few important elements.

4.4. Assign Item Categories to GL account

All splitting rule are define for item categories which is in turn define for a set of GL accounts

Choose Chart of Account:

Maintain Range of Account for Item Categories:

Note that Categories are pre-defined in system.

4.5. Classify Document Types

To bring relevant Business Transaction and variant for Document Splitting a Document Type need to be defined.

Here for given document Type Business Transaction and variant are defined:

Here we defined Vendor Invoice for Transaction 0300 and variant 0001

4.6. Define Zero Balance Account

As discussed above we have to configure zero balance account

4.7. Define Document Splitting Characteristics:

This is step is most critical, here we define document splitting will take place on which characteristics (e.g. Profit Center, Segment)

As it can be seen for our example we choose Profit Center.

Splitting Characteristics can also define for Controlling and Asset Accounting if required.

References:

www.help.sap.com

In this document, I intend to share how to create master data groups excluding certain values. The concept applies to any of the master data groups like Cost Center Groups, Cost Element Groups, Internal Order, etc.

I take the example of Cost Element Groups to explain this

Assume you want to create a Cost Element Group which includes all the Cost Elements except a few. For this, you have options like

1) Manually enter all the Cost Elements except those you want to exclude

2) Manually enter the From...To Range of Cost Elements, carefully ignoring the Cost Elements you want to exclude. Eg: Cost Elements 1 to 105, 107 to 197, 199 to 399 and so on

The above two approaches would be tedious and are prone to issues incase a new GL numbering convention evolves in future. Hence, instead of these options, one can create a Dynamic Cost Element Group, following the steps below

1. Create a Selection Variant for the Cost Elements using Program RKKOASEL

2. I created the Variant OCOS_OTHER. While creating the variant, exclude the Cost Elements that must not form part of the Cost Element Group, as below

3. Now your Cost Element Group would be .OCOS_OTHER (i.e. Prefix the name of the Variant with a dot)

4. You can now include this Cost Element Group in your Allocation Cycles (Assessment / Distribution) or in your Reports (Eg: S_ALR*)

Isn't it that simple? All you need to know is the name of the Program that can create a Selection Variant for you

For CC - Program is RKKSTSEL

For IO -  Program is RKOSEL00

You can search in SE38 as RK*SEL* and that should get you the list of relevant programs to choose from

Regards

Ajay M

Background -

In SAP ERP the document splitting is the most powerful tool is widely and most commonly used. With this function the document splits the line items based on the “Characteristics” we define in system. Often this function is used to get the financial statements correctly for segment reporting.

Back to the Basics –

Concept can be explained of document splitting with the help of one of the most basic business transaction as “Vendor Invoice”. Suppose we have vendor invoice as below which consists of two expense line items say 10,000 in total with 1,000 of tax component which sums to 11,000.

1. Expense Item 1 for 8,000 where it is assigned to PC  - X
2. Expense Item 2 for 2,000 where it is assigned to PC  - Y

If any person is responsible for PC – X wish to analyze the transactions performed for PC – X, but unfortunately the user can’t - because of, if you look at the transaction the “Vendor Balance” and “Input Tax” is cumulative and hence is not assigned to any of the profit center either X or Y.

Now if you look at the transaction above it represents that the total expense is distributed in the ratio of 80% and 20% and same of Profit Centre of X and Y. So base to this the Vendor Balance and Input Tax should also have split according to 80%-20% rule.

As per the above image the system should have posted the document as per below financial transaction entry in system -

Okay so the conclusion for whole exercise is, if the user can post the document as above, the reporting will be pretty particuar and balanced and there won’t be a problem – issue is re-solved.

Its easily said that issue will be solved but why any user will separate the line item as per calculations and split its bases always on its ratio, especially when there are 100’s of line items sometimes in any document ! And what if system takes care of this?

Well the answer is Yes, and that’s what the document splitting is all about!

Now we will understand the Document Splitting elements and key concepts –

• Passive Splitting – This type of splitting is mostly occurs when the payment transaction is posted for a vendor invoice. Now system splits the payment document bases on how the vendor invoice was split in place already.

• Active Splitting – In Active Splitting the document is split according to mySAP ERP predefined rules. SAP almost supports all the business process transactions but if it doesn’t suit to any requirement the own splitting rules can be created.

• Zero Balancing Splitting – When the amounts within financial documents are not able to balance out to Debit of Profit Centre and Credit of Profit Centre which does not Net Off as its own, SAP then automatically generates new line item to balance the document. We will see the example in following section of this scenario.

• Item Category - Item category categorizes the general ledger accounts for document splitting. In the configuration each GL account is assigned to item category. Just to name a few like 01000 – Balance Sheet Account, 02000 – Customer, 03000 – Vendor and so on.

• Business Transaction – Business transaction is real scenario of business processes happens in organization such as vendor invoice, customer invoice etc.

• Business Transaction Variant – In the SAP, financial postings are derives the item category for individual line item. Business transaction variant always works in conjunction with business transaction where business transaction restricts the business processes to be posted to. System validates a check all postings against the item category to validate if these postings are allowed by splitting rule if not then understand this failed.

• Document Splitting Method – Document splitting method works in combination with business transaction and business transaction variant it determines the document splitting rule.

• Document Splitting Rule: Document splitting rule determines which item categories will be split and from which item categories it will derive the account assignment.

Let us see the actual example from system of Document Splitting for vendor invoice –

If we are posting an invoice from FB60 with two different expenses line item as below with two different cost centers assigned now system has derived the profit center from its cost centers mentioned in line item.

Simulate this document to see pre-posting view with line item and associated assignments.

Now press F3 or Back button and come to main screen. Now go to Menu Bar Document --> Simulate with General Ledger  to see the ledger view of this document.

Once clicked on simulate with general ledger, document can be seen as below as “Document Split” functionality.

Document Splitting - Zero Balancing

As discussed above when system is not able to balance out the transaction entry based on its own it balances out by “zero balancing” account. System adds the zero balance account at its own to make balance zero for transaction. We will see the example for this now –

We will post the transaction via FB50.

Now simulate this with General Ledger View as below

If you look at above and notice simulated “General Ledger View” system has automatically generated the “Zero Balance Clearing A/C.”

Now let us look at the configuration of document splitting –

1. Classify GL Accounts for Document Splitting –

Here in this step GL’s are classified according to item categories according to business transaction nature. It is recommended that instead of assigned item category to each individual general ledger account try maintaining the item categories for “Range of General Ledger Accounts”.

2. Classify Document Types for Document Splitting –

In this step the “Business Transaction” and “Business Transaction Variant” is assigned to document types. Now almost every financial transaction in considered for document splitting.

3. Define Zero Balance Clearing Account –

In this step we have to define the zero balance clearing account which will be used to generate and balance out financial entry when it is not possible to balance out at its own, as we have seen this example earlier.

4. Define Document Splitting Characteristics for General Ledger Accounting –

This is one of the most important configurations step in document splitting. In this step we have to define the splitting characteristics. Additionally you can define whether this should be Zero Balance and

Mandatory.

5. Edit Constants for Non Assigned Processes –

In this step the constants are defined which helps to assigned the default account assignment when is not able to derive from any of the sources.

6. Activate Document Splitting

Finally the step to activate document splitting with additional settings like “Inheritance” and Activation of Document Splitting.

Select check box “Document Splitting” and apply appropriate method. SAP Standard pre-delivered method is “0000000012”.

Selecting the Inheritance signifies the line items which do not have account assignment will derive the account assignment from other line item.

Selecting Standard A/C Assgnmnt means system will set the standard account assignment for non-assigned line items.  When this indicator is selected “Constant” needs to be maintained.

Activate of Document Splitting happens at client level but it is always possible to control of activation and deactivation at company code level.

Experts guidance and comments / suggestions will be very helpful on this.

Some countries, as Kosovo, there is no IBAN generator available.

In these cases, SAP acts in accordance with the recommendations of document bellow. For Kosovo, see page 45.

http://www.swift.com/dsp/resources/documents/IBAN_Registry.pdf

The custom settings should be maintained in transaction OY17.

In additional, for more information and how to create their own IBAN generator, customers can see note 1447813, point 1 "Country-independent settings".

Reporting customer/vendor open items per profit center/segment

Expected Outcome

Reporting customer/vendor open items per profit center or segment

How can we get this and what are the pre-conditions?

Pre condition:

SAP New General Ledger is active

Document splitting of SAP New General Ledger is active and customized.

User is familiar to SAP functionality of SAP nGL document splitting.

Understanding about this topic is available at SAP Help:

https://help.sap.com/erp_fao_addon10/helpdata/en/49/11c9cc2a934a18e10000000a42189b/content.htm

An expample can be found on document under following link:

Example document splitting - vendor invoice splitting by profit center

This example deals about splitting per profit center and reporting vendor open items at profit center level.

When doing splitting at Segment level, open items can be reported per Segment.

Use Tcd: S_AC0_52000888 – Report Vendor liabilities per Profit Center.

This report can be found under:

Step 1:

Customizing for document splitting is available and tested.

This can be checked easily by taking a look on the table shown on the screenshot below.

We can see that SAP New General Ledger is active. Splitting method is set up in customizing.

Step 2:

Post invoice via Tcd. FB60

Simulating General Ledger shows following information

Then we check data in Expert Mode and also take a look into the LOG.

From Log we can see, that we have no errors

Then the document will be posted.

Post second vendor invoice

Step 3:

We run report for vendor open items per profit center with Tcd.  S_AC0_52000888

On the screenshot below we can see open items per vendor and profit center.

I am looking forward to your feedback and discussion.

I plan wrting a second/third part about reporting balance accounts per profit center/Segment.

All the best erwin

Document Splitting

I want to show the principle of document splitting.

Expected result shows GL view with splitting information:

How can we achieve this?

Step 1: Customizing

Where do we find customizing – see screenshot below

Classify GL accounts for relevant chart of accounts in your company code.

Which one is relevant – take a look on table T001

Enter name of COA and make setting for accounts

Enter at least P&L account and reconciliation account for posting vendor invoice, also add correct item category to account

In the next step classify document type for entering vendor invoice

Add business transaction and business transaction variant.

Then we define splitting criteria (like segment, profit center,….)

In the next step I have defined splitting criteria for controlling

In the last step document splitting is activated and constant value was set up

Step 2: Posting vendor invoice using TCd. FB60

Data for posting vendor invoice is entered.

Two lines on expense side have been entered with cost centers having different profit center

Using General Ledger Simulation, we take a look on the data in detail

In simulation mode we can see that splitting is done

We can see that data for reconciliation account 16 0000 was splitted in accordance to expense entries (= base lines for splitting)

Using expert mode in this screen shows us some more details.

We post document and take a look on entry and GL view

Step 3 query on posted document

Entry view:

GL view:

When using document splitting, you can report vendors per splitting criteria like segment, profit center

How you do this: I have written in document which can be found under following link:

https://scn.sap.com/docs/DOC-69970

I am looking forward to you feedback and discussion

All the best erwin

Deferred Revenue report provides Detail/Summary of Contracts that are Invoiced to deferred and the amount that is recognized.

SAP provides the Transaction VF45 to get the details but the problem is this transaction provides data for only one Contract/Order at a time. The deferred revenue report uses the VF45 logic to create a report for all/selected open contracts/orders and provides valuable information in a different format which becomes useful for auditing/reporting purposes.

This report pulls all of the Contract/Order data using the VF45 logic and then processes/converts this data into a different format. This report provides the following key information for the Deferred Revenue GL Accounts -- Deferred Revenue OP Balance, YTD Deferred Revenue, YTD Revenue Recognized, Ending Balance and Unbilled revenue in Transaction Currency for each of the Open Contracts along with other details like Customer, Material and Profit Center.

When Revenue Recognition process is activated, invoices posted will hit the designated deferred revenue accounts and upon recognition will reduce the recognized amount from the deferred accounts. This report is useful when your company has thousands of contracts and billing happens often.

Following is the data selection screen:

Report Output:

Output Column calculations:

Deferred Rev Beginning: Sum of the invoices Posted in the prior fiscal year - Sum of Recognized Amount in the Prior Fiscal Year

YTD Invoiced to Deferred: Sum of all invoices posted in the current fiscal year up to the period for which the report is executed for

YTD Recognized Revenue: Sum of Recognized Amount in the Current Fiscal Year up to the period for which the report is executed for

Ending Balance: Deferred Rev Beginning + YTD Invoiced to Deferred - YTD Recognized Revenue

Unbilled Receivables: Sum of amount posted into Unbilled account due to Reversals, Cancellations etc.