Websphere Commerce 每个订单的最大订单数量更改为所有订单历史记录和待处理答案

【问题标题】：Websphere Commerce Maximum Order Quantity Per Order Change to All Order history and pendingWebsphere Commerce 每个订单的最大订单数量更改为所有订单历史记录和待处理
【发布时间】：2015-02-13 22:53:33
【问题描述】：

我这里有一个 Websphere commerce 7 Fp 5 Aurora B2B，它使用组织、合同和价目表的最大订单数量，我们限制每个“商店”组织每个购买 3 个，这样就足够了。我们有 3 套权利，大多数人最多 3 个，更好的商店最多 5 个，一些非常好的商店最多 10 个。

所以我们不必担心分配问题，这些规则让每个商店都可以根据自己的权利进行购买。当他们尝试在购物车中放入更多的东西时，他们会收到一条消息“您请求的订购量超过了您的分配限制。请更改您请求的数量。”我不知道这是从哪里来的。

部分用户购买 5 家或更多商店，这些商店是在付款时在结帐时选择的。这使那些店主不必进行大量登录来跟踪。

我们最近开放了订单管理，我们称之为多购物车，因为这使店主可以通过转到订单管理并创建新订单来创建多个购物车。这让我们的店主可以更轻松地管理他们购买、支付和接收的商品，而无需致电和发送电子邮件给我们的 CSR 团队。

但现在我们注意到，一些商店正在利用 Multi-cart 购买超过他们所允许的 MAX 数量的更多商品。这不会那么糟糕，但他们正在为每位顾客购买所有 1 件商品，而所有其他商店都在打电话抱怨，因为他们没有得到他们的份额。这真的不公平。

我正在考虑在所有不同的地方添加对订单历史记录和挂单的 SQL 检查。这是我的想法。

ATP - 库存检查最好的地方，因为客户、sku、权利和其他一切都在这里发生。它就在前面。 Con- 它没有收货地址，因此需要将拥有超过 1 个商店的人作为例外添加，导致可能会定期更改的草率业务逻辑
OrderItemAddCmdImpl 和重载 ExtendOrderItemProcessCmd Pro - 将送货选择带到最前面并控制这里的一切。缺点 - 不确定开销是否会喜欢它。
结账时亲 - 这也将拥有一切骗局 - 我有点想为所有付款处理保留这个。通读订单行并使用 SKU 回退错误有点脏。
让 ERP 处理异常 - 缺点 - 我意识到我们设置了所有订单发货完成，我们将不得不更改这一点，并且真的不想这样做，因为如果费用少于信用卡持有的金额，则会产生额外的信用卡罚款。

那么，问题是您对其他利弊有何看法？还有其他我想念的地方更有意义吗？

【问题讨论】：

标签： websphere-commerce

【解决方案1】：

我们可能需要创建一个新的 CommandTask，然后将它附加到所有现有的流程中。

或

作为 WebSphere Commerce 团队将这个新逻辑构建到 WebSphere Commerce 的下一个版本中。

【讨论】：

【解决方案2】：

因此，对于这种情况，答案是创建一个 JDBC 查询，当将商品添加到购物车时将调用该查询，该查询将按 sku 的挂单数量求和。

将orderitems添加到购物车时，如果超出查询将返回错误的商品并且不添加商品。

如果付款页面上按 SKU 的送货地址支付的所有订单商品的总数量超过总数量，则查询将在结帐时再次运行，如果我们通过送货地址限制商品的最大数量，客户有机会更改账单地址。

【讨论】：