4

我们为 Mac 创建销售点软件，并正在寻求改进我们的税务引擎。现在很简单，税收由名称、代码和税率组成，可以单独应用于每个产品。虽然这对某些人来说已经足够了，但我们有很多请求来处理更高级的情况。一些例子是美国市/县销售税、加拿大复合（堆叠）税、法国生态税和纽约市奢侈品税。

我们已经确定了这些税收的大部分特征，并且倾向于一种基于规则引擎的实施。我们不必支持所有情况，但我们希望能够在需要时对其进行扩展（以避免再次重写）。

我们正在寻找以前构建过类似东西的人的建议，或者尝试以优雅的方式解决相同问题的项目示例。

4

3 回答 3

2

我的建议是将数据库表用于它们的优点（存储值）和规则用于它们的优点（业务逻辑）。我当然不会将税率或司法管辖区列表之类的东西放在规则中——这些应该放在表格中。我将使用规则引擎来定义确定将哪个速率应用于哪些事务的逻辑。因此，例如，如果我从位于 X 州的公司在线购买一组产品，从 Y 州运送到三个不同的地点，那么交易的哪些部分适用什么税率？这种规则和数据库表的组合非常常见 - 规则确保您查找正确的内容，而表格有助于报告等。例如，加州 DMV 使用车辆登记费做到了这一点——所有各种费用都存储在数据库中，而确定哪些费用适用于哪辆车的规则则在规则库中进行管理。如果您尝试将所有内容都放入规则中，您将无法很好地报告，如果您尝试将所有内容都放入数据库表中，您最终会得到数十个表来管理所有异常和极端情况。捷通

于 2009-08-27T23:58:10.880 回答
1

我会推荐一组数据库表和连接。

例子：

  • 管辖范围：州、县、国家、城市等的列表。
  • 产品：明显
  • 商店：您销售的地点列表
  • StoreJurisdiction (StoreID, JurisdictionID)：店铺负责为其征税的Jurisdiction列表
  • ProductTaxCode (ProductID int, TaxCodeID int)：用于征税的产品类型：基本、奢侈品等。
  • JurisdictionTaxCodeRate（JurisdictionID、TaxCodeID、InterestRate、RateType）：对于每个适用的 Jurisdiction 和 Tax Code 组合，提供要应用的税率，以及税率的类型（复合、简单等）。

要查找要应用的税款列表，您只需要商店、其管辖区、这些管辖区的管辖税编码器以及产品的税码的INNER JOIN 。

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

这可能需要对互联网购买、批发购买和其他销售以某种方式免税或客户负责汇款的情况进行一些调整。它还需要针对客户的位置而不是商店决定税率的情况进行调整。

其他调整：例如，在得克萨斯州，我们有一个“免税”周末，对于个别商品的售价低于 100 美元的某些类别的产品不征收州和地方税。这个想法是为新的一年去上学的孩子们提供更便宜的学习用品、衣服等。可以通过为每个 JurisdictionTaxCodeRate 设置一个日期范围表来实现这种调整，只要它们可以计划在未来发生。

于 2009-08-26T20:35:05.883 回答
1

以下是科罗拉多州丹佛市都会区的“自治”城市示例：

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

作为零售商，您可能还需要将税款发送到不同的地点。对于不是“自治”城市的城市（这是一个可能仅适用于科罗拉多州的特殊术语，但可能每个州都有类似的特殊术语），您会将所有税款发送给将然后将它们分发给相关方。科罗拉多州有一个特点，允许为某些利益征收销售税（在示例链接上，RTD 是公共交通区，而“景顺球场”是丹佛野马队比赛的体育场）。

要扩展 Tallent 先生在此线程上的回答，您还需要在 Jurisdiction 表中包含某种表示税款可能流向不同地方的方式。

于 2009-08-26T21:07:25.567 回答