Jump to content

KirkM

Member
  • Content Count

    151
  • 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,568 profile views
  1. 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".
  2. 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?
  3. 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?
  4. 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/
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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:
  12. 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.
  13. A client in California has alerted me that his store is not correctly calculating sales tax. I checked it and he is correct. He said it started happening after the upgrade to 6.2.9. I checked his tax rate setup and his zones and all appears to be done correctly. He has it to calculate on items and shipping. CA sales tax is 9% and it appears that it is calculating a fraction of a percent over that. The amount of error seems to depend upon the size of the total order. Anyone else experience this or have any idea where I should start looking? It all should be pretty straightforward so I am not sure how this can happen. I thought maybe it was because some products are discounted but when I do the math without the discount it is still off. Example is attached that shows an incorrect tax, it should be $25.15. Thanks for any help or ideas of where to go to try to track this down.
  14. Here is what I have from tonight's test: - Order DOES go to "processing" even if the customer bails out after hitting the "Pay" button and doesn't go back to the store by clicking the "Confirm" button on the Auth.net results window. This is great. - Created a copy of the "Default emails" template, called it "Hard-coded emails", replaced the header image and signature macros with hard-coded urls and made it the default. - Under the "Email Contents" tab, I modified Cart: Order Confirmed and Admin: Order Received, replacing the macro {$DATA.link} with a hybrid hard-code / macro combination of https://mystore.com/index.php?_a=vieworder&amp;cart_order_id={$DATA.cart_order_id} (where mystore.com is the actual store domain and the order number is handled by the dynamic macro {$DATA.cart_order_id}). - Have NOT been able to solve the gigantic store title issue on the Auth.net transaction results page. Will have to keep looking or call their support and find out how to get this under control. It looks like all of the information is being sent correctly and the transaction was successful. (NOTE: I only tested auth only since my clients all capture funds when the item ships.). Generally, it works with a few workarounds and the need for a small formatting tweak. I much prefer the new embedded frame and the clean form look and operation to the old SIM. It works well enough for me to put it live in one of my client's stores. We will see how it goes over the next 24 hours of live use.
  15. Or maybe you are right. It happened when I first tested this extension but there were other things misfiring so that could have been it. I know the old SIM extension did that but we didn't employ the silent post URL with that. I will check v4 overnight (HST) and look at the status in admin before I click the CONFIRM button. Seems to be the standard M.O. with their API and documentation. Lots of blanks you have to fill in yourself. One other thing - Do you know if it is possible to format this? "settingName": "hostedPaymentOrderOptions", "settingValue": "{\"show\": true, \"merchantName\": \"'.addslashes($GLOBALS['config']->get('config', 'store_name')).'\"}" The store name is HUGE. I have searched around the Auth.net docs and I don't see it. If the store name is a moderately long word, it word-breaks and wraps. It looks pretty terrible.
×
×
  • Create New...