Flexible Return Authorization (RMA) for ZC v1.5.x [Support Thread]

[rbarbour]

Sorry, I missed your initial discussion, I would have liked to have participated and contributed.

I think I did say something in my initial post(s) about how awesome this is compared to the original mod. Sorry if it seems like otherwise.

Someone must have changed the email along the way then, I might even be using the original mod or it's from several years ago anyway. My old version has newlines. Anyway, like I said, it's a small point but needs to be fixed to format properly, currently the email is difficult to read.

To start with, in the basic way of doing the return policy window, I am doing just as you suggested with setting the time limit based on the request date and comparing that to the completed (or admin defined) status. In my case I am doing it from the completed status since that's when the order is shipped in our system. I have it working now in the basic framework with hardcoded values, I am adding the configuration switches and defines now and considering a few alternative options while cleaning it all up and getting it ready to test properly. I should have it on my live site over the weekend if I can set aside the time. Then I will work on refining it once we start using it and get experience with it, and adding more options should the need arise.

I was thinking of extending this more than just different order status updates, more along the lines of a separate table specifically for RMA info. I think it will be a lot cleaner and better organized than a bunch of order status updates and can be a lot more detailed with specific, segmented data. Currently we use a spreadsheet to keep track of returns and exchanges and I would much rather have a dedicated admin interface page that displays all of the relevant info on one page instead of still needing to look at individual orders to read the comments from the status updates. I think this can be pretty sophisticated and quick and easy to use, which again for me is super important. I am planning on using ajax to display individual line item details and allow multiple input on the main page without refreshing. Another little timesaver that starts adding up to shave minutes off busy employees' days, plus the info is all easily accessible and editable when talking on the phone with the customer.

My idea of the customer-facing info would have a separate page in the My Account section for RMAs as well as a page available on the main site for COWOA users. It would have only info related to the return, if using just order status updates with comments it can be kind of cluttered looking when the original order stuff is included. And again, I think it would look very polished and professional for the customer.

If this is all too much for you guys, or are not interested in taking it in this direction, I can post it as a new module because by that point it will be substantially changed. I am open to any and all suggestions and will post code for review. I think that this can be an extremely valuable and thorough tool that keeps everything well organized and streamlined. Thoughts?

I think you should do it up and submit it

[dw08gm]

Sorry, I missed your initial discussion, I would have liked to have participated and contributed.

I think I did say something in my initial post(s) about how awesome this is compared to the original mod. Sorry if it seems like otherwise.

Someone must have changed the email along the way then, I might even be using the original mod or it's from several years ago anyway. My old version has newlines. Anyway, like I said, it's a small point but needs to be fixed to format properly, currently the email is difficult to read.

To start with, in the basic way of doing the return policy window, I am doing just as you suggested with setting the time limit based on the request date and comparing that to the completed (or admin defined) status. In my case I am doing it from the completed status since that's when the order is shipped in our system. I have it working now in the basic framework with hardcoded values, I am adding the configuration switches and defines now and considering a few alternative options while cleaning it all up and getting it ready to test properly. I should have it on my live site over the weekend if I can set aside the time. Then I will work on refining it once we start using it and get experience with it, and adding more options should the need arise.

I was thinking of extending this more than just different order status updates, more along the lines of a separate table specifically for RMA info. I think it will be a lot cleaner and better organized than a bunch of order status updates and can be a lot more detailed with specific, segmented data. Currently we use a spreadsheet to keep track of returns and exchanges and I would much rather have a dedicated admin interface page that displays all of the relevant info on one page instead of still needing to look at individual orders to read the comments from the status updates. I think this can be pretty sophisticated and quick and easy to use, which again for me is super important. I am planning on using ajax to display individual line item details and allow multiple input on the main page without refreshing. Another little timesaver that starts adding up to shave minutes off busy employees' days, plus the info is all easily accessible and editable when talking on the phone with the customer.

My idea of the customer-facing info would have a separate page in the My Account section for RMAs as well as a page available on the main site for COWOA users. It would have only info related to the return, if using just order status updates with comments it can be kind of cluttered looking when the original order stuff is included. And again, I think it would look very polished and professional for the customer.

If this is all too much for you guys, or are not interested in taking it in this direction, I can post it as a new module because by that point it will be substantially changed. I am open to any and all suggestions and will post code for review. I think that this can be an extremely valuable and thorough tool that keeps everything well organized and streamlined. Thoughts?

