1
00:00:13,650 --> 00:00:16,832
大家好
我将在 SERVEONE MRO 流程课程中

2
00:00:17,030 --> 00:00:19,775
负责讲解订单相关内容的尹成贤

3
00:00:20,280 --> 00:00:23,003
今天要讲的是整个流程中

4
00:00:23,330 --> 00:00:25,746
围绕订单准备了以下内容

5
00:00:26,370 --> 00:00:28,996
本课程的目标如下

6
00:00:29,749 --> 00:00:32,942
第一，理解 SERVEONE 内部的订单流程

7
00:00:33,279 --> 00:00:36,644
第二，区分各类下单方式的特点

8
00:00:37,079 --> 00:00:41,515
第三，掌握订单生成后可变更的事项

9
00:00:42,040 --> 00:00:47,792
另外在 FAQ 环节，会讲到营业、运营、各岗位负责人最常问的

10
00:00:48,040 --> 00:00:51,472
先行入库的合规凭证

11
00:00:51,769 --> 00:00:53,531
为什么要管理这类凭证

12
00:00:53,828 --> 00:00:57,778
以及凭证应当包含哪些内容我都会向大家讲述

13
00:01:00,360 --> 00:01:02,391
先做个自我介绍吧

14
00:01:02,559 --> 00:01:04,770
我目前是女儿傻爸已经三个月了

15
00:01:04,770 --> 00:01:06,813
每天都过着很幸福的时光

16
00:01:07,239 --> 00:01:10,441
爱好是运动，喜欢羽毛球

17
00:01:10,599 --> 00:01:12,569
在 SERVEONE 已第八年

18
00:01:12,569 --> 00:01:17,187
现负责运营管理系统的管理与企划

19
00:01:18,879 --> 00:01:20,493
是订单Overview

20
00:01:20,800 --> 00:01:23,715
SERVEONE 订单流程可以简要地

21
00:01:24,170 --> 00:01:26,559
用流程图来表示

22
00:01:27,579 --> 00:01:29,350
什么是订单？

23
00:01:29,409 --> 00:01:31,150
按词典的定义是这样的

24
00:01:31,279 --> 00:01:33,299
是向售卖方就某商品的

25
00:01:33,299 --> 00:01:38,156
生产、运输或服务提供提出请求的行为

26
00:01:38,763 --> 00:01:41,246
所以接下来要讲的就是

27
00:01:41,919 --> 00:01:45,734
客户如何向 SERVEONE 请求提供商品

28
00:01:46,170 --> 00:01:49,351
以及 SERVEONE 内部的相关流程如何运转

29
00:01:49,420 --> 00:01:51,671
我将围绕这些进行说明

30
00:01:52,899 --> 00:01:55,389
首先，客户进入 SERVEONE Mall

31
00:01:55,389 --> 00:01:59,503
搜索商品、加入购物车并确认购买

32
00:01:59,859 --> 00:02:03,103
经内部审批后，订单最终完成

33
00:02:03,519 --> 00:02:06,599
或者由 SERVEONE 在接到客户订单后

34
00:02:06,599 --> 00:02:12,400
基于事先设定的逻辑，综合价格、商品属性、品类

35
00:02:12,400 --> 00:02:15,891
与区域等因素进行模拟

36
00:02:16,039 --> 00:02:17,967
据此向供应商下达采购单

37
00:02:18,759 --> 00:02:23,419
对于会生成对供应商发注的直送无库存订单

38
00:02:23,419 --> 00:02:25,402
由供应商直接配送商品

39
00:02:25,679 --> 00:02:28,651
在无发注环节的情况下先创建 S/O

40
00:02:28,928 --> 00:02:33,261
对于中心 VMI 订单，S/O 随后移交至 Hub

41
00:02:33,479 --> 00:02:36,360
由 Hub 将其在库的商品进行发货

42
00:02:37,360 --> 00:02:40,693
随后按既定周期对与配送相关的事项进行处理

43
00:02:41,020 --> 00:02:42,760
双方对账，整理往来交易

44
00:02:42,760 --> 00:02:45,654
并确认债权债务

45
00:02:46,109 --> 00:02:47,801
完成向供应商的采购结算

