综合结算（精选3篇）
综合结算 篇1
1 概述
电信融合重组后形成三家全业务运营商, 运营商之间、运营商与合作伙伴之间竞争与合作的关系也将发生变化并变得更加复杂, 运营商之间的结算关系也从较为单纯的网间结算演变成多层次、多方面的复杂的结算关系。因此, 运营商为了满足综合业务结算的需求, 改善综合结算系统的处理能力, 建立一套综合的结算系统显得尤为迫切, 新系统要具备灵活的结算模式和综合业务实现能力, 才能从不断变化的网间通信中获取结算收入。建设完备的结算体系的不仅是来自外部市场竞争的要求, 也是加强企业内部自身建设的要求, 通过结算体系的不断完善, 可以全面掌握业务经营状况和全网业务流量流向, 有效地实现网内核算单位间、各类业务间的收入摊分和成本核算。
2 结算系统总体介绍
(一) 系统结构
1、系统逻辑结构
综合结算系统由三个逻辑子系统组成, 分别为结算后台核心子系统, 结算后台辅助子系统, 结算前台WEB系统组成。
2、系统物理结构
(1) 结算数据库服务器:结算数据库服务器位于整个系统的核心数据层, 运行关系型的数据库管理系统 (RDBMS) 。负责批价后结算话单的入库汇总, 月底的结算出帐, 以及响应业务人员的查询、统计分析等应用。
(2) 结算处理服务器:结算处理服务器负责对采集过来的结算话单进行实时的预处理, 批价。考虑到结算处理的话单量很大, 且实时性要求较高, 因此要求主机系统具有很高的可靠性、可用性及处理能力。
(3) WEB服务器:WEB服务器将运行应用服务器软件BEA Weblogic Server, 负责客户端浏览器的Web接入。
(4) 采集服务器:系统采用集中采集的方式, 省中心的采集服务器将负责从各个关口局采集结算话单文件, 并实时的将话单发送到结算处理服务器。
(5) 接口服务器:为提高系统的可用性, 系统将采用群集的处理方式, 接口服务器节点间通过应用的均衡部署实现负载分担、互为备份。
(二) 设计思路
1、稳定性
(1) 数据库用户划分:通过将存储不同类型表实体的数据库账户分开, 在结构上保证不同属性的表间的数据在访问权限、占用表空间等方面互不影响, 为系统稳定运行创造条件。
(2) 操作系统用户划分:通过在操作系统层将应用执行用户和软件安装用户分开, 将这两个账户分给不同人员管理, 避免核心程序及脚本被执行者修改。确保软件的稳定运行。
(3) 后台应用分层:通过对后台应用的分层设计, 确保每个后台应用程序逻辑功能相对单一, 为系统稳定性创造条件。
(4) 大量采用非常驻进程:整个系统仅有两个常驻进程, 即shedtsk和srvd。前者为系统总调度进程, 后者为后台监控服务端。这两个进程整体逻辑简单, 完成特定的调度任务和后台监控http服务。其他系统核心模块, 如采集、预处理、批价、累帐、接口等功能, 都是非常驻程序。通过系统配置的时序, 将各模块依次启动运行。
2、灵活性/扩展性
(1) 分离模版:系统通过对话单分拣参数化, 通过TICKET_FIELD、SPLIT_RULE、TICKET_FIELD_RULE、TICKET_FIELD_VALUE、TEMPLATE_RULE等参数表, 将话单分类逻辑参数化。
(2) 公式语言及COMM视图:系统的prep, billing, rate以及settevd程序均支持内置支持公式脚本。该脚本是类C语言的脚本语言。通过抽象话单的字段域, 实现话单字段的灵活组合, 同时, 在公式语言内部提供对COMM_SEARCH和COMM_RANGE表的查找, 使公式语言几乎可以支持任何参数表的快速关联查找。系统提供param_supp共享内存参数服务使快速查找成为可能。
(3) 流程模型及公式:系统通过可配置的流程模型以及prep、rate等支持任意格式的流程环节, 可以组成处理几乎所有话单格式的流程。只要编写简单的prep或rate公式脚本即可支持新业务。
3、完备性 (一致性)
(1) 流程及日志模型:系统提供流程模型以及每个环节的输入输出日志平衡性。在模型上支持话单数据的全流程数据完整性稽核。
(2) 审核稽核手段:系统提供稽核前台的稽核手段, 只要对每个特定流程提供稽核SQL语言脚本, 即可实现对全流程的稽核校验。确保数据完整性。
(三) 系统分层及功能
整个系统由四个层次组成, 即操作系统层、数据库层、后台应用层及前台应用层。
操作系统层:该层由主机存储系统组成, 提供高速的主机运行环境以及大容量的存储空间。综合结算系统可以在IBM-AIX系统、HP-UX系统、COMPAQ系统都能够很好的运行。
(1) 数据库平台:该层是一个数据库管理系统, 一般为ORACLE。综合结算能够在ORACLE系统上运行, 系统也可以通过少量的改造支持其他数据库。
(2) 后台应用:该层使综合结算系统的核心层, 由少量常驻服务 (shedtsk和srvd) 和一系列C语言应用及脚本应用组成。实现对话单的采集到累帐入库的过程。同时系统提供srvd监控后台服务、支持灵活的系统监控。
(3) WEB应用:该层主要采用J2EE技术, 提供综合结算的业务操作手段、实现参数的前台配置以及触发调用后台应用的接口 (如:参数刷新的触发、启停后台应用、导入导出数据等) 。
随着市场竞争的日益激烈, 结算收入、结算支出已经成为公司业务收入和运营成本的重要组成部分, 对公司整体效益的影响作用也越来越大, 因此加强网间结算管理, 增加结算收入、减少结算支出的工作显得越来越重要。综合结算系统就为网间结算管理提供了系统支撑, 除了要保证与其他运营商、合作伙伴的结算数据以及网内摊分数据的准确及时性, 还要不断满足市场部门提出的新需求, 加强对异常流量的监控, 增强个性化结算分析的功能, 提高分析效率, 为市场决策做好支撑。
综合结算 篇2
（征求意见稿）第一章 总 则
第一条 为规范结算会员的期货结算行为，加强对结算会员结算业务的监督管理，根据《期货公司金融期货结算业务试行办法》和《中国金融期货交易所交易规则》，制定本细则。
第二条 本细则所称结算会员结算业务是指中国金融期货交易所（以下简称交易所）特别结算会员、全面结算会员对其受托交易会员办理的期货结算业务。
第三条 结算会员、交易会员应当遵守本细则。
第二章 结算关系的确立与变更
第四条 交易会员应当委托结算会员为其进行结算，且只能委托一家结算会员为其进行结算。
第五条 结算会员受托为交易会员结算，应当签订结算协议，并报交易所备案。
第六条 结算会员与交易会员签订结算协议，应当遵守法律、行政法规、规章和交易所的规定，协议应当包括下列内容：
（一）交易指令下达方式及审查或者验证措施；
（二）保证金标准；
（三）交易会员结算准备金最低余额；
（四）风险管理措施、条件及程序；
（五）结算流程；
（六）手续费标准；
（七）通知事项、方式及时限；
（八）不可归责于协议双方当事人所造成损失的情形及其处理方式；
期保值额度后，应当及时将套期保值额度告知结算会员和交易会员。
第十五条 交易会员申请套期保值额度的，直接向交易所办理申请手续。
交易所对交易会员的套期保值申请材料进行审核，确定其套期保值额度后，应当及时将套期保值额度告知结算会员和交易会员。
第四章 结 算
第十六条 特别结算会员应当在期货保证金存管银行开设期货保证金账户，用于存放交易会员的保证金及相关款项。
全面结算会员应当在期货保证金存管银行开设期货保证金账户，用于存放其客户和交易会员的保证金及相关款项。
交易会员是期货公司的，应当在期货保证金存管银行开设期货保证金账户，用于存放其客户的保证金及相关款项。
交易会员不是期货公司的，应当在期货保证金存管银行开设期货结算账户，用于存放其保证金及相关款项。
第十七条 结算会员向交易会员收取的保证金归交易会员所有。除用于交易会员的期货交易外，任何机构或者个人不得占用、挪用。
交易会员向客户收取的保证金归客户所有。除用于客户的期货交易外，任何机构或者个人不得占用、挪用。
第十八条 交易会员是期货公司的，其与结算会员的期货业务资金往来，只能通过各自的期货保证金账户办理。
交易会员不是期货公司的，其与结算会员的期货业务资金往来，通过交易会员的期货结算账户和结算会员的期货保证金账户办理。
第十九条 结算会员应当对交易会员存入结算会员期货保证金账户的保证金实行分账管理，为每一交易会员设立明细账户，按日序时登记核算每一交易会员的出入金、盈亏、交易保证金、手续费等。
第二十六条 结算会员对其客户和受托交易会员进行风险管理，交易会员对其客户进行风险管理。
第二十七条 结算会员应当依照中国证券监督管理委员会（以下简称中国证监会）和交易所的规定建立对其客户和受托交易会员的保证金管理制度。
第二十八条 结算会员可以根据交易会员的资信及市场情况调整保证金标准。
第二十九条 结算会员调整受托交易会员的交易保证金标准的，应当在当日结算时对交易会员相关合约的所有持仓按照调整后的交易保证金标准进行结算。交易会员保证金不足的，应当在下一个交易日开市前追加到位。
第三十条 交易所开市前，交易会员结算准备金余额小于规定或者约定最低余额的，结算会员应当禁止其开仓。
第三十一条 结算会员不得向交易会员收取结算担保金。
第三十二条 全面结算会员的持仓达到或者超过交易所持仓限额的，其客户、受托交易会员均不得同方向开仓交易；特别结算会员的持仓达到或者超过交易所持仓限额的，其受托交易会员不得同方向开仓交易。
第三十三条 结算会员应当建立并执行对交易会员的强行平仓制度。
第三十四条 交易会员的结算准备金余额低于约定标准的，应当及时追加保证金或者自行平仓。交易会员未在结算协议约定的时间内追加保证金或者自行平仓的，结算会员有权对该交易会员的持仓执行强行平仓。
第三十五条 交易会员的结算准备金余额小于零且未能在结算协议约定时间内补足的，结算会员应当按照结算协议的约定对交易会员或者其客户的持仓采取强行平仓措施。
除前款规定外，结算会员可以与交易会员在结算协议中约定应当予以强行平仓的其他情形。
第三十六条 结算会员和交易会员在结算协议中应当约定强行平仓的执行原则。强行平仓可以参照交易所的执行原则，也可以采取其他原则。
誉，协助交易所处理各种突发或者异常事件。出现突发或者异常事件时，结算会员应当做好交易会员和客户的解释工作。
第四十六条 结算会员应当督促交易会员遵守期货交易相关法律、行政法规、规章及交易所规则，加强交易会员交易行为的合法合规性管理。
第七章 附 则
第四十七条 违反本细则规定的，交易所按照本细则和《中国金融期货交易所违规违约处理办法》的有关规定处理。
第四十八条 本细则由交易所负责解释。
广电融合业务综合结算体系探讨 篇3
关键词：数字家庭,融合网络,综合结算,广播电视
1 结算平台建设前景分析
1.1 结算问题现状
在交易结算方面, 目前, 国内外服务交易结算技术方面研究主要集中在电信领域的网间
互联结算, 其结算方式主要有:一是运营商之间结算通过谈判协商完成, 成功率不高;二是基于长期增量成本的结算, 包括收入分成法和完全成本分摊法, 现已成为美国、英国、日本等发达国家的主流结算方法;三是应用资费法, 解决成本法测算操作困难的问题。
我国现行的网间互联结算, 是单一的以资费 (价格) 为基础确定的结算标准, 但到目前为止, 各国在网间互联结算方面仍然没有固定的结算模式, 没有统一的定价标准。在面向数字家庭用户服务过程中, 除了跨网交易中涉及不同网络运营商之间的跟传输相关的互联网间结算, 更多的是与服务资源提供商之间针对内容的结算, 目前国内外面向内容结算方面尚无成熟的结算模型。
1.2 综合结算面临的主要问题
各广电运营商正逐步开展面向家庭的融合业务实践, 通过整合不同服务主体的内容资源面向用户提供服务, 在服务过程中跨行业、跨网络的业务形态、服务模式各异, 拥有内容资源的不同服务主体间存在业务交叉融合, 各类服务主体的相互结算及跨网结算问题需要解决, 因此, 综合结算技术研究迫切需要在以下几个方面开展工作:
一是数字家庭服务交易结算模式研究工作, 面向数字家庭开展的业务形态模式各异, 参与服务的主体日益增多、关系角色日趋复杂, 需研究数字家庭服务交易结算模式, 抽象定义结算参与角色、主体间结算关系和结算方法, 建立结算模型, 实现结算因素的扩展;
二是综合结算技术研究工作, 面向数字家庭用户服务过程中异源异类的服务数据及结算主体间的日趋复杂的结算方式需求, 需研究规则化的处理技术, 建立结算处理规则化模型, 实现结算数据的统一格式、拆分合并以及多服务主体间多模式的清算;
三是数字家庭交易结算规范及接口协议研究工作。交易结算的完成涉及多方, 且不同的业务处理要求, 需要对结算业务、结算的处理方式、结算数据传输要求进行规范, 并制定结算系统与其他系统间的接口协议, 以保证结算数据能够完整的传递、正确的解析和处理;
四是数字家庭服务交易结算系统开发工作, 围绕数字家庭综合示范业务, 开发数字家庭服务交易结算系统, 通过与数字家庭服务综合集成平台对接, 支撑数字家庭示范业务的开展, 实现数字家庭服务费用的结算。
1.3 结算模式分析
依据“结算对象”将结算分为七大类:
(1) 与内容提供商结算模式
针对付费频道, 与内容提供商依据合同定价买断、或依据详单按单点分成方式结算。如歌华有线2007年12月与广东高尔夫频道有限公司签署了数字付费电视频道合作协议, 收取的“高尔夫频道”全额收视费向主管税务机关缴纳营业税, 城建税及教育费附加后按双方约定的一定比例进行分成, 并向节目供应商提供纳税证明。
(2) 与其他运营商合作结算模式
一家运营商向其他运营商提供业务平台, 提供BOSS或BOSS接口, 用户数据集中在该运营商BOSS系统, 向当地运营商提供报表, 结算方式为根据实际收入报表按比例分成, 或按合同保底价进行分成。如杭州华数向其他运营商提供业务服务时采用此种结算方式。
(3) 与增值业务提供商结算模式
电视购物、互动游戏等增值业务, 采取委托开发或者成立合资公司的形式, 不单独收取费用, 没有与第三方SP结算, 只通过广告赢利。杭州华数通过与其他公司合资成立广告策划公司, 广告收益按照参股份比例分红。歌华自建高清购物平台, 不需要与购物平台提供商结算。歌华有线与合作单位现有的结算模式包括:保底分成、合作运营、资源互换, 目前主要的模式为前两种。
(4) 与第三方服务提供商结算模式
对于第三方接入服务模式, 结算模式主要考虑两点:一是运营商与第三方服务提供商之间进行单点结算;二是由运营商代收增值业务服务费, 然后根据事先约定好的比例和第三方服务提供商之间进行分成。
(5) 与银行结算模式
目前歌华有线利用银行渠道进行收费业务, 与银行之间按照收款金额的双方约定的一定比例进行手续费的结算。用户可通过电视选择工行存折、借记卡和信用卡完成公共事业、歌华宽带、高尔夫节目的缴费, 也可选择农商行存折和借记卡完成公共事业的缴费业务, 可以选择网银、托收、自助缴费终端机等缴费方式。高清购物平台有三种付款方式可供选择, 包括家庭POS机方式、银行支付方式和货到付款方式, 前两种付款方式需要按比例与银行结算。
(6) 与电信运营商结算模式
移动电视、手机电视跟联通、移动合作, 电信运营商掌握用户数据, 并向广电运营商提供结算报表, 依据合同按比例结算。利用手机作为小额支付的手段, 广电运营商需与移动分成。歌华有线与中国移动通信集团北京有限公司签署了歌华有线个人宽带业务用户发展代理协议。歌华有线按照移动公司一定周期内入网户数以一定的标准向移动公司一次性进行结算。
(7) 与第三方支付系统结算模式
目前, 海尔软件已经实现通过第三方支付系统 (支付宝) 购买“安心居家”服务的海尔虚拟币, 可以安全、方便快捷的进行消费、计费。后续还可以由海尔的社区店人员上门收取费用。海尔软件针对集成了感知设备网络控制器的海尔互联网电视产品或者海尔互联网电视智能终端产品, 销售时收取第一年固定服务费, 第一年以后的服务费由海尔的社区店人员上门收取或通过电视进行电子支付。对于组合计费, 将以产品的定价策略、销售策略为基础, 实现产品的计费及同社区、合作商的利益分成。
按照结算性质分, 结算方式可以分为: (1) 合同定价买断; (2) 合同保底价分成; (3) 按单点 (依据详单) 分成; (4) 按约定比例分成; (5) 按用户规模分成。
2 综合结算体系构建
2.1 基本思路
结合数字家庭服务交易结算模型、综合结算技术及结算规范和接口协议的研究, 形成数字家庭服务交易结算系统技术方案, 搭融合业务服务交易结算平台, 实现数字家庭各类业务不同结算对象间服务费用的结算, 支持不同结算业务不同结算流程的定义, 支持结算规则的灵活设置和结算因素的拓展, 能对新的结算对象以及新的结算业务类型进行扩展。
2.2 体系结构
融合业务综合结算系统实现数字家庭各类业务服务费用在不同结算对象间的综合结算。综合结算系统从广电BOSS、数字家庭服务综合集成平台、社群娱乐与公益服务平台、高清交互家庭购物平台、第三方系统及其他业务系统获得相关消费数据。结算结算系统为各业务系统提供结算报表数据, 并向金融系统发送结算资金授权指令并做反馈处理。
综合结算系统包括数据管控子系统、结算账务处理子系统和结算业务管理子系统。其中, 数据管控子系统完成与外部系统间的统一接口管理、消费数据集中汇集、高效处理和分类存储;结算账务处理子系统接收数据管控系统数据预处理的输出数据, 实现综合结算后台账务处理流程;结算业务管理子系统负责结算规则、结算定价、结算产品、结算实体等模型设置、结算账单与凭证制定与管理、结算报表查询分析、人工结算干预, 及帐户信息管理。融合业务综合结算系统总体结构如图1所示。
其中, 系统关键模块如下:
(1) 数据采集接口:数据采集实现交易数据的数据传输功能, 以及离线和在线采集过程中数据校验、采集监控、异常处理、数据备份、数据入库等采集处理功能。
(2) 数据预处理模块:完成消费记录的格式转换、分拣过滤、检错纠错、记录排重、拆合关联、业务识别, 及结算报表进行分类汇总。
(3) 数据分发模块:一方面将消费数据根据结算对象类别的不同进行分拣, 供后续系统进行结算处理, 另一方面将结算处理后形成的结算报表传送给其他系统。
(4) FTP服务模块:由采集接口将消费数据文件按要求存入上传到FTP服务器或存入数据库, 数据预处理、结算账务处理过程均要从到FTP服务器下载或上传所需数据文件。
(5) 结算账务处理模块:实现后台批处理任务的管理, 控制异常状态下的错单回收、结算回退和审核校验和黑名单处理, 及实现结算批价、帐务处理、报表处理、对帐处理、对帐不平时的结算调帐等整个结算处理过程。
(6) 规则引擎模块:规则引擎实现从定价策略分解出计费/结算规则、解析计费/结算规则完成相应的算法调用。
(7) 流程控制引擎模块:实现海量异源异类交易数据自动识别流程化处理, 主要包括流程定义、调试、调用等功能。
(8) web服务和业务管理客户端:主要包括基础管理、计费模型设置和合同管理、人工结算干预、人工清算干预、商户/合作伙伴管理等功能模块。
2.3 系统要求
(1) 建立一种可扩展的数字家庭服务交易结算模型, 满足多种业务、多种结算规则和多方实体间结算的要求, 支持结算对象和结算业务类型等结算因素的扩展, 支撑数字家庭新业态服务的引入。
(2) 解决融合网络环境下拥有内容资源的各类服务主体向用户提供服务时的相互结算问题及跨网结算问题。
(3) 实现海量异源异类结算数据自动识别流程化处理和结算处理规则化算法, 支持格式转化、综合优惠数据拆分合并以及多方多模式清算。
(4) 规范数字家庭服务交易的各种结算方式、结算流程, 以及结算系统与运营支撑系统、第三方业务系统和金融系统间的接口规范。
(5) 实现数字家庭各类服务费用不同结算模式不同结算对象间的综合结算。
2.4 关键技术
(1) 结算模型
结算模型建立过程:对不同结算模式的结算过程涉及元素信息从多维的角度进行分析, 分析参与结算的主体的类型、角色信息;分析结算主体间相互关系情况, 如收付关系、对等关系及双边关系等;分析结算主体针对结算业务的不同结算方法, 如时效要求不同的实时、定期结算, 结算额度差异的大额和小额结算, 数据处理方式不同的逐笔和轧差结算, 分成模式不同的按比例、按实际资费、按交易笔数、按固定金额清算等, 通过研究获取不同维度下结算共性元素及其属性信息。
(2) 规则引擎
规则引擎技术, 可灵活定义业务规则, 实现业务规则与业务逻辑的分离, 确保业务的快速定义与推出, 适应营销策略快速变化的要求。规则引擎从定价策略分解出计结算规则、解析结算规则完成相应的算法调用, 以实现规则化的融合计费方法和规则化的结算处理方法。规则引擎包括规则编辑与设计, 规则管理, 规则调试, 规则调度与执行四大核心模块, 并对外提供维护界面和程序调用接口。
(3) 流程控制
流程控制技术, 可灵活配置业务功能组合, 实现海量异源异类交易数据自动识别流程化处理, 主要包括工作流定义、调试、调用等功能。利用计费结算流程的融合控制方法, 通过融合流程控制提供可灵活定制的业务流程开发和加载运行。流程控制包括流程配置、流程调度、流程监控、流量监控和可视化管理五大核心模块, 并对外提供维护界面和程序调用接口。
(4) 海量数据管理
随着业务处理模型复杂化, 仍旧在磁盘数据库上通过增强硬件性能满足不断苛刻的要求越来越困难。内存数据管理能够大幅提高数据访问的性能, 而且因其平台开放性, 部署时不用对现有框架做大的调整等优点, 逐渐成为进行海量数据管理的一种标准化选择。内存数据管理是在内存中对大批量热点数据进行管理的一种机制, 它对外提供统一的数据操作接口、具备事务控制、安全检验和数据灾难恢复能力。将热点数据存放在内存中, 可提升数据访问效率, 加快处理速度。应用的交易特点是单个交易时间很短但是要同时处理大量的交易等。
小结