Interval 3 Activation In OB52  :

Procedure to obtain the Changes :

1. Transaction code SPRO
2. Select (highlight, don't execute!) the voice 'Financial accounting --> Financial Accounting Global Setting --> Document --> Posting     

     Periods --> Open and Close Posting Period'
3. From menu select: Edit --> Display IMG activity
4. Select the page 'Maint. Objects' into 'Assigned objects' area
5. Double click on object V_T001B
6. Change the value of field 'Transport' (from Automatic to not required)

FIN_GL_CI_2: Posting Period Check for CO-FI Postings (New)

Use

From SAP ECC 6.0, Enhancement Package 4, Business Function New General Ledger Accounting 2, you can still post CO transactions in the preceding period even when this period has been closed for FI postings. For this, you can use the additional period interval 3 in the Customizing settings for the posting periods; this period interval is only relevant for postings from Controlling (CO) to Financial Accounting (FI) (New). It is valid for postings created with the real-time integration as well as for postings created using the CO-FI reconciliation ledger during closing operations.

When you create an entry for period interval 3, only postings that were transferred from CO to FI are checked against this interval. All other posting transactions are controlled with period intervals 1 and 2.

If you do not create an entry for period interval 3, the settings for period intervals 1 and 2 are also valid for postings from CO to FI.

Note

You can only define the period interval for account type +.

Effects on Existing Data

Effects on Data Transfer

Effects on System Administration

Effects on Customizing

You make the settings for this function in Customizing for Financial Accounting (New) under Financial Accounting Global Settings (New) -> Ledgers -> Fiscal Year and Posting Periods -> Posting Periods -> Open and Close Posting Periods.

Further Information

For more information, see the central Release Note for the New General Ledger Accounting 2 business function.

In order to have the field LFB1-XVERR available on modifying the vendor master record, there are five conditions that should be fulfilled:

1. Field selection 'Account groups';
2. Field selection 'Screen layout Company Code';
3. Field selection 'Screen layout activity';
4. A customer must be specified in the Vendor Master Record;
   1. FK02->General Data -> Control. In the 'Account control' tab, in the 'Customer' field, enter the customer number.
5. A vendor must be specified in the Customer Master Record.
   1. FD02->General Data -> Control. In the 'Account control' tab, in the 'Vendor' field, enter the vendor number.

The same conditions should be fulfilled for the field KNB1-XVERR.

To perform the clearing between a Customer and Vendor, follow the SAP help below:

Clearing Between a Customer and Vendor - FI Accounts Receivable and Accounts Payable - SAP Library

Dear friends,

Swachh Bharat cess is a "tax on services" in addition to service tax in india.

It has been introduced with effect from 15.11.2015 in India
The rate of Swachh Bharat Cess is 0.5% of value of taxable service on which Service Tax is payable.

Please note that Swachh Bharat Cess will have to be separately shown in all of Service Invoices raised on or after 15.11.2015.

Let me explain the step by step configurations required to have Swachh Bharat cess in SAP.

Swachh Bharat cess in Accounts Payable:

In T code OBCN (SPRO-->FA-->FA Global settings-->Tax on sales/purchases-->Basic settings-->Check and change settings for Tax processing), create new processing key. This will enable us to assign separate GL account for Swachh Bharat cess(SBC).

Then in T code OBQ1(SPRO-->FA-->FA Global settings-->Tax on sales/purchases-->Basic settings-->Check calculation procedure) create new condition type for SBC.

Then assign the condition type and processing key in pricing procedure vide SPRO-->FA-->FA Global settings-->Tax on sales/purchases-->Basic settings-->Check and change settings for Tax processing.

Then Create separate GL account for SBC vide T code FS01.

Then in T code OB40(SPRO-->FA-->FA Global settings-->Tax on sales/purchases-->Posting-->Define Tax accounts) assign GL account for the relevant tax code in the transaction (Read processing key) created for SBC in T code OBCN.

Then in T code FV11 create condition records for SBC for the service tax applicable tax codes.

The abovementioned process meant for Swachh Bharat cess payable to vendor and Service tax credit is available.

If Service tax credit is not available then we can include the SBC with the Service tax rate.

That is Service tax rate 14% and SBC 0.5% so total taxes is 14.5% and the entire amount will be booked into the natural expenses head.

With respect to Reverse charge cases, in our company we are following Withholding tax type route for Reverse charge mechanism.

We have decided to include the SBC rate in the Service tax rate and then before processing returns pass manual JV to show separately the Service tax and SBC amount.

Example If the Service tax base amount is 1000 Crores, then Serv tax is 140 C and SBC is 5C so in reverse charge, Service tax payable head will be credited by 145C . At the time of filing of return We will pass rectification entry like,

ST payable DR 145 C

ST payable CR 140 C

SBC           CR    5 C.

Swachh Bharat cess in Accounts Receivable

In accounts receivable side, we have used condition type route for service taxes and not followed Tax code route.

Create New condition type in T code V/06 (SPRO-->Sales and Distribution-->Basic functions-->Pricing-->Define condition types).

Then create new account key for SBC vide SPRO-->Sales and Distribution-->Basic functions-->Account assignment/Costing-->Revenue account determination-->Define and assign account keys.

Then in Pricing procedure assign the SBC condition type in T code V/08 (SPRO-->Sales and Distribution-->Basic functions-->Pricing-->Assign Pricing procedures)

Then in VK11 create condition records for SBC.

Then in VKOA maintain GL account assignment for the account key (SPRO-->Sales and Distribution-->Basic functions-->Account assignment/Costing-->Revenue account determination-->Assign GL accounts).

Sample accounting document is as follows.

Hope it helps.

Kindly revert back for any clarification.

Your views and criticisms are also welcome.

Thanks and Regards,

G.Sethuraman

Introduction:

Automatic Payment Program (F110) is used to do the clear the invoices and post the payments.F110 is the standard t-code for doing the same.

In addition to the above there also forms sent to customers and vendors about the Payments done which are called Remittance Advices and Payment Advices based on the payment method configured

Forms:

• There are three kinds of forms that can be used in SAP :
• SAP scripts
• SMARTFORMS
• Adobe Forms

  For payment advices we can use all the three kinds of forms .In this document configuration and the calling logics for all the 3 kinds of forms.SAP SCRIPTS:

• This is the default configuration provided by SAP.
• Standard script for the payment advices  : 'F110_IN_AVIS’
• The same can be configured in the FBZP screen as shown below :

1. Payment method in company code .This will be the default script name in case in case the configuration on the payment methods if the script name is not given.

• Enter the script name in the below mentioned place.

• Print program for each will be defined at the payment method level.

• Two types of print programs can be defined

               Use payment medium work bench :

• In the below print program will always be a standard print program in case of PMW as it is hardcoded in the standard F110 Program .
• In the standard SAPF110V program based on the xformi indicator.

• In the T042Z table FORMI is the name of the Payment medium workbench.

• Based on the above the print program will be called.

Use classic print programs :                        SMARTFORMS:

• There is no standard way of customizing smart forms in SAP for Payment advices.
• So maintain the form names in one table based on the company code and the payment method. In the program call the form name and in the part of the code in the standard include call the form name and smart form name.
• In case of the classic payment medium programs we can custom a Z Program.
• In case of the Payment medium work bench always the program RFFOAVIS_FPAYM is called :

• So create a Z program program and then use the same calling the smart forms.
• Logic to call should be written at this place in the include :

• Fill the variable hlp_pdfformular in the program by the same form name and then instead of the above FM call the smart form FM and then fill the OTF data to either send mail or to create spool.

Adobe Forms:

• Adobe forms configuration can be done only in the Company code level not on the payment method level.
• SAP has already provided standard Adobe forms for the Payment advice.
• The same can be configured and can be used.
• Below are the steps to be followed for the configuration.

Standard adobe forms for the  F110 would be F110_AVIS_INT

• Below is the place where the Adobe form will be called and sent in either email or spool.

Any Inputs are highly appreciated.

Interval 3 Activation In OB52  :

Procedure to obtain the Changes :

1. Transaction code SPRO
2. Select (highlight, don't execute!) the voice 'Financial accounting --> Financial Accounting Global Setting --> Document --> Posting     

     Periods --> Open and Close Posting Period'
3. From menu select: Edit --> Display IMG activity
4. Select the page 'Maint. Objects' into 'Assigned objects' area
5. Double click on object V_T001B
6. Change the value of field 'Transport' (from Automatic to not required)

FIN_GL_CI_2: Posting Period Check for CO-FI Postings (New)

Use

From SAP ECC 6.0, Enhancement Package 4, Business Function New General Ledger Accounting 2, you can still post CO transactions in the preceding period even when this period has been closed for FI postings. For this, you can use the additional period interval 3 in the Customizing settings for the posting periods; this period interval is only relevant for postings from Controlling (CO) to Financial Accounting (FI) (New). It is valid for postings created with the real-time integration as well as for postings created using the CO-FI reconciliation ledger during closing operations.

When you create an entry for period interval 3, only postings that were transferred from CO to FI are checked against this interval. All other posting transactions are controlled with period intervals 1 and 2.

If you do not create an entry for period interval 3, the settings for period intervals 1 and 2 are also valid for postings from CO to FI.

Note

You can only define the period interval for account type +.

Effects on Existing Data

Effects on Data Transfer

Effects on System Administration

Effects on Customizing

You make the settings for this function in Customizing for Financial Accounting (New) under Financial Accounting Global Settings (New) -> Ledgers -> Fiscal Year and Posting Periods -> Posting Periods -> Open and Close Posting Periods.

Further Information

For more information, see the central Release Note for the New General Ledger Accounting 2 business function.

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.

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

Hi Team,

Below are the steps for APP configuration.

                                                APP Configuration Document

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Method / Bank Selection for Payment Program – Set up all company codes for Payment transactions

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Method / Bank Selection for Payment Program – Set up paying Company codes for payment transactions

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Method / Bank Selection for Payment Program – Set up paying method per country for payment transactions

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Method / Bank Selection for Payment Program – Set up paying method per company code for payment transactions

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Method / Bank Selection for Payment Program – Set up bank determination for payment transactions

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Proposal Processing- Make settings for Displaying payments-Define Line Layout for Displaying Payments

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Proposal Processing- Make settings for Displaying payments-Select Standard Line Layout for Payments

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Proposal Processing- Make settings for Displaying payments-Select Search Fields for Payments

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Proposal Processing- Make settings for Displaying payments-Choose Sort fields for Payments

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Proposal Processing- Check Payment block reasons

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Automatic Posting – Prepare automatic postings for payment program

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Automatic Posting – Prepare automatic postings for payment requests

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Media- Make settings for Classic Payment medium programs- Assign Payment forms for Payment method in company code

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Media- Make settings for Classic Payment medium programs- Assign Payment medium program for payment method in country

Spro Path:- Financial Accounting- Accounts Receivable and Payable – Business Transactions – Outgoing payments – Automatic outgoing payments – Payment Media- Check Management – Define number ranges for checks

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.

Introduction:

Automatic Payment Program (F110) is used to do the clear the invoices and post the payments.F110 is the standard t-code for doing the same.

In addition to the above there also forms sent to customers and vendors about the Payments done which are called Remittance Advices and Payment Advices based on the payment method configured

Forms:

• There are three kinds of forms that can be used in SAP :
• SAP scripts
• SMARTFORMS
• Adobe Forms

  For payment advices we can use all the three kinds of forms .In this document configuration and the calling logics for all the 3 kinds of forms.SAP SCRIPTS:

• This is the default configuration provided by SAP.
• Standard script for the payment advices  : 'F110_IN_AVIS’
• The same can be configured in the FBZP screen as shown below :

1. Payment method in company code .This will be the default script name in case in case the configuration on the payment methods if the script name is not given.

• Enter the script name in the below mentioned place.

• Print program for each will be defined at the payment method level.

• Two types of print programs can be defined

               Use payment medium work bench :

• In the below print program will always be a standard print program in case of PMW as it is hardcoded in the standard F110 Program .
• In the standard SAPF110V program based on the xformi indicator.

• In the T042Z table FORMI is the name of the Payment medium workbench.

• Based on the above the print program will be called.

Use classic print programs :                        SMARTFORMS:

• There is no standard way of customizing smart forms in SAP for Payment advices.
• So maintain the form names in one table based on the company code and the payment method. In the program call the form name and in the part of the code in the standard include call the form name and smart form name.
• In case of the classic payment medium programs we can custom a Z Program.
• In case of the Payment medium work bench always the program RFFOAVIS_FPAYM is called :

• So create a Z program program and then use the same calling the smart forms.
• Logic to call should be written at this place in the include :

• Fill the variable hlp_pdfformular in the program by the same form name and then instead of the above FM call the smart form FM and then fill the OTF data to either send mail or to create spool.

Adobe Forms:

• Adobe forms configuration can be done only in the Company code level not on the payment method level.
• SAP has already provided standard Adobe forms for the Payment advice.
• The same can be configured and can be used.
• Below are the steps to be followed for the configuration.

Standard adobe forms for the  F110 would be F110_AVIS_INT

• Below is the place where the Adobe form will be called and sent in either email or spool.

Any Inputs are highly appreciated.

Interval 3 Activation In OB52  :

Procedure to obtain the Changes :

1. Transaction code SPRO
2. Select (highlight, don't execute!) the voice 'Financial accounting --> Financial Accounting Global Setting --> Document --> Posting     

     Periods --> Open and Close Posting Period'
3. From menu select: Edit --> Display IMG activity
4. Select the page 'Maint. Objects' into 'Assigned objects' area
5. Double click on object V_T001B
6. Change the value of field 'Transport' (from Automatic to not required)

FIN_GL_CI_2: Posting Period Check for CO-FI Postings (New)

Use

From SAP ECC 6.0, Enhancement Package 4, Business Function New General Ledger Accounting 2, you can still post CO transactions in the preceding period even when this period has been closed for FI postings. For this, you can use the additional period interval 3 in the Customizing settings for the posting periods; this period interval is only relevant for postings from Controlling (CO) to Financial Accounting (FI) (New). It is valid for postings created with the real-time integration as well as for postings created using the CO-FI reconciliation ledger during closing operations.

When you create an entry for period interval 3, only postings that were transferred from CO to FI are checked against this interval. All other posting transactions are controlled with period intervals 1 and 2.

If you do not create an entry for period interval 3, the settings for period intervals 1 and 2 are also valid for postings from CO to FI.

Note

You can only define the period interval for account type +.

Effects on Existing Data

Effects on Data Transfer

Effects on System Administration

Effects on Customizing

You make the settings for this function in Customizing for Financial Accounting (New) under Financial Accounting Global Settings (New) -> Ledgers -> Fiscal Year and Posting Periods -> Posting Periods -> Open and Close Posting Periods.

Further Information

For more information, see the central Release Note for the New General Ledger Accounting 2 business function.

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