结算从业人员常用词典1.0

1-订单款:电商平台中同一合作模式下,同一账期内满足结算条件的的订单(电商平台订单号,非商家侧订单号),所组成的商家应收结算款。

2-佣金:电商平台的第三方商家入驻模式下,满足结算条件的订单款中需要收取商家的费用。佣金一般是按照商品的销售金额的一定比例收取,当然可能存在其他规则,比如达额阶梯式。

3-优惠:优惠信息来源于优惠券,优惠券由独立的优惠券系统维护,比如创建、审核、发放。结算系统关注的主要是优惠券类型、使用范围、分摊比例、金额,因为这些会影响到商家实际应收结算款。

常见优惠类型:满减优惠、单品优惠。

4-退款:上面说的订单款是正向商家应收,而如果已经发生正向结算的订单产生了逆向退货,则需要将已向商家结算的订单款扣回,同时退还佣金。这里说的退款可能是全额的正向订单款,也可能是扣除佣金部分的净值。

5-结算单:上面所说的正向订单款、优惠、退款等各类金额需要一个单据进行汇总,再提交下游资金系统进行付款,结算单完成的就是这个功能。结算单金额是一个合计金额,里面既有正向又有逆向。

6-账期:既然结算单里填充了各类结算明细,如果要与商家结算,势必还要约定一个时间范围,只有这样结算员在与商家对账时才能确定对账范围,知道商家所说的异常订单所属账期。这个限定了结算明细的开始接收到结束接收的时间就是账期。

常见账期:T+1、周结、月结。

7-结算主体:电商平台一般都有多个主体来开展不同业务。

8-倒挂:如果某个账期的逆向退货金额大于了正向订单那款金额,则结算单的金额就会是负值,也就是站在商家角度的应付。这类结算单就是倒挂。

9-保证金:如果商家要和电商平台合作,总不能空口白牙套合作吧,也得表现出诚意。毕竟如果商家出现违规行为,首先要为未消费者买单的还是电商平台。因此电商平般都要求商家向平台缴纳的一定额度的费用,平台可以根据商家发生的违规行为进行扣减,在合作期结束后全额或部分退还。这就是保证金。

10-调整项:因订单售价或佣金比例错误、业务系统或结算系统等原因,结算员发起的针对已生成但付款的结算单进行的调整。可以说调整项是结算系统必备功能,因为没有哪个结算系统能保证自己的数据100%准确。即使系统计算准确,也会存在需要结算员人工介入进行调整的特殊场景,调整项也应运而生。

11-返利:当平台采购或销售的商品满足一定条件时,商家应允按照一定规则对平台进行奖励。标红的三个关键词是返利的必备三要素:返利商品范围、考核目标、返利规则;

当然,也有平台向商家的返利,这是提高商家营销和售后能力的手段,返利规则与商家向平台的返利规则类似。

12-线下收款:负向结算单、返利等收款方向金额都会涉及到平台向商家收款,虽然大型电商公司已经实现了商家后台支付的线上化,但是还是会有商家使用线下公对公银行电汇。因此需要有这么一个功能完成线上应收和线下实收的匹配和核销。

13-账户:账户是对全部充转提核交易明细的载体,如果结算系统完全是公对公银行卡支付,是不需要账户功能的。常见账户:

1)商家在第三方支付公司开立的账户。商家可以再这个账户看到电商平台的支付(充值)明细,满足一定条件后也支持商家提现到银行卡或平台进行代扣款;

2)保证金账户。这个账户包含商家应收、实收的创建和变更记录,能够比较全面的体现每个金额变更的节点;

3)预付款账户。预付款账户特指电商平台在自己的结算系统为商家创建的虚拟账户,用来实时记录平台与商家之间的实收和实付交易明细。

14-应收和应付:应收和应付是系统计算出的电商平台应向商家收取或支付的金额,与之对应的实收和实付。因为像预付款账户、保证金账户,可能出现应收≠实收,应付≠实付的场景,所以需要各两个字段进行标记。

15-第三方支付机构:正规的第三方支付机构必须拥有央行的认可资质,也就是必须获得央行颁发的支付业务许可证才可以开展业务。支付业务许可证的类型一般为:银行卡收单,互联网支付,预付费卡发行。

我们所熟知的互联网公司基本都有一个归属权在自己的第三方支付公司,比如阿里的支付宝、京东的网银在线、美团的钱袋宝、百度百付宝。

为什么互联网公司都要不惜代价的购买具有支付牌照的第三方支付机构呢,因为如果不使用这些第三方支付公司进行收款、付款,会存在二清风险。

16-发票模式:每一个结算单都有特定的发票模式,因为在结算单付款成功之后,需要按照对应的发票模式进行销项发票开具或进项发票核销。

17-发票核销:发票核销是一种证明商家所寄发票已收、验证有效、且匹配单据的方式,不过在会计上似乎没有发票核销的概念,更多的是让系统感知。

核销方式分为手动核销和自动核销。当然了,两种核销方式的校验内容没有差别,只是定时任务的介入能够减少人肉操作的工作量。

18-结算模式:账期款和预付款。

账期款:电商平台先按照一定账期生成结算单,然后走完审核流程之后方可向商家付款;

预付款:电商平台按照合同约定先向商家付款,然后才会按照账期款的规则逐期生成结算单,只不过预付款结算模式下的这种结算单并不会实际付款,而是去核销预付款账户的余额;

已销定结:这种结算方式不太常见,只有一些应季品类商品(端午的粽子、中秋的月饼、十一前后的大闸蟹)、书籍这种周期性销售商品会使用,因为这种商品周转率在平时比较低,只有在特定节气时令才会有高频交易。

19-期初期末余额:结算和核算维度都有期初期末余额的概念,结算层面的一般应用于预付款结算模式下的账户,用来记录每个账期开始和结束两个节点的余额。一般来说当期期末和下期期初是一致的。

20-付款方式:境内商家有公对公银行电汇、第三方支付;境外商家有渣打、花旗代理的跨境银行卡支付,境外第三方支付有PayPal。

电商后台设计思路探讨

 

 

 

对电商来讲,最核心最难做的三部分:商品、订单、库存

商品与店铺、营销、评价等相关,订单与会员、营销、支付、库存、物流等相关,库存与订单、采购、WMS、营销等相关,系统之间业务逻辑和交互异常复杂,规则多样。

  • 商品中心:主要管理SKU(最小库存单位)、SPU(标准化产品单元)、属性(关键属性、非关键属性、销售属性)、类目品牌、价格等有关商品的数据;
  • 订单中心:管理订单类型、订单状态,落下关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据,进行库存更新、订单下发等一系列动作;
  • 支付中心:主要调用第三方支付平台接口,记录支付信息(对应订单号、支付金额等);
  • 会员中心:主要管理用户等级、用户权益、积分、卡券等会员相关信息;调度中心主要将订单信息转化为发货通知单,调度仓库和物流进行发货;
  • 客服中心:主要管理退货退款、售后服务等操作,包括呼叫中心、在线客服等,与之对应的是工单系统,将客服任务进行队列管理,分配给相应的客服;
  • 营销中心:主要管理活动相关,优惠券、满减、专场活动、促销专区等,营销工具的开发对电商尤其重要,营销活动的滥用造成的用户疲劳,怎样推陈出新,给电商产品经理造成了很大挑战;
  • 运营中心:主要是对用户端进行页面配置(Banner、ICON、TAB)、价格管理等,一般会营销中心并入运营,作为其一部分;
  • 评价中心:管理商品评价和用户反馈,这并没有想象的那么简单,涉及到一些敏感词和敏感图片的筛选,以及回复内容管理;
  • 店铺管理:功能庞杂,相当于提供给B端用户一个Saas管理后台,提供管理商品、营销、订单一系列功能,主要针对一些有to B业务的电商开放平台;
  • 采购中心:管理SKU,当库存预警时,及时生成采购单进行入库,有供应商管理模块,主要进行供应商管理评级,发展新供应商等功能;
  • 财务管理:主要和订单、采购系统相关,数据准确性要求较高;
  • WMS系统(仓库管理系统):主要是入库、出库、盘点等模块,WMS主要和调度中心进行数据交互,反馈出入库状态和库存变动;
  • 物流中心:主要进行运费模板、运费管理(前端订单、真实物流成本)、物流状态保存查询(快递100、菜鸟等关联),如果是跨境电商,还涉及到和海关总署的对接,进行报关操作。
  • 风控中心:主要利用大数据进行用户信用建设、反欺诈,避免恶意评价、刷单退款等操作,构建安全的电商购物环境。

