|
文/张庆龙 众包核算的微任务产品化过程中，要求对于具体核算项目的定义理解必须非常清晰，但许多时候，我们容易忽视这一点。这在后期众包平台系统架构搭建时，如果出现过多界限模糊的比对判断事项，则会造成规则交错，出现科目生成混乱的情况。我们以业务招待费为例，来讲述众包核算任务拆分的细节问题。  业务招待费的理解 业务招待费是企业为生产、经营业务的合理需要而发生的应酬支出。一般表现为餐费、酒水茶费、零食水果费等杂项费用，也包含非福利捐赠性质的礼品费等。 对于绝大多数企业，特别是集团型企业，为了业务发展的需要，对内对外交流的次数逐渐增多，业务招待费的发生已成为常态，按出现次数计量，通常会占到所有报销事项的10%左右，属于高频率核算项目。 企业虽然会有大量事项需要进行会计核算，但并不是每一项都会经常发生。为什么以业务招待费用为例，主要是因为核算事项的出现频率对前期微任务产品设计至关重要。而对于出现频率较高的事项，其标准化程度与合规程度相应较高，按照产品设计最好要遵循先满足大量需求再满足少量需求的顺序，所以定位到高频率出现的核算事项更容易寻求到传统作业向互联网作业转型的突破口。  企业发生业务招待费虽然发生频率较高，但外部监管并未有条款化的干涉，甚至可以说，无论财务会计制度，还是税收制度都未给予准确的界定和计量要求。唯一需要考虑的是业务招待费的税前扣除标准中“最高不能超过当年销售（营业）收入的5‰”的规定，从系统管理角度，可以通过众包平台和销售平台对接实现数据预警。 内部监管部门对于业务招待费的约束多为金额上限分级审批，不准予发生的招待事项，严格区分业务招待费和宣传费等。 众包平台可以通过金额自动匹配电子审批，关键字（词）搜索拒回，增加科目生成条款等予以控制。若企业不愿将大额的业务招待费让外界知晓，可以通过设置微任务金额上限予以屏蔽。因此，内外部监管要求是核算微任务产品设计中必须考虑的事项。任何产品都应符合法律法规及企业规章制度的要求。核算众包平台除了满足核算工作的开展，还应兼顾账务合规与合理性的管控，且将管控更多的交给信息系统自动实现。 如何进行业务招待费原始附件拆解 原始附件是支撑会计计量和财务管理的重要凭证。发生招待事项，通常经办人员会取得发票若干和消费清单。我们需要将这些原始凭证所附带的信息拆解至尽可能的零散。 原始附件拆解是核算微任务设计的重要一环，决定了众包商需要提取哪些信息，表象层面和后台层面需要做出哪些比对判断。同时，拆解的合理性也将会影响微任务完成质量的控制体系，如果拆解不充分，则导致财务审核点不能逐一检测。如果拆解包含过多无关信息，则会导致众包商的交互体验不佳。 1.不同种类原始附件拆解 按发票类原始凭证和非发票类原始凭证定义，应将业务招待费发票和消费清单作独立对待，即每一张发票或每一页清单成为一个核算微任务。若企业要求使用粘贴单，则将发票和清单粘贴完毕后，每一张粘贴单成为一个核算微任务。这里建议有条件的企业对发票类原始凭证和非发票类原始凭证使用不同电子辨识编码（如二维码）的粘贴单，这将对系统自动化率的提高大有帮助。 2.原始凭证审核项目拆解 原始凭证审核项目拆解即按相关规定对原始凭证哪些内容需做正确与否判断，并将这些内容列示。 业务招待费原始凭证审核事项
3.建立原始附件审核项目间以及单个项目与数据库间的联系 建立原始附件审核项目间的联系和单个项目与数据库间的联系的目的，是梳理比对判断规则，用于表象层面和后台层面的连接，针对业务招待费拆解出的原始附件项目，我们能建立如下等式或判断选择： （1）发票开具时间中的年份=系统后台设定完成的当年年份（即所处的会计期间），若企业有更高财务事项发生时间管控要求，可以对月日作比对等式； （2）发票抬头=数据库中准许的公司名称，若企业允许员工使用个人姓名作为抬头，可以增加等式右边的取值范围； （3）同一商家前提下，发票金额=清单金额，若有多张发票时，发票金额合计=清单金额；若使用粘贴单时，粘贴单上发票金额合计=粘贴单金额，粘贴单金额合计=清单金额； （4）发票开具方名称=清单出具方名称； （5）对发票是否加盖发票专用章作是或否的选择判断； （6）若使用粘贴单时，粘贴单附件数量=粘贴单上发票+非发票的张数合计； （7）发票项目是支撑核算科目选择的重要信息，科目生成途径=系统自动生成+人工选择生成，后文会进行相关阐述。 电算化系统信息拆解 从财务信息的安全角度出发，众包平台应定义为核算工作的运行载体，而不是会计电算化系统本身。为此，企业需将财务共享服务的众包平台和正在使用的会计电算化系统进行对接，将电算化系统中需要审核判断的内容进行拆解，并自动传至众包平台形成微任务。 若企业愿意将众包平台直接定义为电算化系统本身，则在页面设计中直接融入微任务的展示操作框。基于预算对内核算与对外的财务管理理念，预算项目、成本中心、发生金额、事项说明等建议让经办人或财务预算管理岗的人员进行录入，而不是让众包商代为操办，这也能更明确核算众包内容的范围和微任务执行要求。  分析金蝶、用友、SAP等国内主流电算化系统操作页面和部分大型企业自行开发的电算化系统操作页面，业务招待费核算系统信息大体能拆解为:①事项描述；②报销金额；③电子审批；④收款方信息；⑤摘要及科目。 对以上五点作比对判断规则时，应充分考虑其与原始凭证之间的联系，并建立规则如下：   1.事项描述规则 事项描述不能出现违规的敏感表达。为此，拆分任务时，应注意通过数据库中违规敏感关键字段的建立，实现众包平台自动判断。例如，描述业务招待费因何发生，大多数情况不能出现违规违纪现象。不能用“宴请监管机构”的描述事项。我们可以根据经办人的用语习惯和财务制度将“宴请监管”设置为违规敏感关键字段，一旦监测出该字段，众包平台自动做出不予以报销的处理。 2. 报销金额 报销金额≤发票金额合计=清单金额，若监测出报销金额大于发票金额，众包平台将自动做出不予以报销的处理。 3.电子审批 电子审批节点人姓名=数据库预设对应金额有权审批人姓名。例如，本次招待共发生980元，数据库预设报销1000元以内需王XX审批，众包平台自动调阅电算化系统中电子审批流是否有王XX节点，如有则通过，否则，如没有则做出不予以报销的处理。  4. 收款方信息 收款方信息中收款方名称=发票开具方名称。若等式不成立，则有很大的资金支付风险，众包平台应做出不予以报销的处理，至少应作出支付预警。 5. 摘要及科目 摘要及科目对众包商的要求相对较高。市场上部分产品会通过一些细节的变化来满足不同层次用户的需。例如iPhone 6，会延伸出iPhone 6S和iPhone 6 Plus。众包微任务对于众包商而言，90%的操作内容是对不同载体上财务信息的提取。但是，也会有10%的操作内容是基于专业的判断。我们可以引入众包商分级晋升机制，以此让众包商处于不同层级执行细节要求不同的微任务。摘要和科目就属于对众包商层级有限定的核算环节。 对此，摘要生成规则首先是固定语句格式。例如，费用报销核算统一为“主语+报销+XX费”。主语可以通过提取电算化系统中的经办人信息自动生成，也可以通过众包商根据事项描述填列。XX费则直接套用会计科目即可，也可以让众包商编写宾语。 科目生成应首先尝试众包平台进行自动判定，判定失败后再让众包商选择。首先在数据库中建立一套生成条件，要计入业务招待费科目，事项描述中应有“报销业务招待费/餐费/食品费……”字样，发票项目应是“餐费/餐饮费……”，当同时满足时则自动生成业务招待费。然后众包平台将事项描述和众包商提取的发票项目与数据库进行配比，若配比成功，则计入业务招待费科目，若配比失败跳转众包商选择。最后，众包商根据获得的事项描述信息和发票项目信息在科目库中进行手动选择。 电算化系统信息拆解的第二、三、四点能实现后台层面的自动比对判断，而不用进行微任务设计。第一和第五点能合并设计成科目判定微任务，若满足系统自动生成条件，则摘要和科目自动编制选择，该微任务不会在众包平台出现。若不能满足，则出现该微任务，由指定层级的众包商执行。 业务招待费微任务的产品定义 所谓产品定义，就是一款产品的使用说明。业务招待费微任务产品定义，就是根据有关业务招待费的一系列规定及拆解出的事项，确定众包商如何执行该项微任务。我们将业务招待费微任务分为两类：一类是原始附件审核微任务，另一类是科目判定微任务。通过比对判断规则，很容易知晓需要众包商帮助企业获得哪些信息，才能与数据库中的设定信息进行校验。在业务招待费原始附件审核微任务中，我们需要众包商执行的有： 1. 无粘贴单情况下 若获得一张发票，需要提取开具时间、抬头、金额、开具方名称和项目，判断是否加盖发票专用章。若获得一张清单，则需要提取金额、出具方名称。 2.有粘贴单情况下 若获得一张仅贴有发票的粘贴单，需要提取所有发票的开具时间、抬头、金额、开具方名称、项目、粘贴单金额和粘贴附件数量，判断是否加盖发票专用章。 若获得一张既有发票又有清单的粘贴单，需要提取所有发票的开具时间、抬头、金额、开具方名称、项目、清单金额与出具方名称、粘贴单金额和粘贴附件数量，判断是否加盖发票专用章。 可以发现，众包商在这个微任务中，大多数时候都在执行提取操作，原始附件上每条信息写的什么，众包商就在任务执行框中原封不动的输入什么。例如，发票上金额是980元，众包商就在众包平台指定的输入框中填写980即可。唯一需要判断的是有无加盖发票专用章一项，对于是或否的选择，我们应充分相信经过注册认证的众包商。看似提取的项目较多，但其实因会计核算工作的特殊性，大部分内容是简单的数字和短语，微任务执行耗时会很短。最重要的是，单纯对文字数字信息的提取，大幅降低了会计的专业性要求，甚至可以说零门槛上手。而系统比对判断则大幅提升了核算质量。这一降一升，充分体现了财务共享服务中心众包的价值。 业务招待费科目判定微任务属于或有事项。支撑科目判定的原始附件，系统会自动拆解成不同微任务从而让不同众包商执行。 例如，众包商A获得一张项目为“餐费”的180元发票，众包商B获得一张项目为“食品”的800元发票，众包商C获得一张与180元发票金额、出具方一致的清单，众包商D获得一张与800元发票金额、出具方一致的清单。ABCD按照原始凭证审核微任务要求完成提取，后台程序自动将四位众包商提取的信息合并，同时提取电算化系统中的事项描述信息为“报销业务招待费”，规则判定符合生成“业务招待费”科目的条件，此时众包平台不会出现本次业务招待费科目判定微任务。若不符合生成条件，则产生微任务，由有资质的众包商根据众包平台提供的支撑判断信息，从科目库中选择。 此时，我们已经将传统业务招待费核算设计成众包微任务，配合报酬定价及支付就可以放至众包平台让众包商去执行。按照此产品化设计流程，绝大多数的会计核算事项都能转变为核算众包微任务。转变过程的重中之重是明确“尽可能让系统自动比对判断”这个思路，拆分出的微任务越短小精干，就越容易提升自动化率，同时微任务使核算工作支离破碎，财务信息安全也得到了最大保障。 随着核算事项的不断拆解，微任务会逐渐增多。这时，我们需要将不同微任务中一样的比对判断点抽出合并。例如，发票几乎会在每项核算事项中出现，而对发票内容的比对判断规则变化极少。我们可以将关于发票的微任务产品定义设置成默认值。又比如，合同的财务信息提取判断，通常为起止时间、金额、支付方式和是否有签章，我们可以将这四点作为合同的微任务产品定义设置成默认值。再比如，纳税凭证、纳税日期、纳税人名称、税种、金额和是否有征税专用章作为常规提取判断项，这些常规项就作为纳税凭证的微任务产品定义默认值……后台程序会根据这些默认值将不同的微任务执行框呈现在众包商面前。 当然，在拆解比对判断点和比对判断点合并的过程中，会出现一些个性化特征明显的特例。有一部分特例会在少数核算事项中浮现。例如，在会议费核算中通常需要一份会议通知作为必要原始附件，在人力成本核算中会需要人力成本清单，在借款核算中要求提供借款签报……。还有一部分特例会在核算事项处于某一情况中浮现，例如，差旅费核算中出现费用超标情况附上了合理超标说明，应收账款核算中出现对方未按时汇款情况取得了审批单以便计提坏账准备，成本核算中出现应摊销情况获取了摊销表……，等等。遇到这些针对性的原始附件，我们也无需担心它不能转变为微任务，任何财务信息的比对判断设计要点都能通过合理的拆解得到。 在由点到面的整个微任务产品设计过程中，参与设计的人员需要打破原有的传统会计观念，在夯实会计理论和实务的基础上，还需要对电算化程序构造和产品研发基础知识有一定了解。 认定会计核算是一个整体的人是做不好核算众包微任务的。核算众包微任务的精髓就在于没有任何门槛的表象层面和准确定义后的后台层面，通过科学合理的比对判断规则由整体到分散，再由分散到整体。核算微任务产品设计的美妙就在于想象力和严谨性的有机结合，整个过程亦能体会到“互联网+”散发的魅力。（未完待续） |
|
|
