This document explains the posting of a parked document, how to trace the history of deleted parked documents in SAP and number of ways to trace the history of deleted parked documents in a step by step manner. Even a beginner to SAP can easily understand this concept. All the possible ways have been discussed below with the help of an example. (A & B parts are meant for beginners of SAP as like me who doesn't have proper idea on this concept)

A. Basics

A.1. Parked Document: -You can park invoices or credit memos. This means that you enter the invoice data or credit memo data in the system and save it in a document, but the system does not post this invoice initially. You can use document parking to enter and store (park) incomplete documents in the SAP System without carrying out extensive entry checks. Parked documents can be completed, checked and then posted at a later date - if necessary by a different data entry clerk.

A.2. Advantages of posting a parked document: -The advantage of parking documents is that you can evaluate the data in the documents online for reporting purposes from the moment they are parked, rather than having to wait until they have been completed and posted. For example, amounts from parked invoices can be used for the advance return for tax on sales and purchases. Using payment requests, parked invoices can be paid punctually and without loss of discount.

B. Pre- requisites to trace the deleted parked document

B.1. Post one Parked document: - You can park invoices (FB60/ FV60) or credit memos (FB65 /FV65) as follows.

1. From the Accounts Receivable, Accounts Payable or General Ledger menu, chooseDocument Entry→ Park Invoice/ Park Credit Memo.

2. Enter the document header and line item data.

3. To save the parked document, Choose Document → Park or press the Park I con or Press F8.

You receive a message with the document number. These document numbers are assigned in the same way as the standard posted document entry function.

E.g.:- I am posting one parked vendor invoice through FB60. And later I have deleted this parked document through FBV2.

FB60:- Post Vendor Invoice

B.2. Delete posted parked document:-

You can delete a parked document as follows:

1. From the Accounts Receivable, Accounts Payable or General Ledger menu, choose

Document → Parked documents → Post/Delete.

2. If you know the document number, please inputs the company code, document number and fiscal year details and press ENTER.

If you do not know the document number, or if you want to delete more than one document, then go to Document → choose List. You can access the same tab by clicking the Document list I con or else press F5.On the next selection screen, enter the appropriate parameters i.e. document number, company code and fiscal year etc. After executing this screen then the system generates a list containing the documents that match these criteria.

3. Select the required document(s) and then choose Document → Delete.

You cannot reuse the number of a document that was deleted. Just go to FBV2 or FBV0 in order to delete the parked document

Please enter the following fields mandatorily as given below.

     1. Company code: -The Company code is an organizational unit within financial accounting. Independent accounting unit; in most cases is a legal entity. You can prepare a balance sheet and income statement for each company code. Several company codes can be set up to manage the accounts of independent companies simultaneously.

     2. Document Number:- The document number is a key the system uses to access the accounting document. This document number is unique per company code and fiscal year. When entering an accounting document, you can specify the number either manually or it can be determined the system from a pre-defined area i.e. number ranges. The relevant area of the document numbers i.e. number range is determined in each company code per document type.

     3. Fiscal Year: - The fiscal period for which this transaction is relevant.

Click ENTER then the following screen will appears

Go to Document tab -> Click Delete Parked Document option.

Then the following Pop-up will appear.

Click Yes. Then you will get a message that the requested parked document got deleted.

FB03 - Display document: – You can able to view this parked document which got deleted through FB03 t code. Please give these mandatory fields i.e. company code, document number & fiscal year. Click Enter then the following screen will appear. Please make note that Parked document which was deleted in Doc type column which is highlighted   as shown below.

Here document is displayed in list mode.

Go to Menu -> Click back button in order to get the overview screen as shown below

After executing the screen please click document header i conor press F5

Then you can find the details like document type, doc. header text, document date, posting date, ref. key, posing period, user name who got posted this doc., t code used to post a parked document and doc. status as Z – Parked document which was deleted.

C. No. of ways to trace the deleted Parked document: - You can able to trace the details of the deleted parked document either t codes or tables total in 5 ways.

C.1. FBV5 - Document Changes of Parked Document: - This FBV5 transaction will allow the user to view the changes in a parked document. The user ID of the individual making the change, date of the change and time of the change can also be viewed. Please enter the company code, document number, Fiscal year and from change date. If you know the changed date exactly so please inputs that date else give probable date.

In the below given screen I have given the changed date as 09/26/2013 (MM/DD/YYY) else give like probable date as 08/01/2013.

Click ENTER

And then please select the selected field and then click Choose button

Then the following pop-up will appear.

Click first item in the above as selected below.

Then the following pop- up will appear – It will show the details like date of deletion of parked document, user name that was deleted this document and parked document no.

You may select a line item and just double click on it to get the detail of the change. Then the following screen will appear which contains the details like date of deletion of parked doc., time of deletion, user name who got deleted this parked doc. as highlighted below.

The user id is defaulted for auditing purposes. To fix the responsibility of the user who got deleted this parked document.

Click to close the detail screen and return to the previous screen. Click the second line item.

Click Technical names on icon then this pop- up will appear which contains the technical table details which captures this data. You can able to track this technical information like VBKPF and VBSEG tables details in CDHDR & CDPOS Tables also.

Then the following pop - up will appear – It will show the date of deletion of parked document, user name who was deleted this document and document no.

Click or press ‘Shift+F3’. You have completed this transaction successfully.

Note: - But parked documents deleted are physically deleted in table VBKPF. As a consequence with deletion of the preliminary posted doc is physically deleted in the table VBKPF so it is not displayed.

I am explaining the balance 4 ways in my next blog Part-II. Because I dont want to put too much information on this blog.By keeping an eye on readers point of view, i am continuing this concept in the next blog.

Here is Part-II

http://scn.sap.com/docs/DOC-48772

As a first step to SCN i am contributing this document from my end.I am requesting you all to read this blog and provide your valuable feed back along with the rating.

Thanks & Regards,

Lakshmi S

This blog is a continuation to the earlier blog "How to Trace the History of Deleted Parked Documents : Part - I"

http://scn.sap.com/docs/DOC-48771

C.2. S_ALR_87012293 - Display of Changed Documents: - This S_ALR_87012293 standard report provides a list of the document changes. And it doesn’t tell anything about the vendor or customer pertaining to which the report caters to and the value of document also. Please give the following details.

Document Type: - Parked documents

General selections:-

          Mandatory fields: - Company code, document number & Fiscal years

          Optional Fields: - Changed on & Changed by

Receiving Co. code – Useful only for Cross- CC transactions

Further Selections: - If you are aware of the data exactly so give the data here else just click the document header data, line item data.

Click Execute Icon else Press F8.

Then the following screen will appear which contains the details of co. code, entry date, entered on, doc. no., fiscal year, user name and line items got deleted.

C.3. BKPF Table- Accounting Doc Header: - This BKPF table stores data at accounting document header level. With the help of this table we can easily trace the no. of documents posted for a company code in period wise in a year or whole documents in a fiscal year. Doc. header text, date of posing, doc. status, reversal doc. no, reversal date and transaction code used to post the document, user id who got posted this document.

Go to SE16 t code and give this table and press Enter then the following screen will appear. Please give the following fields as stated below.

Mandatory fields: - Company code, document number & Fiscal years

Optional Fields: - Document type, document date, posting date and period

Here in our e.g. I am aware of the exact details of posting date of parked document, doc. Type and period so I am giving all these details.

Click Execute Icon else Press F8.

Just double click the line item then the following screen will appear.

Here please observe the document status as Z – Parked document which was deleted

C.4. CDHDR Table - Change document header: - CDHDR table is a header table to store change documents and it is a transparent table. So you cannot join CDHDR and CDPOS tables directly. Generally, old change documents from these tables are always archived for better performance of inserting data. Go to SE16 t code and give this table and press Enter then the following screen will appear. Please give the following fields as stated below.

Mandatory Fields:-

Change doc. object – BELEGV (Accounting Doc). It is changing for MM, SD and FI areas. Please find the details as given below.

Objects Value – You can get this data through FBV5 t code as highlighted below.

Optional Fields:-

Date – Date of deletion of parked document else give probable date like give this as 08/01/2013.Here in our example I just gave the details which I was known very clear.

Click Execute I con or press F8

Click the line item in order to view the details (i.e. User name who got deleted this parked document, date of deletion & T code used for deletion of parked document) in a detailed manner.

C.5. CDPOS Table - Change document items: - CDPOS table has the information for the positions of the object and it stores data at line item level. It is a cluster table.

Go to SE16 t code and give this table and press Enter then the following screen will appear. Please give the mandatory fields like Change Doc. object & Object fields as shown below.

Click Execute I con or press F8.

We can trace the details by any one of the line item.Then double click on the first line item in order to view the details in a detailed manner.

After executing the screen you can observe the Change ID- D i.e. Deleted as highlighted in the below given screenshot.

Then double click on the second line item in order to view the details in a detailed manner.

After executing the screen you can observe the Change ID- D i.e. Deleted as highlighted in the below given screenshot

Hope this blog helps to give better understanding on Tracing the history of deleted parked documents.

Your valuable feed back along with the rating on this blog is most welcome

Thanks & Regards,

Lakshmi S

SAP FI Dunning Procedure customization and Functionality

1. I. INTRODUCTION

Purpose:

When the customer misses the payment for the outstanding invoice within specified payment due date. The dunning letter is generated via sap program and send at customer address for reminding the customer outstanding payment

Requirement:

The dunning system enables to trace liable customers who have not paid their open invoices within a given time span. It enables you to handle the process from, for example, sending a reminder to customers of their outstanding payments through to referring such customers to collections agencies.

The dunning system covers the following documents:

1. 1. Open A/R invoices, including invoices that are partially credited or partially paid
2. 2. Invoices that include installments
3. 3. A/R credit memos
4. 4. Incoming payments that are not based on invoices

Terminology in SAP

Dunning procedure
The dunning procedure controls how dunning is carried out by the system. You can define as many dunning procedures as you like.

Dunning level
The dunning levels are calculated based on the number of days open items are in arrears. You can also have the system calculate the dunning levels based on the dunning amount or a percentage paid (sales-related dunning level determination). Define print parameters.
You can determine more than one dunning level per dunning procedure.

Dunning area
A dunning area is an organizational unit within a company code used for the dunning process.
A dunning area can be a division or a sales organization. You assign a dunning area to an open item when making a posting. You can dun items separately by dunning area. Example South, East, West , North regions

Dunning Key

Dunning key controls the dunning levels

Customization for Dunning

1.       Create Dunning Keys

2.       Dunning Area

3.       Define Block reason for Dunning Notices

4.       Define Dunning Procedures

·         Create Dunning Interval in days to Dunning Procedures

·         Define  Dunning Levels to Dunning Procedures

·         Define  Dunning Charges to Dunning Procedures

·         Define Minimum Amounts to Dunning Procedures

·         Assign  Dunning Texts and forms  to Dunning Procedures

·         Create Smart forms or Script forms

·         Assign smart forms to dunning procedure

·         Assign Special indicator to Dunning Procedures

5.       Assign Company Code to Dunning Procedures

6.       Assign Sort Fields to Dunning Procedures

7.       Create Accounting clerk

8.       Assign dunning program role for user

9.       Activate the dunning via E-mail (To receive letter by mail)

10.    Assign dunning procedure and dunning area in customer master data

11.    Define interest calculation (if calculation indicator required)

12.    Execute dunning run for over due items F150

Create Dunning Keys: Path: IMG > Financial Accounting (New) > Account Receivable and Account Payable > Business Transactions > Dunning > Basic Setting for Dunning > Define Dunning Keys T. code: OB17

Create Dunning Area T.Code OB61

Block reason for Dunning Notices Path: IMG > Financial Accounting (New) > Account Receivable and Account Payable > Business Transactions > Dunning > Basic Setting for Dunning > Define Dunning Block Reasons T. code: OB18

Define Dunning Procedures Path: IMG > Financial Accounting (New) > Account Receivable and Account Payable > Business Transactions > Dunning > Dunning Procedure > Define Dunning Procedure FBMP

Here fill in the required details as par the requirement.

Dunning interval in Days– It is the minimum gap in number of days between consecutive dunning levels.

Number of dunning levels - Maximum of 9 dunning levels could be defined in the dunning procedure. Depending on the requirement dunning levels could be defined and dunning is restricted to the maximum  dunning level assigned in the dunning procedure.

Total due items from dunning level– It is the dunning level from which all the due items in an account needs to be totaled.

1. Min. days in arrears (acct)– Minimum days in account after which a dunning notice will be sent.

Line item grace periods– These are the number of days of grace added for doing first dunning.

Interest indicator– Calculation of dunning Interest. This indicator is used for calculating dunning interest only if interest indicator is not mentioned in the Customer Master. If interest indicator is mentioned in the Customer Master than that gets preference over this Interest indicator for calculation of Interest in dunning.

Public holiday calendar ID– It is a 2 character identifier for identifying public holiday calendar to ensure that the overdue items are not considered as due if the amount falls overdue on a weekend or public holiday.

Standard Transaction dunning– If this indicator is set, then only standard transactions are included when using this dunning procedure and not the special G/L transactions.

Dun special G/L transactions– If Special G/L transactions along with standard transactions needs to be included in the dunning procedure, then this indicator is used.

Create Dunning Interval in days to Dunning Procedures

Define  Dunning Levels to Dunning Procedures

Check the checkbox against the dunning level if interest is required to be calculated for that particular dunning notice.

Number of days specified in Payment deadline is the number of days added to the issue date of the payment run to intimate the customer/vendor about the timelines for honoring the payment. Payment deadlines can be added against each level for the payment of overdue items in the dunning notice. The number entered in this field is added to the date of issue of the dunning run

Define  Dunning Charges to Dunning Procedures

Dunning charge as per the dunning level. This is like an administration charge to dun the customer

Dunning charges can be either a fixed amount or a percentage of the dunning amount.

A minimum amount for the dunning charges can be set.

Define Minimum Amounts to Dunning Procedures

Define minimum amount or percentage of the overdue items to reach a dunning level.

Minimum amount to be reached in order to calculate interest per dunning level.

Assign  Dunning Texts and forms  to Dunning Procedures

For inserting dunning forms, click Dunning Texts and assign the required forms for the dunning text with reference to dunning Level.

Create Smart forms or Script forms

Standard SAP has provided standard smart form F150_DUNN_SF and SAP script F150_DUNN_01. For custom requirement these forms can be copied and modified as per requirement. There are advantages of using smart form over the SAP script; there is more control on managing contents of the dunning letter. For example if overdue items needs to be displayed grouped as per dunning level, Smart form is the best way.

The dunning process will be configured as per the business requirements. Once the dunning process configuration is completed, below are the steps to assign smart form to Dunning program.

Forms are three type : 1. Smart 2. Script and 3. Adobe

Creating Smart form by copying ZF150_DUNN_SF T.Code SMARTFORMS

Assign smart form processing Function Module

1. T.Code FIBF

1. T.Code BF31

Set the FM FI_PRINT_DUNNING_NOTICE_SMARTF for Business Transaction Event (BTE) "1720" with application indicator FI-FI

Assign Smart form for normal dunning procedure

Financial Accounting (New) -> Accounts Receivable And Accounts Payable  -> Business Transactions-> Dunning -> Printout -> Assign Dunning Forms

Script forms in T.Code SE71

Assigned the samrt forms in dunning text

Assign Company Code to Dunning Procedures

We have assigned company code with reference to Dunning Level and not by Dunning area

Separate dunning notice for each dunning level?

An entry in this field means that a separate dunning notice is created within an account for every dunning level determined.

Use: You establish this independent of company code. In contrast to standard dunning in which all items at all dunning levels are dunned with one dunning notice and the highest occurring dunning level determines the dunning text, when dunning by dunning level a separate dunning notice is produced per dunning level with a different accompanying text in each case. The customer/vendor can then receive several dunning notices from one dunning run.

Assign Special indicator to Dunning Procedures

Assigned Special Indicator Reserve for Bad Debt to dunning Procedure

We can take down payments into consideration during the dunning run. When defining the dunning procedure we must specify which down payment types are included in the dunning run. To do this, we specify the special G/L indicators for these down payment types. The dunning program treats a down payment received as a credit memo and reduces the receivables by the amount of the down payment. Since down payments are only included in the dunning run in exceptional cases, each down payment item contains a field for the dunning block. The system sets this block automatically. The down payment also contains a due date field, which the system automatically fills with the document date. You can change these fields with the document change function

Create Accounting clerk

OB05 OR OBVU Dunning clerk

Assign dunning program role for user

Dunning Program authorization assigned in User profile T.Code SU01

Updated dunning clerk mail id

Activate the dunning via E-mail (To receive letter by mail)

Dunning letter output can be in two forms.

1)        Email

