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.
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.
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 VKOA maintain GL account assignment for the account key (SPRO-->Sales and Distribution-->Basic functions-->Account assignment/Costing-->Revenue account determination-->Assign GL accounts).
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 :
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.
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 :
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.
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.
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.
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.Image may be NSFW. Clik here to view.
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:
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, 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.
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 )
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
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-Select Standard Line Layout for Payments
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
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
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 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 3rd 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.
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 3rd 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.
In OBYC, Copy the PRD lines for the required valuation modifier and valuation classes. And assign a General Modifier ZIC.
Assign the required GL account in OBYC, for the PRD transaction and the account modifier ZIC.
Use the enhancement point of the FM MR_ACCOUNT_ASSIGNMENT, as shown below, to write the logic for replacing the PPV account.
Check if it’s an intercompany PO. Same can be checked by various criteria as, PO Document type, the IC vendor.
And check if, the transaction type (VORGANGSSCHLUESSEL) is “PRD”.
If so, change the KONTO_MODIFto ZIC (defined in step a).
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.
By a constant value
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.
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.
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 :
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.
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 :
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.
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.
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.Image may be NSFW. Clik here to view.
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:
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, 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.
