For all customer debit and credit items, maximum cash discount is always considered.

The reason for this, is that the customer should not be penalized for carrying out the automatic payment after the due date. Thus max cash discount should be granted.

SAP Note 31345 explains this behavior.

Credit memos are always paid with the maximum cash discount if they do not have reference to the corresponding invoice in REBZG field.

If you post a credit memo with reference to a certain invoice (or set this reference via FB02) the credit memo will be paid with the same payment conditions as the invoice.

Or if you want the net due date to be calculated according to the payment term you have entered in the document, you need to enter a 'V' in the 'Invoice reference' field (BSEG-REBZG).

Regarding to Vendors, please check customizing of the payment program in your system:

transaction FBZP -> All Company Codes -> your Company Code -> the checkbox 'Max. cash discount'

According to F1-help to this field:

"Vendor Payments Always with Maximum Cash Discount" Means that the maximum cash discount is always to be deducted when automatically paying vendor invoices.

You set the option "Transfer days" in transaction OB82 but this is not being considered when running Item Interest Calculation (program RFINTITAR).

This is because Transfer days are only deducted for incoming payments. If you do not select them (by using dynamic selections) or when the clearing document is not an incoming payment, transfer days are not deducted.

When you select only invoices and clearing items are not selected, the program cannot determine, whether this is a payment or not or take the document date into account.
When no clearing item is selected, the interests for the invoices are calculated till the clearing date.

For considering the transfer days, you can also use BADI FI_INT_CUS01  in method INT_CHANGE_ITEMS.

Single Euro Payments Area (SEPA) Implementation of DD(Direct Debit)(Technical)

Sep, 2013

Introduction

SEPA stands for ‘Single Euro Payment Area’. It’s a system that is designed to create financial efficiency for countries using the currency Euro by providing a unified system in which to perform financial transactions. The SEPA seeks to create a better system for credit transfers, an improved debit system and a cheaper way for individuals and firms to make transactions within member countries or regions. Implementation of SEPA makes the customers life easier. Irrespective of the national area customers will be able to use the same card for all euro payments and also they need only one bank account in euro area.

Introduction to SEPA process:

The below mentioned should be done for Implementation of SEPA business in any SAP system:

1.    SEPA_Activation_Mandate_Management

Following are the activities which are to be done as part of this:

i.        SEPA mandate management has to be activated for the usage with SDD CORE and SDD B2B from FI-AR payment processing.  Apart from activating the SEPA Mandate management we need to maintain the SEPA Mandate management modifiable fields.

Below is the path for activating the SEPA Mandate Management and maintain the modifiable fields.

IMG -> Financial Accounting -> Accounts Receivable and Account Payable -> Business Transactions -> Incoming Payments -> Management of SEPA Mandates -> General Settings.

IMG -> Financial Accounting -> Accounts Receivable and Account Payable -> Business Transactions -> Incoming Payments -> Management of SEPA Mandates -> Define Modifiable Fields

ii.        Creation of new DMEE Payment Format tree for SEPA credit transfer and SEPA direct debit.

·         SEPA_CT and SEPA_DD are the DMEE formats provided by SAP.

·         As we will be dealing with multiple countries it is always better to copy the DMEE formats and create new ones. If there is any custom requirement for any country create a user exit and assign to the field that needs to be changed dynamically.

2.  Pre Notification with payment run  :

With a direct debit pre-notification, Markets can inform a payer in writing in advance of the debiting of his account. To do this, one has to schedule a run for the creation of direct debit pre-notifications before the payment run, meaning before clearing the open items and creation of payment media. These correspond in structure to the payment advice notes, and therefore contain details of the run date, the amount to be collected, mandate ID, Unified Creditor Identifier etc.

Following are the SAP notes to be implemented for SEPA Pre-notification.

As part of the Note implementation 1780941, we need to implement manual steps given below for importing the Standard SAP Form.

·    SAP has provided text file by using this file we need to import the object F110_DD_PRENOTIF into SAP by executing program RSTXCRP.  This is standard SAP form which will be used for sending PreNotifications.

·    SAP has provided XML file by using this file we need to import the object F110_DD_PRENOTIF into SAP using SFP transaction code. Once it is uploaded, activate the form.