2)        Manual Print out

If email id is updated in customer/vendor master data then the dunning letter is sent via email .If email id is not updated in the master data then the letter is to be manually printed and send. One can find it in the spool

1. T.Code SPO1

To received dunning forms through mail , Check in functional module table dunning via email active or not

Assign dunning procedure and dunning area in customer master data

Dunning clerk

Identification code for the accounting clerk dealing with dunning letters Using this identification code, the accounting clerk whose name is printed on the dunning letters is determined. Note if this field is not filled, then the entry from the Accounting clerk field is used.

Define interest calculation (if calculation indicator required)

Intercalation below is transaction code for customization

OB82- Prepare Interest on arrears calculation

OBV1- Prepare Interest on arrears calculation

OB46- Interest Calculation Types

OBAA- Prepare Account Balance Interest Calculation

OBAC- Reference Interest Rate Calculation

OB81- Define Time Based Terms

OB83-Interest Values                       

OBY2- Automatic Account Assignment Of Interest a

Execute dunning run for over due items F150

Below is the example of overdue invoice which we completed three dunning levels.

First dunning

Check customer master data

Second Dunning

Third Dunning

Dunning Form generated as given below example format.

Dunning Table

   Mhnk                  Dunning data (account entries)

   T001                    Company code information

   knb5                   Customer master dunning data

   lfb5                     Vendor master dunning data

   t047                    Company Code Dunning Control

   t047c                  Dunning charges

   t047i                   Standard texts for dunning notices

   t056z                  Interest Rates

   f150d                  Work fields for SAPF150D

   fsabe                  Accounting Clerk Address Data

   adrnr                  Address number

   adrs                    Address details

   t047b                  Dunning level control

  Mhnd                  Dunning data

