“动态”定价系统

时间:2011-01-14 18:33:55

标签: interpreter configurable-product

很快,我将开展一个项目,该项目相当于配置产品的电子商务应用程序。这个问题是关于实现可以每天更改的定价方案的方法,因此我们希望将定价逻辑从代码中提取到数据库中,但不是以导致数据库完成所有工作的方式。

基本思想是这个,有5个属性。您从每个属性中选择一个选项。然后开始向购物车添加产品。您添加的所有产品都会将5个属性添加到它们上(属性会影响定价)。添加产品后,您可以对其进行修改(属性也将应用于修改)。

所以,我们在这一点上得到的是一个产品(具有固定的基本价格)及其中的一些信息(将修改价格),以及零个或多个修改(具有固定价格)和关于它们的一些信息(将修改价格)。修改也可能产生额外费用。例如,如果公司A使用这个软件并且他们使用以下物品定价他们的物品:BASE_PRICE + $ 50 * NUM_WHIRLIGIGS并且该物品有一个添加WHIRLIGIG的修改,则必须反映在价格中。

您知道在确定如何设置时我可能会发现有用的不同定价系统的任何示例吗?你有更好的想法吗?

我目前最好的想法是,如果您对该方法的细节不感兴趣并且想要正确回答,您可以跳过它!

对于任何给定项目(或项目集合),公司可以使用特殊界面来设置定价公式,然后在运行时对其进行解释和评估。

因此,对于PRODUCT_A,该公司可能会提供类似BASE_PRICE + WHIRLIGIG_UPCHARGE * NUM_WHIRLIGIGS的内容。当软件定价时,软件会查看该项目有多少WHIRLIGIG,以及通过任何修改添加多少WHIRLIGIG。

有没有人有实施这种翻译的经验?后来如何?难道/麻烦吗?

提前感谢所有令人敬畏的输入,我相信我会得到。 :P

1 个答案:

答案 0 :(得分:0)

通常,这通常使用具有组件的产品包进行处理。所以带有5个额外子组件的产品不会是base + 5 * addon,而是SUM(base,addon,addon,addon,addon,addon)。

因此,您的产品表可能是自我引用的,或者存在某种链接表,其中说明哪些子产品可以附加到哪些产品上。

根据我的经验,定价通常存储在产品/客户或合同的基础上,因此这是另一张表。

然后实际订单本身包含产品包。如果订单是报价,则冻结定价(直到报价到期)。

当报价或订单变成发票时,根据定价时间范例,当时定价会被锁定在主要定价或报价中。