Streetlights can be managed and billed in different ways in ISU. Streetlights can be managed at Installation Facts level as an Operand or in the installation Structure as devices. There are multiple Variants available in ISU which can be used to perform billing of streetlights. We will be looking at the below variants. REFVAL01 - Valuate a Reference Value with a Price REFVAL02 - Convert a Reference Value to Demand REFVAL03 - Determine Consumption for Lighting Unit from Burning Hour Calendar REFVAL01 REFVAL01 has 2 input operands – (REFVALUE and TPRICE) and one output operand – AMOUNT. Create a Rate with Facts Permissibility and Insert variant REFVAL01. Provide the Input Operand 1 which will be maintained at the Installation facts, Input Operand 2 which will hold the price key, and Output Operand which will hold the amount. When creating the input operand for REFVAL01, verify "Rate type required" checkbox is selected. Price of $2.5 per month is configured. Maintain the Reference value Operand at the Installation level. Entry value – Installed value of device. Value to be billed – Can be a value other than Entry value. This value is used in consumption billing. If value to be billed is not entered, the value from “Entry value” is automatically copied. Rep. factor – Determines how many times the same type of reference value exists. Value to be billed is multiplied by repetition factor. For example, if there are 10 streetlights, we can create one reference value and provide repetition factor as 10. Bill The account. Since we selected Period control as “00 – To the day” at the rate level, price for 1 year is calculated first to get the per day price and then price for time portion is calculated. This can be changed to monthly by choosing PC as 01 or 02. Billing quantity = 10*20 = 200 (val.to be billed * rep. factor) Price for a year = 2.5 *12 = 30 Time portion = 31 (Number of days in the billing period) 30/365 = 0.08219 * 31 = 2.5479 (Price for 1 day) 2.5479 * 200 = 509.59 REFVAL02 REFVAL02 is used to convert a Reference value to demand and has one input operand – REFVALUE and one output operand – DEMAND. Create a Rate with Facts Permissibility and Insert variant REFVAL02. Provide the Input Operand 1 which will be maintained at the Installation facts and Output Operand which will hold the demand. Since REFVAL02 outputs Demand, we need to add one more Variant to calculate the amount. We will add DEMAND01 and provide the output operand of REFVAL02 as the input operand for DEMAND01 Price of $2 per month is configured. Maintain the Reference value Operand at the Installation level. Bill The account. Billing quantity = 20*3 = 60 (val.to be billed * rep. factor) Price for a year = 2*12 = 24 Time portion = 31 (Number of days in the billing period) 24/365 = 0.06575 * 31 = 2.03835 (Price for 1 day) 2.03835 * 60 = 122.30 REFVAL03 REFVAL03 is used when we are calculating the consumption using the burning hour calendar. REFVAL03 has 1 input operand – REFVALUE and 1 output operand – QUANT. We begin by configuring the Operation Types for Lighting and create an operation type. Operation Type defines the type of lightning being used. Navigate to the configuration path below: Contract Billing ➡️ Billing Master Data ➡️ Rate Structure ➡️ Operands ➡️ Lighting ➡️ Define Operation Types for Lighting. Navigate to the configuration path below to configure the Types of burning hour Calendar Maintenance: Contract Billing ➡️ Billing Master Data ➡️ Rate Structure ➡️ Operands ➡️ Lighting ➡️ Define Types of Burning Hour Calendar Maintenance Here we can choose whether Burning Hour is to be maintained on a Daily or monthly basis.  Navigate to IMG configuration path below to configure the Burning hour Calendar: Contract Billing ➡️ Billing Master Data ➡️ Rate Structure ➡️ Operands ➡️ Lighting ➡️ Maintain Burning Hour Calendar. The Burning Hour Calendar contains the total number of hours where the lightning unit was operational in the given period. Create a facts permissible Rate. Add variant REFVAL03 and provide the Input and Output Operands. The input operand should have the 'Rate type required' checkbox checked and ‘Reference value type’ selected as lightning. Since REFVAL03 outputs Quantity, we need to add one more Variant to calculate the amount. We will add QUANTI01 and provide the output operand of REFVAL03 as the input operand for QUANTI01. Create a Rate fact group and add price to the rate facts. Quantity can be set to ‘0’ and set the reference value as ‘Required value’. Add the Refval03 operand in the installation facts. Bill the account Value from Burning hour calendar for 01/01 to 01/31 = 200 200 x 10 (val. To be billed) = 2000 (Billing Quantity) 2000 * 10(price) = $20,000

