PHP数组内容不另行组合排列算法,B2C电子商务系

最近在做ecshop的商品库存模块,分别给一款商品的多个属性组合设置库存,如下图:

# 技术文档

每天逛淘宝和京东的时候,映入眼帘的都是品类繁多的商品,但是当我们选择分类或者直接搜索的时候,按条件筛选时,系统却往往能从千万商品中提供心中想要的商品;在浏览商品时,商品主图、详情图、规格等信息让我们感觉比在超市拿着实物获得更多信息,电商系统到底是怎么做到这些的呢?对于电商产品经理来说,商品中心的合理设计能够满足前端商品的多样化展示,支撑订单商品信息在系统中的流转。

-

 图片 1

## 系统环境

图片 2

一、SKU及相关概念定义

在设计商品SKU之前,首先让我们熟悉一下SKU和相关的一些概念。

# 什么是SKU:

SKU=Stock Keeping Unit(库存量单位)

同一型号的商品,或者说是同一个产品项目(商品条形码是针对企业的产品

项目来进行定义的),因为产品与产品之间有某些属性不同,用以区别开这些

不同商品的属性即商品变异属性,又称作SKU属性,因为它决定了SKU

的绝对数量。

# 参考说明

百度上有一篇文章也有阐述,可以做关联阅读,我就不重复贴上了。

百度SKU参考

# 什么是SKU属性和选项

比如某件衣服有多种颜色、多种尺码,这些属性会直接关联价格和库存的,

系统会根据该商品关联的SKU属性的某个组合生成SKU。

比如某个款式的衬衫,有XL/L/XXL三种大小,有红黄蓝三种颜色。

对应这里例子,尺码和颜色都是是SKU属性。

对应尺码的XL/L/XXL等,都是SKU属性选项。

【注】上述的属性不一定在任何时候都是SKU属性,看实际的商品情况和设置。

比如对于尺码,某种商品是均码的。那么就不需要创建尺码这个SKU属性了,

而是设置为普通属性,仅作为显示用。

# 什么是商品SKU

商品SKU实际上就是SKU,为了避免误解和SKU属性混淆,我用商品SKU来命名,

表示从属于商品的、实际销售和存储的子实体。

一个商品SKU,表示该商品关联的若干SKU属性的的属性值的某个组合所形成的

子实体。

如对应上面的例子,其中的一种组合 XL 红色 就会形成一个商品SKU。然后,

我们可以在该实体上管理价格、库存、专门的图片等信息。

# 什么是商品变异

英文名:Product Variants

商品变异其实就是商品SKU,只不过在某些技术文章中这样定义了。即以“变异”

来表达商品SKU的生成。

# 属性集

B2C电子商务系统研发——商品SKU分析和设计(一)

Attribute Set,用于管理各类扩展属性的集合,其中SKU属性也是在管理范畴之内。

商品通过关联属性集而获得该属性集设置好的SKU属性,然后才可以根据这些SKU属性

生成商品SKU。

属性集也成为产品类型。

常见的属性集有:服装、PC、家具、图书等。

# 概念的统一

虽然不同的研究人员有不同的命名和定义,但为了在本系列文章中不出现混淆,

我对概念做了以下统一定义:

1)SKU(或称商品SKU)指的是商品子实体。

2)商品和商品SKU是主次关系,一个商品包含若干个商品SKU子实体,商品SKU从属于商品。

3)SKU不是编码,每个SKU包含一个唯一编码,即SKU Code,用于管理。

4)商品本身也有一个编码,即Product Code,但不作为直接库存管理使用。

有时为了方便管理,会通过商品的Product Code作为前缀生成SKU Code。

 一款手机有不同颜色,屏幕尺寸,系统和电量,都要设置不同的库存,如果都要手动选择属性组合,则会耗费很多不必要的时间。假如打开页面时就已经设置好属性排列组合那就最好不过,因此想了整天,写了如下函数:

### web服务器

简单粗暴的讲,商品中心是用来管理核心的商品数据。对于使用的维度:从前端来讲,是给商品展示、订单、营销活动提供商品数据支撑,从后端来讲,商品中心给订单发货、仓库管理、供应商管理、采购提供基础数据支撑。为了更清晰的描述商品中心这项重量级工程,打算写两篇文章从上述两个维度来阐述,本文主要从后端的维度介绍商品中心。

二、SKU属性管理

常见有几种情况:

商品独立管理

即SKU属性从属于商品。

优点:基本上没有。

缺点:这种比较不靠谱,因为会导致工作量过大。虽然可以通过“复制”功能来稍稍

简化,但依然不会很理想。所以基本不会采用。

商品独立关联

即SKU属性是公共的,每个商品根据自己的实际情况来关联若干个SKU属性,

然后选择若干选项生成商品SKU。

优点:灵活,设置好了若干SKU属性和相关选项后,由商品自行选择相关的组合。

缺点:太灵活了,容易出错。比如对于颜色这个SKU属性而言,由于是公共的,所以

会定义数十个,甚至更多,但是对于ipad而言,其实只需要2个即可。这种

管理方式,无法从源头控制商品添加时SKU属性和选项的范围。

通过属性集管理

即SKU属性依附属性集存在,不存在可以从属于多个属性集的SKU属性。

优点:容易进行严格的管理,不易出错。比如同样是命名为“颜色”的SKU属性会存在多个

(属性ID/编码不同),但是对于ipad的只需要2个选项(黑、白),对于服装则会很多。

缺点:属性集管理的工作量会稍大,适合属性集不多的系统。

通过属性集关联

即SKU属性是公共的,通过属性集关联。

优点:这种方式重用性不错,对于SKU选项较多的,会简化工作量。

缺点:由于SKU属性是公共的,所以会存在上面第2点的缺点。但我们也可以通过设置多个

同名、但编码不同的SKU属性,如多个“颜色”SKU属性,但是选项不同。

创建独立的SKU属性集

即设计一个独立的SKU属性集的实体,关联或者直接管理SKU属性。

这种方式也是挺不错的。因为虽然各种商品类型之间产品特性会有较大的不同,但是SKU属性

却有可能差异不大。比如对于服装、ipad都存在通过颜色来区分SKU,但是ipad只需要2种选项

(以后也许微调为3~4种等),而服装则很多了。

 

CentOS 7 64位

一.商品常用概念介绍

三、我的选择

上面介绍了五种形式,我个人倾向第4和第5种,上一篇文章的ER图也改成了第4种的形式,比较符合

常见的思路。第5种也是不错的。可以在接下来的设计分析一下。

笔者研究过不少电子商务平台软件,关于SKU的设计各有不同,之所以有这样的区别,是因为面向不同规模的电子商务网站,

存在产品分类复杂度,产品数量级的差异。一种设计方式对于百货式的网站,如京东、淘宝等,也许比较方便,但也许对于一个

专卖服装的小型时尚类网站就不够方便了。

我们先看一下麦包包的

女包:

手包:

可见SKU很简单,就是颜色,至于尺寸,麦包包并没有作为SKU选项来管理,而是作为不同的产品来处理。

再看一下凡客www.vancl.com

时尚印花短款羽绒服

学院风经典连帽印花羽绒服

SKU相对简单,主要是颜色和尺码。但是看多几个产品会发现,即使是同一个品类下面的颜色和尺码均会出现不相同的情况。至于

颜色图片更是各有不同。

再看一下京东的SKU:

华硕EeePad:http://www.360buy.com/product/492015.html

苹果iPad2:http://www.360buy.com/product/386365.html

其中”版本“SKU属性,两个产品下面的可选项完全不同。

京东的SKU更为复杂了,即使是同一个三级品类下面,也有差异。如果预设置好SKU属性(”版本“)和它的可选项(64G/32G/

16G/32G旗舰版/32G标准版/16G旗舰版/16G标准版)等,那估计会比较多可选项。这种类型,分开多个SKU属性管理会比较合适。

针对这三种常见的网站,其中麦包包和凡客其实比较类似,只是麦包包做了些简化,但这两种可以归纳为一种设计方式,这样

B2C电子商务系统研发——商品SKU分析和设计(二)

SKU属性的设计,便可以分为两类了:

通过属性集关联SKU属性

适合品类较少的网站,管理容易些。

如麦包包等专卖箱包或者服饰类的网站。一般就是颜色 尺码两种。而且由于品类很少,为了方便管理,可以将SKU属性纳入到属性

集中管理,这样产品关联了属性集后,自然就关联了普通属性、查询属性、SKU属性和评论属性了。

图片 3

对于上图,如果该网站产品种类很少,比如只卖服装,那么可以做进一步的简化,即直接将SKU属性从属关联属性集,去掉

”属性集关联SKU“。

基于本设计的管理方式:

按品类创建属性集,如箱包、鞋子、服装、文胸等。然后创建多个SKU属性,即使针对内涵相似的,但是可选项不同的也创建

多个,如尺码,用在箱包和用在服装上是完全不同的。这些分别创建,并关联不同的属性集。

产品创建时,关联一个属性集,通过属性集关联了1~N个SKU属性,然后选项这些SKU属性的组合,如2个颜色*3个尺码,

即6个组合,然后可以根据需要删除不支持的组合,这样最终得出了一个组合列表,点击”生成SKU“,就根据组合数量创建了产品

SKU,每个产品SKU对应一个组合,存储在产品SKU选项值表中。对于某些SKU,可以设置专门的选项配图。

产品和SKU属性直接关联

适合品类很多网站,比较灵活,但是维护起来数据量比较大。

为了简化,我增加SKU属性关联产品分类(可为空,表示是全局的),这样在创建产品时,可以只列出全局的 本产品分类的

SKU属性,这样就不会一下子列出很多SKU属性了。

SKU属性分为前端名称和后台名称两个,方便不同业务含义的SKU属性,在前端也能够用同一个名称显示,如颜色、容量等。

另外在操作上可以做些优化,比如用下拉列表显示可选的SKU属性时,可以同时显示该属性的属性描述,供产品维护人员参考。

图片 4

对于上面两个图的数据表设计,笔者就不在细化了,读者可以自行根据实际需要进行细化,要注意的是,基于SKU方式来管理产品时,

产品的价格、库存和图片等信息必然是放在产品SKU表中处理的,和订单、购物车等表的关联,也是通过产品SKU表,而不是产品表。

至于产品表,实际上是一个总的业务汇总和外部关联表,但实际销售的并不是它。

有些网站做的更细些,会就每个产品SKU生成独立的URL(伪静态),这里见仁见智了,但从SEO方面考虑,每个产品SKU拥有独立

的链接对收录和排名会更有优势些,可以考虑。

 1 /*
 2 Author:GaZeon
 3 Date:2016-6-20
 4 Function:getArrSet
 5 Param:$arrs 二维数组
 6 getArrSet(array(array(),...))
 7 数组不重复排列集合
 8 */
 9 function getArrSet($arrs,$_current_index=-1)
10 {
11     //总数组
12     static $_total_arr;
13     //总数组下标计数
14     static $_total_arr_index;
15     //输入的数组长度
16     static $_total_count;
17     //临时拼凑数组
18     static $_temp_arr;
19     
20     //进入输入数组的第一层,清空静态数组,并初始化输入数组长度
21     if($_current_index<0)
22     {
23         $_total_arr=array();
24         $_total_arr_index=0;
25         $_temp_arr=array();
26         $_total_count=count($arrs)-1;
27         getArrSet($arrs,0);
28     }
29     else
30     {
31         //循环第$_current_index层数组
32         foreach($arrs[$_current_index] as $v)
33         {
34             //如果当前的循环的数组少于输入数组长度
35             if($_current_index<$_total_count)
36             {
37                 //将当前数组循环出的值放入临时数组
38                 $_temp_arr[$_current_index]=$v;
39                 //继续循环下一个数组
40                 getArrSet($arrs,$_current_index 1);
41                 
42             }
43             //如果当前的循环的数组等于输入数组长度(这个数组就是最后的数组)
44             else if($_current_index==$_total_count)
45             {
46                 //将当前数组循环出的值放入临时数组
47                 $_temp_arr[$_current_index]=$v;
48                 //将临时数组加入总数组
49                 $_total_arr[$_total_arr_index]=$_temp_arr;
50                 //总数组下标计数 1
51                 $_total_arr_index  ;
52             }
53 
54         }
55     }
56     
57     return $_total_arr;
58 }
59 
60 /*************TEST**************/
61 $arr=array(
62     array('a','b','c'),
63     array('A','B','C'),
64     array('1','2','3'),
65     array('I','II','III')
66 );
67 
68 var_dump(getArrSet($arr));

###数据库服务器

先介绍几个基本概念:SKU、SPU、属性、类目。

转自颜超敏的电子商务博客

 

MySQL

SKU:stock keeping uint(库存量单位),库存控制的最小可用单位。例如Iphone 7plus  128G 银色就是一个SKU,仓库管理、采购进货、库存显示的都是SKU。不同的公司都有自己的SKU编码规则,如果有自己的仓库,在商品入库时一般会打上自己的SKU码,这样整一套库存体系就会自上而下打通,当然还有另一种处理方式,设置自有SKU码与供应商条码的对应关系,将订单转化为发货单时,将自有SKU码转化为供应商的条码。对大公司来说,推荐前一种做法,后一种由于供应商编码规则不同,或者管理规范,在实际操作往往会增加出错率。

##架构

图片 5

为了实现平台的稳定性,可扩展性,操作便捷,安全性高,便于维护等目标,应充分考虑业务发展需要,应用模块化思维,将各模块隔离。

SKU编码

## 功能模块

SPU:standard product unit(标准化产品单元),是一组标准化信息的集合,例如Iphone 7plus就是一个SPU。SPU与SKU的关系有许多种,可以一对多,一对一,如下图所示。SPU信息中应该包含SPU属性、产品图片、产品描述、产品标签。SPU和SKU之间是通过规格来链接的。SPU(Iphone 7plus)通过颜色、内容关联到SKU(Iphone 7plus  128G 银色)。SPU的库存是由其对应的SKU库存共同决定的。

### 商品

图片 6

商品模块是租赁平台的核心。用户的操作行为都围绕商品进行。在前端,商品模块为商品展示,订单,营销活动提供商品数据支撑。在后端,商品模块为订单发货,库存管理,供应商管理提供基础数据支撑。

SPU与SKU

#### 功能范围

属性:分为关键属性、销售属性、非关键属性。关键属性是指能够唯一确定产品的属性,是必填项。例如手机的品牌、型号属于关键属性;销售属性组成SKU的特殊属性,或称为规格属性,如手机的"颜色"、"内存";非关键属性指的是除关键属性、销售属性外的其他属性,如手机的手机接口类型,非关键属性不一定是非必填项,有时为了商品信息完整,也会设为必填项。属性定义对于良好的消费体验有着至关重要的关系,对搜索、索引、筛选都有至关重要的作用。

![商品模块](/Users/zxxair/工作/租赁/开发文档/商品模块范围.png)

类目:分类树,电商常用的有两层类目,前台展示类目,后端商品类目。前台类目指的是展示给消费者的类目,会根据季节、销售策略、活动进行变动;后台类目属于基础数据,不可随意变动,添加SKU时都需要选择类目,进行绑定。需要注意的是,类目树的层次不能太深,一般三层或四层,如果太深,不论对于管理还是技术性能来说,都是不利的。前台类目与后台类目可随意搭配,设置前台类目关联时,对前台类目树最深层进行设置,可让其关联后台类目任一层,可一对一、一对多。前台类目还可以对应品牌。

#### 功能设计

图片 7

#####添加商品

京东前台类目

类目:前后台分离,后台类目面向商家,供应链人员。前台类目面向用户。

二.商品基础资料设计

后台类目:三层树状分类,商品只能挂载于最后一层的叶子类目下。

在介绍商品常用概念时,也透露了很多在产品设计时关联的信息。在添加SKU时,需要选择品牌、填写一些属性,以及关于仓库管理的基础数据(长宽高、重量、供应商等)。商品中心基础资料结构图主要如下,首先是品类管理,主要包括品牌管理(中英文名、可供品类、产地(跨境电商比较重要))、属性管理(针对类目添加相关属性和属性值)、类目管理(后端类目树重中之重,确定时要考虑全面,属于基础数据,后续更改比较麻烦。),大致产品框架如图所示。

前台类目:根据不同客户端设置,PC端,移动端分别设置前台类目。支持平台商家自定义店铺前台类目。

图片 8

前后台对应关系:前台类目对应后台叶子类目和某项属性的组合。

商品中心框架图

属性:挂在具体类目下,包括属性名和属性值,属性分类(关键,销售,非关键,商品),显示类型(单选、多选、自定义),是否必填。

在添加SKU时,通过供应商去关联采购,进而影响仓库中SKU的库存。供应商在添加SKU时亦可不选择,可以在采购系统中添加关联。通过销售属性去关联SPU与SKU,同一SPU在前台显示时可以共用同一商品详情,只是通过规格属性映射到具体的SKU;针对商品的关键属性和属性值,可以在商品搜索和筛选时用上,良好的属性定义对于顾客决策树的缩短有着至关重要的作用。

属性库:将常用属性建立为属性库。

图片 9

属性分组:一个类目有很多属性,将折现属性归为一个组。

SKU使用

属性继承:将商品类目每个层级的属性提取出来,下层属性继承上层属性。

还有一个比较特殊的概念:组合SKU,主要是解决出售组合商品的问题,组合SKU的属性都继承主SKU。组合SKU的应用场景主要是添加赠品、组合售卖,与前台的商品套餐有所区别。在订单解析成发货单时,组合SKU需解析成单一SKU,方便仓库发货,更新库存。

SPU:挂在最后一层的具体类目下,并选择关键属性。如iphone 7 Plush。

三.复盘

SKU:录入SPU后选择销售属性(规格属性),并通过规格属性来连接(区分)SPU。如iphone 7 Plush (64G 与128G)。

商品中心后端属于基础数据,会被许多子系统调用,对于电商公司来说重中之重。商品中心提供接口数据进行仓库管理、采购管理、库存管理、订单管理,可扩展的商品中心结构将给公司业务发展带来很大益处。

SPU与SKU关系:一对一(商品只有一个销售属性),一对多(商品有多个销售属性),多对多(同一商品有多个名字)。同一SPU在前台显示时可以共用同一商品详情,只是通过销售属性映射到具体的SKU上。设置SPU后可依据不同的销售属性确定不同的价格。

文后扩展,很多电商公司业务定位都是B2B2C,为了扩充SKU,增加用户量,或者构建平台体系,都会允许第三方来平台管理商品,类似京东、有赞,这类平台的商品结构更加复杂,SKU需要增加所属商家,商品详情、属性值、库存都需要相互独立,在SKU、SPU纬度上增加一个商家纬度。这里不做过多扩展,感兴趣的朋友可以深入思考。

##### 商品管理

图片 10