Email Sending Functionality for Different Business Process in Sap

Nov, 2013

Introduction

Every Business Process in SAP Follow different communication types to communicate with its Business partners like Print and send via post, Fax, and Email (Internet).Several E-mail communications need to be sent to Vendors & Customers who are the business partners for the organization which contains several Business Processes like Payment Advice, Dunning forms and PO’s etc., with PDF and Excel as attachment, which is a very eco-friendly way. Presently many are using the process of taking a print out and sending it through the post. This Process has lot of paper wastage. So instead of this we can send a mail which saves lot of paper wastage .This process enables the Go green Initiative and reduces lot of manual effort. With the recent releases in SAP all the Business process are enhanced with Email sending functionality.

Introduction to Email Processes

Every Standard FI process like Dunning and Payment and collection advice has a default way of sending there notices to the customer or vendor by post. Sending a mail is not a standard SAP functionality; in order to achieve this nonstandard Functionality we have BTE.  This is an enhancement technique (Open FI) that was developed for Financial Accounting component. This functionality is primarily used in FI in the areas of dunning, Payment advice Customer and Vendor Statement etc. Each of them has their own Function modules which will not interfere with each other.

           Each of these has a BTE’s enabled to fill the FINNA-NACHA structure to determine whether the output should be sent as fax, print via post or email, i.e., if FINAA-NACHA = 1 - print via post and FINAA-NACHA = ‘I’ its email and if its ‘2’ FAX.

This Document contains how this mail functionality can be achieved by using the BTE’s for Different applications in FI.

1. Application Area: FI - Accounts payable and Accounts receivable – Dunning

     Application of the process BTE event '00001040' -

· This process BTE is useful during a dunning run when a dunning notice needs to be sent to the customer by the medium of an electronic form (EMAIL).
As a default property, the dunning notice gets printed and is sent to the customer either by scanning the copy or via 'POST'.

· This same dunning notice could be a very beneficial if it is sent by means of electronic form directly after the dunning has been carried out.

· So, to achieve this non-standard functionality we need to enhance the standard process.

      Transaction - FIBF -> Environment -> Info systems (Processes)

· Click on execute,

· Select the BTE 00001040 as it deals with the Output device/medium

· Change the Already Present function module to Z function Module.

Now, technically the BTE is ready to work as we have registered the BTE.

As a functional aspect, the following things are needed to be taken care of.

· Standard communication option - to 'EMAIL' in the 'General' Tab in customer master 'XD02/01'.

· After configuring these basic steps, the BTE is complete to trigger for dunning run for this particular customer.

     Dunning Run

· SAPF150D2-This Program can be used to execute the Dunning form by giving the Run date and identification and the logic in the FM's can be checked by placing the debugger.

· Best way is to check in the debugger,

Ø  FINAA-NACHA - For Communication Medium (I- Internet, 1-Print Out, 2-Fax)

Ø  FINAA_INTAD – Email Address to send the PDF

Ø Process the next step by confirming the 'Send to mail' dialog,

Ø If 'C_FINAA-INTAD' is left blank the system will pick from the customer master 'Clerks internet', else it will take from the value 'C_FINAA-INTAD'. This enables the PDF sending functionality which enables is standard process and the logic to send excel can be written in the above FM only. Also if you need to fill the Subject of Email use itcpo-tdtitle structure which of 50 characters. If we need to send the Body also Maintain the standard text as mentioned in the below screen shot.

NOTE: If we need to send many attachments other than PDF we have to write the code in the above FM call the common mail sending functionality. In this case first a mail will be sent with Excel or some other as attachment then the standard PDF functionality is called.

This is a very eco-friendly means of informing the customers for their over-due items.

2. Application Area: FI – Payment Advice and Collection Advice:

     Application of the process BTE event '00002040' –

This BTE is called in the standard include RFFORI06 as shown below.

· In the transaction FIBF Select the BTE 00002040 as it deals with the Output device/medium sample_process_00002040 will be assigned.

· Since this is not a standard functionality we need to enhance the FM so copy the

sample_process_00002040 into Zsample_process_00002040.

Logic in the FM

Check if customer or Vendor has Email Maintained in the Master Data. If it’s maintained then

· The structure c_finna included the internet address.

          We set the transmission medium to ‘I’ as below.

          c_finaa-nacha = 'I'.

          c_finaa-intad = l_smtp_addr(130). [The email Obtained from the master data]

·    Later the mail sending functionality can be called after the close_form as shown in the below screen shot or By OTF data and excel can be created using the tab_regup structure in the   form avis_schreiben.

3. Application Area: FI – Customer/Vendor Balance Confirmation:

     Application of the process BTE event '00002410' –

· This process BTE is useful during a Customer/Vendor Balance Confirmation form which needs to be sent to the Customer/Vendor by an electronic form (EMAIL). By default, the form is sent to the Customer/Vendor either by Fax or via 'POST'.

· But as an environmental aspect to avoid wastage of paper, the same Statement could be sent by means of electronic form directly after the Customer/Vendor Statement run has been carried out.

· So, to achieve this functionality we need to enhance the standard process.

     Transaction - FIBF -> Environment -> Info Systems (Processes)

· Click on Execute.

· Select BTE 00002410 as it deals with Determining the Output Device

· Click on Sample Function Module. The FM 'SAMPLE_PROCESS_00002410' is assigned. In order to include the mail sending functionality, Copy the Function Module into a Z Function Module and make the required changes to enable the mail sending functionality.

     Logic in the FM:

Check if the Customer or Vendor has Email Maintained in the Master Data. If it is maintained then

· The structure c_finna includes the internet address.

We set the transmission medium to ‘I’ as below.

          C_finaa-nacha = 'I'.

         C_finaa-intad = l_smtp_addr(130). [Email Obtained from the master data]

· Later the mail sending functionality can be called after the Close_form as shown in the below screen shot or By OTF data, and excel can be created using the Structure HBSIDH for Customer and HBSIKH for Vendor.

4. How to achieve Mail Functionality Technically:

Create a Common Functionality for sending mail using classes

i) For sending the subject greater than 255 characters   

· At present using the FM SO_DOCUMENT_SEND_API1 has the capability of sending only 50 characters but using the below method of the class the subject more than 255 characters.

· So cl_bcs class is used for the below purpose.

· There is also any option of changing the sender ID in case the requirement is not    to use the           

· SAP master User ID using the cl_bcs  class.

· Create the below object of type cl_bcs  and call the method  set_message_subject        

          w_send_request     TYPE REF TO cl_bcs           VALUE IS INITIAL,      
      CALL METHOD w_send_request->set_message_subject
        EXPORTING
          ip_subject = subject.

ii) For Sending Multiple Attachments like PDF and Excel

· In case multiple attachments the below method add_attachment attachment can be used by looping on the attachments obtained to this function module.

     f_ATTACHMENTS    TYPE      RMPS_T_POST_CONTENT

      w_document       TYPE REF TO cl_document_bcs  VALUE IS INITIAL,

      LOOP AT attachments INTO f_attachment.

        w_attachment_subject = f_attachment-subject.
        w_filesize = f_attachment-docsize.

· This Method will have the option to take input as method subject, filesize and
        w_document->add_attachment(
        EXPORTING
        i_attachment_type    = f_attachment-doc_type
        i_attachment_subject = w_attachment_subject
        i_attachment_size    = w_filesize
        i_att_content_text   = f_attachment-cont_text[] ).

      ENDLOOP.

    iii) For Sending Email to multiple recipients like To, BCC and CC,

· The below Logic can applied to provide cc bcc and to as like multiple receivers. The method

add_recipient   has the option to give blind_copy, Copy and recipient.

w_recipient      TYPE REF TO if_recipient_bcs VALUE IS INITIAL,

· Loop at the multiple receivers

LOOP AT receivers INTO f_receivers.

          w_recipient_mail = f_receivers-receiver .

· The below method sets them mail ID of the Receiver.
          w_recipient = cl_cam_address_bcs=>create_internet_address(
                         w_recipient_mail).

        w_send_request->add_recipient(
            EXPORTING
            i_recipient = w_recipient
            i_express = 'X'
            i_copy = f_receivers-copy
            i_blind_copy = f_receivers-blind_copy).
ENDLOOP.

Positive pay - An Overview

