Handling Credit Sales at a Store

[gkathotia]

Dear all,

I am struggling with some very basic POS level store operations fundamentals and would appreciate any insight on them.

FACTS:

u2022SAP Retail is implemented at the back end

u2022There is no SRS (Retail Store) in the store

u2022The Customer is using a 3rd part POS software (Wincor Nixdorf) and not SAP POS

u2022Our client here is not a Retailer in the true sense of the word. They also cater to u2018creditu2019 customers. i.e. a lot of u2018knownu2019 (with master records in SAP and also sent to POS) customers coming in the store and buying goods on credit (i.e. not making immediate payment at stores). The sales process is estimated to happen only through POS terminals at store

u2022The 3rd Party POS does not have u2018Sales Order OR Customers with creditu2019 handling functionality

-

---

PROBLEM STATEMENT

Now,

u2022During POS interface, we would obviously now have to debit the known customer clearing account and credit the Revenue account (A regular POS sales incoming through WPUBON debits the Storeu2019s CUSTOMER master and credits the Revenue Account)

u2022We would have to take care of handling outbound deliveries (complete or split) at store!

u2022We would have to take care of availability check, credit limit check and dynamic updating of credit limit at the store!

u2022We would have to handle customer payments (clearing of their receivables maybe after 2-3 months) at the store!

u2022Etc etc

-

---

POINTERS

Any idea of how this can be achieved at the 3rd party store POS by integrating with SAP ERP?

u2022If we decide to handle credit sale through standard SAP SD route by installing SAP GUI at the store, we run the risk of dual Sales reporting (POS sales and SAP SD sales), feeding into 2 separate cubes/data sources of BI, not being able to use POSDM to handle SD sales etc. I would also then not be able to use Bonus Buys

u2022Developments are the 2nd choice? Basically the idea is to handle credit sales at the POS?

Any school of thought (similar dilemma faced) is welcome!

Regards

Gk

[Former Member · Accepted solution]

Hi

Its very interesting requirement.

First of all in retail business environment no one will offer credit basis. so i have no idea SAP Retail has credit funcationlity or not.

But we can map your senario with integrating SD credit mangement.

> Create sales document, delivery and billing docs for only credit business, (POS has already order type and billing type, those cant use for credit)

> Set up all credit mangt config - cc area, group, risk category etc

> Create customers for credit mangement - XD01

> define payment terms for customers,(this shows credit duration of customer, like he may pay after 3 months, if he fails to payment after 1 months system shold block his next orders)

> Maintain the cc limit in FD32

> you should have GUI @ store for run sale order transactions

regards

satish

[gkathotia]

Hi Satish,

Thanks for the thought.

1) However, the idea is that the client insists that the sales happens through POS so that there is one kind of reporting (if we use SAP for sales, distribution, billing then we would have 2 reporting lines - SD sales and POS sales).

2) If I had to do a common promotion/bonus buy, I would have to do that in both SAP sales orders/POS and we know that SAP

SD deos not handle bonus buys.

3) In any case, the client does not have any SAP GUI at the stores

Credit management, as you have told, would, in any case be set up in SAP.

THE STANDARD POSTING THROUGH WPUBON IN SAP IS

-

---

(A)

Tender Type (DEBIT)

Revenue (CREDIT)

WHAT, I THINK, I WOULD NEED FOR CREDIT SALES ARE 2 ENTRIES

-

---

(B)

Dummy Tender type (maybe called as credit tender type) (DEBIT)

Revenue (CREDIT)

AND

(C)

Actual Known Customer Account (sent through wpubon-kundnr) (DEBIT)

Dummy Tender Type (CREDIT)

Any idea is this is a correct thought process. If yes, how do I achieve (C) as above? We tried exploring WPUFIB (Financial IDoC)

but somehow I am not able to give the 'Actual Known Customer Account' as one of the 'Debit' entry.

Regards

Gaurav

[tn_naveen]

Gaurav,

If you go for SAP GUI at the Store to handle sales to known customers, You need to keep the following in mind:

1. I dont see an issue with Sales Reporting. You can extract only the Billing data to BI and this would be common for both POS and SD Sales.