Once all the relevant OSS Notes are implemented for SEPA Direct debit pre-notification, we will get option of checkbox for Pre-notification in F110 transaction and also pre-notification relevant standard program RFFOAVIS_DD_PRENOTIF and script form (F110_DD_PRENOTIF) available in the system.

The above check box is checked if we need to do SEPA prenotification.

RFFOAVIS_DD_PRENOTIF: This is the payment advice print program that is used to print the pre-notifications the pre-notification

F110_DD_PRENOTIF: This is the standard SAP script which is used to send the pre-notifications.

          Based on the user requirement, the form name can be changed

·      The new "direct debit pre-notification" object is visible in the payment run (F110), in the document display (FB03), in the line item display (FBL5N) and in mandate display (FSEPA_M4). It can be deleted again if the direct debit pre-notification customer objects to it (for example, because the customer pays the bill himself). Otherwise, the posting run and the payment medium creation are performed after the end of the specified wait time based on the direct debit pre-notifications.

3.  Creation of SEPA Mandates for payment transactions :

·       Before doing any transaction for any SEPA customer we need to have a mandate create for the Customer.

·       Before creating a mandate the Customer Should have IBAN number.

·       Transactions used :

NOTE: Mandates can also be created from the payment tab of the Customer Master XD01, FD01, XD02,FD02.

NOTE: Mandate Number can be either External or Internal Number.

·       To make our work easier technically we can use the below procedure using the below BAPI's:

·       The table that is Master for all the SEPA mandates is SEPA_MANDATE.

·       SEPA_MANDATE: This is the Standard Smart form used to print the mandate details for any customer.

·       Assume a file with the Customer and mandate Information is available

Ø  Check if the customer is created by checking in the KNB1 table.

Ø  If the Customer is present then check if the Customer has IBAN and BIC number.

Ø  Check if the mandate is not created for Customer with the mandate number using the BAPI SEPA_MANDATES_API_GET.

Ø  For the BAPI SEPA_MANDATES_API_GET pass the customer number in the importing parameter to check if there is any mandate information present for the Customer SEPA_GET_CRITERIA_MANDATE-snd_id = Customer Number .

Ø  ET_MANDATES contains the mandate information that is fetched from BAPI based on the Customer Number.

NOTE :   SEPA_MANDATES_API_GET FM cannot be used for multiple mandate scenario. We can write take MGUID from REGUH table and go to SEPA_MANDATE table and get the IBAN number and mandate number.

Three BAPI'S are majorly used to Creation and updating of the mandate details of the Customer.

·       Mandate Creation:

Ø Use the BAPI BAPI_SEPA_MANDATE_CREATE1 to create the mandate .

Ø BAPI_S_SEPA_MANDATE_COMMON structure which is importing parameter to the above mentioned BAPI has to be filled with the mandate information .This contains both the Sender (Customer Details ) and  receiver details (Company code data ).

Ø Then collect all the address information either from the file provided or from the customer master data and fill the Sender information in the structure BAPI_S_SEPA_MANDATE_COMMON.

Ø Then based on the company code fetch the address details of the Company code and fill the Receiver information in the structure BAPI_S_SEPA_MANDATE_COMMON.

Ø ES_MANDATE_CREATED exporting parameter in the above BAPI gives a success message if the mandates are correctly created for the customer.

Ø  Error handling can be done with the return exporting parameter.

·       If the mandate already exists then check if there is any change in the mandate information.

Mandate modification:

Ø  Use the BAPI BAPI_SEPA_MANDATE_CHANGE1 to change the already existing mandate.

Ø  BAPI_S_SEPA_MANDATE_CHANGE structure which is importing parameter to the above mentioned BAPI has to be filled with the mandate information .This contains both the Sender (Customer Details) and  receiver details (Company code data ).

Ø  In case ofupdation is failed it can handled by  return parameter of the BAPI

  Display of Mandates :

Ø  The created mandates can be checked by FSEPA_M3 Give the Mandate number or Customer Number and check for the Mandate information.

On Click on Enter the below Screen appears which displays all the information.

Ø We can also check the Mandate information through Customer master display  using transaction fd02,xd02,xd03,fd03.