对电商后端支撑线各模块的业务功能有初步认知之后,可以看到的是,平常手机中的一个电商APP,背后是若干系统在支撑着,亦是许多技术和产品人员在辛苦付出。

用户选择商品、生成订单到订单出库、物流配送、用户签收、退货退款,信息在多系统中流转更新数据。

如何在产品设计过程中描述一个完整需求场景

产品经理玩的就是需求,需求场景更是屡玩屡爽的东西。

需求场景是一种更接地气的分析和描述用户需求的方法。它应该拥有这样的结构:

  “在某某时间(when),某某地点(where),周围出现了某些事物时(with what),特定类型的用户(who)萌发了某种欲望(desire),会想到通过某种手段(method)来满足欲望。”

一、需求场景的意义

传统的软件开发流程中,产品经理/产品策划首先会提供一份功能列表。这种功能列表所使用的描述方式往往是以程序为导向的,比如“商品列表支持按照价格从低到高排序”。

这种描述方式的弊端是:

1.产品经理得出该结论往往是因为竞争对手拥有了该功能,而非分析了用户的真实需求。

2.合作伙伴(交互设计师/10243.html”>视觉设计师/开发工程师)不能直接体会到该功能是为了帮助用户实现什么目标的,也就不知道这个功能的价值,究竟能给真实的生活带来何种变化。

而以需求场景的方式描述需求,就能够有效避免这些弊端:

1.产品经理知道这个新开发的功能是为了帮助用户解决什么问题

2.交互设计师可以从中获知这种需求场景的细节:“发生频率,需求强度,用户有什么样的能力和辅助工具”

3.其他合作伙伴更容易了解到这个功能的价值,更能够及时表达意见,否决不靠谱的功能,并对有价值的功能产生更强烈的共鸣,干劲儿十足。

二、如何判断一个使用(需求)场景有价值?

依照以前所学习的心理学知识,当用户具有某种需求时,会尝试使用各种手段来满足它。当环境中不存在转为为之设计的解决方案时,用户就会用各种尽可能能找到的东西来凑活。

当实在是找不到任何解决方案时,用户就只能憋着了。当很长时间里都无法发现解决方案时,用户就会绝望(学名叫习得性无助),并压抑尝试的行为(没有网购前,正在上班的你无论多么强烈地想给老婆买结婚纪念日的礼物,都不会去开网页)。

但是,一旦把这种解决方案拿到用户面前,请他试用,他在体验到成功的喜悦后就会对它爱不释手(想想在12306上订票成功时的心情吧,虽然确实烂)。

三、两种衡量需求场景靠谱程度的方法

调查现阶段用户是否在凑活着使用某种产品,心里在骂娘,但还忍着用(又想到了12306对吧)。

用最低廉的成本做出一个基本能用的解决方案,请目标用户试用,询问体验。

四、使用(需求)场景的描述方法和各部分必要性

前面提到,需求场景应该如此描述:

“在某某时间(when),某某地点(where),周围出现了某些事物时(with what),特定类型的用户(who)萌发了某种欲望(desire),会想到通过某种手段(method)来满足欲望。”

1.环境条件

各部分信息存在的意义如下:

when,where,with what

这几点信息其实统一地描述了需求产生的环境。从这些环境信息可以分析出诱发需求的条件和需求产生时的环境条件。

例如,“在候机时,候机厅里,用户看到手机电量过低时,会想要充电”。

基于此,可以分析出,用户是在电量低的信息刺激下,想要充电。当时他所在的位置是候机厅,一个充满电器,但是没有插座开发给乘客的地方。

2.什么样类型的人

who

需求场景还需要分析是什么样类型的人有这种需求,他有什么样的能力可以潜在地帮他实现目标。

继续前面的例子,坐飞机的手机用户都可能会有这种需求,因为他们下了飞机一般都会联系家人报平安,联系别人来接机,等等。坐飞机的这些人一般都比较有钱,会带着现金或者信用卡。

3.需求背后深层的解决方案

desire

对需求的描述有一些注意事项,那就是某种需求背后往往还有更深层次某种需求,它只是这种需求的解决方案。

比如想给手机充电是一种需求。但背后的需求可能是打发无聊、给家人保平安、看目的地城市地图、联系旅行社等等。给手机充电只是这些背后需求用户自己能想到的一种解决方案。

不断一层一层分析需求可能帮助你更清楚地了解用户到底想要什么。那么,一旦满足某种需求实在太难,满足它背后的需求也是可以的。比如,假设在候机大厅提供充电太难,还可以向用户提供电视(打发无聊)、刷信用卡的公用电话(给家人保平安)、提供该航班目的地地图(看目的地城市地图)、代定酒店(联系旅行社)。

4.现有的解决方案

method

method是用户现有的解决方案。把现有解决方案清晰地描述出来可以帮助产品团队判断竞争对手是谁。这种竞品往往不局限于同行业,只要目标需求一样,就是竞争对手。

例如,针对获取地理信息这个需求,卫星地图的竞争对手可能是纸质地图,指南针和指路大妈。

有了对竞争对手的了解,就可以更明确地知道这种用户需求是否存在,强度如何,我们的新方案有何优势,对方是否弱爆了。

综上,基于需求场景分析用户需求,可以让产品更接地气。

PM是如何看待一个团队的?

好的团队有引人入胜的产品愿景,怀着传教士般的热忱在工作。差的团队,像是有雇佣兵组成的,当一天和尚撞一天钟,靠混的。

好的团队,从业务关键指标得到启发,通过观察用户的痛点和分析用户使用过程中产生的数据,不断尝试新技术解决现实问题。差的团队,从销售人员和客户那里收集需求。

好的团队,理解谁是主要干系人,干系人所受的约束,承诺引入解决方案,方案对用户和客户有用,同时也满足业务上的约束条件。差的团队,只知道从干系人那里收集需求。

好的团队,掌握大量技术手段,这些技术手段可以快速验证哪些产品创意是值得开发的。差的团队,召集会议来制定路标和排列优先级。

好的团队,喜欢和公司内有想法的主管头脑风暴和讨论产品。差的团队,在团队之外的人胆敢提议他们做任何事的时候,会觉得自己受到了冒犯。

好的团队,产品经理、交互设计师和开发工程师坐在一起,对功能、用户体验、技术的可行性大成一致意见。差的团队,各自坐在小格子间里,没有文档和会议安排,就不会主动响应他人的请求。

好的团队,持续尝试新想法以求创新,过程中会注意保护公司的利益和品牌。差的团队,仍然坐着等待尝试的指令。

好的团队,对于创造出成功产品所需要的技能很有信心,比如强大的交互设计能力。差的团队,甚至压根就不知道交互设计为何物。

好的团队,保证开发工程师每天有时间参与产品原型的讨论,为做好产品献计献策。差的团队,在迭代计划会上展示原型,一心只为了估出工作量。

好的团队,每周直接和用户交流,以便更好的理解用户诉求,并试探用户对最新的产品创意的反馈。差的团队,以为他们自己就能代表用户。

好的团队,清楚的知道尽管他们很喜欢自己在产品上的创意,但这些创意中的很大一部分用户并不见得会接受,即使有一些用户接受了,也需要经过多个迭代的打磨才能达到预期的效果。差的团队,只开发路标上规划的内容,能按时交付,只求不出重大质量问题就阿弥陀佛。

好的团队,理解速度和快速迭代对于产品创新的价值,更知道速度来自于正确的方法,而非加班强制。差的团队,抱怨同事工作不够努力,速度太慢。

好的团队,在评估方案,确认可行性并对客户和业务有实际的价值后,共同作出承诺。差的团队,抱怨自己公司是一个销售驱动的公司。

好的团队,使用工具,以便快速了解用户是如何使用产品的,并基于数据做出判断。差的团队,认为统计分析是可有可无的。

好的团队,持续集成和发布产品,因为他们知道持续的小发布能为用户提供稳定可靠的解决方案。差的团队,在经过痛苦的集成联调之后,手工测试,一次性发布所有功能。

好的团队,专注于用户。差的团队,专注于竞品。

好的团队,在关键业务目标重大影响达成后庆祝。差的团队,在终于发布产品之后庆祝。