46
00:02:48,039 --> 00:02:50,795
以及向客户的销售结算流程

47
00:02:51,399 --> 00:02:56,939
之后，还需对尚未形成现金流的 订单做例外管理

48
00:02:57,800 --> 00:03:00,515
对 SERVEONE 的整体订单流程有大致了解了吗？

49
00:03:00,960 --> 00:03:03,659
接下来我们会把该流程拆解开来

50
00:03:03,659 --> 00:03:09,118
逐步梳理各个概念
与基础业务流程

51
00:03:10,019 --> 00:03:12,129
将上述订单流程

52
00:03:12,129 --> 00:03:15,176
图示化来理解的话会更有帮助的

53
00:03:15,800 --> 00:03:20,182
当客户创建订单并生成 SERVEONE 的 S/O 后

54
00:03:20,479 --> 00:03:23,892
将依据发注模拟确定配送形态

55
00:03:24,229 --> 00:03:27,039
由供应商的 Hub 进行配送

56
00:03:28,010 --> 00:03:29,823
商品配送完成后

57
00:03:30,130 --> 00:03:33,880
会完成与供应商的采购结算
与客户的销售结算

58
00:03:33,880 --> 00:03:35,812
订单流程随之结束

59
00:03:36,440 --> 00:03:39,470
所谓创建订单是什么呢

60
00:03:39,470 --> 00:03:43,024
就是客户向 SERVEONE 订购商品

61
00:03:43,559 --> 00:03:47,342
在日常生活中，我们买什么东西时

62
00:03:47,639 --> 00:03:50,617
我们下单的方式有很多

63
00:03:51,320 --> 00:03:53,691
比如到门店当面下单

64
00:03:53,849 --> 00:03:56,091
或在网上购物

65
00:03:56,240 --> 00:04:00,265
也可以通过外送、跑腿平台下单等

66
00:04:00,839 --> 00:04:05,652
同样，客户在 SERVEONE 创建订单的方式也有多种

67
00:04:05,919 --> 00:04:08,934
主要大体分为以下四种

68
00:04:10,320 --> 00:04:12,480
由客户自行创建订单

69
00:04:12,480 --> 00:04:15,705
在 SERVEONE Mall 下单的称为前台订单

70
00:04:16,160 --> 00:04:18,862
同样是客户自行创建订单

71
00:04:19,089 --> 00:04:22,770
但不是在 SERVEONE Mall、而是在客户自有系统下单的

72
00:04:22,800 --> 00:04:24,274
称为对接订单

73
00:04:24,799 --> 00:04:27,010
客户线下提出请求

74
00:04:27,010 --> 00:04:29,122
由 SERVEONE 代为创建

75
00:04:29,399 --> 00:04:33,207
若先生成订单再推进配送，称为代理订单

76
00:04:33,920 --> 00:04:36,462
同样是客户线下请求

77
00:04:36,670 --> 00:04:38,822
由 SERVEONE 创建

78
00:04:39,000 --> 00:04:41,725
但若先行处理，则称为先行入库

79
00:04:42,279 --> 00:04:46,102
第一种客户前台订单是最常见的方式

80
00:04:46,310 --> 00:04:49,866
即客户在 SERVEONE Mall 上自行创建订单

81
00:04:50,519 --> 00:04:52,379
按照如下流程

82
00:04:52,379 --> 00:04:56,372
客户把所需商品加入购物车并提交订单

83
00:04:56,679 --> 00:04:59,210
系统会检查是否超出授信与预算

84
00:04:59,279 --> 00:05:01,652
如无问题则生成订单

85
00:05:01,880 --> 00:05:04,839
经内部审批后最终生成 S/O

86
00:05:05,799 --> 00:05:08,792
以我们采购办公用品的 SERVEONE Mall 为例

87
00:05:09,079 --> 00:05:12,379
客户直接在该 Mall 检索商品

88
00:05:12,379 --> 00:05:14,848
加入购物车并创建订单

89
00:05:16,319 --> 00:05:18,160
订单创建后

90
00:05:18,160 --> 00:05:21,039
若弹出订单已生成的提示窗口

