我正在尝试确定最合适的方式来存储产品税。
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
)
我承认，即使我对这个结构也有点困惑，所以我需要一些帮助来简化或澄清，或者两者兼而有之。
我的店是国际化的，所以它只针对加拿大和美国…产品在世界各地都能买到
表product_tax的目的是什么?为每个产品存储税务信息不是你应该采取的方式。
美国(可能还有加拿大)的税收因州而异，通常是邮政编码级别的(有时甚至是ZIP以下的!)处理税款的正确方法是将其应用于整个购物车(即按百分比计算)，而不是单个产品。
关于你如何处理税收…欢迎来到有趣的网上购物世界。有一些服务提供web服务(因为税收变化非常频繁)。AvaTax就是这样一个产品。
我将在评论中重申我所说的话。构建了许多购物车(并在此过程中被烧毁!)我在这个领域有相当的经验。"本地"与税收无关。应该征税按国家、州、地区、县、镇等表示项目被"运送"到。换句话说，这是收款人的税适用的规则。如果一个产品是送给某人的礼物地区以外的买家，是他们的税收规则适用。换句话说，买方支付适用于商品的税收到礼物的人!
另外，我将在下面进一步说明我的评论…
税费与相关产品完全分离。税应适用于全部成本金额，而不是个别项目。唯一的例外是产品被视为"不征税"。这主要适用于某些被认为是"必需品"的食物。显然，其他一切都是奢侈品!
因此，如果购物车中有三件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
}
最后一个表提供了将多个产品放入一个类别或将一个产品放入多个类别的方法。
税收可以取决于非常不同的事情，取决于法律情况:
- <
- 卖方的位置/gh><
- 买方位置/gh>
- 产品(类型)
任何组合都有可能。例如，在德国，如果买卖双方都在欧洲，食品的税率为7%，非食品的税率为19%。
可能会有其他规则。例如，税收可以是基于时间的。
因此，最后，您需要一个与您的产品(或产品组)一起使用的税键，以及一个由tax_key、seller_location和buyer_location索引的税表。对于后两者使用通配符，您可以减少所需的记录数量。