Working with Paymetric SAP Credit Card...
Transcript of Working with Paymetric SAP Credit Card...
Working with Paymetric SAP Credit Card
Solution
They have had a long and comprehensive look at SAP‟s standard solution for credit cards and
developed their offering to fill the gaps and improve the functionality.
Here are a few examples:
In standard SAP, the customer needs to decide up front in the sales order to pay by credit
card. It is not possible to pay for your open A/R balance later. Paymetric‟s Open A/R
module allows you to select Open balances after the fact to settle with a credit card.
In standard SAP, if you have a billing plan of say 3 bills of $5,000 each, SAP will
attempt to authorize the whole $15,000 instead of only the amount with in the configured
horizon. There is a way of using the Auto A/R module to cover this.
The solution comprises of a group of SAP programs (imported as a series of transports) and a
separate server called XiPay (actually server is a misnomer, it is actually a piece of middleware
that communicates with the payment processor). There is also an encryption/decryption server
which resides on the same box.
The XiPay server is where you get a lot of value, as Paymetric has certified their interfaces with
the processors (and they support quite a few). This save a bunch of development and testing
time.
Even though the solution is vastly improved, it does not necessarily mean that you do not have to
add code to user exits.
For example: It does not support Invoice Cancellations out of the box. You need to add some
coding to cover the 2 scenarios: before settlement and after settlement. Actually, most of the
coding is related to the XiPay side in this case. Another example is Billing Plans. A bit of code
needs to be added to handle these.
Whatever you do, do not underestimate the effort still involved in implementing credit cards as
we have discovered. Paymetric definitely does shorten the implementation time dramatically, but
do not get the illusion that it is a plug and go.
I have also been very impressed with the caliber of the Paymetric consultants when we have had
questions or issues.
In summary, I think it is an excellent solution and well worth the investment. It will shorten your
credit card implementation time and really improve your final solution.
What a great site! I have a question out to our consultants, but it‟s been awhile so I was
trying to google the answer… we use the customer master functionality for credit card
information, but it‟s becoming a problem when a customer‟s expiration date changes. Our
people in the field need to process the card immediately, and not wait for the centralized
MDM team at corporate to make the change (which could take days). Does anyone have
any ideas or hints on how to change code for this? Thanks in advance!
Eric Bushman June 27, 2013 at 12:05 pm
Lesley,
Unfortunately, SAP has code in place that pulls the details in from the Customer Master
record whenever you enter a card/token number that is stored on a Customer‟s Master
record. In other words, if the card 4444333322221111 is stored on the Customer‟s Master
records with an Expiration Date of 12/15 and you try to use that card on a Sales Order
and enter an Expiration Date of 04/19 then SAP will overwrite it back to 12/15.
This happens in FUNCTION CCARD_ENHANCE_FROM_MASTERDATA. This
function is called in the business logic flow immediately after the Card Validation
Routine from configuration is called in FORM CC_NUMBER_CHECK in program
LV60FFCC. You would need to modify the code to skip that check or have a different
response.
I hope that helps!
Regards,
Eric Bushman
Paymetric.
Reply
Lesley June 27, 2013 at 12:16 pm
Thanks, Eric!
For the expiration date problem, we decided to automate the request to MDM. This way,
it will go through immediately when the user updates it.
Lesley
Reply
Eric Bushman June 27, 2013 at 12:41 pm
Lesley,
My pleasure!
Do you mind sharing how you automated the requests?
Regards,
Eric Bushman
Paymetric
Reply
Lesley June 27, 2013 at 12:46 pm
I believe we are using Service Now for it, but I‟m not 100% sure. There is a helpdesk
type of software in which the user can submit requests as a workflow. And I believe they
would have to enhance that to sync with SAP. Sorry, I‟m not very technical. I‟ll know
more probably next month when it actually rolls out (it is a different department).
Amit Mulay March 19, 2013 at 2:56 am
Hello Eric,
Our business requires sales order authorization should split per line item i.e. if there are
three line items in SO, then total sales order authorization should split in three
authorizations. Each authorization should have value equal to line item value. Is there any
way by which we can split authorization in CRM per line item?
Kind Regards,
Amit Mulay
Reply
Jshah January 5, 2013 at 10:21 am
Hello Eric/ Paul.
Thanks for your Prompt answer.
If i use the User exit option :
Userexit_Field_modification then could you please suggest me the code to suppress the
fields or keep the screen blank for the non payment card customer according to the
Account group.
As you have mentioned Payment card tab is appearing at both overview and Header level
so have to deal with Multiple screens
Eric, I have also come across your Old post where somebody had suggested the code for
the same USER exit. It was back in 2010.
Could it be possible to post that code to see whether it works in my case.
Our ABAPer had spent couple of hours so far but could not able to fix the Problem(could
not able to locate right screen no 4204 & 4001 to suppress the TAB or Greyed out the
Particular fields)
Awaiting for your updates.
Many Thanks
Jitesh
Reply
Eric Bushman January 6, 2013 at 1:17 pm
Jitesh,
I‟ve looked in my archives and am not able to find any sample code for you. I don‟t know
that I‟ve ever done this type of enhancement before.
I do know that you need to be working with program SAPLV60F. The
USEREXIT_FIELD_MODIFICATION you want is in RV60FUS4. I don‟t know that
you can use that userexit to gray out the credit card fields on the Header Payment Card
Screen or not though. It may be that you need to place an Enhancement Point somewhere
in the Screen Flow logic of screen 4204 instead.
Let me know if that helps at all.
Regards,
Eric Bushman
Paymetric
Reply
Alex June 6, 2013 at 4:26 pm
Hi Eric,
I have a question for you. Please take a look at the scenario
Paymetric has been implemented and the incoming files are being processed successfully.
However in some cases we need to reverse the payment back to the credit card of the
customer.
Can you tell me how to go about it?
Reply
Eric Bushman June 6, 2013 at 4:50 pm
Alex,
If you need to reverse a Settled credit card transaction in SAP (either because the
transaction was rejected, fraudulent or for some other reason was not funded), SAP
provides transaction FBRC to accomplish this. The result of running transaction FBRC is
that the payment is reversed from the Settlement Pre-Cash GL account and the original
Accounting Document is re-opened to reflect the liability on the customer account.
You can find a deeper discussion about this topic here:
http://www.sapfans.com/forums/viewtopic.php?f=10&t=146720.
Regards,
Eric Bushman
Paymetric
Reply
Jshah January 3, 2013 at 4:49 am
Hi Eric,
we have recently Implemented Sales Payment card Functionality in our Company.
We have came across following problem.
We are using a Document type ZYO( Sales order) for the all the customer , and same
document type for the Sales Payment card as well.
We have also created New Payer group(4050) and assigned Pyment procedure to the
customer. So theoritically when Sold to Party Place an order with this Payer , Payment
card tab should appear at Document level.
We tested it and it appears there but at the same time if sold to party place an order with
different payer (non- Payment card payer) with using the same order type , Payment card
tab is also appearing there.
I have checked the customer master account for the payer there is not payment gurantee
procedure assigned there still Tab appears at doc header level.
Business wanted this tab to be suppressed for NON payment card customer?
What could be the soultion for this?
Awaiting for your reply.
Reply
SAPGuy January 5, 2013 at 5:00 am
Hi Jitesh
My initial questions would be:
Why is your company afraid of displaying the blank Payment Card tab on the order?
What is the perceived risk?
Only authorized people should be able to create/change/display information on this tab
anyway.
The bad news is that there is no standard way of suppressing this tab.
Once you activate the payment guarantee procedure for the Document Type (ZYO in
your case), it automatically activates the display of the Payment Card tab for the
document type. It does not depend on whether the customer is also activated. The
reasoning is that it allows the user to manually add or change payment cards on the order,
irrespective of whether there was a payment card on the customer.
I can give you 3 options for achieving this:
Option 1: The simplest way is via Authorizations (speak to your SAP Authorization
person if you do not know anything about SAP authorizations)
The authorization object that controls user activities related to payment cards on the sales
order is V_VBAK_AAT. The authorization object that controls user activities related to
payment cards on the invoice is V_VBRK_PKA. The different kinds of activity that can
be controlled are:
Activity = C1 Controls ability to create/change credit card info.
Activity = C2 Controls ability to display credit card info
Activity = C3 Controls ability to enter manual authorizations
I do not believe this will suppress the payment card tab (I may be wrong – you may want
to test this), but the user will not have any authorization is create/change or display the
information. This does not give you exactly what you are looking for, but it may address
the concerns your company has.
Option 2: Suppress the Tab via ABAP user exit This code should not be too complex. It is simply a header level check against the
payment card configuration of the customer and then the code would suppress or display
that tab based on that check.
Option 3: Using GUIXT and Input Assistant I only recommend this if you are already using GUIXT and Input Assistant. This is a
bolt-on produced by Synactive used to simplify and changes SAP screens. The free
component GUIXT is already packaged with all SAP versions since 1999. This would
also require the paid module called Input Assistant. It would apply a similar logic to
Option 2. It is designed specifically to work with SAP screens and makes these changes
much more rapidly than using ABAP.
Hope that helps. Let me know what solution you come up with.
Regards
Paul
The SAPGuy
Reply
Eric Bushman January 5, 2013 at 9:48 am
Jitesh,
Paul has already responded with some excellent information and included what I would
have initially responded with:
“Once you activate the payment guarantee procedure for the Document Type (ZYO in
your case), it automatically activates the display of the Payment Card tab for the
document type. It does not depend on whether the customer is also activated. The
reasoning is that it allows the user to manually add or change payment cards on the order,
irrespective of whether there was a payment card on the customer.”
SAP decided to allow the Payment Card fields on the Sales Overview screen and the
Payment Card Header Tab to be visible based on the document type. So if you‟ve
configured a certain document type to allow payment by credit card then those fields and
tab will be visible on every document of that type regardless of the partners on the
document.
There is a little used configuration technique that you could apply here, but it isn‟t
something I usually recommend because it can be extremely cumbersome to maintain. It
has to do with the “Define Payment Guarantee Schema Determination” configuration.
You‟ve mentioned already that you have setup a Document Determination Schema that is
assigned to document type ZYO. And you also said you “assigned Pyment procedure to
the customer” so you have a Customer Determination Schema configured and assigned to
customers as well. You can now limit which customers can pay by credit card by setting
up the proper Payment Guarantee Schema Determination.
Normally in that configuration step you‟d see the following (assuming a Customer
Determination Schema of „ZCPG‟, a Document Determination Schema of „ZD‟ and a
Payment Guarantee Procedure of „ZPAYME‟):
Cust Doc Payment Guarantee Procedure
BLANK ZD ZPAYME
ZCPG ZD ZPAYME
The first entry, where the Customer Determination Schema is left BLANK, is added to
allow for ANY customer(partner) to pay by credit card so long as the document has the
„ZD‟ Document Determination Schema associated with it in configuration. If you were to
remove that entry then only customers(partners) with the „ZCPG‟ Customer
Determination Schema on their Customer Master Record would be able to pay by credit
card. And specifically it must be the Payer Partner on the order that has that „ZCPG‟
Customer Determination Schema on their Customer Master Record.
The reason I don‟t typically recommend that is because you must manually maintain the
„ZCPG‟ Customer Determination Schema on their Customer Master Record on every
customer that should be allowed to pay by credit card. All other customers can not pay by
credit card. However, if that is what you‟d like to enforce then this is the best way I know
how to do so.
Regards,
Eric Bushman
Paymetric
Reply
Sarang Gujrati December 6, 2012 at 2:10 am
Hi Eric,
Sorry I dont know whether this blog is still active or not.
I am facing one problem with credit card authorization.
At the time of Sales order creation, we would like to know if we can check whether
customer credit card has authorization for the sales order amount.
The reason behind to this is that we are calling 3rd part interface to determine plant and
inventory.
So if system fails to get authorization then we have to reverse whole order back to intial
point.
so if I can determine authorization before calling the 3rd party interface then we dont
have to go through the reversal process.
Thanks,
Sarang
Reply
Eric Bushman December 6, 2012 at 9:49 am
Sarang,
SAP‟s business logic determines the amount for an Authorization request based on the
Material Availability Dates on schedule lines. If a line item on a Sales Order is in stock
(ATP) and has a Material Availability Date within what SAP calls an “Authorization
Horizon” (this is configured in the IMG – I suggest it be set to 3 days) then the amount of
that line item will be added into the Authorization amount to be requested.
So if your ATP checks are accurate and your stock is up-to-date then SAP will
automatically request an Authorization for the amount of the items that can ship in 3
days.
If you would prefer to force SAP to request an Authorization for the full order value
instead of relying on the business logic described above you can also do that by adding
code to userexit AUTHORIZATION_VALUE_SPLIT in program MV45AFZH. You
basically force SAP to include the full amount of all line items whether they can ship in 3
days or not. However, I generally advise against this.
Hopefully that answers your question. If not please let me know!
Reply
Sarang Gujrati December 20, 2012 at 9:29 am
Sorry Eric for the delay in reply. I was struck with some other issues.
Thanks for the detailed explaination. It is really helpful. Your explanination gave us very
clear picture what is actuaaly happening in the system.
Thanks once again.
Right now we are facing issues with CRM. Orders replicating from CRM in ECC are not
calling MV45AFZH user exit.
Not able to understand why.
Reply
Eric Bushman December 20, 2012 at 10:07 am
Sarang,
It has been a while since I‟ve debugged the replication of Sales Orders from CRM to
ECC. However, I seem to recall that SAP doesn‟t use the same code flow in SAPMV45A
that is used when you create orders via t-code VA01 in ECC.
What are you hoping to do with userexit MV45AFZH when replicating from CRM to
ECC? If you‟re trying to affect the authorization amount I‟d suggest you do that in CRM
before the replication happens.
I suppose I should also ask, have you configured your CRM system to perform
authorizations? Or did you setup your system to send the orders from CRM to ECC and
have the authorizations take place in ECC?
Regards,
Eric Bushman
Paymetric.
Reply
Sarang Gujrati December 20, 2012 at 12:10 pm
Thanks for the reply..
We are trying to split authorization in MV45AFZH
(AUTHORIZATION_VALUE_SPLIT) by using ZUKRI field .
Plant and other spliting criteria are determined by ECC only. Order first takes single
authorization in CRM then comes to ECC.
We want then to run our code written in MV45AFZH .
When we create order in ECC spliting code works perfectly but not in the case of
replication from CRM.
Please advise..
Thanks,
Sarang
Eric Bushman January 2, 2013 at 2:06 pm
Sarang,
I‟m not able to respond to your most recent response for some reason, so I‟ll respond
here.
CRM has different logic that is similar to MV45AFZH, but I can‟t recall off-hand what it
is. As I recall it is one of the BADIs that is available in the IMG. You‟d need to create
similar logic in that BADI for orders created in CRM.
I hope that helps.
Regards,
Eric Bushman
Paymetric
Sarang Gujrati March 18, 2013 at 4:34 am
Hi Eric/Paul,
We need to check/validate credit card authorized amount before saving the sales oder. Is
there any way or any function module which we can use in user exit MV45AFZZ
(Save_Document_Prepare.
Thanks,
Sarang
Eric Bushman March 18, 2013 at 9:19 am
Sarang,
The best approach for checking the authorized amount before the order is saved is to
create a userexit in the configuration for the Authorization Function call. In
configuration, where you specify the Function and RFC Destination for Authorization
you can call a „Z‟ function module that you create.
In that „Z‟ function you can have a “Pre Authorization” and “Post Authorization” userexit
in which you can perform any activity you‟d like. You would call the External
Authorization function between the two. In the “Post Authorization” routine you can
check the response and determine what action to take.
Alternatively, you could use USEREXIT_SAVE_DOCUMENT. The Payment Card logic
is called AFTER USEREXIT_SAVE_DOCUMENT_PREPARE and BEFORE
USEREXIT_SAVE_DOCUMENT.
Regards,
Eric Bushman
Paymetric
Tariq Bashir November 14, 2012 at 5:05 pm
Dear Mr. SapGuy:
I have been working in the credit card/payment industry for 10 years now & been
responsible for daily authorization transactions edits and processes. I making an serious
effort to move my career towards SAP based platform. Do you think that my backgroud
will help me understanding SAP if yes the which SAP module? And last any company
that you are aware of that uses SAP in credit card / payment industry?
Regards,
Tariq Bashir
Reply
SAPGuy December 6, 2012 at 8:30 am
Hi Tariq
Sorry for the delay in the reply. I have been traveling.
Having a solid background in the credit card industry is a huge advantage. The credit card
functionality is primarily in the Sales and Distribution (SD) module with parts in the
Financial (FI) module.
The majority of companies that use SAP use credit card functionality. Many companies
also use a bolt-on such as Paymetric to supplement the SAP functionality (see my
previous articles). But there are a few other vendors (who I have never worked with) as
well.
I wish you good luck.
Regards
The SAPGuy
Reply
Donna June 6, 2012 at 4:44 pm
Is anyone getting authorization for a Payment Card on the CRM Side for a Credit Memo?
We get authorization on the ECC Side for the Credit Memo but not the CRM Side. I‟m
not sure if this is related to our Paymetric Implementation or CRM.
It is causing an extra step on the ECC Side. We need to touch every Credit Memo in ECC
to get an Authorization.
Any information is appreciated.
Thanks.
Donna
World Kitchen
Reply
SAPGuy June 6, 2012 at 5:43 pm
Hi Donna
It has been a long time since I touched CRM. However, as I recall (I may be wrong), the
authorization for CRM is a call to R3. I want to refer this to a colleague at Paymetric.
Regards
Paul
Reply
Eric Bushman June 6, 2012 at 5:56 pm
Donna,
SAP CRM has it‟s own connection to Paymetric via the Cross Application Payment Card
Interface (CA-PCI) for Authorization. SAP CRM also should “authorize” a CREDIT
amount just the same as it does for a DEBIT amount.
I‟ve helped other SAP customers setup the functionality in CRM and never seen the
problem you‟re describing. Perhaps the document type isn‟t configured for Payment Card
Processing in CRM? Has it ever worked before in CRM or is this a new implementation
of CRM for World Kitchen?
Regards,
Eric Bushman
Paymetric
Reply
Donna June 7, 2012 at 3:54 pm
Hi Eric,
It has never worked in CRM and we are working on a project to reduce additional
unnecessary steps.
The document type is configured for payment card processing in CRM… I did check
that. PaymtPlan Type is 03 Payment Card and Checking Group is 01 Standard.
All other payment card authorization works.
Thanks.
Donna
Reply
StanS May 22, 2012 at 10:55 am
Hello,
I have an issue after XiPAy has successfully preauthorized a credit card, the invoice
cannot be posted/cleared successfully in SAP, even manually. I‟m a security consultant,
so please forgive my lack of understanding of the process.
It seems that some transactions fail and the AR person can pull them in manually from
XiPay and clear the invoice in SAP/successfully posting the charge. However, some she
tries will not ever process successfully. The ST01 SAP authorization trace is not very
helpful, as the RC=0 for all objects checked. In a QA environment the AR user with
SAP_ALL cannot make these particular charges post. Any idea how I can futher
troubleshoot the process?
Many thanks!
Stan
Reply
Suzi February 8, 2012 at 12:58 pm
I have a question about the $1 preauth.
We have set our authorization period for 7 days so no order will be authorized until it is
within 7 days prior to the requested delivery date. However, we are having an issue with
orders that are only obtaining a $1 preauth even though the start date is within 7 days or
even immediately.
We have put in a user exit to use requested delivery date rather than material availability
date since we use AFS and allocation will go out further than the delivery window
designated on the order. Therefore, in case other materials are allocated they can then be
delivered since we are authorizing the entire order amount.
What can we do to correct SAP from only obtaining a $1 preauth and not authorizing the
entire amount of the order plus the percentage we have added for freight costs?
Our business users are getting very annoyed that the functionality is not working as
expected.
Additionally, when VFX3 or VCC1 are being run, they are not picking up orders and
deliveries whose authorization has expired. Very frustrating. Any suggestions?
Reply
Eric Bushman February 9, 2012 at 11:00 am
Suzi,
In which userexit did you add code to have SAP consider the Requested Delivery Date
instead of the Material Availability Date when determining if the amount of a line item
should be included in the Authorization Amount? I‟d like to have a look at that in one of
my systems to see if the timing sequence of that userexit and the SAP logic to build the
Authorization request are in the correct order.
If you want to FORCE SAP to always send an Authorization Request for the FULL order
value plus the additional percentage you add to account for freight you can do that in the
AUTHORIZATION_VALUE_SPLIT userexit (program MV45AFZH – the same one
where you‟re adding in the percentage for freight). You simply change the same amounts
that you‟re adding a percentage too, or, in the case where a line item was EXCLUDED,
you add a new entry in table OPEN_VALUES to account for that line item.
VFX3 and VCC1 will only pick up documents where SAP has already indicated that an
Authorization is expired. If the Authorization is expired, but you haven‟t tried to create a
subsequent document yet then SAP doesn‟t “know” that the Authorization is expired yet
because that status isn‟t set until you attempt creation of a subsequent document. To
address that we‟d suggest you schedule our “Expiring Payment Card Authorizations”
report to run daily. This report pro-actively identifies expired transactions and resaves the
Sales Order that transaction is associated with so that SAP can attempt a new
authorization.
Reply
Suzi February 9, 2012 at 11:15 am
We added our user exit in AUTHORIZATION_VALUE_SPLIT userexit (program
MV45AFZH) as recommended by our consultant from Paymetric, Bill. It works
sometimes but sometimes it does not which makes it very difficult to determine why.
During our testing before implementation, it worked as expected but then last summer
started sporadically only authorizing $1 on some orders with immediate start dates or
start dates within the 7 day period we configured. I know the common rule is to use
material availability date but since we use AFS and our allocation settings go out beyond
the 7 days, we changed it to use requested delivery date instead. It worked fine in testing
and seemed to be working okay up until last summer when it started only authorizing $1
on some orders with immediate start dates or that were within the 7 day time frame we
configured to authorize within. Any advice is greatly appreciated.
Reply
Eric Bushman February 9, 2012 at 11:50 am
Suzi,
Will you email me the code from MV45AFZH in a text file so I can review it? You can
send it to [email protected].
As you‟re likely aware, the $1 preauthorization is what SAP will attempt if it is
determined that NO line items fall within the 7 day window of the Material Availability
Date (or in your case the Requested Delivery Date). So apparently SAP doesn‟t think the
line items are eligible.
I‟m guessing, that since you are changing which date to look at in the userexit, SAP may
have already built the OPEN_VALUES tables entries based on Material Availability
Date and that may be too late in some cases to switch to Requested Delivery Date.
Having a look at the code will be helpful!
Reply
Eric Bushman February 19, 2012 at 5:27 pm
Suzi,
I wanted to post on here, for the benefit of others reading this post, the resolution which
together we found for one of the issues you were experiencing – that of SAP requesting
multiple authorizations when you saved a Sales Order instead of just a single
authorization.
It turned out that it was a bug in the code in userexit
AUTHORIZATION_VALUE_SPLIT in program MV45AFZH where you were
overwriting the Material Availability Date with the Requested Delivery Date. The field
that was being overwritten was OPEN_VALUES-SPTAG. That is fine, but because the
date in OPEN_VALUES-FKDAT was not being changed also that caused SAP to
generate multiple Authorization Request lines in Function Module
SD_CCARD_PERFORM_AUTHORIZATION.
It came down to a COLLECT statement in Function Module
SD_CCARD_PERFORM_AUTHORIZATION that would create multiple authorization
lines whenever the OPEN_VALUES-FKDAT value was different from the
OPEN_VALUES-SPTAG value. Once we set OPEN_VALUES-FKDAT to the same
value as OPEN_VALUES-SPTAG the issue of multiple authorizations was solved.
Obscure, but understandable why it was happening once we debugged the issue.
Whether this also solves the issue of the $1 pre-authorization or not remains to be seen.
But let me know if you run into that again and we‟ll have another look.
Eric Bushman February 20, 2012 at 8:05 pm
Suzi,
Another update regarding the solution we found today for the $1 preauthorization issue. It
turned out that the configuration in PRD was different than the configuration in DEV &
QA for some reason.
The Authorization Horizon configured in DEV & QA was set to 7 days, but in PRD it
was set to 1 day. That meant that an item had to be in stock and available to be delivered
within 1 day from the current date in order for SAP to include the amount of that line
item in the Authorization Request.
The resolution was to send a transport of the correct setting of 7 days to PRD. Once that
is transported you should only see $1 preauthorization requests when there are no items
on the sales order which are in stock and available to ship within 7 days.
Jennifer Radden January 24, 2012 at 6:33 pm
Hi Nafran –
Almost all of Paymetric‟s customers integrate SAP with Paymetric via web services
using SAP‟s standard payment card interface (Cross Application Payment Card Interface)
which Paymetric is certified with. I would be happy to discuss this with you or provide
you with documentation.
Thanks,
Jennifer Radden
Reply
Cheryl December 5, 2011 at 9:15 am
Hi we have been using Paymetric for a number of years but are now implementing an
ECommerce solution. Since our shipping cost vary so widely we have been using Auto
AR to Authorize our orders (the credit card is retrieved from the order in the appropriate
exit). the problem is that when using the Auto AR functionality the authorization no
longer carries the Ecommerce indicator found in FPLT-CSOUR. Is there an exit that can
resolve this issue – or is my only solution to raise the authorization amount and to do an
immediate authorization (ie – not use Auto AR) ?
Reply
SAPGuy December 14, 2011 at 7:55 pm
Hi Cheryl
I know this indicator is used a lot these days. The merchant factor it in to assess the risk
which in turn affects the CC fees
I have not worked with the ECommerce indicator. I assume that you are setting
something on the order to indicate this order came from the web. I have seen it done a
number of ways. We have an order source field (VBKD-BSARK) at my current
implementation and one of the values is “WEB”. There is another field that is not visible
on the screens on VBAK (I believe it may be VBAK-LOGSYSB) that also indicates the
Order source. This is used by CRM for example to show that the order originated in
CRM.
Using Auto AR seems to be a logical solution way of dealing with the varying shipping
costs.
We implemented a user exit to retrieve a profit center in Auto AR. I believe the exit we
used was ZPCCC_CUSTOMER_AR_AUTO_EXIT_RI. If I recall correctly, you have to
activate it first in Table: /PMPAY/PUSREX.
There are also a few SAP notes that refer to it.Tip: Don‟t limit your search to your
current version. I often can find earlier notes, that while not relevant to your current
version, give me a some insight on a potential solution and where to look. Some possible
search terms are: ECI, E-Commerce, E-Commerce indicator.
Hope that helps. Let me know what your final solution is.
Thanks
The SAPGuy
Reply
Cheryl December 15, 2011 at 8:03 am
Thanks for replying! We did come up with a solution. I altered the user exits for pre-auth
by accessing a field from the calling program of the function module. I‟ve included the
code below if anyone else needs this. In addition it was also necessary to alter the pre
settlement user-exit to find the VBAK-BSARK and set the ecommerce flag. (code also
below)
The reason we did not use the methodology of inflating our authorization to cover the
freight was that the processing bank told us this would result in penalties if the
authorization did not match the settlement amount exactly.
Code for pre-auth
" The following assignment will only work
" when called from the Auto AR Program
lv_temp = '(/PMPAY/PRE_AUTO_AR)it_open_items_selected-vbeln'.
clear: lv_vbeln, lv_bsark.
assign (lv_temp) to .
if sy-subrc = 0.
create object lor_socc.
lor_socc->get_sales_order_for_invoice(
exporting
i_invoice =
importing
e_vbeln = lv_vbeln
exceptions
no_sales_order_for_inv = 1
others = 2
).
" Continue with the logic if the Sales Order is found for the
Invoice
if sy-subrc = 0.
" The PO Type is set to ECOM from the Web Site
select single bsark into lv_bsark
from vbak
where vbeln = lv_vbeln.
check lv_bsark = 'ECOM'.
loop at it_ccaut_in.
* condition for identifying AutoAR WebOrders and set 'E'
if lv_bsark = 'ECOM'.
it_ccaut_in-csour = 'E'.
modify it_ccaut_in.
endif.
endloop.
endif.
endif.
**** Settlement function module changes
**** Coding for Web Orders Processed via Auto AR
**** These transactions must have the CSOUR set = E. We do this based
**** on the value of the BSARK (PO Source) on the original order
loop at it_settab assigning where bukrs = '0003'.
clear l_invoice.
select single belnr into l_invoice
from /pmpay/parcl
where rebzg = -belnr
and rebuk = -bukrs
and rebzj = -gjahr
and buzei = -rfzei.
check sy-subrc = 0.
" Find the sales document for the Invoice and check the BSARK for
" ecommerce (Only the first line item is checked !)
clear l_bsark.
select single bsark into l_bsark
from vbrp inner join vbak on vbrp~vbelv = vbak~vbeln
where vbrp~vbeln = l_invoice.
" if the order is not found or it does not have po source = ecomm
exit
" otherwise update the ecommerce source flag
check l_bsark = 'ECOM'.
-csour = 'E'.
endloop.
Reply
SAPGuy December 15, 2011 at 8:53 am
Hey Cheryl
Glad you found such an elegant solution and thanks for sharing it.
Regards
Paul
Reply
subrata November 25, 2011 at 4:13 pm
Hi Paul,
When payment cards settle, there should only be 1 batch per day per G/L Account.
Since go live, we are seeing up to 3 batches per day settle. We only want to have 1 batch
settle each day with the bank.
If this continues, we may be charged an extra service charge by the bank for multiple
batches per day when there should only be 1.
Regards
Subrata
Reply
Anthony September 15, 2011 at 10:53 am
Thanks Paul. We have considered the “authorization inflation” approach and even have
the user exit coded, but haven‟t implemented. We may yet use this approach.
Coincidentally, we just recently received this not about VOID transactions that may work
for us as well. Of course this creates a possibility of voiding X amount, then authorizing
Y amount and getting declined – now you have no authorization.
Implementing Voids from SAP The Void operation is performed by making a call to the external Void Function Module
from the desired SAP program or user exit. Potential uses cases for voids include when:
The Expiration check function module is called and an authorization is marked as
expired
An order is canceled
An order is deleted
An authorization is deleted
An order amount changes
In lieu of performing a DELTA authorization in SAP, Void the original Authorization
and create a new one for the correct amount. If supported by your chosen Processor and
the Card Issuer, the Void operation makes a call to the Processor and the original
authorized amount is added back to the available credit amount in real-time. Please refer
to the Cartridge documentation for your chosen
Processor to confirm if real-time voids are supported. Otherwise, the transaction is
marked in the XiPay database so no further processing occurs and the funds are made
available once the authorization horizon has passed.
Following are the high-level steps to configure PAS and SAP for voids with XiPay:
1. Create a new RFC Destination for Voids in SAP via transaction code
SM59 with the appropriate security.
a. If needed, see XiPay SAP Integration Guide, Install and Initial
Setup Set Up RFC Destinations in SAP for detailed instructions.
2. Create a Void XAS Program in the PAS GUI.
a. If needed, see PAS Install and Config Guide, Configuration XiPay
Programs for detailed instructions.
3. Create a call to an external Operation called 'XIPAY_CC_VOID' per
the following example and implement your own security objects as
needed.
A call should be made from each user exit or program for which you are implementing
the Void Operation.
Reply
SAPGuy September 26, 2011 at 7:18 pm
Hey Anthony
That is pretty cool. Must be some new functionality, because it certainly was not there
last time I work with PM.
Thanks for sharing that.
Regards
Paul
The SAP Guy
Reply
Anthony September 8, 2011 at 3:26 pm
Hi Paul,
We have been using Paymetric for the past 18 months and have been happy with it. I
have a question that is not Paymetric specific, but CC processing in general. We get a CC
authorization for the scheduled shipment amount at the time the order is saved. But, we
also charge actual shipping costs, in some cases, which are not known until the order is
shipped and PGI‟d. This creates a billing block. We have a process that automatically
gets authorizations for these orders and release them. All well and good.
The problem we are having is that now the customer sees two (or more) charges on their
credit card bill, and in certain situations the billing can really look odd. For example, an
order is authorized for $100, but only $95 ships, and there is a $15 shipping charge
added. The total invoice will be for $110 so an additional $10 authorization is needed.
The customer now sees a $100 charge and a $10 charge. Is there any way that you know
of where the two authorizations or settlements can be combined so that that the customer
only sees one charge of $110?
Thanks,
Anthony
Reply
SAPGuy September 15, 2011 at 8:09 am
Hey Anthony
Apologies for the late reply. I have been on vacation.
We had a similar issue at a client. The way we dealt with it was as follows:
We calculated the maximum freight an order was likely to be charged as a percentage of
the order value. So for example: We calculated that no order would ever have freight
charges exceeding 10%. Then instead of authorizing a $100 order for $100, we would
authorize it for $100 + 10% = $110. That way you only have one authorization. I would
not hardcode that 10%. I would rather put it in a TVAR variable (TCode: STVARV) or
alternatively if you have a good pricing person, save it in a statistical pricing condition.
This way you can refine it on the fly without having to do code changes. Obviously, this
is a user exit.
To answer your question though, it is not possible to “combine” 2 different
authorizations. You cannot use authorizations more than once either. For example: if you
have payment plans (typically used for projects) you have to get a new authorization for
each settlement.
Another way you might be tempted to “combine” authorizations would be to simply
ignore the 2 authorizations and get a new authorization for the whole amount via a user
exit at billing or settlement. As I am sure you know (but it is worth mentioning for other
readers), this would create further issues for the customers. While you would only get one
charge appearing on customer‟s credit card which would use up the new authorization,
the original 2 authorizations would still “consume” the customers available credit on that
credit card until those authorizations expire (7 days to 30 days, depending on the card).
Hope that helps.
Regards
Paul
Reply
Prachi September 9, 2012 at 1:38 pm
Hi Paul,
This is an interesting blog. Thank you!
I seek your inputs for dealing the situation with respect to
additional authorization for Freight amount in the sales order.We use Paymetrics for our
credit card processing.
Our calculation is that no order would ever have freight charges exceeding 10%, so this
value has been hard coded in MV45AFZH.
While saving sales order, if the order value is $100, then our order is authorised with a
total value of $ 110, but we have TWO DIFFERENT authorization lines – one for $100
and one for $10.
During PGI actual Freight was say $4.
So my Billing document-.Header->Payment Card has two lines:
Billing Val Authorized Amt
Net val auth 100 100
Frieght auth 4 10
When I pass this data for Settlement using ZFIPMFCC1 transaction (delivered by
Paymetrics – copy of std FCC1)
I am sending above two lines and hence Customer sees these two lines/charges in his
credit card statement.
So, as of today my customer‟s credit card statement shows:
Reference Billing dt Billing amt Curr
Billindoc#7100000000 06/26/2012 100 USD
Orde#XYZ 06/26/2012 4 USD
Is there any method by which, the customer‟s credit card is charged only once (so that he
sees only one charge item of $104)?
You suggestions would be appreciated. Thank you.
Reply
SAPGuy September 9, 2012 at 4:04 pm
Hi
Is there a reason that you are creating 2 authorizations?
Typically, we would do 1 authorization for say $110 in your example. You are basically
inflating the value that you submit for the authorization. Instead of submitting the order
twice for authorization, you are only submitting it once for $110.
Now, say the actual freight was only $4.
Now your billing document is for $104.00 and thus you have a single settlement for $104
(as you have a single authorization that is more than the $104).
Regards
Paul
Reply
Prachi September 9, 2012 at 4:21 pm
Hi Paul,
We submit the sales order only once for authorization. Which, creates one line for USD
100 (order net value) and another line for USD10. (to cover 10% for freight).
So I am not inflating any value but just covering for my freight that is not known until
PGI.
Is there a way/exit I can combine the two authorizations on a single line in sales order
itself?
Prachi
Ron April 20, 2011 at 9:23 pm
Hi Paul,
Your posts are quite informative.
We have requirement to implement Credit card functionality. My primary question is –
can it be done without 3rd party tool (ex: paymetric) ? Why do we need 3rd party tools ?
Thanks for publishing useful information.
Regards,
Ron
Reply
SAPGuy April 26, 2011 at 8:07 am
Hi Ron
Besides some of the gaps mentioned in this article, a big reason to use a 3rd party vendor
is the certification of the interface to your credit card provider (See this post for more
information).
Is it possible to do it yourself? Absolutely. But, I would suggest you build a dedicated
team of business, functional and developers to do it. It may take you a whole lot longer to
do it than you think. You will also have to deal with the legal ramifications of securing
your credit card information (See this article for a brief introduction).
At the end of the day, I think you will discover that the costs are a lot more than you
think. Much the same way as almost no companies in the USA try to maintain their own
tax rates in SAP (they all use a tax solution such as Vertex or Taxware that does monthly
updates to account for tax changes), I would recommend the same strategy with credit
cards (use a solution such as Paymetric). In my opinion, it is just not worth it doing it on
your own.
Hope that helps.
Best Regards
Paul
The SAPGuy
Reply
SShr April 11, 2011 at 2:04 pm
Hi Paul
Does Paymetric functionality work with noted items? We are still prototyping milestone
type orders and the first step is to create a noted item for downpayment request. if the
credit card info is stored in sales order. Will it automatically settle and change to a
downpayment. I tried creating a request using F-37 and tried using paymetric receivables
Tcode and it doesnot show that particulatr item in open items list!
Reply
SAPGuy April 11, 2011 at 3:32 pm
Hi Sangeet
Couple of things here.
Not familiar with the terminology “noted items”. I assume a down payment is an example
of a noted item. If you are processing down payments in SD, you are making use of
Billing Plans.
Processing Down Payments & Payment Cards in SD
SAP Limitation Standard SAP cannot handle periodic payments with Credit Cards (periodic or milestone
i.e. Progress Billing). It gets the authorization on the order and the first time it bills, it
uses that authorization up. The authorization can only be used once. It does not have the
ability to go back and get another authorization for the next payment on the order.
Additionally, SAP tries to authorize the whole amount instead of only the relevant
payment. Example: 10 Progress Bills of $10,000 over 10 months. SAP would try to
create an authorization for $100,000 instead of only $10,000.
Paymetric Solution is AutoAR. How does AutoAR work? It is actually very similar to Paymetric Open AR. It also runs post billing. However, it
fetches the CC information from the Sales Order, gets an authorization and processes it as
an incoming payment and clearing document.
User Exits in the order and how it works All the magic happens on the order. When a user enters a credit card on the order that has
items that are relevant for Billing Plans (SAP‟s term for Progress Bills), it does 2 things:
Applies a unique Payment Term – “ZAUT-Paymetric Auto AR” for example
It removes some indicators that allow the item to process to billing as a normal
AR (as opposed to billing by CC).
Now when we run the Auto AR Program, we filter by payment terms of ZAUT.
Therefore, Auto AR shows a list of Progress Bills that have already been invoiced. The
Auto AR Program then fetches the credit card information from the sales order, gets a CC
authorization and processes it as an incoming payment & clearing document. This must
now also be settled.
A useful SAP Note 313416.
Processing Down Payments & Payment Cards in FI Processing via F-37 will probably not work. If you review even the standard SAP
programs, they all get information from the order.
Your only option here is to use the Paymetric Open AR module.
Hope that gives you some direction.
Regards
Paul
The SAPGuy
Reply
SShr April 26, 2011 at 1:42 pm
Sorry for replying late. Thank you for all the pointers.
To your question – “I assume a down payment is an example of a noted item”. This
actually is not. Noted Items are ones that are not real financial entries (for example –
Downpayment requests- from sales point it is type – FAZ). These noted items change to
an actual downpayment only when payment is applied. Paymetrics pay open AR
transaction does not show these as open items even though they are in open AR table.
F110 transaction pulls these once special GL indicator is included in the config. Probably
we need to approach paymetrics for solution?
Reply
SAPGuy April 26, 2011 at 5:01 pm
Hey Sangeet
Interesting. I have done some prototyping with down payments quite a while ago, but we
never ended up using them. They decided to process them through FI.
I think your best bet is to approach Paymetric for a solution. I would be curious to hear
what your final solution is.
Regards
Paul
The SAPGuy
Reply
GopiKrishna April 5, 2011 at 5:58 pm
Hi Paul,
We have implemented payment cards through XiPay which works well when we
authorize the payment card at sales order level. However due to business need I had to
pre-auth $1 at order level and then get an actual auth at delivery level , I tried the user
exit but I am stuck with an issue.
Teh problem is that when I call SD_ORDER_PAYMENTCARD_AUTHORISA before
creating delivery it clear some values such as sship to party and the system is unable to
generate a delivery because of that.
I would appreciate if you can let me know if there is any similar issue you faced and any
possible solution.
Reply
SAPGuy April 7, 2011 at 3:05 pm
Hi Gopi
I am sorry. I have not run into this problem. There are 2 ways I would approach this
issue:
Configure the Payment Card authorization to Authorize the card 0 days before
delivery. Schedule the authorization before the delivery due list runs every day. That way
you are using standard functionality.
Create the delivery. On save, call the authorization routine. If the authorization fails, it
will block the delivery. The blocked delivery will appear in the Credit Reps Worklist
(TCode: VKM1)
You could also approach Paymetric and ask them for an old document they have:
“TEC900-005 – Authorization During Delivery Creation Guide.pdf”. It may not be 100%
valid today, but it may give you some ideas.
Hope that helps.
Regards
The SAPGuy
Reply
Keshini March 3, 2011 at 2:34 pm
Hi,
Nice Article. Very informative.
We are planning on implementing payment cards and will work on Paymetric on this as
well.
However i have configured the standard payment card functionality in SAP(Using
function module provided by SAP to test authorizations), and would like to know
whether its possible to authorize the credit card for the value at the delivery save. The
authorization should only cover the value in the delivery and not the amount on the sales
order.
Appreciate if you could please let me know if its possible?
Reply
SAPGuy March 5, 2011 at 10:13 pm
Hi Keshini
Interesting question.
Let‟s first consider what the standard behavior is. A pre-authorization is done when the
order is created. This is usually for a small amount such as $1. It is just to make sure that
the credit card is valid and not blocked or reported stolen. Then depending on the settings
in your system, the real authorization takes place a certain number of days before the
material availability date (MAT). This is the date when the delivery can be created.
On delivery create, the system verifies that the authorization exists and is not expired.
This check also happens for a delivery change. Note, it does not apply for an
authorization on the delivery, it only checks if it has a valid one.
If the credit card authorization has expired, it will set the sales order authorized amount to
zero, set the delivery status to not approved and give you a message to reauthorize the
Sales Order. This can also happen if you change the quantity on the delivery to more that
the order (a setting on the delivery item category controls if you can do this or not).
Note that most of the action happens on the sales order. The CC information is not even
on the delivery.
Here are some classic issues that do occur.
The order is $200. The delivery is only for $100, the remaining $100 is on backorder.
You bill the customer for the $100 and it is settled via the credit card. Now you deliver
the remaining $100. When you invoice it, you get a message “Document 91…. saved
(faulty authorization)”. This is because an authorization can only be used once, even if it
is not fully used up. The only solution is to reauthorize the order for the remaining $100.
Back to your question. It can be done via a user exit. Bear in mind that the Payment Card
checks make use of the Credit Check functionality. The function module used to check
the credit from a delivery is SD_DELIVERY_CREDIT_CHECK. Look at TCode: oVA8
where you define the automatic credit checks for deliveries and orders. Find the check
used on the delivery. In the Checks section, you will see a User 1, User 2 and User 3.
These activate the call to user exits. The user exit for User 1 is found in program
LVKMPFZ1. The function module to call is
SD_ORDER_PAYMENTCARD_AUTHORISA. This should give you a clue where to
look.
I understand what you are trying to do and why. I would however challenge the business
with some questions such as:
1. Why are there so many orders that you cannot deliver fully? In other words, why so
many backorders?
2. If an authorization check fails on the delivery, what do you do now? You have already
allocated that delivery to ATP.
3. How long will it take to get a new credit card or authorization? Do you still want to
“hold” that inventory?
…
I am sure you can come up with half a dozen more
Hope this helps. Good luck.
Warmest regards
Paul
The SAPGuy
Reply
NAFRAN February 15, 2011 at 6:49 am
Hi ,
Interesting blog. But I have a question which I was trying to search the answer and got
into this blog. I would like to know the flowing
you have mentioned
“The solution comprises of a group of SAP programs (imported as a series of transports)
and a separate server called XiPay (actually server is a misnomer, it is actually a piece of
middleware that communicates with the payment processor). There is also an
encryption/decryption server which resides on the same box.”
this means we can use this with out PI . I mean my question is can this be implemented in
a normal R/3 system which does not use PI.
I tried to checking on any documentation and it seems its bit difficult to find any unlike
paypal‟s payflowpro where the documentation is readily available.
Thanks
Nafran
Reply
SAPGuy February 16, 2011 at 9:27 pm
Hi Nafran
Glad you enjoyed the articles.
The solution does not rely on PI at all. We did not have PI implemented in our system.
And in fact at my current client, they have Paymetric and do not have PI at all (we are on
4.7).
Hope that helps.
Regards
Paul
The SAPGuy
Reply
NAFRAN February 18, 2011 at 12:10 pm
Hi Paul,
Thanks for updating me with that info. since most web sites were saying Xipay was
connecting trough SAP PI. I wanted to know if this can really be used with out PI.
Thanks a lot for your info. btw is there any place you know where I can find some
documentation on this product .
Thanks
Nafran
Reply
SAPGuy February 19, 2011 at 8:30 am
Hi Nafran
Your best bet to get any up to date documentation is to contact Paymetric directly. I have
not worked with it for a while now and I have not worked with their new hosted solution.
Regards
Paul
The SAPGuy
Reply
Suzi February 21, 2012 at 9:31 am
Yes, once we retransported the correct value of 7 days, orders within the 7 day auth are
now processing as expected rather than getting the $1 preauth. Thanks again for your
help.