大家好，欢迎大家参加今天的 TechTalk 没有站点的软预订功能 和仓库的库存可见性服务。 我的名字是 Hiran Naik，我是 今天将主持本次会议。 本次会议正在代表录制 微软公司在今天的 TechTalk 上的演讲 以及 Microsoft 的所有其他活动。 我们只是想提醒大家庆祝一下 我们的多样性并包容每个参加者 通过意识、友好、尊重、耐心和热情。 为了共同主持今天的 TechTalk，我邀请了 来自库存可见性产品团队的 Jia Cheng Xia 和 Jasmine Ye， 谁将在活动期间帮助解决问答 以及最后剩下的问题。 就这样，我们开始吧。 因此，就议程而言，我们将讨论哪些内容 是库存可见性服务中的软保存吗？ 软装在什么业务场景 可以使用保存功能吗？ 有哪些限制 目前的软保存机制是什么？ 如何使用来解决这个约束 软保存能力有新的增强吗？ 然后我会把它交给贾 Cheng 将带我们了解数据 库存可视性服务中的存储机制，所需的 设置和配置以使用此功能。 然后我们还将使用网站演示软预订 API 有场地和仓库以及无场地和仓库。 最后，我们将分享一些有用的资源来学习 有关此功能的更
多信息，并花一些时间进行问答。 那么我们先来回顾一下什么是软预订？ 在我们详细了解新增强功能之前 在IVS的软预订功能中，让我们快速 回顾一下与此功能相关的一些术语。 软预订是库存可见性中的一个概念 允许预订数量的服务 收到订单时的产品。 例如，从 ecom 网站下订单。 然后请求可以立即发送到 IVS软保留订单数量。 它仍然是软预订，因为它不是 直接进入 Dynamics 365 SCM 并进行预订 ERP是输入的来源。 随后，ecom 订单会同步到 Dynamics 365 SCM 这就是它要做的事情 硬预订和偏移预订。 但与此同时，要准确地了解 现有可用，IVS 中的软预订功能 用于使用软预订功能 IVS，通常设置两种措施。 可以将一项物理测量创建为软保留。 该措施用于软储备 订购数量并提供详细信息 到目前为止，大量数量是软预订的。 另一个度量设置为计算度量 在 IVS 中，通常称为“可用” 预订，意味着可用数量是多少 可以软预订的产品吗？ 当收到订单时，通常是 设置为可用物理量减去任何数量 订单收到时已经软保留 从 ecom 网站同步到 Dynamics 365 SCM。 Dy
namics 中保留订单数量 365 SCM 通常被认为是 预订或硬预订。 最后就是偏移量的时候 软预订的触发也是从 Dynamics 365 SCM 到库存可见性服务。 好的，现在让我们回顾一个业务场景 并了解软预订功能是如何实现的。 目前正在为您提供库存可见性服务 可以看到，我们有三个应用程序。 左边我们有ecom 网站或第三方应用程序。 右侧有 Dynamics 365 SCM 和 中间我们有库存可见性服务。 所以第一步是通过的过程 整合、产品详细信息和定价详细信息已制定 可用于 ecom 网站，以便客户可以 浏览产品并下订单。 此外，之间还有内置集成 Dynamics 365 SCM 和库存可视性服务 从 Dynamics 365 SCM 持续同步库存更改 近乎实时的库存可视性服务。 在本例中，最初有 100 件 适用于仓库一中的产品，该仓库将 同步到库存可见性服务。 接下来，在该过程的下一步中， 新订单数量为 50 个。 然后ecom站点会调用软 预订 API 用于检查是否可以预订 特定仓库中产品的数量。 目前可预约数量 一号仓库有 100 件。 因此ecom网站可以立即软预
订订单数量 该仓库中该产品的数量为 50。 正如你所看到的，软储备措施已经 现在数量更改为 50 个，现在可供购买 一号仓库的预订数量已减少至 50 个。 由于订单数量是软保留的， 预订 ID 被发送回 ecom 网站。 请注意，此 ecom 订单尚未 同步到 Dynamics 365 SCM 并随时可用 Dynamics 365 SCM 中有 100 块。 与此同时，ecom 又收到了一份订单 假设有 50 件。 ecom 网站调用软预订 API 来 检查可预订产品的数量 此时在特定的仓库中。 可预订数量为 一号仓库50件。 因此，电子商务网站可以立即软保留另一个订单 WHS 一个仓库中该产品的数量为 50 个。 现在你可以看到软储备措施已经 数量变更为100个并可预订 一号仓库数量已减少至零。 软预约成功的ID 预订将返回至 ecom 网站。 这样，软预留能力 可以提供可用的准确视图 收到订单时库存。 在此过程的后期，ecom 订单 同步到 Dynamics 365 SCM。 因此，当订单行同步到 ecom 网站时， 它将包含预订 ID 的详细信息， 库存维度，例如站点和仓库，其中
订单数量已被保留，并将 为每个销售订单行存储。 在 Dynamics 365 SCM 中，当订单行为 保留或硬保留，通过自动保留 或分布式订单管理或可能发布到 仓库流程 Dynamics 365 SCM 将发送偏移量 立即向库存可见性服务提出预订请求。 因此，在这种情况下，偏移保留标准有 匹配产品、预订 ID，以及 库存维度，即场地和仓库 其中订单数量是软保留的。 所以希望这个流程能给你带来 对软预订的理解 库存可视化服务能力。 现在让我们了解什么是约束 在这个过程中又如何不软保留 场地和仓库将为我们提供更大的灵活性 来克服一些限制。 我们将再次举类似的例子 我们在上一张幻灯片中回顾了。 所以最初，正如你所看到的，手头上的是 110横跨两个仓库，一号仓库和二号仓库。 第一份订单已收到 50 件。 对照仓库一进行检查。 100 件可以预订，所以 50 件 件将被软保留并可供预订。 现在 1 号仓库有 50 件。 收到第二份订单，数量为 60 件。 所以在这种情况下，请现场检查 一号仓库有 60 件。 但仅有 50 件可供选择 预约一号仓库。 由于可用数量不足 对于预订，请求将失败。 同
样，假设收到了 60 件的第三份订单， 检查二号仓库现有 60 件。 不过仅有十件可供选择 预约二号仓库。 由于可用数量不足 对于预订，请求应该再次失败。 但是，如果您同时可以预订 仓库，则可以满足订单数量。 为了解决这种情况，我们有 软预留功能的一些新增强。 那么让我们回顾一下增强功能如何 到软预订会有帮助 我们讨论过的一些限制。 所以如果你再次看到这个例子，手头的初始值 跨两个仓库（仓库一和仓库二）的值为 110， 收到的第一份订单为 50 件。 通过此功能，可以检查 手头发生跨仓库的情况。 所以共有 110 件可供选择 储备，其中50个数量将 已预订且现在可供预订的将是 两个仓库共 60 件。 收到第二份订单 60 件 检查仓库中现有的 60 件物品， 60件可供预订。 因此另外 60 个数量将被软保留 而现在可供预订的数量将为零。 正如您所注意到的，这些新的增强功能允许查询 产品层面的现有和软预订与 在前一种情况下，它允许现场查询 以及针对特定地点和仓库的软储备。 现在让我们经历同样的事情 我们之前看到的新业务场景 增强交换预留并确定 工艺流程的差异。 同样，我们有三个应用程序
ecom 网站， Dynamics 365 SCM 和库存可视性服务。 产品和定价详细信息可提供给 ecom网站以便客户可以浏览 产品并下订单。 Dynamics 365 SCM 之间的内置集成 库存可视性服务将持续同步 Dynamics 365 SCM 中的库存变化 库存可见性服务。 请注意，此处有 100 台 PC 可用于某个产品 仓库 1 中有 10 台 PC 存在于仓库 2 它将同步到库存可见性服务。 接下来，收到 50 个数量的电子商务网站的订单 调用软预订API来检查可用的 用于跨仓库产品的预订数量。 使用这些新的增强功能 时间、可预约数量为 两个仓库共 110 件。 ecom网站可以即时软预订订单 一种产品的数量为 50 个。 测量的软储备现已更改为 50 数量 可供预订数量减少至60个 如果你跨仓库查询手头的东西。 接下来，预订 ID 是 返回ecom网站。 ecom订单还没有同步到D 365 手头还有110件 跨两个仓库的 Dynamics 365 SCM。 与此同时，ecom 又收到了一份订单 假设有 60 件。 ecom网站会调用软预订 用于检查可用的 API
该产品在各个仓库的预订数量。 目前可预约数量为 60 件，所以 ecom 网站可以软预订 该产品的另一份 60 份订单。 软储备措施现已更改为 110 数量和可供预订的数量减少至 数量为零，软预订 ID 为 返回网站。 接下来，ecom 订单将同步到 Dynamics 365 SCM。 当订单行从 ecom 网站同步时， 将包含预订 ID 的详细信息 从每个销售订单行存储。 这就是你会注意到的差异 当订单行同步到 Dynamics 365 时 SCM，只有预订 ID 才会成为其中的一部分 消息而不是库存尺寸。 这是你的第一个区别 将在 Dynamics 365 SCM 中注意到。 当订单行通过硬保留时 自动预留或 DOM 或 RDW 流程 将针对特定仓库进行保留。 但是，当 Dynamics 365 SCM 将发送偏移量时 向IVS请求预订，它找到预订 基于预订 ID 和产品。 因此在这种情况下保留标准的偏移量 仅检查产品和预订是否匹配 ID 与库存尺寸不再匹配， 前面的场景就是这种情况。 当订单量偏软时 保存在仓库级别。 所以希望这能让你理解结局 结束流程以及新的增强功能如何 软预订
功能，如何查询 手，如何软储备并最终抵消 产品级别的预订。 接下来，我现在就交给嘉诚 分享一些更详细的数据 分区设置和配置以及演示此功能。 Jiacheng over to you. 谢谢希兰。 我现在将接管剩下的事情 TechTalk 介绍如何配置库存 可见性服务也可以进行软预订 当其他库存发生变化时，无需指定 整个过程中的场地和仓库。 首先，我们首先介绍一下 库存可见性服务内的数据存储规则。 我们称之为数据存储规则或 分区规则描述数据如何 分组在库存可见性服务内。 如您所知，在库存可见性中 服务缓存，当前正在存储数据 作为库存可见性服务过去有 要求每个变更操作都需要仓库， 包括软件预约、库存变更等 作为分配 API 请求。 其根本原因是为了性能 担心，我们需要以某种方式将数据分组在一起 并将它们放入不同的实例中以最小化 访问该数据的时间并支持 用户需要同时进行库存操作的场景 有和没有仓库。 我们现在推出一组新的 库存可视性服务内的数据存储规则 我们称之为购买产品 ID。 所以现在我们有两个不同的 数据存储规则的类型。 现有方式是购买仓库，新建 方法是做副产品ID，如果你使用 新添加
的按产品分组的数据存储方式 作为站点和仓库的 ID 不再是主要的 您需要查找数据所在位置的键 定位后，不再需要进行库存更改操作。 请注意，这将是一个全局设置 将确定数据的存储方式，因此 您不能在这两种机制之间进行交换 系统上线后。 为了做出改变，你只需要清理 所有数据并从头开始同步数据。 在 TechTalk 的其余部分中，我们将 仔细查看场景以了解发生了什么变化 通过使用这两种类型的数据存储规则。 首先，我们将介绍配置 切换数据分区规则的过程，所以 我们将很快推出新页面 它设置分区配置。 将有两个选择。我们可以选择。 第一个，也是现有用户的默认值 将按位置，即按仓库 动态 365 SDM 上下文和我们的另一个上下文 如果我们想进行软预订，则需要采取 无场地、无仓库，按产品ID使用。 在从 Powerapps UI 更改此设置后，我们 对于所有其他配置表，我们需要 更新配置以使此更改生效。 这里需要注意的是，要更新到 按产品 ID 进行新分区，不应有 该环境中的任何现有库存交易。 为了在您的环境中实现此功能，我们 需要根据数据做出决定 存储或分区规则，按仓库或 通过产品 ID 开头 基
于业务需求的集成过程。 所以切换数据分区会 要求完全清理库存数据 将演示的 IVS 环境。 我们很快就会做一个演示， 但不需要清理配置。 然而，这两种数据存储规则之间的热插拔是 暂时不支持，也就是说唯一的办法 改变规则就是清理所有的 清点数据并重新开始数据传输。 这是该版本中的公共预览功能 2024 年 4 月，如果您想要私人 在模具时间之前预览，您可以联系我们 用于获取私人预览说明的群组电子邮件 请继续关注 YAML 帖子和 有关此功能的更多详细信息，请参阅文档。 此功能的计划正式发布时间为 7 月 2024 年，让我们回顾一下我们如何 在新引入的 UI 中更改数据分区规则。 会有一个data分区的条目 导航栏中的规则，我们需要 更改双位置副产品 ID。 但是，如果用户正在进行更改或 还有库存的时候误改了 数据存在，则更改不会生效。 当我们更改配置并存在数据时 并更新配置，我们会在那里找到 是配置更新的验证异常 说我们无法更改分区配置 当环境不为空时。 如果您看到此数据并相信正在改变 分区配置仍然是你想要的 做，你需要做的就是去 返回 Powerapps UI 并转到管理员 设置，点
击管理按钮，删除所有库存 数据并遵循随后提供的说明 用户界面，然后验证是否 配置更新成功。 您可以使用邮递员 API 来获取最新的 配置以查看它是否已按产品更改 ID 或根据您选择的位置。 如果您确实看到变化正在发生， 这意味着分区配置已成功更新。 因此，通过介绍我们如何能够 更改我们将要经历的分区配置 我们如何制作软体的演示过程 没有场地和仓库的预订并进行比较 我们现有的做法 拥有场地和仓库。 我们将使用与 Hieron 相同的示例 在本次会议的几分钟前做了。 所以让我们假设我们正在使用 产品 T 恤，我们有两个仓库。 在一号仓库我们有 100 件 T 恤 在二号仓库，我们有十件 T 恤。 相应地，我们将前往 通过以下场景。 首先我们来比较一下 我们正在预订有或没有仓库 以及这些预订机制中的每一个。 预订后我们将使用库存查询 看看数据分区规则如何 会影响查询行为。 我们要使用的公式是 可预订数量等于初始可用数量 我们为这两个仓库添加的数量。 减去软储备数量 所以回忆一下现有的方式。 当我们进行软预订时，我们会进行库存更新 或者我们对场地和仓库进行分配。 在当前设置下，库存可见性服务将
需要用户指定站点和位置 当他们进行库存变更时。 在 UI 的这个示例中，我们预订了 50 件 T 恤。 一号仓库里。 预约成功，人数为50 剩余件数可在仓库 1 中保留。 这是软件的 API 请求保留的内容 站点一和仓库一的样子。 我们从唯一的 Id 开始来标记这个 是一个新请求，我们指定一个组织 ID USMF 的数据区 id 是动态的 365供应链管理，我们指定产品ID。 最重要的是，在尺寸领域，我们 需要指定具体地点和 仓库 ID 和位置 ID。 我们不能让它们空着。 之后我们也指定预留50个数量 作为自我保留的数据源和修改器。 为了不保留超过 仓库有货，我们需要标记 如果检查可用于保留字段为 true。 这就是我们自助预订的流程。 我们从配置开始并注意到 可以预留计算量度。 我们必须看到计算测量的细节。 这意味着我们首先添加 IV 然后减去 IV 的保留 从数据源 IV 中软保留。 由于我们要预约，所以我们首先 为 T 恤添加手部。 我们为一号仓库添加 100 件， 我们将为二号仓库添加十件。之后。 由于我们只需要链上质量公式，因此我们 将省略其他措施的字段。 现在我们可以看
到这 100 件 成功了，我们把十件换成仓库工具。 现在我们从同一个例子开始 与刚才介绍的例子相同。 我们将进行预订。 请记住，我们需要指定站点 ID 和本例中的位置 ID，因为我们的系统是 仍配置为按位置 ID 存储数据，并且 我们对 IV 进行软预订和软预订 并检查可预订的情况。 在这里我们可以看到 50件预约成功。 现在我们将尝试再进行 60 个预订。 由于我们不想指定仓库一或 二、我们去删除站点和仓库ID 我们要求看看会发生什么。 它会说如果有零 可供预订的数量不够。 所以你可能注意到的一件事是 这里的软预订还有60件 可用，但当我们进行 60 预订时， 会说 Python 仓库中可用的为零。 那是因为我们正在配置一个 按位置 ID 存储数据的系统， 我们稍后会讲到。 现在让我们看看如果我们 切换数据存储机制购买产品ID 无需场地和仓库即可预订。 所以我们从同一个例子开始。 这里唯一的区别是 我们要离开现场和地点。 我们没有指定站点和位置 ID，并且如果 我们这里订的是50件，一定会成功的。 差异在于现有的结果。 如果我们改变数据存储规则并且是 不指定仓库，IVS系统 不会自动
为我们选择仓库。 而是会暂时 存储预订结果。 在空荡荡的仓库里，你有 50 个 预留 50 和 -50 可用。 我们将对同一产品进行求和。 在所有这些结果中我们将看到 有 50 个保留和 60 个可用。 60 来自 110 可用 从两个仓库减去 -50 从临时结果中可以看出。 那么API请求方面有什么区别呢？ 当我们使用 和 进行软件预订时 没有仓库，我们可以从这个页面看到 其他字段是相同的，除了 尺寸字段中的尺寸。 如果我们尝试在没有网站的情况下进行预订 和位置 ID，我们只是简单地不指定它们。 我们将他们排除在我们的请求之外。 这是预订后的流程 50和60这两个阶 每个都相应地没有指定周期。 仓库我们从现有的两个仓库开始， 一号仓库有 100 个，二号仓库有 10 个。 第二步，我们预留50个无仓库。 所以总和结果将是 50 储备金 60 个可用，我们要预订 60 个 又没仓库了，还有110 在这种情况下可用保留和零。 所以请注意，这里的关键要点是 如果我们试图做一个 无场地、仓库的软预订，然后库存 可见性服务永远不会为我们决定。 它会将其留空。 再次让我们看一个邮递员的例子 看看
软预订如何不如何 无需站点和位置 ID 流程的软预订即可工作。 所以我们省略了刷新的过程 数据以及设置配置。 所以如果我们删除这里的尺寸， 我们会发现预订确实成功了 50 件和 60 件。 那么如果我们进行事件树查询，结果会是什么呢？ 在这种情况下，因为我们没有 不再按仓库对数据进行分组，我们 可以进行两种不同类型的查询。 第一个是查询总库存 无需按现有站点和仓库进行分组 通过仓库ID存储数据的方式。 我们会在没有情况下进行库存查询吗？ 按站点和位置 ID 指定组？ 按站点位置 ID 分组始终是强制性的，但是 在我们的例子中，我们可以注意到有 尽管有多个仓库，但只有一个结果。 所以通过将数据切换到新分区 ，我们可以发现系统会 将来自不同站点的所有结果汇总在一起 仓库，并且我们可以选择添加回该组 通过站点和位置 ID 的值。 然后它会呈现几乎相同的 与我们相同的结果 仓库的存储规则。 正如我们在本例中看到的，我们有三个 不同的结果，结果的三个不同条目。 前两个是现有的 对应仓库一和二，并且 最后一个用于存储临时结果 进行没有仓库的子预订。 所以这里需要注意的一个细微差别是 默认查询行为在
我们之后发生了变化 切换数据分区规则。 如果我们使用 by 仓库 我们所有现有的用户都在使用 库存查询将始终按以下条件对结果进行分组 站点和仓库，尽管用户可能不 在查询中指定分组依据值。 但是，通过使用产品 ID，查询将不会 默认情况下按站点和仓库进行更长的分组。 用户需要添加按值分组 自己明确地使用同一组 像他们一样通过场地和仓库能力 对于按仓库对数据进行分组的情况。 那么，简单比较一下API请求的差异 按仓库和副产品 ID 存储数据 我们正在比较四种不同类型的操作。 第一个是没有产品ID的情况下查询现有产品。 在按仓库的情况下，我们支持这一点 将返回结果的查询类型 同一仓库中的所有产品。 但是，对于副产品 ID，由于 数据存储，主要按产品 ID 分组， 必须指定产品才能进行库存查询。 接下来，我们将比较查询 手头上没有场地和仓库。 正如我们在 最后一页，它们都受支持。 唯一的例外是，在以下情况下 副产品 ID，用户可以控制是否 想要按站点和仓库对数据进行分组。 在我们展示的预订案例中 我们的演示，在按仓库的情况下，用户总是 需要指定仓库，但是在副产品中 我们为用户提供的灵活性不 保
留到混凝土仓库。 但请注意，预订总是在 特定的产品 ID，因此您需要指定 这两种情况下的产品 ID。 介绍完这些功能之后，我们就来过一遍 关于该做和不该做的一些最佳实践建议。 当你实施软 使用库存可视性服务进行预订，最 要记住的重要一点是 切勿提出混合预订请求。 例如，我们这里有一个反例 一号仓库有 100 个可用库存 仓库二号有十个可用。 第一个预订将遵循我们的 没有仓库的情况下进行预订的示例。 所以在预订结果中我们会看到 有一个空仓库正在使用 主要用于存储预订数据。 将会有50个储备金 我们的仓库总共有 60 个可用。 不过，我们可以进行第二次预订 一号仓库有 100 件。 它会成功的。 它会成功的原因是 为了尽量减少搜索时间，我们总是 检查是否可以预订 指定的最具体的库存尺寸。 因此，如果用户指定他想要 预订一号仓库，则仅 可在仓库一进行预约检查。 然而，在这种情况下，存在负数 空仓库可预留 50 个 不会在此考虑 情况，所以它也会成功。 但如果我们回过头来考虑 实际业务场景，仅剩60块 在可以预订的仓库中。 造成这种冲突的原因是用户 先预约无仓库，再预约 指定具体仓库的预订。
由于 IVS 的做法， 我们不能让用户进行混合预订。 所以我们应该时刻记住这一点 当我们执行的时候，我们不应该 对同一商品进行混合预订。 用于软预订的库存维度 中的每个项目应该一致 同一个公司的系统。 最佳实践建议的另一个主题是 考虑对数据存储规则进行偏移 动态 365 供应链管理中的产品 ID 要求进行预订抵消的原因 在当前系统的同一个仓库中是 需要软预留请求和偏移请求 位于同一分区中。 但是，如果我们改变数据分区规则 到副产品ID，那么基本上都是一样的 产品 ID 将转到同一分区。 所以预订请求和偏移请求，如果它们 拥有匹配的预订 ID 库存可见性服务 将能够将它们匹配在一起。 例如，在更复杂的情况下 我们动态地确定和更新销售线 运行其他工具后进行 365 供应链管理，例如 Dome，该场景仍将支持 根据产品 ID 和预订 ID 进行偏移预订 根据副产品ID的数据存储规则。 所以这些就是我们的内容 今天打算介绍一下制作软件 未指定库存可见性服务的预订 站点 ID 和仓库 ID。 请注意，此更改适用 也适用于其他库存操作。 您可以通过以下方式找到更多参考 此页面上的链接。 首先，请继
续关注我们的 Microsoft 文档，该文档将 向您展示最新的使用说明 当该功能发布时，我们有此功能 库存可见性的示例代码添加在 显示此页面的 GitHub 存储库链接。 您可以访问我们的存储库并下载 您可以使用 open 来玩的示例 源码工具，你可以找到以前的 TechTalks 和 Microsoft Dynamics 块。 另外，请加入我们的 Yammer 小组，了解财务和 运营和库存可见性渠道也是如此。 如果您对我们有任何意见，请随时留言 向我们发送电子邮件、在 Yammer 组中发帖或访问 在创意网站上投票以询问功能 您相信会解决您的问题。 这就是今天TechTalk的内容 我们正在经历的会议。 问答谢谢嘉诚 我只是 我想宣布几件事。 嘉诚今天展示了以下能力 他正在更新配置的演示 通过 postman API 进行分区。 但是什么时候会公开预览以及什么时候 是Ga，你应该能够改变 通过用户界面进行配置 您的方式 今天在库存可见性服务应用程序中执行此操作。 但这目前处于私人预览阶段，所以 所有保存检查、库存检查 手头还有换分区 一切仅通过 API 发生。 所以如果你想尝试这个
私人预览版您将必须使用 API。 但当我们进入公开预览版时 GA 您将拥有一些能力 也可以从用户界面执行此操作。 用户界面部分仍在开发中， 所以我们会在准备好后宣布它。 我们收到了一些问题。 我就过去一下。 我们已经回复了我认为最多的 但无论如何我们都会经历。 所以我们收到的第一个问题是 如果在订单一和订单二之后发生 放置SMB直接在FNO保留相同的货物 我想茉莉已经做出了回应。 如果有其他订单直接在印度收到 365 单片机的话基本上开箱即用就可以了 D 365 SCM 中的软预留能力。 如果您使用该功能，基本上当您尝试时 在 D 365 SCM 中软保留，它将 检查您的 IVS 的可预订情况。 如果已经完成软预订并且有 手头上的资源不够，它会限制你 在D365 SCM中进行软保留。 这是开箱即用的功能。 因此，如果您遇到这样的情况：您的订单 来自多个渠道，也许来自网站，您 也在从 D 365 创建订单，并且您 仍然想要软预订入住 放置，然后您就可以开箱即用 D 365 中的软预留功能。 好的，所以我想下一个问题是 SCM 将收到每条线路的预订 ID， 但没有库存尺寸和仓库。 因此，
接下来由 SCM 决定 来决定分配哪个仓库。 是对的吗？ 是的，这才是正确的理解 您在以下位置预订的新功能 库存可视性服务中的产品级别。 这样您就会获得预订 ID 以及预订时间 您的订单从 ecom 网站或第三方同步 方应用程序到销售订单行，您基本上将 携带预订ID，您将不会有 在这种情况下的任何库存尺寸，因为您有 针对产品 ID 本身保留。 然后当创建销售订单行时 在 D 365 中，并且 DOM 处理或释放到 仓库流程，无论您使用什么机制 D 365 SCM 用于硬预订。 届时将分配实际仓库。 基本上只要硬 预约完成，也会触发 库存可见性服务中的偏移预留。 所以基本上它会使用产品ID 和预订 ID 组合来抵消预订。 它将不再与库存匹配 用于抵消预订的尺寸。 希望这是有道理的。 下一个问题是，可以在不同的实体仓库吗？ D 365与IVS联动，实现软预约 可以跨实体和仓库完成吗？ 对此，茉莉花已经做出了回应。 您当然可以同步所有库存 跨不同法人实体和不同仓库的数据。 但是，您只能查询 针对同一特定法人实体中的仓库。 所以你还是要指定法人实体 以便跨仓库查询现有的ID。 手头无法查询 跨
法人实体的仓库。 组织 ID 或法人 ID 仍为 查询和预订的主键之一。 那么下一个问题就是预订 正在使用销售订单行？ 其他类型怎么样 交易、库存日记帐？ 茉莉，你想回答这个问题吗？ 是的，我想对于软件预订场景 它正在处理销售订单行并且 关于其他类型的交易。 我们现在确实有正在处理的工作项目。 这是关于调整日记账的，会有更多的交易 即将推出的类型，但它们将被计划 并将逐步推出。 再说一次，如果任何交易类型非常 对于您的场景解决方案很重要，请随意 在创意门户上创建创意。 所以我们会一起规划优先事项 根据投票结果与 PM 团队合作。 谢谢茉莉花。 所以，是的，我们肯定有软预订。 销售订单行库存调整日记帐是这样的 我们已经在努力了，但是如果你 还有其他期刊的要求吗 如果有想法或帖子就太好了 您对 YAML 渠道的疑问或反馈。 下一个问题是can d 365 cm 利用任何软预订 可用库存需要自动预订吗？ 或者有没有 D 的路线图 365厘米库存调用直接打IVS API？ 我想我们已经讨论过这个问题了。 这与您的订单类似的情况 来自多个渠道，在本例中 订单来自电子商务，或者如果您是 直接将订单
输入 D 365 cm，您 需要 D 365 cm 的软预留能力。 然后就可以使用软预订了 开箱即用的功能实际上可以 支票可用于 IBS 预订。 所以如果没有足够的可用 就手头而言，你基本上会受到限制。 您可以设置您想要的继续方式，无论您 想要受到限制或者您仍然想预订。 这些就是可用的功能 还有一个很好的文档。 所以希望你能满足这个要求 应该能够利用这种能力。 是的，我想对此还有一个评论是 我认为销售订单已经实施了 盒子，我们确实有一些客户。 我确实收到了一些反馈 合作伙伴谈话说他们有 转移单的类似要求。 非常相似，但今天却不同了 概要中开箱即用。 再说一次，如果你需要的话 需要写一些定制。 但如果您希望它不被实施。 创造一个想法，这样我们就可以 根据得票数来计划。 是的，听起来不错。 ISV 是开箱即用的吗 与微软电子商务解决方案集成？ 你想拿这个吗？ 是的，如果这是关于 D 365 商务，对吧？ 是，对的。 是的，如果是这样的话，我们已经 今天已经有了开箱即用的集成。是的。 所以基本上对于 D 365 commerce 后台负责财务和运营。 所以从后台 立场一切保持原样。 您将整合
库存 与后台的可见性服务。 但我们确实有能力， CSU 的新功能。 所以你应该可以在手头查询 直接来自 CSU 库存可见性服务，您应该 可以为您做预订 应该可以做软保存和所有 来自科罗拉多州立大学的这些能力。 我们有关于此功能的良好文档。 所以请检查一下。 但是，是的，开箱即用的集成 适用于 43 65 商业。 是的，我想今天已经是 商业的公共预览功能。 您可以继续查看文档 在那里并启用该功能。 启用后，库存检查 以及CSU背后的库存调整 实际上已经与IB整合了。是的。 好的，我想我们已经回答了所有问题。 请随时发布您仍然有的任何问题或 您可以随时通过 yammer group 与我们联系。 但我想如果没有更多的话 问题然后我们可能会结束今天的会议。 谢谢我们的主持人和我们的 观众参与您的反馈。 您的反馈非常非常重要。 至此，我们将结束本次会议。 再次感谢您并祝您度过愉快的一天。
Comments