Jump to content

KirkM

Member
  • Posts

    166
  • Joined

  • Last visited

  • Days Won

    5

KirkM last won the day on December 1 2021

KirkM had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Kapaau, HI

Recent Profile Visitors

6,135 profile views

KirkM's Achievements

Rookie

Rookie (2/14)

  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges

7

Reputation

  1. Well, I feel like an idiot (not the first time). I was totally focused on where the coupon was applied and not on the shipping module. Uncommenting that line of code did the trick and makes perfect sense. It was right there in the shipping.class.php file, with a big flag of a comment to tell dummies like me "HEY! right here!". Sheesh. Thanks Brian for always jumping in to help. Your remark made me take a look over at the AIOS class after being so focused on the coupon class code.
  2. This is commented in the AIOS class: $this->_value = (float)$this->_basket['subtotal']; // XXX May want to remove coupon discount, i.e. // $this->_value -= $this->_basket['discount']; Could it really be as easy as uncommenting that line of code?
  3. Sorry, I realize this is not really clear. The example of what he needs is over-simplified with just the one product. There could be multiple products. The coupon in this case is for $15 off the whole order. Plus, his promotion also has free shipping for all orders $49 or more. He needs the shipping to be considered AFTER all coupons and any other discounts are deducted. The way the store works now, the coupon looks at the subtotal and the shipping looks at the subtotal ignoring the subtraction for the coupon, because the coupon also happens AFTER the subtotal. There is no consideration by the shipping for a modified subtotal because of the coupon. He will always need the shipping promotion to be on the final amount AFTER any discounts. To me, he is right, that is the way this should work or at least have the option for it to work that way. I hope that is a bit clearer on what the issue is with the current way CC handles the checkout flow.
  4. Been trying to figure out a way to get the coupon to be part of the calculation of subtotal. The more I examine the function of the cart / checkout process from the store owner's point of view and possible marketing approaches, the more I see that the coupon logic is deficient in it's ability to be used in conjunction with other marketing tools. I realize my point of view is rather simplistic since I am not intimately familiar with the code, but I have been reading through the relevant scripts and it seems that even with the complication of coupons for particular products or other variables, those discounts should be taken BEFORE the subtotal that all other things act upon, like shipping. Do you have any suggestions or ideas of how to hack this? Combining coupons with variable shipping zones / rates is pretty common for my client and seems to me to be a pretty basic marketing approach. Thanks.
  5. All in one shipping. What I was thinking was that the coupon should have the user choice of either calculating on the subtotal or as part of the calculation of the subtotal. That way the shipping or any other module can stay looking at the subtotal for their calculations. It would be a really nice flexibility feature in the coupon module.
  6. Interesting situation with a client on CC 6.4.4: He has shipping set up for a fixed rate of $7.95 for orders $0 - $48.99. He has another rate of free shipping for $49.00 - $100,000. He also has a coupon for $15 off for new customers. He needs the coupon to be subtracted BEFORE the store calculates the shipping rate. Here what is happening: Product Z 49.96 Subtotal 49.96 Certificate -15.00 Free Shipping Total 34.96 What he needs: Product Z 49.96 Certificate -15.00 Subtotal 34.96 Ship Charge 7.95 Total 42.91 I don't see a way to get this to happen. Anyone know if this is possible?
  7. OK, I got it. Once again, I got bitten by the "security by obscurity" silliness of CC. Updated the admin folder but not the old obscured admin folder before I ran the upgrade. Loaded the files manually to the new obscured folder and all is good now. I REALLY hate that "feature".
  8. No. Only Authorize.net Accept Hosted, Paypal Commerce Platform and All In One Shipping modules are enabled.
  9. OK, I see the bug you are referring to appears to be in the Print Order Form extension. I don't use that extension. I am getting this in the admin interface when viewing an order. Did I miss something in that bug thread on Github?
  10. Thanks Brian. I should have gone and checked the bug tracker but am so busy I took the lazy way and posted here. Will monitor it over there.
  11. Upgraded store from 6.2.9 to 6.4.4. No error messages in the upgrade. However, now product options print in what looks like a hash of some sort instead of the color, size, etc. (See attachment) Everything seems correct in the admin and I even deleted and re-added the options but it still prints out this hash on the order. I went in to the tables to make sure it wasn't something getting written that way but the options are correct and in plain text there. Any help on where I should start looking for this would be greatly appreciated.
  12. Is this available somewhere? One of my clients wants this functionality and it appears it still isn't built into the latest version of CC. I don't see it in the Extensions Marketplace. Thanks
  13. Just a side note - I took a look in detail of the 6.x checkout process since my client is kind of inferring that it is leading to people opening multiple accounts if they shop before starting checkout. <rant>JFC, you have to be some special sort of stupid to not be able to log into your account at ANY TIME shopping or at checkout. The very first step in checkout says to log in if you have a profile. If you ignore that and start to fill out the information, the ajax call to check the email tells you in real time that you already have that email registered so you can click the login link at the top. To purposely ignore all that and type a different email and continue and THEN call to complain that the store said you couldn't use your registered email address is absolutely mind blowing. You have to work at being that oblivious. </rant> Back on topic, if he requests it, I will close his store overnight, back everything up and try consolidating accounts according to the process I have identified and see if it works. If it does, I will do my best to document it and report back. If it doesn't work, I will report that too. If, after letting him know the risks of undetected issues appearing down the road upon initial success, he decides to leave it, then I will go radio silent on this whole thing. Thanks for the ear.
  14. That is about what one of my clients wants to do - Ask the customers if they intended to have multiple accounts. If not, then find out which email do they want to consolidate under. In most cases, this comes about because his customers call and complain that they couldn't log in so they used a different email to just get the order done. Not sure if it is due to text case issues (does CC use strtolower() on both read and write of user emails to eliminate text case verification errors?) or just people being stupid in one way or another. His business has a giant selection of dietary supplements so he has people that order over and over again for years and even decades. My only concern with doing this manual consolidation was missing something and causing data issues. I listed the ones that I found to be relevant and was looking for some guidance or verification that this will work from someone who has done it before in CC6.x.
  15. Resurrecting this from last year, I think a lot of store owners have this problem (my clients do), so I was looking at the tables and it appears that all of the tables regarding orders use the order number as a key reference and the only table that relates back to the customer ID is order_summary. It looks to me like this is where the relationship between orders (via order #) and customer (customer ID) is established and the order number is the key for all other relational information. Am I wrong in thinking that if I simply do a query in the order_summary table replacing the redundant customers I don't want with the ID of the one I am keeping, that this should move the history and all of the relational table information to that customer? It looks like it to me at this point since I don't see any other reference to customer ID in any tables relating to orders. Any observations about this? The other tables that would have to have the customer_id changed appear to be addressbook, downloads, customer_memberships, saved_cart, shipping_log (no entries?), transactions and customer_reviews. Cookie consent and sessions are strange ones since it seems that the store always puts a 0 in customer_id.
×
×
  • Create New...