• What is Positive Pay?
• Positive  Pay is an automated fraud detection service offered by the US Commercial Bank.
• Positive pay is informing the bankers about the checks your  company has issued.

          How does Positive Pay work?

• For instance, ABC Company issues approximately 500 checks every Monday. After the checks are cut, ABC Company transmits to their bank, a list of the checks that are being issued (check number and dollar amount etc...). This list is imported into Bank's computer.

     Later, when the checks are presented to Bank for payment, Bank matches each check presented against ABC's previously transmitted lists. If the presented checks' numbers and amounts appear on a previously submitted list, the check is sent through for payment. If both items do not match, the check is not cleared.

• How would be the positive pay file?

           Positive pay file structure is specific to the banks. Each bank has its own format. We need to get information from the bank about their file format with details of header, record count, amounts etc., A customized program to map these fields is required. After the automatic payment run, if this program is executed, it will generate the positive pay file in the bank's required format..

• There is a standard T Code – FCHX, program RFCHK0E0 which extracts the information of checks issued from the system but the file format which it creates is different than what is required by the Bank. It also stores the file on the SAP Application server.

• RFCHKE00 program reads the data from PAYR, BNKA, T012 (House bank) and T012K (House bank Account).

How do we execute Positive Pay?

Procedure:                                                                                                                            

        Step-1:  Copy the program RFCHKE00 and create a ZRFCHKE00.

               Step-2:  Create Z T-code (Ex:-ZFCHX). We need to take the help of ABAPer to create the Positive pay file as per the format specified by the Bank.

              Step-3: After issuing the checks (Manual checks issue or through APP), we have to execute T-code ZFCHX.

               Step-4: Once the T-code ZFCHX has been executed, the program ZRFCHKE00 will extract the data in to a Positive Pay file which we have mapped      with the help of ABAPer as per the format specified by the bank.

               Step-5:  The file which has got generated in Step-4 will be stored in SAP Directories (T-code AL11) or as per the file path we specify.

              Step-6:  Positive Pay information can be transmitted to Bank through processes like FTP, EDI (IDOCs) as these are secure more sophisticated than others

SAP Business Transaction Events - Dupliacate Invoice checking

SAP business transaction events are one type of customer enhancements provided by SAP! On this post I’ll talk about how we can change the logic for duplicate vendor invoice check using SAP business transaction events!

We can access the business transaction events using FIBF

Next we have to find the process interface for duplicate invoice check! To do that, follow the following steps.

• Select the menu as stated below

• Execute the info system as stated below

• All the processes will be shown below

• Select the process 1110 and click on “Sample function module” as stated below

• Copy the sample functional module “SAMPLE_PROCESS_00001110” and create “ZSAMPLE_PROCESS_00001110”. Put the customized logic in the functional module “ZSAMPLE_PROCESS_00001110” and activate it!

• Now go back to FIBF and execute the menu as shown below

• Define a new product and activate it

• Now go back to FIBF and execute the menu as shown below

• Assign the function module “ZSAMPLE_PROCESS_00001110” to the process “1110”and the product that was defined in the earlier step.

• Now every time when a vendor invoice is being posted the invoice check will be carried out using the custom logic built into the function module “ZSAMPLE_PROCESS_00001110”. But make sure that the “double invoice check” tick has been put on the relevant vendor masters!

Regards

Vijay

Overview of Customer Fields in FI New Gl functionality

Introduction on Customer Field  

A customer field is a database table field that is created and defined by the customer. Such fields are therefore not delivered in the SAP standard system. The inclusion of customer fields has effects across the whole system (as well as across all clients in a same server) because customer fields entail repository changes.

Nevertheless, the fields contained in the standard delivery might not be sufficient to meet your needs. In such cases, you can consider using fields that you define yourself, referred to as "customer fields“.

From Release SAP ECC 5.0, you can include customer fields directly in new General Ledger Accounting, without having to implement an FI-SL solution in parallel, as was required in previous releases. Customer fields can be added to the standard set of tables in new General Ledger Accounting and can be valuated using the standard reporting tools. This may mean that customer developments (such as customer-specific reports) that were used previously then become superfluous if you have created special valuations on the basis of existing posting data.

• In Financial Accounting, you can include customer fields in the coding block. In this way, you can broaden the scope of new General Ledger Accounting by adding new customer fields and by combining such fields with the existing standard fields. This enables you to adapt the information in new General Ledger Accounting to the specific reporting requirements of your company.

                This document is focused to give a better understanding on adding the customer fields in New GL functionality and its impact to various tables and usage in terms of reporting. We will understand the process of adding customer fields in FI tables and how we can use in different business scenarios

Why Customer fields:

Business Scenario

Customer fields can be used for many purposes.

     1. In order to reduce the number of GL account count, customer field “ADD Free Info” was created to segregate single GL account for drill down reporting

Below customized table displays mapping between customer field (Add free Info) and GL account code

In expense GL line item the Customer / Vendor account(s) can be traced/ tracked against AR/AP line items.

Example: Expense line item Customer/Vendor displayed as shown below

Segment reporting in FI module

Restrictions on Using Customer Fields during Implementation:

                If you intend to use a customer field, you should definitely deploy it upon implementing (or migrating to) new General Ledger Accounting so that the documents and totals data contain this field from the beginning. It is not possible in the standard system to subsequently supplement totals data or open items with document splitting; this requires a project-specific migration solution. For more information, see SAP Note 891144.

                For the implementation of a customer field in new General Ledger Accounting, different initial situations need to be considered with regard to the migration from classic General Ledger Accounting to new General Ledger Accounting. For more information, see Migration with Customer Fields

How to configure

Customizing Customer Fields

Prerequisites:

1. a) Before you create a customer field, you must always run a data backup and proceed as per SAP guidelines mentioned above
2. b) No postings may occur at the time when the field is created and at the time of the transport to the production system.

Note that you can no longer delete a customer field from the coding block as easily (that is, not with standard means).

To avoid naming conflicts, the customer fields must have names falling within the customer namespace. For more information about customer namespaces, see SAP Note 16466 and the related notes.

The implementation flow is as follows:

1. Defining the Coding Block
2. Changing the Field Status of a Customer Field
3. Include Field in the Totals Table
4. Assigning Customer Fields to Ledgers
5. Setting up Check on Customer Fields (Optional)
6. Defining the Master Data Check

Let us understand in detail the steps being followed as shown in the respective slides

Defining the Coding Block

     I.Defining the Coding Block

When a customer field is added to the coding block, the structures CI_COBL and CI_COBL_BI (for batch input) are created or enhanced. Table BSEG, as a cluster table, is enhanced directly. Using the customer include ensures that the customer field is automatically included in other important tables.              

1. In the first step, you have to include the customer field in the coding block. You do this in the following IMG activity: Financial Accounting (New) ® Financial Accounting Global Settings (New) ® Ledgers Fields ® Customer Fields ® Edit Coding Block.

Note: This can be created with the help of ABAP technical team.

The data elements are created by ABAP technical team. Let us illustrate this with an example.

Data element ‘ZZ0001’ is created with Add Free Info as its description

Similarly the other data elements ZZ0002, ZZ0003, ZZ0004, ZZ0005 are created. Once the data element is created they need to be assigned to the Coding block setting.

The newly created data element fields are updated in the Customer Include structure. No posting transactions may be performed while including the customer field. It is recommended using the “light” (activation) mode. For this, you only need to make the following entries so that all necessary changes to the dictionary and to the tables are performed automatically in the background

Depending on system performance, this may take some time. The system outputs the result in a log. For detailed information, see the documentation on the IMG activity Edit Coding Block

     II.Changing the Field Status of a Customer Field

To be able to change and display a customer field in documents, you need to open it in the field status groups.

To change the field status groups for the G/L account, perform the IMG activity under the following path: Financial Accounting (New) ®Financial

Accounting Global Settings (New) ® Ledgers ® Fields ® Define Field Status Variants. Customer fields are located in the subgroup Additional Account Assignments. Depending on the G/L accounts that you want to use, you can open the customer field in all field status groups or just in the relevant ones.

Besides the field status groups for G/L accounts, you also have to open the field in the field status for the posting key. You do this in the following IMG activity:

Financial Accounting (New) ® Financial Accounting Global Settings (New) ® Document ® Define Posting Keys.

Since only G/L account items can have additional account assignments in the form of a customer field, only the posting keys for G/L accounts can be used here. We recommend including the customer field in the posting keys for G/L accounts as an optional field and using the field status groups for further control. It may be possible to define the customer field as a required entry field for some of the G/L accounts selected, and as an optional field for other G/L accounts. This option is particularly relevant if the customer field is substituted partially. As an alternative to specifying required entry fields in the field status, you can also use validation.

  III.Include Field in the Totals Table

To include a customer field in the standard totals table or in a customer-specific totals table, perform the following IMG activity:

Financial Accounting (New) ® Financial Accounting Global Settings (New) ® Ledgers ® Fields ® Customer Fields ® Include Fields in Totals Table.