Click on the Tab to check and create the mandate Details from Customer master

Display the List of Mandates:

Ø  Use the transaction FSEPA_M4 to display a list for customers for a particular company code.

Ø  Mention the company code in the below transaction and then execute all the mandates present for the company code will be displayed.

Ø  A list of mandates will be displayed as shown in the below screen shot.

The above lights depicts different status of the mandates below are the differnent status of mandates.

Ø  If we need to print a particular mandate information then select the Print mandate button on the top right corner of the list .

Ø  For this SAP has provided a smartform SEPA_MANDATE.This can be customized at central level and the thus the mandate can be created and mandate information can be printed.

All the inforamtion related to the mandate is available in the table SEPA_MANDATE.

Payment order is  a Standard SAP tools used in payment process .. its firstly assign a payment order number against the open item paid with no payment entry generated then when processing bank reconciliation if the payment order appear in bank statement the system generates the payment entry and close the open item.. assignment of payment order number is preventing from duplicate payment ..

The configuration steps is:

T-code: OT84

          - ( Create account symbols) Y12 “Payment Order”

• (Assign Accounts to Account Symbol ) assign Y12 to GL Account ++++++ as below

• (Create Keys for Posting Rules) create a Keys for posting rule Y12

• (Define posting rule)  define a posting rule like below

Posting Area 2 “Sub ledger posting “

Document Type: KZ

Posting Type : 7 “clear Debit Sub ledger account

• T-Code FBZP “ Pmnt method in country” in posting details section choose Payment order only

• T-code OT52 create manual bank statement posting rule

Interpretation Algorithm : 29 “Payment order”

• T-code: OT43 Define Variant for Manual bank Statement

You have to add the payment order to variant

• While Run F110 , SAP will create payment order Number for the selected invoice to be paid
• You can display the payment order created from F110

• When Run FF67 .. you have to enter payment order Number

• SAP will create the below entry and clear the open item

Note that the payment order will not appear in FBL*N report due to standard SAP behavior .. you may refer the below link to insert the  payment order number in FBL*N report

How to insert Payment Order in FBL1N or FBL5N

Regards

Mahmoud EL Nady

Introduction:

‘BAPI_COPAACTUALS_POSTCOSTDATA’is a Standard SAP BAPI provided to post COPA documents in the system. This BAPI is ideal to post CO-PA documents through ABAP programs by providing all requisite information as input.

As-Is situation:

• Currently SAP is using the below mentioned function module to execute the KE21 transaction for posting CO-PA documents.

call function 'RKE_CREATE_BATCH_INPUT'
exporting
erkrs       = p_erkrs
group       = p_sesion
user        = sy-uname
tables
ep_tab      = it_batchinput
fieldtab    = it_dbtable
exceptions
no_ep_found = 1
others      = 2.

• Once the above sessions are created then run the below program

submit rsbdcsub exporting list to memory
with bis      = sy-datum
with mappe    = p_sesion
with von      = sy-datum
with z_verarb = true
and return.

• The above FM creates a BDC and creates the session for which it will be run from SM35 Transactions.

Cons of using the FM 'RKE_CREATE_BATCH_INPUT'

• In case of any errors the entire session has to be reprocessed.
• Also time taken to create the session and the run the session in SM35 is tedious job.
• No track of the Document number in the output display is possible if the posting is done through the standard reporting.
• Many performance impacts are possible as we are using the BDC recording.

Usage of the BAPI ‘BAPI_COPAACTUALS_POSTCOSTDATA’:

• The mentioned FM can be replaced with the BAPI

  call function 'BAPI_COPAACTUALS_POSTCOSTDATA'
      exporting
      operatingconcern = i_erkrs
      testrun          = i_testrun
      tables
      inputdata        = t_dat
      fieldlist        = t_field
      return           = t_return.

The above BAPI provides the below advantages for postings :

• Test Mode functionality for which it will identify if there are any errors which are present.
• In the return parameters if there are errors in the postings then the erros can be shown in the report .
• Individual document postings are also possible which was happening as a session in the case of the above BDC Fm.
• Below is the sample code with which shows program logic to post CO-PA documents using BAPI ‘BAPI_COPAACTUALS_POSTCOSTDATA’.

f_dat-record_id  = w_recno.
f_dat-fieldname = 'WWTP'.
f_dat-value     = w_bukrs.
append f_dat to t_dat.

clear f_dat.
f_dat-record_id  = w_recno.
f_dat-fieldname = 'WWACT'.
f_dat-value     = <fs_final>-wwact.
append f_dat to t_dat.


clear f_dat.
f_dat-record_id  = w_recno.
f_dat-fieldname = 'WWAT'.
f_dat-value     = <fs_final>-wwat.
append f_dat to t_dat.

clear f_dat.
f_dat-record_id  = w_recno.
f_dat-fieldname = 'VRGAR'.
f_dat-value     = 'J'.
append f_dat to t_dat.

clear: f_field.

f_field-fieldname = 'WWTP'.

append f_field to i_field.

clear: f_field.

f_field-fieldname = 'WWACT'.

append f_field to i_field.

clear: f_field.

f_field-fieldname = 'WWAT'.

append f_field to i_field.

clear: f_field.

f_field-fieldname = 'VRGAR'.

append f_field to i_field.

Call function 'BAPI_COPAACTUALS_POSTCOSTDATA'
exporting
operatingconcern = i_erkrs
testrun          = i_testrun
tables
inputdata        = t_dat
fieldlist        = t_field
return           = t_return.

If the posting is successful

if sy-subrc is  initial  .

call function 'BAPI_TRANSACTION_COMMIT'

exporting
wait = 'X'.

                             Endif.

• Use the below enhancement to fetch the document number from each posting :
• Before calling the BAPI 'BAPI_COPAACTUALS_POSTCOSTDATA' write the below code.

• Inside the FM RKE_SERVE_ACT_DOC_NUMBER write the below code and fetch the document number as mentioned below :

• So after the posting of the each document number we can fetch the document numbers if the posting is successful which makes life easier for the reporting as shown in the below screen shot.

• For more details on the BAPI read the below documentation :

SAP standard Report for testing the above BAPI:

• SAP has provided a standard program for the COPA_BAPI_TEST through which the postings can be tested as done in the KE21 report.
• Below are the steps for which this BAPI has to be tested.When you enter the BAPI it will have an option to enter the operating concern and do the postings based on either Costing-based or account-based.
• 
  

• Then it will provide various option through which posting can be done as done in case of KE21.

• The same can be first tested which the above BAPI and can be copied and customized for further custom requirements.

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

You set the option "Transfer days" in transaction OB82 but this is not being considered when running Item Interest Calculation (program RFINTITAR).

This is because Transfer days are only deducted for incoming payments. If you do not select them (by using dynamic selections) or when the clearing document is not an incoming payment, transfer days are not deducted.

When you select only invoices and clearing items are not selected, the program cannot determine, whether this is a payment or not or take the document date into account.
When no clearing item is selected, the interests for the invoices are calculated till the clearing date.

For considering the transfer days, you can also use BADI FI_INT_CUS01  in method INT_CHANGE_ITEMS.

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.

Dear All

As per the guidelines from Central Government, The levy of Swachh Bharath Cess (SBC) as provided under section 119 of the Finance Act, 2015 will become effective from appointed date i.e 15.11.2015 on all taxable services at 0.5% of the value of the taxable services. Effectively the new rate of service tax would be 14.5%. Introduction of this cess was seen as precursor to introduction of GST.  

                                                                                                                                       - Notification No 21/2015 and 22/2015 Dated 06.11.2015

Key Points.

1.     The SBC is leviable on value of all taxable services.

2.     SBC is calculated on Value of taxable service not on service tax amount.

3.     Needs to be charged seperately and needs to be accounted seperately.

4.     Swatch Bharath Cess is applicable only on Services not on manufacture of Goods.

5.     No info on CENVAT credit as of now.

Configuration Steps

For Input Tax 

1. Creation of Processing Key (OBCN)
2. Creation of Condition Type (OBQ1)
3. Pricing Procedure changes as per new Process Key and Condition Type. (SPRO-->FA-->FA Global settings-->Tax on sales/purchases-->Basic settings-->Check and change settings for Tax processing.)
4. Creation of New G/L account(FS01).
5. Assigning G/L account for relavent tax code (OB40).
6. Maintaining Condition Record of 0.5% in FV11 or FTXP.

