Ubercart

I've having trouble tracking through the line item system to figure out why on the Preview page the discount/fee is showing as a line item but is not being used to calculate the order total. The same thing is happening on the admin Order Review page. Can anyone point me in the right direction? Thanks.

Checked it out on the Livetest... don't think I ran into any real problems, at least not that I could reproduce. It seemed to throw up some raw HTML the first time I tried it, but that may have been due to me not refreshing the cached JS.

I think I'd recommend handling the (-5) part or whatever it is before payment methods differently, though. Perhaps by using the XHTML/class to get something akin to the field description text saying "Choosing this payment method adds a 2% fee to your order." or something similar?

Yeah, I'm not real fond of how it is thrown in there either. Is your suggestion to have the discount/fee text come up along with the other payment specific text once an option is selected? That would look much cleaner, but I also thought it would be good to let the user know before selection that there were price adjustments associated with payment methods. It would look nicer to append the text to the end of the payment method instead of the beginning, but the images that are a part of the payment methods' descriptions will make that difficult.

Do you think maybe a plus or minus or asterisk or something next to the payment method and a line to identify that it indicates a discount or fee along with the descriptive text loaded on select could work?

Sorry, haven't tested the 1.2 as I was working on other stuff and just got to making this mock-up. Check out the screenshot and let me know what you think. This was accomplished by appending the following HTML to the radio:

Obviously, you wouldn't want to hardcode the style there, but you can add that property as a CSS rule for .form-radios .description. I think it would be better if that text isn't customizable simply for multi-lingual sites. I'm repenting over having so much customizable text in forms.

Also, to bring up my point again about the title on the table being "Subtotal adjustment" ... I'm curious if you had any thoughts on that. The best I could come up with for another title was "Fee/Discount" since it can be either. Also, can that be moved to be in between weight and default gateway? Makes it look better since the field will always have a uniform size but default gateway may not.

Hmm....there isn't much to 1.2 and there should be a 1.3 shortly, so there isn't much reason to try it out.

I like all of your suggestions and I think the .form-radios .description will work well. Thanks for the lil' mock-up. I've never considered multi-lingual sites, so I'll need to make an effort to keep that in the back of my mind when I'm doing things.

I uploaded those changes. I wasn't sure if placing that property in uc_cart.css was appropriate or if I should have created a uc_payment.css with just that one property.

Can you tell me if it's still adding a line item for payment methods that have no fee/discount? I haven't tested 1.3 yet, but noticed on Livetest it was throwing in an unecessary $0 line item on the review order screen.

Yeah, that is still a problem. I'll fix that up and upload.

Ok, that is up now. The old code was returning an empty amount and then would not display, but then I added in number_format code which returns 0.00 instead and would display. So the new checks for display will not show anything less than $0.01

cYu, not sure if you still have the ability to do this or not, but the patch failed in multiple places when I tried to apply it to the current working version. Is there any way you can re-roll it against bzr?

Sure. I'll take a look at what I did and just put it back together from scratch on the bzr head.

Ok Ryan, I re-applied my code and uploaded as v1.5. I don't think it should break anything although it does change some line item javascript stuff that you might want to review for correctness.

The patch applied fine and seems to work out as needed. I may make a few minor textual changes before a final commit, but this seems to be heading in the right direction. Just a minor aside for your future development, uses of the t() function cannot use concatenation and should be all on one line in the code. It can make for some crazy long lines, but it's how the extractor recognizes translatable strings.

The one thing I'd call out right now is that it doesn't work off the order total... it seems to be calculating percentage shifts from the product subtotal, disregarding shipping and taxes.

Also, to be honest, I'm struggling to remember or think of good applications for this functionality. It's just a lot of new code to drop in and have to support further if it never gets used, ya know? What are your thoughts about that, although I realize you can't be the most objective responder since you spent the time to get it done.

(I added a padding-left of 25px to the description text, too.)

A couple notes... b/c the style is so minimal, I'd recommend adding it inline. Then you don't have to screw with an extra load request or messing up other radio selects that might be on the page... never know.

Also, I'm curious to know what you think it would require for this code to be in a separate module instead of core? The stuff at checkout can work on hook_form_alter() no problem, and line items are already processed through hooks. It seems like I'd need to maybe modify the JS file a bit, but those would be improvements I imagine. Besides that there's the table in the payment method settings form, but the theme function for that part of the form can be switched in the form alter to the updated one.

Thoughts?

Calculating on the order total would not work easily. A 10% payment method fee of $1 on a $10 order total would result in an $11 order total and a $1.10 payment method fee...and so on. I guess there are ways to get around that happening, but at first glance of the line item system it seems like that sort of thing could get messy. A feature could be added where you could check off that the % applied to taxes, shipping, etc., but that gets into some additional clutter and config that might not serve a very useful purpose.