You can include more than one field in the totals table. Note, however, that each additional field increases the data volume. Other than customer fields, you can also include standard fields in the totals table. Ensure that you reach a decision on this in good time. For more information, see Customer Field.

http://help.sap.com/saphelp_erp60_sp/helpdata/en/52/185a40aba66f13e10000000a1550b0/content.htm

For reporting, however, it is both necessary and logical to add the customer field (or even just selected customer fields) to the totals table in new General Ledger Accounting. If you work with your own totals table, note that you should always use the standard totals table FAGLFLEXT for the leading ledger. You can add customer fields to the totals table using the customer include CI_FAGLFLEX04

IV. Assigning Customer Fields to Ledgers

To update a customer field in the desired ledgers, you have to assign the field to your ledgers in the following IMG activity: Financial Accounting (New) ® Financial Accounting Global Settings (New) ® Ledgers ® Ledger ® Assign Scenarios and Customer Fields to Ledgers.

You can assign customer fields to the leading ledger as well as to non-leading ledgers. If, for example, you portray group accounting in the leading ledger and only need the customer field for local purposes, you can assign it just to the relevant non-leading ledger.

V. Setting up Check on Customer Fields (Optional)

When you have included a customer field in the coding block, you can enter any information in this field - but this data is not checked. Since a customer field is generally applied for specific structured data or a limited number of characteristic values need to be entered, we recommend that you always run a check. You have the following options for this:

Check Using a Validation

What is a validation: Validation checks whether a pre-requisite is met. If the pre requisite is not met it throws an error message

A validation can consist of up to 999 steps. You can therefore validate data against any number of Boolean statements before the data is posted. Validations are created at 3 levels via, Header level, Item level and complete document level.

A validation step contains the following statements:

You can use a validation in Financial Accounting to check the entries or the substituted field contents. This is useful if the validation rules are kept relatively simple and in a manageable number. You set up the validation by performing the following IMG activity:

Financial Accounting (New) ® Financial Accounting Global Settings (New) ® Tools ® Validation/Substitution ® Validation in Accounting Documents.

Prerequisite statement

The prerequisite statement determines whether the entered value(s) should be checked. If the prerequisite statement is false, then the value is valid and the transaction continues.

Check statement

The check statement determines whether the entered value(s) are valid. If the check statement is true, then the value is valid and the transaction continues. If the check statement is false, the system displays a message.

Call Up Point: Call up point 2 indicates that the validation is at the line item level

Set: Sets are used in many components and sub components of the SAP R/3 System (such as reporting, planning, and currency translation). Before you can begin working with these components, you must first create the sets that you want to use.

Most of us creates a Z tables and provides a maintenance view to store values which we want use for validations or some other propose in programs. However when values are in ranges or amount of load is very low then Instead of a table we can create a FI set which holds the values and also provides simple maintenance in production.

Sets simply hold a number of values for a field. The set is created to check whether the pre requisite is met or not. You define the set in the following IMG activity:

Financial Accounting (New) ® General Ledger Accounting (New) ®Tools ® Sets® Define Sets.

OR T-code GS01. After the Set is created enter the GL account against which the validation check is created

VI. Defining the Master Data Check

To perform planning and allocation in new General Ledger Accounting, you need to define a master data check for customer fields. If you use a customer-specific check table, you can use it for this purpose. You can base your entry on the existing entries delivered by SAP and copy a suitable entry to your customer field. Specify your own table as the value table and text table. You define the master data check in the following IMG activity:

Financial Accounting (New) ® Financial Accounting Global Settings (New) ® Ledgers ® Fields ® Customer Fields ® Define Master Data Check.

For more information, see

http://help.sap.com/saphelp_46c/helpdata/en/5b/d221ac43c611d182b30000e829fbfe/content.htm

Once the configurations for customer fields are completed, the fields will be ready for input in FI transactions. The customer fields will also be available for special selection for any FI report execution (refer point 3 below).

So finally we have seen what is customer fields, what is the business scenario where this customer fields can be used and the various steps of customizing.

        Few key take away:

• Customer fields should be implemented in a fresh implementation or if system is already on SAP then for migration , SAP help is required since data base level changes  are required.
• Maximum of 18 customer fields is allowed from SAP
• Customer fields are used for internal reporting purpose.
• With the help of customer fields the number of GL master data can be reduced drastically.

SAP Notes:

• 841884 - Customer fields in the Enjoy entry transactions
• 1259117 - ENJOY/NewGL: F4 help triggers dump

Thank you !!!

While creating a chart of account in SAP you need to pay attention to all the five fields in the screen.

Creation of Chart of Accounts path: - SPRO > Financial Accounting New > General Ledger Accounting New > Master Data > Preparations > Edit Chart of Accounts List

T Code: OB13

Fields used for creating chart of accounts in SAP;

Maintain Language

SAP provides option of maintaining different languages including English.

Length of G/L Account number

SAP provides you to have the length of GL account as 10. If you create a GL account with 4 digit number then system will add another 6 zeros in front of the number. To avoid the number of zeros you can restrict the length of g/l account number here. If you set your length of G/L account number as 4 then system will not add any zeros to it. For alpha numeric number system adds value to the end of the number

Example: if you define your account number as 1234 and in place of “Length of G/L Account number” you mentioned 6 then the number will be displayed as “001234”

Controlling Integration

Two options are available here;

1. Manual creation of cost element: you create manually after creation of all general ledger accounts in SAP. With this option you have an option of creating your own cost elements with you own choice.
2. Automatic Creation of Cost elements: system will create all the cost elements automatically either at the moment you execute a batch program or at the moment general ledger creations are completed.

So chose this option wisely. In all most all the companies they chose manual creation of cost element options.

Group Chart of Accounts

If you have company codes assigned within company and you want all the accounts of the company code get consolidated at a place then define a group chart of accounts and assign the same group chart of accounts here.

Blocked

If for some reason you want to block the chart of accounts for its use then use this option. Once the chart of accounts is blocked system will not allow it to use anywhere. Chart of accounts can again be unlocked by removing the flag from here.         

You can achieve this requirement through FI clearing rule(transaction code OBIA and OBIB).

For example, you want to populate same payment reference value from vendor invoice document to payment document.

Create FI Clearing Rule

Transaction Code: OBIA

Click on New Entries, enter Clearing Rule (two characters ) and Description.

Save.

Select clearing rule  and click on "Clearing Rule Fields" of Dialog structure on left hand side.

Click on New Entries, enter  Item number 1 and Field KIDNO for payment reference.

Save the entry.

Maintain Maintenance view for assigning FI clearing rules

Transaction Code: OBIB

Click on new entries and select account type (K for vendor D for customer and S for GL)& assign your clearing rule which you created through OBIA.

Now setting has been done for populating payment reference value from  invoice document to payment document for vendor.

Post incoming invoice

Transaction Code: FB60

During posting an invoice, click on payment tab and enter payment reference value.

Check Payment reference value in Vendor Line Item Report

Transaction Code: FBL1N

Post outgoing Payment

Transaction Code: F110 or F-53

Check value for payment reference for cleared and clearing item

Transaction Code: FBL1N

Overview of the Requirement

Define Financial Statement Version is one of the IMG activities that is frequently required in the daily operation and can be declared as a current setting, meaning it can be directly maintained in Production system by business users without a transport request getting created.

You can do these changes in customizing system and move the changes through the transport route to production system.

Procedure to transfer IMG activity to current setting

The current setting indicator can be maintained directly from the IMG. Place the cursor on the IMG activity and select menu option EDIT --> Display IMG activity.

to navigate to below screen.

(Alternatively you can use Transaction – SOBJ).

Select the Select the tab

Double click on the customizing object displayed on the screen shown above. This takes you to View Cluster Maintenance screen (Transaction – SOBJ)  where you can flag the current setting check box directly. (You will require a developer access key for doing this setting).

Alternatively use Transaction – SOBJ

Click on button and you get an information message

Then click on position and enter the object & type as per below screen.

This will take you to the screen from where you can select the object to be changed.

Double click on the object selected and check if the current setting indicator is ticked.

Flag the indicator and save the changes. A new workbench request will be created.

Current setting indicator after saving the transport.

Release the transport request in customizing system and import to production system.

Testing & Troubleshooting

The changes done have a dependency on the client role.

Make sure the client role is Production

Make sure the transport was released without errors and imported to production system successfully and check current settings indicator is flagged.

In production system use Transaction– FSE2 and see if the system allows you to change the Financial Statement Version.

Though the current settings indicator is flagged in production, the system displays error message TK430: Client &1 has status 'not modifiable.

To resolve this error message, maintain the message number FE 146 in customizing system and import to production system through a customizing request; which will stop the error for all users or specific user who is responsible for making changes to Financial Statement Version in production system.

To do these settings, click on Change Message Control in performance assistant or use Transaction – OBA5 to go to message maintenance settings screen.

Enter the Application Area as FE and click on new entries to add the message number 146 optionally enter a user name and select the stop message option from the list of values for Online & Batch Input fields and save the changes.