91
00:05:21,039 --> 00:05:23,595
则表示订单已正常生成

92
00:05:24,239 --> 00:05:26,339
第二种客户对接订单是指

93
00:05:26,339 --> 00:05:29,522
客户在自有系统内创建订单

94
00:05:29,865 --> 00:05:32,859
订单会自动移交到 SERVEONE 系统

95
00:05:32,859 --> 00:05:36,344
并在 SERVEONE 系统中生成 S/O 的方式

96
00:05:36,908 --> 00:05:39,251
第一种与第二种的区别

97
00:05:39,409 --> 00:05:42,449
只在于下单站点是 SERVEONE Mal

98
00:05:42,449 --> 00:05:44,732
还是客户自有系统

99
00:05:44,920 --> 00:05:48,594
本质流程前台订单与对接订单并无差异

100
00:05:49,139 --> 00:05:51,999
从第三种代理订单开始

101
00:05:51,999 --> 00:05:53,964
SERVEONE 的角色就更为重要了

102
00:05:54,320 --> 00:05:57,400
代理订单是基于客户的线下请求数据

103
00:05:57,400 --> 00:06:02,256
由运营负责人在 SERVEONE 系统内代为创建订单的方式

104
00:06:02,880 --> 00:06:06,940
SERVEONE 订单号中以700开头的订单

105
00:06:06,940 --> 00:06:12,217
以及 SSP 代理订单以400开头的订单，皆属此类

106
00:06:12,880 --> 00:06:15,934
代理订单并非向所有客户开放

107
00:06:16,340 --> 00:06:19,170
仅限签署了代理订单特约协议的客户

108
00:06:19,170 --> 00:06:21,498
在限定范围内提供此下单方式

109
00:06:22,320 --> 00:06:26,792
流程如下，客户线下提出下单请求后

110
00:06:26,881 --> 00:06:30,673
运营负责人会按内部标准审核

111
00:06:30,930 --> 00:06:33,123
所附凭证是否合格

112
00:06:33,559 --> 00:06:38,391
仅对合格凭证的请求，由运营负责人在系统中创建订单

113
00:06:38,579 --> 00:06:41,382
随后依据授信与预算的审批结果

114
00:06:41,600 --> 00:06:44,798
如无异常则完成订单创建

115
00:06:45,550 --> 00:06:49,361
相较一般前台订单，代理订单需要额外的凭证审核

116
00:06:49,519 --> 00:06:52,950
 虽说这是为在系统内创建订单

117
00:06:52,950 --> 00:06:55,072
而需投入工作工时的下单方式

118
00:06:55,399 --> 00:06:57,781
会根据客户方的实际情况

119
00:06:57,989 --> 00:07:01,542
由内部的战略判断来决定是否采用

120
00:07:01,839 --> 00:07:06,347
是不是也好奇运营负责人实际是如何生成代理订单的？

121
00:07:07,640 --> 00:07:10,241
这个流程我会用视频来说明

122
00:07:10,409 --> 00:07:16,222
是把通过 RPA 自动化、由电脑自动执行的业务操作录屏展示出来的

123
00:07:16,978 --> 00:07:22,728
S-Portal 登录

124
00:07:27,888 --> 00:07:31,638
在未读邮件箱中查询订单代办邮件

125
00:07:33,083 --> 00:07:41,333
保存凭证及客户请求文件

126
00:07:43,494 --> 00:07:51,144
S-MRO 登录

127
00:07:58,270 --> 00:08:03,670
运营单位查询

128
00:08:04,074 --> 00:08:21,274
下载已登记的收货地址信息

129
00:08:21,867 --> 00:08:26,467
将下单请求表与地址信息对账，比对后抽取新增地址

130
00:08:26,602 --> 00:08:34,752
邮编检索第1次（邮政 App）

131
00:08:35,832 --> 00:08:43,782
邮编检索第2次（Daum）

132
00:08:44,703 --> 00:08:50,303
邮编检索第3次（道路名地址）

133
00:08:50,956 --> 00:08:53,456
生成 S-MRO地址批量登记上传文件

134
00:08:55,469 --> 00:08:57,819
S-MRO 登录