Thanks for the t() advice, I'll store that away for future use.

I wasn't sure about that css file and the Ubercarty way to do that, but I saw a similarly small uc_shipping.css file and decided to create the uc_payment one.

I think the impact on user interface and code is pretty minimal, but I can see why you might not feel that this is needed for core. As far as the frequency of use, it did seem to pop up more than a couple times on the forums, but maybe with only enough interest to justify a contrib module. That said, I don't exactly know how I'd flesh out all those parts. Definitely not as smoothly as just adding the needed code into uc_payment.

I can take a stab at that if you decide not to go with a patch to uc_payment, but probably not in the immediate future.

Nah, I wouldn't ask you to duplicate your work. I'll think about it, toss it around the office, and take care of getting it in unless you have some outstanding issues that need to be resolved. (Well, if I go the contrib route, I'd be sure to post it in your name, not mine. )

I remember a few of those posts, too, so I know it's not a totally undesirable feature... just a little on the fence.

I think it is a useful addition.

Anyone who is selling tickets to an event, for example TicketMaster.
The tickets to AC/DC is $25 each, then they add a processing fee (which is the basically the same as payment method fee).

Or if the new Amazon payments was ever implemented for Ubercart, Amazon charges different fees based on whether credit card or debit card, or amazon payment is used. This addition would allow you to pass the savings on to your customer for using a "less expensive" payment method.

Ok, I went ahead and made this into a module as a proof of concept and invite folks to test it out and use it. The original code was cYu's, so I'll leave it up to him to keep up with bug reports if he wants.

The code depends on Bazaar revision 804, so you'll need the latest dev code until I release beta 4 (probably this evening).

@cYu: my recommendation would be to update this page with instructions instead of a patch history, namely to set the fees/discounts on the payment methods table and then test them out in the checkout process. Also, feel free to grab this attachment and put it as the main download for the contrib.

Cool, thanks Ryan. I can take care of the bug reports for the module and update this page with some instructions when I get some time. I'll be taking a pretty close look at the module since there were a few things I didn't understand how to do very easily through hooks as opposed to directly in uc_payment.module, so maintaining this shouldn't be a problem.

When the first payment option has a discount it is calculated and shown on checkout->Payment method pane. When i change the payment method does not change. Like in shipping the discounts should recalculated. Please find the attached screen shots. May be the discount should not shown on checkout page even it is the first payment type.

bakyildiz, I'm unable to duplicate this problem. Can you give me info on your Ubercart version, browser, and platform?

If you are running with Firefox and Firebug? Can you see what is being returned from the AJAX calls when the payment method is changed?

The ereg_replace() functions causes errors.
If your currency format is similar to x.xxx,xx and you put in the adjustment 6.90, at the checkout-pane it is displayed as 690.

Michels, I don't follow your example. The ereg_replace attempts to preserve the separator which represents the decimal separator and removes any extraneous characters, like a thousands separator.

In US currency this would turn $1,250.05 to 1250.05, which is the desired behavior. I don't really understand x.xxx,xx currency formats I suppose because I didn't think 6.90 was a valid use of this format and I don't know why 690 isn't equal to 6.90 . Can you elaborate for me and I'll try to patch up the code? Thanks.

I use the module on a different server and it works fine. I think i have problem in my local system.

i had some problems with values like 9,50 which resulted in being changed to 9.00

so i modified the code on two places:

line 136:
$adjustment = uc_currency_format(str_replace(variable_get('uc_currency_dec', '.'),".",$adjustment));

line 185:
$ret['value'] = number_format(str_replace(variable_get('uc_currency_dec', '.'),".",$ret['value']), 2);

Johnny, thanks for the feedback. Before I update the module with your fixes, I think I need a better understanding of what this is fixing and how it is fixing it.

I think I'll follow the Ubercart crew in saying that internationalization is a big weakness of mine and something I've never had to account for before.

I think what I'll want to do is store the adjustment data in the database in XXXXX.XX format. In this case, I'm storing as a string and could store relative to the site's currency settings or store exactly as it is entered, but should avoid this to stay standard with how number fields are generally restricted to this format. I'll then be able to use uc_currency_format and number_format on this data without your fixes, and have the store settings dictate display.

Does that sound right?

Upon further review, I prefer Johnny's fix as opposed to what I was planning. My lack of time for implementation and testing is playing a part in that...

If someone who is informed about internationalization of currency best practices has some thoughts on the matter, I'd be interested in the preferred method for handling such things.

Hi,

sorry for the late reply but I forgot to track this topic.

I think in ubercart all money values are stored inside the database as a decimal(10,2).

i found this function on php.net:
http://nl2.php.net/manual/nl/function.number-format.php#80281

this should convert the most general versions to a php float

ps. how do i turn off smileys?

I modified this module to be able to enable/disable the discount/fee dependent on the subtotal of the order. A positive adjustment (fee) is only enabled when the subtotal is below the given threshold. A negative adjustment (discount) is only enabled when the subtotal is more than or equal to the given treshold.

The theshold can be given in a new field in the Payment settings page.

Could you please apply the attached patch?
Also attached is the tar file of the complete module.

Apply this patch to make the word 'fee' translatable

Slipped through the cracks... even better, to provide translators with a little more context, try this line:

Good catch guys. There similarly is an instance of 'discount' not being translated, so I will apply Ryan's fix there as well.

stacium, I'm up in the air on the need for the Threshold feature and also the implementation of it. For now I'm going to leave it up to people to apply your patch (which will no longer apply after the translation fix) or download your tar. I don't recall seeing any requests for this feature previously and I'd like to avoid adding another potentially confusing term to the payment methods screen, but if it turns out that this is needed by many people I will see about patching the module. Regardless, thanks for the feedback and helping to make the module better.

cYu, stacium's threshold feature is exactly what I have been looking for. I am charged a "small order fee" if I place an order under a certain $ amount. I need a way to pass this fee on to my customers. Your module with stacium's addition provides this functionality. I am applying the same $5 fee to all payment types if the order subtotal is under $50. Now if I could get the description text to not show when the subtotal is over the threshold.

wadehays, if all you are looking for is a "small order fee" regardless of payment type I believe there are workflow-ng ways to accomplish that. I know I've seen people describe free shipping if an order is over a certain amount. That same type of logic should be able to apply a $5 tax/fee if an order is under $50.

I have been down the path of workflow-ng, but the problem I have is that you can only set up a tax as a % of the total not a flat rate, and unless I am missing something if you set the fee up as a shipping type the customer would have to select the fee as there shipping type. I do have flat rate "FREE" shipping working on orders over $2000 and on specific products. The threshold feature does exactly what I need. I had to hack the code a bit to change the verbiage that is shown, but it is working great.

Hi,

I do not know if I understood well, but normally there is ajax well inside?
I tested the module, but the fee does not change directly in subtotal.
Even problem that bakyildiz I think. But here is on my webserver.

Strange because the ajax well usually functions.

Tom.

Tom, can you let me know what browser/version/operating system you are using? Have you noticed any other ajax problems or only this?

Hi cYu,

I tested on Windows Vista Business 32Bits on IE7, Opera last version, Firefox last version and Safari last version.
I never had any problem with Ajax, except with your module Attribute Ajax version 2.0 where the price indicated in the drop-down lists of the forms don't update(but not problems for the update of the price total of the product). I am turned over on the version 1.4 and there not of problem.

You can see the test site in order this production:
http://www.ferengis-lobe.com/ubercart/?q=node/1
Used the login: demo and password: demo

lemandarin, can you please post your problem to http://www.ubercart.org/contrib/2010 or even the issue tracker at http://drupal.org/project/uc_aac ? The Payment Method Adjustments module is completely different than the Ajax Attribute Calculations module.

There were some menu changes in AAC 2.0, so perhaps you need to clear the menu cache or run update.php to get that working?

Oh, ok Tom...I think I understand what you were saying now. Anyhow, can you try turning on clean urls? I think that might be a quick fix, but I'll try and figure out what this is not working with clean urls turned off.

The latest uploaded version of the module should work for you now regardless of clean url config. Thanks for helping to track down that problem. The problem was in uc_pma.js, so if your browser has that file cached it will not immediately work.

I found an issue with the module and posted here:
http://drupal.org/node/307151

ClipGlobe - World Travel

I don't know if this is posted already, but for % adjustements with decimals, it truncates the decimal part.

ie. for 6.95% COD adjustment the adjustment applied is 0.06 instead of 0.0695

I've modified the _payment_method_adjustment of uc_pma.module for solving this (lines 178-183 or so):

Before:

After:

You might be sure to post this fix in the issue tracker for this module:

http://drupal.org/project/issues/uc_pma

The str_replace() on the decimal marker is good idea, but maybe instead of number_format() it should be floatval(). If someone wanted a percentage like 7.125%, it wouldn't work.

I've opened an issue as Ryan recommended

http://drupal.org/node/315194

staciums threshold mod works great! Thanks so much!

If have tried to upgrade uc_pma to Drupal 6.x Ubercart 2.x.

But there are some difficulties i can't solve at the moment.
- form_alter doesn't work correct

Who can help?

mountain, perhaps you would have better luck if you posted your progress in the issue queue of the project at drupal.org. There is already a drupal 6 port issue opened for this module where you could attach your module or a patch http://drupal.org/node/325741