Saturday pickup surcharge

I didn't know about the Saturday *pickup* surcharge. Yes, I think it would be reasonable to add a checkbox to the admin menu to "Allow Saturday pickup", defaulting to no.

And you're right I still need to do something about cutoff times. I know what I want to do, just haven't had the motivation to add it in yet.

TR,

Could you post your ideas on how you would like to see this implemented. I have a client that is interested in this feature and I would like to implement it in a way that it can be contributed back to the community.

Cheers,

Antoine

subscribing

@AntoineSolutions:

I want to add an admin menu option to specify the store's business hours (days/times it's staffed and can actually process orders), turn-around time (how long it takes to process an order) and pickup/dropoff time (when the FedEx truck arrives, or when the company truck departs to head to the FedEx dropoff center). These should all be in the same fieldset.

Then, in the same block of code cited by the original poster, I want to do the date math to calculate exactly when (date & time) an order will ship: if order date + turn-around time is earlier than cutoff time then it ships today (iff today is a business day and checking for Sat pickup allowed if today is Sat). If order date + turn-around time is later than cutoff time it ships tomorrow, unless tomorrow is Saturday and you've disallowed Sat pickup in which case it ships Monday, etc. - have to keep in mind that turn-around time must take place during business hours.

The turn-around time provides the fudge factor you need to be able to fine-tune the process so that you always meet your promised ship date.

Once this is done and the shipping date/time is based on reality, the FedEx guaranteed delivery date can be extracted from the quote reply and presented to the customer on the checkout page if desired.

Subscribing. I'm very interested in the planned closed/cut-off features as well.

What's the status of this for D6? I need this and can quickly knock out the code to function as described by TR above but don't want to do duplicate work. Thanks.

I never got around to doing anything about this, that's why the issue is still open. If you could submit a patch that would be great!

Ok... started a new job right after I made that offer and only just today got time to write the code. Basically, I added a fieldset on the admin page that allows the user to set their internal cut-off time for Mon-Sat (or set the day to "Closed" for business) and allow Sat pickup and the surcharge. Instead of bothering with business hours and turnaround time, it seemed easier and cleaner to let the user figure out turnaround time do the math themselves. That way we only have to deal with 1 value in the logic.

The ship time logic looks to see that it's not Sunday, not Closed and that it's before the cut-off time. If it is Saturday, it also checks to see if the surcharge is allowed/enabled. If the conditions are not met for any of the above, the ship date is set to the following day. In the case of Saturday, Fedex is closed so telling them that the ship date is the next day (Sunday) will automatically quote for Monday.

I had started writing this code on Saturday but didn't finish until the evening and Fedex stopped giving me Saturday rates so, I haven't fully tested it.
I also didn't try to solve the D6 timezone issue.

The patches are attached since I haven't had time to figure out git yet.
Let me know what you think!

Errrr..... don't test the module patch in my last post. Late night, messed up some variable naming. Also need to check the conditionals of one of the if statements.
I'll bang it up later today.

Ok... I don't know what I was thinking yesterday. I can't just set the ship date to the following day if the current day's conditions aren't met. It's necessary to find the next available day that allows processing and use that. So, attached is an updated patch that checks the status for the current day and, if shipping can't happen that day (business closed, past cutoff, Saturday with no pickup allowed or a Sunday) then we loop though day by day until we find a day that is available for package processing and set the ship timestamp to that day at the user defined cut-off time.
I also simplified the the Saturday setting so that one just sets the business to closed if you don't want to quote with the Fedex Saturday pickup surcharge.
Lastly, I set the day of the week to adjust for the site's timezone setting. Using the date() function in the $now variable is still a cause for concern as it will likely cause errors in PHP 5.3:
Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier.
The solution (as suggested here: http://drupal.org/node/615438#comment-3033080) is to set your timezone in php.ini.

Please test before you use this in a production environment! I am going to test though-out the week to make sure it continues to behave as expected.

Please get rid of the tabs in your patch.

Uh, weird. Didn't realize my editor was doing that.

Thanks for working on this. I haven't tested out the functionality yet, I've just reviewed the patch for coding standards and obvious errors. Please see http://drupal.org/coding-standards and modify your patch accordingly. Some problems are:

Indentations should be two spaces, not four.

Spaces around = needed: $i=0;

else should start the line: } else {

Space needed before ( and after both ;
Also, would be better to use range() here I think: for($i = 1;$i < 96;$i++) {

Array key should be string or variable. Avoid using capitalization for internal keys like this: $times[Closed] = 'Closed';

You should also test the code to make sure it handles timezones correctly. If the timezone of the customer is different than the timezone of the web server, or if the timezone of the web server is different than the timezone of the store administrator, the cutoff times will be wrong.

Ok, here's an update per your suggestions. I think I hit all the coding standards issues. Also changed the _uc_fedex_cutoff_times() function to use range() so it is simpler. As for the timezone, when I originally added it, the only constant but configurable item that I could come up with is the Drupal timezone offset found at admin/settings/date-time (which is stored in the variables table as date_default_timezone). So, it doesn't reference the web server timezone which could be different. The assumption was that the Drupal install will be set to the same timezone as the shipper. You make a good point though so I have added a menu item to select between the Drupal time offset and the user's time offset. That way the user who does the shipping can be set to their own timezone different than the Drupal install. The default is to use the Drupal time.

It also occurred to me that setting every day to Closed would cause the module to loop infinitely looking for a valid ship day. To prevent that, I added form validation that requires at least one day has a cut-off time selected.

And once again late night coding after a full day at the regular job bites me in the derrière again. Ignore the new timezone settings in the last patch. We can't use the user's timezone. It would, perhaps, be better to add a list of timezone offsets dedicated to the uc_fedex module so one can set the timezone of the shipper if different than the Drupal install offset.

Ok, I think I might have it now. I'll keep testing through the week, but let me know if you still see anything that stands out. I should mention that this is for 6.x-2.x-dev.

• Added configurable timezone support in the module that can use Drupal's offset or it's own independent setting. I used the Drupal 6 _system_zonelist() function from system.module (http://api.drupal.org/api/drupal/modules--system--system.module/function...) to generate the list. This may not be the best approach so, I would like your opinion on that in particular. In Drupal 7, the function name changed to system_time_zones().
• Moved timezone setting above daily cut-off settings for better workflow.
• Made the time drop-down menus display both military and am/pm times for international users.
• Cleaned up the menu instructions text.
• Added jump to anchor link in form error for convenience.

I've also attached a screenshot of the settings menu.

My testing over the weekend revealed that timezones in my last patch weren't working as expected. This update corrects that.

This is looking good! Thanks for all your hard work. I don't have time right now to do my own testing on this right now, but I'll try to get to it sometime within the next week.

Just dropping in to say that I've had this code running on a live site now for a couple weeks with no issues.

Good work fred0! Your patches work as advertised. TR, will they be committed to the dev version soon?

Updated patches against the Jan 27, 2012 dev release.