135
00:09:01,508 --> 00:09:16,508
批量登记新增地址

136
00:09:17,389 --> 00:09:26,189
下载已登记的收货地址信息

137
00:09:26,337 --> 00:09:34,837
将下单请求表与地址信息对账，比对后生成代理订单上传文件

138
00:09:38,555 --> 00:09:41,955
查询运营单位、会员 ID

139
00:09:44,632 --> 00:09:48,798
上传凭证与代理订单文件

140
00:09:48,798 --> 00:09:50,498
生成订单

141
00:09:51,579 --> 00:09:59,929
订单查询

142
00:10:00,390 --> 00:10:05,090
生成结果文件

143
00:10:06,482 --> 00:10:08,282
S-PORTAL 登录

144
00:10:11,024 --> 00:10:20,375
将PRA执行结果邮件发送给业务负责人

145
00:10:23,020 --> 00:10:25,213
最后是先行入库

146
00:10:25,520 --> 00:10:28,980
先行入库仅适用于已签署特约条款的客户

147
00:10:28,980 --> 00:10:33,893
是指在系统生成订单之前，应客户请求先行推进的处理

148
00:10:34,200 --> 00:10:38,524
分为先行入库订单和先行入库处理 这两种情况

149
00:10:38,880 --> 00:10:42,322
若客户尚未收货，则为先行入库订单

150
00:10:42,480 --> 00:10:47,078
若客户已收货，则为 先行入库处理

151
00:10:47,840 --> 00:10:52,550
正如处理这一词的语感
流程已先行完成

152
00:10:52,550 --> 00:10:56,527
之后在系统中进行对应处理的类型

153
00:10:57,200 --> 00:11:01,590
另外，考虑到先行入库订单可能会和代理订单混淆

154
00:11:01,590 --> 00:11:03,113
我补充说明一下

155
00:11:03,420 --> 00:11:06,422
代理订单走的是正常流程

156
00:11:06,610 --> 00:11:11,151
只是订单的创建主体不是客户而是 SERVEONE

157
00:11:11,359 --> 00:11:15,129
而先行入库订单不仅由 SERVEONE 发起

158
00:11:15,179 --> 00:11:18,809
而且不按正常流程，即使没有预算

159
00:11:18,849 --> 00:11:21,289
或者尚未完成审批也允许先行生成订单

160
00:11:21,289 --> 00:11:24,099
这是一个非常规类型，这样想就简单一些了

161
00:11:24,980 --> 00:11:28,920
先行入库订单和处理还会因请求

162
00:11:28,920 --> 00:11:32,876
与提交主体不同而再细分

163
00:11:33,440 --> 00:11:35,620
若客户直接向供应商提出请求

164
00:11:35,620 --> 00:11:41,043
由供应商在其前端发起
就是供应商先行入库订单处理

165
00:11:41,350 --> 00:11:46,742
若客户向销售或运营提出请求，由运营在 S-MRO 中发起

166
00:11:46,910 --> 00:11:49,312
则称为销售侧先行入库订单处理

167
00:11:50,579 --> 00:11:53,784
大家能看到标为红字的指定供应商那一部分吗？

168
00:11:54,269 --> 00:11:56,449
这一点在 FAQ 里也会出现

169
00:11:56,449 --> 00:12:00,180
由于先行入库处理发生在客户已收货之后

170
00:12:00,319 --> 00:12:04,559
必须指定实际履约的供应商

171
00:12:05,668 --> 00:12:08,711
进一步区分先行入库订单和先行入库处理这两者

172
00:12:08,919 --> 00:12:13,540
先行入库订单是先在系统里登记该订单，随后发生交付

173
00:12:13,689 --> 00:12:17,609
而先行入库处理则是客户依据对供应商的事前请求

174
00:12:17,609 --> 00:12:20,039
已提前收货的状态下

175
00:12:20,039 --> 00:12:24,456
之后再在系统内补建订单这是其最大的特点

176
00:12:25,080 --> 00:12:28,922
此外，这两种类型都要求在配送完成之前

177
00:12:29,140 --> 00:12:33,726
客户必须执行先行入库发注确认这一环节是个特征

