不同行业基本都会有自己独特的业务，甚至同行的不同企业之间的业务逻辑也会相差千里，只有最大程度抽象出通用性、标准性和普适性的系统才能够成为平台系统，平台系统开发的成本和难度可想而知。
个人深度参与或独立设计开发过的公共服务型平台系统，主要包括基础数据平台、支付平台、财务平台、结算平台、配送平台、CRM、OA等。财务系统是业务系统中重要且复杂而庞大的一个公共服务系统。
市面上有很多成熟的财务软件可供选择，比如用友、金蝶和SAP等，这三种财务软件我个人都直接开发对接和踩坑过，这样看上去好像显得更加专业，事实是财务系统至今仍是我最不想开发的系统，咩哈哈。
十多年前我首次接触财务系统，在帝都某电商公司做财务开发。所谓不看不知道，一看想不到，每天和不同系统各种SQL以及不知所云的表字段命名打交道，代码就像闹着玩似的，倍感无力，至今心有余悸。
和同事交流后发现，果然大家都是相似的压抑和不爽，看代码能当场去世的感觉。我想第一印象这么糟糕，财务系统大概会和我绝缘，想不到离开帝都到魔都工作又机缘巧合阴差阳错做了两次财务系统开发。
三次财务系统开发经历收获不少，开阔了眼界，体验到了复杂系统的设计和实现，当然也有明显副作用，就是工作量太大，每次发布上线伤害更大，但是祸兮福所倚，我的代码自信也给磨砺了出来，咩哈哈。
一入财务深似海，从此下班是路人。财务系统实现的不好就会容易变成各路神仙的SQL和Excel奇技淫巧大赛，加班分析数据和排查各种问题是常态，不知道这算不算业界共识，反正我是亲自领教过多次了。
虽然财务系统的开发体验一度让我想起法国作家司汤达著名的墓志铭”活过，爱过，写过。”，感觉心累和疲惫，但男子汉大丈夫，能屈能伸，输人不输阵，正所谓没有什么高山不能攀登，我坚信事在人为。
迄今为止，个人深度设计和开发过的财务系统包括的主要功能有：财务基础、记账、开票、报销、借款、报税、库管、履单成本、往来支付、工资福利发放、财务报账、金融保险、增值业务、供应链融资等。
财务系统常见的其他管理模块如固定资产管理、现金管理、费用管理、合同管理、银行授信、贷款管理、商业汇票、担保管理、运输管理、分账管理等等，个人也有间接做过一些二次开发支持和维护的工作。
你可能已经听说过对账、扎帐、平帐、核销、T+n、应收、应付、税控、收支、清算、结算、NC等等财务领域的术语，有很多财务专业术语还很佶屈聱牙，本文不会对这些关键术语进行严格的定义和说明。
自从见识过看一眼会升天的财务系统代码，自我感觉再看到任何恶劣晦涩的代码都能宠辱不惊以平常心对待，直到多年后接手了一个代码很过分让人脑壳疼的WMS系统，果然天外有天人外有人，咩哈哈。
根据经验，混乱的demo型财务系统的特点包括：单据多且关系复杂，基础数据不统一，有跨库操作，互联系统间关系凌乱，数据表字段很多，命名中西合璧，幻数和枚举极多，报表多而杂，性能不佳等。
再加上很多公司的财务系统报销做的稀烂，每次个人报销都感觉困难重重举步维艰体验奇差，很像公司要赖账的样子，所以我对财务完全没有任何好感，每次用财务软件都有忍不住重写的冲动，咩哈哈。
虽然财务系统在个人印象中是极其复杂繁琐费力不讨好的公共服务系统，但作为有洁癖和强迫症的完美主义者，明知工作量巨大，我还是尝试用PowerDotNet进行重写，为兴趣工作，挑战不可能也是乐趣。
将财务过程流水线化是我用PowerDotNet重写财务系统的直接动力，但还是低估了体力活的大小，恰巧有段时间心情特别特别好，对写代码热情高涨，去粗取精扬长避短大事化小小事化无一通操作就写完了。
用PowerDotNet重写后的财务平台，模块划分明确清晰，功能稳定，灵活性和可扩展性极好，实现优雅，可维护性也很强，良好的工具会让人更自信更喜欢编程，更让人积极热爱自己的编程事业，咩哈哈。
因为不同公司的主业务不同，财务系统的侧重点也会有不同，PowerDotNet这里介绍的财务平台，只是个人所从事的电商财务管理系统中很基础的通用功能的一部分，当然也预留了特殊业务的可扩展性。
PowerDotNet的财务平台系统设计和实现做了很多取舍和痛苦抉择，很多特定行业或定制化业务没有吸收整合进去，毕竟PowerDotNet最初的主要目标是要实现一套能够被绝大多数公司通用的公共服务。
面条代码 (Spaghetti Code)常有，面条系统也不少见。支付、财务、CRM、配送等系统，解耦做不好，很容易变成面条系统。面条系统的解耦难度远比业务系统按服务、模块或应用等进行划分解耦难得多。
PowerDotNet的财务平台系统在系统解耦方面做了极大努力，非常考验开发经验和业务广度，因为根据个人经验，电商财务系统和商品、库存、CRM、订单、支付、配送等系统有藕断丝连暧昧不清的关系。
混乱的Excel需求和各种数据库连接是财务这种容易解耦失败变成面条系统的直接体现。遵循PowerDotNet的开发接入规范，可以大大降低面条系统出现的可能，哪怕是财务或者WMS这种特别复杂的系统。
本人有多年一线编程经验和代码量的积累，PowerDotNet正是积累的直接产物，现在个人遇到技术和业务难题，不敢说随心所欲信手拈来，却也有一整套相对完备成熟可行的解决方案或思路，并且屡试不爽。
对于复杂的CRUD业务逻辑型开发来说，应对各种变化是大概率事件，因为“唯一不变的是变化本身”。来说是非者，必是是非人。PowerDotNet不是空口无凭嘴上说说而已，而是拿出实践成果来证明自己。
编程是非常讲究动手实践的科目，在绝对实力面前，一切方法论高情商都是务虚的浮云。 事实胜于雄辩，只有把良好的软件务实设计开发出来，才能证明事情做对了，同时你会不知不觉中发现路也走宽了。
软件开发普遍认为造轮子比调包调参更高级，PowerDotNet早期也是深受这种说法影响，仅限于框架工具研发，但个人现在的看法和做法已与过去不同，技术服务于业务，软件开发离不开业务的积累和抽象。
对于复杂的业务开发，尤其是支付和财务结算这类复杂的中大型系统，代码的业务可读性和可维护性尤为重要，PowerDotNet总结了前人开发经验，在代码业务可读性和可维护性方面做了很多实践和探索。
PowerDotNet和PowerDotNetCore不能保证系统设计和实现的上限有多高，但至少能保证下限不低，因为它们可以提供统一的编程规范，而且完善的基础设施和公共服务的高度抽象和复用更便于系统实现。
雄关漫道真如铁，而今迈步从头越。PowerDotNet和PowerDotNetCore目前在财务系统开发上已经小有所成，但距离好的精品财务系统目标还相去甚远，财务开发道阻且长，这点个人有非常清醒的认识。
环境准备
1、（必须）.Net Framework4.5+
2、（必须）关系型数据库MySQL或SqlServer或PostgreSQL或MariaDB四选一
3、（必须）PowerDotNet数据库管理平台，主要使用DBKey功能
4、（必须）PowerDotNet配置中心Power.ConfigCenter
5、（必须）PowerDotNet注册中心Power.RegistryCenter
6、（必须）PowerDotNet缓存平台Power.Cache
7、（必须）PowerDotNet消息平台Power.Message
8、（必须）PowerDotNet文件平台Power.File
9、（必须）PowerDotNet个人用户管理平台Power.PCRM（后续详细介绍）
10、（必须）PowerDotNet人员管理平台Power.HCRM
11、（必须）PowerDotNet基础数据平台Power.BaseData
12、（必须）PowerDotNet定时任务调度平台Power.TaskSchedule
13、（必须）PowerDotNet数据同步平台Power.DataX
14、（必须）PowerDotNet支付平台Power.Payment
15、（必须）PowerDotNet商品管理平台Power.Commodity（后续详细介绍）
一、财务基础
财务基础数据包括财务专用基础数据、外部业务系统基础数据和全局通用基础数据。
1、财务专用基础数据
比如收支项目、费用类型、结算方式、账期类型、税率、银行类型、银行信息、银行账户等，这些数据基本都是财务系统内专用，其他业务系统很少用或者不用，就算要用也是提供接口低频调用。
2、业务系统基础数据
财务和外部互联互通的业务系统非常多，常见的比如商品、采销、支付、配送、仓储、人员管理等，后面介绍电商财务系统会和哪些常见的业务系统进行互联互通。
使用依赖的业务系统的基础数据，常规有三种方式，PowerDotNet都给出了完美支持
（1）直接连接业务库查询，有了DBKey这非常容易，但是极不推荐这样做
（2）调用业务系统查询接口，这是我们所推崇的服务化方案，有了服务治理，开发工作量并不大
（3）在财务系统里冗余一份数据，通过数据同步平台同步基础数据至财务库，开发人手不足的情况下，这是最优方案
3、全局通用基础数据
比如区域、证件类型、币种、语言、应用终端类型、公司信息、组织信息等，从基础数据平台可以轻松获取这些数据，PowerDotNet重写的财务平台主要借助数据同步平台同步数据至财务库。
万丈高楼平地起，财务基础是没什么技术含量纯HelloWorld型体力活，但它却是财务平台稳定可靠运行的基石，根据我的经验，混乱的财务系统通常都能看到基础数据的随意变更痕迹。
不重视基础，就是不尊重软件开发规律，任何轻视基础数据抽象设计和管理的公司迟早都要受到惩罚。
二、财务应收
财务平台设计与开发涉及到大量专业的财务和会计知识，深入理解这些业务知识对开发人员的好处显而易见，在财务系统中最常见的就是各种往来账，比如应收账款和应付账款，预付账款和预收账款等。
本文根据个人开发过的财务结算系统常见的划分方式进行总结，对于一般公司而言基本够用，但实际开发应结合公司业务需要进行规划开发和管理，本文所写的单据和业务分类仅供参考。
财务应收属于通常我们所说的AR范畴。
1、应收单
应收单单据的抽象是企业应收账款的直接体现。
应收账款是指企业在正常的经营过程中因销售商品、产品、提供劳务等业务，应向购买单位收取的款项，包括应由购买单位或接受劳务单位负担的税金、代购买方垫付的各种运杂费等。
应收账款虽然是你的资产，但它现在毕竟在别人兜里，能否收回来是个未知数，所以应收账款非常的“虚”。如果应收账款占总资产的比重过大，企业的财务模型可能非常不健康。
2、收款单
应收单是应收，还没有收到手里，收款单则偏重于实收，收款单通常是在应收账款收到的情况下进行创建，但也支持特殊业务需要，先创建收款单而后真正收款到账。
以一个电商场景举例，国内机票商户创建订单，调用支付平台接口或跳转到支付平台完成支付后，得到支付单结果，国内机票变更订单状态，做其他相关业务逻辑，最后在财务平台创建收款单。
3、应收退款单
应收退款单可以认为是收款单的逆向单据，一个收款单可以创建一个或多个应收退款单。
在支付平台里我们已经介绍了支付单有三种常见类型，即扣款支付单、退款支付单和担保支付单。应收退款单发起的真实退款在支付平台都有体现。
以一个电商场景举例，国内机票商户订单支付完成后，个人用户或者企业用户发起退款，我们通常有两种链路模式进行退款处理：
（1）国内机票商户直接调用支付平台接口进行退款，得到退款支付单结果，国内机票变更订单状态，做其他业务逻辑，最后在财务平台创建应收退款单。
（2）国内机票商户调用财务平台创建应收退款单接口，财务人员在财务平台审核并调用支付平台接口退款，支付平台回调通知财务平台，财务平台回调通知商户，商户做退款后业务逻辑。
根据个人开发经验，建议使用（1）这种处理路由，因为这种模式给了商户更多的灵活性，链路也相对简短一点。
4、应收发票
应收发票是开票模块最重要的业务功能之一，涉及非常多的财务业务逻辑，包括税控、创建财务应收、代收代付、红冲、发票文件处理、虚拟开票、票据作废等。
5、应收对账
对账同样也是财务平台的重要模块。在单据多且杂的财务系统中，主要单据的对账功能必不可少，对及时发现和解决业务问题有不可或缺的作用。
在支付平台里我们已经简单介绍过对账功能，支付平台分担了一部分财务对账功能，系统解耦更加合理。
财务单据对账更偏重于实际业务单据的数据比对，而不仅仅是支付或退款数据。
6、应收核销
财务系统核销单也是很常见的单据，但是核销单功能并不是必须的，如果人手不足，可以简化设计直接在业务单据上进行核销处理而不用独立设计核销单。
小结：从我们熟悉的电商系统角度看来，财务应收更加直面终端用户，线上和线下业务都能覆盖，更加偏重于B2C，但B2B也能很好支持。
三、财务应付
财务应付属于通常我们所说的AP范畴。
根据个人经验，AP应付模块和供应链管理、库存管理、金融、运营等业务平台深度绑定，财务业务逻辑的复杂程度和业务部门的需求有直接关系，所以通用型财务平台是真不好写。
1、应付单
和应收单类似，应付单单据的抽象是企业应付账款的直接体现。
应付账款是会计科目的一种，用以核算企业因购买材料、商品和接受劳务供应等经营活动应支付的款项。
应付账款通常是指因购买材料、商品或接受劳务供应等而发生的债务，这是买卖双方在购销活动中由于取得物资与支付货款在时间上不一致而产生的负债。
2、付款单
从企业自身角度出发，收款单是收取个人用户、企业用户或者供应商的钱，也就是挣钱；付款单就是将企业的钱花出去给到个人用户、企业用户或者供应商，也就是花钱。
付款单根据经营对象的不同，又分为经营性付款单和非经营性付款单，这一节写的是经营性付款单，主要面向企业用户或者供应商，后一节单独写非经营性付款单。
付款单真正付款，前期哪怕已经被审核确认通过，最后提交真正转账付款时也需要财务人员再次确认付款信息，防止误操作导致不必要损失，出问题了也可以说是业务操作问题，这就是严谨^_^。
3、应付退款单
应付退款单又称应付退货单，主要处理公司付款后，因为各种问题导致公司退货至企业用户或者供应商的单据。
应付退款单的主要业务逻辑可以看做是付款单的逆向单据，但是实际情况是非常复杂多变的，比如因为供应商问题，常常导致公司无法拿到退款而产生坏账。
4、应付发票
和应收发票相比，应付发票逻辑就简洁多了。根据个人经验，应付发票经常要和Excel、PDF、图片等类型的文件有直接联系，处理不好，也会加重财务人员处理票据的效率和准确性。
5、应付对账
应付对账和应收对账类似，主要用于查漏补缺，对于业务逻辑极其复杂且款项很多金额很大的财务应付单据来说，每一笔单据对账都要非常到位才行，否则财务月结必然困难重重。
6、应付核销
和应收核销非常相似，应付核销单主要是由AP相关单据的核销操作而产生。
7、应付催款
应付催款单主要是由AP相关单据的审计或对账操作而产生，无法收回的款项就会形成坏账，应付催款单经常和坏账联系在一起。
小结：从我们熟悉的电商系统角度看来，财务应付更加直面B端企业或者供应商，更加偏重于B2B。
四、非经营性付款
非经营性付款仍然属于AP应付范畴，非经营性可以直观理解为不参加企业的生产经营活动，不能直接地为企业创造价值和带来收益，和经营性付款有显著区别。
1、非经营性付款单
非经营性付款单主要来源包括（日常、差旅和业务招待）报销单、借款单和付款申请单，其中报销单和借款单主要针对企业自己的雇员，所以通常和人员管理或者OA有直接联系。
非经营性付款单真正付款，和经营性付款单处理流程基本一样，不能和钱过不去，最后提交真正付款时也需要财务人员再次确认付款信息，防止误操作导致公司或个人不必要损失。
2、报销单
3、借款单
4、付款申请单
5、工资福利发放
非经营性付款单也是付款单的一种，需要通过支付平台将公司的钱转账到用户。
财务系统维护了一份人员账户信息，便于通过支付平台进行转账汇款操作，这样财务平台和支付平台、人员管理平台HCRM就可以实现互联互通了，报销、借款、工资福利发放等功能实现易如反掌。
五、简易工作流
1、流程设计
财务平台像OA系统一样，经常有需要将单据做各种业务流程控制，比如单据审批、对账、核销等操作，这就涉及到工作流的设计和实现，工作流是独立的基础框架软件，不是本文重点，仅作参考。
PowerDotNet设计实现的财务简易工作流主要有流程模板、流程规则、流程实例、流程节点（步骤）、流程节点日志共5张表，配合HCRM，支持单据撤销、通过、驳回、退回到某步骤这几种常见处理。
2、流程模板
财务简易工作流主要包括两大类流程模板，即应收流程审核模板和应付流程审核模板，业务处理状态仅包括撤销、通过、驳回、退回到某步骤四种，功能虽然不太全，但是一般财务业务单据基本够用。
应收流程审核模板，处理步骤相对较少，通常创建好应收单，普通财务人员审核即可，一般不需要财务总监或者更高级别人员审核，有些应收单据甚至在程序自动简单校对后可根据定时任务自动审核。
应付流程审核模板，相比应收流程，应付流程往往更加严格，步骤也多，除了普通财务人员，往往需要总监或更高级别人员二次或三次审核，毕竟应付是要公司大笔花钱出去，出了问题后果很难承受。
3、流程处理
目前实现的财务简易工作流，支持应收和应付常见单据处理流程，但是内部还是有不少和人员相关的业务逻辑判断处理，和HCRM耦合较深，状态判断也不够灵活，这是财务简易工作流不足的地方。
工作流规则是不怎么会变化的，但变化又是确实存在的，比如付款单审核用到的付款额度规则，可能超过N万就要总监审批，N就会根据需要调整，这种就容易出现历史单据和当前配置规则处理不一致。
解决的方法也很简单，每次创建流程实例，将当前流程规则自动生成实例规则，实例仅和实例规则匹配，这样就达到历史数据就按照历史规则进行处理，新流程数据按照新规则进行业务处理的目的。
财务简易工作流已支持业务人员审核、财务专员审核和财务总监审核，但是单据审核和工作流处理紧密相连不好移植，很难独立出通用的财务工作流抽象，这是我不推荐这个简易工作流的主要原因。
六、库存单据
库存单据管理主要包括库存入库、库存出库和库存盘点等，其中入库类型又可分为采购入库、调拨入库、移仓入库、销售退货等，出库类型可分为销售出库、调拨出库、移仓出库、采购退货等几种类型。
库存通常都在WMS或进销存系统中管理，为了解耦，财务系统理论上是不需要单独存储库存单据的。但根据经验，财务单据经常要查询库存业务数据，可以根据业务需要将固化的库存数据写入财务。
库存系统中数据量较大或者经常变动的数据，比如库存流水、库存快照等，不建议存储在财务系统中，WMS和财务的库存单据我都亲自开发过，也算是见多识广了，咩哈哈。
作为资深且涉猎广泛的程序员，对于库存和秒杀这样的有较高技术挑战的公共服务型系统，如果没有亲自开发过不能不算一种遗憾。
通常介绍到这里你就知道我可能要在某个有空的时候写写库存系统了，是的，几年前我确实为库存系统搬过砖，本人就是这样全面，但是说实话库存系统通用性比支付财务CRM等系统差远了，咩哈哈。
1、库存入库
2、库存出库
库存入库和出库涉及到每笔库存的流水，财务平台也有详细的流水记录可供查看。
七、财务报表
财务报表是财务系统必不可少的也是开发人员绕不开的一个重要功能模块，大公司里往往会产生各种财务报表，兼有各种酷炫展示，通常开发工作量非常大且枯燥。
常见报表需要支持饼图、柱状图、折线图等，报表可视化通常需要开发后端报表元数据管理模块，也需要前端和客户端技术支持，当然这不是本文重点，顺带一提。
报表需求的一个常见情形是很多中小公司跟风搞大数据，强撸“低代码平台”，连接各个系统数据库，拼接sql，不好查询的就跨库硬查，放在前端用漂亮的图表显示出来，或者再投到大屏上，很高级的样子。
报表这种对查看使用的人友好，必然对开发维护的人不友好。个人经历的业务系统报表需求，尤其是支付财务方面的报表，简直可以直接写一个“你没见过的烂代码”系列。
PowerDotNet实现的财务平台对报表开发进行了归类分析和总结，根据数据特征分组，我们通常可以将数据分为结构化数据、半结构化数据和非结构化数据三种。
结构化数据：一般是指可以使用关系型数据库表示和存储，可以用二维表来逻辑表达实现的数据。
半结构化数据：是结构化数据的一种形式，它并不符合关系型数据库或其他数据表的形式关联起来的数据模型结构，但包含相关标记，用来分隔语义元素以及对记录和字段进行分层，数据的结构和内容混在一起，没有明显的区分，因此它也被称为自描述的结构，简单的说半结构化数据就是介于完全结构化数据和完全无结构的数据之间的数据。例如：HTML、Markdown、JSON、XML和一些NoSQL数据库等就属于半结构化数据。
非结构化数据：顾名思义，就是没有固定结构的数据。
非结构化数据包括所有格式的办公文档、文本、图片、多媒体文件等都属于非结构化数据。对于这类数据，我们一般直接整体进行存储，而且一般存储为二进制的数据格式。
PowerDotNet财务系统的报表开发，主要支持结构化数据，对于非结构化或半结构化数据，要么间接转为结构化数据，要么放在大数据平台/ETL进行处理，不建议直接在关系型数据库上设计XML或者JSON格式的字段，哪怕关系型数据早就支持这些字段类型。
PowerDotNet实现的财务平台根据日常报表需求抽象提取出了常用的导入导出模板，日常报表导入和导出功能通常只需要配置下模板一行代码即可搞定。
PowerDotNet实现的财务平台支持应收、应付、发票、对账、转账、非经营性付款、NC管理等主要模块的常见报表功能，也开发了一个便于开发人员拉取数据的万能自定义报表功能。
1、简单报表
PowerDotNet开发的财务平台，对于常见的财务单据，都开发出了导出Excel功能，满足绝大多数财务基本需求。
2、复杂报表
在财务报表模块我是经常碰到洋洋洒洒几百上千行十几二十个表join连接查询的SQL，子查询嵌套子查询是常态，跨库查询也不在话下。PowerDotNet会全力拒绝出现这种难以维护的SQL出现。
虽然报表开发通常都很复杂，但作为一名3000多行复杂SQL语句曾经的直接受害者，个人强烈建议SQL Boy要向CRUD Boy转变，思路换一下，程序的可维护性、可扩展性甚至灵活性都大大加强。
对于复杂报表，PowerDotNet有三种处理方式。
第一种是实时join连表查询，相对而言sql也不怎么复杂，对于数据量不大的单据，这种就能快速解决问题。
第二种是借助PowerDotNet的数据同步平台和定时任务平台，将报表数据结转到一张表或几张表，非实时的财务报表的生成和查询逻辑可以大大简化。
第三种是针对财务系统单独创建报表数据库ReportDB，通过数据库的同步功能或借助PowerDotNet的数据同步平台和定时任务平台，专门生成报表，和第二种唯一区别是新增一个报表数据库。
根据个人经验，对于复杂报表，尤其是涉及到多系统的数据查询，定时生成宽表（大表）几乎不可避免的，否则报表查询的SQL将会是开发者和维护者的噩梦。
3、万能报表
稍微懂点财务和技术的业务人员对SQL总有一种执念，所以还是需要暴露万能报表功能给业务以备不时之需。你要说这样玩不安全，当业务系统和数据库系统权限控制是吃素的？
八、NC管理
个人开发业务系统曾经对接过用友NC和金蝶EAS，也对接过SAP，对这三种财务软件相对有点了解，本文以比较熟悉的用友NC举例。
1、NC基础
NC基础和财务基础一样，导入NC必备，虽然没什么技术含量但是需要好好开发管理起来，否则各种基础数据问题很容易导致混乱。
2、NC应付
3、NC付款
4、已导入NC单据
为了防止重复导入，需要加一层已导入NC单据，主要的应收和应付财务单据表都设计一个是否导入NC字段就没有必要了，当然多一个冗余字段也没有任何问题。
相比金蝶的EAS，导入NC需要二次开发很多东西，但是NC财务功能也更强大更完善。
5、定时导入NC
有了PowerDotNet定时任务调度平台Power.TaskSchedule和服务治理平台，只需要在财务系统开发Job接口，在定时任务调度平台点点按钮配置即可。
通常支付和财务都有很多定时任务，我个人倾向于把支付和财务分在不同分片单独进行处理，当然如果对性能相对没有要求，也可以把它们放在一个分片处理。
九、支付管理
支付和财务联系实在是太紧密了。
在支付平台里我们已经介绍过，为了将财务和支付完全解耦，让财务平台专注于财务方面的事情，支付平台专注于支付方面的事情，比如对账功能，财务平台可以直接调用支付平台接口。
当然根据个人开发经验，财务系统经常需要排查支付相关问题，为了在财务平台更好的排查支付或退款等问题，这里列出财务平台对支付功能的补充。
1、转账回调
每一笔转账汇款都有回调数据由支付平台通知到财务平台，两个平台虽然有数据冗余，却极大地提高了高频数据查询效率。
2、支付工具
有些应急单据可以直接在财务平台后台页面快速查询或者处理退款等操作，也可以按部就班，商户创建退款单，财务平台审核，支付平台发起真实退款，按照业务需求模型来完成逻辑。
对于多商户系统，财务平台支付工具的开发非常有利于解决各种各样的支付或退款问题，这是多年开发经验实践而得出来的结论。
十、税控管理
1、税控盘
税控盘是一种专用的税控装置，按照国家税务总局的“税控盘技术规范”进行研制。
金税盘和税控盘都可以用于开具增值税专用发票和增值税普通发票，也能开具货运专票和机动车发票。
个人开发财务系统使用过百旺税控盘，了解肤浅，不求甚解，小记一下，咩哈哈。
2、税控发票
税控发票主要包括开票设置、开票、发票作废、发票打印、发票上传等核心功能。
这一块需要实际开发财务页面才能理解，我的印象中百旺税控盘用到了古老的ActiveX技术，有浏览器兼容问题，好像IE兼容最好，有些国产浏览器也能正常使用。
十一、财务回调
和支付平台类似，财务系统里也有大量的回调和补偿操作，定时任务调度平台Power.TaskSchedule真是功不可没。
回调通知必须做好接口串行化和业务数据幂等性处理，防止高并发情况下导致的单据重复创建。
1、业务系统回调财务平台
典型的如订单系统（各个商户）、支付平台、门店系统、结算系统等通过财务平台接口创建财务单据，完成互联互通。
2、财务平台回调业务系统
主要功能就是在财务平台完成单据业务逻辑后通知各个业务系统财务处理结果。
正是因为支付、财务、订单等系统的回调非常频繁，借助服务治理平台，PowerDotNet的回调可以大大简化，完全可以抽象成一个独立系统或应用专门处理回调通知逻辑，减少各个系统的重复建设。
十二、文字识别
个人开发过的主要功能，就是基于OCR的文字识别功能，自动识别发票图片上的发票号和财务业务单据进行关联处理，接着将发票图片自动转换为pdf文件最后上传文件服务器。
这部分功能主要偏重于客户端程序实现，当然也做了网页版自动识别补偿程序，不过客户端跑的非常稳定，网页版几乎没有用到。
十三、互操作
和支付平台类似，财务平台也需要调用很多二方库三方库甚至要通过外部SDK进行socket通信处理（码枪、高拍仪、自助开票机等），在税控处理模块还可能需要使用古老的ActiveX技术。
我们可通过regsvr32命令行注册COM组件直接在项目中引用DLL，或者通过DllImport实现互操作，这些可参考支付平台互操作一节，本文不再赘述。
十四、系统交互
财务平台和很多内部业务系统保持互通关系，有些公司很多业务系统都必须围绕财务平台开展业务活动，不然会引发各种混乱，整理下个人开发和对接过的几种常见互联系统。
1、订单系统
这里的订单系统可以直接理解为支付平台抽象出来的商户系统，比如电商领域常见的各种业务订单、账户充值等，都可以抽象为商户订单系统。
PowerDotNet实现的财务平台提供了所有商户支付和退款的兜底方案，如果商户系统因为业务逻辑频繁改动而造成支付和退款业务难题，财务平台可以代劳。
2、支付系统
在支付平台里已经对支付和财务之间的关系有详细介绍，这里不再赘述。
3、CRM
财务系统和HCRM、PCRM及ECRM都有紧密联系，不论是偏向B2C业务的应收还是偏向B2B业务的应付，都离不开和人打交道。
4、结算系统
结算系统我个人也亲自开发过，甚至模块划分AR、AP、发票、对账单这些都几乎相同。
我个人参与开发过几个复杂而重要的结算应用，手头还有源代码，C#和Java版本的都有，但我对它们都不太满意，甚至短期内也没有写出来介绍的冲动，咩哈哈。
毋庸置疑，财务和结算联系最紧密，很多公司都把两者放在一个系统中进行开发。
5、账户系统
账户系统可以抽象理解为一个支付商户（特殊的订单系统），账户的充值、提现、支付和退款都需要在财务系统中有体现，都要有详细的往来账流水。
6、商品系统
毫无疑问，企业在正常的经营过程中，必须有销售商品、产品、提供劳务等业务，订单系统主要提供商品售卖服务，所以商品（含虚拟商品）系统必然是和财务系统紧密联系在一起的。
商品也是大多数企业非常重要的核心业务系统，某些特殊场景除了商品，还要考虑辅料、原料（物料）等，商品管理系统的设计直接关系到采销、财务、订单等核心业务系统的复杂度。
7、库存系统
如你所知，库存系统主要用于管理商品库存，主要包括商品入库和商品出库。
商品主要由供应商提供，我们常见的企业进销存系统或采销系统或仓储WMS系统或供应链系统等都和库存紧密相关，可以算作库存系统的核心。
8、门店系统
门店系统主要经营企业线下业务，相较于线上业务，线下业务模式可能远远不同于线上，但门店系统的经营活动最终也会将各业务单据写入到财务系统中去。
9、票券系统
财务系统记账时可能需要记录票券系统的单据号，这些单据号主要用于分析对账和排查问题，这样票券系统就和财务系统产生关系，不过这种联系并不算非常紧密。
10、其他系统
其他如运营、活动等电商业务系统也和财务有些联系，根据业务需要，这些系统和财务都会或多或少有交互，本文就不再介绍了。
小结：个人认为开发好财务系统，需要深厚的专业知识和技术积累，也需要高屋建瓴的抽象和洞若观火的编码能力，还需要不同系统组织和管理的支持，否则财务系统很可能拖泥带水成为业务发展的瓶颈。
十五、其他
本人开发过的财务平台的其他主要功能还包括：
1、补偿和重试
因为财务和各个业务系统互联互通非常频繁，所以需要定时做补偿和重试操作，和支付平台类似，借助定时任务调度平台，这些都是没有难度的体力活，写写接口配置下补偿和重试job即可。
2、敏感数据脱敏处理
财务敏感数据必须加密存储，比如人员账户信息等必须赋予最高数据安全性。
3、数据结转与备份
和支付平台一样，自从用了DataX数据同步平台，这一块几乎不用写任何代码了，咩哈哈。
4、财务监控
和支付平台类似，也根据实际业务和部署情况，抽象出财务业务正常指标，按需动态配置监控和预警参数，可进行短信、邮件、钉钉、微信等方式进行业务告警。
对于转账付款等和金钱有关的操作要设置安全付款额度指标，超过额度就给相关财务人员发送预警提示。
5、财务接口安全
财务平台所有信息敏感的（尤其是和钱、余额、积分、资金、流水等相关的）接口必须经过严格的授权、鉴权、认证（校验token）、验签等操作，这些都是服务治理平台分内的事情。
6、成本中心
主要功能包括履单成本和运营成本，单据实现和AP付款单有很多相似之处，对于公司成本控制有直接帮助。
7、商务排款
AP模块重要功能，根据公司政策，给各采销小组分配额度，实现对供应商的有计划的付款，主要包括财务基础配置、额度管理、排款管理、税票管理和付款管理。
8、增值业务
增值业务通常是公司主业之外的副产品，也就是副业，某些公司的副业绝大多数不如鸡肋，食之相当无味，弃之毫不可惜，说不定等你辛苦开发完了，公司倒闭也没用到，咩哈哈。
9、财务报帐
偏重于企业台账的流程管理，主要单据包括报销申请单、借款申请单、付款单、收款单、立项申请单等。
10、供应链融资
主要抽象出借款单、还款单、利息单、费用单等单据用于实现供应链融资管理，对于传统财务开发来说，还算有点业务上的亮点。
11、存货核算
涉及到物料、商品、库存等业务单据复杂的财务逻辑计算，和采销、生产加工以及库存管理密切相关，可能还要和SAP等系统对接。
12、金融保险
此金融保险非彼金融保险，业务需求多样随意的结果就是命名多样而随意。
13、发票打印
发票打印模块个人开发过的最重要的功能是打印模板的制作，以及浏览器插件的安装和各种兼容问题排查，说多了都是泪，就让这一切都随风去吧，咩哈哈。