税收引擎示例
我们为 Mac 创建销售点软件，并正在寻求改进我们的税务引擎。现在非常简单，税费由名称、代码和费率组成，可以单独应用于每个产品。虽然这对于某些人来说已经足够好了，但我们收到了很多处理更高级情况的请求。一些例子包括美国市/县销售税、加拿大复合（叠加）税、法国生态税和纽约奢侈税。
我们已经确定了这些税收所具有的大部分特征，并且倾向于某种基于规则引擎的实施。我们不必支持所有情况，但我们希望能够在需要时对其进行扩展（以避免再次重写）。
我们正在寻找以前构建过类似内容的人的建议，或者尝试以优雅的方式解决相同问题的项目示例。
We create point of sale software for the mac, and are looking to revamp our tax engine. It's pretty simple now, with taxes consisting of a name, code and rate that can be applied to every product individually. While this is good enough for some people, we've had lots of requests to handle more advanced situations. Some examples are US City/County sales tax, Canadian compound (stacked) taxes, French ecotax and NYC luxury tax.
We've identified most of the characteristics that these taxes have and are leaning towards a sort of rule-engine based implementation. We don't have to support every case out there, but we want to be able to extend it if needed (to avoid another rewrite).
We're looking for advise from people who built something like this before, or examples of projects that try to solve the same in an elegant way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的建议是使用数据库表来发挥其优势（存储值），并使用规则来发挥其优势（业务逻辑）。我当然不会将税率或司法管辖区列表之类的内容放入规则中 - 这些应该放在表格中。我将使用规则引擎来定义逻辑，以确定对哪些交易应用哪种费率。因此，举例来说，如果我从位于 X 州的一家公司在线购买一组产品，并将其从 Y 州运送到三个不同的地点，那么交易的哪些部分适用什么税率？
这种规则和数据库表格的组合非常常见 - 规则确保您查找正确的内容，而表格有助于报告等。例如，加利福尼亚州 DMV 就车辆登记费做到了这一点 - 所有各种费用都存储在确定哪种费用适用于哪辆车的规则在规则库中进行管理。
如果您尝试将所有内容放入规则中，您将无法很好地报告；如果您尝试将所有内容放入数据库表中，您最终将得到数十个表来管理所有异常和极端情况。
杰特
My suggestion would be to use database tables for what they are good for (storing values) and rules for what they are good for (business logic). I would certainly not put things like tax rates or lists of jurisdictions in rules - those should be in tables. What I would use a rules engine for is defining the logic that determines which rate to apply to which transactions. So, for instance, if I buy a set of products online from a company based in State X that ships from State Y to three different locations, what tax rates apply to which parts of the transaction?
This combination of rules and database tables is very common - the rules make sure you look up the right things while the tables aid in reporting etc. For instance, the California DMV did this with vehicle registration fees - all the various fees are stored in a database while the rules that determine which fee applies to which car are managed in a rulebase.
If you try and put everything in rules you will not be able to report well and if you try and put everything in database tables you will end up with dozens of tables to manage all the exceptions and corner cases.
JT
我会推荐一组数据库表和联接。
示例：
负责收税的
要查找要应用的税费列表，您所需要的只是商店、其管辖区、这些管辖区的管辖区税码以及产品的税码的 INNER JOIN。
您可以将 ProductTaxCode 定义为视图，以便所有产品都会收到默认的 TaxCode，除非提供了特殊的 TaxCode。通过抽象 TaxCode，您可以将有关产品（例如“食品”）的相同元数据以不同的方式应用于不同的区域。如果特定司法管辖区对“食品”有自己的定义，您只需添加特定于司法管辖区的代码并根据需要将其应用于产品。
这可能需要对互联网购买、批发购买以及销售以某种方式免税或客户负责汇出的其他情况进行一些调整。它还需要针对客户位置而不是商店决定税率的情况进行调整。
其他调整：例如，在德克萨斯州，我们有一个“免税”周末，对于某些类别的单件商品售价低于 100 美元的产品，不征收州税和地方税。这个想法是为新年上学的孩子们提供更便宜的学习用品、衣服等。这种调整可以通过为未来每个 JurisdictionTaxCodeRate 制定一个日期范围表来实现（只要可以计划）。
I would recommend a set of database tables and joins.
Example:
responsible to collect taxes for
To find the list of taxes to apply, all you need is an INNER JOIN of the store, its jurisdictions, the jurisdictiontaxcoderates for those Jurisdictions, and the product's tax codes.
You could define ProductTaxCode as a View so all products receive a default TaxCode unless a special one is provided. By abstracting TaxCode, you can have the same metadata about a product ("Food" for instance) apply to different regions in different ways. If a particular jurisdiction has its own definition of "food", you just add a jurisdiction-specific code and apply it to products as needed.
This may require some tweaking for Internet purchases, wholesale purchases, and other situations where the sale is somehow exempt from taxes or the customer is responsible for remitting them. It would also need tweaking for situations where the customer's location, rather than the store, decides the tax rate.
Other tweaks: here in Texas, for instance, we have a "tax-free" weekend where state and local taxes are not collected on some classes of products where the individual item's sale price is less than $100. The idea is to provide cheaper school supplies, clothing, etc. for children heading off to school for a new year. This sort of tweak could be implemented by having a date range table for each JurisdictionTaxCodeRate going off in the future as far as they can be planned.
以下是科罗拉多州丹佛市大都市区“自治”城市的示例：
http ://www.c3gov.com/pages/about/division_salestax.html
作为零售商，您可能还需要将税款发送到不同的地点。对于不是“地方自治”城市的城市（这是一个特殊术语，可能仅适用于科罗拉多州，但可能每个州都有一些类似的特殊术语），您将把所有税款发送给该州，该州将然后将其处理给相关各方。科罗拉多州有一个特点，即存在“特殊税区”，允许收取某些福利的销售税（在示例链接中，RTD 是公共交通区，“Invesco Field”是丹佛野马队比赛的体育场）。
为了扩展塔伦特先生在该主题上的回答，您还需要在管辖权表中包含某种表示税收可能流向不同地方的方式。
Here is an example of a "home rule" city in the Denver, CO metropolitan area:
http://www.c3gov.com/pages/about/division_salestax.html
You, as a retailer, may also need to send the tax payments to different locations. For cities that are not "home rule" cities (which is a special term that probably only applies to Colorado, but then probably every state has some equally special term like it), you'll send all the tax payments to the state who will then deal them out to the relevant parties. Colorado has a feature where there are "special tax districts" that are permitted to collect sales taxes for certain benefits (on the example link, RTD is the public transportation district, and "Invesco Field" is the stadium where the Denver Broncos play).
To expand upon Mr Tallent's answer on this thread, you'll need to also include in the Jurisdiction table some way of representing that the taxes may go to different places.