178
00:12:34,439 --> 00:12:37,692
先行入库发注确认是仅存在于先行入库中的步骤

179
00:12:37,959 --> 00:12:42,459
用于确认客户实际先行入库了多少件并且确已收货

180
00:12:42,459 --> 00:12:46,044
可理解为客户与 SERVEONE 的双向确认流程

181
00:12:47,460 --> 00:12:50,657
什么时候会用到先行入库呢？

182
00:12:51,320 --> 00:12:54,920
刚才讲过先行入库是一种在紧急需要货物时

183
00:12:54,920 --> 00:12:57,283
可启用的非常规流程

184
00:12:57,748 --> 00:13:00,280
因此在下游紧急交付请求时

185
00:13:00,280 --> 00:13:04,362
或客户内部审批延迟时，最常被使用

186
00:13:04,540 --> 00:13:08,604
这也意味着，即便尚无审批或预算，订单亦可被创建

187
00:13:09,799 --> 00:13:14,143
因此，SERVEONE 负责人需要注意多项风险点

188
00:13:14,499 --> 00:13:17,222
由于预算为负也能建单

189
00:13:17,539 --> 00:13:19,259
在创建先行入库订单之后

190
00:13:19,259 --> 00:13:22,901
须防止因预算问题引发的取消或退货

191
00:13:23,020 --> 00:13:25,960
另外，在进行先行入库处理时

192
00:13:25,960 --> 00:13:30,170
若发注发往了非先行入库的实际协力社，可能造成重复发注

193
00:13:30,170 --> 00:13:31,568
这一点也必须特别留意

194
00:13:32,320 --> 00:13:36,418
又因客户侧先行入库审批完成后方可进行结算

195
00:13:36,705 --> 00:13:40,557
务必追加确认审批状态，以免影响销售结算

196
00:13:41,919 --> 00:13:46,300
此前在代理订单里介绍的聪明的 RPA，不仅用于代理订单

197
00:13:46,419 --> 00:13:48,351
也在执行先行入库处理

198
00:13:48,509 --> 00:13:52,290
现在通过视频了解先行入库处理业务如何进行

199
00:18:04,199 --> 00:18:07,389
到目前为止，SERVEONE 内部的四种订单生成方式

200
00:18:07,389 --> 00:18:11,839
前台订单、对接下单、代理订单，以及先行入库下单、处理

201
00:18:11,839 --> 00:18:14,863
向大家介绍了这四种

202
00:18:15,229 --> 00:18:18,291
接下来我们来看订单变更

203
00:18:19,119 --> 00:18:23,311
所谓订单变更，是指从客户下单到配送完成这一过程中

204
00:18:23,549 --> 00:18:26,129
哪些内容可以如何变更与管理

205
00:18:26,129 --> 00:18:28,105
我们做一个简要说明

206
00:18:28,640 --> 00:18:31,761
实际系统操作由运营负责人执行

207
00:18:31,890 --> 00:18:35,222
但了解哪些项目、如何修改

208
00:18:35,400 --> 00:18:38,560
有助于对内对外沟通

209
00:18:38,560 --> 00:18:40,727
因此我会简要给大家说明

210
00:18:41,479 --> 00:18:45,124
先看整体的订单管理类型

211
00:18:45,688 --> 00:18:49,279
订单管理可分为面向客户、面向协力社、以及内部业务

212
00:18:49,279 --> 00:18:51,425
这样共三类

213
00:18:51,920 --> 00:18:58,084
面向客户的工作包括因客户原因的取消、退货、换货、售后 AS 跟进、

214
00:18:58,440 --> 00:19:01,426
客户系统问询应对、紧急配送处理、

215
00:19:02,040 --> 00:19:04,141
面向协力社的工作包括

216
00:19:04,270 --> 00:19:09,266
协力社请求处理、分批交货处理、发注信息确认、交期确认、

217
00:19:09,959 --> 00:19:16,319
内部业务包括对接错误订单、PO 确认、配送凭证、基础单据管理

218
00:19:16,319 --> 00:19:19,572
大致以上这些是主要工作

219
00:19:20,780 --> 00:19:23,922
订单管理范围非常广

220
00:19:24,160 --> 00:19:28,290
这里仅就订单查询界面
可变更的若干项

221
00:19:28,290 --> 00:19:30,479
做个简要说明

222
00:19:31,479 --> 00:19:33,759
面向客户的大多数可修改项

223
00:19:33,759 --> 00:19:36,772
基本都汇总在该界面上

224
00:19:37,099 --> 00:19:39,413
可变更的客户信息

225
00:19:39,839 --> 00:19:45,441
收货地址、费用、部门、采购事由、客户参考代码等

226
00:19:45,659 --> 00:19:48,109
这些均可调整

227
00:19:49,040 --> 00:19:52,740
若因客户内部原因需更换审批人

228
00:19:52,740 --> 00:19:55,839
可在 SERVEONE 系统内变更审批人信息

229
00:19:56,760 --> 00:20:01,340
另外，订单的营业信息也可调整

230
00:20:01,419 --> 00:20:08,367
例如币种，KRW、USD 等，以及内销、本地、直出口等流通路径都可修改

231
00:20:09,120 --> 00:20:12,248
对于对接客户，已生成的订单上

232
00:20:12,248 --> 00:20:15,911
客户系统的变更不会实时同步

233
00:20:16,168 --> 00:20:20,940
此时可在订单上直接将 PR 或 PO 编号等信息

234
00:20:21,059 --> 00:20:22,826
进行手动修改

235
00:20:24,360 --> 00:20:28,984
除了文字项变更外，还可附件上传

236
00:20:29,380 --> 00:20:31,460
在订单上附加文件

237
00:20:31,460 --> 00:20:36,176
以便客户、协力社、SERVEONE 三方沟通更顺畅

238
00:20:36,839 --> 00:20:42,200
以上即通过系统处理进行订单管理
从而落实客户各项变更需求

239
00:20:44,400 --> 00:20:47,380
接下来简要说明一项一线同仁经常咨询

240
00:20:47,380 --> 00:20:51,200
且必须掌握的先行入库凭证

241
00:20:51,200 --> 00:20:53,064
然后结束本次课程

242
00:20:54,040 --> 00:20:57,425
若在没有先行入库凭证、仅口头沟通 推进，会怎样呢？

243
00:20:57,900 --> 00:21:01,021
可能因沟通失误而入错商品

244
00:21:01,021 --> 00:21:02,584
或入库数量错误

245
00:21:03,000 --> 00:21:07,320
甚至由非实际履约协力社处理，导致重复发注等

246
00:21:07,320 --> 00:21:10,565
将可能引发无数问题

247
00:21:11,199 --> 00:21:14,651
因此，为将后续可能发生的问题最小化

248
00:21:14,859 --> 00:21:17,941
并在问题发生时进行留痕、履历管理

249
00:21:18,020 --> 00:21:20,083
凭证是必不可少的环节

250
00:21:20,360 --> 00:21:24,541
营业、运营负责人需要具备判断客户所提交凭证

251
00:21:24,749 --> 00:21:29,290
是否适格是否存在潜在风险的能力

252
00:21:30,280 --> 00:21:33,860
先行入库凭证的目的在于，当客户未在系统注册订单

253
00:21:33,860 --> 00:21:37,950
却请求先行处理，或已先收货的情况下

254
00:21:37,950 --> 00:21:42,437
对客户的具体请求事项及是否收货加以明确

255
00:21:43,239 --> 00:21:48,021
无论是先行入库订单、处理都必须由请求人确认

256
00:21:48,209 --> 00:21:50,132
其请求了哪些商品及数量是否无误

257
00:21:50,479 --> 00:21:53,448
而对先行入库处理，还需进一步确认

258
00:21:53,448 --> 00:21:57,148
是否确由A协力社完成了最终交付

259
00:21:58,280 --> 00:22:01,032
基于上述凭证标准完成核对后

260
00:22:01,240 --> 00:22:03,401
再在系统中生成订单

261
00:22:03,569 --> 00:22:06,438
才能在最终结算时避免问题

262
00:22:07,221 --> 00:22:10,882
按请求渠道的不同，可被认可的凭证也不同

263
00:22:11,090 --> 00:22:13,700
其原则是尽量不另行制作新凭证

264
00:22:13,700 --> 00:22:16,416
而是优先沿用现有资料

265
00:22:17,000 --> 00:22:19,500
因此，可将客户方先行入库模板

266
00:22:19,500 --> 00:22:23,441
关账资料、计量凭证、接口对接信息等资料

267
00:22:23,639 --> 00:22:26,248
作为先行入库凭证来使用

268
00:22:26,941 --> 00:22:29,350
从这一页起到接下来的 9 页

269
00:22:29,350 --> 00:22:33,133
按先行入库凭证类型分别说明了实际案例与必填项

270
00:22:33,479 --> 00:22:38,088
以及注意事项和例外事项

271
00:22:38,920 --> 00:22:41,254
这是先行入库请求书的基本模板

272
00:22:41,690 --> 00:22:46,390
如下图所示，必填项目、客户公司、订购人、签名

273
00:22:46,390 --> 00:22:48,957
协力社、商品名、数量、规格

274
00:22:49,393 --> 00:22:52,243
需要具备上述信息

275
00:22:52,560 --> 00:22:55,050
若相同凭证以 Excel 文件形式提交

276
00:22:55,050 --> 00:22:57,171
由于内容可被修改

277
00:22:57,310 --> 00:23:00,610
必须能通过邮件或其他方式

278
00:23:00,610 --> 00:23:03,727
佐证客户确实按该内容提出了请求

279
00:23:04,479 --> 00:23:08,201
接下来是经客户前台渠道流入的 VOC 先行入库案件

280
00:23:08,379 --> 00:23:13,561
此类情形在系统内可确认客户 确已提出请求或完成收货

281
00:23:13,759 --> 00:23:18,349
因此无需额外凭证，只要能确认商品
与数量即可

282
00:23:20,439 --> 00:23:22,675
下一个是协力社交易明细单情形

283
00:23:23,249 --> 00:23:27,754
交易明细单上必须有商品与数量

284
00:23:28,308 --> 00:23:31,829
并能通过客户签名

285
00:23:31,829 --> 00:23:34,151
确认实际收货的客户是谁

286
00:23:35,319 --> 00:23:37,947
然后是客户方先行入库请求书模板

287
00:23:38,630 --> 00:23:42,100
不限定模板，但需记载商品信息

288
00:23:42,289 --> 00:23:47,781
取得请求客户签名后 还必须标注协力社名称

289
00:23:48,880 --> 00:23:51,005
接着是客户方关账资料

290
00:23:51,500 --> 00:23:56,811
与客户往来邮件中应出现
关账资料\入库明细等字样

291
00:23:56,989 --> 00:24:02,260
是否包含可据以生成订单的信息如商品、商品ID、数量等

292
00:24:02,260 --> 00:24:03,938
务必确认

293
00:24:04,829 --> 00:24:09,982
计量单据可通过截图证明入库事实

294
00:24:10,199 --> 00:24:12,582
但其中缺少下单所需信

295
00:24:12,859 --> 00:24:15,280
因此订购人、商品、商品ID

296
00:24:16,320 --> 00:24:19,889
订购数量等信息务必补记

297
00:24:21,719 --> 00:24:24,014
这是先行入库接口画面

298
00:24:24,469 --> 00:24:30,350
部分客户由客户系统
向我方发送先行入库接口数据

299
00:24:30,518 --> 00:24:33,672
该接收记录本身即可被认可为先行入库凭证

300
00:24:33,959 --> 00:24:37,490
因此此类凭证可替代客户签名，但必须核对

301
00:24:37,648 --> 00:24:41,516
其中所有必填项是否完整记载

302
00:24:42,759 --> 00:24:46,469
好的，以上我们讲解了订单的生成方式与订单管理，以及

303
00:24:46,469 --> 00:24:50,522
先行入库凭证等与订单相关的主要内容

304
00:24:50,839 --> 00:24:53,809
希望有助于大家搭建起基本框架

305
00:24:53,809 --> 00:24:55,390
长时间辛苦了

306
00:24:55,479 --> 00:24:56,150
谢谢大家