Skip to Content

Exchange Process: Sales Returns and Sales in one Sales Order

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!

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • Best Answer
    Oct 26, 2017 at 07:50 PM
    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.

    Add comment
    10|10000 characters needed characters exceeded

    • 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).

  • Oct 23, 2017 at 12:07 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

  • Oct 20, 2017 at 03:26 PM

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

    Add comment
    10|10000 characters needed characters exceeded

  • Oct 20, 2017 at 02:31 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded