Credit Card Reconciliation
Where does Credit Card Reconciliation Occur, and which form it is suppose to be interfaced with?
The solution will provide a function to reconcile these card-level adjustments with the associated card balances displayed on A Bank provided reports. If an agency-level download capability is added, all activity will be imported into the financial solution on a daily basis. After cardholders have entered individual charges, the system will allow an effective, workflow-managed reconciliation process.
These are user-to-user forums, you are not talking to Apple here - I've asked the hosts to remove your email address and phone number from your post.
You can contact iTunes support via this page : http://www.apple.com/support/itunes/contact/ - click on Contact iTunes Store Support on the right-hand side of the page, then Purchases, Billing & Redemption
To try and stop it happening again you can turn off in-app purchases on your phone via Settings > General > Restrictions > In-App Purchases 'off'
Similar Messages
-
Hello! Really sorry! Originally this APP software free game, only peace of mind to let children play, but a recent credit card reconciliation only to find the charges and found that the game content is not completely free, content or Payplay games, children do not understand the meaning, pressed by mistake to the game fee of options found APP software fees has been removed, the 3 pen order really is not a small amount, a small fortune in Taiwanthe burden, the normal person would not spend such fees to play mobile games, kids really are unintentional, Sorry! hope you can help me claim to cancel the game cost very grateful!
PS: order number --- 1.MH****Z0J --- 2.MH****4QJ --- 3.MH****6NQ
My English is not good, please forgive me.
<Personal Information Edited By Host>These are user-to-user forums, you are not talking to Apple here - I've asked the hosts to remove your email address and phone number from your post.
You can contact iTunes support via this page : http://www.apple.com/support/itunes/contact/ - click on Contact iTunes Store Support on the right-hand side of the page, then Purchases, Billing & Redemption
To try and stop it happening again you can turn off in-app purchases on your phone via Settings > General > Restrictions > In-App Purchases 'off' -
Credit Card Refunds, Deposit Form, and Bank Reconciliation
Our Credit Card Refunds do not show in the Deposit Formm, can they?
Without the refunds showing in the Deposit form, our bank reconciliation does not match the bank. We have to create a separate JE to move the refund from undeposited cash to the bank account. Now the bank shows one deposit of $100 and we have two transactions, a deposit for $120 and a refund for -$20 for a combined total of $100.
This make the audit trail very convoluted.
Is there a setting to show the refunds in the Deposit Form?
Thanks,
Rob
Edited by: Rob Burke on Nov 25, 2009 11:19 AMThanks Gordon,
We do add the credit memo and payment on account. We want this payment on account to show in the deposit form so that the deposit matches the credit card deposit.
Deposit the following amounts $10 + $12 +7 and refund $2. Our credit card processor deposits $27. SAP deposits $29 via the Deposit form and then we create a journal entry for the $2 refund. We would prefer our reconciliation to match the bank statement and show a single entry for $27.
Thanks for your help anyway.
Rob -
Purchasing & A/P Credit Card Processing
We have cases where we place purchase orders to vendors with a company credit card. We would like the PO to be for the actual vendor. When the Goods are received, we would perform a PO goods receipt and A/P Invoice. When the A/P invoices is paid, we need the check to go to our credit card vendor. We would not do a wire transfer to the credit card vendor.
Plus more than one person with thier own company credit card could purchase from the same vendor.
Any suggestions or ideas would be greatly appreciated.Scott,
The process you outlined is a little different than how the system is set up to handle Credit Card purchases.
This is the standard process:
1. Setup a GL Account as a clearing account for each Type of Credit Card (helps big time with reconciliation to the cc statement)
2. Set this account as the credit card's account in Banking setup
3. Create the PO, GRPO, and Invoice for the actual Vendor you're purchasing from.
4. When you do the A/P Invoice, you could process an outgoing payment there by clicking the Payment Means button (money bags)
5. Choose the Credit Card tab
6. Select the Credit Card that was used
you could have a card setup to represent each card in your company, or use one card in B1 to represent them all.
7. fill out any extra information about the card you want to capture
8. You now have closed the Invoice and created the Outgoing Payment by Credit Card
9. The outgoing payment hit the credit card clearing account
10. Now do an A/P Invoice - Service Type for the Credit Card Vendor
11. In the GL Account field, select the Credit Card clearing account
12. Put in the amount the Credit Card company billed on your statement
13. Add
This process creates a temporary AP for the first Vendor, paid immediately by Credit Card.
That clears the AP and moves the balance to the CC Clearing Account
The AP Invoice for the Credit Card Vendor as Service Type with the offset GL set to the CC Clearing Acct moves the balance from the CC Clearing Account into AP for the Credit Card company. You can then pay this AP Invoice as you would any other.
That's not to say you couldn't automate this or devise a simpler process that accomplishes a similar result, but that's the "official" way to process AP Credit Cards and seems to be the most correct accounting wise.
Hope this helps.
Brad Windecker -
Outgoing Payment - Credit Card
Hi All,
We have a company credit card. With this card, we may pay say 5 different vendors.
Since I cannot find a kind of "deposit" function for outgoing payments, I am thinking of this:
1. Create a "credit card prepayment" GL account in Assets
2. Do all 5 outgoing payments from this GL account (ignoring error message about cash flow report)
3. When we get the credit card statement to pay each month, doing another outgoing payment from my bank account to the "credit card prepayment" GL account
4. Manually internally reconcile "credit card prepayment account" GL
Can anyone suggest a better way, or does this look ok? The error with cash flow report is odd, as on one hand the amount of money has been paid, but on the other, is still owed to credit card company.
Thanks!
Rajiv
Edited by: Rajiv Agarwalla on Feb 23, 2009 7:33 PMIf there is a way to use an interim GL account similar to "cheque clearing a/c" for incoming payments, but for outgoing payments, then of course that is perfect!
We are trying to do the same thing but manually (it makes external bank reconciliation easier, as only 1 entry for payment to ccard company as per bank statement).
I tried to go to:
Banking->Outgoing Payments->Outgoing Payments->select Vendor/GL, tick amt, then click money bag, then Bank Transfer tab.
However, I do not see an option for interim GL account? I can see how to set this up as you suggested, but we wish to make payments manually each time and not using the Payment Wizard. Is there another way of utilizing this deature?
Thanks again,
Rajiv
Edited by: Rui Pereira on May 1, 2009 10:47 AM -
Credit Card Payment Processing
Dear Experts,
We are implementing CRM and need your help to crack below D2C Scenario :-
While booking the Sales order, Customer gets charged on his/her Credit Card (prepayment).
The sales order then flows to R/3 and subsequent processes viz. Pick/Pack, delivery & PGI get executed. At this stage following accounting entry gets generated
Debit COGS
To Inventory
After billing, system gerenarates only one accounting document with the following entries
Debit Customer 100
Credit Revenue 100
Credit Customer 100
Debit clearing account 100
This is creating problems in terms of:
1. Bank Reconciliation( there may be a lag between SO and billing so the received amount may remain unaccounted till billing is done and hence the Bank reconciliation would not be possible)
2. Reversal of billing document will reverse the collection as well.
3. Refund of any amount to customer only can be posted along with credit note to customer. If we try reverse the payment transaction, the billing would also get reversed and vice versa. Sales return will also be a problem when a credit has to be issued to the customer.
__The client requirement is__ :
1. Generation of "Payment Received" document at the time of Sales order (payment authorization)
2. Generation of "Billing Document" Dr. Customer To Revenue at the time of billing
Appreciate if you could share your experience on the captioned requirement.
Can anybody suggest how to solve this.It's nothing personal against PayPal, I'm currently
investigating their PayFlow Gateway:
https://www.paypal.com/cgi-bin/webscr?cmd=_profile-comparison which
looks like a payment processor sans the customer interaction with
PayPal. Unfortunately I can't seem to find any specifications on
European currencies and communications with credit card banks.
Since we have a merchant account we only need a service to
authorize and bill users credit cards, no shopping basket, no
processing through the Service's own bank.
Has anybody used PayFlow gateway? -
HI,
Can any on tell me settings related Credit Card functioanlity and config settings related to SD module
Regards
Ajoydear ajoy
This is how you can configure for credit card payments
regards
swapnil
Set Up Credit Control Areas:
Define Credit Control Area
Transaction: OB45
Tables: T014
Action: Define a credit control area and its associated currency. The Update Group should be 00012. This entry is required so the sales order will calculate the value to authorize
Assign Company Code to Credit Control Area
Transaction: OB38
Tables: T001
Action: Assign a default credit control area for each company code
Define Permitted Credit Control Area for a Company
Code
Transaction:
Tables: T001CM
Action: For each company code enter every credit control area that can be used
Identify Credit Price
Transaction: V/08
Tables: T683S
Action: Towards the end of the pricing procedure, after all pricing and tax determination, create a subtotal line to store the value of the price plus any sales tax. Make the following entries:
Sub to: A
Reqt: 2
AltCTy: 4
Automatic Credit Checking
Transaction: OVA8
Tables: T691F
Action: Select each combination of credit control areas, risk categories and document types for which credit checking should be bypassed. You need to mark the field no Credit Check with the valid number for sales documents.
Set Up Payment Guarantees
Define Forms of Payment Guarantee
Transaction: OVFD
Tables: T691K
Action: R/3 is delivered with form 02 defined for payment cards. Other than the descriptor, the only other entry should be 3 in the column labeled PymtGuaCat
Define Payment Guarantee Procedure
Transaction:
Tables: T691M/T691O
Action: Define a procedure and a description.
Forms of Payment Guarantee and make the following entries Sequential Number 1
Payment Guarantee Form 02
Routine Number 0 Routine Number can be used to validate payment card presence.
Define Customer Payment Guarantee Flag
Transaction:
Tables: T691P
Action: Define a flag to be stored in table.
Create Customer Payment Guarantee = Payment Card Payment Cards (All Customers can use Payment Cards).
Define Sales Document Payment Guarantee Flag
Transaction:
Tables: T691R
Action: Define the flag that will be associated with sales document types that are relevant for payment cards
Assign Sales Document Payment Guarantee Flag
Transaction:
Tables: TVAK
Action: Assign the document flag type the sales documents types that are relevant for payment cards.
Determine Payment Guarantee Procedure
Transaction: OVFJ
Tables: T691U
Action: Combine the Customer flag and the sales document flag to derive the payment guarantee procedure
Payment Card Configuration
Define Card Types
Transaction:
Tables: TVCIN
Action: Create the different card types plus the routine that validates the card for length and prefix (etc )
Visa , Mastercard, American Express, and Discover
Create the following entries for each payment card
AMEX American Express ZCCARD_CHECK_AMEX Month
DC Discover Card ZCCARD_CHECK_DC Month*****
MC Mastercard ZCCARD_CHECK_MC Month
VISA Visa ZCCARD_CHECK_VISA Month
The Routines can be created based on the original routines delivered by SAP.
*****SAP does not deliver a card check for Discover Card. We created our own routine.
Define Card Categories
Transaction:
Tables: TVCTY
Action: Define the card category to determine if a
payment card is a credit card or a procurement card.
Create the following two entries
Cat Description One Card Additional Data
CC Credit Cards No-check No-check
PC Procurement Cards No-check Check
Determine Card Categories
Transaction:
Tables: TVCTD
Action: For each card category map the account number range to a card category. Multiple ranges are possible for each card category or a masking technique can be used. Get the card number ranges from user community. Below is just a sample of what I am aware are the different types of cards.
Visa Credit Expires in 7 days.
400000 405500
405505 405549
405555 415927
415929 424603
424606 427532
427534 428799
428900 471699
471700 499999
Visa Procurement Expires in 7 days.
405501 405504
405550 405554
415928 415928
424604 424605
427533 427533
428800 428899
Mastercard Credit Expires in 30 days
500000 540499
540600 554999
557000 599999
Mastercard Procurement Expires in 30 days
540500 540599
555000 556999
American Express Credit Expires in 30 days
340000 349999
370000 379999
Discover Card Credit Expires in 30 days
601100 601199
Set Sales Documents to accept Payment Card Information Transaction:
Tables: TVAK
Action: Review the listing of Sales Document types and enter 03 in the column labeled PT for each type which can accept a payment card
Configuration for Authorization Request
Maintain Authorization Requirements
Transaction: OV9A
Tables: TFRM
Action: Define and activate the abap requirement that determines when an authorization is sent. Note that the following tables are available to be used in the abap requirement (VBAK, VBAP, VBKD, VBUK, and VBUP).
Define Checking Group
Transaction:
Tables: CCPGA
Action: Define a checking group and enter the
description. Then follow the below guidelines for the remaining fields to be filled.
AuthReq Routine 901 is set here.
PreAu If checked R/3 will request an authorization for a .01 and the authorization will be flagged as such. (Insight does not use pre-authorization check).
A horizon This is the days in the future SAP will use to determine the value to authorize
(Insight does not use auth horizon period).
Valid You will get warning message if the payment card is expiring within 30 days of order entry date.
Assign Checking Group to Sales Document
Transaction:
Tables: TVAK
Action: Assign the checking group to the sales order types relevant for payment cards
Define Authorization Validity Periods
Transaction:
Tables: TVCIN
Action: For each card type enter the authorization validity period in days.
AMEX American Express 30
DC Discover card 30
MC Master card 30
VISA Visa 7
Configuration for clearing houses
Create new General Ledger Accounts
Transaction: FS01
Tables:
Action: Two General Ledger accounts need to be created for each payment card type. One for A/R reconciliation purposes and one for credit card clearing.
Maintain Condition Types
Transaction: OV85
Tables: T685
Action: Define a condition type for account determination and assign it to access sequence A001
Define account determination procedure
Transaction: OV86
Tables: T683 / T683S
Action: Define procedure name and select the procedure for control. Enter the condition type defined in the previous step.
Assign account determination procedure
Transaction:
Tables:
Action: Determine which billing type we are using for payment card process.
Authorization and Settlement Control
Transaction:
Tables: TCCAA
Action: Define the general ledger accounts for reconciliation and clearing and assign the function modules for authorization and settlement along with the proper RFC destinations for each.
Enter Merchant IDs
Transaction:
Tables: TCCM
Action: Create the merchant ids that the company uses to process payment cards
Assign merchant ids
Transaction:
Tables: TCCAA
Action: Enter the merchant ids with each clearinghouse account -
In sales through credit cards , the amount is splitting .
Dear Community ,
I have problem with invoices which are being paid by credit cards . The authorized amount is splitting . For example , if invoice value is 500 , the amount is splitting as 400 , 70 , 20.5 , 6 ,2.5 , 1 .. the split is happening illogically and reconciliation of invoices is becoming very difficult .
Also in the corresponding sales order, in header- payment cards tab , this split is coming ...
Why this is happening . This is having a big impact as the customers are not preferring to buy though credit cards and sales are coming down .
request your inputs on this
Thanks and regards
RaghuI think that this may not be an SAP issue. Is the authorization being taken from SAP directly?
Maybe you can check the middleware.
Rgds -
Personal Credit Card Transactions(used in expense report) showing unused
We have an issue here (in Oracle 11.5.10.2) where credit card transactions even though used(tied to an expense report and having final status as PAID/INVOICED) is still coming as UNUSED in the aging outstanding credit card transactions report. This is due to the fact that in the credit card transaction table, the expense amount column for these transaction is zero and hence these gets picked in the report. This is a bug that many users are facing the system and I have found in the metalink that this is a bug and a patch 5080064 needs to be applied. The concerned metalink note is Credit Card Transactions Included in Expense Report and Adjusted to Personal show as Used[ID 414566.1].
But it states here it is for Oracle Internet Expense 11.5.9 and pre-requsite patch is
3618125 - Patch 11i.OIE.J
4341684 - 11I.OIE.J (11i.FIN_PF.G) Rollup #2
We are at iExpense patch level 4165000 - patch 11i.OIE.K which superseds both the above patches.
The sql files included in the patch have lower version than we have in our instance. We are skeptical whether applying the patch can resolve our issue. We are sure that this is a bug and we need to know if there is a patch for fixing it or any workaround.Hi Priyanka,
We have had the same issue last month where same VCF4 file has been uploaded twice and duplicate CC records have been created. Actually the application never creats same record again although same VCF4 file been uploaded multiple times but after applying some patch system started creating duplicate CC records. That patch was meant to resolve a different issue on iExpense side but affected VCF4 file uploading program.
To narrow down the problem you can ask business users not to submit the expense report for the same transactions, if they have already done it and the expense report is not yet approved then they can withdraw it .
As a permanent solution it's highly recommended to raise an SR with Oracle Support.
I'm sure this is really painful issue in terms of reconciliation and can't take any decision as the Credit Cards data is more sensitive...
Wish you all the best...
Cheers,
Vara -
Paying vendors via credit card and then reconciling to SAP
We normally pay vendors via checks going EDI/Idocs - we run F110 with RFFOUS_C and then RFFOEDI1 to actually create the idocs and issue a 'check' number (at this point, the PAYR table is updated with this information). The bank sends us back a recon file containing the check number and vendor data, and we reconcile it in SAP.
We now have a project where for certain vendors we are going to pay via a credit card thru a bank. The process will be to create a new payment method and house bank and assign the payment method to those vendors. We would run F110 for that payment type, using program RFFOUS_C. This populates tables REGUP and REGUH. From these tables, I would extract the data I need to send to the bank - they need it in a very specific format (which I can do). The problem comes in at the reconciliation point. The bank will send us a file of transactions of vendors that were paid. How do I reconcile this with SAP if no actual check number was created, and no PAYR table record exists?I am running RFFOUS_C. I'm not sure what you mean by 'set the variant for check print by using the new dummy check number range'. I had created a check number range (and lot) and attached it to the house bank I enter when running the program - is this what I should be doing? Under print control, I have the 'print checks', 'print payment advice' and 'print payment summary' options selected, but I do not have 'print immediately' selected. When I run RFFOUS_C in this manner, check numbers do not get created. In fact, their is a function module 'get_check_number', but this only gets executed when you run RFFOEDI1. What could I be doing wrong?
-
Hi everyone,
Could anyone send me some links, or explain me something regarding credit card integration in SAP SD.
Thanks in advance.
I apprecieate your helpDear Aditya,
I have worked extensively on credit card configuration. let me know you email id so that i can send the documents to you.
In SAP the credit card processing is integrated with the sales and
distribution module.
Payment card configuration
Much of what is required for credit card processing to work with VISA, Master
Card, and American Express is already set up in SAP.
For all credit card configurations refer to
Define Card Types
Transaction SPRO IMG Sales and Distribution Billing Payment Cards
Here we define the type of cards that can be used in the system. A four-letter
code is given for each card type. E.g. MAST for Master Card, VSAJ for Visa
Japan. A function module for checking the card number is also specified here.
Credit Card Configuration And Processing In SAP
Maintain Card Categories
(a) Define card Categories: Here we specify the card category of the
payment card. With this the system automatically determines the card
category when you enter a card number in master data or sales
documents.
(b) Determine card categories: Here we specify the acceptable number
ranges for different card types. Also card categories are assigned to the
card types. Even though SAP comes with card checking algorithms
(Function Modules) for standard card types this configuration setting
is particularly useful to those cards that do not contain any standard
checking algorithm already set up in SAP.
Maintain Payment Card Plan Type
In this step, you assign the payment plan type for payment cards, the payment
card plan type, to all sales document types in which you will be using payment
cards. You cannot process payment cards if you have not made this assignment
The standard system contains payment plan type 03 for processing payment
cards. Fig 3. Show the screen where this assignment is done.
Credit Card Configuration And Processing In SAP
Maintain Blocking Reasons
In this step, you define blocking reasons for payment cards. You enter these in
the payer master record to block cards. The standard system contains blocking
reason 01 for lost cards.
Risk Management for Payment Cards
Transaction SPRO IMG Sales and Distribution Billing Payment Cards
Authorization and settlement 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. SAP comes with predefined
payment forms of guarantee as shown below. Customer can also
maintain other forms of payment suited for their line of business.
Credit Card Configuration And Processing In SAP
Define forms of payment guarantee
Maintain payment guarantee procedures
In this step, you define Payment guarantee procedure. These procedure controls,
which form of payment guarantee, are valid for a particular customer, and for a
particular sales document type.
The various settings done under this configuration are
Define payment guarantee procedures
Maintain customer determination procedure
Maintain document determination procedure
Assign sales document types
Determine payment guarantee procedures
Maintain authorization requirements*
Here requirements* are set to tell the system how and when to carry out
authorization when a sales order is saved. SAP comes with two requirements
Form routine 1. Carry out authorization only when the sales document is
complete. The system carries authorization when the order is saved.
Form routine 2. Carry out authorization only when the sales document is
complete, but the authorization for all the complete documents is carried out in
batch.
Additional requirements* can be assigned here as per the business requirements.
*Requirements are ABAP/4 code. Requirements for various functions can be accessed using transaction VOFM
Credit Card Configuration And Processing In SAP
Maintain Checking Groups
How and when authorizations are carried out depends on the setting you make in
the customizing for maintain checking group routines.
The three main settings that influence authorization are:
a) Authorization requirements
b) Authorization horizon
c) Preauthorization
There are two settings under this setting.
Define checking group: Here a checking group is defined and the
authorization requirement (described in the previous section), Authorization
horizon (described below) and preauthorization settings are done for this
checking group.
Credit Card Configuration And Processing In SAP
Here you can see a checking group C1 is defined with the authorization
requirement 902. Checking the pre-authorization tells the system to carryout preauthorization
if the order fulfillment date falls outside the horizon. The
authorization horizon specifies the number of days before the material
availability date, or billing date, that the system is to initiate authorization. If a
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
preauthorization.
In this example, the system has been set to authorize one day before delivery
creation. The system does not carry out authorization when the order is saved on
Day 0, rather on Day 2. Note that the authorization validity period has been set to
14 days in Customizing IMG Authorization and settlement Specify
authorization validity periods. The transaction will have to be reauthorized if
delivery activities take longer than 14 days.
Assign checking groups: Here the checking groups defined earlier are
assigned to different sales document types as shown fig 8.
Specify authorization validity periods
Here number of days that an authorization can remain valid for different card
types are maintained. Refer to Fig 9.
Credit Card Configuration And Processing In SAP
Assign checking groups
Assign validity period for authorization for different card types
Credit Card Configuration And Processing In SAP
Account Determination
Transaction SPRO IMG Sales and Distribution Billing Payment Cards
Authorization and settlement Maintain Clearing House
In the following steps, you set the condition technique for determining
clearinghouse 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 clearinghouse account. These accounts are a special type of general
ledger account that is posted from Sales and Distribution.
Here, you maintain:
Maintain field catalog.
Condition tables and the fields that they contain
Access sequences and condition types
Account determination procedures
You then assign these accounts to condition types.
Add to field catalog
Here you maintain the fields that can be used in the condition table. Fig 10.
Shows the transaction to maintain the field catalog.
Maintain Field Catalog.
Maintain condition tables
Here condition tables are maintained with fields that are added to the field
catalog. SAP comes pre-configured with two condition tables 4 and 6.
Credit Card Configuration And Processing In SAP
Maintain Condition Table
Maintain access sequences
In this step we define an access sequence and link the access sequence with the
condition tables.
Here an access sequence is defined. SAP comes with the access sequence A001.
Define Access Sequence
Once the new access sequence is defined, it is linked to the condition tables as
shown in the next screen.
Credit Card Configuration And Processing In SAP
Maintain Access For Access Sequence
Selecting an access and clicking fields will display the fields for the selected
access as shown below for access 10 as shown above.
Display Access Fields
Maintain condition types
Here condition types are defined and the access sequence to linked to it.
Condition types are contained in account determination procedures and control
which access sequences the system uses to find condition records.
These are
The condition
tables.
Credit Card Configuration And Processing In SAP
Define condition type
Maintain account determination procedure
In this step an account determination procedure is defined and linked to the
condition type (which in turn is linked to the access sequence).
Define account determination procedure
Assign account determination procedure.
Here an account determination procedure CC01 is defined and the condition type
CC01 is assigned to it.
Access sequence linked to the condition type
Credit Card Configuration And Processing In SAP
Assign account determination procedures
In this customizing the previously set up account determination procedure is
assigned to different billing documents.
Assign Accounts (G/L)
G/L accounts are assigned here for the combination of Sales organization, Card
type, chart of accounts and condition types.
Assign G/L accounts
Set authorization / settlement control per account
Each G/L account is assigned an authorization and a settlement function module.
The system will read the configuration a call the authorization and settlement
function module during authorization and settlement respectively.
Credit Card Configuration And Processing In SAP
Set Authorization and settlement function module
Maintain merchant IDs per account
A merchant may have one or more IDs for each clearinghouse with which it does
business. Here, you assign these different merchant IDs to their related
receivables accounts.
Assign Merchant IDs
Credit Card Configuration And Processing In SAP
Authorization and Settlement in SAP
Sales Order Cycle With Credit Card
Authorization
When an order is placed through the front-end system, the order information,
credit card information, billing information, shipping information is passed to
SAP. SAP processes the order calculates the taxes, the shipping costs and reads
the configuration information settings and executes the function module setup as
described . The function module formats the data and makes a RFC *
call to the payment application**.
The payment application screens the order for fraud, encrypts the data and
communicates with the third party processor who in turns communicates with
the card association and card issuer.
*RFC (Remote Function Call)
*Payment Application: Middle ware between SAP and third party processor/bank.
Credit Card Configuration And Processing In SAP
The third party processor responds back with the response whether the
transaction is approved or declined or referred.
Note: When any item in the order does not have a confirmed quantity, then
authorization is not carried out for the full amount. A small dollar amount
usually ($1) is used as the authorization amount. During the rescheduling run
the system will check for the material availability. If the material can be
delivered within the horizon date, a full authorization for the order is carried
out.
Approved: When the credit card transaction is approved the systems checks for
the material availability, confirms the material for the ordered quantity and saves
the order.
Declined: The material availability check for the material is not made, and the
order is rejected.
Referred: The order is saved and is blocked for delivery. In this situation is
merchant calls the bank checks for the available credit on the card and a manual
authorization is carried out.
Sales Order Entry Screen in SAP
Payment Card
Information
Credit Card Configuration And Processing In SAP
The first line in payment card screen is the card check performed by SAP system,
using the card check algorithm function module as described in Fig 1. And the
remaining lines represent the actual authorizations that are carried out.
Payment Card Screen
Path Header Payment Cards.
Settlement
Legally the merchant can charge the credit card after the order has been
completely processed. In SAP this happens after a delivery is created and the
goods has been shipped. In case there is not enough authorization for the order
to be delivered, the system goes out the get the authorization for the remaining
amount.
In SAP settlement is initiated using the transaction FCC1. All the valid
authorization is submitted in a batch to the payment application at scheduled
intervals as specified by the third party processor.
The payment application encrypts this data and communicates with the third
party processor. The third party processor checks if the settlement request has a
valid authorization against it. The third party processor then transfers the fund
from the cardholders bank to the merchant bank.
Authorization
Response
Credit Card Configuration And Processing In SAP
Credit Card Configuration And Processing In SAP
Regards,
Rakesh -
Dear All,
Can I have some information related to Credit Card in SAP.
Please mail me on my mail id [email protected]
Regards,
GeorgeDear George,
Please find the relevant details related to credit Crads as follows:
Overview
This document attempts to explain in the brief the credit card processing in SAP.
SAP provides a flexible and secure payment card interface that works with the
software of selected partners that provide merchant processes and clearing house
services. In SAP the credit card processing is integrated with the sales and
distribution module.
Payment card configuration
Much of what is required for credit card processing to work with VISA, Master
Card, and American Express is already set up in SAP.
For all credit card configurations refer to
Define Card Types
Transaction SPRO IMG Sales and Distribution Billing Payment Cards
Here we define the type of cards that can be used in the system. A four-letter
code is given for each card type. E.g. MAST for Master Card, VSAJ for Visa
Japan. A function module for checking the card number is also specified here.
1. Define Card Types
Credit Card Configuration And Processing In SAP
Maintain Card Categories
(a) Define card Categories: Here we specify the card category of the
payment card. With this the system automatically determines the card
category when you enter a card number in master data or sales
documents.
(b) Determine card categories: Here we specify the acceptable number
ranges for different card types. Also card categories are assigned to the
card types. Even though SAP comes with card checking algorithms
(Function Modules) for standard card types this configuration setting
is particularly useful to those cards that do not contain any standard
checking algorithm already set up in SAP.
2. Determine Card Categories
Maintain Payment Card Plan Type
In this step, you assign the payment plan type for payment cards, the payment
card plan type, to all sales document types in which you will be using payment
cards. You cannot process payment cards if you have not made this assignment
The standard system contains payment plan type 03 for processing payment
cards. 3. Show the screen where this assignment is done.
Credit Card Configuration And Processing In SAP
3. Maintain Payment Plan Type
Maintain Blocking Reasons
In this step, you define blocking reasons for payment cards. You enter these in
the payer master record to block cards. The standard system contains blocking
reason 01 for lost cards.
Risk Management for Payment Cards
Transaction SPRO IMG Sales and Distribution Billing Payment Cards
Authorization and settlement 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. SAP comes with predefined
payment forms of guarantee as shown below. Customer can also
maintain other forms of payment suited for their line of business.
Credit Card Configuration And Processing In SAP
Define forms of payment guarantee
3. Define forms of payment guarantee
Maintain payment guarantee procedures
In this step, you define Payment guarantee procedure. These procedure controls,
which form of payment guarantee, are valid for a particular customer, and for a
particular sales document type.
The various settings done under this configuration are
Define payment guarantee procedures
Maintain customer determination procedure
Maintain document determination procedure
Assign sales document types
Determine payment guarantee procedures
Maintain authorization requirements*
Here requirements* are set to tell the system how and when to carry out
authorization when a sales order is saved. SAP comes with two requirements
Form routine 1. Carry out authorization only when the sales document is
complete. The system carries authorization when the order is saved.
Form routine 2. Carry out authorization only when the sales document is
complete, but the authorization for all the complete documents is carried out in
batch.
Additional requirements* can be assigned here as per the business requirements.
*Requirements are ABAP/4 code. Requirements for various functions can be accessed using transaction VOFM
Credit Card Configuration And Processing In SAP
4. Maintain Card Authorization Requirements
Maintain Checking Groups
How and when authorizations are carried out depends on the setting you make in
the customizing for maintain checking group routines.
The three main settings that influence authorization are:
a) Authorization requirements
b) Authorization horizon
c) Preauthorization
There are two settings under this setting.
Define checking group: Here a checking group is defined and the
authorization requirement (described in the previous section), Authorization
horizon (described below) and preauthorization settings are done for this
checking group.
5. Define Checking Group
Credit Card Configuration And Processing In SAP
Here you can see a checking group C1 is defined with the authorization
requirement 902. Checking the pre-authorization tells the system to carryout preauthorization
if the order fulfillment date falls outside the horizon. The
authorization horizon specifies the number of days before the material
availability date, or billing date, that the system is to initiate authorization. If a
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
preauthorization.
6. Preauthorization Concept
In this example, the system has been set to authorize one day before delivery
creation. The system does not carry out authorization when the order is saved on
Day 0, rather on Day 2. Note that the authorization validity period has been set to
14 days in Customizing IMG Authorization and settlement Specify
authorization validity periods. The transaction will have to be reauthorized if
delivery activities take longer than 14 days.
Assign checking groups: Here the checking groups defined earlier are
assigned to different sales document types as shown 8.
Specify authorization validity periods
Here number of days that an authorization can remain valid for different card
types are maintained. Refer to 9.
Credit Card Configuration And Processing In SAP
8. Assign checking groups
9. Assign validity period for authorization for different card types
Credit Card Configuration And Processing In SAP
Account Determination
Transaction SPRO IMG Sales and Distribution Billing Payment Cards
Authorization and settlement Maintain Clearing House
In the following steps, you set the condition technique for determining
clearinghouse 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 clearinghouse account. These accounts are a special type of general
ledger account that is posted from Sales and Distribution.
Here, you maintain:
Maintain field catalog.
Condition tables and the fields that they contain
Access sequences and condition types
Account determination procedures
You then assign these accounts to condition types.
Add to field catalog
Here you maintain the fields that can be used in the condition table. 10.
Shows the transaction to maintain the field catalog.
10. Maintain Field Catalog.
Maintain condition tables
Here condition tables are maintained with fields that are added to the field
catalog. SAP comes pre-configured with two condition tables 4 and 6. Refer
11.
Credit Card Configuration And Processing In SAP
11. Maintain Condition Table
Maintain access sequences
In this step we define an access sequence and link the access sequence with the
condition tables.
Here an access sequence is defined. SAP comes with the access sequence A001.
12. Define Access Sequence
Once the new access sequence is defined, it is linked to the condition tables as
shown in the next screen.
Credit Card Configuration And Processing In SAP
13. Maintain Access For Access Sequence
Selecting an access and clicking fields will display the fields for the selected
access as shown below for access 10 as shown above.
14. Display Access Fields
Maintain condition types
Here condition types are defined and the access sequence to linked to it.
Condition types are contained in account determination procedures and control
which access sequences the system uses to find condition records.
These are The condition tables.
Credit Card Configuration And Processing In SAP
15. Define condition type
Maintain account determination procedure
In this step an account determination procedure is defined and linked to the
condition type (which in turn is linked to the access sequence).
Define account determination procedure
16. Assign account determination procedure.
Here an account determination procedure CC01 is defined and the condition type
CC01 is assigned to it.
Access sequence linked to the condition type
Credit Card Configuration And Processing In SAP
Assign account determination procedures
In this customizing the previously set up account determination procedure is
assigned to different billing documents.
Assign Accounts (G/L)
G/L accounts are assigned here for the combination of Sales organization, Card
type, chart of accounts and condition types as shown in the 17.
17. Assign G/L accounts
Set authorization / settlement control per account
Each G/L account is assigned an authorization and a settlement function module.
The system will read the configuration a call the authorization and settlement
function module during authorization and settlement respectively.
Credit Card Configuration And Processing In SAP
18. Set Authorization and settlement function module
Maintain merchant IDs per account
A merchant may have one or more IDs for each clearinghouse with which it does
business. Here, you assign these different merchant IDs to their related
receivables accounts.
19. Assign Merchant IDs
Credit Card Configuration And Processing In SAP
Authorization and Settlement in SAP
20. Sales Order Cycle With Credit Card Authorization
When an order is placed through the front-end system, the order information,
credit card information, billing information, shipping information is passed to
SAP. SAP processes the order calculates the taxes, the shipping costs and reads
the configuration information settings and executes the function module setup as
described in Fig. 18. The function module formats the data and makes a RFC *
call to the payment application**.
The payment application screens the order for fraud, encrypts the data and
communicates with the third party processor who in turns communicates with
the card association and card issuer.
*RFC (Remote Function Call)
*Payment Application: Middle ware between SAP and third party processor/bank.
Credit Card Configuration And Processing In SAP
The third party processor responds back with the response whether the
transaction is approved or declined or referred.
Note: When any item in the order does not have a confirmed quantity, then
authorization is not carried out for the full amount. A small dollar amount
usually ($1) is used as the authorization amount. During the rescheduling run
the system will check for the material availability. If the material can be
delivered within the horizon date, a full authorization for the order is carried
out.
Approved: When the credit card transaction is approved the systems checks for
the material availability, confirms the material for the ordered quantity and saves
the order.
Declined: The material availability check for the material is not made, and the
order is rejected.
Referred: The order is saved and is blocked for delivery. In this situation is
merchant calls the bank checks for the available credit on the card and a manual
authorization is carried out.
21. Sales Order Entry Screen in SAP
Payment Card
Information
Credit Card Configuration And Processing In SAP
The first line in payment card screen is the card check performed by SAP system,
using the card check algorithm function module as described in 1. And the
remaining lines represent the actual authorizations that are carried out.
22. Payment Card Screen
Path Header Payment Cards.
Settlement
Legally the merchant can charge the credit card after the order has been
completely processed. In SAP this happens after a delivery is created and the
goods has been shipped. In case there is not enough authorization for the order
to be delivered, the system goes out the get the authorization for the remaining
amount.
In SAP settlement is initiated using the transaction FCC1. All the valid
authorization is submitted in a batch to the payment application at scheduled
intervals as specified by the third party processor.
The payment application encrypts this data and communicates with the third
party processor. The third party processor checks if the settlement request has a
valid authorization against it. The third party processor then transfers the fund
from the cardholders bank to the merchant bank.
Authorization
Response
Credit Card Configuration And Processing In SAP
Regards,
Rakesh -
Credit Card Configuration in SAP
Dear All,
Can I have the information on Credit Card Configuration.
Regards,
GerogeDear George,
Please find the relevant details related to credit Crads as follows:
Overview
This document attempts to explain in the brief the credit card processing in SAP.
SAP provides a flexible and secure payment card interface that works with the
software of selected partners that provide merchant processes and clearing house
services. In SAP the credit card processing is integrated with the sales and
distribution module.
Payment card configuration
Much of what is required for credit card processing to work with VISA, Master
Card, and American Express is already set up in SAP.
For all credit card configurations refer to
Define Card Types
Transaction SPRO IMG Sales and Distribution Billing Payment Cards
Here we define the type of cards that can be used in the system. A four-letter
code is given for each card type. E.g. MAST for Master Card, VSAJ for Visa
Japan. A function module for checking the card number is also specified here.
1. Define Card Types
Credit Card Configuration And Processing In SAP
Maintain Card Categories
(a) Define card Categories: Here we specify the card category of the
payment card. With this the system automatically determines the card
category when you enter a card number in master data or sales
documents.
(b) Determine card categories: Here we specify the acceptable number
ranges for different card types. Also card categories are assigned to the
card types. Even though SAP comes with card checking algorithms
(Function Modules) for standard card types this configuration setting
is particularly useful to those cards that do not contain any standard
checking algorithm already set up in SAP.
2. Determine Card Categories
Maintain Payment Card Plan Type
In this step, you assign the payment plan type for payment cards, the payment
card plan type, to all sales document types in which you will be using payment
cards. You cannot process payment cards if you have not made this assignment
The standard system contains payment plan type 03 for processing payment
cards. 3. Show the screen where this assignment is done.
Credit Card Configuration And Processing In SAP
3. Maintain Payment Plan Type
Maintain Blocking Reasons
In this step, you define blocking reasons for payment cards. You enter these in
the payer master record to block cards. The standard system contains blocking
reason 01 for lost cards.
Risk Management for Payment Cards
Transaction SPRO IMG Sales and Distribution Billing Payment Cards
Authorization and settlement 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. SAP comes with predefined
payment forms of guarantee as shown below. Customer can also
maintain other forms of payment suited for their line of business.
Credit Card Configuration And Processing In SAP
Define forms of payment guarantee
3. Define forms of payment guarantee
Maintain payment guarantee procedures
In this step, you define Payment guarantee procedure. These procedure controls,
which form of payment guarantee, are valid for a particular customer, and for a
particular sales document type.
The various settings done under this configuration are
Define payment guarantee procedures
Maintain customer determination procedure
Maintain document determination procedure
Assign sales document types
Determine payment guarantee procedures
Maintain authorization requirements*
Here requirements* are set to tell the system how and when to carry out
authorization when a sales order is saved. SAP comes with two requirements
Form routine 1. Carry out authorization only when the sales document is
complete. The system carries authorization when the order is saved.
Form routine 2. Carry out authorization only when the sales document is
complete, but the authorization for all the complete documents is carried out in
batch.
Additional requirements* can be assigned here as per the business requirements.
*Requirements are ABAP/4 code. Requirements for various functions can be accessed using transaction VOFM
Credit Card Configuration And Processing In SAP
4. Maintain Card Authorization Requirements
Maintain Checking Groups
How and when authorizations are carried out depends on the setting you make in
the customizing for maintain checking group routines.
The three main settings that influence authorization are:
a) Authorization requirements
b) Authorization horizon
c) Preauthorization
There are two settings under this setting.
Define checking group: Here a checking group is defined and the
authorization requirement (described in the previous section), Authorization
horizon (described below) and preauthorization settings are done for this
checking group.
5. Define Checking Group
Credit Card Configuration And Processing In SAP
Here you can see a checking group C1 is defined with the authorization
requirement 902. Checking the pre-authorization tells the system to carryout preauthorization
if the order fulfillment date falls outside the horizon. The
authorization horizon specifies the number of days before the material
availability date, or billing date, that the system is to initiate authorization. If a
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
preauthorization.
6. Preauthorization Concept
In this example, the system has been set to authorize one day before delivery
creation. The system does not carry out authorization when the order is saved on
Day 0, rather on Day 2. Note that the authorization validity period has been set to
14 days in Customizing IMG Authorization and settlement Specify
authorization validity periods. The transaction will have to be reauthorized if
delivery activities take longer than 14 days.
Assign checking groups: Here the checking groups defined earlier are
assigned to different sales document types as shown 8.
Specify authorization validity periods
Here number of days that an authorization can remain valid for different card
types are maintained. Refer to 9.
Credit Card Configuration And Processing In SAP
8. Assign checking groups
9. Assign validity period for authorization for different card types
Credit Card Configuration And Processing In SAP
Account Determination
Transaction SPRO IMG Sales and Distribution Billing Payment Cards
Authorization and settlement Maintain Clearing House
In the following steps, you set the condition technique for determining
clearinghouse 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 clearinghouse account. These accounts are a special type of general
ledger account that is posted from Sales and Distribution.
Here, you maintain:
Maintain field catalog.
Condition tables and the fields that they contain
Access sequences and condition types
Account determination procedures
You then assign these accounts to condition types.
Add to field catalog
Here you maintain the fields that can be used in the condition table. 10.
Shows the transaction to maintain the field catalog.
10. Maintain Field Catalog.
Maintain condition tables
Here condition tables are maintained with fields that are added to the field
catalog. SAP comes pre-configured with two condition tables 4 and 6. Refer
11.
Credit Card Configuration And Processing In SAP
11. Maintain Condition Table
Maintain access sequences
In this step we define an access sequence and link the access sequence with the
condition tables.
Here an access sequence is defined. SAP comes with the access sequence A001.
12. Define Access Sequence
Once the new access sequence is defined, it is linked to the condition tables as
shown in the next screen.
Credit Card Configuration And Processing In SAP
13. Maintain Access For Access Sequence
Selecting an access and clicking fields will display the fields for the selected
access as shown below for access 10 as shown above.
14. Display Access Fields
Maintain condition types
Here condition types are defined and the access sequence to linked to it.
Condition types are contained in account determination procedures and control
which access sequences the system uses to find condition records.
These are The condition tables.
Credit Card Configuration And Processing In SAP
15. Define condition type
Maintain account determination procedure
In this step an account determination procedure is defined and linked to the
condition type (which in turn is linked to the access sequence).
Define account determination procedure
16. Assign account determination procedure.
Here an account determination procedure CC01 is defined and the condition type
CC01 is assigned to it.
Access sequence linked to the condition type
Credit Card Configuration And Processing In SAP
Assign account determination procedures
In this customizing the previously set up account determination procedure is
assigned to different billing documents.
Assign Accounts (G/L)
G/L accounts are assigned here for the combination of Sales organization, Card
type, chart of accounts and condition types as shown in the 17.
17. Assign G/L accounts
Set authorization / settlement control per account
Each G/L account is assigned an authorization and a settlement function module.
The system will read the configuration a call the authorization and settlement
function module during authorization and settlement respectively.
Credit Card Configuration And Processing In SAP
18. Set Authorization and settlement function module
Maintain merchant IDs per account
A merchant may have one or more IDs for each clearinghouse with which it does
business. Here, you assign these different merchant IDs to their related
receivables accounts.
19. Assign Merchant IDs
Credit Card Configuration And Processing In SAP
Authorization and Settlement in SAP
20. Sales Order Cycle With Credit Card Authorization
When an order is placed through the front-end system, the order information,
credit card information, billing information, shipping information is passed to
SAP. SAP processes the order calculates the taxes, the shipping costs and reads
the configuration information settings and executes the function module setup as
described in Fig. 18. The function module formats the data and makes a RFC *
call to the payment application**.
The payment application screens the order for fraud, encrypts the data and
communicates with the third party processor who in turns communicates with
the card association and card issuer.
*RFC (Remote Function Call)
*Payment Application: Middle ware between SAP and third party processor/bank.
Credit Card Configuration And Processing In SAP
The third party processor responds back with the response whether the
transaction is approved or declined or referred.
Note: When any item in the order does not have a confirmed quantity, then
authorization is not carried out for the full amount. A small dollar amount
usually ($1) is used as the authorization amount. During the rescheduling run
the system will check for the material availability. If the material can be
delivered within the horizon date, a full authorization for the order is carried
out.
Approved: When the credit card transaction is approved the systems checks for
the material availability, confirms the material for the ordered quantity and saves
the order.
Declined: The material availability check for the material is not made, and the
order is rejected.
Referred: The order is saved and is blocked for delivery. In this situation is
merchant calls the bank checks for the available credit on the card and a manual
authorization is carried out.
21. Sales Order Entry Screen in SAP
Payment Card
Information
Credit Card Configuration And Processing In SAP
The first line in payment card screen is the card check performed by SAP system,
using the card check algorithm function module as described in 1. And the
remaining lines represent the actual authorizations that are carried out.
22. Payment Card Screen
Path Header Payment Cards.
Settlement
Legally the merchant can charge the credit card after the order has been
completely processed. In SAP this happens after a delivery is created and the
goods has been shipped. In case there is not enough authorization for the order
to be delivered, the system goes out the get the authorization for the remaining
amount.
In SAP settlement is initiated using the transaction FCC1. All the valid
authorization is submitted in a batch to the payment application at scheduled
intervals as specified by the third party processor.
The payment application encrypts this data and communicates with the third
party processor. The third party processor checks if the settlement request has a
valid authorization against it. The third party processor then transfers the fund
from the cardholders bank to the merchant bank.
Authorization
Response
Credit Card Configuration And Processing In SAP
Regards,
Rakesh -
Credit Card config and encryption
Hi frnds
I would appreciate if anyone can provide the config steps for credit card and also the step for encrytion. If you have a doc on it then please mail it to [email protected]hi
CREDIT CARDS
Go thr below links:
PAYMENT CARDS:
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/SDBILIVPC/SDBILIVPC.pdf
http://help.sap.com/saphelp_erp2005vp/helpdata/en/93/745309546011d1a7020000e829fd11/frameset.htm
Overview
This document attempts to explain in the brief the credit card processing in SAP.
SAP provides a flexible and secure payment card interface that works with the
software of selected partners that provide merchant processes and clearing house
services. In SAP the credit card processing is integrated with the sales and
distribution module.
Payment card configuration
Much of what is required for credit card processing to work with VISA, Master
Card, and American Express is already set up in SAP.
For all credit card configurations refer to
Define Card Types
Transaction SPRO IMG ‡ Sales and Distribution ‡ Billing ‡ Payment Cards
Here we define the type of cards that can be used in the system. A four-letter
code is given for each card type. E.g. MAST for Master Card, VSAJ for Visa
Japan. A function module for checking the card number is also specified here.
1. Define Card Types
Credit Card Configuration And Processing In SAP
Maintain Card Categories
(a) Define card Categories: Here we specify the card category of the
payment card. With this the system automatically determines the card
category when you enter a card number in master data or sales
documents.
(b) Determine card categories: Here we specify the acceptable number
ranges for different card types. Also card categories are assigned to the
card types. Even though SAP comes with card checking algorithms
(Function Modules) for standard card types this configuration setting
is particularly useful to those cards that do not contain any standard
checking algorithm already set up in SAP.
2. Determine Card Categories
Maintain Payment Card Plan Type
In this step, you assign the payment plan type for payment cards, the payment
card plan type, to all sales document types in which you will be using payment
cards. You cannot process payment cards if you have not made this assignment
The standard system contains payment plan type 03 for processing payment
cards. 3. Show the screen where this assignment is done.
Credit Card Configuration And Processing In SAP
3. Maintain Payment Plan Type
Maintain Blocking Reasons
In this step, you define blocking reasons for payment cards. You enter these in
the payer master record to block cards. The standard system contains blocking
reason 01 for lost cards.
Risk Management for Payment Cards
Transaction SPRO IMG ‡ Sales and Distribution ‡ Billing ‡ Payment Cards
‡ Authorization and settlement ‡ 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. SAP comes with predefined
payment forms of guarantee as shown below. Customer can also
maintain other forms of payment suited for their line of business.
Credit Card Configuration And Processing In SAP
Define forms of payment guarantee
3. Define forms of payment guarantee
Maintain payment guarantee procedures
In this step, you define Payment guarantee procedure. These procedure controls,
which form of payment guarantee, are valid for a particular customer, and for a
particular sales document type.
The various settings done under this configuration are
Define payment guarantee procedures
Maintain customer determination procedure
Maintain document determination procedure
Assign sales document types
Determine payment guarantee procedures
Maintain authorization requirements*
Here requirements* are set to tell the system how and when to carry out
authorization when a sales order is saved. SAP comes with two requirements
Form routine 1. Carry out authorization only when the sales document is
complete. The system carries authorization when the order is saved.
Form routine 2. Carry out authorization only when the sales document is
complete, but the authorization for all the complete documents is carried out in
batch.
Additional requirements* can be assigned here as per the business requirements.
*Requirements are ABAP/4 code. Requirements for various functions can be accessed using transaction VOFM
Credit Card Configuration And Processing In SAP
4. Maintain Card Authorization Requirements
Maintain Checking Groups
How and when authorizations are carried out depends on the setting you make in
the customizing for maintain checking group routines.
The three main settings that influence authorization are:
a) Authorization requirements
b) Authorization horizon
c) Preauthorization
There are two settings under this setting.
Define checking group: Here a checking group is defined and the
authorization requirement (described in the previous section), Authorization
horizon (described below) and preauthorization settings are done for this
checking group.
5. Define Checking Group
Credit Card Configuration And Processing In SAP
Here you can see a checking group C1 is defined with the authorization
requirement 902. Checking the pre-authorization tells the system to carryout preauthorization
if the order fulfillment date falls outside the horizon. The
authorization horizon specifies the number of days before the material
availability date, or billing date, that the system is to initiate authorization. If a
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
preauthorization.
6. Preauthorization Concept
In this example, the system has been set to authorize one day before delivery
creation. The system does not carry out authorization when the order is saved on
Day 0, rather on Day 2. Note that the authorization validity period has been set to
14 days in Customizing IMG‡ Authorization and settlement‡ Specify
authorization validity periods. The transaction will have to be reauthorized if
delivery activities take longer than 14 days.
Assign checking groups: Here the checking groups defined earlier are
assigned to different sales document types as shown 8.
Specify authorization validity periods
Here number of days that an authorization can remain valid for different card
types are maintained. Refer to 9.
Credit Card Configuration And Processing In SAP
8. Assign checking groups
9. Assign validity period for authorization for different card types
Credit Card Configuration And Processing In SAP
Account Determination
Transaction SPRO IMG ‡ Sales and Distribution ‡ Billing ‡ Payment Cards‡
Authorization and settlement ‡ Maintain Clearing House
In the following steps, you set the condition technique for determining
clearinghouse 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 clearinghouse account. These accounts are a special type of general
ledger account that is posted from Sales and Distribution.
Here, you maintain:
• Maintain field catalog.
• Condition tables and the fields that they contain
• Access sequences and condition types
• Account determination procedures
• You then assign these accounts to condition types.
Add to field catalog
Here you maintain the fields that can be used in the condition table. 10.
Shows the transaction to maintain the field catalog.
10. Maintain Field Catalog.
Maintain condition tables
Here condition tables are maintained with fields that are added to the field
catalog. SAP comes pre-configured with two condition tables 4 and 6. Refer
11.
Credit Card Configuration And Processing In SAP
11. Maintain Condition Table
Maintain access sequences
In this step we define an access sequence and link the access sequence with the
condition tables.
Here an access sequence is defined. SAP comes with the access sequence A001.
12. Define Access Sequence
Once the new access sequence is defined, it is linked to the condition tables as
shown in the next screen.
Credit Card Configuration And Processing In SAP
13. Maintain Access For Access Sequence
Selecting an access and clicking fields will display the fields for the selected
access as shown below for access 10 as shown above.
14. Display Access Fields
Maintain condition types
Here condition types are defined and the access sequence to linked to it.
Condition types are contained in account determination procedures and control
which access sequences the system uses to find condition records.
These are The condition tables.
Credit Card Configuration And Processing In SAP
15. Define condition type
Maintain account determination procedure
In this step an account determination procedure is defined and linked to the
condition type (which in turn is linked to the access sequence).
Define account determination procedure
16. Assign account determination procedure.
Here an account determination procedure CC01 is defined and the condition type
CC01 is assigned to it.
Access sequence linked to the condition type
Credit Card Configuration And Processing In SAP
Assign account determination procedures
In this customizing the previously set up account determination procedure is
assigned to different billing documents.
Assign Accounts (G/L)
G/L accounts are assigned here for the combination of Sales organization, Card
type, chart of accounts and condition types as shown in the 17.
17. Assign G/L accounts
Set authorization / settlement control per account
Each G/L account is assigned an authorization and a settlement function module.
The system will read the configuration a call the authorization and settlement
function module during authorization and settlement respectively.
Credit Card Configuration And Processing In SAP
18. Set Authorization and settlement function module
Maintain merchant IDs per account
A merchant may have one or more IDs for each clearinghouse with which it does
business. Here, you assign these different merchant IDs to their related
receivables accounts.
19. Assign Merchant ID’s
Credit Card Configuration And Processing In SAP
Authorization and Settlement in SAP
20. Sales Order Cycle With Credit Card Authorization
When an order is placed through the front-end system, the order information,
credit card information, billing information, shipping information is passed to
SAP. SAP processes the order calculates the taxes, the shipping costs and reads
the configuration information settings and executes the function module setup as
described in Fig. 18. The function module formats the data and makes a RFC *
call to the payment application**.
The payment application screens the order for fraud, encrypts the data and
communicates with the third party processor who in turns communicates with
the card association and card issuer.
*RFC (Remote Function Call)
*Payment Application: Middle ware between SAP and third party processor/bank.
Credit Card Configuration And Processing In SAP
The third party processor responds back with the response whether the
transaction is approved or declined or referred.
Note: When any item in the order does not have a confirmed quantity, then
authorization is not carried out for the full amount. A small dollar amount
usually ($1) is used as the authorization amount. During the rescheduling run
the system will check for the material availability. If the material can be
delivered within the horizon date, a full authorization for the order is carried
out.
Approved: When the credit card transaction is approved the systems checks for
the material availability, confirms the material for the ordered quantity and saves
the order.
Declined: The material availability check for the material is not made, and the
order is rejected.
Referred: The order is saved and is blocked for delivery. In this situation is
merchant calls the bank checks for the available credit on the card and a manual
authorization is carried out.
21. Sales Order Entry Screen in SAP
Payment Card
Information
Credit Card Configuration And Processing In SAP
The first line in payment card screen is the card check performed by SAP system,
using the card check algorithm function module as described in 1. And the
remaining lines represent the actual authorizations that are carried out.
22. Payment Card Screen
Path Header ‡ Payment Cards.
Settlement
Legally the merchant can charge the credit card after the order has been
completely processed. In SAP this happens after a delivery is created and the
goods has been shipped. In case there is not enough authorization for the order
to be delivered, the system goes out the get the authorization for the remaining
amount.
In SAP settlement is initiated using the transaction FCC1. All the valid
authorization is submitted in a batch to the payment application at scheduled
intervals as specified by the third party processor.
The payment application encrypts this data and communicates with the third
party processor. The third party processor checks if the settlement request has a
valid authorization against it. The third party processor then transfers the fund
from the cardholder’s bank to the merchant bank.
Authorization
Response
Credit Card Configuration And Processing In SAP -
How can we remove credit card from account
im in malaysia i tried to use an canadian credit card at first it was workin but whenever i tried on pc to see if i can change it wont accept my other credit card, then i left it like this after that its been almost 8 months now it says its been declined idk ***, and then i try to change it it says put malaysian credit card now, and i cant even choose to none option coz it doesnt show idk what to do? if i make another account would it delete all my purchased apps? and one more thing now it cant change i canteven update my apps now, oh yeah its say put malaysian credit card why would it do that i dont understand help me pelase
Contact iTunes Customer Service and request assistance
Use this Link > Apple Support iTunes Store Contact
Maybe you are looking for
-
I am unable to activate Genius since upgrading to Windows 7. Prior with Vista and iTunes 9 Genius worked fine. Upgrade to Win7 and I cannot activate Genius. It goes through step 1 fine then goes into step 2. It pops up an error message after about a
-
Workflow event bus1022-created triggered twice with ME21Nu200F
Hi everybody The explanation to my problem is as follow: Initially I was using the Tcode AS01, ME21N, ABUMN to create fixed assets and every asset created triggers the event BUS1022-CREATED, but then I set the system to synchronizing assets with equi
-
On the first page of my website, I want the user to be asked for their zip code and based on their zip code would depend on what data they see. The results would be based on information found on the database and posted by the users. The site will be
-
LightRoom has always been touted as a "Productivity Tool", and LR3.6 lived up to that claim. LR4 does not, at least on my machine, and obviously on many other peoples' machines as made clear on this forum. If some of you find LR4 it snappy and quick,
-
Getting rid of single letters in index
Hello! Creating and index with framemaker I would like to get rid of the letters at the beginning (in red), e.g.: A Action Apple Artist B Bakery Beachball Bubble Where exactly on reference page is that coded?