2. What happens if there is no credit for the customer, but he is willing to pay cash. You must configure the downpayment scenario for SD Sales. The Cash needs to be collected in POS

3. As you mentioned, Bonus Buys cannot be used for SD Sales. The best you can do is replicate the same Bonus Buy as Free Goods in the promotion (Note that Free Goods cannot support all the functionality that Bonus Buy offers) You woul also need to activate Promotion determination in SD if you want to further analyse Promotional Sales.

If you go for Sales Via POS only always, you will need to keep the following in mind -

1. think on the lines of RFC call to SAP for dynamic credit check for known customers.

2. Interface to Create Sales Order in SAP. Again I dont see this impacting Sales Analysis as you would be extracting Billing data only.

3. Do you have scenarios where the goods are delivered to the known customer on a future date?

4. What about delivery from Vendor to the customer? (Third Party Orders) etc.

Hope I have not raised further questions instead of answering any!!

Cheers,

Naveen

[gkathotia]

Dear Naveen,

Thanks a lot for your inputs. Please see my answers to the sme below:

1. I dont see an issue with Sales Reporting. You can extract only the Billing data to BI and this would be common for both POS and SD Sales.

I STILL BELEIVE SOME TWEAKING AROUND WITH THE STANDARD BI CONTENT WOULD BE REQUIRED. STANDARD SD SALES ARE FOR E.G. REFELECTED IN S001, S002, S003 INFOSTRUCTURES ETC, WHILE THE POS SALES ARE REFLECTED IN S120

2. What happens if there is no credit for the customer, but he is willing to pay cash. You must configure the downpayment scenario for SD Sales. The Cash needs to be collected in POS

IF WE ARE IN FACT USING SAP GUI AT THE STORE, WHY CAN'T WE HANDLE DOWN PAYMENT ENTIRLY THORUGH SAP SD WITHOTU POS COMING INTO THE PICTURE. DOWN PAYMETN COLLECTION ALSO WOULD BE HANDLED THROUGH SAP SD AS A STANDARD FUNCTIONALITY

3. As you mentioned, Bonus Buys cannot be used for SD Sales. The best you can do is replicate the same Bonus Buy as Free Goods in the promotion (Note that Free Goods cannot support all the functionality that Bonus Buy offers) You woul also need to activate Promotion determination in SD if you want to further analyse Promotional Sales.

YOU ARE RIGHT

If you go for Sales Via POS only always, you will need to keep the following in mind -

1. think on the lines of RFC call to SAP for dynamic credit check for known customers.

WE ARE THINKING OF USING CREATING AND CONSUMING SOME WEB SERVICE TO READ A KNOWN CUSTOMER'S CREDIT LIMIT AND REJECT POS BILLING IF CREDIT LIMIT IS INSUFFICIENT

2. Interface to Create Sales Order in SAP. Again I dont see this impacting Sales Analysis as you would be extracting Billing data only.

WHY DO WE NEED TO CREATE SALES ORDER IN SAP. WE ONLY NEED TO CHECK IF THE POS GIVES A TENDER TYPE CALLED

"CREDIT" AND IF SO, WE CREATE A FINANCIAL DOCUMENT INCREASING CUSTOMER RECEIVABLES AND REVENUE. ASSUMPTION IS THAT POS IS ABLE TO GIVE ME THIS TENDER TYPE AND ALSO GIVESME THE KNOWN CUSTOMER'S NAME

3. Do you have scenarios where the goods are delivered to the known customer on a future date?

YES, AND WE ARE STILL PONDERING ON HOW TO ADDRESS THIS

4. What about delivery from Vendor to the customer? (Third Party Orders) etc.

WILL BE DONE ENTIRELY THROUGH SAP S THROUGH PHONE CALL OR CUSTOMERS DIVERTED TO THE DC WHERE THE ORDER WILL BE RAISED

[tn_naveen]

1. I dont see an issue with Sales Reporting. You can extract only the Billing data to BI and this would be common for both POS and SD Sales.