For OutputTax 

1. Create New Condition in V/06.
2. Creation of Account Keys (SPRO-->Sales and Distribution-->Basic functions-->Account assignment/Costing-->Revenue account determination-->Define and assign account keys).
3. Assign SBC COndition Type in Pricing using V/08.
4. Maintain Condition Record of 0.5% in VK11.
5. Create G/L accounts.
6. Assign G/L accounts for Account keys in VKOA.

Hope this info is useful.

Thanks

Siva

Payment order is  a Standard SAP tools used in payment process .. its firstly assign a payment order number against the open item paid with no payment entry generated then when processing bank reconciliation if the payment order appear in bank statement the system generates the payment entry and close the open item.. assignment of payment order number is preventing from duplicate payment ..

The configuration steps is:

T-code: OT84

          - ( Create account symbols) Y12 “Payment Order”

• (Assign Accounts to Account Symbol ) assign Y12 to GL Account ++++++ as below

• (Create Keys for Posting Rules) create a Keys for posting rule Y12

• (Define posting rule)  define a posting rule like below

Posting Area 2 “Sub ledger posting “

Document Type: KZ

Posting Type : 7 “clear Debit Sub ledger account

• T-Code FBZP “ Pmnt method in country” in posting details section choose Payment order only

• T-code OT52 create manual bank statement posting rule

Interpretation Algorithm : 29 “Payment order”

• T-code: OT43 Define Variant for Manual bank Statement

You have to add the payment order to variant

• While Run F110 , SAP will create payment order Number for the selected invoice to be paid
• You can display the payment order created from F110

• When Run FF67 .. you have to enter payment order Number

• SAP will create the below entry and clear the open item

Note that the payment order will not appear in FBL*N report due to standard SAP behavior .. you may refer the below link to insert the  payment order number in FBL*N report

How to insert Payment Order in FBL1N or FBL5N

Regards

Mahmoud EL Nady

Introduction:

‘BAPI_COPAACTUALS_POSTCOSTDATA’is a Standard SAP BAPI provided to post COPA documents in the system. This BAPI is ideal to post CO-PA documents through ABAP programs by providing all requisite information as input.

As-Is situation:

• Currently SAP is using the below mentioned function module to execute the KE21 transaction for posting CO-PA documents.

call function 'RKE_CREATE_BATCH_INPUT'
exporting
erkrs       = p_erkrs
group       = p_sesion
user        = sy-uname
tables
ep_tab      = it_batchinput
fieldtab    = it_dbtable
exceptions
no_ep_found = 1
others      = 2.

• Once the above sessions are created then run the below program

submit rsbdcsub exporting list to memory
with bis      = sy-datum
with mappe    = p_sesion
with von      = sy-datum
with z_verarb = true
and return.

• The above FM creates a BDC and creates the session for which it will be run from SM35 Transactions.

Cons of using the FM 'RKE_CREATE_BATCH_INPUT'

• In case of any errors the entire session has to be reprocessed.
• Also time taken to create the session and the run the session in SM35 is tedious job.
• No track of the Document number in the output display is possible if the posting is done through the standard reporting.
• Many performance impacts are possible as we are using the BDC recording.

Usage of the BAPI ‘BAPI_COPAACTUALS_POSTCOSTDATA’:

• The mentioned FM can be replaced with the BAPI

  call function 'BAPI_COPAACTUALS_POSTCOSTDATA'
      exporting
      operatingconcern = i_erkrs
      testrun          = i_testrun
      tables
      inputdata        = t_dat
      fieldlist        = t_field
      return           = t_return.

The above BAPI provides the below advantages for postings :

• Test Mode functionality for which it will identify if there are any errors which are present.
• In the return parameters if there are errors in the postings then the erros can be shown in the report .
• Individual document postings are also possible which was happening as a session in the case of the above BDC Fm.
• Below is the sample code with which shows program logic to post CO-PA documents using BAPI ‘BAPI_COPAACTUALS_POSTCOSTDATA’.