When using a Price adjustment clause in the price, we can use an adjustment factor to update the price without changing the actual price maintained at price level. For example, we have maintained a price of $2 and for the next 2 months the price must be increased to $2.5. In this case, instead of manually changing all the price keys, we can maintain a price adjustment clause with an adjustment factor of 1.25. this way we will be able to adjust the price on all price keys indirectly where this adjustment clause is maintained. We can perform multiplication, addition or both when configuring a price adjustment clause. Price Adjustment Clause can be created for all price categories. To create a price adjustment clause, in the SAP configuration, navigate to the following path: SAP Utilities ➡️ Contract Billing ➡️ Billing Master Data ➡️ Rate Structure ➡️ Prices ➡️ Price Adjustment Clause ➡️ Define Price Adjustment Clause Enter the Price category, Division, Text, valid from and to dates when the adjustment should happen, Price adjustment factor and click on Save. We can also provide a flat price to be added with or without the adjustment factor. For example, if we have price of $2 maintained and provide adjustment factor of 1.25 and Added price as 1 the price will be calculated as follows: $2 x 1.25 = 2.5 2.5 + 1 = $3.5 If the "addition first" checkbox is selected, the price will be calculated as follows: $2 + 1 = 3 3 x 1.25 = $3.75 Price adjustment clause created from 02-01-2020 to 03-31-2020 Price adjustment clause maintained at price key Price of $2 is maintained. Account billed for period where Price adjustment clause is inactive: Account billed for period where Price adjustment clause is active:

Payments are the Receivables getting from the customer or the third-party vendor to the Utility Company. There are three types of Payment methods: Direct Debit Payment through vendors Cash Journal Payments Direct Debit The customers provide bank account details or credit card details to the utility company stored in the Master data level. Whenever there is due item for contract account, it will automatically fetch the due item during the daily batch run and post the payment for the corresponding due item in customer’s account. Like there will be large number of accounts who are enrolled for this direct debit method the system will check for the due item in a batch process method. Once the Batch job run is completed and it will create the File with the Customer details and send to the House bank in a daily basis. Once the House bank received the file, they will send to the respective customer bank for debiting the amount from their account. From the list of account, if the account does not have sufficient balance or any other reason for the failed amount debit those accounts are consolidated and sent back to the Utility company. That file is posted as Returns. a) Configuration of Direct Debit FICAIMG -> Business Transaction ->Payments->Incoming/Outgoing Payments creation -> Define Payment Methods Select the country which you want to add the payment method, click on new entry to create payment method Selection the check box ‘Payment method for incoming payments’ option, otherwise the payment method is considered as the outgoing payment method. Give the payment method format as ‘ACH’ and Document type and Clearing reason you can add based on the requirement. Click on Save. b)Creating File for House Bank Clearing On the part of the Direct debit payment there will be 2 methods like Credit card and bank account configuration. For debit batch job run, the sap system will run the program twice for credit card and bank account configuration separately. File format for bank account and Credit will also be different, so need to create the separate file for both payment methods. Example of the File creation for Bank account Configuration FICAIMG ->Business Transaction ->payments ->Incoming/Outgoing Payment creation -> payment medium-> Define payment medium formats. To configure the format for the ACH file creation, go to Define Payment medium formats. We need to specify the program module to run the file creation. As keep reference to the below screen shot 10 -> header line creation 30 -> footer record 20-> Detailed Record line item based on the number of records available in the system per day. How will it run FPY1 and when? On daily basis the batch job will be run for the accounts with the payment method as D and having the line with this due date. Those accounts are picked up and added to the batch job once the run completed. The file will be created at the end of the day and will be send to house bank for clearing process. Create a new variant for ACH in the payment medium program SAPFKPY3. File path is also maintained at the variant level and save the variant. Maintain the back details and incoming payment method in account level. Go to T-code BP to maintain the Bank details for the Direct debit purpose. Add the Incoming Payment “D-Direct Debit” in the Contract account. Validate the account in FPL9, open due items exist on it. Example: Run FPY1 to clear the open due item. In background the same transaction will run in a batch every day to pick CA with the Due open items available in an account with the Incoming payment configured as Direct debit. Give the Contract account Details that is optional, in real time it will run for all the account which are configured for direct debit. Give the due date for picking up of the due items available in the account with method as “D”. In Bank selection tab select the house bank account for the processing of the Direct debit, rest of the tabs are leave it with the default values. Save the details and run. Payment posted to customer account and clear the open items. To create a file, go to Environment ->Payment Medium. Give the variant and schedule it. File successfully created in AL11. Payment through vendor In a real-time, Payments has been posted in an automatic way by calling the custom program in background for posting payment to the Customer account from based on the file which will get from the vendor. Whenever the File is created by the third-party vendor and sent to the SAP system the system picks the file from PI/PO to the AL11 folder on which it is configured to place. Once it got placed SAP must design the custom program based on the Client request to read the file and Convert to SAP readable format. That custom program will help to convert the File to SAP readable format there is not any specific standard program for this conversion. a) Creation of file through the Program RFKKZEDG Program which helps the system to create a sample File in an SAP readable format. To create a sample file to run the Report RFKKZEDG through the SE38 T-code and execute it. Enter the details as per below. File will be generated in AL11 directory. FPB3 transaction will help us to post the payment to the customer account. Give the lot name in identification and respective path of the file. Execute it. Posting is scheduled for payment. Verify the Posted Lot in the FP05 T-code. If the file is showing the error failed to post the payment. Correct the file by using the T-code FPB4. Correct the Lot based on the error description raised in the T-code screen FPB4. In this example profit center is missing in the Lot header. Once the Error is cleared save the lot and Re-execute the Lot and check for the payment scheduled. Go to FPB3 and select the process error option and click on execute. Manual Lot creation through FP05 Incoming Payment to the customer account is posted manually using the FP05 transaction. Enter the CA and amount details, Close and Post the lot. Once the Lot is closed, we cannot add any item to the Lot. Post the lot for the successfully posting of payment to account. If there are any errors in the lot, it will create clarification case for that Lot. Once the Error is rectified then the payment is getting posted to the account successfully. Example: Fill the required field (Bank clearing act, company code, currency, etc) in the next screen. Click on new item and enter the amount and Contract account (selection category K)/BP(G) or document (B). After closing the lot, we can’t be able to add entries in the lot. Click on “Post “for posting the payment to the account. In the account level, we can see the payment. Clarification of Payment Lot When the posting is made with some errors or while processing the payment lot file if the vendor missed any character in the file will push those line item to the post processing. The below screenshot gives you the example to clarify the items posted. Correct the error and post the payment. Verify the completed status is the clarification case. Cash Journal Payments Currently most of the utility company not using this method of payment. T-code used is FPCJ. Going directly to Utility company and paying the cash across the due item available in account. Click on go to Cash desk. Give the CA details and if you want to post the payment against the Open items available in the account, then click on Open item button at the top of the screen. Click on the select items to choose for the amount to be posted across the customer’s account. Or give the payment and post. Once the Items are selected for the post click on the post at the top of the screen. Verify the Payment posted through the account balance display screen FPL9. Following the above process, we shall be able to post payment.

Returns are posted for payments which fail to get realized at the bank. Return lots are posted as per the file received from the bank/payment vendors. Failed returns go into the return lot clarification list for manual correction. Return reason, Reason activity, Return charge Here, we can configure the return reason The returns reason specifies the company-specific reason for a return. A business partner's creditworthiness provides information about the payment history. Creditworthiness is used for returns, correspondence and dunning. In this way, charges can be made or dunning activities carried out for a business partner that is based on creditworthiness G/L account to which a posting is made if the return cannot be posted as planned and clarification processing is required. If there is no clarification account specified for an item to be clarified, the clarification account stored in the system is used. To create a new return reason, proceed as follows: Define the return reason. Maintain the settings for the return activities. Define currency-dependent lot charges. Define the maximum permitted difference amounts for each currency. Give the return reason and name below Return type: The type of return is defined, such as a bank or check return Automatic account assignment uses the return type to determine the G/L accounts for the return charges and the bank clearing account. Creditworthiness: A business partner's creditworthiness provides information about the payment history. Creditworthiness is used for returns, correspondence and dunning. In this way, charges can be made or dunning activities carried out for a business partner that are based on creditworthiness. The best creditworthiness value is 0. This means that the business partner has a good payment history and has, for example, not been sent a dunning notice in the last few months. The worse the payment history of a business partner is, the higher the creditworthiness value The application form is nothing but a layout of the form which needs to be printed. Clarification account: G/L account to which a posting is made if the return cannot be posted as planned and clarification processing is required. Return activity The number of returns is determined from the return’s history for the history days (observation period) defined in Customizing. The number always refers to a business partner and a contract account. No. of returns: The number of returns is determined from the return’s history for the history days (observation period) defined in Customizing. The number always refers to a business partner and a contract account. Deferral days: The date on which an item is due for payment without deduction of cash discount. Number of days that a receivable is deferred if a return has occurred for the payment. We can put the lock and duration in the return reason. Post charges statistically: Line item which does not result in postings to the general ledger and is treated only as a noted item in Contract Accounting. This means that charges receivable to a business partner are only posted statistically. Calculate graduated charges: You set this indicator to calculate a charge markup in addition to the bank charges for a business partner. The amount of the graduated charge depends on the amount of the return. If we want to delete the payment method from the customer's account based on the history of the customer. You can select the checkbox. For example, if the customer using an incoming payment method but the account is empty when the debt is coming to the customer's account. ie, If the return happened twice, we can select the delete incoming payment method. Directly delete the incoming method from the account. When the return happens, select 'Create correspondence' to inform or create correspondence for a particular return reason. Assign Return Reasons to House Banks In this activity, you define a company-specific return reason for each house bank return reason for your house banks. Define the bank-specific return reasons for each house bank and assign the company-specific return reasons. House bank return reason: The house bank's return reason indicates the bank-specific return reason for a return. A company-specific return reason is assigned to each house bank return reason in Customizing. When processing a return lot, this house bank return reason is then sufficient for the system to be able to determine the company-specific return reason. When the return lot is posted, the activities defined for the company-specific return reason are then carried out. Define Bank Clearing Account for Returns In this activity you define the bank clearing accounts for returns. To activate the account for returns lots, select the field Valid for Returns. Define Clarification Accounts for Returns Here, defines a clarification account for each house bank and returns the reason. Determine Document Type and Clearing Reason for Returns In the FP09 screen, if you want to set the default value you can set the function here. Define Field Selection for Returns Create variant for returns In FP09, Converting files from third-party The third-party (Bank) will create a file to return the payment amount from the customer account. It may contain the Date, Business partner, contract account and return amount. PO will take the file and put it into a SAP AL11 directory. SAP couldn’t read the file which the third party sent. So, SAP will convert the file to SAP readable format using a custom program (each client needs a different format. Based on that will create the custom program and use it for conversion). Once the conversion is completed, use another program to create a return lot. a) Use of the RFKKRLDG program The RFKKRLDG program is used to create sample files in SAP readable format. This report generates a test file for the returns lot transfer program. A sample file is created. FPB5 and FPB6 transactions This report transfers data and uses it to create one or more return lots. To do this, it executes the following steps: The report reads the specified application server file and checks the data contained therein. It creates one or more return lots as long as the data records are correct. It closes and posts the returns lots created as long as the appropriate indicator is set. Data records that contain errors are saved separately and can be transferred after they have been corrected. We can use FPB5 transactions to post the return lot. If we get any error when we run FPB5, we can run the FPB6 transaction to correct the error. FP09 and FPCRL transactions Return lot: The returns lot is a central object in returns processing. It is essentially a grouping of documents that were sent back by the house bank and are settled with the same bank clearing account. Create the return lot: Save the details after giving the return reason and document number. Close and post the return lot. FPCRL- To clarify the return lot. We can see the error message when we are expanding the clarification. Reverse the cleared item and click on the post. We can see the message with the document number. Clarification case status also changed to Completed. Following the above process, we shall be able to post returns. If the information is incorrect, it will be posted to clarification. Using the return clarification process, the return can be clarified against the right payment document.

