5.6 商业支撑之商品域

一、基础介绍

当业务在线化后,用于内部管理的产品主数据,叠加一堆销售属性变成了商品被推倒了前台,成为导购链路中最最重要的信息载体。看似最基础和最简单的商品模块也有很多门道。主要集中在以下几个方面:

  1. 商品的属性如何管理、呈现、参与导购(类目、搜索的过滤条件)

  2. 如何解决固定不变的内部管理需求与基于销售特性长期变化的运营需求之间的矛盾

  3. 在多渠道情况渠道商品,如何映射到实际sku进行履约

二、模型介绍

5.6 商业支撑之商品域

图5-6-1 模型介绍

  1. 类目属性,解决“商品的属性如何管理、呈现、参与导购(类目、搜索的过滤条件)”

  2. 前后台类目设计,解决“如何解决固定不变的内部管理需求与基于销售特性长期变化的运营需求之间的矛盾”

  3. 销售Sku和库存Sku设计,解决“在多渠道情况渠道商品,如何映射到实际sku进行履约”

要把这些问题搞清楚,得先把名词统一下:

领域 名称 oinone的定义 说明 举例
平台运营视角 Spu Product –>Spu2.1.9 –> 3.0.0 SPU(Standard Product Unit):标准化产品单元。SPU是商品信息聚合的最小单位,是一组可复用、易检索的标准化信息的集合,该集合描述了一个产品的特性 iPhone X可以确定一个产品
后台类目 后台类目(Category) 商品分类分级管理,以及规范该类目下公共属性可以分为普通属性、销售属性 比如类目:3c数码/手机销售属性:内存大小、颜色等普通属性:分辨率
前台类目 前台类目(FrontCategory) 平台导购类目 通过前台类目关联后台类目或后台类目属性,用于满足运营需求
大体上SPU处于最上层、Item属于下一级,而SKU属于最低一层。SPU是平台层面,Item是商家层面,SKU是商家的Item确定销售属性SPU非必须,在平台类交易中,平台方为了规范商家发布商品信息,进行统一运营时需要
商家销售视角 Item 渠道商品(Item) 简单来说是:SPU加上归属商家、以及商家自有的价格与描述 商家A的iPhone X
Sku 销售Sku(SaleSku) SKU=Stock Keeping Unit(库存保有单位)。是对每一个产品和服务的唯一标示符,该系统的使用SKU的值根于数据管理,使公司能够跟踪系统,如仓库和零售商店或产品的库存情况。 iPhone X 64G 银色 则是一个SKU。
店铺类目 ShopCategory 商家店铺导购类目 在平台类电商,商家都会有自己独立的店铺主页,商家类目跟前台类目作用类似,只是局限影响范围为商家店铺内
销售SKU中会有一个InvSkuCode来关联InventorySku,比如:品牌上在不同渠道(淘宝、京东、自建电商)中会有不同的销售SKU,在从渠道同步销售SKU会根据外部code
商家管理视角 产品或库存Sku InventorySku 跟销售领域的sku的定义类似,但销售领域是为了规范购买行为,这里规范企业内部管理。 iPhone X 64G 银色
组合Sku InventorySkuComposition 空调有内外机组合而成,这就是一个组合sku
产品分类 ProductKind 企业内部管理划分
商品系列 ItemSeries 指互相关联或相似的产品,是按照一定的分类标准对企业生产经营的全部产品进行划分的结果。一个产品系列内往往包括多个产品项目。产品系列的划分标准有产品功能、消费上的连带性、面向的顾客群、分销渠道、价格范围等
存货类别 StorageKind 为了反映存货的组成内容,正确计算产品的生产成本以及销售成本,会计上必须对存货进行科学地分类,按存货的不同类别进行核算

表5-6-1 各领域名称说明

Oinone社区 作者:史, 昂原创文章,如若转载,请注明出处:https://doc.oinone.top/oio4/9321.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