上下架:商品批量上下架,定时上下架,缺货后自动下架。

实物商品

价格管理:爬虫获取竞品销售价,调整商品售价。

以上文章从后端角度介绍了商品中心用到的一些基础数据设计,接下来,我们主要从商品前端显示来说后台设计的那些事儿。用户平常购物接触到最多的就是商品显示页,商品列表、商品详情页的基础信息都是从商品中心获取。目前对于商品设计有着成熟的产品方案,电商网站的商品产品结构大同小异,淘宝上的商品以SPU形态显示,京东上以SKU形态显示,两种处理方式各有优劣势(表达可能不太准确,但认真研究过两者商品结构应该理解我说的不同点,下文解释)。 其实我更倾向于淘宝的商品结构,能够支持更加灵活的商品方案。

商品标签:活动(热销,新品),服务(上门维修),性能(正品)标签。

图片 11

### 库存

京东与淘宝的商品详情页

库存管理是供应链管理的重要组成部分。库存与仓库密不可分,而仓库和销售、采购相关。所以库存体系构建复杂,影响库存变动主要有采购,销售订单,仓间调拨,盘盈盘亏,预售,售后退货等因素。

商品信息主要由类目、标题、品牌、商品属性、规格(京东定义为销售属性)、价格、库存、SKU信息(毛重、长宽高等)、商品图、商品详情描述、物流信息等组成。至于经常看到的服务标签(白条、极速退款)、商品标签(热销)、活动标签(满减、优惠券)、价格标签(拼团价、活动价)、同类商品等都是在商品信息上的包装层,不在本文的阐述范围。

####功能范围

1.商品类目、商品基本信息

![库存模块范围](/Users/zxxair/工作/租赁/开发文档/库存模块范围.png)

商品类目分为两层,基础数据类目层、前台展示类目层,在添加和管理商品时,都是在基础数据类目层对商品进行管理(如下图)。商品属性、销售属性及品牌等很多数据都是在基础类目上进行管理,所以类目管理属于较为核心的工作,一定要从长远角度考虑。

#### 功能设计

在添加商品时,需选择对应的类目。前台类目在展示时,有两种处理方式:

销售库存:前台显示的销售库存。可销售库存与实物库存保持一致,不能超卖。设置活动库存,决定参与活动库存数量,设置预售库存,决定是否可下定金预定。

前台类目对应后台类目,可一对一、一对多、多对多,自由组合,动态调整。现在大部分自营电商都是用的这种类型。

调度层:将订单转换为发货单。账面库存与实物库存一致,订单流到调度层后经调度后推动至仓库发货。

前台类目直接对应商品,适合商品较少的小商家,主要是一些电商平台提供给平台上商家的类目服务,添加商品时直接选择前台展示的类目。

仓库层:发货单推送到仓库层后,操作wms系统同步响应,扣减库存并出库。

另外,类目一般是分为三层,类目树不要太深,否则将影响产品效率。

联系:一般情况下,销售层库存和调度层实物一致。不一致的情况有:允许超卖,预售,活动占用库存。

图片 12

###订单

JD商品类目

### 会员

设置商品信息、副标题(一般介绍产品卖点、促销),选择商品对应的品牌。在品牌管理中,有两种方案:

会员模块主要是管理用户信息,增加用户活跃度,开发新用户的系统。

品牌统一管理,小公司商品丰富度较少时的方案。

个人

品牌关联类目,商品丰富度高的选择。

公司

图片 13

### 运营

基本信息编辑

客服

2.商品属性

营销

商品属性包括属性名、属性值,一般都是挂在具体类目子叶下,设置必填和非必填。在设置属性值时,须保留一定的扩展性,部分允许自定义属性。商品属性管理要求强大的类目运营能力,在中小型电商平台一般会提供基础属性值,再开放自定义属性编辑,让用户来完善属性库数据。

评价

