1

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

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

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

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

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

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

  1. ATP - Inventory check Pro - 自客户、sku、权利和其他一切几乎都发生在这里的最佳场所。它就在前面。缺点 - 它没有收货地址，因此需要添加超过 1 个商店的人作为例外导致草率的业务逻辑，可能会定期更改

  2. OrderItemAddCmdImpl 和重载 ExtendOrderItemProcessCmd Pro - 将送货选择带到最前面并控制这里的一切。缺点 - 不确定开销是否会喜欢它。

  3. 在结帐 Pro - 这也将包含所有内容 - 我有点想保留它以用于所有付款处理。通读订单行并使用 SKU 回退错误有点脏。

  4. 让 ERP 处理异常 - Con - 我意识到我们已设置所有订单发货完成，我们将不得不更改这一点并且真的不想这样做，因为对于少于信用额度的费用会有额外的信用卡罚款。

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

4

2 回答 2

0

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

当 orderitems 添加到购物车时，如果超出，查询将返回错误的 item，而不是添加 item。

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

于 2015-03-05T21:42:25.317 回答
0

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

或者

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

于 2015-02-16T02:59:36.593 回答