税务引擎示例

我建议使用一组数据库表和联接。

例子:

• 管辖权 :州、县、国家、城市等的列表。
• 产品 明显的
• 商场 :销售地点列表
• 仓库管辖权 (storeid,辖区id):存储的辖区列表 负责征收
• 产品编码 (productid int,taxcodeid int):用于征税的产品类型:基本型、豪华型等。
• 管辖权、强制指令 (辖区ID、税码ID、利息、税率类型):对于每个适用的辖区和税码组合,提供要应用的税率和税率类型(复合、简单等)。

要找到要申请的税单,您只需要 内连接 商店、其辖区、这些辖区的辖区和产品的税码。

您可以将ProductTaxCode定义为视图,这样所有产品都会收到默认的TaxCode,除非提供了特殊的TaxCode。通过抽象taxcode,您可以让关于产品的相同元数据(例如“food”)以不同的方式应用于不同的区域。如果一个特定的司法管辖区对“食品”有自己的定义,您只需添加一个司法管辖区特定的代码,并根据需要将其应用于产品。

这可能需要对互联网采购、批发采购以及销售免税或客户负责汇款的其他情况进行一些调整。如果客户所在地(而不是商店)决定税率,还需要进行调整。

其他的调整:例如,在德克萨斯州,我们有一个“免税”的周末,州税和地方税都不收。 一些 单个产品的销售价格低于100美元的产品类别。这个想法是为准备去学校过年的孩子们提供更便宜的学校用品、衣服等。这种调整可以通过为每个辖区创建一个日期范围表来实现,在将来可以计划的范围内,这是一种例外。

我的建议是使用数据库表来实现它们的优点(存储值)和它们的优点(业务逻辑)。我当然不会将税率或司法管辖区列表等事情放在规则中——这些应该放在表格中。我将使用规则引擎的目的是定义逻辑,该逻辑确定应用于哪些事务的速率。例如,如果我从一家位于X州的公司在线购买一套产品,该公司从Y州运送到三个不同的地点,那么交易的哪些部分适用什么税率? 这种规则和数据库表的组合是非常常见的-规则确保在表帮助报告等时查找正确的内容。例如,加利福尼亚州的DMV使用车辆登记费进行查找-所有的各种费用都存储在数据库中,而确定哪种费用适用于哪种车辆的规则则存储在数据库中。规则库 如果尝试将所有内容都放入规则中,您将无法很好地报告;如果尝试将所有内容放入数据库表中,您将得到几十个表来管理所有异常和角情况。 JT公司

以下是一个位于丹佛市的“家庭规则”城市的例子:

http://www.c3gov.com/pages/about/division_salestax.html

作为零售商,您可能还需要将纳税款发送到不同的地点。对于那些不是“家庭规则”城市的城市(这是一个可能只适用于科罗拉多州的特殊术语,但可能每个州都有类似的特殊术语),你将把所有的税收支付给州政府,然后由州政府向相关方支付。科罗拉多州有一个特点,那里有“特殊税区”,允许为某些福利征收销售税(在示例链接上,RTD是公共交通区,“invesco field”是丹佛野马队比赛的体育场)。

为了进一步说明塔伦特先生在这一问题上的答案,您还需要在司法管辖权表中加入一些表示税收可能转移到不同地方的方法。