We can predefine the Document type and Clearing reason while executing the FPE1 transaction. We can do the manual posting by using the FPE1 t-code. Configuration part: Go to FICAIMG transaction, and navigate to the below place.   Under the Function, select the Document type and Clearing reason then save the process. Open the FPE1 transaction and verify the Document type is displaying as Z1.  Manual Posting using FPE1 transaction Provide Document Date, Posting Date, Currency, and Document type as ‘Z1’. Then press Enter. Enter the Company code, Net Due Date, Contract account, Main and Sub in the Business Partner Items tab. Note: Enter Contract and Division only if the posting is Division-specific. Main and Sub transactions will decide the type of the posting and whether the posting is Debit or Credit. The tax amount is calculated based on the tax jurisdiction code and  Click on Save. The document is posted under the selected CA.    Credit amount is posted to the account as we have selected credit posting transactions( Sub transaction will decide whether the posting is debit or credit). As mentioned we can do the manual posting to the account level.

Period Control is a calculation procedure used to calculate the length of Time Portions. The time portion is the billing period in days or months based on the period control used. The Proration of charges happens based on the Time portion. There are 3 standard methods that are commonly used to calculate the length of Time Portions. To the Day Monthly time portions dependent on a key date Monthly time portions dependent on an interval 1. To The Day (00). When we select Period control “00 – To the Day”, the exact days in the billing period are used to calculate the time portions. Here the charges are calculated on a per day basis. Period control is maintained at the Rate step level. Tcode: EA32 The Price is configured as $50 for 1 month. Tcode: EA91 We will perform Interim billing. Below we can see that the Time portion is the exact number of days that comes under the billing period and the amount is calculated accordingly. Billing Period: 05-01-2017 to 06-16-2017 (47 Days) Since the price is maintained on a per-month basis, to get the per-day price, the 50$ is multiplied by 12 (months) and then divided by 365(days). Price for 1 year = $50 (Price configured for 1 month) x 12 (Months) = $600 Time portion = 47 (Number of days in the billing period) 600/365 = 1.6438356164 (Price per day) 1.6438356164 x 47 = $77.26 (Price for 47 days) 2. Month-based using key date (01). When we select Period control “01 – Month-based using key date”, the Key date is used to calculate the time portions. Period control is maintained at the Rate step level. In the Rate Step, select the Period control “01” as shown below and save the Rate. The Key date is maintained inside the MRU. We will perform Interim billing. Here the billing period will cover from 15th of July till 15th of August. Since two Key dates are falling within the billing period, the amount should be calculated for 2 time portions. Billing Period : 07-01-2017 to 08-16-2017 In the billing document, we can see that the Time portion is shown as 2 and the amount is calculated accordingly. Price amount is $50 and Time portion is 2 so the Net amount is 50 x 2 = $100 . 3. Month based with interval. to the day Move I/O (02). When Period Control “02 – Month based using Interval” is selected, if the total number of days in a billing period falls within the Interval period specified inside the Portion, then the account is billed for one billing period. The period control is maintained at the Rate step level. The Interval days are maintained inside the Portion. We will perform Interim billing. Here the bill period is still within the interval date specified in the portion. Billing Period: 09-01-2017 to 10-04-2017 (34 Days) In the billing document, we can see that since the total number of days are within the interval days, it is calculated as 1 time portion. When the number of days in the billing period does not fall within the interval days, the time portions are first calculated for an exact number of days. Then these time portions in days can be converted to the standard month. In the below example, we can see that the billing period only has 24 days, so the time portion is calculated for 24 days and shown in months. Billing Period: 09-01-2017 to 09-24-2017 (24 Days) 24/30 = 0.8 Month We will also see how this Period control works in case of a Moveout. A Moveout was carried out and a Final bill is created. Billing period: 09-01-2017 to 10-04-2017 Here the billing period contains 34 days, and the time portion is calculated for 34 days on a “To the day” basis as configured in the Period Control. 34/365 = 0.0931506849315068 0.0931506849315068 x 12 = 1.117808219178082 4. Creating Custom Period Control. Based on business requirements, we can also create custom Period controls. Before creating the custom Period Control, we need to create a Category of enhanced interval procedure by going to Tcode SPRO . Path: SAP Utilities ➡ Contract Billing ➡ Billing Master Data ➡ Rate Structure ➡ Rate ➡ Period Control ➡ Basic Calculation Procedures ➡ Month-Based Calculation Using Interval Execute “Define Category for Enhanced Interval Procedure” Click on New Entries and create Interval Procedure Category as shown below. Go back to SPRO path and execute “Define Type for Enhanced Interval Procedure.” Click on New Entries and create Interval Procedure Type as shown below. Go back to the SPRO path and execute “Define Additional Values for Enhanced Interval Procedure.” Click on New Entries and define additional values as shown below. Go to Tcode E41C and add the “Cat. of Enhanced Interval Procedure” to the portion. Go to Tcode SPRO and open the path mentioned below: Path: SAP Utilities ➡ Contract Billing ➡ Billing Master Data ➡ Rate Structure ➡ Rate ➡ Period Control Click on the Execute button next to “Define Period Control.” Click on “New Entries” button to Create a new Period Control. Create a new Period Control by providing the Period control, Description, Period Procedure as 03, and the Cat. of Enhanced Interval Procedure as shown below. Using this method, when we have a new requirement and the standard Period control does not fulfill the requirement, we can create a custom Period Control and use it at the Rate Step.