Once the message settings are imported to production system, IMG activity– Define financial statement version is available for direct changes.

You can use Transaction – FSE2 or the current setting transaction – S_ALR_87003215.

Thanks for reviewing the document. Your valuable comments and any value addition will be appreciated.

Regards

KIM Khan

Introduction

The brazil statutory and legal requirements poses certain unique requirements, the same has been covered in the document alongwith ways in which such scenarios can be attended in SAP.

FI – Organisation Structure

Business Place – Each Company code in Brazil is assigned to a Business Place which is further mapped to Plant. Creation of Business Place is mandatory as taxes are reported Business Place wise.

FI – Accounts Payable Process

Accounts Payable Process Overview

The AP process starts with GR/IR verification, in Brazil a document called Nota Fiscal is issues along with goods which contains the tax and other details. For invoices with PO, accounting document which is generated contains tax and other legal details from the Notas Fiscal. For Invoices without PO, these details have to be manually entered.

Automatic Payment Method is used for making payment to Vendors. On running the payment program a file is sent o bank for payment which is processed by bank and the payment is made. Brazil specific payment methods like Boleto, and requisite settings for the same need to be in place.

Brazil Specific Considerations

• Banking Instruction Codes and Communication with bank - Boleto Bancário; Borderô; Duplicata; Vendor Operation; SPB (Sistema de Pagamento Brasileiro).
• Payment Methods, Conditions and Types need to be set up – for payment method Boleto scanner and requisite setting needs to be in place.

FI – Withholding Taxes Classification

Witholding Tax Process Overview

On financial front, the tax laws at country and state level for Brazil are manifold.  To name a few, we have

• IPI - Federal tax on industrialized products
• ICMS - State tax on goods movements
• ISS - Service tax on city level
• PIS, Coffins, CSLL - social contributions
• IRRF, INSS - withholding taxes

SAP supports all these tax types, automatic calculation based on predefined rules which are aligned with tax laws, by setting up tax rates with integration of material management, FI tax codes, and vendor/customer master data. Few specific codes like NBM, CFOP also should be managed to ensure correct determination of tax category (product/service) and tax level (federal or state level), tax type (IPI, ICMS) and finally the rates.

Brazil Specific Considerations

• Use of specific fields on Vendor/Customer master data (tax identifications: CNPJ, CPF, State Inscription, City Inscription, Tax classification, type of business) for tax purposes.
• Setup Tax conditions, codes and rates - TAXBRA reflects new standard solution for Tax Pricing Procedure using Condition Base Technique (CBT).

FI – Accounts Receivable Process

Accounts Receivable Process Overview

On making sale a sale alongwith invoice, in Brazil a document called Nota Fiscal is issues along with goods which contains the tax and other details

Brazil Specific Considerations

• Nota Fiscal - Under Brazilian law, the NF-e is replacing the conventional, hard-copy nota fiscals with an electronic counterpart which must be digitally signed and shaped into a particular government specified XML format. We also need to set up CFOP code, and NBM code for determination of NF based on direction of goods movement, usage of materials, branch office, master data set up, and put necessary configurations for automatic NF generation.
• For AR formats to be used DME: Remittance file (arquivo remessa); confirmation file (arquivo retorno); bank statement (arquivo extrato); Febraban (Segment , P,Q,T,U); Itaú (CNAB400); Bradesco (Layout Cobrança Bradesco 400), Borderô printing (list of payments); Boleto printing (payment form)

FI – Asset Accounting Process

\

Asset Accounting Process Overview

At first the chat of depreciation needs to be set up and mapped with asset class. Asset acquisition may be with or without purchase order. Periodically depreciation run will be made to post the amount of depreciation to GL. Also in Brazil depreciation amount for tax purposes may differ and needs to be separately calculated.

.

Brazil Specific Considerations

• Country specific chart of depreciation needs to be created.
• Tax incentive on asset investments (CIAP)

This document was co-authored by SCN member varun harlalka

Overview of the Requirement

Companies using Automatic Payment Program functionality have different options to control the creation of payment medium at the time of Proposal Run.

This is basically done to stop payment advice getting created at the time of proposal run.

Option 1 - Control through security settings

The authorization objects related to F110 are F_REGU_KOA (for restrictions at account type (D, K & S) level) & F_REGU_BUK (for restrictions at company code level).

You need to check with the BASIS/SECURITY consultant, and figure out if you can restrict (exclude) activity 15 (Create Payment Medium for scheduled proposal run) with respect to above authorization objects, in the ROLE assigned to the user.

Setting the authorization for above mentioned objects at Role level will be applicable to all the users to whom role is assigned.

This option will hide the Create Payment Medium check box.

Option 2 - Default

By default the Create Payment Medium check box is blank (Un-ticked).

User has to make sure he/she does not tick the check box and leave it as it is and proceed with the proposal run.

At times users may accidentally tick the check box and payment medium gets created at the time of proposal.

Option 3 - Sequence of steps for doing F110

Follow the steps listed below while doing F110.

1. Enter parameters in parameter tab, enter required free selections (optional), select required check boxes in Additional log tab and then save without maintaining a variant against the RFFOUS* program in Printout/data medium tab. (See screen shot below)

2. Click on proposal button to schedule the proposal run.

The moment you click the proposal button, you see a pop up to schedule the proposal. (See screen shot below) You will notice the Create Payment Medium check does not appear in the pop up window.

3. Once the proposal is run you can go back to the printout/data medium tab and maintain the variant against the RFFOUS* program and save the new changes.

Once the variant is maintained and changes saved, the Check box is available and is by default unchecked without the question of checking it as checking it is not mandatory.

4. Execute rest of the steps after proposal run in F110.

The user has to make sure that a variant has been maintained in printout/ data medium tab before doing the Payment Run.

Thanks for reviewing the document. Your valuable comments and any value addition will be appreciated.

Regards

KIM Khan

1.  Introduction

Company finalizes standard cost estimates for a given period in advance. That means all costs, including raw material, in the costing run need to be considered as applicable in future date. Standard Cost Estimates Transactions CK40N and CK11N read standard cost of raw material at the time of executing Standard Cost Estimates. So we need to develop process to load future standard cost and configure product costing valuation variant to read future standard cost from accounting view.

2.  Configuration and Development

2.1  Create LSMW to load future standard cost of Raw Material

2.1.1       Use Business Object Method (BAPI)

2.1.2       Source Fields

2.1.3       Structure Relations

2.1.4       Field Mapping and Conversion Rules

2.2  Create a background job to perform mass load from a flat file

2.2.1       Use Program /SAPDMC/SAP_LSMW_INTERFACE to create a job which will need to create a variant to reference the LSMW.

2.3  Proposed configuration

2.3.1       Change Valuation Variant assigned to the costing variant

               Product Cost Controlling --> Product Cost Planning --> Material Cost Estimate with Quantity Structure --> Define Costing Variants

Strategy G should be maintained as priority 1. It means System would read future price first. if future standard price is not available then it would look for current standard Price. Standard Cost Estimates Execution When we execute CK40N or CK11N, we have to specify various dates based on Valuation Date, system derives Standard cost from MBEW .

Scenario A: MBEW Table

Above Costing Run in Scenario A for a Material# A110001 would read Future Standard Price 1,104,554.00 which is valid effective 02/01/2014 from the table MBEW: This is because Valuation date in the costing variant if 02/01/2014

Scenario B: MBEW Table

Above Costing Run in Scenario B for a Material# A110001 would read Standard Price 1,103,443.00 which is valid effective 02/01/2014 as current price from the table MBEW: This is because Future Price Valid from date is out of range for the valuation date in the costing variant if 02/01/2014.

Hi All,

I have attached a document on Foreign Currency Valuation. Request you all to go through it and suggest for any changes. Will shortly come with Part 2 on this topic.

Regards

A very warm Hello to you!!

This series of documents would aim at explaining the various key business processes that a finance person is expected to demonstrate the knowledge about. I would restrict myself to explaining the process as is relevant to a FICO person, however, ranging from SAP Logistics and right until the process culminates into FICO, with various accounting touch points. Hence, the name PODs (Process Oriented Discussions)

The present document aims at explaining the various stock transfer scenarios. I would broadly categorize them into

1. Intra-Company Stock transfer (Between Plants of the same company)

2. Inter-Company Stock transfer (Between Plants of different company)

Intra-Company Stock transfer

A Product ,say, P1 is manufactured in Plant A. For some reason (eg: further processing) it is transferred to Plant B of the same company code. This process is called as Intra-Company Stock transfer. Briefly, the process steps would be as below

a. Plant B raises a STO (Stock Transfer Order) on Plant A

b. Plant A might have the stock ready with it or it may need to manufacture the same

c. Once stock is available in Plant A, the same will be despatched (PGI) to Plant B (Movement type 641)

Accounting entry at this stage will be:

  Stock account Dr (receiving plant)

  Stock account Cr (sending plant)