商品搜索能力,除了标题、类目,很大部分依赖于商品属性,条件筛选的基础数据也是商品属性和规格属性。完善商品属性对于良好用户体验至关重要。

### 系统管理

图片 14

网站设置

淘宝的商品属性(男装>风衣)

权限

3.规格、价格、库存、SKU信息

在购买商品时,我们会经常选择规格(销售属性),主要包括颜色、尺寸,为了支持多样化的用户需求,选择之后可以编辑规格。规格一对一确定之后,可单独设置价格、库存、商家SKU,淘宝上亦可添加条形码(69码)。也可以设置统一价、统一库存。填写商家SKU主要是为了方便对应到具体的实物,上文亦讲过,仓库和采购管理的都是具体的SKU。

仔细观察会发现,京东的商品标题是加上具体的规格,在选择规格时会跳转SKU,对于落单数据有效率提升,但是对于页面效率和体验是不如淘宝的SPU结构的。现在大部分电商都采用的是淘宝的SPU结构,亦是优质选择。

图片 15

JD规格、价格、库存、SKU设置

在淘宝上选择具体的规格后,会发现商品缩略图会发生变化,这就需要在管理商品时,针对某规格单独上传图片。这里有个设计很巧妙的地方,只是不同颜色需要上传对应的商品缩略图,而尺码不需要。

图片 16

淘宝不同颜色上传具体的缩略图,京东可上传多图

针对商品设置平台价和市场价,主要是为了商品在列表展示商品、未选择具体规格时展示,相当于商品的均价。毛重、长宽高等数据主要是为了物流而设置的,自建仓库的自营电商一般在SKU数据层就会录入这些数据,直接调用。货号即商品编码,在商城购物时会扫描的条形码就是货号。货号不等同于SKU编码,同一商品编码的商品可能是不同SKU,有着不同的规格,所以不能直接拿货号来管理SKU。

图片 17

JD商品信息填写

4.商品图、商品详情描述、物流信息

除了不同规格对应的商品缩略图,商品图还包括商品主图,一般要求图片质量较高,包括整体图和细节图。商品主图是吸引顾客眼球的必要利器,不论是列表页,还是活动页,顾客除了关注价格,主要就是商品主图,运营上架时需对商品主图较为慎重。

商品详情页现在一般会区分电脑版和手机版,由于两者的使用场景和设备不同,侧重点也不相同。为了更好的展示产品特点,可提供不同的产品详情模板,亦可支持不同的富文本编辑。

图片 18

商品详情描述

选择运费服务时,要选择对应的物流模板(包邮、按重量、按件数等),在订单处理是按照具体的物流模板计算运费。运费模板计算较为多样复杂,下篇文章详细描述讲解物流运费相关的细节。

图片 19

商品物流选择

5.其他商品信息

主要包括售后服务(发票、保修服务、退换货)、包装清单等相关说明。

6.上下架管理

设置完商品基本信息之后,设置上下架时间,亦可直接上架发布。和商品相关的活动,一旦商品下架,活动将失效,无法购买。搜索、筛选的商品范围都是在上架的商品范围进行。

图片 20

上下架设置

自营与平台电商的商品区别

在商品管理层面,平台电商提供给平台商户的商品服务与自营电商自己的商品服务有着很大不同。最大区别在于自营电商比平台电商多SKU管理,库存和属性都是基于SKU进行管理,在添加商品时,如果还要重新填写,就会造成数据冗余。所以一般会共用数据。

总结

这两篇主要介绍了商品的基础数据模块,也是商品的框架,营销活动等其他部分都是在商品的基础上进行包装升级的。由于细节较为繁琐,很难面面俱到,如果有问题,可留言交流。后面将详细讲解订单、营销等后台,若有兴趣,可关注我。

本文由星彩网app下载发布于计算机编程,转载请注明出处:PHP数组内容不另行组合排列算法,B2C电子商务系

TAG标签: 星彩网app下载
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。