In FICA, to determine the G/L Account, the main and sub-transactions are defined and then used different posting areas to determine the G/L account. Main Transaction- Determination of receivables and payables accounts.  Sub Transaction- controls revenue account determination, determination of the tax determination code, and information about any additional accounts. GL Account To provide a comprehensive picture of external accounting and accounts. Based on the requirement we need to configure the main and sub-transactions in the system. In SAP, Main and sub-transactions are already maintained for some standard functionality (Invoice, Payment, Returns, Reverse, Security deposit etc.). Maintain Main Transaction Go to SPRO/FICAIMG transaction. Select "Maintain Main Transaction" using the following path. Financial Accounting (New) Contract Accounts Receivable and Payable Basic Functions Postings and Documents Maintain Document Assignments Maintain Main Transactions. Click on the “New Entries” button to create a new main transaction. Give the Application area, Main transaction and description based on the requirement. Click on “Save”. We can see the entries here and table TFKHVO as well. Maintain Sub Transaction Select "Maintain Sub Transaction" using the following path. Financial Accounting (New) Contract Accounts Receivable and Payable Basic Functions Postings and Documents Maintain Document Assignments Maintain Sub Transactions. Click on the “New Entries” button. Give the Application area, Main transaction, Sub transaction and description based on the requirement. Click on “Save”. We can see the entries here and table TFKTVO as well. Maintain Attributes per Company code and Division and Debit/Credit indicator Select the “Maintain Transaction for charges” using the below path. Financial Accounting (New) Contract Accounts Receivable and Payable Basic Functions Postings and Documents Maintain Document AssignmentsMaintain Transaction for ISU Maintain Transaction for Charges. Click on “New Entries”. We need to maintain the Entry for the new Main and Sub transactions. Enter the company code and division (If required). For example, based on the requirement, we need to post the credit/debit to the contract level instead of the contract account. So, we need to add the division also with the main, sub-transaction. Give the description of the combination of Main/Sub transaction. Enter the Main and sub-transactions which we created now. Under the Account assignment data, choose the Debit and Credit based on the requirement. Select the check box “Manual Posting Allowed”, if you want to use this combination for manual posting (FPE1 transaction). Click on “Save”. Create another entry for credit. we can use the same method that we used for debit. Maintain Account Assignment data relevant to Main transactions: Overview(EK01) If you would like to post the document at the contract level, you can add the division and ADID(Contract level). you can able to post documents/invoices at the contract level(eg: Division dependent). Here we are posting the document at the contract account level(ADID from CA). Posting area R000 maps the balance sheet GL A/c against the particular combination of Company Code/Account ID/main Transaction. ADID is used to determine the GL account. Go to EK01 transaction and click on “Create button”. One popup will come. Enter the Main GL account and click on “Save”. Maintain Account Assignment data relevant to transactions: Overview(EK02) Go to EK02 Transaction and Click on “Create”. Enter the company code, ADID, Main and Sub transaction and continue(Based on the requirement). Click on "Save".  In the TFK033D table, the Posting area R000/ R001 and give the Main transaction in KEY04(Technical name). Posting area R000 maps the balance sheet GL A/c against the particular combination of Company Code/division/Account ID/main Transaction. Posting area R001 maps the P&L GL A/c against the particular combination of Company Code/division/Account ID/main Transaction/sub Transaction.