f_dat-record_id  = w_recno.
f_dat-fieldname = 'WWTP'.
f_dat-value     = w_bukrs.
append f_dat to t_dat.

clear f_dat.
f_dat-record_id  = w_recno.
f_dat-fieldname = 'WWACT'.
f_dat-value     = <fs_final>-wwact.
append f_dat to t_dat.


clear f_dat.
f_dat-record_id  = w_recno.
f_dat-fieldname = 'WWAT'.
f_dat-value     = <fs_final>-wwat.
append f_dat to t_dat.

clear f_dat.
f_dat-record_id  = w_recno.
f_dat-fieldname = 'VRGAR'.
f_dat-value     = 'J'.
append f_dat to t_dat.

clear: f_field.

f_field-fieldname = 'WWTP'.

append f_field to i_field.

clear: f_field.

f_field-fieldname = 'WWACT'.

append f_field to i_field.

clear: f_field.

f_field-fieldname = 'WWAT'.

append f_field to i_field.

clear: f_field.

f_field-fieldname = 'VRGAR'.

append f_field to i_field.

Call function 'BAPI_COPAACTUALS_POSTCOSTDATA'
exporting
operatingconcern = i_erkrs
testrun          = i_testrun
tables
inputdata        = t_dat
fieldlist        = t_field
return           = t_return.

If the posting is successful

if sy-subrc is  initial  .

call function 'BAPI_TRANSACTION_COMMIT'

exporting
wait = 'X'.

                             Endif.

• Use the below enhancement to fetch the document number from each posting :
• Before calling the BAPI 'BAPI_COPAACTUALS_POSTCOSTDATA' write the below code.

• Inside the FM RKE_SERVE_ACT_DOC_NUMBER write the below code and fetch the document number as mentioned below :

• So after the posting of the each document number we can fetch the document numbers if the posting is successful which makes life easier for the reporting as shown in the below screen shot.

• For more details on the BAPI read the below documentation :

SAP standard Report for testing the above BAPI:

• SAP has provided a standard program for the COPA_BAPI_TEST through which the postings can be tested as done in the KE21 report.
• Below are the steps for which this BAPI has to be tested.When you enter the BAPI it will have an option to enter the operating concern and do the postings based on either Costing-based or account-based.
• 
  

• Then it will provide various option through which posting can be done as done in case of KE21.

• The same can be first tested which the above BAPI and can be copied and customized for further custom requirements.

Hi All

The below article will explain one of the approaches through which Inventory can be valued on FIFO basis in SAP -

We have two approaches to present our Inventory on FIFO basis -

1. Batch Input Method - A batch capturing the Receipt Value and the Quantity for every GR is maintained in the system. At the time of Goods Issue, the system will fetch the value from the batches in the ascending order.
2. Balance Sheet Valuation Method - In this approach, the goods are valued at the Moving Average Price throughout the period and at the Period-end date, an adjustment entry is posted to bring the inventory at the FIFO method.

I will discuss the configuration steps of Balance Sheet Valuation Method here.

1.     Activating FIFO Valuation

• Menu Path: SPRO>IMG> Material Management> Valuation and Account Assignment> Balance Sheet Valuation Procedures Configure LIFO/FIFO Methods> General Information> Activate/Deactivate LIFO/FIFO Valuation (Tcode - OMWE)

2.     Defining Valuation Levels

• SPRO>IMG> Material Management> Valuation and Account Assignment> Balance Sheet Valuation Procedures Configure LIFO/FIFO Methods> General Information> Define LIFO/FIFO Valuation Levels (Tcode - OMWL)
• This is an important step because we can set valuation level either at Valuation Area or Company Code level. Once saved and entries posted for valuation, changing this will require changing database and a program needs to be called up to pursue that.

3.     Define FIFO Relevant Movement Types

• SPRO>IMG> Material Management> Valuation and Account Assignment> Balance Sheet Valuation Procedures Configure LIFO/FIFO Methods> General Information> Define LIFO/FIFO Relevant Movement Types (T.Code - OMW4)
• This is another step which will define the valuation. We have to define the FIFO relevant Movement Types which can be used for Inventory Value calculation. You may check SAP Note # 167330 - Relevant receipts for LIFO/FIFO valuation to select relevant movement types for FIFO.

4.     Define FIFO Methods

• SPRO>IMG> Material Management> Valuation and Account Assignment> Balance Sheet Valuation Procedures Configure LIFO/FIFO Methods> General Information> Define LIFO/FIFO Methods. (T.Code - OMWP)
• The method can be copied from any of the standard methods or can be created afresh.
  • Method - 6 digit alphanumeric identifier for the method.
  • Sample - SAP provided 6 samples as shown below. 01 is only to be used for FIFO. Rest others are for LIFO.
  • Single Receipts indicator - This indicator will identify if you allow the system to value on each inward movement or not. If this is unchecked, then system will pick collective monthly movements.
  • Quantity Comparison - This field will identify the comparison inventory value with which SAP will check the FIFO value and show/post the variance. It has four options provided by SAP -

    • VOM - Previous Month - If this option is assigned to a FIFO Method, system will check the FIFO value calculated against book value of material as on last date of the previous month (MM Period). For e.g. If the previous period is October and current period is November, then System will check the FIFO value calculated (say $100) with the Material Book Value as on October 31 (say $95), and display/post the variance of $ 5.

    • VVM - Month before Last - Using this option means System will check the FIFO value calculated ($100) with the Material Book Value as on September 30 (say $97), and display/post the variance of $ 3.

    • GJE - Previous Year - Using this option means System will check the FIFO value calculated ($100) with the Material Book Value as on October 31 last year (say $90), and display/post the variance of $ 10.

    • CUR - Current - Using this option means System will check the FIFO value calculated ($100) with the Material Book Value as on FIFO run date (say $99), and display/post the variance of $ 1.

5.     Configure FIFO Valuation Areas (Defining Base Year)

• SPRO>IMG> Material Management> Valuation and Account Assignment> Balance Sheet Valuation Procedures Configure LIFO/FIFO Methods> FIFO> Configure FIFO Valuation Areas

With the above five steps, configuration is complete to allow system to run Balance Sheet Inventory Valuation on FIFO Basis.

Now, from end-user point of view, three transaction codes needs to be executed to complete the FIFO run during Month-end -

1.     MRF4 - FIFO Valuation: Flag Materials -

• Logistics> Materials Management> Valuation> Balance Sheet Valuation> FIFO Valuation> Prepare> Select Materials
• Executing this transaction code will flag the materials for getting picked in FIFO run. User can restrict the run for specific materials/company codes/plants etc. Material Codes which are not flagged for FIFO will not be considered for FIFO Valuation Run.

Note - Make sure to tick the Update "Material Master and FIFO Index Table" option. Without ticking this, nothing will happen.

2.     MRF3 - FIFO Valuation: Create Document Extract -

• Logistics> Materials Management> Valuation> Balance Sheet Valuation> FIFO Valuation> Prepare> Create Document Extract
• This step will allow system to select the transactions to be considered for FIFO Valuation. This selection is based on the FIFO method defined (OMWP)(Single/Monthly receipts tick) and the movement types defined as FIFO relevant (OMW4)
• The output will show the Movements in the materials included/excluded while drafting the document extract for FIFO run.

Note - Ensure ticking Update Receipt Data. Otherwise nothing will get selected for FIFO run.

3.     MRF1 - Execute FIFO Valuation -

• This is the main step where user can select -
  • Whether any financial postings should be made or only report display is needed.
  • Lowest Value Principle needs to be considered or not.
  • FIFO Price tables to be updated or not.
  • Material Master data to be updated with the FIFO price or not.
• These above decisions are purely business requirement based.
• The output of this step will display the material wise variance (Book Value and Calculated FIFO Value) and GL Account wise variance as well.

This concludes the entire FIFO Valuation Run which can help you revalue the inventory on FIFO Basis in the Financial Statements without touching the MM module. Further, it can be put to use for displaying the impact of change in accounting policies wherein a shift from FIFO to MAP is made by any organisation.

Feel free to provide your ratings/comments/remarks for improvement of this document.

Regards

Arjun Malviya

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.

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

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.

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

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.