Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Justin

Archived
  • Posts

    101
  • Joined

  • Last visited

Profile Information

Justin's Achievements

  1. Hi Anita. I noticed the same problem myself a few days ago. I will try to fix this as soon as I can, although I can't make any promises. It may take several days or even weeks, but I'll post a note here when it's ready.
  2. No, sorry -- I know nothing about that contribution.
  3. Is anyone out there interested in testing the new code I have written to integrate attribute-level inventory tracking with the RMA Returns contribution? I have not received any responses from people regarding my previous request for testers, so I thought I would post another note and see if anyone is willing to lend a hand. The sooner I get some testing feedback, the sooner I can wrap up the code and release the next version of RMA Returns. If you can help with testing, please PM me as soon as you can. It would be nice to release this code to the general public. Thanks! Justin
  4. I'm happy to report an initial bout of success in my efforts to make QTPro and RMA Returns interoperate. I've added an SKU field to QTPro's products_stock table. This SKU field ties the two contributions together. When an order is placed for a product with attributes, the new products_stock SKU is inserted in the order's products_model field instead of the value that would normally come from the products table. When an item with attributes is returned, the SKU is used to add the stock back to the products_stock table instead of the products table. For items without attributes, everything is handled the way it always was: returned items are added back to the products table. Get all that? ;) In any case, now I need testers. Please IM me if you are interested in managing your inventory for products with attributes and are willing to help out with testing. Justin
  5. Rather than try to re-invent the wheel, I poked around the contributions list and downloaded an attribute-aware inventory management module called Quantity Tracking Pro. After installing it yesterday and doing some initial testing, it seems to do a solid job of storing and subtracting inventory counts even when multiple attributes are used per product. The only issue is that the code doesn't use many functions, so it's not easy to integrate it with RMA Returns. For example, when you process a return, the item is supposed to be added back to inventory. At the moment, RMA Returns is not attribute-aware (as we have discussed), nor are there any functions available to easily ensure that products with attributes get added back to the correct place in the database. In short, it should be possible to modify QTPro and RMA Returns so that they are interoperable. It will be no small task, however, and will take a significant amount of effort. I'll let you once I have something available for testing. Justin
  6. As far as I know, no version of this contribution has any code relating to product attributes. While I can guess at what you're looking for, more detail would be helpful. You mention phrases like "dealing," "recognizing," and "implementing" product attributes without actually describing what you want the RMA Returns System to do with them. I assume you would like attributes for returned products to be recorded and displayed in the catalog/admin modules. If this assumption is correct, this would probably be a non-trivial task, albeit not an impossible one. However, my company's current position regarding product attributes is that they are not very useful for our business until OSC can manage inventory counts by attribute. That leaves us with two options: 1. Separate every color/size/etc variation of a product into its own product (i.e., no attributes) 2. Hack the core OSC code to record inventory counts by attribute If we decide to go the first route, there won't be much incentive for us to get the RMA Returns System to record attributes (since we won't be using attributes any longer). If we go the second route, we'd obviously have to complete that step before we even consider modifying RMA Returns System to record attributes. As mentioned earlier in this thread, I don't know anything about PHP -- I'm just a tinkerer. So as far as suggestions are concerned, unfortunately I don't have too many. Trial and error are the only techniques I've mastered so far... ;) Justin
  7. Version 2.4.1 has been posted. Changes from 2.4: --- Enhancements --- * To avoid multiple return request submissions, JavaScript enhancement was added to prevent customers from clicking the "Submit" button more than once. (catalog/return_product.php) * Returns status added to heading title of Track Return page (catalog/returns_track.php, catalog/includes/languages/xxxxxx/returns_track.php) --- Fixes --- * Fixed missing error message if RMA was entered incorrectly (catalog/includes/filenames.php, catalog/includes/languages/xxxxxx/return_track.php was renamed to returns_track.php) * Better rendering of account history page (catalog/account_history_info.php) * Better rendering of RMA request page (catalog/return_product.php) * Better rendering of return tracking page (catalog/includes/modules/returns_track.php) * Fixed incorrect variable name in Addressbook Enhancer extra (catalog/return_product.php) * Improved installation documentation If you haven't changed any of the files specific to this contribution, you can just copy over the new RMA files, make the needed edits for two core OSC files (catalog/account_history_info.php and catalog/includes/filenames.php), and delete catalog/includes/languages/[english|german]/return_track.php. As before, the best way to upgrade is to use a file comparison tool on the files listed above. If you're on Mac OS X and need help with file comparison tools such as BBEdit or FileMerge, I'd be happy to help. I'm not familiar with Beyond Compare or its ilk on Windows, so unfortunately I can't help there. ;) Enjoy, Justin
  8. Well, now I'm the one who's confused. I do indeed think having the status in the page heading title is sufficient, so that's what's been done for 2.4.1. Since we seem to be crossing wires here, you can download 2.4.1 and see if it meets your needs. ;)
  9. As I mentioned before, this has already been done. I'll post 2.4.1 as soon as I can. I can't promise anything, but hopefully I'll get the time to package it within a day or two.
  10. Yes, I'm familiar with how the order status history works. But this is a technical implementation issue -- not a business process issue. As I mentioned in a previous post, you can do the same thing with the current system by entering subsequent "updates" below the previous ones (with the caveat that the comment bar can't be used). For example: 10/1/04: Customer requested RMA because FedEx conveyor belt ate the package (and contents) 10/2/04: RMA approved. Instructions sent. 10/9/04: Item returned. Store credit issued. I can understand why some people would prefer automatic time stamping. As I mentioned above that would require a lot of work for -- what appears to me, at least -- very little reward. There is a header text string at the top of nearly every page in OSC. By default, this text is grey. In the OSC framework, this text string is known as HEADING_TITLE. I have modified this heading to include the current returns status. I tried getting it to appear further below, but for some reason that wasn't working. Given the time/reward trade-off alluded to above, I decided including this info in the HEADING_TITLE was good enough. ;) Justin
  11. The easiest solution for this is to include the current status in the comment. That said, I've spent the last hour looking at how to incorporate the return status itself on the Returns Tracking page. At the moment I've got it appearing in the header that appears at the top of the page, which I'll incorporate into 2.4.1 when I find the time to package everything together. This request was made earlier in the thread, and I've thought about it. There are several reasons why I don't like this idea: 1. It means creating additional tables to store the history for returns status updates. 2. It would require adding a lot of code -- on both the catalog/admin side of things. Personally, I prefer the way that status box only displays the most recent information. For those who want to keep the customers' original comments, you can always add your comments below theirs. Of course this means you can't use the comment bar (since it automatically overwrites everything), but that's about the best workaround I can think of. Sounds like a missing bracket or semi-colon. If you see an error that references a line that is not relevant (e.g., in this case the line has not changed from the old to the new), most likely the reason is a missing bracket, semi-colon, or closing PHP tag. I would check to make sure the copy/paste was done correctly. If that doesn't work, please just wait for 2.4.1. :) A bunch of borked code was fixed, but obviously nothing that inhibits functionality. The hard-coded English strings were replaced with multilingual-friendly variables, as well as a dozen other syntactical fixes. No, I don't think you're missing anything. I think that's the way the contribution was originally designed. Once the current status in included in the header, I would think that -- along with the current comments -- should provide enough detail as to the current status. But that's just me. Everyone has their own needs. :) The RMA number generation function is located in catalog/includes/functions/refund_functions.php Hope this helps! Justin
  12. That's certainly something I haven't yet tested myself. Hopefully I'll get a chance to give that a try one of these days. This has worked just fine for me, including both testing and on a live store. Do you receive the message when you send it manually to the same email address via the Mail Gift Voucher function in Admin? Have you checked the junk mail filter on that email account?
  13. Your database table definitions are not being recognized. Make sure you added the DB table definitions to both catalog/includes/database_tables.php and admin/includes/database_tables.php as instructed in the docs.
  14. You didn't miss anything during your installation. This is caused by a series of bugs with the original contribution. The included language file is wrong, the correct language file doesn't match the include call, and the code to display the error message was a complete disaster. It took me a long time to determine that the author had tried (unsuccessfully) to nest PHP statements. Once I unraveled that mess, everything works fine. 1. Rename catalog/includes/languages/english/return_track.php to returns_track.php 2. Find: require(DIR_WS_LANGUAGES . $language . '/' . FILENAME_RETURN); $breadcrumb->add(NAVBAR_TITLE, tep_href_link(FILENAME_RETURN, '', 'NONSSL')); Replace with: require(DIR_WS_LANGUAGES . $language . '/' . FILENAME_RETURNS_TRACK); $breadcrumb->add(NAVBAR_TITLE, tep_href_link(FILENAME_RETURNS_TRACK, '', 'NONSSL')); 3. Find: <!-- end new insert here --//--> <? } else { ?> <tr> <td><table border="0" width="100%" cellspacing="0" cellpadding="2"> <tr> <td width="100%" valign="top"> <table border="0" width="100%" cellspacing="0" cellpadding="0"> <? if (isset($error)=='yes') { $error_message = '<tr> <td colspan=3 class=main><? echo TEXT_TRACK_DETAILS_1; ?></td> </tr> <tr>'; new infoBox(array(array('text' => $error_message))); // } echo '<br><BR>'; } $returns = '<form action="' . $PHP_SELF . '?action=returns_show" method=post> <tr> <td colspan=3 class=main><center>If you have previously requested an RMA Number from us,<br>enter the number received in the box to review the status of your return.<br><? echo TEXT_TRACK_DETAILS_2; ?></td> </tr> <tr> <td width=100& colspan=3 class=main> </td> </tr> <tr> <td width="33%" height="30" align="right" class="main"><?php echo TEXT_YOUR_RMA_NUMBER; ?> </td> <td width="50%" height="30" align="left" class="main" colspan="2"><font color="CC0000"><input type="text" name="rma" value="" size="20"></font></td> </tr> <tr> <td width=100& colspan=3 class=main> </td> </tr> <tr> <td width=100% colspan=3 align=right><input type=submit name="submit" value=Track Return<? echo TEXT_FIND_RETURN; ?> </td> </tr> </form> Replace with: <!-- if RMA number doesn't exist, show error message //--> <?php } else { ?> <tr> <td><table border="0" width="100%" cellspacing="0" cellpadding="2"> <tr> <td width="100%" valign="top"> <table border="0" width="100%" cellspacing="0" cellpadding="0"> <?php if (isset($error)=='yes') { $error_message = '<tr> <td width="10"> </td> <td colspan="2" class="main">' . TEXT_TRACK_DETAILS_1 . '</td> </tr> <tr>'; new infoBox(array(array('text' => $error_message))); // } echo '<br /><br />'; } $returns = '<form action="' . $PHP_SELF . '?action=returns_show" method=post> <tr> <td colspan="2" class="main"><center>' . TEXT_TRACK_DETAILS_2 . '</center><br /></td> </tr> <tr> <td width="45%" height="30" align="right" class="main">' . TEXT_YOUR_RMA_NUMBER . ' </td> <td width="50%" height="30" align="left" class="main" colspan="2"><font color="CC0000"><input type="text" name="rma" value="" size="20"></font></td> </tr> <tr> <td width="100%" colspan="2" class="main"> </td> </tr> <tr> <td width="100%" colspan="2" align="right"><input type=submit name="submit" value="' . TEXT_FIND_RETURN . '"> </td> </tr> </form> It will also help to edit catalog/includes/languages/english/returns_track.php to taste, since the strings in there will actually be used instead of the hardcoded cruft. These changes will eventually be rolled into 2.4.1. Hope this helps! :rolleyes: Justin
  15. Very glad to hear that. I would have put money on 2.4 breaking on installations without CCGV, and I'm glad to hear I would have lost that bet. :D I haven't used the restocking fee section as of yet, since we don't charge one. But I'll toy with this over the weekend and see if I can't figure out what's going on. I should also note that as of version 2.4 the restocking fee checkbox should be unchecked by default, so you shouldn't have to keep unchecking it -- you only need to check it right before you're ready to complete the return. You are too kind. :D I'm very glad to hear that it's working well you! As noted above and in the ReadMe, people who are upgrading from 2.3 should look at the detailed version history provided at the end of the ReadMe. It sounds like you haven't copied over any of the files specific to the RMA Returns System (admin/returns.php, among many others). It seems the instructions do not explicitly state to copy over the RMA Returns-specific files, so I have added that to the instructions for the next release. Just to clarify, it's probably best to manually make the relevant DB changes via phpMyAdmin if you already have returns-related data you don't want to lose. If you just run the SQL script, it will drop tables and the data inside before re-creating them. The only significant changes made to the database between 2.3 and 2.4 are: * gv_tracking table removed * "Awaiting Return" added to returns_status ...and even those aren't critical. Version 2.4 should work just fine even without changing your 2.3 database structure. The changes I made to the SQL file were very minor. Hope this helps! Justin
×
×
  • Create New...