New features for payment card handling in sales orders with 2008

[former_member37881]

I am happy to share with you that with SAP S/4HANA Cloud 2008, we added three great new features for our payment card solution in the sales order process.

Let me start with my personal highlight:

New app ‘Resolve Payment Card Issues – Reauthorizations’

This app will make life much easier for you if you need to detect issues with payment cards in sales orders, and deliveries (for example, like expired authorizations, or only available pre-authorizations without any final authorizations ).

Some real-life examples where this app will help you:

a. You created an outbound delivery for a sales order which is covered by a payment card; at that time, the authorization of the payment card was valid. But then, the goods issue is delayed, and in the meantime the authorization expires. You only notice this when you try to post the goods issue which terminates with an error message, telling you that the authorization expired. In the past you had to find the related sales order and update it to trigger a new re-authorization. Only then could you post the goods issue from the delivery.

With our new app, you can simply search for the delivery number for the failed goods issue. This will show you the related sales order which needs a new valid authorization. Then just choose ‘Reauthorize’ – and now the shipping clerk can go on with posting the goods issue.

b. You have a completed sales order with two open deliveries. Only one authorization exists in the sales order, so you will need a second authorization from this order , one for each delivery. The ‘Resolve Payment Card Issues - Schedule Job’ app will not select this sales order for re-authorization, as it only selects open sales orders. Now again, you just need to know either the related sales order number] or one of the delivery numbers and search for it in the new app. Choose 'Reauthorize', and you're good to go on with your process. The following screenshots illustrate this example:

i. You create a sales order covered by a payment card (notice there’s only one authorization) with two deliveries

ii. You try to post the goods issue for the second delivery, but it fails due to missing authorizations

iii. You find this delivery in the new app, select it, and reauthorize the related order

iiii. A new authorization was triggered and you can now post the goods issue from the delivery

c. A straightforward use case would be checking which authorizations of sales orders are about to expire soon, by selecting for example today or tomorrow as authorization expiry date:

In addition, you can configure the result list and adapt it to your purposes. We provide several standard views.

2. Our Business Add-In (BAdI) 'Sales Document Check Before Save' was enhanced with payment card fields.

With this enhancement, you can now implement your own checks based on payment cards. For example, you might want to make credit cards the mandatory payment method for sales orders with specific payment terms. So you can check with this BAdI whether a credit card was entered in the sales order if the respective payment terms are found. Only in this case would you then allow the saving of the order, otherwise, you would raise an error. This is illustrated by the following example coding:

if salesdocument-customerpaymentterms = '0001' and salesdocument-paymentguaranteeprocedure is not initial.

if lines( electronicpaymentdetails ) = 0.

append value #( messagetype = 'E' messagetext = 'Credit card payment mandatory, maintain credit card.' ) to messages.

endif.

endif.

3. Documented credit decision for credit block due to payment cards

In case of payment card issues, like expired authorizations, the sales order and the related delivery get a credit block. There is a special credit status for credit blocks caused by payment cards. However, the overall credit status also leads to a block, which prevents follow-up activities. In case of a credit block set by a credit limit check a documented credit decision (DCD) is created. Until now, this was not possible for credit blocks based on payment cards. But now we changed this! So as of release 2008, a documented credit decision will be created for a credit block based on a payment card block in sales orders and deliveries. So, the credit controller can now decide on actions for exceptional cases. Here's an example: After the first delivery of a sales order, the payment card is stolen. This blocks the sales order and you cannot proceed. The credit controller can now decide that this sales order will be treated like a sales order payed on invoice (without charging the payment card) by executing a credit release for it from the documented credit decision.

Also, in case a delivery has a credit block set due to payment card issues and the payment card issue was already resolved in the related sales order, a recheck can simply be triggered from the documented credit decision.

To be able to use this feature, credit management must be active in your system for the payer. This means that, for example, a credit account and a credit segment must exist before you can generate a DCD.