In this project, we are introducing a new service called item_promotion_business service.
在此项目中，我们引入了一个名为 item_promotion_business 服务的新服务。
In the future, this service will be the entry point (gateway) for external & internal clients to query Product Promo Info (Price / Price+Stock) information.
在未来，该服务将成为外部和内部客户查询产品促销信息（价格/价格+库存）信息的入口（网关）。

Function - This service will function as:
功能 - 该服务将作为以下功能：

1. Facade - to hide the complexities of calculating product promotion info (price / price + stock)
   外观 - 用于隐藏计算产品促销信息（价格/价格+库存）的复杂性
2. Gateway - as the centralized entry point for clients to obtain price information
   网关 - 作为客户端获取价格信息的集中式入口
3. Core Engine - as the main calculator of complex queries and business logic
   核心引擎 - 作为复杂查询和业务逻辑的主要计算器

Scope - the service will only return promotion related information to its clients.
范围 - 该服务仅向其客户端返回与促销相关的信息。

Style - the service will serve requests in terms of scenario_id and client_ids (encapsulated with flow_id).
样式 - 该服务将根据场景 ID 和客户端 ID（封装在流程 ID 中）来处理请求。
The business logic / features to apply / return will differ depending on the applicable scenario_id and client_id passed in the request.
应用的业务逻辑/功能/返回结果将根据请求中传递的场景 ID 和客户端 ID 而有所不同。

We will provide clients with a service & API to provide:
我们将向客户提供服务和 API 以提供：

1. Promotion Information  促销信息
   1. Price  价格
   2. Stock  库存
2. Final Price Information  最终价格信息
   1. E.g. price after voucher & product promo discount
      例如。使用优惠券和商品促销折扣后的价格
3. User Eligibility Check  用户资格检查
   1. This will disable some promotions if the users are not eligible for them.
      如果用户不符合资格，这将禁用一些促销活动。
      e.g.  例如
      1. Live Streaming promotions
         直播促销活动
      2. Exclusive Price promotions
         独家价格促销活动
      3. Welcome Package promotions
         欢迎套餐促销
4. Tax Selection  税项选择
   1. Will apply tax when applicable (based on the default tax requirements)
      适用时将应用税（基于默认税项要求）
   2. total tax  总税额
5. Rebate  返利
   1. product promo rebate  产品促销返利
   2. voucher rebate  优惠券返利
   3. total rebate  总返利

This API will return error when encountering errors from order-critical dependencies (e.g. Price service, Stock service).
当遇到来自订单关键依赖项（例如价格服务、库存服务）的错误时，此 API 将返回错误。
However this API will not return error when receiving errors from other services such as Voucher (display) service → on such cases the service will assume that there are no applicable vouchers for the item / model.
然而，当收到来自其他服务（如代金券（显示）服务）的错误时，此 API 不会返回错误，在这种情况下，服务将假定该商品/型号没有适用的代金券。

Available downgrades:  可用的降级选项：

In order to query the voucher API to get the best recommended vouchers (price after voucher feature), we need to provide voucher with some item basic information and label information.
为了查询代金券 API 以获取最佳推荐代金券（使用代金券后的价格功能），我们需要提供一些商品基本信息和标签信息。
Currently we have several different flows of doing so:
目前我们有多种不同的处理流程：

 According to Listing team:
根据列表团队：

We can give out a new doc to clarify the usage and differences of IIB and IAS next week(before 10 Jan). And before that point, I think u can choose IAS for all scenarios if possible. 
我们可以在下周（1 月 10 号之前）发布一份新文档来阐明 IIB 和 IAS 的使用方法和区别。在那之前，我认为如果可能的话，你可以选择使用 IAS 处理所有场景。

Therefore we should implement the IAS+ITS solution in this project for IPB service, by default.
因此，我们应在此项目中为 IPB 服务默认实施 IAS+ITS 解决方案。
Estimated QPS: refer to Section above: Expected QPS From Clients + Traffic Type
预计每秒请求数（QPS）：参考上方：来自客户端的预期 QPS + 流量类型
Since the estimated QPS is expected to be small, we won't be caching IAS & ITS response in this phase.
由于预计的 QPS 较小，在本阶段我们不会缓存 IAS & ITS 的响应。
We should consider caching the data only when we find it's necessary in the future.
我们应在未来发现有必要时再考虑缓存数据。

The diagram below explains the query logic for IAS & ITS to calculate Price After Voucher:
下面的图表解释了 IAS 和 ITS 如何计算使用优惠券后的价格：

In this project, there is an update to the calculation formula of rebate rate (field name: rebate.rate ).
在此项目中，折扣率的计算公式（字段名： rebate.rate ）有更新。
Previously in the Price Advisor Project, rebate rate is calculated by:
在价格顾问项目中，折扣率是通过以下方式计算的：

This formula can cause inconsistencies for scenes where we're adding back the rebate to the final price.
此公式可能导致在将返利加回最终价格的场景中产生不一致。

After discussion with Price/Calc PM, we received a confirmation so that we update the formula to be:
在与价格/计算产品经理讨论后，我们确认可以更新公式为：

In IPB response structure, we are returning fields called tax.rate and rebate.rate .
在 IPB 响应结构中，我们返回了名为 tax.rate 和 rebate.rate 的字段。
Following the common (and existing) style of rate calculation, IPB will return the rate value inflated by 1e5 (multiplied by 100,000).
遵循常见的（现有的）利率计算风格，IPB 将返回的利率值会膨胀 1e5（乘以 100,000）。
In this case 100% will be 100,000, and 50% will be 50,000.
在这种情况下，100%将是 100,000，50%将是 50,000。
This way, clients can freely decide how to round the values (up to 3 decimal points).
这样，客户端可以自由决定如何四舍五入这些值（最多保留三位小数）。

Tax rate calculation follows the implementation in Price Advisor project, which is also an existing formula since 2023.
税率计算遵循价格顾问项目中的实现，这也是自 2023 年以来现有的公式。

The table below defines the responsibility of each entity in the proposed scene management design.
下表定义了在拟议的场景管理设计中每个实体的职责。