Payment Card Processing Tutorial Purpos Payment cards frequently replace cash as a means of payment, becoming indispensable to customers and valuable tools for businesses, Implementation guideline and tutorial on Payment Cards for L’Oreal USA, PPD business area Payment card categori ‘* Credit card - Used for purchasing goods and services with regular billing, usually with extended credit. '* Customer cards - Used by customers to buy goods and services from a specific merchant or group of merchants. ‘* Debit cards - Used as 2 means of cashless payment. The cardholder's bank account is, debited instantly. ‘* Procurement cards - Issued on behalf of companies to employees for purchasing items up to a given amount. ‘+ Walking cards - Issued on behalf of companies to employees for purchasing a wide range of goods and services for company travel. The payment card functions in Sales and Distribution (SD) allow for sales involving these Categories of cards, with the exception of walking cards, which are supported by Human Resources (HR), and debit cards, which are supported by Retail (SAP Retail) using point of sale (POs).Payment Card process flow in sales and distribution (SAP! In Sales and Distribution, you can enter payment card data in the sales order and use it throughout the order to cash cycle. Sales order Authorization Settlement Billing document ‘Accounting document ¥ ¥ 1, When you create a sales order, you can enter credit card data manually, or copy it from the payer master record. You can enter one card in the sales order overview screen. You are able to enter multiple cards or multiple authorizations on one card, in the payment card plan in the sales order header. The system automatically authorizes the sales order when you save it. 2. Ata later time, you create the delivery. The authorization may have expired in the meantime, so the system checks to ensure that itis still valid. if the authorization is no longer valid, the system tells you to reinitiate authorization in the sales order. You complete and save the delivery. 3, When all the items are picked packed, and goods issue is posted, you create a billing document. Here, payment card data is copied from the sales order, or uploaded directly into ‘the billing document from an external system, as in the case of point of sale. The system usesthe authorizations in the payment card plan to calculate billing amounts. You process the billing document and release it to Financial Accounting. Paymetric Interface flow diagram: med Res Termnal us Terminal eS pre te oc ao il Fecure ~HA — f/ f/ A Gearing Hose Partners involved in Credit card transactions: The different partners involved in card processing in the SAP environment are as below: ‘* Cardholder - Uses a payment card to purchase goods and services. (CUSTOMER/PAYER) ‘© Merchant - Provides goods and services and accepts cards as payment. (L’Oreal USA) ‘* Clearing house - Issues authorizations and provides services for processing settlement data supplied by the merchants. (BOA First Data, Chase Payment tech)‘© _Interface/SERVICE COMPANY ~ Used for transfer of card/transaction data between Merchant's SAP system and Clearing house for authorizations, settlement and card tokenization services etc. (Paymetric Inc.) Payment card data as entered in Payer master record: Payment card data can be manually entered in a Sales order or also pulled from the payer record if already maintained in the master record. NOTE: The one-time customer record is a collective account, in the master record, for a group of unrelated customers. For this reason, you cannot maintain payment card data for one-time customers. Path: XD02 > General Data > Payment transactions tab > Payment cards button, (® .) Display Customer: General Data other Cistomer YF Comaany Coc Data Sales AreaData @] [A cove System Enhancements Sacncontne cusemer —_—_[ennsas hen tes amar rene) SEELEY HEIGHTS | Bark Beta cy Bank key ‘Bank Account acct hablar (co.., BAN [iBaNvale o (Banko. ] (BIS [paver cas] | Akemativo payer nidacument pos 1 [Sees Dienires fot retsien ‘Mewied paver[BL] Display customer: General Data - payment cards Umit cx cusconee FRR lb eat res femee) Parent ack “ype ur vaio cater cosilerates vate bet TIE altooroorocanek 127089 PED Tet ae rE) = vero) You can enter the follo 1g card information in the payer master record: ‘* Card type, for example VISA, MC, or AMEX Payment Card type is maintained in configuration as below. Path: IMG > Sales and Distribution > Billing > Payment Cards > Maintain card types. Display View "Payment Card Type": Overview & Payment Card Type se HEX cea cad ——_—esana_e_ es ae vk acd cearo_oC. 8h toa © Card number The system checks the card numbers you enter to ensure that they correspond to the numbering standards of the relevant payment card company (for example, checking to make sure that a Visa card number begins with "4").This reduces the risk of having to go through a lengthy authorization process in the sales order with an incorrect card number. The Function modules in Check column (above screenshot) perform the validation function. The system also checks to ensure that a payment card belongs to only one customer. You cannot enter one payment card in two different master records. ‘© Expiration date * Cardholder or company name as it appears on the card‘© Card category, such as credit card, customer card, or purchasing card Card category is maintained in configuration as below. Path: IMG > Sales and Distribution > Billing > Payment Cards > Maintain Card Categories. + By __ Saos and Distribution > By Master Data » Be Basic Functons By Sales » By Foreign Trade/Customs B__ sing + By Billing Documents Be amet crs By © Wantan Cara Typed + By ® maintain Gard Cateconies + By ® Maintain Payment Card Plen Types + B® maintain Bocking Reasons > Authorzaton and Settierent > BB Follow-up Processing Activities Pe... Name of Activty i oY (pevermine care cavegoraes Y Define cerd categories Define card categories: - Display View "Payment card category”: Overview Bea Payment card category Cat Description One card per trans, ‘Additional data fii} 1 Credit card Oo a 2C_ credit card PPD NOTE: if ‘One card per trans." is ticked in the above then multiple cards cannot be used per Sales order.Determine card categories: - Display View "Payment Cards: Determine Categories": Overview BEE Type Seq, 0. Payment cards fic Payment carc 10 uit Cat Descnpton i] Jac re Co edtcad FED * Hun cre eo credtcardFeO |” visn io cre Vac cred card PFO In the above setup each credit card type is determined asa credit card category ‘2’ and number range with no particular limits and hence ‘* Is defined. ‘© Blocking reason If required, you can block the payment card by entering a reason, for example 01 or LC for “card Stolen” A block is for a particular payment card only. if one of the customer's payment cards is blocked, the customer can use another card. ‘iso, a block does not affect sales documents that have already been created with the card. You can, however, run a standard search to determine all documents in which the card number is used. Patt IMG > Sales and Distribution > Billing > Payment Cards > Maintain Blocking reasons. Display View "Blocking reason": Overview BG Blocking reason lack _Long Text be Great card lst or stolen © Card valid-from date © Default card You can assign a default card if there is more than one card for a customer. When you call up a list of cards for the customer in the sales order, this card is highlighted.Payment cards in sales orders: © Create or change sales orders with payment cards ‘+ Authorize transactions ‘* Call up work lists of sales orders with payment cards Because payment information is particularly relevant in the sales order, the sales order header includes a payment card plan. The card data you enter in the payment card plan is used throughout the order to cash cycle. Payment Card Plan: Plan attached to the sales order header and billing document header that contains information on payment cards used in a transaction. You reach the payment card plan by choosing Header > Payment cards. Display Standerd Order 32042: Header Date esata ae esa cdi Meare aereant Fano Tene Vrs Sas oxen hchieort | Pama Thee Cad ante Vato GV ela Meramaract Units Sata bttomdent Bh fa Go Re Pd ids IE [Fasteners zs FO Teste rans) io qd Jost beowos, 2/50 oa era ee NOTE: Payment card plan type should be assigned to the sales order document types for which payment cards are to be allowed in processing, this is done via configuration. With no assignment the payment card tab does not appear in the Sales order header for the particular order type. Standard SAP card plan type for payment cards is ‘03". Make sure corresponding return order types, credit and debit memo requests are also assigned payment card plan type. Path: IMG > Sales and Distribution -> Billing > Payment Cards > Maintain Payment Card Plan Types.Payment card plan structure: (Refer above screenshot for the fields below) The payment card plan contains a header which displays ‘© The authorized amount ‘© The total sales order value (net value + tax) ‘+ The amount to be authorized for the next service or delivery as well as the date of the next service or delivery You use these fields to process sales orders with multiple delivery dates. ‘The header includes a section on authorization, indicating: ‘+ Whether requirements for the authorization were met The system uses the requirements that you set in Customizing to decide whether or not to authorize the sales order. For example, you could set the system to automatically authorize complete sales orders. Or, you could disallow authorization in the sales order and use a report to authorize in batch at a later time. ‘Whether the system has set a block ‘+ The call status of the authorization, detailing if transmission to and from the clearing house was successful and whether a response was received ‘+ The results of checks by the clearing house on payment card data Another section in the payment card plan contains card items and authorization items: ‘* Card items contain detail on the payment card, such as card type, card number, expiration date, and billing information ‘* Authorization items contain detail on the authorization For an overview of the authorization, scroll right in the authorization item. For detailed information, select an item and choose Detail. The system displays all current information pertaining to authorization, including codes, accounts, times, and dates, Card items and authorization items at first glance may appear similar. To tell the difference between these items, note that authorization items:Do not have a Limit to indicator or a maximum amount Have a traffic light in the status field and authorized amount Authorization items detail: Display Standard Order 32044: Header Data [laccount cbtermhtion anaes ot value b= Te srount Grd information Card type ‘visa Card cateacry Card number aloaooon00000001 bep.cate reer card Verlication Value Cardholder PPD Test Payer (nor-Sc) ‘Authorization uth 55 Auth date authrefercode 7 Auth time ‘amt to be auth, 10.72 Authorized arnt 10.72 (03D auth, type A Manual authorization reauth Gfl account i5ea006 Merchant 1D zsas ‘Authorization statue GAP statue Call status | Extornal system reachodt respons... [ Bling status A) Not yet processed Enteral statis Text Response A 24.80 0.08 22C| credit card PPO 06/30/2011) isr07202) ‘There are two additional features at the bottom of the payment card plan. © The first is the settle ling docs button. This function provides you with billing information for cards in the payment card plan that has already been billed.‘+ The second feature is the manual authorization button. With this button, you can manually authorize a sales order during a telephone call to the clearing house. Processing Sales orders with single card: Enter the payment card information in the line item of Payment card (Header data) for the sales order value (Net + Tax), and SAVE the sales order. ‘Automatic authorization is carried out while saving sales order and authorized amount, status, blocks on authorizations if any are displayed. Each and every authorized amount creates a new line item in the payment card section as a log of the authorizations carried out. Automatic authorization is only possible with interface to third party software (e.g. Paymetric) connecting, SAP R/3 to Bank (Clearing house). If no interface setup then only manual authorization is possible. Manual authorization can be done by clicking on manual authorization button after selecting the line item containing the entered the card details. The amount to be authorized can be entered over here and authorization code notified by clearing house for the particular transaction. For test purposes in test environment some dummy value can be entered for the auth code and manually authorized, then save the order. Manual Authorization ‘Change Standard Order 32041: Header Data eesaesopay siitooan THMLSE | cHIETORER HELLY SHLON NG, SEB EEGE AEE ai pooner Ccortere serine sport Famer | Tees | Gr ota Ste | sausofit ashoatcn ac curte vaso ow cw uamestne Yaarn zon Uitte Sts thoes nt Seen meres)Select the line item with card information and click on ‘Manual authorization’ button. Enter amount to be authorized, auth code, auth ref code and go back to payment card screen, then save the sales order. Change Standard Order 32041: Header Data [Bfiaccount determinction anabsis Net value sao 248 Tex amount 3.00 cad information Card tyne visa Card category [EC) cra cars Pen) Card ruber —_—_[aiconannancana Speate 1 zya0ea Card Verticaton Value Cardholder PPD Test Paye:(hor-SC) uthorkation authuna a authdate orora011 Authretercods [234 Auth time 14:00:40 Amt tobe auth a0 ‘Authorized amt 3.00 [tsp auth, type [A)_ Manual authertation Ore GIL account 11590006 Merchant iD —_[1zeas ‘uthorieation status SAP status Cal statue C) External system reached: respors. Bing status 44) Not yot processedChange Standard Order 32041: Header Data Grsatioes sauna COFSTFFER ELSON SEE AVE. onnmet— # eaaererene aero | foarte i siielcedania vssio CW CWS CW ck Cre Nommaret Unto afidont a] | Fr atesooneses rm Poet Fear). eC) Ifa particular authorization is already billed then select the line item and click on ‘settled in billing docs’ button to list the invoice number. Only authorization log items that are not yet settled in billing can be manually deleted in the order. NOTE: Authorization can be done while saving order or authorize list of sales orders in batch at a later time. This is controlled by setting in configuration for ‘Checking groups’. (Refer to configuration of this in Authorization section later) Processing Sales orders le cards (Automatic authorization] ‘* Enter the payment card types, numbers, and expiration dates, or use the match code on the payment card number field to select cards listed in the payer master record, This data is required to continue processing the sales order. The system checks the card number and expiration date. ‘+ Enter maximum billing amounts for the cards. Select Limit to, choose Enter, and enter an amount in the Maximum amount field. To specify an unlimited amount for a card, leave the Limit to indicator blank. You can do this for only one card per order. Note that splitting amounts between cards may result in rounding. The amounts are split across the cards as per the maximum limits specified per card. If the amount is greater than the total of maximum limits of the cards then the remaining amount is automatically assigned to the only card with no ‘Limit to” checked. ‘* Choose Back and save the order to authorize the amounts on the multiple cards specified in the payment card plan.Authorization: When a customer pays for goods and services using a payment card, the card number, the. relevant amount and the payer’s name and address are forwarded to the clearing house for authorization. The clearing house checks this information, and either authorizes the transaction or turns it down. A successful authorization is a guarantee of payment. You require third-party software (e.g. Paymetric XiPay) to carry out authorization. The system relies on settings in Customizing for payment cards to determine how and when to carry out authorization. Risk Management (Covered in later section) affects authorization process. With the authorization functions in payment card processing, you can: Set the system to authorize sales orders according to a certain set of requirements Preauthorize sales orders ‘Automatically authorize sales orders Manually authorize sales orders Determine which colleagues are permitted to manually authorize sales orders (authorization profile V_VBAK_AAT) Run a report to carry out authorizations in batch (RV21A010) Run a report to call up a list of sales orders with payment cards according to document features that you specify (RV21A001) Display complete current authorization information in the payment card plan. Use the authorization log to check the history of authorization changes in a sales order, including change dates and responsible parties (Choose Environment _ Changes)Path: IMG > Sales and Distribution > Billing > Payment Cards > Authorization and settlement > Maintain Checking groups. Actives Pe... Name of Activity oY [Assis checking groups wo Define checking groups Define checking groups: Display View "Payment Cards: Checking Groups - Sales Doc.”: Overview BEB ‘ckcroup_Descriation ‘AuthReq Preau. |AHorien Vali ft uth in ordsave 1 Oo a+ 22 auth in batch 2 7 a In the above screenshot, AuthReq column has routines ‘1’ and ‘2’ in SAP by default. Routine 1 allows authorization to be carried out in sales order when saved and routine 2 allows authorization of lst of sales orders at once in batch by using report: RV21A010. Select Preau for preauthorization. The system performs preauthorization when you enter and save a sales order. In this procedure, a ‘soft’ authorization is sent to the clearing house with an amount of $1 to check that the name, address and card number is correct. In this way, the risk of problems with the actual authorization, made at a later date, is reduced. The system carries out preauthorization when the material availability date, or biling date lies outside of the authorization horizon, that is, before the authorization horizon takes effect. When the authorization horizon does take effect, the system does not carry out authorization automatically. AHlorizn (Authorization Horizon): Authorizations may sometimes expire before an order is delivered or billed. To reduce the chances that this will happen, you may want to authorize orders only several days before they are due for shipping, or billing. The authorization horizon specifies the number of days before the material availability date, or billing date, that the system is to initiate authorization. Ifa sales order is saved within the authorization horizon, the system carries out authorization immediately. if a sales order is saved before the authorization horizon comes into effect, the system does not authorize at all, or carries out reauthorization. In the above screenshot ‘7 days’ is being used for Auth horizon. Valid: Specifies the minimum number of days after the payment card is entered that you require the card to be valid. The system issues @ warning message if the card expiration date you enter in the sales order iswithin the validity horizon that you specify here. Note that the expiration date is not checked against the dates of the schedule lines. You require all payment cards to be valid for at least one month after entering the payment card. Hence 30 days has been entered as in the above screenshot. Assign checking groups: (The assigned order types will authorize credit cards as per the auth check group, Make sure that corresponding return order, credit/debit memo order types are also assigned the checking groups) Display View "Sales Documents: Types - Checking ¢ Baa say Desertion CkGroup Descristion fai] ‘YORT 3rc-party std order 21 auth in ord save PR Promotion Order YERP Pre-nortfalio Order YERT Sdparty Promo Order RE Return Refusal z1 auth in ord save YREL Reprise Negotiated YRE2 Reprise Seasonal Prd YRE3 Reprise Ref invoice YRE4 Reprise at Date YRES Reprise Lest at Cust YRE6 Return Refusal Store YREG Returns Order DEG 21 auth in ord save Specify Authorization Validity periods: In this step, you specify the number of days that authorizations are valid within the SAP System for each card type. Path: IMG > Sales and Distribution > Billing > Payment Cards > Authorization and settlement -> Specify Authorization Validity periods.Display View "Payment Card Type: Validity Period of Auth.": Overview BEE Type Desciption vad Sparx Amex crecit card zt MC Master Card 28 tos VISA Visa card 28 System Reactions to Document Changes Note that the system automatically reauthorizes when yo ‘* Add an item to the sales order © Raise the sales order value ‘© Change a schedule line quantity The system issues a message, warning you to reauthorize when you ‘* Increase quantities in the delivery. © Increase the value of the billing document. * Have an incomplete delivery for which the authorization has expired System Reactions to Unsuccessful Authorization In some cases, an authorization may be insufficient or the clearing house may request a block for a lost or stolen card. The system reacts to a failed authorization, by: ‘+ Setting the overall credit status to ‘Not approved’ in the sales order header (status B) ‘* Setting the authorization block in the payment card plan Use report RV21A001 to process blocked sales orders. You can then reauthorize by removing the block and saving the sales order. ‘+ Resetting the confirmed quantity to zero in the sales order and blocking the entry in the shipping index.Handling Unsuccessful Authorizations: * Release an order without authorization (and take your chances on collecting). ‘* Resubmit an order for authorization. © Change an order (which will trigger automatic reauthoriz n by the system) Risk Management for Payment Cards: Risk Management plays a central role within Sales, providing you with checks and functions to minimize your credit risk. In addition to letters of credit and export credit insurance, payment cards are among the payment guarantee forms that you can use to insure payment for sales order items. Note that when a payment card is used in a sales order, the payment guarantee form for payment cards takes precedence over the others and is activated first. Because Risk Management affects amounts and dates in the authorization process, you must make the appropriate settings for sales order types in which payment cards are used. Here, you can define payment cards as a form of payment guarantee, and maintain an appropriate procedure. In the same way as for the credit check in Credit Management, the system sets an internal status for Risk Management that influences the overall credit status. You can use this status to prevent certain subsequent functions from being carried out for documents that have been blocked due to payment guarantee, in this case failed authorizationPath: IMG > Sales and Distribution > Billing > Payment Cards > Authorization and settlement > Risk Management for Payment Cards. Display IMG GH | BisthaBcsets sree sets Ge Activated structure +B Bilin » B Biling Documents + By Paymant Cards + By ® Maintain Card Types + Be © maintain card categories + By © maintain Payment Card Plan Types > By & Maintain Blocking Reasons > By__ Authoriation and settiement ~ By __ Fisk Management for Payment Cards + By & betne forms of payment guarantee + By & Mantan Payment Guarantes Procedures Path: IMG > Sales and Distribution > Billing > Payment Cards > Authorization and settlement > Risk Management for Payment Cards. > Define forms of payment gurantee. Define forms of Payment guarantee: Display View "Maintain forms of payment guarantee": Overview Q@REB PayG|Pymt... FOcat |FOType| Form af payment guarantee a 1 0 COL Confirmed revocable letter of crecit = 03 0 0k Unconfirmed irevocable letter of credit 04 0 ©6600 GuarenteePath: IMG > Sales and Distribution > Billing > Payment Cards -> Authorization and settlement -> Risk Management for Payment Cards-> Maintain Payment guarantee procedures. Maintain a Guarantee Procedures: Activities Pe... Neme of Activity Petine Payment Guarantee Schema Define Customer Deternination gcheua Define Docuent Determination schema Assign Document Schema to Order Types Define Payment Guarantee Schems Determination Define Payment Guarantee Schema (SAP default procedure used is: 000002) Display View "Payment guarantee determination procedure": Overview BEE Daeg Suu 7 GUhoyment gurantee determination procedure + Cafes of payment guarantee I Paym.ouange. Payment custartes procedure [oocoez rect cad nayment gurantee proc | econ “Gadt cad paynent gauranteo crocDisplay View "Forms of payment guarantee”: Details a) Dilog Structure ~ Creynent querantes dete + GaFoms of payment Pay ourart pro. [OOOO pent cart rament wanton ree Sequential number 10 Paymt guarantee form (02 Payinent cards Attribute for fon of payment quarantes Fnancal ac. cat. Financal dec, type Payment Guarantee Requirement Routine number 0 Define Customer Determination Schema (Not needed for payment cards guarantee procedures). Define Document Determination Schema: (SAP Default value used is ‘O1") Display View “Maintain control of payment guarantee procedure”: Overvi Ps Payment guarantee procedure: a 01 credit card payment gatrantoo doc orec = fed “bee determ schema for crect card = Assign document schema to order types: (For e.g. ord type YOR in below screenshot, make sure it is assigned to related return order, credit/debit memo types) Display View "Risk Management: Document Control": Overview Bae SaTy_Descriotion Pa Payrrent quarantse procedure | [sar [ror Standard Order ©1 credit card payment gaurantes doc proc - ‘oR arckpaty std aides E YPR Promotion Order Define Payment Guarantee Schema Determination: (doc guarantee schema 01 is assigned to guarantee procedure 000002 in below screenshot)Display View “Maintain customer/doc assignments to payment guarantee p @Baa ae [pa (Pv. oe oe a Ta coooa ~ (2caR ze zccool ba NOTE: Without Risk guarantee procedures for payment cards setup as in above screenshots, GL account determination for payment card receivables is not possible. (Refer to the account determination setup and merchant id setup for clearing house in later sections).Payment card guarantee appears at header and line item level in sales order in the Billing tab. (Refer to Risk Management section in below screenshot) Change Standard Order 32041: Header Data Be 2A standard Orlar fazoar Purchaco ardor na, fect ced cad iois6 | CHRISTOPHER KELLY SALON ING, / 386 EDGE AVENUE / V. Payment cards ‘Cenditions | Account essigrme Payer ac03as PPD Test Payar (hon-SC) 50, Connal drive / BERKELEY | Delvary and payment tems | fo ‘pwn |] redvaldio TemscfPament ‘0399 Standard Crder c000032385 |o6/29/2011 Completed ~ B Delivery on7o003763 06/29/2011 Completed + B hanuling unit oono74e523 06/29/2011, + Bi wns transfer order ocooooses+ 06/29/2011 Completed + Bip gous issueidehy «900008828 06/29/2011 complete > B invoice o7a0007558 08/29/2011 Completed ig] 06/29/2011 ClearedFor e.g. GL account 1590006 (VISA Card type) is where credit card charges are posted as in below screenshot (a Ding lay Daciament Data Entiy view PGE B itn: Boppy cinerey Dower Lecger view Daa Ene VeW Document unter [OWOO06IS | cengany Coda [B10 Fecal Yor fon teemencnae [06/2s/zo1i| _Festrqoste (05/29/2013) Pence foference oto00s%es —ansscc na 1 urencr (ve eet Lota Goan @GFRRs) Ele) PC Rey bo od MMR acount “Dosen fs, Mocs Cantey of Cor] Anaurtin ELE |Asienment 6 oun fot axon PRD Testraye fer) “00 mae, 74 UD) test adcad + ous 918) FPO Tost paar (en's) 3200 som 78. USD tos aedcad (oug, 8/50. ace Trdrecasn Dee Ace S200 a2 gi us zone Tsp mpItOn Ryty PbS sao same oe uD 250 coreenn NS Gisscer SnD sao sosn- uso 20110809 340 QUIS rato Abswreehood 200 a2 347 us cons cd rade Alowarcafecd Zu aa Gur uD Zone 540 PII Povtroenoe a0 ae a1 we =OnaK 40 SOD Gap Take Teh sno 00 28 uso z01108e9 Only the receivables collected in GL for each payment card type of credit card institution is open which gets cleared during settlement program run and posted to cash clearing account of the clearing house. Once posting is done to cash clearing account the receivables information is transferred from the clearing account to the clearing house for cash payment on credit card charges posted. (Refer to SETTLEMENT section for further details on this process) GL account for payment card receivables is determined in sales order that flows down to billing and accounting documents. The setup is done via Account determination condition technique in configuration for payment cards as below: The condition technique is used for determining clearing house reconciliation accounts for authorization and settlement. The system uses the entries here to determine the clearing account for the payment card charges. When settlement is run, the postings in the receivable account for the payment card will be credited and a consolidated debit will be created and posted to the clearing house account. These accounts are a special type of general ledger account that is posted from Sales and Distribution.Path: IMG > Sales and Distribution > Billing > Payment Cards > Authorization and settlement > Risk Management for Payment Cards-> Maintain Clearing House > Account Determination. Display IMG at | Existing BC Sets i°BC Sets for Activity stucure ~ Br bina » Ey Bling Documents + Bi ___Payment Cards + EB @ Maintain Card Types + & & maitain Card Categories + By & mairtan Payment Card Plan Types + By & Maintain Blocking Reasons ~ Br __ Authorization and Sattiement +B Risk Management for Payment Cards + By @ Maintah authoreaton Requirements + By & maintain checking Groups ~ B® specify authorization validity Periods ~ Bi Maintain deating House ~B__ ecount Determaton] + By & mantan Fed catalog + By © Maintain Condition Tables + By & mantain access Sequences + By & Maintain Condition Types + By ® mantain Procedures + B® assion Git accounts Standard SAP access sequence A001 is maintained with two default condition tables: Display View "Accesses": Overview vEER Dajog Seat secass sequence [Ait stndact + Cisceees sequences on aca ve [Td Dmcntin eke feb seated ° mo 4 Grea 0Access seq A001 is assigned to newly configured custom condition type: Display View "Conditions: Types"': Overview BEE Overview of Cendtion Types Tye Name |ASDescrition Tranedtcatcotina 00) Se New account determination procedure is configured with the above condition type: Display View "Control data": Overview VHA Dadoa Structre Procedure ECAR Credt cad GL account posting ~ Goprececures + Sconiral data Reference Step Cvetvew Step Co... CTyp Description Reguremnt & Poston | Entry Lot 1The Account determination procedure for Payment card GL accounts is assigned to respective billing document types as below: (Make sure to assign to invoices, credits/debits etc) Display View “Billing doc: Billing type - G/L account determination pr BEG BIT [Description ADP... |Dasciption o fear: phestor Tian. ¢ - FL Inwoice ZCCARD Credit card GL account posting ted re vce Z2eaD Ged cack account postr F5 Pro Forme for Order FB Pro Forma Inw FD Assignment of GL accounts: Assign G/L Accounts SQ BR 47 ae HEE Assign G/L Accounts Table Description | 4 Benera 6 Se0raiCard cat. ‘As can be seen below, each payment card type is assigned a different GL account per sales org to post receivables for payment card transaction charges: Display View "SlsOrg/Card cat.": Overview BEBE SisDraCard cat, ChdTy. chéc SOrg. Type G/L Account Provision acc, 2caR 1110 (200 AMEX 1590007 i 2caR F110. 0209 MC 1ss00n6 zcaR 7110 0200 VISA 1s90006GL account for payment cards is determined in sales order payment cards tab, authorization item details based on above configuration and flows down to billing and accounting via copy controls, Change Standard Order 32385: Header Data Gl account determnation anatysis Net vals j= > 70a) Tox amount ne) card ype ‘waea card category cred card PPD Cardnumber __A1coos990006c00 ———*| Esp.cite 1970838 | Card Yenfication Value rl] acho FFD Test Payer (norr9C) a uth dato 6/29/2011 suthietercode 348 ————*d auth tme 1620706) Amt to be auth, 7.04 | authored art 7.04 ith fps __ |] Manual aterenton Dirrcauth, G/L account ‘isso005 Mechent 0 [2885 Click on Account determination Analysis on top of the authorization item detail screen (as in above screenshot) to view the GL account determined for the card type used. Analysis Acct Determination (Procsdire Descietion |= G@izcoxo \cetitcart acc. BS ve) Details on condition type ZCAR ene | © Git) soarcsct | + Basen cereal 2h 12 Cerefer raced nas been specie 2cah 215 GlL seount i eoeumert 9001530005 eco Message Desr6ton 30 103 Cercter record hes been soc 20 (27 Accaserat mace ue to a pavous acestLinking Payment card receivables GL account with Cash clearing account: Path: IMG > Sales and Distribution > Billing > Payment Cards > Authorization and settlement > Risk Management for Payment Cards-> Maintain Clearing House ~> Set Authorization / Settlement Control per account. Display IMG SEG cwctrgecsets spe structure ~B__ Bilng + By Biling Documents ~ By__ Payment cards + By ® Mantann Card Types + Ey ® Maintain Card Categories + B® Maintain Payment Card Plan Types + Ey ® Maintain Blocking Reasons > By Authorization and Settlement » By Risk Management for Payment Cards + By @ maintan authorzaton Requirements + Ey ® Maintain checking Groups + By & Specify Authorization Validity Periods > By Maintain clearing House ~ B__ Account Determination + By & maintain Field Catalog + By © maintain condition Tables ~ By & maintain access Sequences + By @ Maintain Condition Types + By © mantain precedures + By @ assign Git accounts + B & Set Authorization / Settlement Control Per Account ? Table View dt Goto Selection Utes System Help @ */I8'6@@ SHR AXHLA ADO Display View "Clearing account/external functions": Overview GGBE hac Receivable Short Text (Clearing [Short Text oO 7110 1590006 (open) 1713803 Cash Drawer { = ¥110 1580007 (o2en) 1713503 Cath Drawer ¥ Pi1o 1590008 (open) 1713509 Cash DrawerSelect and click on details of each assigned item of receivable and clearing accounts: (Below screen appears) ‘The function modules appearing in the below screenshot for authorization and settlement are local FMs provided by SAP R/3 for local authorization and settlement runs for testing. These FMs are to be replaced by the new FMs that will be provided by the Service Company (Paymetric Interface) in order to carry out real authorization and settlement in production environment. Display View "Clearing account/external functions": Details aga Cart of Accounts pos Pent ed veces evo) [epen) cleaing account ‘rissos | (Gehbrawer | Authorization control functions ‘authorzation CCARD_AUTH_ SIMULATION Initiiztion Authorization SET Result Authorization (SET) REC dostinatione of furctione Settiement contial functions Settlement CCARD SETTLEMENT STHULATION REC destination of functions Settlement answerMerchant IDs: Aunique number, issued to a merchant by 2 clearing house, that identifies this merchant in payment card transactions. Path: IMG > Sales and Distribution > Billing > Payment Cards > Authorization and settlement > Risk Management for Payment Cards-> Maintain Clearing House > Maintain Merchant IDs. Display IMG TE | Existing BC Sets sib: stsfor Activity Spactivat Structure ~B__ Biing » By Billing Documents > Be Payment cards + By & Maintain Card Types By & maintain card categorios By & Maintain Payment Card Plan Types By & maintain Blocking Reasons ~ By__Authoricaton and Settiement + By Risk Management for Payment Cards + By ® maintan euthoreaton Requirements + By & mantan checking Groups + By ® spectty authoreation validity Periods ~B__ Maintan dearing House ~ B__ Account Determination + By © Mantan Fie Catalog + By @ Maintain Condition Tables + By © mantan access Sequences + Bs @ mantan Condition Types + By © mantain procedures + By ® Assign GIL Accounts + Ey & set authorization J Settlement Control Per Account + Be @ Maintain Merchant 1Ds Activities Pe... Name of Activity Assign merchant. TDs Enter uerchant IbeEnter merchant IDs (Merchant ID used here is a dummy value, real IDs should be provided by the Clearing house) Display View “Merchant IDs": Overview BEB Merchant 10) Description 4 Assign merchant IDs: Display View "Assign Merchant IDs": Overview BE Chae Receivable Short Text Merchant ID Description i 1.0 1890006 (epen) 1284s ‘test merchatid for paymetiic | test merchant id for paymetri: test merchant id for naymetri= PLio 1890007 (cpen) azsas PLLO 1s90008 — (cpen) azsasSettlement_of Payment card charges: Settlement Run is done via FCC1 transaction to post payment card receivables to the clearing house account: The settlement document created after the run is a report that is then transferred to the clearing house for cash payments on card charges. RECCSIMU program can be used for simulating settlement before submission. Settlement execution log can be displayed as settlement document report, Any line items that are not cleared due to unsuccessful settlement for any reason can be displayed as reset cleared items. Payment Cards: Execute Settlement o cena Seber Company Code ‘Bio Payers card caves ss0008 8 ther Slaton Parent cad bre merchert Tas Curercs Pont of ecept Payment card cat seece sll] Danmar aie Fic You aa Frc En oamant type ia Dour Date Posty ote 7708/2004 80 Precesng eaamaters esi 2 @ ‘Tere shes dita “peta bo Uda Fun Transaction FS10N can be used to verify balance in payment card receivables GL account before and after settlement run.Settlement Document Type configuration Configuration settings for the settlement document type to be used to display results of settlement run for both successfully cleared/settled and unsuccessful settlement/reset of cleared items. (Refer screenshot below). Path: IMG > Financial Accounting > Accounts Receivable and Accounts Payable > Business Transactions > Payments with Payment cards > Make central settings for Payment cards. Display IMG TH | existing Bc sets stucture + Cress-Application Components > By inaneal Accounting > By Francia Accounting Glabal Settings » BB cenetal Ledger accountna +B __ Accounts Recewable and Accounts Payable » By Customer Accounts » Be Vener accounts ~ By Business Transactions > Incomning Invaces/Credt Memos Raloase for Payment Gutaoira Payments Curgairg Invaices/credte Memos Incoming Payments Payments with Payment Cards + By @ Make central Settings for Payment Cards SUPPPe Display View "Payment cards: Central FI settings”: Details ca SGtinge for Grwaraine bina Slaecrnert= tar Satine eatnepaereEaoCITET Document Tepe hs) Settings for rasettina clearing when sattiemant unsuccessfilNotes and Additional points: Follow the flow of screenshots in the above tutorial for configuration of payment card processing. Partial authorization of Sales order value should be possible simulated and tested in 080. E.g. partial authorization of sales order value allowed account posting in bill (Screenshot below) Document Flow Histatus overview — Gebisplaydecument Service dacument: [Hy 32.adcitional Inks Business partner 0000800343 PPD Test Payer (non-SC) (14)! Document On status + B Standard Order ooc0032047 7/11/2011 Completed + DB delvery 0070003886 07/11/2011 Completed > B sp imoice 700007474 7/11/2011 Completed + Bilsccounting document 0700000116] 07/11/2011 partly clearedBilling Invoice 700002646 (F2) Display : Header data > Railing items accountng fffoutput [row ~|roonzeaé | Payer 0033 PPD Test Payer (nan-SC) | $0, Connal chive / US - 07622 BE Created by Us2HANDA [Created on (07/11/2011 Tme 1:83:58 _ {eos orters_\Conctons | ForTacejcustors | Hesdtect_ | Accounting Data ailing Date Document Cuarency Corrpany Coda (Det exchange r Reference oo7ocoo3s1 Exchange rate-acntg [1.00000 Assignment test ced cad 4 [Payinent Method ~ Tiading Partner ] Durning Area ¥ Fired value dete Durning key Si Addit.value days o| Durning block AcctAssoGr Posting status Tested (ia acthowation) Since Payment card information is maintained in general data of customer master record, the same card information can be used in sales orders for every sales area for which the customer is defined. Restriction on payment cards to be used only for PPD business can be applied by blocking Sales orders (Delivery and billing blocks) for further processing and setting user status as blocked if payment card information is used for other sales areas while order CREATION/SAVE via MV45AFZZ (Include program) in order save user exit. Similar functionality is already used to block orders for different processes in current system, so need to leverage on this user exit to implement the restriction....(TBD)References: ‘+ This tutorial on Payment card functionality for SAP R/3 is sourced mainly from: (a) ‘SAP_payment card procesing SDBILIVPC. pd ‘+ Please refer to the above attached document for further information, especially on work lists/reports to list documents related to payment cards, how payment cards are processed in sales orders, deliveries and billing documents which is not covered in detail in this tutorial,