相关推荐

• 产品使用手册

  元数据在线发布（5.1.0及以上版本）

  一 产品功能说明 1. 设计同步部署 设计同步部署功能实现不同环境设计数据一键同步的目标，即将A环境设计完成的模型、界面、等设计数据一键部署至B环境。 使用此功能，需要在‘应用中心’安装‘应用环境’： ‘应用环境’安装完成，进入发起同步部署环境——>业务应用——>‘应用环境’，对要进行快速部署的发起环境、目标环境进行配置： 在进行多个环境同步部署设计数据时，必须正确配置发起环境、目标环境。 完成配置后，在应用中心，选择目标‘已安装’应用，在操作下拉菜单选择待部署设计类型，即可按照指引完成操作： 2. 设计导出 设计导出功能具备将已安装应用所属（应用技术名称）设计元数据，如模型、界面、流程、集成设计、数据可视化导出为json文件的能力，具备筛选导出、一键导出两种方式以满足不同业务场景需要。 目标是实现在多个环境通过技术接口调用、或通过应用中心导入界面完成导入，使设计元数据在不同环境之间快速迁移同步： 因平台允许多个应用名称相同，能够唯一定位具体应用使用的是‘应用技术名称’，因此识别应用标识的依据为应用技术名称。 3. 设计导入 3.1. 迁移导入 对于已导出设计元数据json文件，如果导出类型为‘迁移导出’，可以在不同环境，通过应用中心——>已安装应用——>设计导入（迁移），实现设计数据导入： 3.2. 标品导入 对于导出类型为‘标品导出’的设计元数据，目前只支持通过技术接口形式完成导入，暂不支持界面进行可视化导入操作。 4. 导出导入任务 不同环境设计元数据以导入json文件方式进行迁移的基础是设计导出，基于界面导入实现设计元数据在不同环境进行迁移场景、或通过技术接口导入以实现标品升级的场景，存在导出类型为迁移导出、标品导出的区别。 使用此功能的操作者需要依据实际需求场景进行相应导出类型的选择。 4.1. 导出任务查看 对于已经执行导出的任务，可通过‘应用环境——>设计导出’查看导出任务信息： 4.2. 导入任务查看 对于已经执行导入的任务，可通过‘应用环境——>设计导入’查看导入任务状态、进度、详细信息： 5. 部署任务 部署任务功能用于查看设计数据同步部署功能任务状态、详细信息；分为发起环境任务查看、目标环境任务查看。 无论是发起环境，或是目标环境，均通过所属环境‘应用环境’中‘部署任务’功能进行查看： 二 产品功能操作手册 1. 设计导出 1.1. 环境迁移导出 点击‘业务应用——>应用中心’，进入应用中心，默认显示‘应用列表’标签页： 选择‘已安装’应用——>操作，出现操作菜单： 选择‘设计导出’，显示支持导出的各设计项： 1.1.1. 模型导出 操作菜单选择‘模型导出’： 打开模型导出信息弹窗： 在弹窗页中存在要素信息项及操作项： 导出类型：选择‘迁移导出’。 文件名称：默认为‘应用名称+设计类型’。 导出模式：异步模式，不可修改。 导出格式：JSON文件，不可修改。 一键导出：操作项，直接导出当前应用下的所有无代码模型，不需要筛选。 筛选导出：操作项，进入无代码模型导出筛选页，选择要导出的设计数据。 1.1.1.1. 一键导出 点击‘一键导出’，关闭弹窗，回到应用中心，右上角出现导出进行中提示信息： 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.1.1.2. 筛选导出 点击‘筛选导出’，进入无代码模型导出筛选页： 筛选页面按照‘模型类型’、‘可用/废弃’、‘来源’选择或输入查找条件，点击‘搜索’，进行条件搜索，查找满足条件无代码模型： 点击‘重置’按钮，清空已输入查找条件： 点击列表标题栏勾选框，可进行全选/取消全选操作，全选——选择全部模型，取消全选——取消所有已勾选项： 勾选要导出模型，点击‘导出’按钮： 回到应用中心，右上角提示导出信息： 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.1.2. 界面导出 ‘业务应用——>应用中心’，进入应用中心，选择已安装应用——>操作——>设计导出——>界面导出，弹出界面导出信息项弹窗，‘导出类型’选择‘迁移导出’： 1.1.2.1. 一键导出 点击‘一键导出’，关闭弹窗，回到应用中心，右上角出现导出进行中提示信息： 界面导出会将所选菜单项、菜单目录路径、菜单绑定页面、页面使用的自定义组件全部导出为json文件。 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.1.2.2. 筛选导出 点击‘筛选导出’，进入应用环境——>界面导出筛选页面，显示当前应用下所有菜单项： 查询项‘菜单名称’输入名称，点击‘搜索’按钮，进行模糊查找匹配的菜单项： 点击‘清除’按钮，清除已输入的查询内容： 勾选菜单项后，点击‘导出’按钮： 回到应用中心页面，同时页面右上角提示导出进行中信息： 界面导出会将所选菜单项、上级菜单目录项、菜单绑定页面、页面使用的自定义组件全部导出为json文件。 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.1.3. 流程导出 点击‘业务应用——>应用中心’，进入应用中心，选择已安装应用——>操作——>设计导出——>流程导出，弹出导出信息弹窗： ‘导出类型’选择‘迁移导出’。 1.1.3.1. 一键导出 点击‘一键导出’： 关闭弹窗，回到应用中心，右上角出现导出进行中提示信息： 一键导出流程数据会按照应用技术名称，将当前应用下所有流程、元数据、涉及的业务数据如审批用户、角色等全部导出为json文件。 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.1.3.2. 筛选导出 点击‘筛选导出’： 进入流程数据筛选页面，显示当前应用（技术名称）下所有已发布流程： 支持按照流程名称（模糊匹配）、触发方式（模型触发、定时触发、日期触发、子流程）进行筛选；输入筛选条件，点击搜索按钮，查找匹配结果： 点击‘清除’按钮，清空筛选内容： 勾选列表流程项，点击‘导出’按钮： 返回应用中心，同时页面右上角提示导出信息： 流程导出会将应用（技术名称）下的所有已发布流程及相关元数据、业务数据全部导出为json文件。 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.1.4. 集成导出 点击‘业务应用——>应用中心’，进入应用中心，选择已安装应用——>操作——>设计导出——>集成导出，弹出集成导出信息项弹窗，‘导出类型’选择‘迁移导出’： 1.1.4.1. 一键导出 点击‘一键导出’，关闭弹窗，回到应用中心，右上角出现导出进行中提示信息： 一键导出集成数据会按照应用技术名称，将所有已发布数据流程；以及所有已启用连接器（与应用无关）、已启用开放接口（与应用无关）全部导出为json文件。 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.1.4.2. 筛选导出 点击‘筛选导出’： 进入集成数据筛选页面，默认显示‘连接器’标签页——>应用（已启用）数据项列表： 可选项： 连接器：应用（已启用状态）、数据库（已启用状态）、与应用无关。 数据流程：已发布状态，且属于发起导出应用（技术名称）下的数据流程。 开放平台：API接口（已启用状态）、与应用无关。 以上各项在列表中展示的数据均可勾选并支持导出为json文件： 勾选列表数据项，点击‘导出’按钮： 回到应用中心，右上角显示导出提示信息： 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.1.5. 数据可视化导出 点击‘业务应用——>应用中心’，进入应用中心，选择已安装应用——>操作——>设计导出——>数据可视化导出，弹出数据可视化导出信息项弹窗，‘导出类型’选择‘迁移导出’： 1.1.5.1. 一键导出 点击‘一键导出’： 关闭弹窗，回到应用中心，右上角出现导出进行中提示信息： 一键导出数据可视化会将所有已发布图表（含路径目录）、报表（含路径目录）、数据大屏（含路径目录）、图表模版全部导出为json文件。 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.1.5.2. 筛选导出 点击‘筛选导出’： 进入数据可视化筛选列表页面，默认显示‘图表’标签页，并展示已发布图表数据项列表： 标签页： 图表：显示所有已发布状态图表，以树形结构展示，支持按照‘图表名称’模糊匹配查找。 报表：显示所有已发布状态报表，以树形结构展示，支持按照‘报表名称’模糊匹配查找。 数据大屏：显示所有已发布状态数据大屏，以树形结构展示，支持按照‘数据大屏名称’模糊匹配查找。 图表模版：显示所有图表模版，列表形式展示，支持按照‘图表名称’模糊匹配查找。 勾选列表数据项，点击‘导出’按钮： 关闭弹窗，回到应用中心，右上角出现导出进行中提示信息： 筛选导出数据可视化数据会将所有已发布图表（含路径目录）、报表（含路径目录）、数据大屏（含路径目录）、图表模版全部导出为json文件。 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.2. 标品导出 点击‘业务应用——>应用中心’，进入应用中心，点击‘应用列表’标签项；选择‘已安装’应用，点击操作，出现操作菜单： 选择‘设计导出’，显示支持导出的各设计项： 1.2.1. 模型导出 点击‘业务应用——>应用中心’，进入应用中心；点击已安装应用——>操作，出现操作菜单： 选择‘设计导出——>模型导出’： 打开导出信息弹窗： 1.2.1.1. 一键导出 导出过程同《1.1.1.1 设计导出/环境迁移导出/模型导出/一键导出》，区别是标品导出json文件无法通过前端页面导入其它环境，只能通过技术接口导入。 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.2.1.2. 筛选导出 导出过程同《1.1.1.2 设计导出/环境迁移导出/模型导出/筛选导出》，区别是标品导出json文件无法通过前端页面导入其它环境，只能通过技术接口导入。 导出任务状态信息、导出任务详细信息查看方式参见《1.3 设计导出/导出任务查看》。 1.2.2.…

  萧炎

  2024年9月2日

  683000
• Oinone 7天入门到精通

  5.1 CDM的背景介绍

  如果说低代码开发框架输出技术标准，CDM则是结合oinone技术特性和软件工程设计，让输出数据标准变成可能。 一、背景介绍 无法照搬的最佳实践 要了解引入CDM的初衷，得从互联网架构的演进开始，了解其过程，就知道为什么说Oinone的CDM是中台架构的最佳技术实践的核心！我们在2.2【互联架构做为最佳实践为何失效】一文中介绍过互联网技术发展的四个阶段，特别平台化到中台化的阶段，目的是在一套规范下让听的见炮火声音的团队自行决定业务系统发展，适用多业务线（或多场景应用）独立发展。 互联网架构在演进过程中碰到的问题跟企业数字化转型过程中碰到的问题是非常类似： 随着企业业务在线化后对系统性能、稳定都提出了更高的要求，而且大部分企业的内部很多系统相互割裂导致，导致很多重复建设，所以我们需要服务化、平台化。 同时没有一个供应商能解决企业所有商业场景问题，又需要多个供应商共同参与，所以把供应商类类比成各个业务线，在一套规范下让供应商自行决定业务系统发展 既然跟阿里当初在架构演进过程中碰到的问题非常类似，那么是不是照搬阿里中台架构方案到企业就好了？当然不是，因为历史原因阿里的中台架构是采用的平台共建模式：“让业务线研发以平台设计好的规范进来共同开发”，其本质还是平台主导模式，它是有非常大的历史包袱。我们想象各个供应商的共建一个交易平台或商品平台，那是多么荒唐的事情，平台化已经足够的复杂了，还让不同背景、不同企业的研发一起共建，最后往往导致企业架构负载过重，这时对企业来说便不再是赋能而是“内耗”。 那么如果没有历史包袱，我们重新设计，站在上帝视角去看有没有更好的方式呢？当然有 借鉴微软的CDM 这里我们借鉴微软的CDM理念，CDM这个概念最早是2016年微软宣布“以Dynamics 365的形式改造其CRM和ERP”战略时提出的。微软给它的定义是“用于存储和管理业务实体的业务数据库，而且是开箱即用的”。CDM不仅仅提供标准实体，它还允许用户建立个性化的实体，用户可以扩展标准实体也可以增加和标准实体相关的新实体。 CDM可能并不性感，但绝对是非常必要的。它成为了微软的很多产品的基础，是构建了无数业务领域的原型。同时微软也期望它能成为快速实现数据交换和迁移的标准，这个有点像菜鸟网络推出的奇门，让所有TMS、OMS、WMS都基于一套数据接口API进行互通，一套标准是为了解决一个行业问题，而不是具体某一个企业一个集团的问题。 我们发现CDM的理念跟我们想要的“企业级的数据标准”是非常吻合的。但是我们也不能照搬照抄，虽然微软的CDM很好的解决了数据割裂问题，但就模型来说就够大家喝一壶了，模型库非常庞大而且复杂，学习成本巨高。 数字化时代软件会产生新的技术流派 我们知道传统软件的设计理念：侧重在模型对业务支撑全面性上。优点体现为配置丰富，缺点模型设计过于复杂，刚开始有前瞻性，但在理解、维护都非常困难，随着业务发展系统原先的设计逐渐腐化，异常笨重。 而Oinone的CDM设计理念：侧重在简单、灵活、统一上，体现为在上层应用开发时，每一业务领域保持独立，模型简单易懂，并结合Oinone的低代码开发机制进行快速开发，灵活应对业务变化。 所以我更想说Oinone的CDM是微软CDM的在原有基础上，与互联网架构结合，利用Oinone低代码开发平台特性形成新的工程化建议。Oinone-CDM不以把模型抽象到极致，支撑“所有业务可能性”为目标，而是抽象80%通用的设计，保持模型简单可复用，来解决数据割裂问题，并保持业务线独立自主性，快速创新的能力。 图5-1-1 Oinone-CDM要解决的问题 二、Oinone的CDM本质是创新的工程化建议 引入CDM以后系统工程结构会有什么变化，跟大家认知的互联网架构有什么区别。 原本上层的业务线系统，需要调用各个业务平台提供的功能，增加CDM以后也就是我们右的图，每个业务线就像一个独立右边。看上去复杂了，其实对业务线来说更加简单了。 互联网整体平台化带来的问题： 业务线每次业务调整都需要给各个平台提需求 业务平台研发需要了解所有业务线的知识再做设计，对研发要求非常高 各个业务域的不同需求相互影响包括系统稳定性、研发对需求响应的及时性 结合oinone特性提出的新工程建议： 一些通用性模块继续以平台化的方式存在，能力完全复用。 业务线自建业务平台，保持业务线的独立性和敏捷性 业务线以CDM为原型，保证核心数据不割裂，形成一致的数据规范 图5-1-2 引入CDM概念后的工程结构对比 三、CDM思路示意图 该示例中OinoneCDM的商品域不仅仅提供标准实体，保证各个业务系统的对商品的通用需求、简单易懂，在我们星空系列业务产品中如全渠道运营、B2B交易等系统以此为基础建立属于自身个性化的实体，可以扩展标准实体也可以增加和标准实体相关的新实体。 带来的好处： 通过多种继承方式，继承后的模型可扩展模型本身、模型行为等，从而解决业务独立性问题。 通过CDM层统一数据模型，从而解决多应用数据割裂问题 图5-1-3 Oinone-CDM思路示意图

  史, 昂

  2024年5月23日

  852000
