Exchange Process: Sales Returns and Sales in one Sales Order

[schoaib_ahmed]

Hello!

We have a scenario wherein we are getting data from a third Party POS system wherein the Customer Exchange certain goods over the counter and get it exchanged from other one and balance is paid accordingly.

I have created a Sales Order with both TAN and REN item category. Maintained in the Copy Control as well. It is working fine till Delivery and executing PGI and PGR in one Delivery document.

When it comes to Billing, how can we achieve that by recording Sales with A/R and Credit Memo in one Billing document which has to be delivery related?

In VTFA copy control Delivery to Billing, 002 Ord-rel.credit memo is maintained in standard Data VBRK/VBRP.

This is a business requirement as there are some hindrances from the thrid party system as it allows both outgoing and returned goods in one invoice and same needs to be replicated in SAP SD as well.

Looking anxiously for expert insights.

Thanks!

[Jelena · Accepted solution]

same needs to be replicated in SAP SD 

I believe this is a false assumption. There doesn't seem to be a requirement to implement the same exact process in SAP. All you need is to have the sales and financial data recorded properly in SAP. How third-party system does it should have no effect on how this is implemented in SAP.

We have a similar process configured but my colleagues mentioned on many occasions that they wish it wasn't done, so I won't go into details. From the technical standpoint, those documents caused additional work in the custom reports and interfaces because the "inbound" (i.e. returned) items had to be excluded from the sales information. There was literally not a single transaction we could use without having to filter out those lines.

Fortunately, lately those "exchange" document types have been abandoned in favor of regular return/sale process. I'd urge you to question what is the actual end goal here. I bet "make it work like another system" can't be it.

There are a couple more old SCN posts on the subject: here and here.

[VeselinaPeykova · Accepted solution]

You are right, such process could cause problems with reporting.

In our case all reporting and printforms were based on parameters for item categories/document types etc. that we kept in a small z-table, so we did not encounter this kind of issues.

The exchange process is tricky in reality and I also wished it gone. It is only manageable with a low number of documents and really good discipline from the business.

To be fair, in the case described by the OP I would try persuading the client not to use exchange at all and treat this as a combination of standard sales and a return (preferably requiring approval/inspection). The main reason is that if you go to a shop to return a product (for example SSD) that you bought previously, this is allowed only in specific cases - e.g. you return it within the warranty period, it cannot be repaired, you did not violate the warranty, there are no replacements of the same article (the vendor called off the product due to problems), the equivalent that I chose has a higher price. In this case you get your money back for the original SSD, they update products bought and valid warranties per customer, receive the faulty SSD (probably will ship it back to the vendor), issue a new SSD, print out new warranty, create and print a new invoice.

If it was discovered that the warranty was violated or if I decided to get a new SSD from somewhere else this process would not apply. For finished products processes can get complicated very fast, which is why I would not recommend exchange for such scenarios even for low number of documents (mine was for returnable containers, which were non valuated materials, we only collected deposit for them and the business proved that they can handle exceptional cases with good discipline and proper business controls).

[Lakshmipathi]

In one of my support projects, one process was running similar to what you mentioned and we had some unexpected issues which I don't remember now (as it is almost 8 years back). The reason for the root cause was the document category validated in many SAP standard programs and we had to carry code corrections which could have been avoided had the business process been configured with the standard document types. Of course, it was in old version and not sure, whether SAP has taken care of this in the latest environment.

[schoaib_ahmed]

I have made note of that.. cannot rule out system's behavior even if its a newer version

[VeselinaPeykova]

I have worked in the past on a process similar to yours.

I would not say that it is impossible to bill together in F2 delivery-related and order-related return items, it is possible. I just did it.

Although, considering that I had to do some shameful things to get around the billing split for reference/assignment and that there are entries in the log which look confusing, I really did not like the end result.

Any chance to reconsider and go with order related on delivery quantity (billing relevance G) all the way?

This is what I used actually in my project and it worked out quite well...

[schoaib_ahmed]

Hi

Really would like to learn this.. though it should not be practiced but there are some times situation becomes helpless.

Please share the configuration in detail of how it was achieved. Would be really thankful.

Waiting and looking forward.

[VeselinaPeykova]

The only serious problem that I faced when reproducing your case was assignment/reference that caused invoice split. For testing purposes I forced the same values for assignment and reference to be used in order-related and delivery-related case by changing copy controls VTFL and VTLA at header level. And, of course, I had to ensure that the dates for order-related and delivery related case are the same.

My return item is actually with billing relevance G, but it still uses the order as reference like billing relevance B.

I have already shared some of the configuration for the project that I mentioned in a blog on this site. It is a bit different to what you are doing - my aim was to manage returnable containers, I used BOM explosion and I had no problems with credit control due to the process specifics. Probably if you read the blog, you could figure out how to adapt it for yous case.

[schoaib_ahmed]

Hi..

Thanks for the detailed reply.

I will try to go through the blog.

Let's see what it turns out to be.

[Lakshmipathi]

Not at all possible. When the document category for standard order, return order, delivery & return delivery are different, how is it possible to achieve this ? Just because some third party software is working like this, it doesn't mean that SAP should behave in the same way. Please try to convince your client that it is not possible.

[schoaib_ahmed]

Boss you are SD Veteran I agree to what you said and trying to convince but the situation is I would say is compromised.

Thanks.