This blog walks you through determining and configuring the document type and assigning number ranges in detail for a FICA document. Document types differentiate different business transactions. The number ranges assigned to them also control the way documents are stored. During document posting, the system determines the document number from these number ranges. Transaction used for displaying document: FPE3 To configure Document type and number ranges, go to the transaction FICAIMG and navigate to the below-highlighted node. Here we can maintain different document types and number ranges in the below displayed window. To add a new document type to the list, click on the 'New Entries' button. The 'Application area' is defaulted as a Utility company. Provide 'Document Type, Description and Number range'(determine the document number from these number ranges) Select the ‘Not Manually’ button if we want to prevent manual posting using this document type. Example: For invoice documents, Not Manually option is checked as we can’t post any invoice document using the FPE1 transaction Once entered data in the required fields, click on the save button. As mentioned above this is the way a document is determined. The number ranges would be the same whenever we post a FICA document using the document type.

A customer informs, that he will pay an outstanding receivable within a specified timeframe. This information is stored in the system in the form of a promise to pay. Creation of Promise to Pay(P2P) Go to the transaction FP2P1 and enter the BP. Click on ‘Create Promise’ button to create new Promise. The agent enters the following parameters for the new promise to pay: • Reason • Category • Start date • Correspondence creation After entering this data, the agent can simulate creation of the promise to pay. Valuation of P2P via TCODE - FP2P3 and FP2P Configuration To configure the Promise to pay, go to the transaction FICAIMG and navigate to the below highlighted node. Define Categories: Provide Category and Name. Payment Dates (Monthly, Every 2 Months, ...): Time interval between two sequential instalments. Number of Payment Dates: Number of payment dates for the promise to pay. The value specified here is used to calculate the amount and due date of the instalments. Define Reasons for Creation: Create new reason and save the process. Define specifications for creation: In this activity you define the specifications for the standard entry and the fast entry (CRM) of promises to pay. Select Use from the list and select Category and the reason.