I STILL BELEIVE SOME TWEAKING AROUND WITH THE STANDARD BI CONTENT WOULD BE REQUIRED. STANDARD SD SALES ARE FOR E.G. REFELECTED IN S001, S002, S003 INFOSTRUCTURES ETC, WHILE THE POS SALES ARE REFLECTED IN S120

If you have a BW system in the landscape you would not be using the infostructures at all. Use the standard extractor for billing item 2LIS_13_VDITM to extract data into a BW infocube. Pls consult with your BW consultant on this.

2. What happens if there is no credit for the customer, but he is willing to pay cash. You must configure the downpayment scenario for SD Sales. The Cash needs to be collected in POS

IF WE ARE IN FACT USING SAP GUI AT THE STORE, WHY CAN'T WE HANDLE DOWN PAYMENT ENTIRLY THORUGH SAP SD WITHOTU POS COMING INTO THE PICTURE. DOWN PAYMETN COLLECTION ALSO WOULD BE HANDLED THROUGH SAP SD AS A STANDARD FUNCTIONALITY

I am not sure how functionality like cash balancing will happen if you dont handle cash via POS. You would still need to collect the cash and put it in the till and manage the the End of Day processing and cash balancing activities on POS.

If you go for Sales Via POS only always, you will need to keep the following in mind -

2. Interface to Create Sales Order in SAP. Again I dont see this impacting Sales Analysis as you would be extracting Billing data only.

WHY DO WE NEED TO CREATE SALES ORDER IN SAP. WE ONLY NEED TO CHECK IF THE POS GIVES A TENDER TYPE CALLED

"CREDIT" AND IF SO, WE CREATE A FINANCIAL DOCUMENT INCREASING CUSTOMER RECEIVABLES AND REVENUE. ASSUMPTION IS THAT POS IS ABLE TO GIVE ME THIS TENDER TYPE AND ALSO GIVESME THE KNOWN CUSTOMER'S NAME

You are right. You could create a billing doc directly. The SO is more useful if you have scenarios where there is a future delivery date etc. which was my next question earlier.

Good Luck with the project!

Cheers,

Naveen

[Former Member]

For your point

u2022We would have to take care of availability check, credit limit check and dynamic updating of credit limit at the store!

You can achieve this through SAP standard IDoc WP_PER, because credit limit field is the part of standard IDoc in SAP Retail .

OR

You can achieve this throught SAP standard change pointers functionality available in SAP Retail system, the only thing you need to enhance your standard IDoc to add change enabled balance feed to IDoc.

If you are using customer's credit management functionality in SAP and you want to use the same in POS also, then you need to feed customer master from SAP to POS , You ca use WP_PER IDoc to achieve this.

Tables Involved, to calculating customers current open balance

BSID (customer open items)

BSAD (Accounts Receivables - Customers Cleared Items)

You can use the following BAPI to get Customer account balance at a key date

BAPI: - BAPI_AR_ACC_GETKEYDATEBALANCE

In standard SAP ECC, KNKK table can be included in BD52 to obtain change enabled A/R balance (customeru2019s Open balance).

Object class: KLIM

Table: KNKK

Field: SKFOR - Total receivables (for credit limit check)

SKFOR filed is always providing current open A/R balance amount.

Ajay

Edited by: Ajay Kumar Minhas on Jul 20, 2010 12:57 PM

[Former Member]

I know this post has some time now, but was this solved? This is a very common scenario in smaller retails that do not have store charge cards.

[gkathotia]

Hi Jose

We didnt any 'right' or 'exact' solution and the customer decided to use SAP GUI at stores to handle sales order based sales

Regards

Gaurav

[Former Member]

Guarav,

We have solved this to a certain extent with custom development.

1. The Client PLU has to be sent to the POS

2. Once a store credit is invoked as a method of payment, POS asks for a client number

3. The POS sends a message containing transaction total along with client number to ERP regarding the client's balance via incoming FTP flat file.

4. The ERP sends a message back via FTP flat file confirming to proceed transaction if remaining credit is available, and to reject if credit is not available.

5. When the transaction is completed, the transaction is sent in the TLOG file with customer number.

Let me know if this helps.

Regards,

Jose