我们遇到了零售POS行业的一个场景，客户只处理MRP。MRP总是包含GST税。

我们知道定价程序是如何运作的。它需要一个基价，然后根据基价计算税金。例如，如果基价是2000，数据更新，税率是28%，那么总金额将是{2000+（2000*28%）}=2560.

我们遇到一个要求，用户只需要输入包含税额的净值，系统必须分别计算税额和基价。例如，大数据数据采集，用户将只输入2560。现在系统将计算2000为基准价，560为税额。系统将发布收入账户的2000金额和税收账户的560金额。

该场景适用于用户不知道基价和税收金额的行业。他们只输入最高零售价（MRP）和税率。他们的期望就像我们的智能SAP系统将自己带来基本金额和税额。因此，用户的基本要求是他们只想维护净金额和税率的条件记录。我们看到很多客户在定价过程中使用一个例程，他们编写代码进行计算，并根据输入的净额和税率修改基数。

据观察，这种方法是一种反向计算。因此，云市场，正常的定价程序步骤将不适用于同样的情况。在这里，让我们介绍一个来自SAP的工具，在这里您可以不使用任何例程和任何编码就获得场景。只需对定价程序进行一些更改，即可进行反向计算。

在开始更改之前，请查看博客文章，了解标准定价程序是如何工作的https://blogs.sap.com/2013/11/27/pricing-procedure-details-and-steps-in-sap-mm/

纳税条件类型变更。需要将税务条件类型的计算类型更改为"H"。可能这是现有系统中的一个问题。此计算类型"H"允许系统进行税务的反向计算。保持所有其他信息不变。

根据您对上述条件类型的要求使用访问顺序。

引入一个新的条件类型，即税务条件类型的反向条件类型。此条件类型是从净额中减少税额值所必需的。此条件类型将携带与上述纳税条件金额完全相同的负金额。条件类型的属性如下：

不要忘记将此条件类型标记为负数。建议使用一个简单的访问序列（例如仅销售组织或销售组织/分销渠道）来维护此条件类型的条件记录，因为我们只需要使条件值与税务条件值相同。

引入另一个新的条件类型作为MRP价格。此条件将作为净额输入。对于此条件类型，系统将计算反向计算。条件类型的属性如下：

根据您对上述条件类型的要求使用访问顺序来维护特定物料代码的MRP（含税净价）。

引入另一个新的条件类型作为基价。此条件类型的值将由系统计算。因此，对于该条件类型，淘客app定制，只需在条件记录中保持100%的as条件值：

请注意：以上所有条件类型仅为示例。如果需要为上述任何条件类型维护不同的属性，允许更改相同的。

现在在定价过程中包括所有这些条件类型，如下：

请注意定价过程中的以下输入（您的步骤可能与上面截图中显示的不同）：

不需要解释其余的步骤，而其余的步骤大体相同。

现在继续创建一个所有这四种条件类型（ZMRP、JOIG、ZRMW和RR00）的条件记录。

ZMRP条件类型创建条件记录为MRP:

JOIG条件类型创建条件记录为tax:

ZRMW条件类型创建条件记录为税额反向，所以维护为100%：

为RR00条件类型创建条件记录为100%，由系统计算：

现在我们设置好了。我们只需要继续创建销售订单。进入项目条件页签：

这里是预期的结果，人工智能是，如要求所述。我想我不需要再解释逻辑：）.

这就是计算类型"H"在特定场景下的工作方式。欢迎提出意见和建议。