lankeeyankee, I am so looking forward to this.

rbarbour, please do not despair, I really do appreciate all of your contributions.

Just as a side note, this mode offers those not so proficient in coding (like me) greater insight into how customer-side forms can and possibly should work. So far, I have only been able to glean insight into how forms interact with the db from one other form - create account, which has its own challenges - as most of the other forms only process to send an email.

Thanks all.

[DivaVocals]

I searched the 1.1 version from the downloads and do not see ORDER_COMMENTS_RMA_OPTION in the init install script or anywhere else except the line in the tpl file referencing it:

if (ORDER_COMMENTS_RMA_OPTION == 'true') {
$db->Execute("insert into " . TABLE_ORDERS_STATUS_HISTORY . " (comments, orders_status_id, orders_id, date_added) values ('" . $reason ."', '" . $autoRMA ."', '" . (int)$orderID ."', now() )"); 

ORDER_COMMENTS_RMA_OPTION is a true/false config setting? I searched the entire 1.1 module directory with astrogrep just to make sure I wasn't missing it somewhere and it only returned the above line of code. The status updating is there in the config and it is being updated in the db. Perhaps the init file didn't get updated in 1.1? Because it's also showing a config version number of 1.0 on line 100.

The one bug that comes to mind, and it's just a small point, is the use of html break tags in the text section of the admin email in the header file. That breaks the layout of the text email and needs to be changed to a newline instead. We only use text admin emails so that came to light right away in testing. The other couple are small, too, mostly format/layout issues, but I am not at my computer that has my notes on it right now. I remember that I was thinking of changing to a config option to add a phone number so the language file doesn't need to be edited to help avoid confusion for newer users who will be wondering where 1.111.111.1111 can be changed and haven't yet discovered the joys of the developers toolkit. Or at least put something in the readme about where to change it as well as the body of the customer email. I always err towards making things as well-explained as possible with new users in mind to keep their frustration levels down and minimize the amount of time spent getting the module up and running on a live site.

I will report back the other little things I found to help tighten it up once I get back to my other laptop. It's nothing major, overall this works really well and is a vast improvement over the original version and has already come in pretty handy in the couple days it's been running live. Much more professional customer-facing-wise and more streamlined admin-wise.

Once I get the db table set up to store the RMA details it will allow tracking of the RMA process and the ability to set an RMA as closed once the process is complete with an admin page to see all RMAs and their progress/status to help admins keep track of what's going on, post comments and details, and enter refund/exchange transaction records, which I think will be a very useful feature. This is the table the daily cron will pull from to check the expiration date of an RMA and take action if needed. I will need help testing that part out on 1.5.x since there will be an admin interface. I will also want some feedback about features that should be included, like whether to have the ability to set comments/entries as public so the customer can track the RMA from the store side. I think this would be a good idea but would like input from other users.

Sounds like the improved module will be even more improved.. Like my co-collaborator rbarbour, I too will be willing to help with the v1.5 testing as well... (you still have my email address correct??) I like the idea you are floating of heading in the direction that Clydes Testimonials Manager went in where returns will have their own DB. This makes it easy to apply a workflow around them as you are clearly walking down the road of doing... I agree with rbabour though that the phone number could easily use the existing phone number from the store admin configuration.

The order comments being left out of the install script was totally my bad, and I didn't realize it was missing.. I'm sure you can see how the install file is configured and easily add it back in though..

Looking forward to the next update..

[rbarbour]

rbarbour, please do not despair, I really do appreciate all of your contributions.

Are you serious!

You know, I held back from really saying what I've been wanting to say. I have been "OFFERING" help on these forums from the time I became a member, maybe not actual "plugins" but I have offered up code and even gained access to well over a hundred community member websites to personally fix their issues without question, payment or donation.

PLEASE DO NOT DESPAIR.

I did not realize I was in a competition and that I had felt beaten out or had loss of hope, I have been watching the same people visit plugin thread after plugin thread pushing their "PERSONAL business needs" on contributors, offering ONLY what they "THINK" needs to be incorporated, MAKING SLY, IGNORANT and BELITTLING remarks towards the CONTRIBUTORS and nit-picking their CONTRIBUTIONS.

As every business has it's own personal needs, doesn't mean that code should be incorporated. If that was the case, all these plugins would already exist in the initial download of Zen Cart.

With that said,

As fellow CONTRIBUTORS you did not even wait till this was released, downloaded, used, played with or out of it's "testing" stage before you felt it necessary to rip it apart and force your "PERSONAL business needs" into the code. BRAVO

What baffles me is that you consider me to be in competition with someone else especially after offering help to incorporate these improved functions because I felt they would serve the vast majority.

GET THE OVER YOURSELF.

I mean no disrespect to those viewing this thread, downloading this plugin, offering suggestions or anybody that doesn't agree with my typing tone or disagrees with what I posted.

And if the ADMINS feel it necessary to delete my post, ban me from the forums - by all means, go ahead.

[dw08gm]

rbarbour

Apologies. You have every right to rally against my bad. I did not mean to bait you, but rather to humour you into seeing what others could offer. I have been waiting patiently (since I do not possess the skills) for this mod to be upgraded from 139 to 150+ and for the inclusion of some code to manage the returns process. Despite my disagreement over the cosmetic change for change sake upgrade, that would have rendered my 139 version of the returns form very difficult for my customers to follow, I still wait patiently.

[DivaVocals]

rbarbour

Apologies. You have every right to rally against my bad. I did not mean to bait you, but rather to humour you into seeing what others could offer. I have been waiting patiently (since I do not possess the skills) for this mod to be upgraded from 139 to 150+ and for the inclusion of some code to manage the returns process. Despite my disagreement over the cosmetic change for change sake upgrade, that would have rendered my 139 version of the returns form very difficult for my customers to follow, I still wait patiently.

Writing off Clydes addition of a modern improved UX techniques to the RMA error validation as merely "change for change sake" is truly your own personal opinion, and based on your past posts this is more a reflection of your own personal preferences/tastes. You have more than made it clear that you would prefer to use the older message stack error message technique, and that's fine but IMHO the way you've chosen to advocate for the return of this feature is based on your own personal preferences because I've not seen any other feedback from the community objecting to the introduction of inline error messages. Furthermore, the way you've expressed your opinion was done in a manner that makes it appear as if Clyde was doing something out of the ordinary or incorrect by implementing inline error messages. rbarbour and I defended the feature because we both KNOW that it really wasn't simply "change for change sake" as you have put it..

The addition of inline validation messages in fact implements methods in practice in MANY major (modern) websites and web based applications.. What could (and probably should) be included in not just this form, but perhaps in ALL Zen Cart forms is the addition of "real-time" inline validation (but that's a whole 'nother discussion). This is not change for change sake at all but a reflection of improved UX in RMA. If you Google "best practices in form validation UX" you will find lots of articles on the topic.. all with the same recurring theme. Inline validation improves the user experience.

Poor communication leads to poor business results and there is plenty of proof for that. Research conducted by Luke Wroblewski clearly shows that using properly designed inline form validation might make a tremendous difference:
“When compared to our control version, the inline validation form with the best performance showed compelling improvements across all the data we measured. Specifically, we saw:

• a 22% increase in success rates,
• a 22% decrease in errors made,
• a 31% increase in satisfaction rating,
• a 42% decrease in completion times, and
• a 47% decrease in the number of eye fixations.

This shouldn’t be ignored. Designing form validation in the right way might have a huge impact on your business!

Source: http://designmodo.com/ux-form-validation/#ixzz2ZhlZ4GTO

What did we learn about inline validation?

Our participants were faster, more successful, less error-prone, and more satisfied when they used the forms with inline validation. Eye-tracking also showed that they “fixated” on the forms with inline validation less frequently and for less time, which shows that they found these forms easier to process visually than the forms without inline validation. This was likely because they didn’t have to reread the entire form after submitting it to resolve any errors—instead, they resolved errors as they went along.

Source: http://alistapart.com/article/inline...n-in-web-forms

While you can style your form a thousand different ways, there are generally three basic steps to helping your user fix the validation problem:

1. Inform the user that there is a mistake somewhere on the form.
2. Highlight the field that’s incorrect.
3. Show them an example of what you are expecting. (ie: [email protected])

Color is one of the best tools to use when designing validation. Because it works on an instinctual level, adding red to error messages, or green to success messages is incredibly powerful.
Proximity is another important tool – keep specific notifications near to the problem fields and keep messages about the entire form away from any individual fields. If you can create custom “skin” solutions that make these strategies even more obvious (like making the notification look like it’s physically attached to a specific field), you’ll do even better.

Source: http://webdesign.tutsplus.com/articl...the-right-way/

Now though Clyde isn't here to confirm his reasons, I'm quite sure that Clyde added the inline error validation to RMA for similar reasons.. This is far from "change for change sake"

Now, that all said, I don't know if you remember the discussion on the old RMA thread on this topic or have even downloaded and tested the Flexible RMA module, but BOTH the older message stack as well as the modern UX technique of providing inline error messages is supported.. In fact half the reason for calling this module FLEXIBLE RMA is due to the fact that it offers lots of FLEXIBLE admin options for shopowners.

[dw08gm]

Now, that all said, I don't know if you remember the discussion on the old RMA thread on this topic or have even downloaded and tested the Flexible RMA module, but BOTH the older message stack as well as the modern UX technique of providing inline error messages is supported.. In fact half the reason for calling this module FLEXIBLE RMA is due to the fact that it offers lots of FLEXIBLE admin options for shopowners.

Yes I am aware and appreciative of the dual arrangement in the most recent upgrade. Hopefully the improvements will also cater to smaller screen sizes.

Now FWIW I hear zc 1.60 is to include jquery of a sort, which will probably entail replacing spiffycal with a jquery datepicker.

[DivaVocals]

Hopefully the improvements will also cater to smaller screen sizes.

You are free to adjust the stylesheet to your hearts content to achieve whatever layout arrangements you need..

[Luke007]

Thanks for sharing this great mod.

Having said that, I am having... one issue at this time.

When you go to submit a ra request, fill out all the details.. hit submit... the data is not recorded anywhere? Maybe I have missed a step when installing it.

The status gets updated - ie, to RMA-Pending
but no comments nor the ra number generated is not recorded

Everything else seems to working though.

Using latest zencart, new install (only having the front end/theme changed).

any assistance would be greatly appreciated

Cheers
Luke

[rbarbour]

Thanks for sharing this great mod.

Having said that, I am having... one issue at this time.

When you go to submit a ra request, fill out all the details.. hit submit... the data is not recorded anywhere? Maybe I have missed a step when installing it.

The current version sends the data to customer and shop owner via email with the exception of the order_status and reason text for return.

The status gets updated - ie, to RMA-Pending
but no comments nor the ra number generated is not recorded

The current version is missing the configuration to return the reason text as comments

Running the following SQL patch will add that configuration:

SET @configuration_group_id=0;
SELECT (@configuration_group_id:=configuration_group_id) FROM configuration_group WHERE configuration_group_title= 'Return Authorization' LIMIT 1;
INSERT INTO configuration (configuration_id, configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, date_added, use_function, set_function) VALUES 
(NULL, '<strong>Admin</strong> Update Order Comments option', 'ORDER_COMMENTS_RMA_OPTION', 'true', 'Update <strong>Admin</strong> Order Comments upon RMA Success',@configuration_group_id, 30, now(), NULL, 'zen_cfg_select_option(array(''true'', ''false''), '), 

Everything else seems to working though.

Using latest zencart, new install (only having the front end/theme changed).

any assistance would be greatly appreciated

Cheers
Luke

Other contributors have shown interest in providing a solution that stores the information from the form in its own database and can be retrieved via the admin for recording data sake. I have yet to see or been offered to test.

I am away on vacation but if it hasn't been submitted before Monday July 29th I will upload and submit v1.2 which is complete.

v1.2 features:

**Adds a new row to the database to store only the RMA#
**Adds a new column on the order page "next to comments" for the RMA#
**Adds a new configuration to pull stores phone number from admin for the returns success page
**Adds a new configuration to set order_complete status just like the current configuration to update order status upon success
**Adds a new configuration to set returns grace period
**Adds a function to disable form if order_complete status extends beyond the returns grace period set
**Adds a order look-up page similar to the one offered in the plugin FEC for COWOA customers so order information can be gathered before allowing form submission
**Adds a Popup window on returns success page for customer to print returns shipping label
**Adds an altered customer email to reflect the new process
**Adds an altered admin email to better display form details

I am 2500 miles away from my sandbox but I will do my best to get the files to @DivaVocals for testing, packaging and documenting.