Sensei
- Join Date:
- Jan 2004
- Posts:
- 63,513
- Plugin Contributions:
- 176
Odd problem with orders and authorize.net
rbobzin:
The authorizenet table shows both the void and refund transactions, but in each case, the customer_id field is -0-. The Void transaction showed the correct order number (although it was the order # plus digits from the "-xxxxxx" string), while the Refund transaction showed order_id as -0-. Both Void and Refund transactions did, however, show up correctly in the orders_status_history table.You don't need to worry about the authorizenet table.
rbobzin:Does either the Void or Refund process do anything to the order itself, or is it just an easy way to send adjustments to Auth? I'm not complaining, mind you, as this alone is a huge timesaver, just asking.The void and refund options only send the request to authorize.net, and add a comment in the order comment history stating what's happened. The order status is updated as well.
rbobzin:
- If the order itself remains untouched, I guess it's easy enough to delete a Voided order, but how do we edit a "partial refund" order?One would not normally "delete" any orders, since accountants don't like to see gaps in order numbers.
A partial refund is just that ... a partial refund of the funds collected. If you want to do more than that, you could use the functionality of addon modules such as super-orders or edit orders or an RMA module, etc.
There's nothing wrong with keeping Super Orders installed. But if you want the refund capability for Authorize.net orders (or PayPal or Linkpoint either) you'll need to just be sure to use the original /admin/orders.php page instead of the super orders page for doing that.
rbobzin:
- And finally, is there a way to turn off the extra -xxxxxx string piece?
If you want the risk of duplicate orders, no.
Or, if you want to use the other addon for generating order numbers, that's an option you'd have to re-integrate into the module.