如果你是 Ragic 订户,并且有以下困扰:
(1)新手上路,总觉得搞不清楚“一张表单”跟“一笔数据”的差别是什么,不确定免费版 3 张表单的限制,指的是三张订单?还是三种不同的表单?
(2)开始设计一张表单时,不确定数据的切分怎样才适当,例如公司的文具、设备、器材要细分到每一个物品都列为一笔数据,还是每个品项一笔数据即可?(例如,如果我有10个印泥和5支笔,这会是2笔数据还是15笔数据?)要纪录家庭收支帐,是要全家人每个月一笔数据,还是每位家人/每个月一笔数据,又或者要是每位家人/每个月/每种开支类型都列成一笔数据?
(3)想要能够“自动结算”某类型、某阶段流程生成的总费用、总收入、或任何这段时间的统计信息,想知道怎么设置才能正确生成报表,或者想要比既有的功能更多一些,例如:将每段时间的统整信息都纪录成表单数据,并且可以根据这些数据做更上一层的运算与统计。
那么,今天这篇文章是写给你解惑的。如果你没有以上困扰,但希望能用 Ragic 做更多事、达成更多自动化的功能,或希望自己的表单设计更好用,也可以看看这篇文章有没有你需要的信息。
Ragic 客服偶尔会接到订户询问:我们的价格方案中,免费版可以使用 3 张表单的意思,是只能 Key 三笔订单吗?这时客服通常会举例解释, 假如你创建了订单、报价单、采购单,这是 3 张表单,但如果你只有“订单”这个表单,在“订单”表单 Key 了三笔订单数据并不会超过免费版额度(免费版的数据笔数上限为一千笔)。
在 Ragic ,创建“一张表单”(Sheet)的意思比较像是创建一个数据的框架,例如创建一张“订单”表单,并不是指填写了一份订单的数据,而是设计出之后“订单”数据要有哪些字段、和其他表单要有什么链接关系。创建/设计好一张表单之后,才能在里面新增一笔一笔的数据(Entry),例如今天有 3 个客户下订单,就在订单表单里新增 3 笔数据。
这和平常我们口语说的“拿到一张大订单”或“请给我一张报价单”不太一样,拿到“一张订单”,对应 Ragic 的用语,会是“一笔订单数据”。
在某些类型的表单中,这很直觉,不需要特别设计或思考。例如,以管理“数据”的表单来说,“员工通信录”会是“一位员工一笔数据”,“客户”是“一位客户一笔数据”;以流程管理的表单来说,经常“一次”流程是一笔数据,例如:客户下一次订单是一笔订单数据,而申请单、请购单、采购单等本身就会根据每次的流程编号,一个单号是一笔数据。
有些略微需要思考。例如:固定资产管理、可租借设备、商品、办公室用品管理、这些可以有不同的分法:设备、资产可能“每一个”都要编号,都是一笔数据(以便租借使用),例如 1 号投影机和 2 号投影机会分别是两笔数据;办公室用品和商品则可能是“一种品项”(商品编号)一笔数据,例如 50 支同型的笔会是一笔数据,而不是 50 笔数据。
这时要怎么切分一笔数据,就是依据情境、使用需求来看,需要将数据区别到什么程度,要是“大类别”或是“细目”、“细项”。以下以实例说明:
有些企业做的是 B2C 生意,每个客户都是一个消费者,“客户”表单一笔数据就代表一位客户;有些企业做的是 B2B 生意,客户是一间公司,且同一个客户可能有不同的联络窗口。此时可以在“客户”表单中,设一个“联络人”子表格,纪录一间公司的多个客户。
如果想查看自己手上总共有多少联络人窗口,不想一家一家公司子表格里查的话,可以用子表格生成新表单的功能,将所有子表格数据抽出来生成一张新的“客户联络人”表单,此时新表单每笔数据的单元会是“(联络)人”。
而以 Ragic 快速范本的“订单”范本为例,一笔订单可能包含多个商品,因此有一个商品子表格。如果为了出货管理的方便,将这个“订购项目子表格”也以子表格生成新表单,生成一个名为“订购细项”的表单,此时这张“订购细项”表单里,决定一笔数据单元的逻辑就比前面的例子略微复杂一点,是由两个维度:“订单”和“订购商品”共同决定的,一笔数据的单元 = “一笔订单底下的一个订购项目”。
例如:“订单”表单共两笔数据(两笔订单),第一笔订单的订单购买项目有两项( 3 个 A 产品, 2 个 B 产品),第二笔订单的订单购买项目有两项( 4 个 A 产品, 2 个 C 产品),则“订购细项”表单的数据笔数 = 订购项目合计 = 4 ,而非总产品数量或产品类型数。
同样是订单, Ragic 免费订单管理模块的设计中包含了商品的价格管理,在“销售商品”表单中放了“商品售价管理”子表格,可纪录每一个商品的价格波动,由此子表格生成的“商品单价管理”表单一笔数据的单元 = “一个商品的一种售价”。
有了这个数据切分得更细、更能区分不同售价的“商品单价管理”表单,设计者就可以在这组订单管理模块的“销售订单”表单“订购项目”子表格中,链接加载“商品单价管理”表单(而非无法反映同个商品不同价格的“商品”表单字段),这样每次有客户下订单时,可以根据当时的条件选择同个商品的不同售价放进订单信息中。
因此,一张表单的数据单元要怎么设置、要切分得多细,主要是依据数据、流程管理的需求去设计,以上面的例子来说,商品简单、没有价格波动或波动少的业者,可以做类似快速范本的设计,不需要有“一个商品一种售价”为数据单元的表单,管理维护较简单;而需要做售价管理的业者,就可以考虑偏向免费订单管理模块的设计,没有标准答案。
其他部分 Ragic 应用商店免费模块中的案例:
看到这里可能有人会想问:我怎么知道要怎么设计,才最适合自己的流程管理需求?底下再搭配一些例子来说明。
相关情境例如:有大量外包兼职员工的公司,希望可以根据派工单或工时表上的纪录,自动结算出每月总工时、自动产出每月薪资单;公司人资希望根据出缺勤表每月自动生成考勤纪录;会计希望根据费用报支单自动生成每月请款单;固定接收订单、申请表单的单元,希望自动结算出每季收到多少笔订单、每个业务各有多少等。
这些都是“周期结算”的需求:希望根据某一段时间的数据,在设置好的时间区段(例如每个月、每季、每年),自动统计出某些结算数据。
如果只是希望在有需要时,透过简单的点选操作结算出特定时间段的数据,那么只要来源表单有一个“时间区段”的字段,就可以透过筛选 > 加总与分析,或是报表的操作来达成。
例如某公司提供客户产品维修的售后服务,希望分析每位维修人员每个月的案件量、每个月收到多少维修单,那么只要维修单(以案件为单元)上有记载“维修人员”、“月份”的字段(例如选项字段 2018/01 , 2018/02 等), 就可以在列表页上筛选出特定月份或特定人员来查看结果,或者利用数据仪表板或分群报表来分析每个月的维修单数量,并利用数据透视获取维修人员每月份的案件量。
如果希望这些结算数据可以成为另一张表单,以便检视或根据结算表单做更进一步的操作,或者有筛选与报表无法满足的需求,那么可能就要搭配子表格,甚至使用插入参照子表格(显示从其他表单的链接)的功能,此时更需要考量清楚该张月结算(周期结算)表单每一笔数据的单元。
例如:用 Ragic 设计出缺勤系统时,如果希望每个月可以自动结算出员工的出缺勤状态,在表单设计体系结构上,可以将每一位员工每一个月的出缺勤当作一笔数据,例如,员工出缺勤表单上有一个“年份/月份”字段,像 2018 年 8 月可以是 201808 ,每天的出缺勤细节纪录在该张表单的子表格中,再使用公式(例如 SUMIF 公式)让子表格的数据自动结算、带入一般字段;每到一个新月份就新增另外一笔数据。
这样的设计是以结算周期为单元,细节放在子表格中。如果源数据新增/生成的顺序是“先有以细项为单元的表单、想依据该表单做周期结算”,例如:每天工作流程会用的表单(例如派工单)里,已经包含了所需要的细项(工时纪录),希望据此结算每月工时。那么可以另外设计一张以结算周期(月份)为单元的表单,并藉由以下的设计步骤让已存在的“工时细项”成为该结算周期表单的子表格:
(1)以结算周期为单元的表单,要放入一个以结算周期为单元的字段(月份),并先行新增未来几个月份的数据。
(2)细项表单(派工单或工时表)也要有一个相同的字段。接着将该字段设计为链接与加载自结算周期表单的月份字段。
(3)在结算周期为单元的表单中,使用显示从其他表单的链接这个功能,将细项表单插入成为参照子表格。步骤2的目的是为了在两张表单之间创建链接关系,以便插入参照子表格。
以上这两个种方法,结构其实是一样的,差别只在于来源数据的先后顺序(先有主表单数据或先有细项的子表格数据)。
“轻松订盒饭”模块的表单设计逻辑,有一部分跟上面(3-2)“先有细项(子表格)、再有结算数据(主表单)”的方法一样:在订盒饭模块里,“细项”就是“订购细项”这张表单,是由用户填写的“个人订购单”而来的,也是数据的来源;“周期结算”表单则是“统整订购单”这张表单。
最初设计订盒饭系统时,是默认每天只需要订一次盒饭,因此“周期结算”的周期设置是一天,“统整订购单”这张表单一笔数据的单元因此设置为“日期(天)”。每天负责人在“统整订购单”开立一笔数据,在日期字段填入当天日期,要订盒饭的人在个人订购单选择对应的日期,相关数据就会自动在“统整订购单”结算。
但后来同事提醒我:不是每家公司一天都只需要订一次盒饭,也有公司订午晚两餐,或者因采轮班制,订餐时间不是中午和晚上,而可能是下午或半夜。因此最后的设计,就将“周期”从“一天订一次”改成“任何时段都可以订”,“统整订购单”一笔数据的单元改成一个“订购时段”。这个调整数据单元的实例供大家参阅。
(另外,就如同前面所说的:这种结算功能通常可以用报表来达到,不一定非要产出另一张表单不可,我们设计订盒饭系统的教学文章中也提供了使用报表来结算的方式)
希望这篇文章可以提供大家一些帮助。针对此文若有任何疑问、建议,或有任何建议的教学文章主题,都可以直接响应文章,或寄信到 support@ragic.com 让我们知道!