Like (0)
史, 昂's avatar史, 昂数式管理员
Previous 2024年5月23日 am8:17
Next 2024年5月23日 am8:19

相关推荐

  • 应用审计

    1. 整体介绍 应用审计是基于模型字段记录用户操作留痕记录,通过定义审计规则,平台基于审计规则订阅的字段记录形成日志。平台名词概念: 应用日志:针对已订阅的审计规则记录用户操作信息,是用户在各应用中操作行为留痕记录。 审计规则:业务审计中,数据变化订阅记录的规则。 操作入口:应用中心——业务审计应用。 2. 审计规则 审计规则是指定义审计过程订阅数据变化的信息,根据模型、订阅到具体字段内容变化形成应用日志。如订阅销售订单的备注,销售订单S20231001888,订单备注【尽快发货】,备注修改为【需易碎品包装】,审计规则为:销售订单模型,订阅【备注】。 操作包括:新增、编辑、删除。 2.1. 新增 新增时,定义审计规则名称,选择需要审计的模型,指定需要订阅的字段信息,同时可以指定关联关系的字段。 需要注意:每个模型仅限定义单条审计规则。 2.2. 编辑 编辑同新增操作,不做赘述。 2.3. 删除 删除规则后,平台将不再监听对应数据的变更日志,请慎重删除。 3. 应用日志 应用日志是针对已订阅的审计规则记录用户操作信息。记录操作用户、IP、登录设备、位置、订阅的字段变化内容。 应用日志详情 4. 业务表达 4.1. 展示效果 表格-行操作—日志记录 详情—日志记录 4.2. 操作步骤 Step1:在应用中心,需要维护业务应用依赖业务审计应用; 操作入口:应用中心,找到业务应用——编辑,依赖模块选择业务审计。 Step2:配置审计规则; 操作入口:业务审计应用——审计规则——新增规则。 Step2:界面设计器配置日志记录; 操作入口:界面设计器,找到需要配置的页面——模型组件,将动作区的日志记录拖动到页面中。

    2024年1月20日
    1.4K00
  • 模型

    1. 模型介绍 Oinone低代码设计器是采用模型驱动的方式来设计应用,数据、数据都在模型,在模型设计器的模型管理模块,通过可视化配置的方式为用户提供快速设计模型的功能。 模型是对应用中所需要描述的实体进行必要的简化,并用适当的变现形式或规则把它的主要特征描述出来所得到的系统模仿品。模型由元信息、字段、数据管理器和自定义函数构成。 2. 操作模式 为了满足有无研发背景知识的不同用户使用需求,在模型设计器中,支持切换操作模式,包含专家模式和经典模式。经典模式功能基础且完善,操作交互简单易理解,适用于非研发用户;专家模式下模型的设计能力更高,有经典模式下的所有功能,相比于经典模式,功能更多,适用于一般有研发知识基础的用户。 比如在添加模型时,经典模式下可以创建的模型类型有:存储模型、传输模型,专家模式下,在此基础上还可以创建抽象模型和代理模型。 3. 分组管理 当模型过多时,可以自定义添加15个分组,将模型进行归类管理。点击「全部」展开所有分组,展开后,分组右侧可以管理分组。 3.1 管理分组 展开分组后,点击「管理分组」,出现弹窗,在弹窗中可以修改分组名称、添加分组、删除分组。 3.2 添加分组 操作「+模型分组」,可以直接输入分组名称后回车以添加一个新分组,或快捷选择其他应用使用的分组。最多添加15个分组。 3.3 修改分组 双击分组标签,即可对已有分组进行名称的修改。若分组在其他应用也使用,则在其他应用内,该分组名称也同步变化。 3.4 删除分组 点击分组标签右侧的“X”按钮,即为删除分组,但分组下如果有模型或者分组有被其他应用使用,则分组无法删除。 4. 模型管理 4.1 管理模式 在模型管理中,有两种管理模式,分别是图管理模式和列表管理模式。(下文简称图模式、表模式) 可以根据不同的使用场景,切换管理模式: 图管理模式下,模型操作区展示当前模型和与当前模型有直接关联关系的模型关系图,可以在关注模型关联关系时使用; 列表管理模式下,展示更多更详细的模型信息、字段信息,且左侧可快速切换不同模型,可以在关注模型基础信息时使用; 4.2 筛选 4.2.1 图模式筛选 在图模式下,顶部进行应用/模块、模型类型、分组的筛选,依此向下可以搜索或展开当前筛选条件下的模型列表,切换模型后在模型操作区将展示另一模型的信息。为了更大程度保留图模式下的模型展示区域,模型列表默认不会展示,点击搜索行的任意筛选项,即可展开模型列表。 4.2.2 表模式筛选 在表模式下,顶部和图模式一致,都是应用/模块、模型类型、分组的筛选,模型操作区左侧会直接展示模型列表。 4.2.3 重置筛选 图模式和表模式下,右侧都有重置筛选的选项。如果点击“重置筛选”按钮,则将筛选栏恢复到进入页面时的选项。 4.3 模型分组 模型新增成功后,默认无所属分组,每个模型可以设置所属分组,设置后通过分组进行筛选时,模型即展示在所属分组下。 4.3.1 图模式设置分组 图模式下为模型设置分组,点击模型信息顶部第一个「模型分组」操作图标,点击后设置或修改分组。 4.3.2 表模式设置分组 表模式下为模型设置分组,点击模型信息右上角第一个操作「模型分组」,点击后设置或修改分组。 4.4 继承关系 查看模型的继承关系,点击展示跟当前模型有父子关系的模型关系图。 页面初始状态只展示一层父模型与一层子模型,父模型顶部和子模型底部有“展示更多”按钮,点击展示更多再向上或向下加载一层。连线的顶部展示“收起”按钮,点击“收起”按钮收起子模型。 点击非当前模型,会打开新窗口,链接跳转到点击模型的模型设计器页面,新页面满足点击模型的筛选条件; 支持设置显示比例,缩放模型关系图; 支持最大化全屏展示。 4.4.1 图模式继承关系 4.4.2 表模式继承关系 4.5 查看引用关系 当删除模型时,如果模型有被其他设计器引用使用,则无法被删除。删除失败时会弹出“该模型仍在使用中,无法删除模型”的提示,并且可以点击「查看模型引用」,进而展示引用的详细信息。 引用包括五种:模型引用、页面引用、逻辑引用、流程引用、图表引用。 每种关系通过列表展示,列表项为链接(链接到对应的设计页面),内容为对应名称。例如,存在引用关系的流程的列表项显示的是流程的名称。列表项链接到对应流程的设计页面。 4.6 导入模型 导入模型的添加模型的一种方式,下载导入模板后在Excel中按照规则填写模型信息,成功导入后即添加模型成功。 点击「导入模型」后,可在弹窗中下载导入模板、上传导入文件、查看导入说明。 4.6.1 下载导入模板 下载导入模板时,会根据当前的操作模式不同,下载到的模板也不同。 在经典模型下,下载的导入模板中需要填写的模型信息基础、数量少、易懂。 在专家模型下,下载的导入模板中需要填写的模型信息丰富、数量多、专业。 4.6.2 查看导入说明 导入说明中描述了导入模板中各项内容的含义、填写规则等,有助于用户正确填写导入文件。在经典模式或专家模式下点击「导入说明」后,分别弹出两种操作模式下的导入说明。 4.6.3 导入上传 导入文件正确填写后,在弹窗中选择Excel文件,或将Excel直接拖入弹窗中的文件上传区域。Excel文件仅支持三种格式:.xlsx .xls .xlsm。 4.7 添加模型 点击「添加模型」,出现模型信息填写的弹窗,弹窗中包括:模型名称、模型类型、父模型。填写并保存成功后,模型即创建成功。 4.7.1 模型类型 专家模式下支持创建4种类型的模型:存储模型、传输模型、抽象模型、代理模型;经典模式下支持创建2种类型的模型:存储模型、传输模型。 存储模型:用于存储数据的模型,生成前后端交互协议、数据表、数据构造器和数据管理器。 抽象模型:用于配置多个子模型的公用字段和函数的模型,不会生成前后端交互协议、数据表、数据构造器和数据管理器。 传输模型:用于数据传输的模型,生成前后端交互协议和数据构造器,不生成数据表和数据管理器。 代理模型:用于以代理的方式扩展存储模型的模型,可以在存储模型的基础上增加传输字段和函数,与被代理的存储模型共用相同的数据管理器。 4.7.2 选择父模型 添加模型时,需要选择父模型,其中,经典模式下,无需且不展示父模型;专家模式下,必须选择父模型。 存储模型的父模型,默认是“基础存储模型”,可选项为可见的抽象模型和存储模型。 传输模型的父模型,默认是“基础存储模型”,可选项为可见的传输模型。 抽象模型的父模型,默认是“基础存储模型”,可选项为可见的抽象模型。 代理模型的父模型,无默认值,可选项为可见的存储模型和代理模型。 4.8 编辑模型 创建成功的模型,可以对其进行编辑,但只有部分信息支持编辑。 4.8.1 图模式编辑模型 图模式下,点击模型标题右侧的「编辑模型」按钮,即可在右侧弹出的抽屉中编辑模型信息。 4.8.2 表模式编辑模型 表模式下,点击模型信息标题右侧的「编辑模型」按钮,下方模型信息中可以被编辑修改的字段即由只读变为可编辑。 4.9 隐藏/可见模型 对于暂时不使用的模型,可以进行隐藏(隐藏后可再设置可见)的操作。 在其他设计器需要选择模型使用时,隐藏的模型将不被展示。对隐藏的模型再次操作可见后,即可选择到。 4.9.1 图模式隐藏/可见模型 图模式下,展开模型列表,模型列表中每个模型所在行的右侧,可点击隐藏/可见图标,以隐藏/可见该模型。 可见的模型常规展示,无特殊标识;隐藏后的模型在列表中将置灰展示。 4.9.1 表模式隐藏/可见模型 表模式下,模型信息左侧的模型列表中每个模型所在行的右侧,可点击隐藏/可见图标,以隐藏/可见该模型。 可见的模型常规展示,无特殊标识;隐藏后的模型在列表中将置灰展示。 4.10 删除模型 不再使用模型可以进行删除,删除时需要确保模型没有被其他设计器引用。删除成功后的模型将不在列表展示,且不可恢复,请谨慎操作。 4.10.1 图模式删除模型 图模式下,展开模型列表,模型列表中每个模型所在行的右侧,可点击删除图标,以删除该模型。 4.10.2 表模式删除模型 表模式下,模型信息左侧的模型列表中每个模型所在行的右侧,可点击删除图标,以删除该模型。 4.10.3 存在引用关系 如果删除的模型存在引用关系,则无法删除,并提示模型仍在使用。点击提示中的「查看模型引用」,可以查看这个模型引用情况。 5. 字段管理 在模型中,可以对字段进行增删改查等基础管理操作。 5.1 添加字段 每个模型中可以添加多个字段,手动添加的字段都为自定义字段。点击「添加字段」,右侧出现字段信息填写的抽屉,抽屉中包括:字段名称、字段业务类型、存储类型、长度(部分业务类型的字段无长度设置)。填写并保存成功后,字段即创建成功。 5.1.1 图模式添加字段 5.1.2 表模式添加字段 5.1.3 字段业务类型 添加字段时,支持设置16种基础类型的字段、支持设置4种关系类型字段。 基础类型:用户ID、整数、浮点数、金额、布尔型、文本、多行文本、富文本、日期时间、年份、日期、时间、数据字典、键值对、手机、邮箱; 字段为数据字典时需要选择一个数据字典。 关系类型:一对一、多对一、一对多、多对多 字段为关系类型字段时需要选择关联的模型。 5.1.4 多值字段 多值字段表示该字段可以存储或传输多个该业务类型的数据,非多值字段只能存储或传输单个该业务类型的数据。 5.1.5 存储类型 设置字段的存储类型:存储字段、传输字段 存储字段:用于查询和存储字段 传输字段:仅用于数据的组装与存储 5.2 编辑字段 创建成功的字段,可以对其进行编辑,但只有部分信息支持编辑。 字段长度和精度只能由小往大改,不能由大往小改。 关联关系的关联模型、关联字段、关系字段、中间模型,中间关系字段、中间关联字段、支持关联查询不可修改。 5.2.1 图模式编辑字段 图模式下,点击字段列表所在行右侧的「编辑字段」按钮,即可在右侧弹出的抽屉中编辑字段信息。 5.2.2 表模式编辑字段 表模式下,点击模型信息标题右侧的「编辑模型」按钮,下方模型中的字段都可以被展开编辑。 5.3 隐藏/可见字段 对于暂时不使用的字段,可以进行隐藏(隐藏后可再设置可见)的操作。 在其他设计器需要选择字段使用时,隐藏的字段将不被展示。对隐藏的字段再次操作可见后,即可选择到。 5.3.1 表模式隐藏/可见字段 表模式下,编辑模型时,字段所在行右侧可以操作隐藏/可见。 可见的字段常规展示,无特殊标识;隐藏的字段在列表中将置灰展示。 5.4 删除字段…

    2024年6月20日
    1.8K00
  • 7.4 Oinone的低无一体

    基础介绍 前面我们学习了基于低代码开发平台进行快速开发,以及通过oinone的设计器进行零代码开发两种模式。当然低无一体不是简单地说两种模式还指:低无两种模式可以融合。 在做核心产品的时候以低代码开发为主,以无代码为辅助。见低代码开发的基础入门篇中设计器的结合一文 在做实施或临时性需求则是以无代码为主,以低代码为辅助 本文主要介绍第二种模式,它是www.oinone.top官网在SaaS模式下的专有特性。满足客户安装标品后通过设计器进行适应性修改后,但对于一些特殊场景还是需要通过代码进行完善或开发 在该模式下,我们提供了jar模式和代码托管两种模式,客户只要选择需要进行代码开发的模块,点击生产SDK,下载扩展工程模版,按Oinone低代码开发平台规范进行研发,后上传扩展工程即可。 操作手册 低无一体这个模块是连接无代码设计器的桥梁,可以为一个模块或应用设计低代码的逻辑,可以在界面设计器或流程设计器中使用低代码的逻辑。 1.选择模块 首先需要在下拉单选中选择需要低代码的模块或应用。 下拉选中只展示在「应用中心」中已安装的模块或应用,可前往「应用中心」安装后继续低代码操作。 选择模块中不展示系统的基础模块或应用,因为这些模块或应用无法自定义模型。 2.模块信息 模块信息展示的是选择模块的基础信息:模块名称、模块编码、模块作者、模块版本、包的前缀、工程模板下载地址,下载地址仅在上传jar包模式时候用到。 3.低无一体操作 低无一体支持了两种使用模式:上传jar包模式、源码托管模式。 上传控制工程或创建研发分支动作完成会生成一条数据,可以对单条数据进行部署、卸载、修改、删除。 3.1 上传jar包模式 在这个模式下,需要做四步动作。 生成SDK,点击按钮之后,会把模块的当前模型状态打成一个SDK包,SDK最新生成时间更新。当模型变更但未生成SDK时,使用低无一体就会出错,请重新生成SDK并修改扩展工程。生成SDK通常需要1分钟左右,若第一次使用低无一体模块,可能需要更长时间,请耐心等待。 下载扩展工程模板,点击按钮之后,会将SDK包和工程模板生成一个下载链接,复制模块信息中的卸载地址打开即可下载。 技术人员在工程模板的基础上写低代码逻辑。 上传扩展工程,点击按钮展开弹窗,在弹窗中设置标签、备注,并将最终的jar包上传,完成上传之后表格中就会新增一条数据。 上传jar包模式下,模板工程中代码需要注意的点参考下图: 3.2 源码托管模式 在这个模式下,需要做三步动作。 生成SDK,点击按钮之后,会把模块的当前模型状态打成一个SDK包,SDK最新生成时间更新。当模型变更但未生成SDK时,使用低无一体就会出错,请重新生成SDK并修改扩展工程。生成SDK通常需要1分钟左右,若第一次使用低无一体模块,可能需要更长时间,请耐心等待。 创建研发分支,点击按钮展开弹窗。首次创建时需要设置git账号名称、git账号邮箱来创建一个账号,另外在弹窗中设置分支名称、标签、备注,完成创建后表格中就会新增一条数据。 通过表格中的Gitlab地址,技术人员写低代码逻辑。 3.3 行内操作 部署:工程状态为未部署、部署失败、已卸载时展示行内的部署按钮,点击之后进行部署,工程状态变为部署中。部署过程大致需要5-10分钟,请耐心等待。部署完成之后,会生成一个新的模块:“原模块名称”扩展工程。 卸载:工程状态为已部署时展示行内的卸载按钮,点击之后会卸载这个已部署的工程,工程状态变为已卸载。同一模块只能有一个已部署的工程(与选择的模式无关),若需要使用新的工程请先卸载已部署的工程。 修改:行内操作修改按钮始终展示,只允许修改标签、备注。 删除:工程状态为未部署、部署失败、已卸载时展示行内的删除按钮,点击之后删除这一条工程记录。 3.4 部署效果 低无一体部署成功之后,可以进入对应模块的模型页面中使用提交动作来使用低代码逻辑,也可以在流程设计器中的引用逻辑节点中使用低代码逻辑。

    2024年5月23日
    2.7K00
  • 5.8 商业支撑之执行域

    一、基础介绍 执行域包括两个核心一是订单的产生,二是订单的履约。往往品牌商既有自营渠道(包括2c、2b)、又有第三方渠道。那么有两种设计思路: 把第三方渠道的订单当作自有渠道的订单产生一种特殊方式,开放订单创建接口,并统一履约。 好处:简单,在3方渠道不多、且自有渠道单一,并且逻辑相识时系统结构会简单 坏处: 当3方渠道的履约方式、库存分配方式、逆向逻辑等有差异时,会让自有渠道参杂很多不相干的逻辑引入不必要的复杂度 自有渠道不够独立和纯粹,自有渠道多样化时难以支撑 把商家自营渠道假设为特殊的第三方渠道,再建立统一的订单管理系统来对接渠道订单,并完成履约 好处:交易与履约逻辑分离,对未来发展有扩展性 坏处:引入一定复杂度 我们采用的是第二套方案,整体结构简易图如下 图5-8-1 方案整体结构简易图 二、模型介绍 图5-8-2 模型介绍 核心设计逻辑 首先我们看到上图交易域和履约域有很多相同父模型的子模型,交易域和履约域的父模型在CDM的在himalaya-trade里。履约域看oms(libra)对himalaya-trade扩展,交易域看b2c(leo)和b2b(aries)对对himalaya-trade扩展。libra、leo、aries是我们对上层业务产品的命名,取自黄道十二星座 交易域是多商家平台视角设计,有自身渠道必要的履约相关信息,完成自闭环。 履约域是从单一商家对接多渠道视角设计,有渠道交易订单同步后完成履约发货相关设计,完成自闭环。 履约域的合单拆单发货设计,渠道订单只能合单为履约单不可拆,履约单可以拆单发货不可合。用m2o和o2m的组合设计来降低难度,而非采用两个m2m的设计。

    2024年5月23日
    1.2K00

Leave a Reply

Please Login to Comment