• Oinone 7天入门到精通

  3.6 问题排查工具

  当前端发起对应用的访问时，如果出现错误，那么我们可以通过以下方式进行简易排查，如果排查不出来，则也可以把排查工具给出的信息发送给Oinone官方售后进行进一步分析。本文将通过模拟异常信息，来介绍排查工具，提供了哪些辅助信息帮我们来快速定位问题。 排查工具基础介绍 通过前端页面的 /debug 路由路径访问调试工具的页面，假设我们的前端页面访问地址为http://localhost:6800，那么我们的排查工具请求路径就是 http://localhost:6800/debug排查工具可以帮我们排查前端页面元数据异常和后端接口的异常 排查前端页面元数据 将问题页面浏览器地址栏内 page 后的部分复制到调试工具的 debug 路由后重新发起请求，如图可以看到调试工具展示的信息，可以根据这些信息排查问题。 排查后端接口 后端接口出现问题后，打开(在原页面）浏览器的调试工具，切换到“网络”的标签页，在左侧的历史请求列表中找到需要调试的请求，右键会弹出菜单，点击菜单中的 “复制”，再次展开该菜单，点击二级菜单中的“以 fetch 格式复制”，这样可以复制到调试所需要的信息 2.复制调试信息到“接口调试”标签页内的文本框内，点击“发起请求”按钮获取调试结果 我们可以看到页面展示了该接口的各种调试信息，我们可以据此排查问题。 场景化的排查思路 业务代码中存在代码bug 报错后发起调试请求，我们可以看到，调试工具直接给出了异常抛出的具体代码所在位置，此时再切换到“全部堆栈”下，可以看到是业务类的233行导致的空指针异常，查看代码后分析可得是data.getName().eqauls方法在调用前未做条件判断补全该判断后代码可以正常执行 业务代码中没有直接的错误，异常在平台代码中抛出 报错后发起调试请求可以看到异常不在业务代码内再切换到“全部堆栈”，可以看到具体异常信息，提示core_demo_item表出现了重复的主键，该表是DemoItem模型的我们还可以切换到“sql调试”的标签页，可以看到出错的具体sql语句经过分析可以得知是240行的data.create()�重复创建数据导致的。 三、排查工具无法定位怎么办 当我们通过排查工具还是没有定位到问题的时候，可以通过调试页面的“下载全部调试数据”和“下载调试数据”按钮将调试信息的数据发送给官方售后人员帮助我们定位排查问题。 点击页面最顶部的“下载全部调试数据”按钮，可以下载页面调试数据和接口调试数据点击“调试接口”标签页内的“下载调试数据”按钮，可以下载接口调试数据 四、排查工具细节

  史, 昂

  2024年5月23日

  1.3K000
