3

First off, this seems like a fairly basic function required for ecommerce.

I was presented with a question today:

"Will our new website give reporting so accounting can be done from within the website?"

The answer: "Yes! With Commerce Reporting module and Views."

Then came the followup question:

"Great! So we will be able to add partial refunds, full refunds and discounts to existing orders within the site, have our payment gateway (PayPal) receive the discount/refund requests and have all of this show up in our reporting exports?"

The answer to that: "UMMMMMMM........"

Simple example: Customer purchases two items. Item #2 was a mistake. Customer requests a refund via good old fashioned email. We are presented with a question: Does the refund get issued from within Drupal Commerce or within the payment gateway?

What are the solutions for dealing with this?

Does the company still have to rely on the payment gateway (and its ever-changing, unstable export features) for reporting? If so, how does Drupal account for any changes made to an order (i.e. refunds, manual discounts)?

If not, how do I set up Drupal Commerce to get the reporting accurate to include refunds and any line item price corrections?

  • According to drupal.stackexchange.com/questions/25610/…, drupal.org/project/commerce_rma should help – zerolab Feb 21 '17 at 14:30
  • Ya, saw that. I definitely offers a complex invoicing option including refunding, But adds no support for actually processing the money side of things. – Anon Ymous Feb 22 '17 at 3:39
  • He send me an email directly as a real human being communicating. Not an automated process. And question updated to reflect. However, I did not address the human rights portion of your question. Not the time or place for that :) – Anon Ymous Feb 23 '17 at 21:51
  • The previous comment was not referring to human rights, but your use of he as pronoun for referring to the person requesting a refund. It doesn't matter if he asked a refund, or she asked a refund; at least, it doesn't matter for the question being answered. – kiamlaluno Feb 23 '17 at 22:14
  • It sounds like a 'fairly basic function' but trust me, it is not. RMAs can be difficult to do as the process is different for different vendor payment gateways or payment services. – Kevin Feb 27 '17 at 16:43
0

Step 1 - Enable Commerce RMA

First of all, you need to get something in place to enable the tracking/registration of such refund requests within the Drupal Commerce ecosystem. For that, the Commerce Return Merchandise Authorization module appears to be the best alternative available today. Some more details about this module (from its project page):

This module aims to extend Drupal Commerce with the Return Merchandise Authorization functionality. It's built on top of the nice Entity API library and using its own Entity Type (CommerceReturn).

Feature list:

  • Exposes a return of goods workflow on customer side.
  • Ability to separate products that can and cannot be returned
  • Ability to specify a return period, after which the ability to create an RMA is not available.
  • Provide an Admin UI to manage customer returns. Admin can remove or add product and change the prices of returned product.
  • Ability to customize the customer reasons on both product and product type levels.

Step 2 - Create custom Rules reacting to Rules Events about a CommerceReturn

By using the Commerce Return Merchandise Authorization module, you'll get the CommerceReturn entity types available. And because of those entity types, it opens up all sorts of custom business logic you may want to implement by using the Rules module. That will allow you to build custom rules that react on the typical entity-related Rules Events, such as:

  • After deleting a CommerceReturn.
  • After saving a new CommerceReturn.
  • After updating an existing CommerceReturn.
  • Before saving a CommerceReturn.

Step 3 - Create custom Views about CommerceReturn entities

As per those CommerceReturn entities, you also get out-of-the-box reporting (and even charting ...) capabilites by simply using the Views module. So for anything that is not already covered by Commerce Reporting, just create the required custom Views.

Step 4 - Create work-arounds for payment gateway limitations

I'm not aware of any solutions to also automagically take care of the payment gateway processing for such refunds. Especially because I think that there is no way to refund part of a transaction.

However, if you have the Rules module available (see above), you might create custom rules with Rules Actions that (eg) transform such CommerceReturn entities in (e.g.) User Points (piece of cake), so that they can be used to get discounts on future transactions.

Summary

The above is not a perfect/complete solution, but at least an improvement as compared to the "requests of a refund via good old fashioned email" (as in your question). Actually it would at least keep track of such outstanding refunds to be processed.

PS: I'm assuming this is about D7.

  • Thanks for the general outline. I didn't see anywhere that the RMA attaches itself to the original ticket. How is the accountant suppose to keep track of returns and refunds when returns are their own entity type and not a line item on the original transaction. Doesn't really seem like a solution for a production site. Thoughts? – Anon Ymous Feb 28 '17 at 22:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.