(v5) Design Documentation

v5.0.0 and later of Edit Orders is delivered as a Zen Cart encapsulated plugin and changes its processing to

• Re-use any orders_products table entries, where possible.
• Use AJAX to enable an admin to make all changes necessary, committing those changes only when satisfied with the outcome.
• Run under zc210 and later without core-file changes.
  • Will run under zc201 with various zc210 PRs required.
    • https://github.com/zencart/zencart/pull/6707
    • https://github.com/zencart/zencart/pull/6743
    • https://github.com/zencart/zencart/pull/6750
  • Might run, but isn't supported, on Zen Cart versions prior to 2.0.1.
• Reuse (as much as possible) the Zen Cart base installation of the order and shopping_cart classes, recognizing the possible situations:
  • A coupon was applied to the original order, but either the coupon has expired or its number of uses has been exceeded.
  • A product or product-variant in the order has been removed from the site.
  • A product in the order was on special/sale when the order was placed, but the special/sale has expired.

Note: PHP_FLOAT_EPSILON is 2.2204460492503E-16

This version will address these GitHub issues:

• https://github.com/lat9/edit_orders/issues/242
• https://github.com/lat9/edit_orders/issues/239
• https://github.com/lat9/edit_orders/issues/145
• https://github.com/lat9/edit_orders/issues/59
• https://github.com/lat9/edit_orders/issues/58

Additional notifications to consider:

• shopping_cart.php
  • NOTIFIER_CART_GET_PRODUCTS_END
  • NOTIFIER_CART_SHOW_TOTAL_END
  • NOTIFIER_CART_SHOW_TOTAL_BEFORE_DISCOUNT_END
• Product.php
  • NOTIFY_GET_PRODUCT_OBJECT_DETAILS_NOT_FOUND
  • NOTIFY_GET_PRODUCT_OBJECT_DETAILS
• functions_attributes.php
  • NOTIFY_GET_ATTRIBUTE_DETAILS
  • NOTIFY_ZEN_HAS_PRODUCT_ATTRIBUTES_CHECK
  • NOTIFY_GET_ATTRIBUTE_DETAILS_BY_ID

Tax Reconstruction Issues

The way a storefront order's ot_tax values and, as important, titles are created depends on a couple of factors:

1. The value for Configuration :: My Store :: Show Split Tax Lines
2. The value for Configuration :: My Store :: Sales Tax Display Status, which indicates whether/not to include 0-value taxes in an order's recording.
3. Whether a site has multiple tax-rates set for a given Tax Class
4. Whether the customer-selected shipping module has its own Tax Class or reuses that configured for the products.

For these examples, I'm using the demo products' installation as a start. That installation defines a Tax Class of "Taxable Goods" with a default tax-rate for Florida of 7% with a description of FL TAX 7.0%. For Florida, I've added an additional county tax-rate for that tax-class and added another tax-class that can be configured into various shipping modules. I've also added another Zone Definition for US/GA taxes, so the current "Tax Rates" show as:

I've updated the Flat-Rate shipping module to use the 'Shipping Tax' tax-class and the Per-Item module to use 'Taxable Goods'.

For a single product in the cart, shipping to Florida and choosing the Per-Item shipping, the order's totals are recorded differently for various combinations of the above factors. Here's the product

With "Show Split Tax Lines" set to 'false':

With "Show Split Tax Lines" set to 'true':

Switching to a shipping-address in Georgia and using Per-Item shipping, the shipping tax and products' tax are properly combined: