Question

我正在尝试确定最适合存储产品税的方法。

TABLE products (
    id
    name
    description
)

TABLE tax_zones (
    id
    code
)

TABLE tax_rates (
    id
    zone_id
    rate
)

TABLE tax (
    id
    rate_id
)

TABLE product_tax (
    id
    product_id
    tax_id
)

我承认，即使我对这种结构感到有点困惑，所以我需要一些帮助来简化或澄清两者。

我的商店是国际性的，所以它只适用于加拿大和美国......产品可以在世界各地购买。

Answer 1

表product_tax的目的是什么？存储每种产品的税务信息不是您应该采用的方式。

美国（可能还有加拿大）的税收因州而异，通常低至邮政编码级别（有时甚至是子ZIP！）。处理税收的正确方法是将它们应用于整个购物车（即按百分比计算），而不是单个产品。

关于如何应对税收......欢迎来到有趣的网上购物世界。有一些服务提供Web服务（因为税收变化非常频繁）。其中一个产品是AvaTax。

我将重申我在评论中所说的内容。建造了许多购物车（并在此过程中被烧毁了！）我在该领域拥有丰富的经验。

＆＃34;本地＆＃34;在税收方面无关紧要。应该征税根据国家，州，地区，县，镇等的说法物品正在运送＆＃39;至。换句话说，它是收件人的税适用的规则。如果产品是送给某人的礼物除购买者以外的地区，是他们的税收规则应用。换句话说，买方支付适用于的税收收到礼物的人！

此外，我将在下面进一步阐明我的评论......

税收与相关产品完全分开。税收应适用于全部费用金额，而不是单个项目。唯一的例外是产品被视为＆＃34;非应税＆＃34;。这主要适用于被认为是＆＃34; essentials＆＃34;的某些食品。显然，其他一切都被视为奢侈品！

因此，如果购物车中有3个1美元的商品，税率为8.00％将使总额达到3.24美元。在税后添加任何运费。运费不属于产品价格的一部分，因此不征税（运费由税务局，UPS等预先征税）。

由于税率因地域而异，因此尝试附加税收是没有意义的。值对数据库中的产品。该数据应在每次交易中单独应用。从Web服务获取正确的税额可以减少发生错误的可能性。值得注意的是，税收经常变化很重要。如果您经过审核并证明已收取不正确的税款，您可能需要自己支付差额。税法很少关心谁支付税款，只支付税款。

好的，关于表结构的一些想法......

product table { id sku [manufacturer or made up] related_items brand description features specifications keywords price weight width height length packaging_type shipping_info flatrate_shipping taxable discountable insured featured status [enum('outofstock','instock','specialorder','calltoorder','comingsoon','onorder','sold','onhold','hide')] stock } category table { id category_id category_name category_description } product_category table { id category_id product_id }

最后一个表格提供了将许多产品放入一个类别，或将一个产品放入多个产品的方法。

Answer 2

根据法律情况，税收可能取决于非常不同的事情：

卖家的位置
买方所在地
产品（类型）

任何组合都是可能的。例如，如果卖方和买方都在欧洲，则在德国（简化）有7％的食品和19％的非食品。

可能会出现其他规则。例如，税收可能是基于时间的。

因此，最后，您需要一个与您的产品（或产品组）一起使用的税码，以及一个由tax_key，seller_location和buyer_location索引的税表。使用后两者的通配符，可以减少所需的记录数。

税收数据库架构

2 个答案: