The Foxy forums are on the move!

We're in the process of moving our forums over to a new system, and so these forums are now read-only.
If you have a question about your store in the meantime, please don't hesitate to reach out to us via email.

Just updated to 1.0; a few notes

oskayoskay Member
in General edited February 2013
I've just had some time available to (finally) update our store to 1.0.

A few notes:
1. The plain-text E-mail receipt looks simply *TERRIBLE* now. I don't know why you've changed the format so much, nor why you think that this is an improvement. Guess I'll have to figure out what the twig system is now....

2. So far as I can tell, there's no way to test nor preview how e-mail is going to look. As far as I can tell, I'll need to debug this on live e-mail, which doesn't feel right to me. (Less so, now that our receipts look terrible.)

3. The foxycart standard templates include the bad link: "https://{{ store_domain }}/cart?cart=updateinfo." Please remove or add a space before that period.

4. Shipping costs are now taxed, while they were not before. This is a big change, actually, and I'm very surprised that you didn't either announce it nor provide an option to disable it.
Comments
  • fc_adamfc_adam FoxyCart Team
    edited February 2013
    @oskay,

    Thanks for your notes! I'll try to answer each one for you.
    1. The plain-text E-mail receipt looks simply *TERRIBLE* now. I don't know why you've changed the format so much, nor why you think that this is an improvement. Guess I'll have to figure out what the twig system is now....

    Could you be more specific as to how it's displaying terribly? I've just done a quick test between an 0.7.2 and a 1.0 store, and while they are a little different in formatting, both were legible and easy to read. If you have some specific feedback we can certainly take that under consideration for adjusting the default template for a future version.

    As you mentioned though, if you want to customise the template at all, you can certainly do that using Twig - in fact you can completely rebuild the template to look however you want, it's a very powerful feature.

    2. So far as I can tell, there's no way to test nor preview how e-mail is going to look. As far as I can tell, I'll need to debug this on live e-mail, which doesn't feel right to me. (Less so, now that our receipts look terrible.)

    We don't have a way to preview an email without first having completed at least one transaction. After that though, you can trigger a resend of a receipt email as many times as you want. You'll see an email link in the transactions report to trigger that under the customer name on the right.

    3. The foxycart standard templates include the bad link: "https://{{ store_domain }}/cart?cart=updateinfo." Please remove or add a space before that period.

    That's actually consistent with the previous template, and surprisingly we haven't actually had anyone report this that I'm aware of. In my testing, I wasn't able to trigger an email client incorporating the period into the URL though - could you let us know which email client you're utilising that did that?

    4. Shipping costs are now taxed, while they were not before. This is a big change, actually, and I'm very surprised that you didn't either announce it nor provide an option to disable it.

    You've selected to have your taxes calculated automatically - which uses the Tax Data Systems database to work out the correct tax rate based on the customers billing/shipping details. It uses the postcode to work out the customers correct tax rate.

    This automatically works out if the tax should be applied to the shipping and handling rates as well - depending on the rules set in Tax Data Systems.
  • Could you be more specific as to how it's displaying terribly? I've just done a quick test between an 0.7.2 and a 1.0 store, and while they are a little different in formatting, both were legible and easy to read. If you have some specific feedback we can certainly take that under consideration for adjusting the default template for a future version.
    .

    You really call that "legible"? You've removed the bullets and whitespace within the cart that made it easy to read. And, because you've done it within the placeholders, it can't even be edited without what looks like an *absurd* amount of effort. You probably don't think twice about asking someone to learn a new templating language to fix your minor changes, but we just don't have time for that. We'll have to generate the e-mail from our backend from now on, and that does not feel *at all* like an upgrade to me.


    We don't have a way to preview an email without first having completed at least one transaction. After that though, you can trigger a resend of a receipt email as many times as you want. You'll see an email link in the transactions report to trigger that under the customer name on the right.

    OK, thanks-- I hadn't seen that. Does it also e-mail the customer?
    That's actually consistent with the previous template, and surprisingly we haven't actually had anyone report this that I'm aware of. In my testing, I wasn't able to trigger an email client incorporating the period into the URL though - could you let us know which email client you're utilising that did that?

    I do not use your default template, so I've never seen this before today. I was looking at your default templates in the admin, double clicked to copy it, and pasted it in my browser, edited the store name, and of course it failed until I removed the period. Looked like a bug; thought that I should say something.

    You've selected to have your taxes calculated automatically - which uses the Tax Data Systems database to work out the correct tax rate based on the customers billing/shipping details. It uses the postcode to work out the customers correct tax rate.

    This automatically works out if the tax should be applied to the shipping and handling rates as well - depending on the rules set in Tax Data Systems.

    Well, the rate is wrong, and I'm pretty unhappy about that because the sales tax was the main reason that I upgraded. And, I don't know if it's their fault or yours. It seems like it would be pretty expensive for me to get a copy of their database to check. Are you using their separate data for the taxability of shipping alone versus shipping combined with handling?
  • brettbrett FoxyCart Team
    Hi @oskay!

    * Email: We're discussing that now. We may be able to help you with that Twig to get it how you want it.
    * Period after the URL: We'll take a look at that too.
    * Taxes: Whisper us the transaction ID and we'll let you know exactly what was in our database. No need for you to have to check it on your end. It's entirely possible that it's a bug on our end, but it's also possible that TDS says shipping should indeed be taxed for that zipcode, in which case we'll followup with them and get you an answer.
    OK, thanks-- I hadn't seen that. Does it also e-mail the customer?
    Yes, it will, so you probably want to do it with a test transaction if you can. Or set up a quick test store to test against, depending on what'd be easier for you.
  • Thanks, Brett. I'll whisper some details.
  • brettbrett FoxyCart Team
    @oskay, I think the issue here is that on the BOE site. It says "Delivery–related charge is taxable when (for taxable sales only)" when:
    You do not keep records that show the actual cost of the delivery.

    Since FoxyCart groups the shipping + handling together (ie. even though we know what the shipping cost is, we don't have it as a separate line item as described in another part of that tax table), I interpret that to mean that the shipping charge itself _is_ taxable. Which kind of makes sense since typically handling fees aren't intended to be transparent to the customer, and if the tax was applied only partially then any customer with basic algebra could figure out what the shipping v. handling portions are.

    Thoughts?
  • oskayoskay Member
    edited February 2013
    Since FoxyCart groups the shipping + handling together (ie. even though we know what the shipping cost is, we don't have it as a separate line item as described in another part of that tax table), I interpret that to mean that the shipping charge itself _is_ taxable.

    Hi Brett,
    That argument is correct *when* there is a nonzero handling charge.

    If a FoxyCart store has a handling charge configured, then (in states like California where shipping+handling is taxed), the total cost of shipping+handling should be taxed. And, if the store does not have a handling charge configured, then (in states like California where actual shipping cost alone is not taxed), the total cost of shipping should be not taxed.

    As our store does not have a handling charge, it shouldn't collect tax on the shipping cost. This is a competitive disadvantage to us, if our store collects tax when it does not need to. And, it just seems plain silly to have to overcharge the customer, and then to refund that excess tax collected to the state.

    Which kind of makes sense since typically handling fees aren't intended to be transparent to the customer, and if the tax was applied only partially then any customer with basic algebra could figure out what the shipping v. handling portions are.

    That argument does *not* make sense to me.

    There are three possible cases that I can see (Again, for the case of California, where shipping cost alone is not taxable, but handling fees or shipping+handling is taxable):

    A ) The handling cost is separately itemized to the customer, and is taxed, while the separately itemized shipping cost is not.

    B ) The (shipping + handling) cost is itemized together, and is taxed (if handling cost is nonzero).

    C ) The (shipping + handling) cost is itemized together, while only the handling cost (if any) is taxed.


    And, then there's the case currently implemented:

    D) The (shipping + handling) cost is itemized together, and is taxed (whether or not handling cost is nonzero).


    You seem to be concerned about possible commerce issues* with implementing case (C)-- and there may be some valid issues there, but implementing case ( B ) also would just as easily solve this issue. I'm only trying to point out that the current situation, case (D), is incorrect.


    [*You might consider, in a future FoxyCart version, giving a choice for which option ( A ), ( B ), or ( C ) the FoxyCart customer would like to choose. Some of your customers (or their accountants) might prefer to have just the handling portion taxed; it feels like you're trying to make tax decisions here that you really should leave to the customer.]
  • brettbrett FoxyCart Team
    edited February 2013
    Thanks for the comments, @oskay. We'll look at the specifics on that text-formatted email and make sure we take those into account.
    As our store does not have a handling charge, it shouldn't collect tax on the shipping cost.
    Sorry, I totally missed that you weren't adding a handling charge. Our tax database does indeed say "don't tax shipping by itself" and "_do_ tax shipping + handling together", so it looks like this definitely isn't correct. We'll take a look and let you know when we roll out a fix (or if any new info emerges).
  • brettbrett FoxyCart Team
    Update for you, @oskay.
    We've just fixed the taxes on shipping / handling behavior. Once it gets past QA we'll push it live and update you. Thanks so much for pointing this out.
  • Great-- thanks so much for looking into this!
  • lukeluke FoxyCart Team
    Hey @oskay: we just pushed up a fix for live tax rates involving handling fees for both 1.1 and 1.0. Please check it out and let us know if you run into any other problems.
Sign In or Register to comment.