Paymetric SAP Credit Card Solution.docx

Working with Paymetric SAP Credit Card SolutionThey 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 BushmanPaymetric.

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


http://www.paymetric.com/


Lesley,

My pleasure!

Do you mind sharing how you automated the requests?

Regards,

Eric BushmanPaymetric

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,


Reply


Alex June 6, 2013 at 4:26 pm

Hi Eric,

I have a question for you. Please take a look at the scenarioPaymetric 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


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,


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 exitThis 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 AssistantI 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.

RegardsPaulThe 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 ProcedureBLANK ZD ZPAYMEZCPG 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,


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 BushmanPaymetric.

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,


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,


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.

RegardsThe 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.DonnaWorld 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.

RegardsPaul

Reply


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,


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 [email protected]

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.

ThanksThe 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 CherylGlad you found such an elegant solution and thanks for sharing it.RegardsPaul

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.

RegardsSubrata

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 SAPThe Void operation is performed by making a call to the external Void Function Modulefrom 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 chosenProcessor 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.

RegardsPaulThe 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 AnthonyApologies 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.

RegardsPaul

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 toadditional 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 AmtNet val auth 100 100Frieght 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 CurrBillindoc#7100000000 06/26/2012 100 USDOrde#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).

RegardsPaul

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 RegardsPaulThe 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 LimitationStandard 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 worksAll 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 exampleIt 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 FIProcessing 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.

RegardsPaul

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


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.


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


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.

RegardsThe 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

PaulThe 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 flowingyou 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.

ThanksNafran

Reply

SAPGuy February 16, 2011 at 9:27 pm

Hi NafranGlad 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.


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 .

ThanksNafran

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.


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.

Paymetric SAP Credit Card Solution.docx

Documents

Transcript of Paymetric SAP Credit Card Solution.docx