Note that accounting entries are posted when sending plant does the PGI. After PGI, the stock is removed from the books of Plant A and the same is shown as "Stock-in-Transit" in the books of Plant B

d. Plant B receives the stock and does GR (MIGO - Movement type 101).

No accounting document is made at this stage because the accounting entries are already accounted in step c above. The impact of this step will be that the stock in the books of Plant B will now move out of "Stock-in-Transit" category and show as unrestricted stock or QI stock depending on the inspection plan.

Remember that till the time the stock reflects under Stock-in-Transit, it cant be issued for consumption in Plant B.

Experts corner:- 

Below points are meant to provide expert knowledge about this process. These are separated from the above process steps so as to target the relevant audience.

a. Material master set up in Plant A:- (Only the settings relevant to FICO)

  - Procurement Type = E (In-House manufacturing)

  - Price control = S (Standard price)

b. Material master set up in Plant B:-

- Procurement Type = F

- Special Procurement Type = Z1 (to be configured in OMD9)#1

- Price control = S or V ? #2

#1 - When a special procurement type is assigned in material master of Product P1 in Plant B, during MRP run or Costing run, the system will be directed towards Plant A.

This means, during MRP in Plant B, the requirement for Product P1 will be generated and transferred to Plant A. System will not intend to manufacture P1 in Plant B. The planned order generated upon MRP can be converted into a STO

During costing run in Plant B, system can be diverted to Plant A to read and transfer the cost estimate from Plant A

#2 - It is an important consideration / decision to be made regarding the price control of the material in the receiving plant. One school of thought is to have Price control V in the receiving plant, because the material is not manufactured in this plant. Another school of thought is to have Price control S. Preferably, S, is the one that is commonly used. This helps to roll-up the cost component split of sending plant into the receiving plant "as-is". One can have the Price control V and still roll up the cost components in receiving plant. However, it becomes challenging in some scenarios. I would not go into details here, and they can be provided upon request in the comments section.

c. Valuation price of the material in the receiving plant:-

Valuation price of the material depends on the choice of the price control.

  - If the price control is V in receiving plant, the cost of the sending plant (Standard cost) + Any planned delivery cost (PDC) + Non deductible taxes (NDT) become the valuation price of the receiving plant. If there are no PDCs and NDTs, then standard cost in sending plant = MAP of receiving plant.

- If the price control is S in receiving plant,  you can transfer the standard cost and its components from the sending plant. If you transfer the "released cost estimate" from sending plant, then the standard cost in both the plants will be same. Hence, no Price differences or inventory valuations would occur during STO.

In order to transfer the "released cost estimate", you must allow "Cross plant transfer" in the Transfer control of your costing variant. If you don't allow "cross plant transfer", then during cost estimate in Plant B, system would recalculate the cost of P1 in Plant A and update the same in Plant B. As a result, the standard cost in both plants can be different and can result in valuation gain/loss upon STO

- If the price control is S in receiving plant and you want to add the freight charges to the inventory value, then you need to use the "Additive cost" feature in Product costing. In a layman's language, the standard cost in receiving plant would become Standard cost of sending plant + manually specified freight charges.

Note that in this case, the standard cost in both the plants would be different and would result in valuation gain during STO. The accounting entry upon PGI will be

  Stock        a/c  Dr 110 (receiving plant)

  Stock        a/c  Cr 100 (sending plant)

  Val. gain  a/c 

d. Custom validations required in the process:-

Where the material has Price control S in the receiving plant, and the standard cost is not maintained/released, then during PGI, the inventory in receiving plant will be valuated at ZERO.  This becomes a serious concern in accounting and balance sheet finalization.

Similarly, after the standard price in receiving plant is released (same as sending plant) and later on the standard price is changed in the sending plant without updating the same in receiving plant, it can result in valuation gain/loss during STO. This becomes an audit observation during finalization of accounts.

To overcome above problems, one can implement a custom check using FM MB_MIGO_BADI to check that the price of the material in the sending and receiving plant is same. If it is not, the system shall throw an error message, which will prevent the PGI

Thank you for reading the document. I would appreciate your feedback on the document, which will help me to improve it further.

Next document would focus on Inter-Company Stock transfer process.

Best Regards,

Ajay Maheshwari

Post Dated Cheque

1) What is Post Dated Cheque?

A post dated cheque, as the name indicates is a cheque in which a future date is entered. This means that the cheque cannot be cashed until that day. Till the date of cheque, it remains bill of exchange and it becomes cheque only on the date written on the cheque. Its popular name is PDC.

2) Process flow of PDC

Step 1: Receive PDC from the customer

Step 2: Enter the PDC into the SAP system

Step 3: Convert the PDC to Payment on due date

3) Configuration Involved in PDC

Post Date Cheque will be treated as Bills of Exchange. And also, for that Alternative Reconciliation Acct will be created.

While posting bills of exchange/PDC, the system will post the entries to Alternative Reconciliation Acct instead of to the normal receivables account (reconciliation account). This way it is possible to keep bills of exchange/PDC separate from the normal receivables.

Special GL Indicator “W” is meant for bill of exchange and we need to maintain GL Acct in this Special GL Indicator. Special GL Indicator will be maintained at Chart of Account level so there is a need to specify the Chat of Account here.

Customer reconciliation account as well as the special GL account corresponding to the Reconciliation account will be specified.

Step 1: Receive PDC from the customer

Step 2: Enter the PDC into the SAP system

While posting PDC payment and linking the same to the appropriate open item for the customer (via Process open items), the system automatically credits the reconciliation account from the customer master record. However, instead of debiting the G/L account for "bank" or "cash in bank" as it would with a normal incoming payment, the system debits the special G/L account for PDCs.

Transaction code F-36 is used for posting below mentioned entry on the date of receiving of PDC. System by default take the posting Key as “09” and Special GL Indicator as “W”. Here company will specify the customer code against which we have received the PDC.

Accounting Entries: (While receiving PDC/Bills of Exchange)

PDC Receivable A/c                    Dr XXXX

    Customer A/c                                 Cr XXXX

Reports on bill of exchange

Status of PDCs can be monitored each day that have been received, and check if there are some cheques that mature on the particular day. In order to meet the above purpose, report with Transaction code S_ALR_87012208 & S_ALR_87012209 can be generated.

Step 3: Convert the PDC to Payment on due date

When mature cheque have been cashed, incoming payment will be executed (for individual PDC) to credit the PDC account and debit the cash, bank account, or bank clearing account – depending company's accounting procedure.

Transaction code F-28 is used for posting below mentioned entry on the date of maturity of PDC.

Accounting Entries: (On due date of PDC)

Bank A/c                                          Dr XXXX

    PDC Receivables A/c                       Cr XXXX

Overview

Concept of Enhancement

Enhancement means "Adding new functionality to the standard SAP according to the requirement". Underlying concept behind enhancements in SAP is very simple. In a nutshell, “SAP delivers a standard version of software comprised of several repository objects. SAP anticipates that this standard version of its software may not be fit for use right away. So, it has made a provision in its repository objects for customers to plug-in their developed repository objects. The provisions made by SAP keep looking for the repository objects plugged-in by customers. With these plugged-in objects, the enhanced version of SAP software becomes fit for customer’s business process”.

For more information, kindly check the attached document.

A very warm Hello to all!

This document is part of the POD series that I started. The earlier two docs are referenced below for quick reference

POD - Series 1

POD - Series 2

This document will focus on the Inter-Company stock transfer process. This is basically a variation/extension of the Intra-Company stock transfer process discussed in POD- Series 1

The process of inter-company stock transfer can be divided into two parts

1. Refurbishment

2. Drop Shipment

Refurbishment:- This process is also known as Stock replenishment process. This is basically when Company A manufactures the Product and stock transfers it to Company B upon request.

As said earlier, from Logistics perspective, this is same as Stock Transfer Process. However, because the product is crossing the company code boundaries, this amounts to Sale/Purchase in the eyes of law. 

A Product ,say, P1 is manufactured in Plant A (Company 1000). For some reason (eg: further processing) it is transferred to Plant B (Company 2000).

Briefly, the process steps would be as below 

a. Plant B raises a STO (Stock Transfer Order) on Plant A

b. Plant A might have the stock ready with it or it may need to manufacture the same

c. Once stock is available in Plant A, the same will be despatched (PGI) to Plant B (Movement type 601)

Accounting entry at this stage will be:

     Dr. COGS (cost of goods sold)

     Cr.  Stock account                       

After PGI, the stock is removed from the books of Plant A and the same is shown as "Stock-in-Transit" (SIT) in the books of Plant B

d. Billing will follow after PGI in Company 1000

       Dr     Inter Co Customer (Company 2000)

       Cr     Sales revenue

e. Plant B receives the stock and does GR (MIGO - Movement type 101). At this moment, the stock shifts from SIT to Unrestricted / QI stock depending upon the system set-up

Accounting entry at this stage will be:

     Dr.  Stock account                       

     Cr.  GR/IR account

f. Invoice verification (MIRO) in Company 2000

