Odd problem with orders and authorize.net

[DrByte]

I don't think Super Orders integrated the refund/void capabilities, so you'd have to use the regular Order page that normally comes with Zen Cart if you wanted to use those extra features.

[rbobzin]

Yeah, I was afraid you were going to say that!

Let me, if I may continue to bug you, ask a different question. I replaced the authorizenet_aim.php file in my local copy of the live site with the standard file from the 1.3.8a install files. I uninstalled AIM, then re-installed it again, changed over to test mode, then went to the store and input a new order.

Admin said the new order # was 3008 (which is correct), but when I looked at the authorizenet table via phpMyAdmin, it had the order_id as 300876! The x-invoice-number in that record's "sent" field is TEST-3008-d7NG6j. Since the order_id field is INT(11), it looks like it picked up the integer chars from the "-xxxxxx" and added that to the order number. Since all the Zen Cart orders tables show the id as 3008, I don't understand why they match, i.e. why Admin shows the order as paid?

This issue makes uninstalling Super Orders and using Zen Cart's Orders to do refunds questionable.

Thanks!

[rbobzin]

Let me add a little to the above. I just installed a fresh version of 1.3.8a on my laptop - clean, no mods - then installed AIM with valid ID and Key, put it in test mode, then went to store and input a new order. I got the following results:

1. Zen Cart says order # is 1.
2. authorizenet table says "id" is 1, but order_id is "166". And, yup, the "-xxxxxx" string had 2 numbers in it - 6 and 6!

So, added another order:

1. Zen Cart says order # is 2.
2. authorizenet table says "id" is 2, and order_id is "2". And the "-xxxxxx" string had NO numbers in it.

If Zen Cart matches authorizenet table to orders table, does it use "id" or "order_id" to compare to the orders table's "orders_id"? If it uses "id", then it might be that Admin's Store Manager tool to reset the current order id doesn't carry over to the authorizenet table.

Seems like the deeper I dig into this, the more confused I get!

One last thing - I looked all over Admin to see where to issue a refund, but couldn't find anything.

[DrByte]

Okay, the authorizenet table is dropping the letters. Correct. We may or may not fix that. That table is never used by the code anywhere at the present time. It is for diagnostic purposes only.

To do a refund requires the Transaction ID, which is stored in the order comments next to the Auth Code.

[DrByte]

One last thing - I looked all over Admin to see where to issue a refund, but couldn't find anything.

Like I said, if you use the original Orders tool instead of Super Orders, you'll have access to the additional functionality.

You've likely removed the menu option for the original order-mgmt screen, so you'd have to access it manually by going to /admin/orders.php in your browser, after being logged in to your admin area.

[DrByte]

EEKS ... and you'll have to make one adjustment to the code:

In /includes/modules/payment/authorizenet_aim.php
find this line:

  function RENAME_admin_notification($zf_order_id) {

and change it to:

  function admin_notification($zf_order_id) {

[rbobzin]

The EEKS did it! As soon as I made the change to the authorizenet_aim.php file on my clean test site, the Refund and Void Transaction sections appeared under the order! And, WOW, does this make refunds easier or what!!!

I'll be testing this today and let you know if I run into any problems. However, knowing the quality of your and the Zen Cart team's work, I expect to come back with nothing but praise.

Thanks, Doc. I'll be buying you and your team several cups of coffee now and only wish I could do more.

[DrByte]

Please do let us know how well it works.

And thanks for the support.

[rbobzin]

OK, in the store's test site (as opposed to the clean install site) I removed all Super Orders tables, files, and file mods - not an easy task, although WinMerge is a GREAT helper! Then I upgraded Admin Profiles, which I happened to notice while I was cleaning our the SO stuff - again WinMerge was essential.

I added 2 new orders in the store, then went to Admin -> Orders, found my first new order, and voila - there were the Refund and Void Transaction areas under the order details. WooHoo! I submitted a partial refund, but got a friendly little error message saying "the transaction did not meet specified criteria" - I think this message may have come from Authorize.net. Anyway, I figured it might have something to do with the transaction not having "settled" yet, so I did a Void Transaction instead. Bingo, Auth came back to say the void was being processed!

I waited until tonight for the transactions to settle, and issued a partial refund for the other order. Bingo - accepted by Auth, and the "refund" comment I had input appeared when I looked at the order again.

But (isn't there always a "but"!):

1. The "voided transaction" order is still listed as an order - I assumed it would be deleted during the void process, but guess not. Should it have been deleted, or is that a separate step I would need to do in Admin?

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

I may be making a mountain out of a molehill with the authorizenet table issues, so I'll just ask these questions:

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

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

3. And finally, is there a way to turn off the extra -xxxxxx string piece?

Thanks!

[rbobzin]

By the way, in testing all Admin functions, I found that the Search by Product Name in Admin -> Orders didn't work - always gave me an error. When I looked on the forum for that error, I found it under a sticky thread in Announcements called something like "Known 1.3.8 bugs". When I made the recommended fix, all worked beautifully!

So anyone reading this, even though you may have installed 1.3.8a, you might still want to look at the "known 1.3.8 bugs" thread to see if it includes any issues you're also having. In other words, don't assume 1.3.8a fixed all the 1.3.8 bugs!