产品类目能够拆分为后台主分类和前端出售分类

之前和咱们同享了这么多和举荐、查找相关的战略，今天想给咱们讲一讲两个战略融会贯通、相互交织的运用场景。各家大厂信息流举荐中

）假如事务体系仅服务于一个事务体，不存在其他事务或不考虑复用性，那产品根底数据能够全量保护在一个表单，产品准入后即创立成功。

这样创立和保护比较简单但局限性很大，基本只合适在后台运用，前台无法共用。假如有一些通用特点相同，出售特点不同的，需求从头再保护一遍，工作量也比较大，且计算也比较难以聚合起来，统一剖析。这种比较合适品类比较单一，不需求做聚合的企业。

2）假如考虑多事务体复用性，则能够根据产品特点区别：

• 根底特点（大局统一）：①产品编码 ②产品称号 ③产品主分类 ④根底单位。
• 出售特点（答应不同事务体定义值不同）：①产品出售称号 ②前端出售分类 ③税率 ④产品出售单位 ⑤规格 ⑥标签 ⑦产品图片等。

这样在产品准入时保护产品根底特点即可，出售特点在实际引用时保护，这样能够做到体系在服务不同事务体的时候，同一产品仅需求建码一次，在引用时经过保护不同出售特点加以区别能够灵敏适配不同事务状况，一起也避免数据混乱或数据计算不完全，比较合适渠道型企业或品类较为复杂，涉及到的数据维度也比较复杂的企业。

4. 产品类目

产品类目是产品的一个重要组成部分，在内/外部体系中运用频率都比较高。一般来说，产品类目有一级类目，二级类目，三级类目等。三级类目基本能够满足多数体系的运用需求，但不排除有些事务有更精细化的要求，会分到四级类目，比如轿车零部件行业等。

1）产品类目能够拆分为后台主分类和前端出售分类。

产品主分类是所有产品的规范分类，一般是两级到三级树形结构，涉及到许多外部体系的逻辑，一般不会容易改变。

主分类上还能够承载产品的根底特点，在保护产品时，挑选主分类后，能够将分类下的特点带出，节省保护产品数据的时间。

一起，后台主分类也多用于产品数据剖析的场景，辅佐判别产品的流通性、出售趋势、价格趋势、库存趋势等关联性。

2）前端出售分类主要是用来促进出售，有时具有一些营销或节日特点（比如今天促销、产地蔬菜），且多是平铺，便利客户浏览检查。

前端出售分类有时还会承载一种事务类型的规矩集合，以咱们做的生鲜供应链为例，在建议售后时，不同品类（猪肉，蔬菜，杂百等）之间的售后审批流程，售后规矩均不相同；这种不同类别的装备便是依靠前端出售分类来区别的。

后台主分类和前端出售分类的对应或许是一对一，一对多，多对多的，主要仍是看实际的事务场景装备。

5. 编码

再跟大家分享下几种编码的运用场景：

1. 产品编码：一般是指SPU编码，产品准入后主动生成，一般运用在体系内部，用于确认详细产品。
2. SKU编码：保护出售特点后生成，多用于供应链内部流转，一般运用在体系内部，唯一性确认某一个产品。
3. 产品条码：一般称为69码，69码的编码规矩包括20位数字，其中前14位是全球唯一的产品编码，由全球唯一编码组织（GS1）颁布；第15到17位是地区码，表明产品在哪些地区出售；第18位是包装级别码，表明产品包装的级别；第19位到20位是校验码，用于检验前面数字的准确性。主要是用于库房出入库扫描，识别SKU的根据。
4. SN码：产品出厂时印在产品包装盒上的识别码，同一SKU下的每一个实物SN码都不同，一般用在产品价值比较高或需求全程溯源的行业。

四、客户数据

1. 客户主数据保护/报废

同产品主数据，都是在SAP中建档，流程经往后创立成功，报废同理，流程的搭建更多是匹配公司事务规矩，可根据实际状况装备。

2. 客户信息

1）客户基本信息，可直接获取：

• 包括客户的称号、公司法定称号、联系人等基本身份信息。
• 联系方式： 客户的电话号码、电子邮件地址、传真等联系方式。
• 地址信息： 客户的办公地址、库房地址或者其他重要地址信息，特别是在涉及到物流和配送的事务中。
• 记载负责该客户的出售团队成员信息，跟进记载等，以便协调交流。

2）客户消费信息，由渠道消费记载获得：

• 客户购买前史。
• 客户支付记载。
• 客户参与营销记载状况

3）客户用户画像，经过数据剖析得出：

• 客户生命周期。
• 客户类型（一般客户/VIP会员/分销商/批发商等）。
• 客户偏好（下单偏好及客户售后偏好等）。
• 客户层级。

3. 客户结算

假如体系一起支撑多个事务主体，那么在建档时或许会区别出几种客户类型，用以便利终究结算：

1. 结算客户：一般性的客户类型，表明与公司有结算关系的客户。这或许包括惯例的出售和采购活动。
2. 一次性客户：短期一次性的交易，不需求保存过多的客户信息，一般不做建档，统一放在同一个一次性客户下。

档口客户：一个结算客户下或许存在多个档口客户，在终究结算时均结算在一个结算客户下。举个例子：客户中有校园客户，校园有多个食堂，每个食堂都有独自的菜单，分隔采购。这时候就能够树立一个校园主体作为结算客户，多个食堂作为档口客户，档口客户之间能够分隔下单，数据不互通，终究统一结算在校园这个结算客户下。