Jump to content

KirkM

Member
  • Content Count

    154
  • Joined

  • Last visited

  • Days Won

    3

KirkM last won the day on March 26

KirkM had the most liked content!

Community Reputation

5 Neutral

Profile Information

  • Gender
    Male
  • Location
    Kapaau, HI

Recent Profile Visitors

5,712 profile views
  1. 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.
  2. 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.
  3. 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.
  4. I just did a test with the original code restored and the CCD enabled and it appears you are correct. Thanks for tracking that down. Seeing that the GDPR extends to any company who could possibly do business with anyone in Europe, I suppose it should just be enabled by default in CC since theoretically every store on the web is doing business "worldwide".
  5. Using DevTools in Chrome, I cleared all cookies from the site and then loaded a couple of pages. I see a lot of cookies being stored from the CC store, but none that appear to be any of the listed cookie names used by Smarty. I need to find out where the $smarty.cookies.accept_cookies variable is stored and how it is triggered to true. Perhaps this is a result of the "Cookie Compliance Dialog" not being active in the store?
  6. So it has something to do with the cookie acceptance. If I go to skins/foundation/templates/element.google_analytics.php and take out the smarty {if} statement, it works fine. Original code: {if isset($smarty.cookies.accept_cookies) && $smarty.cookies.accept_cookies=='true'} {literal}<script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', '{/literal}{$ANALYTICS}{literal}', 'auto'); ga('set', 'anonymizeIp', true); ga('send', 'pageview'); </script>{/literal} {/if} Removed the {if} statement and that works: {literal}<script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', '{/literal}{$ANALYTICS}{literal}', 'auto'); ga('set', 'anonymizeIp', true); ga('send', 'pageview'); </script>{/literal} I don't see where this cookie acceptance is unless it is in the GDPR settings. In this store, they are both off. Does the cookie compliance dialog have to be on for the GA code to work?
  7. My skin is basically the Foundation skin with a few css tweaks. It should be doing exactly what the Foundation skin does. I will have to hunt around and see if I can find what you are talking about. In the mean time, I see a LOT of this in the error logs: File: [controller.admin.pre_session.inc.php] Line: [26] "SET @@time_zone = 'America/Los_Angeles'" - Unknown or incorrect time zone: 'America/Los_Angeles' File: [controller.index.inc.php] Line: [27] "SET @@time_zone = 'America/Los_Angeles'" - Unknown or incorrect time zone: 'America/Los_Angeles' Don't understand how that can be since it is the correct formatting for a timezone and it is selected from the admin drop-down menu. Edit: It does it with all timezone choices. Edit #2: It appears it is not relevant to this situation per this thread - https://forums.cubecart.com/topic/55533-error-about-timezone/
  8. Strangest thing - I upgraded from 6.1.13 to 6.2.9 a little bit ago and my client just noticed that there is no GA feed to his GA account. The really strange part of it is that it isn't an instant drop off. It goes from Feb 2 to Feb 17 in a sharp decline to zero over days. I don't know if the upgrade has anything to do with it or not. If it did, you would think it would have dropped to zero instantly when the upgrade was done. I have diffmerged all of the files to make sure that everything is the same on my installation as the clean version of 6.2.9, including matching my custom skin to the foundation skin with only my css changes the difference. Everything seems to be there. Also, I noticed that Google Tag manager shows no Google Pixel on the site when I go to it in Chrome. I also checked to make sure the element.google_analytics.php file is there in the skin templates file. Not sure where to start looking for this.
  9. Al - Just noticed that the First Name and Last Name are inverted in versions 1.0.4 & 1.0.5 on lines 179 & 180 in gateway.class.php
  10. So I tried the mod you suggested and it appears to work and give the correct tax based on my loading a basket with the same items that were in the original example. As far as the customer's view is concerned, the display is still rounded to 2 dp. I took it up to the hosted checkout so it would register in the admin as a pending order and that seems to display correctly also. I don't think any template mods are necessary unless I am missing something. Is there any reason this can't be in the next version as the actual bug fix? It seems that the rounding on each taxable line item before subtotaling isn't necessary for the entire tax routine to work accurately.
  11. My wife did some accounting early in her career and tells me that line-item tax calculation is the way she was taught for various reasons, such as returns and refunds. You have to be able to pinpoint the amount of tax paid for each item so you can refund the item cost AND the tax paid for it from a multiple-item order. Therefore, your proposal seems like a reasonable theoretical solution. However, right now, my clients need the tax to be accurate and can't wait for a possible fix in the distant future. Tax authorities frown on taking excess tax from consumers. Too little is fine because they just make you take it out of your profits to pay your sales taxes. Too much can be considered defrauding the consumer since you end up with the excess that was taken under the guise of tax after you pay the correct amount to the government tax authority. If you are going to rip people off, they want you to use the "Shipping and Handling" scam. I will try to use your fix idea above and see if that works for now. Thanks again for all of your help and expertise.
  12. Thanks bsmither. I see that the final conclusion of issue 2210 is that the tax calculation of the store really needs to be rewritten to solve all of the issues. I am looking into sprintf vs round discussions to try to expand my knowledge of working with floats in php. Forgive me if this is the dumbest question ever asked, but why can't the order carry two (non-displayed) subtotals: one for taxable items (& shipping, if specified as taxable) and one with non-taxable and tax-included items? At the calculation / display endpoint, tax is calculated on the taxable item sum rounded to 2 dp (for western currencies). Since tax always applies to subtotals per order and not individual items per order in normal commerce transactions, wouldn't this eliminate the "creep"? You would only be rounding once at the end instead of creating a chain of rounding that increases the error with each additional line item. It just seems that the tax work is being unnecessarily done on product line items where it isn't needed and should be moved to a taxable subtotal. Are there accounting reasons for needing a sales tax breakdown for every item sold? Again, forgive me if this is incredibly naive.
  13. Thanks very much for your help. It would take me ages to track it down as I am not really familiar with the CC code.
  14. It appears that the discounts are manually calculated by them and each sale price is entered in each individual product's "sale price". The $20 off is a coupon discount for the entire order in addition to the individual sale prices on each item. I just checked the one item quickly and saw that the sale price was exactly 20% off the regular price so I assumed that they are doing that with all of the products on sale. However, I did a spot check on a couple of others and they are all different percentages off so maybe they are discounting based upon cost or something. Anyway, it shouldn't matter since they are manually entering a sale price on each individual product. It could be anything and the math should still work on the tax calculation. There is not any kind of global discount, they are all product-specific. See the screen shot for an example of how each sale product price is entered. Here are the numbers in regular price -> sale price: $99.95 -> $83.96 $72.95 -> $58.36 $19.95 -> $11.97 $49.95 -> $33.27 $79.95 -> $66.96 $59.95 -> $36.97 And here is the tax setup, it is pretty straightforward:
  15. Store was upgraded from 6.1.13 Yes. Those cents you find odd are the result of a percentage discount off of the regular price. Everything in the store is $X.95 at regular price. For example, the item that is $58.36 is normally $72.95 and is discounted 20% to $58.36, which they have entered in the product's pricing tab under sale price. No products in this store have options. Order summary in the admin area.
×
×
  • Create New...