Accounting entry at this stage will be

      Dr. GR/IR account

      Cr. Inter Co. Vendor (Company 1000)

Note that there are various options possible to automate this step.

    a. One can set-up the Idoc process whereby at Step (d), system generates an Idoc and posts a corresponding entry in the receiving company

   b. One can set up the ERS (Evaluated Receipt Settlement) process to automatically process Invoice verification using a scheduled background job. Since group company is involved in the process, it would be a trusted source of supply and hence using ERS should not be an issue (ERS process automatically does MIRO for the posted goods receipts)

Dropshipment:- This is when a customer approaches company 2000 to purchase a product. Company 2000 may not be manufacturing the product or the customer is close to the location of company 1000. Hence, company 2000 requests company 1000 to deliver the goods to the customer, on behalf of company 2000

The process goes like this:-

However, accountancy angle says there are two set of transactions involved in the above process

    1. Company 1000  selling to Company 2000

    2. Company 2000 selling to the Customer.

The process steps and scheme of entries in this case would be as below

a. Customer approaches Company 2000. Company 2000 creates a Sales Order in its system

b. Company 2000 raises a STO on Company 1000. For Company 1000, Sold-to-Party and Bill-To-Party will be Company 2000, however, Ship-To-Party will be the end Customer

c. Company 1000 ships the Product to the end Customer.

Accounting entry at this stage will be:

     Dr. COGS (cost of goods sold)

     Cr.  Stock account 

d. Company 1000 raises invoice on Company 2000

Accounting entry at this stage will be:

       Dr     Inter Co Customer (Company 2000)

       Cr     Sales revenue

The COGS account posted above is maintained in T code OBCB (not in OBYC)

f. Company 2000 raises invoice on the end customer

Accounting entry at this stage will be:

        Dr. Customer

        Cr. Sales revenue

g. The payment process will follow the course (between End Customer <-> Company 2000 and between the group companies)

                                                                           =====End of the Process========

Experts corner:- 

Below points are meant to provide expert knowledge about this process. These are separated from the above process steps so as to target the relevant audience.

a. Material master set up in Plant A:- (Only the settings relevant to FICO)

  - Procurement Type = E (In-House manufacturing)

  - Price control = S (Standard price)

b. Material master set up in Plant B:-

- Procurement Type = F

- Special Procurement Type = Z1 (to be configured in OMD9)

- Price control = V

Note that it is still possible to transfer the cost component split from the sending plant, provided both the companies use same cost component structure.

c. Valuation price of the material

Usually, the price at which the Product will be sold by the Company 1000 + any planned delivery costs + any non-deductible taxes would form the valuation price of the receiving company

d. A separate distribution channel can be earmarked in SD in order to distinguish the inter-company sales so as to report them separately in COPA

Thank you for reading the document. I would appreciate your feedback on the document, which will help me to improve it further.

Next document would focus on few other processes

Hi ,

I have seen lot of post About  Profit centre Distribution cycle definition where we can see Cost centers instead of Profit centre . 

I hope below document will help you .

Configuration changes  for Profit centre distribution

SPRO – IMG Implementation –FINANCIAL Accounting (NEW)-General ledger Accounting –Period Processing –Allocation – defined field’s usage for distribution

                       Or

Direct T-code – GCA6

Will give you below screen

Now choose Cost Center ( Actual )  and double click on that (This will give you current settings)

Now delete all setting in here ( in change mode )and should look like as below (BELOW IS SAND BOX SCREEN )

And SAVE the above changes  And now go back to screen and choose profit centre to Make sure that when you create Cycle you can see PROFIT CENTER there .

After this DEFINE your DISTRIBUTION CYCLE in FAGLGA31   same as Usual. You won’t find any cost centre field here this time.

Now you can see the You do not have any Cost centre . All You see is just Profit Center.

SAVE this cycle and run  Profit Centre distribution Via T-code FAGLGA35 .

Please assign the point if you think its helpful.

Audience: This is for those who are familiar with OpenText VIM.

Introduction

OpenText VIM is packaged solution for managing invoices. With OpenText VIM one can better manage the workflow of the invoices, pay correct amount to vendors, create various types of invoices, get the aging report, keep check and various validations (document type, invoice information etc.), elimination of errors and duplicate check. Having a highly configurable design allows VIM to accommodate various business scenarios and cater needs to various organizations.

VIM preprocess data before creating SAP document. Once system validates all the business rules and pass the document then document in SAP is created. DP comprises of following:

Configuring DP document types

OpenText provides standard document types for most of the scenarios however one can create a custom document type by following below steps:

1. Create SAP ArchiveLink Doc Types: Go to T-Code OAC2 and create new SAP ArchiveLink document type by providing values for Document Type, Description and Document Class.

It is recommended to maintain one SAP ArchiveLink for each DP doc type even if the process is same as it allows separation of database and custom functions.

2. Create new DP Doc Type:

    a. Go to T-code /n/OPT/VIM_1CX1

    b. Click on 'New Entries' button (In case you wish to edit existing one then double click on the document type)

    c. Enter following details: Description, Document Index Type (Indexing using OCR, Online Indexing, No Indexing, and Indexing using IDOC), Invoice Type, Number Range, SAP FI Doc type, Archive Doc Type, Line Item Data, Duplicate Check Group, Duplicate Check Role, Default Process type, Posting Role, Rescan Role, Check Display Index Data checkbox, Check Skip Dashboard checkbox and Check Display Image checkbox.

NOTE: Indexing is a process of filling up the invoicing details in the DP document.

3. Define Process Type:

    a. Got to T-Code /n/OPT/VIM_1CX1. Select the created DP Document Type

    b. Double Click on Document Process and select the process type. Click on Details button

    c. Check the Active checkbox button. Select the value of BDC transaction ID and Background Tran ID (BDC transaction ID is used to process an SAP transaction to create SAP document in user context. Background Tran ID is used to process SAP transaction to create SAP document in background). Enter value of Autopost flag (X: for background processing) and parking reason.

4. Configure Index screen option:

    a. Go to T-Code /n/OPT/VIM_1CX1. Select the created DP Document Type.

    b. Double click on Index Screen Option and click on New Entries Button.

    c. Provide following details: Process Type, Description, Current Role (Role which processes the Work Item), Check on Allow Changes check box, check Show Duplicates check box, select Initial Tab (Dashboard and Index Data), Select Enable Simulate in case you want to skip certain business rules, check Disable Obsolete check box in case you want to hide obsolete button in dashboard and check Disable Rescan check box in case you want to hide Rescan button in dashboard.

5. Configure Automatic Image Display:

    a. Go to T-Code SM30 and enter /PTGWFI/Z_CONST in Table/View and Click Maintain.

    b. Under product code 005 double click constant DASHBOARD_IMAGE_AUTO. Enter value X and save.

6. Define Process Type determination sequence:

    a. Go to T-Code /n/OPT/VIM_1CX1. Select the create document type and double click on Proc. Type. Det. Sequence.

    b. Enter following details: Step Id, Process type, check Exclude from Simulate checkbox to exclude business rule from simulation and check Bypass      possible checkbox to enable bypass of business rule

    c. Select the step and double click on Sequence Steps. Enter value for Step Sequence, Field Name for the field that needs to be validated, check type (Table Field, Check Function, Constant Value, Required Field)

7. Maintain PO line Determination: When data is captured from external system then PO line number might not be supplied thus this step helps to determine the PO line number in such scenario.

    a. Go to /n/OPT/VIM_POL

    b. Enter PO Line Det. ID (should start with 1), Check Function (custom function to determine PO line number. It is blank by default and OpenText standard function module is used).

    c. Double click on PO Line Determination Fields and maintain fields you to bed used for PO line determination and save.

    d. Go to /n/OPT/VIM_1CX1. Double click on Document Type and enter the value for Determination Logic ID. Save.

8. Maintain Tax Code Determination:

    a. Go to T-Code /n/OPT/VIM_1CX1. Double click on Document Type and select the radio button for required option. In order to get the tax code from vendor master then select 'Tax Code from Vendor Master'.

    b. In case tax is determined using OpenText tax table (table: /OPT/VIM_TAX_CFG) use t-code /n/OPT/VIM_BL_TAX_CFG

    c. Select applicable checkbox for tax calculation (Auto Calculate Tax, Allow Zero Tax Rate, and Allow without Rate).

9. Configure Duplicate Check: This is to check in case a duplicate document is created. After identifying the document can be routed back to the predefined role for further processing.

    a. Go to T-Code /n/OPT/VIM_1CX5

    b. Click on New Entries button and enter the Duplicate Check Group number, Description, Duplicate Check Type (Function Module and Index Data Field) and Ext. Dup. Check Function. Select Run Duplicate Check in Central System

    c. Select the created group and double click on group field and mention the fields for duplicate check

10.  Determine PO invoices by Vendor Table: Table /OPT/VT_DOC_DET contains vendors that send PO based invoices. Vendor can send invoices without providing PO number. If vendor is not found in this table then system checks for PO number.