• Oinone 7天入门到精通

  4.1.20 框架之Session

  在日常开发中，我们经常需要把一些通用的信息放入程序执行的上下文中，以便业务开发人员快速获取。那么oinone的PamirsSession就是来解决此类问题的。 一、PamirsSession介绍 在oinone的体系中PamirsSession是执行上下文的承载，您能从中获取业务基础信息、指令信息、元数据信息、环境信息、请求参数，以及前后端MessageHub等。在前面的学习过程中我们已经多次接触到了如何使用PamirsSession： 在4.1.19【框架之网关协议-后端占位符】一文中，使用PamirsSession.getUserId()来获取当前登入用户Id，诸如此类的业务基础信息； 在4.1.18【框架之网关协议-variables变量】一文中，使用PamirsSession.getRequestVariables()得到PamirsRequestVariables对象，进而获取前端请求的相关信息； 在4.1.5【模型之持久层配置】一文中，使用PamirsSession.directive(),来操作元位指令系统，进而影响执行策略； 在4.1.13【Action之校验】、3.4.1【构建第一个Function】等文章中，都用到PamirsSession.getMessageHub()来设置返回消息。 二、构建模块自身Session（举例） 不同的应用场景对PamirsSession的诉求是不一样的，这个时候我们就可以去扩展PamirsSession来达到我们的目的 构建模块自身Session的步骤 构建自身特有的数据结构XSessionData 对XSessionData进行线程级缓存封装 利用Hook机制初始化XSessionData并放到ThreadLocal中 定义自身XSessionApi 实现XSessionApi接口、SessionClearApi。在请求结束时会调用SessionClearApi的clear方法 定义XSession继承PamirsSession 扩展PamirsSession的经典案例设计图 图4-1-20-1 扩展PamirsSession的经典案例设计图 构建Demo应用自身Session 下面的例子为给Session放入当前登陆用户 Step1 新建DemoSessionData类 构建自身特有的数据结构DemoSessionData，增加一个模型为PamirsUser的字段user，DemoSessionData用Data注解，注意要用Oinone平台提供的@Data package pro.shushi.pamirs.demo.core.session; import pro.shushi.pamirs.meta.annotation.fun.Data; import pro.shushi.pamirs.user.api.model.PamirsUser; @Data public class DemoSessionData { private PamirsUser user; } 图4-1-20-2 新建DemoSessionData类 Step2 新建DemoSessionCache 对DemoSessionData进行线程级缓存封装 package pro.shushi.pamirs.demo.core.session; import pro.shushi.pamirs.meta.api.CommonApiFactory; import pro.shushi.pamirs.meta.api.session.PamirsSession; import pro.shushi.pamirs.user.api.model.PamirsUser; import pro.shushi.pamirs.user.api.service.UserService; public class DemoSessionCache { private static final ThreadLocal<DemoSessionData> BIZ_DATA_THREAD_LOCAL = new ThreadLocal<>(); public static PamirsUser getUser(){ return BIZ_DATA_THREAD_LOCAL.get()==null?null:BIZ_DATA_THREAD_LOCAL.get().getUser(); } public static void init(){ if(getUser()!=null){ return ; } Long uid = PamirsSession.getUserId(); if(uid == null){ return; } PamirsUser user = CommonApiFactory.getApi(UserService.class).queryById(uid); if(user!=null){ DemoSessionData demoSessionData = new DemoSessionData(); demoSessionData.setUser(user); BIZ_DATA_THREAD_LOCAL.set(demoSessionData); } } public static void clear(){ BIZ_DATA_THREAD_LOCAL.remove(); } } 图4-1-20-3 对DemoSessionData进行线程级缓存封装 Step3 新建DemoSessionHook 利用Hook机制，调用DemoSessionCache的init方法初始化DemoSessionData并放到ThreadLocal中。 @Hook(module= DemoModule.MODULE_MODULE), 规定只有增对DemoModule模块访问的请求该拦截器才会生效，不然其他模块的请求都会被DemoSessionHook拦截。 package pro.shushi.pamirs.demo.core.hook; import org.springframework.stereotype.Component; import pro.shushi.pamirs.demo.api.DemoModule; import pro.shushi.pamirs.demo.core.session.DemoSessionCache; import pro.shushi.pamirs.meta.annotation.Hook; import pro.shushi.pamirs.meta.api.core.faas.HookBefore; import pro.shushi.pamirs.meta.api.dto.fun.Function; @Component public class DemoSessionHook implements HookBefore { @Override @Hook(priority = 1,module = DemoModule.MODULE_MODULE) public Object run(Function function, Object… args) { DemoSessionCache.init(); return function; } } 图4-1-20-4 新建DemoSessionHook Step4 新建DemoSessionApi package pro.shushi.pamirs.demo.core.session; import pro.shushi.pamirs.meta.api.CommonApi; import pro.shushi.pamirs.user.api.model.PamirsUser; public interface DemoSessionApi extends CommonApi { PamirsUser getUser(); } 图4-1-20-5 新建DemoSessionApi Step5…

  史, 昂

  2024年5月23日

  1.1K000
• Oinone 7天入门到精通

  5.7 商业支撑之库存域

  库存的差异会反馈到企业的整个价值链上，所以对库存的设计是至关重要的 一、基础介绍 我们先抛开仓库中对库存的实操管理和整个流通领域的库存，只围绕企业自身一级的采销链路上我们可以从管理和销售两个角度去看。 从管理角度上我们会关心：实物库存、在途库存、在产库存、库存批次等等，也就是企业有多少库存分布在哪里在什么环节。 从销售角度上我们会关心：可售库存、安全库存等等，也就是企业在特定渠道销售中库存分配规则。 在商业场景中库存管理一头对接仓库、生成、采购，另一头对接多个销售渠道。它的挑战在于不同行业不同特征商品都有比较大的差异。比如家具行业卖的是生产能力，家电区域化销售，生鲜拼车销售，服饰一仓销全国。热销的要分配提升体验防止超卖，滞销的要活动拉流量，普通的要渠道共享最大化可售。库存管理的差异会反馈到企业的整个价值链上，所以对库存的设计是至关重要的。 库存设计挑战在于： 技术上：库存类似账户账本的设计，需要能追溯库存变化的过程，且库存操作都能可追溯业务单据。热点数据的并发控制 业务上：在管理角度上游能跟仓库、采购、生产等进行对接、对账、并为其设置可售规则，下游能为各个销售渠道设置库存分配与同步规则 二、模型介绍 图5-7-1 模型介绍 核心设计逻辑： 单据链路：业务单据（外部业务单据+库存业务单据）产生库存指令（库存调整入\出库单），再由库存指令操作库存并记录库存流水。 管理链路：基础数据维护仓库、供应商、服务范围与费用。这些数据是订单履约路由和可售库存同步的基础 库存数据：对外跟商品域，通过库存指令进行操作。不同库存各自维护自身库存与流水记录，确保可追溯。 如果跟销售渠道对接，还需要扩展可售库存逻辑规则以及同步规则。比如oms类似的应用

  史, 昂

  2024年5月23日

  976000