HYPERLINK " \t "_blank" 千寻创意 创意千寻 想象力没有边界，未来谁来把握？
海南移动通信有限责任公司
BOSS系统三期扩容
技术建议书-设计方案
亚信科技(中国)有限公司
2001年8月
目 录
31 概述
海南移动业务运营系统现状
移动通信网现状
业务配置现状
计费营帐业务运营现状
网络结构现况
现存问题和需求分析
本期项目建设的目的
32 海南BOSS系统集成设计
系统建设原则
高效性原则
高可靠性原则
高灵活性和可扩展性原则
系统设计连续性原则
系统建设策略
建设前瞻性
投资保护规范
规范化程序设计
规划目标分阶段实施
总体设计思想
海南移动的业务特点
系统总体技术要求
系统总体结构设计
主机系统设计
主机系统设计概述
BOSS系统主机设备
网络结构设计
原网络结构
网络结构设计
网络设备配置
数据库选型设计
数据库选型原则
大容量数据处理的解决方案
应用软件设计
软件的结构特点分析
CORBA技术体系结构
海南BOSS系统的特点
亚信BOSS产品设计优点
33 海南BOSS系统软件方案
AICBS系统设计特点
AICBS技术特点
新型的业务管理模型
新型的系统管理模型
WEB方式的营业管理
大容量数据处理
34 AICBS系统功能模块
AICBS体系结构
融合设计
系统架构
运行环境
计费处理功能模块
数据采集
话单予处理
数据传输
计费资源管理
批价系统
错单处理
重计费处理
入库系统
综合帐务管理模块
帐务系统结构
客户出帐管理
帐单管理
核销管理
欠费管理模块
坏帐、呆帐处理
无主户的管理
帐务级优惠与资费管理
实时限额
帐务稽核
帐务结算
综合营业管理模块
综合业务系统的特点
营业系统的总体设计思想
营业系统的总体架构
网上营业的实现
业务管理功能说明
大客户管理
信用度管理
代理商管理
统计分析模块
分析主题
报表及即席查询系统
创建统计分析应用的策略及原则
网间结算模块
网间结算的功能结构
数据采集系统
话单预处理系统
话单批价及结算系统
话单入库系统
统计分析系统
操作员管理和维护系统
资源管理系统
统计报表系统
网间结算系统的技术特点
系统监控模块
BOSS系统监控模块EagleSight概述
总体设计思想
Eagle Sight总体结构
前台子系统
监测系统功能结构
监控系统任务管理模块
系统数据结构
Eagle Sight网络结构图
海南BOSS监控管理
外围系统
自动停开机系统ASOG
查询系统
话单转发
自动报表生成系统
高额话单检测系统
安全性管理
稽核系统
日志管理
任务管理
数据分发
数据管理
统一接口管理
35 AICBS产品规格说明
系统功能组成
客户服务
业务受理
业务变更
查询服务
缴费管理
系统管理
资源管理
资费管理
开通管理（包括工单管理）
帐务处理
外部帐务数据处理
出帐处理
帐务管理
销帐
帐单管理
帐单分发
帐务稽核
欠费管理
无主详单管理
大客户管理
大客户业务受理
大客户资料统计
大客户资料查询
代销商管理
代销商资料管理
代销商资源管理
代销商费用结算
代销商业绩考核/调整
信用度管理
初始信用度维护
信用度规则维护
黑名单管理
黑名单发送
黑名单接收
黑名单查询
辅助系统
权限管理
系统监控
操作日志管理
系统备份
统计报表管理
系统接口
与计费系统（AICBS或其他计费系统）之间的接口
订购信息传递接口
用户资料传递接口
用户资料查询接口
详单传递接口
系统基础资料传递接口
与联机指令系统的接口
开户接口
销户接口
订购状态查询接口
订购状态变更接口
订购属性查询接口
订购属性变更接口
口令变更接口
与客服系统的接口
详单查询接口
帐单查询接口
帐务情况查询接口
36 AICBS功能模块列表
模块关系图
计费系统
帐务系统
营业系统
自动停开机系统
网间结算系统
外围系统
37 容灾系统建议
容灾设计
主备系统磁盘级的同步更新
应用软件的数据复制
数据业务容灾设计
系统切换管理子系统
概述
海南移动三期BOSS系统是一个基于计算机网络、数据库及相关应用技术，用以支持海南移动业务运营的综合性系统平台。本系统设计方案从主机、数据库、网络、应用软件等几方面进行了综合考虑，追求它们在结构、设计上的一致性及整体性能的优越性。同时，我们充分考虑到了原有系统的建设、使用情况和移总BOSS规范，在总结以往建设经验的基础上，力求充分利用现有的资源，结合我司推出的BOSS产品的技术特点，提供实现实时计费和营业、帐务系统的全套应用软件和系统集成方案。我们的系统设计方案严格遵循中国移动BOSS建设的相关技术和业务规范，基于海南移动的具体情况和未来市场、技术的发展趋势，充分体现了我司计费和营业及帐务系统产品的标准化、高效率、高可用性、灵活性和可扩展性以及技术先进性等特点。
海南移动业务运营系统现状
移动通信网现状
海南移动近几年来努力开拓市场，不断推出新业务，截至2001年5月止，海南省现有的业务种类（包括本地通等）的用户已达到553739户，其中全网GSM用户322861户，神州行用户227054户，TACS用户3824户，平均每月话单数8000万张左右。全省共有4个GSM交换机端局，3个关口局，其中移动交换机端局和关口局综合设置。全网交换系统交换能力为80万户。
海南GSM交换机配置容量表
表
序号
交换局名称
交换机种类
交换机容量
备主
1
金美1
Nokia DX200i
23万
端局和关口局合设
2
金贸
Nokia DX200i
34万
端局和关口局合设
3
三亚
Nokia DX200i
13万
端局和关口局合设
4
金美2
Nokia DX200i
10万
业务配置现状
目前海南移动的计费、营帐系统设置在海口市金盘大道电信枢纽大楼11层计费中心机房。
海南计费、营帐系统设计支持80万用户的计费、营帐处理需要。该中心现有的主要软硬件设备如下：
(1)服务器主机：Sun公司的E6500(2台，GSM计费主处理机)、Sun公司的E5500(4台，一台网间结算数据库服务器、一台TACS计费与高额服务器、一台营帐服务器、一台营帐系统接入服务器)、Sun公司的E3500 (1台，用于磁带库服务器以及测试服务器)、 Digital的Alpha 2100(2台，用于大客户管理系统)、Sun公司的E250(2台，一台预处理服务器、一台智能网采集)、Sun公司的R220（1台，用于网间结算应用），HP D380(1台，用于集团公司漫游数据传送)、HP D230(1台，用于深圳帐务中心漫游数据传送)、若干Ultra系统的工作站（用于监控平台、银行联网等）；
(2)网络设备：采用Cisco公司的Cisco7507路由器(2台)、Catalyst 5505交换机(2台)、Catalyst 2924 LAN交换机(1台)等；
(3)数据库：采用ORACLE8数据库系统；
(4)磁盘阵列：采用Sun公司的9台A5000（每台容量14*9G），3台A5100（每台容量14*18G），1台A5200（容量6*36G），约容量；
(5)磁带库：采用Exabyte公司的E-480磁带库(2T)。
计费营帐业务运营现状
现有计费、营帐系统的应用软件主要完成：
(1)联机计费数据采集及处理：海南移动在各MSC、GMSC、SSP及SCP局址侧均设置有计费数据采集机，计费中心联机采集计费数据并做进一步处理．目前原始话单保存1个星期、明细话单在线保存3个月，磁带长期保存．
(2)营收管理：对营业受理和话费收费进行管理，并具有查询和统计功能．
(3)帐务管理：完成综合帐单的生成，发送银行数据的生成，同时还具有部分查询和统计的功能．
(4)信用管理：对用户的信用度、高额、欠费等进行管理。
(5)号码资源管理：对移动电话号码资源进行管理。
(6)SIM卡资源管理：对SIM卡资源进行管理．
(6)大客户管理：对大客户资料进行管理．
(8)查询统计：对各种数据和报表进行查询和统计．
(9)参数管理：对系统所有的参数进行管理．
(10)计费数据的联机采集系统
海南省计费中心计费数据的联机采集，采用分散采集方式，即各计费点（各地MSC、GMSC等）均设置计费采集机。为保证计费数据的完整、准确，在联机采集时还同时保存原始脱机介质(磁带或光盘)作为计费处理的备份，以便当联机采集不能进行或出现数据丢失时，通过计费介质(磁带或光盘)脱机采集。海南移动网目前有4个Nokia GSM交换机分别设置在海口的金美局、金贸局；三亚的金鸡岭局。（关口局与端局合设）；有2个Ericsson TACS交换机设置在海口的白坡和三亚，智能网平台、短消息平台设在海口，
网络结构现况
海南省目前的业务管理系统集中设在海口，下设32个营业厅；12个业务代办点，分布在全省19个地市县，无地市业务中心，营业厅与各分公司经营、管理同处一个局域网。海南省业务中心网络配有Cisco7206路由器两台、3640路由器一台；Catalyst5505交换机各两台。并通过64K DDN 与中行、工行、建行、交行及农行实现点对多点方式联网。各分公司通过64K DDN 与海口、儋州、三亚3个本地网中心局相连，本地网中心局与省计费中心间用E1(2Mbit/s)电路连接。全省各分公司及营业网点都使用数字终端直接登陆业务系统，目前最忙时有600多个进程登陆系统。具体网络结构图见海南MDCN业务系统网络图：
现存问题和需求分析
系统的性能、容量和可扩展性不能满足高速发展的市场的需要；
系统的发展受C/S体系结构的局限；
系统现有的体系结构无法适应未来业务聚合的需求；
系统缺乏数据备份和容灾措施；
系统要求提供极度灵活的资费调整手段以满足不断变化的运营业务需求；
系统要求提供更加灵活的优惠管理手段；
系统要求提供详细的统计和图表功能支持市场经营决策；
系统要求提供集中式的应用一级的管理平台；
支持大容量用户数据；
支持全面、开放的相关外部接口。
本期项目建设的目的
为海南移动计费结算中心提供一套完整的移动业务计费、结算及客户服务系统，和一套包含话音、Internet等多业务的综合帐务系统。能实现多业务在帐务级融合的一客一单系统；
建设一个具备处理100万用户能力的软硬件系统；本期BOSS系统建设的容量满足期为2004年底，全省约100万用户的计费、结算、营业、帐务等业务处理，以及移动公司业务管理的需求；
系统满足中国移动相关移动通信客户服务及计费管理系统技术规范和具体业务及技术需求；
提供高于现有系统，符合未来发展方向的系统功能及性能指标；
提供包含地市分公司与省公司连接的网络设备和主机系统的集成技术方案，提供计费系统与邮政、银行等系统间的业务接口，根据标书的要求，本方案不包括营业网络设备的内容；
提供包含数据库、OS、中间件平台、应用软件等一切完成需求所必备的软件系统的解决方案；
发挥亚信公司公司在移动通信及IP计费及营帐系统建设中的技术优势，充分体现我司融合计费产品产品的大容量、高效率、高灵活性及可扩展性、满足未来业务聚合的需求的特点，为中国移动海南分公司的业务发展提供有力的、长期的运营支持系统。
遵循集团公司有关的BOSS业务、技术规范的要求，按照“两级系统、三层结构”的原则，对我公司计费、结算、帐务、业务管理及客服等功能进行集中、统一的规划和整合，使中国移动BOSS系统成为一体化的、信息资源充分共享的支撑系统。
三期BOSS系统是一个多业务融合的计费和营业帐务管理系统，要求能够统一管理用户的业务资料，实现统一的用户服务界面和“一客一单”功能；并能够实现多业务捆绑销售，融合计费，交叉优惠等功能；
(1) 计费产品产品的大容量、高效率、高灵活性及可扩展性、满足未来业务聚合的需求的特点，为中国移动海南分公司的业务发展提供有力的、长期的运营支持系统。
(2) 遵循集团公司有关的BOSS业务、技术规范的要求，按照“两级系统、三层结构”的原则，对我公司计费、结算、帐务、业务管理及客服等功能进行集中、统一的规划和整合，使中国移动BOSS系统成为一体化的、信息资源充分共享的支撑系统。
(3) 三期BOSS系统是一个多业务融合的计费和营业帐务管理系统，要求能够统一管理用户的业务资料，实现统一的用户服务界面和“一客一单”功能；并能够实现多业务捆绑销售，融合计费，交叉优惠等功能；
海南BOSS系统集成设计
系统建设原则
根据中国移动计费和营业系统的技术规范和海南移动的技术要求，本期系统的设计原则是在海口设省级计费营业和结算中心，海南省分公司计费系统采用集中管理、集中计费、集中营业的模式。该设计原则合理地利用了系统资源、强化了系统的集中管理能力、系统的整体性得到了提高，但是不可避免地带来了巨大的系统负荷瓶颈以及管理维护压力。因此在我们的系统设计必须要本着高效性、可靠性、灵活性、可扩展性以及系统建设和升级的连续性的原则，充分体现集中方式带来的优越性，同时对于由与完全集中而产生的困难提供切实可行的解决方案。
高效性原则
计费和营业及帐务系统的效率是考量一个系统的成败的关键，系统的效率受到多种条件的制约，如：网络条件、主机等物理平台以及操作系统、数据库系统等软件平台和应用系统的结构都会对系统产生重大影响，其中，网络、主机和基础软件平台（OS、数据库）受到市场和投资的限制，作为系统集成商，除了尽力改善底层的网络、主机、数据库及操作系统的性能指标以外，应用系统的结构设计对于系统整体效率的影响尤为巨大。所以，我司的方案着重说明了软件解决方案的独特设计，通过应用我司特有的一些先进的软件技术，结合对系统网络和硬件平台的适当增容，更加充分地利用硬件平台的处理能力，在优先的硬件投入的前提下，实现尽可能高的系统运行效率，满足实时计费系统和营业帐务系统的速度需求。
高可靠性原则
本项目建设的另一个重要的设计重点是系统的高可靠性。系统的高可用性和可管理性能构成了高可靠性的基础。为了实现高可靠性目标，我们除了提供高度可靠的设备配置以及经过反复测试合格的优化的程序代码外，从网络、主机、数据库、应用系统和系统安全、系统管理功能等多个角度考虑了系统高可靠性的实现。主要通过：网络设备备份、HA技术、数据复制、权限管理和日志管理、应用软件系统的实施集中监控功能等技术手段保证系统的可靠运行以及故障报告及恢复功能，提高的反应能力和容错、容灾能力。
高灵活性和可扩展性原则
本项目要支持未来几年的发展，在系统建设上也必然是分步实施的。因此，系统的灵活性和可扩展性尤为重要，所选硬件设备必须能充分估计未来的扩展情况，软件设计更是必须模块化、可配置，能够适应一定时间内的业务变化，可扩展性强，并保证系统在进行扩展时，不影响系统的正常运行。可扩展性设计要保证系统扩展后其性能有近似线性的提高，在增加新业务模块时，也不影响原有应用软件的正常运行。
系统设计连续性原则
系统的设计的连续性原则体现在：按照系统目前的结构，当用户数增加时，系统可以通过增加主机的CPU数目、增加内存、增加硬盘甚至通过增加主机数量的方式来实现系统平滑地升级，以有效地保护系统现有的投资，同时，也可以保护目前系统的应用软件，以避免对应用软件的整体结构作大的改动。
系统建设策略
根据中国移动通信和计费的发展趋势和海南省的实际情况，同时结合亚信公司公司在系统集成领域和联机实时计费领域多年来的经验，对本期系统的建设，我们提出如下建议：
建设前瞻性
系统的建设必须高起点、严要求，必须具有技术上的先进性和前瞻性。本期系统的建设目标是能满足2004年的用户和业务发展需要，只有技术上的领先才能保证系统的较长生命周期。
根据目前移动计费的发展趋势，是否联机和实时已是衡量一套业务系统先进性的标志，因此本期系统必须满足联机和实时。同时在系统建立的初期，就有一个良好的设计规划，考虑国内移动通信的迅速发展和将来可能面临的来自国内外的竞争，结合国外系统的建设经验，避免在建设过程中走弯路、走错路。
投资保护规范
在海南移动移动业务系统的建设中，应当尽量的利用海南移动公司已购置的现有资源，在充分利用现有资源的基础上，建成一个具有先进的、高效的移动业务系统。
我们在设计中，充分利用原有设备，并对原有设备进行了合理的扩容和升级，最大限度地保护原有投资，同时，原有设备依旧可以负担运行多种关键应用，决不影响业务运行。这也归功与上一期系统建设和设计的可扩展性与前瞻性。
规范化程序设计
一套成熟的移动业务系统建设，需要进行长时期的试运行与完善。国内的许多信息系统的建设发展过程证明，如果一套系统不具备完善的系统设计，或难于维护和管理，系统便很容易走向失败。因此，在海南移动公司移动业务系统的建设过程中，我们应该采用规范化，立足长期的设计思想，进行周密的系统配置，并遵循软件工程学的标准建立完善的系统文档，在规范化设计初期就充分考虑到系统以后的维护和可能的修改，以有利于系统的长期发展和生存周期。
规划目标分阶段实施
本期移动业务系统建设周期短、时间紧，随着新的交换系统扩容，新系统要求马上建成。但一套完善移动业务系统是一个长期的建设过程，因此应有一套计划安排，加之海南移动自身的建设也有一个逐步完善的过程，因此，我们建议海南移动业务系统的建设采取“规划目标，阶段实施”的策略，逐步建成一套功能完善、技术先进、具有世界一流品质的业务运营支撑系统。
总体设计思想
海南移动BOSS系统是一个集计算机、网络、数据库、和应用软件为一体的大型应用系统，与其它网络应用系统一样，它的实施亦将是包含总体规划、方案设计、软/硬件设备选型和配置、网络建设、应用软件开发、试运行、维护、推广等各阶段在内的一个全过程，是一个计算机集成工程的实施过程。
本系统设计方案从主机、数据库、网络、应用软件等几方面综合考虑，通过对海南移动公司的业务需求及停用系统的特点进行透彻地分析了解，将上述各方面应紧密相连，密切配合，以达到结构、设计上的一致性及优越的整体性能。
海南移动的业务特点
海南移动公司的移动业务系统的建设必须根据其业务现状及其今后发展的趋势来进行，根据我们的了解，海南移动公司的移动电话业务具有下列特点：
实时性要求高
实时系统要求较高实时性。按移动业务目前标准，应能做到：用户计费信息实时生成，并能根据用户话费变化，实时控制用户呼叫和漫游权限，用户本人可做到实时话费和话单查询。所有这些对系统的处理能力和网络传输能力同样提出了很高要求。
数据量增长快
海南移动现有移动用户网络容量206万，实际用户现已达到191万，预计在2004年将达到620用户的水平。目前用户的发展速度时迅猛，而且高速增长的势头不减，将在较长一段时间内持续。这一高速发展的用户数量对于计费和营业系统的压力是十分巨大的。同时，对于海南移动计费系统处理的业务数据量而言，其增长速度又大大超过用户数的增长。如此高的增长速度，现有的系统已接近其极限处理能力，对于未来的系统，不但要求具有相当的处理能力和容量，而且要求系统应具有更好的扩展性能，能适应将来用户数量、业务数量和业务种类的更大发展。
业务发展变化快
海南移动目前正在经历而且今后将不断经历种种业务上的种种变化，如各种费率和优惠的变化；分时段计费、分用户类别计费、单向计费、套餐计费等各种计费方式的变化；租机租卡、呼叫前转等新业务的开展；计费结算方式的变化；随着GPRS、WAP技术的引进而带来的日益增长的无线数据业务的需要；甚至将来可能发生的体制的变化；所有这些要求系统有很好的灵活性，能满足现在及将来业务发展的需要。
容灾和管理性能的要求高
海南省地域广阔、人口稠密，海南移动的业务网点遍布全省23个地区，以省计费中心为核心，各个计费数据采集前置机、地市营业局域网络、外部系统接口设备和省中心之间通过移动自己的数据网络以及部分租用的电信分组专线连接成一个大的应用系统网络。集中式的计费系统结构使省中心成为整个系统的瓶颈，省中心计费数据的安全和系统核心应用的运行稳定对于整个网络的运行起着决定性的作用。另外，由于营业网点的分布，省中心和各地市营业中心之间的数据的一致性和完整性很大程度地依赖了网络状况。众多的计算机和网络设备以及关键的应用程序的运行状态使系统管理员最关心的焦点。海南联机计费系统的这些特征要求我们的系统设计方案能够提供可靠的容灾和备份方案，以及功能强大的网络管理软件。
系统总体技术要求
根据中国移动电话计费和客户管理系统的业务要求和海南移动公司的业务特点，本系统将满足以下总体技术要求：
安全性要求
严格的操作员权限管理机制。
记录操作员的使用日志，以防止非法操作。
保证数据不被非法入侵者破坏和盗用。
保证数据的一致性。
可靠性/稳定性要求
故障检查和处理机制，保证数据不因意外情况丢失或损坏。
数据的备份和恢复。
实现负载均衡，防止“瓶颈”产生。
保证系统在任何情况下，都保持可预见的输出。
灵活的任务调度机制
可扩展性
支持新的计费方式、新的优惠手段。
采用模块化设计原则，用户可以选择需要的组件而构成不同规模的应用系统。
实现新旧系统的平滑过渡，并充分保护现有资源。
对新增加的节点，系统可平滑地过渡，以适应应用系统硬件规模的不断扩大。
易操作、易管理
良好的用户操作界面。
完备的帮助信息。
系统参数的维护与管理通过操作界面实现。
实时性
实时完成大容量数据的处理。
对实时性要求更高的业务提供特殊的处理方法。
准确性：
话单处理过程既要保证准确性，也要尽量减少运营者的损失。
系统总体结构设计
在海南移动提供的BOSS三期扩容工程需求中，明确地选择了在海口建立省级计费和结算中心，实现集中管理、集中计费、集中营业的运行模式，据此，本方案提供了集中方式的总体结构设计说明。在集中方式的设计方案中，所有的处理都在省中心处理，所有的营业终端或管理终端都与省中心的计费/营业数据库相连接，地市营业系统不再设立本地的数据库服务器保存本地数据，所有的有关业务数据的访问都通过C/S方式或中间件服务器跨越广域网络和三个本地网中心到省中心数据库服务器进行连接。
采用集中方式的系统结构，我们在省中心设立一套数据库服务器，在数据库服务器前端设立中间层的应用服务器，所有的终端通过应用服务器访问中心数据库服务器，在数据库服务器中，各地市数据分别存放在不同的表中，不同的数据表建立在不同的数据块上，以提高处理速度。在省中心，我们通过增加相应的主机服务器，分别作为省中心的计费、营业/帐务数据库服务器以及应用服务器，全省的所有营业厅终端都可以通过应用服务器访问营业帐务系统数据库。
网络设计方面，各地市的营业终端可通过拨号或DDN的方式与地市的路由器连接，地市的路由器与省分公司的路由器连接。采用省中心-地中心-营业厅三级网络结构。我们可采用原有网络设备，尽可能利用原有的资源以节约系统投资。
数据库系统安装在省级费中心，所有终端通过应用服务器访问中心数据库。数据库中存放所有用户的用户资料、帐务数据、详单数据等。
综合考虑现有的技术条件、主机设备上的投资以及节约的其他设备和人力资源的投入，集中式的系统方案具有加强管理，节约投资，简化系统管理维护工作的复杂性等优点，是十分现实可行的方案，并且符合移动总部对于计费系统建设的要求。
主机系统设计
主机系统设计概述
海南移动公司移动电话计费和营业帐务系统按照如下原则组建：
整个系统由省计费和本地网营业中心、地市分公司营业中心、支公司中心与营业厅四级结构组成。同时，考虑到与局内相关系统如：管理信息系统、交换网管OMC-S/OMT系统等相连接；与其他电信局、电信运行商相连接；与市话、长途系统、银行、邮政等话费代收点相连接；与VMS、SMS、HLR、WAP网关相连接；与大代办户、大客户相连接。
广域网的连接采用E1、DDN或，E1、DDN为骨干，为备份，主要支持到移动总部的连接。
BOSS系统主机设备
主机系统需求
根据我们对海南移动计费合营业帐务系统工程的理解，以及省中心和各个地市中心的具体情况，描述主机系统需求如下：
本系统的处理能力以能够满足100万移动用户计费和营业及帐务处理业务的需要及100万用户的网间结算任务的要求。
仅由省中心保存全省用户资料、营业数据及话单数据。
系统应具备高度的安全性。移动业务系统是移动业务的基本业务系统，用户数据、话单数据和统计、分析系统都是移动业务的档案资料，应根据不同部门的业务制定不同的安全标准。
系统应具备异常处理的能力，在数据处理的各个环节中，应保证系统具有对突发错误、硬件设备故障等具备相应的处理措施，保证系统的正常运行。
主机功能分配
本次海南移动公司移动电话计费既营业帐务系统所涉及到的计费中心的各台服务器主机及相关设备的选型，均是以海南移动公司的计费系统的建设实际以及业务发展的实际要求和我们的分析为依据的。为各个服务器选择符合要求的设备并且具有良好的性能价格比是我们的宗旨，同时我们充分考虑到利用现有的使用设备以保护用户的前期投入。
数据库服务器设备是整个网络的核心，为保障系统的可靠性，数据库服务器选用HA方式。
主机系统的存储
由于计费系统与营业及帐务系统分属不同的系统功能，我们将它们的应用和数据分别分布在不同的集群系统上。同时考虑到用户话单需要保存6个月，而实际上在计费营帐系统中，绝大部分的对话单的操作都在最近的两个月内，因此建议将话单的存储分成两部分进行存储，第1—2月按详细的话单格式进行保存，第3—6个月话单按简单格式（话单的基本信息：包括手机号码，IMSI、对端号码、起始呼叫时间、漫游城市、归属城市等）
主机平台
鉴于BOSS系统的数据中心建设要求，建议将计费、帐务和营业系统数据库采用同一主机组建成数据管理中心，采用主流小型机平台，支持多处理器, 64位处理器的双机高可靠性群集系统，鉴于海南移动的实际情况，建议的主机选型方案为（AICBS系统支持以下三种主机平台）SUN主机和IBM主机。
根据海南移动的现有主机情况，BOSS三期建设的主机设备除数据库服务器需另行购置外，可以充分利旧。详细的配置建议见技术建议书－设备配置。
主机系统的升级
按照系统目前的结构，当用户数增加时，系统可以通过增加主机的CPU数目、增加内存、增加硬盘甚至通过增加主机数量的方式来实现系统平滑地升级，这样可以有效地保护系统现有的投资，同时，也可以保护目前系统的应用软件，以避免应用软件作大的改动。
双机热备HA方案
在本方案中，我们采用计费数据服务器双机热备，以及营业数据库服务器、应用服务器互为热备份的方式实现对系统高可靠性的保证，计费系统两台主机共享磁盘，营业系统主机和应用服务器共享磁盘，通过HA软件实现双机的相互监控，一旦某台主机发生故障，或出现网络故障，HA系统将自动选择另一台主机将启动备份应用软件，实现对故障主机的接管。根据我们建议的系统服务器的选型，可以采用VERITAIS的CLUSTER软件、SUN CLUSTER软件、IBM HPCMP软件或是LEGATO的CLUSTER都可以满足需求。
HA软件通过网络，光纤，共享磁盘实现双机的相互通信，在本系统中，我们在每台主机都配置光纤或100M以太网卡，用于心跳线的连接，有力保证系统的可靠性。
网络结构设计
原网络结构
海南移动通信公司现有的网络结构如图，核心交换网络采用100Mbit/s，海南省目前的业务管理系统集中设在海口，下设32个营业厅；12个业务代办点，分布在全省19个地市县，无地市业务中心，营业厅与各分公司经营、管理同处一个局域网。海南省业务中心网络配有Cisco7206路由器两台、3640路由器一台；Catalyst5505交换机各两台。并通过64K DDN 与中行、工行、建行、交行及农行实现点对多点方式联网。各分公司通过64K DDN 与海口、儋州、三亚3个本地网中心局相连，本地网中心局与省计费中心间用E1(2Mbit/s)电路连接。
原网络结构图
网络结构设计
由于海南移动通信公司在前期的网络规划和设计的成功设计和实施，基本能够满足三期工程的需求，因此本期BOSS三期工程对网络的设计将不作大的修改，而对原网络建设提出两点建议，第一，关于网络安全问题，建议采用防火墙对系统核心层与接入层进行隔离；第二，为核心交换机增加千兆交换模块，解决核心数据库的访问瓶颈，。
中心网络拓扑图合
考虑到网络的质量直接影响系统的运行效率和服务质量，对用户满意独有较大影响，因此网络必须具备高传输效率和高可用性能。根据海南移动计费系统的现状和要求，本方案中仅讨论省中心局域网和省中心到各个地市的广域网的设计。在省计费中心，我们建议增加二台骨干网交换机Cisco Catalyst 6509，同时在省中心增加二台Cisco 7507路由器，路由器与两台中心交换机之间都有线路连接，构成双星形网络结构。双星形网络结构是一种完全冗余的结构，结构中任何一条链路断开都不影响整个系统的工作，两个中心交换机只要有一个运行就不影响系统的工作。双星形结构适用于对可靠性要求很高、整个系统不能中断的网络环境中。因此，我们强烈建议在省中心采用这种结构。
WAN主干网
省计费结算中心与各地市中心以及分布在全省各地的交换机联机数据采集设备、HLR接口通过广域网连接。考虑较高的网络可靠性要求，依靠单一的WAN链路难以得到保证，因此我们建议采用广域链路的冗余备份技术。若某一链路不通，网络设备自动切换到后备链路以保证广域网的连通性。
在路由器构成的数据网络中，当路由器之间的某一连接发生故障，或者某一路由器不能正常工作时，快速收敛路由协议，如OSPF，E-IGRP等会保证在数秒内让数据传送通过迂回的路径进行，但对于计算机主机与路由器之间的连接，当与其连接的路由器发生故障时，计算机主机便不能正常进行通讯。这是因为通常情况下计算机主机并不参与路由协议，而是静态地配之以单个路由器的地址。当采用两台路由器互为备份时，也需要人为重配置计算机主机的Gateway地址，才能保证在路由器失效情况下通过后备路由进行正常通讯。
有些IP主机使用RIP协议来寻找路由器，但RIP协议收敛速度很慢，从一台路由器失效到寻找到另一台备份路由器往往需要3-10分钟时间。
Cisco公司的HSRP(Hot Standby Routing Protocol)提供路由器备份的很好的解决方案。HSRP使用优先级机制来确定哪个HSRP-Configured路由器是缺省的活动路由器，要使某一路由器成为缺省活动路由器，只需为它分配一个比其它HSRP-Configured路由器较高的优先级即可。
HSRP允许两个或多个HSRP-Configured路由器使用一个虚拟路由器的MAC地址和IP地址。虚拟路由器物理上并不存在，它只为那些提供互为备份的路由器作一个公共目标的IP地址，实现多个路由器的备份冗余。HSRP为网络的IP数据包提供了容错路由，当与快速收敛协议一起使用时，可提供极快的路由器的切换，保证为网络上的主机提供不间断的访问服务。
HSRP工作时通过交换Multicast Message在HSRP-Configured路由器之间广播优先级信息。当一活动路由器在一段可配置的时间内不能发送Hello信息时，在备份路由器中那个具有最高优先级的将会变为活动路由器。路由器之间的切换对网络上的主机而言完全是透明的。
在本方案中，省中心采用两台Cisco 7507路由器，利用HSRP协议，实现广域连接路由的冗余备份。
网络设备配置
海南移动公司省计费中心LAN建议采用两台Catalyst 6509网络主干设备组成双星型结构，建议采用两台Cisco 7507系列路由器通过HSRP协议组成主备路由器，使用E1、DDN为主链路，以E1、DDN分组网链路作为备用链路。
LAN主干网选用1000Mbps快速以太网作为主干，计费系统以及营业和帐务系统的服务器均直接联入中心交换机。 两台中心交换机分别连接两台路由器。路由器通过E1、DDN与各营业中心连接，并以E1、DDN链路作为备份。
数据库选型设计
数据库选型原则
数据库系统是计费和营业帐务应用软件系统的基础和核心。对于数据库系统最基本的要求是，必须在多用户的环境下，可靠的管理大量的数据、保证多个用户能够同时地、互不干扰地访问同一数据。并且数据库系统还必须确保数据库的数据不能发生丢失和差错。所有这些必须在数据库高效运行时同时实现。归纳起来可分为以下几点：
支持C/S体系结构
作为一个大的信息系统，必须要求该系统具有强大的处理能力、良好的用户界面、充分的可扩展性，并且能支持各种应用软件。若采用传统的主机终端方式或微机局域网方式都不能圆满的解决这个问题，只有采用先进的体系结构-客户/服务器方式才能满足要求。客户/服务器体系巧妙地将系统从逻辑上分为客户和服务器两部分，服务器可以是处理能力极强的主机，运行多任务操作系统如UNIX等；客户端可以采用PC机或工作站，运行DOS、WINDOWS、OPEN LOOK或MOTIF等图形环境，两者通过请求回答方式协同工作。一个真正具有客户/服务器体系结构的系统应该在其操作系统、网络及数据库方面都应按照客户/服务器体系结构进行设计。客户/服务器体系结构还是实现当前最先进的三层体系结构的基础。
支持OLTP和负载均衡
随着系统的扩展，在一个网络上，可能会有许多用户的多种应用并发访问数据库，这要求DBMS提供一套机制，尽可能的减少每个应用的开销；同时，用户要求以一种交互式的方式工作，这就要求系统具有非常短的响应时间，系统核心采用单进程、多线程机制可以最大限度地降低用户的开销，加快各应用间的切换。SMP技术使系统可以通过增加CPU个数，来得到灵活的伸缩处理能力，以满足大规模数据处理的要求。因而，数据库管理系统应能根据当前各种应用情况，自动在多个CPU上调节所负担的应用数量，以均衡全系统负载。
高可靠性和自恢复能力
移动通信行业对计费系统的可靠性要求非常高。因而，就要求数据库有足够的容错能力，以应付各种情况下对数据库系统的损坏，并提供在硬件、操作系统出现故障时，保护数据不受破坏以及从故障中恢复的能力。具体的说，应支持Cluster、Standby等双机热备份、联机快速备份、快速加载数据和快速备份数据恢复等功能。
支持数据的自动复制
数据库应该能提供复制工具来自动维护多个副本间的异步一致更新，即将一些主场地的数据复制到需查询的地方，以加快数据访问速度和减少网络开销，并提供基于事务的自动、远程和定制复制功能，当副本所在地出现故障时，能由系统事先指定的副节点自动接替。这一特性对于海南移动公司实现系统的容灾功能十分适合，通过增加容灾设备以及数据的自动复制技术，实现省中心计费营业系统数据和备份系统之间的数据自动复制功能。
高可伸缩性
数据库系统应具备良好的可伸缩性，以适应移动电话业务的高速发展。在数据量增加的情况下，通过增加CPU、内存，提高主机档次，增加主机节点等集成手段来适应系统的要求，而不需要对应用系统作较大的改动。
支持分布、异构的数据源
目前，海南移动公司面临着和众多计算机业务系统之间的接口问题，如银行系统，邮政系统，移动网管系统等。移动通信计费和营业帐务系统将来需要与这些系统实现数据的交换，因而数据库系统应支持分布、异构的数据源。
易于管理和维护
根据我们在集成领域的经验和海南移动公司的系统现状，应用系统应具有功能强大，简单易用的数据库管理工具和良好的维护界面，减少用户监控维护上的复杂程度，有利于将来系统的运行。
基于上述原则，我们建议采用ORACLE数据库Oracle8i。
大容量数据处理的解决方案
数据库分区技术
话单的入库与分发是整个集中式计费系统中最耗费时间的部分，为保证计费系统的整体性能，合理地设计数据库（表）的结构是至关重要的。因此，我们采用了数据库分区技术，按照下列原则对数据库中通话详单表进行划分：
原则1：按照IMSI码段（或其它标准）划分详单表；
原则2：按照手机号码段划分表；
原则3：码段的划分要与各地市所分配的码段保持一致；
原则4：按照时间划分；
其中原则1和原则2中只能选择一种。
按照上述原则，系统可选择如下具体的分表规则：
日期：不同天的话单被插入到不同的天表中；
归属地市：归属局为不同地市的话单被放置到不同的表中；
手机号码段：按照手机号码中的某些位划分表；
这些分表规则可以存储在配置文件或数据库“分表规则“表中，系统运行时依据这些规则建立或删除相应的表。按照以上原则，每个话单表的表名可能具有如下的形式：
本省话单： GCDR_XXQ00_L_19990120；
国内漫游来访： GCDR_XXQ01_NRIN_19990120；
国内漫游出访： GCDR_XXQ00_NROUT_19990120；
国际漫游来访： GCDR_XXQ00_IRIN_19990120；
国际漫游出访： GCDR_XXQ00_IROUT_19990120；
重复话单： GCDR_ALL00_DUP_19990120；
错误话单： GCDR_ALL00_ERR_19990120。
其中： G： GSM话单；
CDR： 详单；
19990120：CCYYMMDD；
XX01： 地市代码 + 分区代码；
L： 本地话单；
NRIN： 省际来访漫游话单；
NROUT： 省际出访话单；
IRIN： 国际来访漫游话单；
IROUT： 国际出访漫游话单；
DUP： 重复话单；
ERR： 错误话单。
按照以上标准划分表，使每个表所存储的话单数减少，从而提高数据的录入、查询、读取的速度，并进一步提高系统整体的效率。同时，系统将不同的表分配在不同的物理设备上，在进行数据入库或数据分发时，采用多进程并行操作，使入库、分发的速度大大提高了。此外，对这些表的维护并不需要用户的干预，系统将自动完成。
例如，分表规则可以以如下形式存储在数据库表中：
号码段1
号码段2
所属地市
13908000000
13908009999
XX00
13808000000
13808009999
XX00
13708100000
13708109999
XX01
13608100000
13608109999
XX01
13508110000
13508119999
XX02
13908110000
13908119999
XX02
……
……
……
虽然数据库本身也提供了自动分区的功能，例如自动根据手机号码分区，但与手工分区相结合，将会使系统具有更多优点：
手工分区完全考虑到应用中的要求，它的分区使得对数据库的操作能更有效地分配到不同的进程或线程（多进程、多线程在下节介绍），从而最大限度地保证的负载均衡；
手工分区的规则保存在数据库的表中，用户可以根据不同时间业务量的不同，合理地修改分区原则。例如，对新增加的号码段，用户只需要在表中增加或修改表中的记录即可；
手工分区具有更大的灵活性，它允许用户从多种分区原则中选择一种或多种原则的组合，而形成对本地业务（数据）处理最有效的方式。而相比之下，数据库的自动分区能够提供给用户的选择较少，只能在表中部分字段附加分区原则；
此外，系统的各个部分在处理过程中，也充分考虑手工分区的原则，在很大程度上，进一步提高了系统的整体处理速度。
应用软件设计
软件的结构特点分析
随着计算机硬件和软件技术、网络技术的发展，数据库应用体系结构经历了四个阶段: 第一阶段是基于主机的计算机系统，第二阶段是PC与传统的网络技术相结合，即文件服务器结构，第三阶段为客户/服务器(C/S)方式，第四阶段是在C/S体系基础上扩充的包括客户、数据库服务器、应用服务器构成的三层结构。
主机计算机系统
在基于主机的计算机系统中，各终端通过串行通讯接口线路与主机相连接(一个终端占据一条通讯线)，一台主机对系统的各种资源与数据进行集中管理，主机分时地对各终端进行扫描访问，用户通过各自的终端与系统交互作用，来执行自己的处理任务。这种集中式计算机信息系统的好处是：管理容易，数据的保密与完整容易保证，而且系统建设成本低，但是它的缺点是对业务变化的适应能力、系统的扩充性以及可维护性较差，当主机出了故障就有可能引起系统的瘫痪。
PC/文件服务器系统
八十年代由于PC机的广泛应用以及计算机硬件、软件技术、网络技术的迅速发展，由共享的文件服务器、工作站、网络传输介质组成的计算机局域网广泛应用于各行各业中。 在这种应用中，所有应用程序和数据都集中在共享的文件服务上，而不是驻留在实际使用它们的客户计算机上，当用户需要时，相应的应用程序和数据就整个地从文件服务器上下载到计算机上。在这种结构中，比基于主机的计算机系统使用简单、用户界面友好，并具有一定的可伸缩性。但是系统运行效率低下，当用户数增多时，网络的通信负载明显增大。
客户/服务器系统
PC机或工作站通过网络连接起来，系统把这些计算机设备划分为服务器与客户端，以承担不同的工作职能，服务器主要用于信息系统的管理与服务(一般由能力较强的计算机系统来承担)；客户机主要提供给用户来访问系统，具有良好的人机界面。用户只要通过客户机与网络上的任何服务器预先建立连接，就可以对它们进行访问。
采用网络连接的C/S操作方式的计算机环境，其优点是:系统有较大的灵活性;系统性能的提高容易(服务器性能提高或增加服务器的数目可以使系统整体性能提高);系统的连接方便，可以根据需要随时地增减用户；系统有较大的可维护性，一个服务器失效，其他服务器可以取代其部分功能，仍然保持系统的正常运转，不会使整个系统瘫痪。
这种客户/服务器系统实际为两层结构，即客户端程序＋数据库服务器。可分为两种模式：胖客户型和胖服务器型。胖客户型客户服务器系统的特点是数据计算和数据处理集中在客户端。这种系统的网络负荷大，直接影响业务处理速度，且用户连接多时容易在数据库端发生访问冲突。胖服务器型客户服务器系统的特点是数据计算和数据处理集中在数据库服务器端。数据库服务器端是这种系统的瓶颈，当用户连接增多时，在这里就会发生数据堵塞，系统性能急剧下降，根本无法适应多用户的需要。
三层结构体系
三层结构是在客户／服务器体系基础上的扩充，它将客户／服务器系统中各种各样的部件分为三层服务：
客户端服务程序：在用户计算机上提供用户界面。
应用服务器，它驻留在客户可访问的网络中心，为任意数量的客户应用提供公共的数据服务。
远程数据库服务器，提供关系型数据库管理系统(RDBMS)。
每一层服务在不同的计算机上协同运行，并且通过局域网甚至Internet共享数据和相互通讯。
在三层结构数据库应用中，具有如下优点:
(1)系统可根据需要把各个服务分别或重复地分布在不同的计算机上，使整个系统的工作量平衡分配到网络中，从而实现最佳的性能。
(2)由应用服务器统一管理数据库连接、数据接收、数据同步、事务处理和线程调度等工作，因此可最大限度地保障了数据的统一、完整和准确性能。
(3)对系统的修改或升级可简化到只对某个特定部件的更换。使系统的维护和升级更加容易。
(4)适用范围广且支持Intranet/Internet，并具有很强的开放性。
分布式多层体系结构
90年代后期，信息产业出现了分布式对象技术，应用程序可以分布在不同的系统平台上，通过分布式技术实现异构平台间对象的相互通信。将企业已有系统集成于分布式系统，可以极大地提高企业应用系统的扩展性。分布式多层体系结构的核心概念是在应用的业务逻辑、表示逻辑和数据分为三个不同的处理层的基础上，通过中间件的利用，实现应用的分布。
第一层的表示逻辑(客户层)，它的主要功能是实现用户交互和数据表示，为以后的处理收集数据，向业务逻辑请求调用核心服务处理，并显示处理结果。
中间是分布的业务逻辑(服务器组件)。这些分布的组件可以由中间件管理，实现核心业务逻辑服务并将这些服务按名字广播、管理并接受客户的服务请求，向资源管理器提交数据操作，并将处理结果返回给请求者—客户或其他服务器。
数据(资源管理器)构成模型的最后一层。 比如关系数据库，负责管理应用系统的数据资源，完成数据操作。服务器组件在完成服务的过程中通过资源管理器存取它管理的数据，或者说请求资源管理器的数据服务。
中间件应用设计应该是从异构的计算资源中创建一个“虚拟主机”：在分布式应用环境下提供可管理的相互关联的资源。中间件提供了一个基础的框架来帮助你建立、运行和管理一个分布式多层体系模式的应用，使你不需要从零做起，缩短应用开发的时间，提高了应用开发的成功率。中间件在对事务完整性的保证、对大规模并发处理的响应、对异构系统互联的透明支持，以及对应用数据的安全性保护等方面的表现将成为应用系统成败的决定性因素。
从以上论述可以看出，数据库应用体系结构的发展是个向“开放式”结构不断迈进的过程，我们始于非常封闭的集中式主机，目前正向一个真正开放的、与平台完全无关的环境过渡。
以上的数据库应用体系结构，有很多的解决方案。AICBS系统架构是一个基于CORBA协议的分布式多层体系结构，在其实现中应用了Inprise CORBA应用的解决方案中的Visibroke产品。客户端开发工具采用了C++ Builder，封装访问和操作数据库的复杂性，提供了许多访问和操作数据库的可视化组件和用户界面组件，利用它可以快捷、方便地开发基于单机、客户/服务器、分布式多层体系结构的数据库应用系统。
分布式对象标准
企业要构建多层分布式系统，必须遵循分布式的工业标准，基于什么样的标准直接影响到企业应用系统的开放性和可扩展性。目前业界主流分布式对象技术主要有三种架构标准：Microsoft的COM/COM+、Sun Microsystems的Enterprise JavaBeans/RMI以及OMG组织的 CORBA。COM/COM+是Windows环境专属的分布式对象架构，虽有协力厂商移植至少数 UNIX 平台，但与Windows平台上的版本仍有相当程度的差异性，为部门级（Department Level）分布式运算的主要架构，支持平台种类有限，无法满足企业级的需求。RMI与Enterprise JavaBean 是以 Java 程序语言为主体的分布式对象架构，新版本的Enterprise JavaBean 规范与 OMG 的 CORBA 规范也逐渐集成，完整支持异构平台的特性，非常适合大型企业的跨平台的需求，但现实的软件应用环境里常是由多种不同的程序语言所构建的，大型企业组织只使用一种语言来构建其全部的应用系统是非常罕见的，单纯用Java 和Enterprise JavaBean 是无法完全满足企业用户需求。由于Enterprise JavaBean能够提供软件人员快速开发分布式应用系统的能力，而OMG 的 CORBA又提供了强大的集成能力，因此目前世界上大多数的分布式应用系统以及电子商务同时使用这二种技术，以CORBA做为分布式运算的核心框架，而以Enterprise JavaBean做为开发应用系统的组件。使用这种架构的中间件目前已逐渐成为新一代的标准分布式中间件。
CORBA技术体系结构
OMG 组织的 CORBA
有别于Microsoft主导的分布对象技术COM/COM+，CORBA 是由 800 多个大型软、硬件公司参与的OMG (Object Management Group) 组织所制定，获得IBM、Sun Microsystems、Oracle、Sybase、Inprise、Novell、Netscape等大型 IT 技术供货商的支持，CORBA规范是众多厂商平台上软件对象间沟通的桥梁，遵循CORBA标准能够保障用户的技术投资。CORBA 的对象管理架构 OMA由下列几个重要部分所组成：
对象请求代理 (Object Request Broker, 以下简称ORB )
共通对象服务 (Common Object Services, 以下简称 COS )
共通设施 ( Common Facilities, 以下简称 CFA )
应用程序对象
ORB ( Object Request Broker ) 是整个CORBA应用的骨干，它用于连接客户端的请求与被请求的对象（Object）之间的连接，下图描述了这种关系。
图 CORBA工作原理图
客户端的程序不必知道被请求的对象的位置，即该对象在本地主机或远程主机对客户端是透明的。客户端进程唯一所需要知道的是对象的名字，以及调用该对象的接口。ORB则完成二者之间的连接，即定位对象、发出请求、并返回结果的过程。
软件厂商只要遵循应用对象与ORB间沟通的接口定义语言 ( Interface Definition Language, IDL )，便能够以对象的型态提供服务或是享用服务，ORB如同一个软件的总线( Software bus ) ，结合应用程序对象，让开发人员完全不需考虑异构作业平台、异构的通讯协议或是不同程序语言间所造成的隔阂。因此，CORBA标准具有操作系统的中立性及开发语言的中立性特点，也就是说，CORBA对象并不局限于某一特定系统平台 (Windows NT或Unix )，CORBA的开发也不局限于某一特定的开发语言(开发人员可以使用C/C++、Java、Object Pascal或Smalltalk)分布对象管理架构中的共通对象服务 (COS) 是以对象型态提供许多公用的服务，例如；事件传递管理、交易管理、对象命名、安全管理、数据交换等，而共通设施 (CFA) 则提供复合文件、网络管理等多种服务。
CORBA强劲的分布式计算能力能够集成各种异构平台，但是在现今Internet/Intranet的时代，Time To Market则是企业信息系统必须面对的挑战。现在的软件信息人员需要一个快速开发的环境，而Enterprise JavaBean就提供了基于组件开发 ( Component-Based Development ) 的能力。
VisiBroker 系列产品
INPRISE公司是CORBA领域居领导地位的厂商，VisiBroker 系列产品是Inprise CORBA应用的解决方案。VisiBroker系列产品包括：
VisiBroker for Java / C++
VisiBroker GateKeeper
VisiBroker SSL Pack
VisiBroker for OS/390
VisiBroker ITS
VisiBroker系列产品可以为企业带来新的商业机会，并可以利用面向对象可重用组件技术，缩短开发周期、降低开发成本，VisiBroker系列产品遵循CORBA标准、采用开放的架构，能够容纳、集成企业现有异构环境。
企业面对日益严峻的竞争，必须不断地快速改善商业运作的方式。信息机构应该引导企业，并为企业的发展提供有价值的策略。为了保持企业的竞争优势，我们需要的是能够适应不断涌现的新技术（如Web技术）的战略性应用。基于CORBA标准的分布式对象计算架构能够集成异构企业应用，并为下一代应用软件提供高度灵活的平台。VisiBroker率先实现CORBA标准，可以构建跨平台通信和组织内部互操作的关键任务应用，并确保其稳定性。
美国第一联合银行和美国汽车协会（AAA）已经应用VisiBroker提供的高效率、高可靠性和高灵活性，按时、按预算地交付了他们具有战略意义的应用。通过在业界具有领先地位的合作伙伴，如Oracle、Cisco、Netscape和Novell，VisiBroker已经成为事实上的CORBA解决方案。例如，VisiBroker技术嵌入了Netscape的每一个浏览器中，以确保关键CORBA应用能够与运行环境中的其它关键技术相兼容。
分布式对象计算的高效率软件基础
企业需要分布式计算（包括VisiBroker）所提供的灵活性和扩展性来保证企业应用的不断成功。VisiBroker提供的业界标准使分布对象能够跨平台通信。VisiBroker为构建、分发及管理分布式Java和C++对象提供了完整的CORBA ORBTM环境。利用IIOP的原生实现，VisiBroker构造了一个在Internet、Intranet和基于Web计算的工业标准协议。
提高CORBA效率
VisiBroker是CORBA开发的优先选择。由于能够和先进的Java和C++开发环境互操作，VisiBroker强大的开发能力使关键任务应用的开发更容易、全面，降低了开发风险。
Borland快速应用开发工具JBuilder、Delphi、C++Builder紧密结合的CORBA ORB产品，通过简单的拖拽即可实现基于CORBA的开发。由此降低了培训费用，并使应用能够按时、按预算交付。
交付可扩展的应用
应用必须能够承受当前Web用户带来的潜在负担。VisiBroker是提供适应分布在intranets、extranets和Internet上的企业应用所需的扩展性的唯一架构。作为VisiBroker构造的各种应用的固有部分��智能资源管理��使应用的大小或规模不再受基础条件的限制，只取决于企业的需求和需要。
可定置的基本结构
对VisiBroker适中的控制是确保VisiBroker ORB能够被控制和扩展以满足进一步分布式应用的特殊需要。集成新功能的能力，如对分布式事务的支持和SSL安全通讯的支持，就是这种灵活性的结果。对于在开发早期阶段没有预见到的需求，也可以在需要的时候引入，而无须重新设计系统。VisiBroker可以保护用户投资并使其随时拥有最新技术。
Inprise VisiBroker系列产品是一整套集成的开发工具和服务，确保开发、分发和管理的灵活性、可扩展性和编布整个企业以及企业的Intranet和Intenet的安全性。
Inprise VisiBroker for Java and C++：
领先的CORBA ORB为在异构环境中进行稳定的开发提供开放性和灵活性。
VisiBroker Integrated Transaction Sevice（ITS）：
下一代事务解决方案，用于交付可靠的、高性能分布式对象应用系统。
图1 VisiBroker ITS 方案
VisiBroker SSL Pack：
是Inprise VisiBroker ORB的选件，提供了入门级的安全性。允许开发人员为他们的分布式应用增加认证（Authentication）和加密。
VisiBroker Gatekeeper：
在保证网络完整性和安全性的同时将应用延伸到防火墙以外。
图2 VisiBroker Gatekeeper/SSL方案
VisiBroker Naming Service：
帮助应用程序在公司上千个对象中定位单个对象，从而提供了一个符合业界标准的方法来降低分布式应用的复杂性。
VisiBroker Event Service：
通过支持CORBA标准服务，允许基于事件的应用开发，扩展了VisiBroker ORB的灵活性。
VisiBroker Manager：
通过可视化访问ORB信息和设置，支持并增强了VisiBroker应用的开发、分发和管理。
Visibroker是用来开发大型应用程序的第三方CORBA软件产品，它除具备CORBA的优点之外，还包含以下特性。
灵活的代理结构
（Smart Agent Architecture）
Visibroker中的Smart Agent是对CORBA中基本对象适配器（Basic Object Adaptor）的扩展，它是一种动态的任务分配机制。网络上多Smart Agent的组合将有效地实现SERVER对象之间的负载均衡，从而实现更高的可用性。Smart Agent动态地跟踪网络上所有可用的对象，在客户端有请求时，它能够根据所有对象信息的记录，建立两者之间的连接。不仅如此，在由于网络中断、主机故障，而使客户端与对象之间的连接中断时，它能够自动重新建立连接。
强化的定位机制
（Enhanced object discovery with the location service）
为提高稳定性，Visibroker提供更有效的定位机制（Location Service），这种定位机制也是对CORBA基本功能的扩展，通过这种定位机制，应用程序能够从多Smart Agent中获取更多的信息。利用Smart Agent，定位机制可以获取所有可满足客户端请求的对象的信息。
对象激活支持
（Implementation and object activation support）
Visibroker的对象激活进程（Object Activation Deamon）可以使得对象只有在接收到请求时，才自动启动。
线程与连接管理
（Robust thread and connection management）
Visibroker支持对单线程或多线程的管理：
在“线程-任务”（thread-per-session）的模式中，线程可以在有请求到达时启动，而在请求结束、连接中断时，自动终止线程的运行；
在线程池的模式中，线程根据请求的数量来分配，这意味着：在有大量请求的情况下，将启动较多的线程，以保证请求能够更快地被执行；因为很少有多于一个的请求共享单独的线程。
图连接管理
Visibroker的连接管理使的客户端同对象之间的连接数减小到最少，所有客户端的请求共享相同的连接，即使这些请求是由不同的线程所引起的。此外，Visibroker中提供连接重用的机制-被释放的连接可以在下次连接到相同SERVER时重用。
应用的部署
（Deploying applications）
当开发人员已经完成客户端的程序或服务器端的程序时，Visibroker将完成CORBA结构应用中的最后一步-应用的部署。下图是一个简单的应用：
图 应用的部署
在上图中，客户端可以是GUI（Graphic User Interface）、applet，或是其它的应用程序。SERVER端则在包含所有的应用逻辑Object A、Object B和Object C。
应用服务器负载均衡
（Application Load Balance）
应用服务器是连接数据库服务器和用户终端的桥梁，系统运用CORBA结构，采用分布式运算结构。结构如图所示。
图应用服务器结构
同时，各Smart Agent之间和各服务器之间，也可以达到自动容错，保证系统的高可靠性。
图应用服务器的高可用性能
简捷的开发进程
（Easy Development Process）
VisiBroker为基于CORBA的应用程序开发提供了一个简捷、灵活的途径。客户端与应用服务器端的业务应用接口规则由IDL定义。它提供了一种跨平台、跨语言的开发环境，使应用的实现更为高效、稳定。
图 CORBA开发流程
Visibroker支持的平台
VisiBroker for C++ 支持的平台如下所列：
Microsoft Windows (Intel)
Sun Microsystems Solaris (SPARC)
RedHat Linux (Intel)
Hewlett Packard HP-UX (PA-RISC)
IBM AIX (RS/6000)
详情请参见下表：
Microsoft Windows (Intel)
OPERATING SYSTEM
SUPPORTED JDK(s)
SUPPORTED COMPILER(s)
MINIMUM SYSTEM REQUIREMENTS
Windows NT
JavaSoft JDK
JavaSoft JDK
Borland C++Builder
Borland C++Builder
Microsoft Visual C
Microsoft Visual C
NT 4 Service Pack 3 or 5
Pentium II 333MHz
128 MB RAM
50 MB disk space
Windows 98
JavaSoft JDK
JavaSoft JDK
Borland C++Builder
Borland C++Builder
Microsoft Visual C
Microsoft Visual C
Pentium II 333MHz
128 MB RAM
50 MB disk space
Windows 95
JavaSoft JDK
JavaSoft JDK
Borland C++Builder
Borland C++Builder
Microsoft Visual C
Microsoft Visual C
Pentium II 333MHz
128 MB RAM
50 MB disk space
Sun Microsystems Solaris (SPARC)
OPERATING SYSTEM
SUPPORTED JDK(s)
SUPPORTED COMPILER(s)
MINIMUM SYSTEM REQUIREMENTS
Solaris 7 (32 bit)
JavaSoft JDK
JavaSoft JDK
Sun Workshop Compiler with patches 105591, 107311, and 107357
UltraSPARC?168MHz
64 MB RAM
54 MB disk space
Solaris 7 (64 bit)4
JavaSoft JDK
JavaSoft JDK
Sun Workshop Compiler with patches 105591, 107311, and 107357
UltraSPARC?168MHz
64 MB RAM
54 MB disk space
Solaris
JavaSoft JDK
JavaSoft JDK
Sun Workshop Compiler with patches 105591, 107311, and 107357
UltraSPARC?168MHz
64 MB RAM
54 MB disk space
Hewlett Packard HP-UX (PA-RISC)
OPERATING SYSTEM
SUPPORTED JDK(s)
SUPPORTED COMPILER(s)
MINIMUM SYSTEM REQUIREMENTS
HP-UX (32 bit)
JavaSoft JDK
JavaSoft JDK
ANSI aC++ (32-bit)
PA-RISC 100MHz
64 MB RAM
54 MB disk space
HP-UX (64 bit) 4
JavaSoft JDK
JavaSoft JDK
ANSI aC++ (32-bit)
PA-RISC 100MHz
64 MB RAM
54 MB disk space
HP-UX
JavaSoft JDK
ANSI aC++
PA-RISC 100MHz
64 MB RAM
54 MB disk space
IBM AIX (RS/6000)
OPERATING SYSTEM
SUPPORTED JDK(s)
SUPPORTED COMPILER(s)
MINIMUM SYSTEM REQUIREMENTS
AIX (32 bit)
JavaSoft JDK
JavaSoft JDK
C Set++
RS/6000 PowerPC-604 200MHz
64 MB RAM
54 MB disk space
AIX (64 bit) 4
JavaSoft JDK
JavaSoft JDK
C Set++
RS/6000 PowerPC-604 200MHz
64 MB RAM
54 MB disk space
AIX
JavaSoft JDK
C Set++
RS/6000 PowerPC-604 200MHz
64 MB RAM
54 MB disk space
RedHat Linux (Intel)
OPERATING SYSTEM
SUPPORTED JDK(s)
SUPPORTED COMPILER(s)
MINIMUM SYSTEM REQUIREMENTS
Linux
JavaSoft JDK
JavaSoft JDK
Linux EGCS
Pentium II 333MHz
128 MB RAM
50 MB disk space
VisiBroker应用案例
VisiBroker是业界分发量最大的CORBA解决方案，在电信、金融、医疗、MIS和电子商务等领域有着广泛的应用实例，亚信公司在CORBA应用开发上有着丰富的经验，并在各产品种有着成熟的应用。如内蒙移动综合营帐系统工程、天津长话计费营帐工程等等，Visibroker应用有着高效、稳定的效能。
在国外Visibroker更有着广泛的应用案例，现列举一二：
美国林肯国家再保险系统
美洲银行网上查询系统
欧洲第一个网上银行系统
AON RISK SERVICES公司风险管理应用系统使用Borland JBuilder 和VisiBroker
平安保险公司采用Inprise Application Server构建金融保险服务网站
爱沙尼亚Optiba银行选用 Inprise VisiBroker4构建其客户关系管理集成系统
Borland JBuilder 帮助用户构建
Motorola下一代无线电话应用
Cisco公司网管解决方案（CISCO WORKS2000）
Cisco公司网管解决方案CisciWorks 2000采用VisiBroker
美国AAA协会采用VisiBroker构建全球旅行综合业务核心系统架构
该综合业务系统包括机票预定、酒店预定、汽车租赁和游船预定等
VisiBroker 应用于电力交换系统
美国亚特兰大的Salient公司运用Inprise CORBA产品VisiBroker实现电力交换系统
Telenordia选用Inprise技术
VisiBroker 应用于First Union公司的呼叫中心
综合医疗信息网络管理系统
北美最大的健康保险商McKesson公司的健康保险系统
GENSTAR集装箱租赁公司采用VisiBroker构建其分布式应用系统
Florida Power and Light公司采用VisiBroker 构建其企业信息系统
VisiBroker运用于信息管理系统
VisiBroker 构建GAP公司的电子商务系统
UUNET选用Inprise Application Server
海南BOSS系统的特点
海南移动BOSS三期的建设，是移动通讯领域集中计费和集中营帐系统的典型，结合海南移动现状，计费营帐系统具有如下特点：
信息存储量大，用户数的高速增长，在系统中需要存储大量的详单数据、用户资料数据以及相应的帐务数据，对与数据的相关性、可追溯性的要求高；
数据的特殊性：移动通信计费和营业帐务系统存储的均是敏感的用户的个人信息以及财务数据，数据的安全性、准确性要求高。
系统服务质量的要求：移动通信行业的垄断地位被打破，由行政和服务转换为服务行业后，哪家企业的服务好就会赢得更多的用户。只有通过提供更强大的服务功能才能吸引用户。
业务变化快：随着移动通信的业务已从单纯的提供话音服务，逐渐扩展到了无线数据领域。GPRS、WAP、LMDS技术应用的普及，使未来移动通信的业务供应方式、计费方式发生越来越多的变化，业务的更新速度也越来越快。
亚信BOSS产品设计优点
移动通信计费和营业帐务系统的设计目标是：对外提供优质的服务，对内加强管理。优质服务体现在：系统的实时响应速度要快，为移动通信用户提供实时通话计费和结算功能，实时出帐、实时查询；系统的数据资料要准确；系统要灵活适应业务的发展，提供灵活的优惠方式和实时出帐方式。对内加强管理体现在系统的资料的特殊性决定了对系统的安全性要求要高，对系统的使用记录要有完善的监督功能；系统易学易用，操作维护简单；提供强大的管理工具，实时监控整个系统的运行状况；故障的自动恢复功能以及关键数据的容灾设计。
总而言之，海南移动三期BOSS系统软件设计是一个全省集中的一套综合性系统，全面强调全省集中统一的业务管理和监控，讲究“全省一套系统，全省一盘棋”。因此，我们对应用软件设计在灵活性、可扩展性、可靠性、安全性、高效性等方面做出全盘周到细致的考虑。
应用软件的灵活性设计
软件系统要满足最大程度的灵活性。包括对业务扩展的灵活性，计费的灵活性。由于整个系统是采用的面向对象的设计思想，并采用了目前面向对象技术中最新的CORBA三层体系的设计方法，使得可以对中间件对象做二次开发，可以灵活地装载、卸下、替换和更新相应的业务功能。另外，系统的整个软件功能构件采用了模块化的设计，各个模块之间有严格的调用接口，各个模块之间数据与功能的独立性，保证了整个系统的灵活组装性。同时采用CORBA的应用软件的实现方法保证了系统在不同的软硬件平台上均具有良好的移植性。
可扩展性设计
移动通信用户的高速增长，其用户信息的增长是非常之快的，客观要求整个系统具有可扩展性。硬件上可以增强单机性能，也可以增加系统的结点数，软件上的各个子系统一定要能适应这种扩展。
高可靠性、高安全性设计
本系统的特殊性决定了可靠应作为系统设计的出发点。除了通过数据传输系统DTS实现了系统的可靠数据传输以外，系统具备了良好的数据备份机制，通过数据复制技术实现重要的营业、帐务数据的异地双向备份，不但提高了系统的运行效率，而且为重要的用户数据提供了安全性保障。通过基于SNMP的网络应用管理软件，系统能够实时监控整个计费和营业网络的可靠性和可管理性能，同时能够有效地防止非法用户的入侵，保护系统数据。系统发生的各种事件记录在数据库及日志文件中，以备系统恢复用。
实时性、高效性设计
集中实时计费系统通过分表机制、多进程多线程设计，实现话单级别的实施采集、预处理、批价及快速数据入库功能。提供更多的客户端，提高应用系统的响应速度，提高系统的处理能力，是营业和帐务系统提供优质服务基础。而以前的CLIENT/SERVER体系的软件结构，在客户终端达到几十，上百以后，由于服务器本身网络连接的限制以及网络传输能力的限制，使得系统的处理响应速度急剧下降。已经不能适应目前需要同时处理几百个响应的要求。因此，我们的系统采用了最新的基于CORBA的软件结构。CORBA体系结构可以自动根据客户端的请求数量来动态生成相应的代理Server处理对象，以适应多达数百的客户响应。
操作的方便性设计
Client端的操作采用统一的WIN/WEB风格，操作更加方便。业务功能参数化、规则化的设计，适应实际业务多变的特点，即可通过营业前台接入数据系统也可通过WEB接入中心系统。
系统的适应性设计
保证系统不间断工作，通过采用回调函数（Call back），确保系统在费率、计费规则等资料发生变化的情况下，可灵活地修改系统的参数而不影响系统的正常运行。
面向对象的设计方法
面向对象是一种先进而又成熟的技术，它可应用于软件开发的全部过程，包括面向对象的系统分析（OOA）、面向对象的系统设计（OOD），以及面向对象的编程（OOP）。面向对象的设计放法保证了系统的灵活性、可操作性与可扩展性。
海南BOSS系统软件方案
亚信公司的融合计费营帐系统AICBS是一套针对电信业务的实时大容量计费营帐系统，是针对移动运营商的业务特点量身定制的业务运营支撑系统（BOSS）软件产品，它提供了一套集成化的完整的数据采集、计费、客户服务、帐务处理、缴费管理以及系统监控/故障管理的解决方案，广泛支持多种电信业务及其任意组合形式的计费管理，包括：移动通信（TACS/GSM/CDMA）、PCS、SMS、Paging、固定市话、长途电话、VoIP、IP、数据通信、CATV、WAP、GPRS、LMDS等等，并且为未来的新业务的出现预留了空间及接口。真正做到统一的用户资料管理，统一进行所有业务的受理，采用统一的资费管理模型，统一的计费引擎计费。
AICBS系统设计特点
AICBS提供强大的外围系统接口，高度集成化的的实时数据采集系统功能以及用户命令接口功能是系统效率和客户满意度的可靠保证。此外，AICBS能够提供与多种业务网络及功能实体的连接，如：银行系统、客服系统、SMSC、OMC、Clearing House等等。
为适应多种不同的业务类型以及业务的不断更新发展，AICBS提供了强有力的面向对象的表驱动设计，计费方法的自动导航机制提供智能化的动态计费方法绑定能力，从而实现了高度灵活的资费政策以及个性化的计费能力。AICBS还发展了电信计费及优惠的概念，为新型的融合计费系统的研发提供了理论基础。
AICBS从体系结构、数据组织、应用处理、数据管理等多个角度实现了融合，达到了降低电信运营商维护计费系统的成本，使电信运营商能更迅速的实现对新业务的计费、实现更多的促销方案（如多业务捆绑销售，交叉优惠等），方便用户购买和使用自己的多种服务的目的。从而为电信运营商吸引更多的客户，取得更大的经济效益，在竞争激烈的市场中，立于不败之地提供了技术上的支持。
AICBS具有大容量、扩展性好、可靠性高、框架灵活、操作方便等特点。
AICBS技术特点
新型的业务管理模型
AICBS的各子系统是通过服务/产品/计划/促销这一业务模型和用户/帐户/定购这一用户信息模型有机结合起来的。服务/产品/计划/促销业务模型是很好体现电信运营商多业务（既包括GSM/CDMA、固定电话、长途电话又包括Internet的拨号接入、专线、电子邮件、信息服务等）经营管理理念的抽象模型，而用户/帐户/定购信息模型则是联接电信运营商和消费者的最佳关系模型。
服务、产品、计划和促销的概念
服务：服务是对电信运营商提供给用户使用的业务的统一描述。服务由服务类型、服务名称、计费资源、服务属性组成。服务类型是运营商基于某种现有的技术提供给最终用户服务的类型，如GSM服务类型、拨号服务类型、Email服务类型等；服务名称是对服务类型的一种通用命名；计费资源是最终用户使用服务时的时长、流量、次数等；服务的属性就是使用服务时涉及的所有承载实体（如手机、电信网络、固定电话等等）具有的特征属性。服务的某些属性仅当用户购买具体的产品时方能确定如手机的号码、漫游支持、来电显示支持、短信收发支持等等。
产品：产品是用户可以购买的最小服务单位。产品由服务、服务的基本费率、服务的固定费用、附加的免费服务、一些基本条件组成。如GSM网络产品的定义――服务类型是GSM网络；名称是GSM网络服务；计费资源是通话时长和短信条数；服务属性包括GSM手机号码、对端号码、漫游支持、来电显示支持、短信收发支持等；基本费率是通话费元/分钟，通话月租费是50元/月，通话的费率在午夜12点至清晨7点之间半价，在节假日全天半价；短信、自动转接、来电显示免费，本产品的适用用户群是全体用户。
计划：将多种服务的多个产品组织在一起，并赋予新的费率和优惠规则，就构成了一个计划。一个产品也可以称为计划。如GSM语音加WAP计划的定义--GSM通话费是元/分钟，月租费是50元/月，可以免费使用GSM短信、自动转接、来电显示，通话的费率在午夜12点至清晨7点之间半价，在节假日全天半价；WAP服务费率为零，月租费20元/月，本计划的的适用用户群是全体用户。设置计划的目的是简化产品选择，同时也便于宣传和促销。
促销：促销是通过对已有产品和计划的有效时间、使用条件、适用的客户群、费率或费用的进一步限制实现的，也就是对已有的产品或计划在不改变名称的前提下的重新定义的过程。如上面定义的GSM加WAP的计划，可以进一步进行如下的促销—在原有条件基础上，添加“在5月1日凌晨12点（不包括）至12月31日凌晨12点（包括）之间，所有XXX类客户，每个月的通话时长超过150小时后，通话费率按元/分钟计算”的限制。
用户、帐户和定购的概念
用户：用户是对帐户负责的实体（自然人/法人）的相关信息。是处理欠费及其他业务时的认证依据之一。用户之间可以有从属关系，即一个用户可以属于其他某一上级用户。
帐户：帐户是最终用户与运营商之间的基本结算单位。帐户记录用户的帐务信息以及产品或计划的定购和相关资源使用情况。
定购：订购记录用户选择使用的产品、计划、相应服务的特征以及对应的帐户和用户。
业务模型与用户信息模型的关系
在业务模型中，一个服务可以生成零到多个产品；一个产品可以由一到多个服务组成；一个计划由一到多个产品组成。一个产品也可称为一个计划，但一个服务不能称为一个产品。用户可以定购产品或计划，服务必须被包装成产品或计划后，方可被用户定购使用。
在用户信息模型中，一个用户可以拥有零到多个帐户；一个帐户由一个用户负责；一个帐户可以拥有多条订购；一条订购对应一个产品或一个计划，并且属于一个帐户，属于一个用户。
用户信息模型和业务模型是通过用户定购建立联系的。
业务模型与用户信息模型的意义
通过服务/产品/计划/促销业务模型，电信运营商可以更灵活的管理所经营的业务，实现更多的促销优惠方案，如针对服务使用时间的优惠（节假日优惠、时间段等），针对服务使用量的优惠（费用封顶、总量打折等），针对服务使用特点的优惠（根据对端号码优惠等），针对用户信息的优惠（如教师节优惠、大客户优惠等）。
通过用户/帐户/定购用户信息模型，电信业务的最终用户可以更方便的选择使用电信运营商提供的各种服务，简化定购和缴费的手续；而电信运营商可以更清晰的维护与最终用户的关系，综合评价用户的信用。
新型的系统管理模型
AICBS为了使运营商更好地管理整个系统，系统实行按域--组--角色的层次管理。具体到营业点管理表现为按行政域--节点的层次管理；具体到操作员管理表现为按工作组--角色的层次管理。下面介绍其中涉及的所有概念。
行政域：是个区域性的概念，如一个地域管理范围：杭州。系统为了行政管理的需要，根据地域的不同划分不同的行政域进行管理。数据库初始化时设置中心行政域。
节点：对营业点实行按行政域--节点的层次管理。系统可以根据管理需要划分节点，一个行政域有多个节点，一个节点只能属于一个行政域。数据库初始化设置中心节点，属于中心行政域当节点本身为叶节点时，表现为营业点、代销点、代办点形式。
工作组：对操作员实行按工作组—角色的层次管理，每个工作组必至少包含一个操作员（管理员）。每个操作员必且只能属于一个操作员组。每个操作员与工作组之间必定义了上下级的从属关系。
权限：所谓权限是由登录范围、业务功能和权限级别三项内容组成。定义至组一级。任何人不能授予别人自己没有的权限。权限有作用起止时间限制。
业务功能：定义了系统中的所有模块业务的层次关系，是由系统管理员根据操作员的工种定义不同的操作权限。
权限级别：权限级别有四种,具体含义如下，0---对所有的操作对象有权限；1---无权限；2---对creator属于自己的操作对象有权限；3---对creator属于本组的操作对象有权限。
登录范围：即实际可登录的节点范围，操作员只能对登录范围内的节点资源进行操作
角色：扮演的身份，定义至操作员一级。同属一操作员组的操作员，不一定拥有同一角色；拥有同一角色的操作员，不一定属于同一操作员组。如营业组包含普通营业员及班长不同的角色。
安全级别：系统设定安全级别为0~~9级，数值越大安全级别越高。包括对安全级别代码、安全级别说明、操作员密码的最小长度、密码有效期、密码不重复个数的维护。定义至角色一级。
代办、代销：即从电信运营商处批发一定数量的产品，为电信运营商办理这些产品的销售业务的称为“代销”。购置或由电信运营商提供产品，在列车、轮船、长途客车、出租汽车等移动体上为电信运营商办理这些产品的应用业务的称为“代办”。
受理编号：记录业务操作的流水序列号，在系统中永不更新、永不重复。同时，为管理部门对存单、操作的查询更为方便，又设立了按受理业务项分类的套号，称为业务套号，与受理编号一一对应。
系统初始化时，设置一个中心行政域、一个中心节点和一个系统管理组。系统管理组中的操作员（节点管理员），具有缺省密码，并拥有所有权限。整个系统运作管理由系统管理组成员负责。
系统管理模型的建立和应用，为电信运营商规范所经营电信业务的管理，提高电信运营商本身的运作效率提供了基础。
WEB方式的营业管理
采用WEB方式的操作员界面，极大的减轻系统的维护安装的工作量，同时对于发展代理商也是非常方便，运营商无须对代理商进行系统维护，通过高度透明、清晰的系统界面使用帮助，使得代理商无需培训就可以根据使用手册完成业务的开展，发展代理商对于运营商来讲是一个非常有效的发展用户的手段。
主要构成
WEB界面由四层体系（用户Browse、WEB Server 、Application Server和 DB）构成，如下图：
第一层为客户机，可支持任意浏览器，可由PC、NC或工作站实现，静态界面由HTML实现，动态界面接口由SERVLET完成，由应用服务器处理客户端的所有应用需求。
第二层为WEB Server，可支持任意浏览器，可由PC、NC或工作站实现。
第三层为应用程序服务器，由多个组件组成。我们的应用逻辑将由此实现，包括用户登录验证、开户、用户帐单查询和详单查询等等。
第四层为数据仓库，该层定义、维护、访问和更新数据，并管理和满足业务对数据的请求。
安全问题
一般情况下，对WEB的攻击主要有三种手段：
盗窃或馔改数据，直接盗用服务器更改有效数据；
恶意的程序代码，恶意程序由WEB侵入系统破坏数据；
窃听，拦截系统登录信息或有效数据；
因此，我们从以下方面实现WEB安全：
网络安全
该界面由防火墙实现第一层网络安全保护，限制所有TELNET、FTP等权限。
WEB SERVER 安全
第二层的WEB安全由WEB SERVER提供，具体由如下机制实现
基本身份验证
该机制要求进入系统的用户必须输入用户名和口令，只有通过访问控制检查，才能访问某个主页和相关资源。这种基于身份验证的访问控制与物理上及操作系统紧密配合，有效防止与控制盗窃或馔改数据等直接攻击。
数字鉴定
采用数字方式传输用户信息。
SSL服务器身份验证、SSL隐私保护
在网络环境下，一种能确认当前给他们发送数据的服务器就是他们所要求的服务器的机制，HTTPS URL可使用户知道服务器身份。同时HTTPS协议使所有服务器与客户间传送的数据都是经过加密的，如果窃听者无密钥，即使得到这些数据也无法得到原有效信息。
用户和用户组领域管理
将系统的许多的用户，划分为相应的用户组、领域，控制相应的权限，从而简化系统管理，减少系统安全漏洞。
访问控制列表管理
访问控制列表描述了用户访问服务器资源的具体信息：
每个用户都有各自帐号、口令和相应目录权限
用户可分配到不同组中
各用户组分别有不同的权限
用户、用户组的作用范围是一个Realm，不同的Realm中的两个用户即使同名也不会相互发生冲突。
另外界面的四层体系结构的实现方式，使得WEB Server并不直接与数据库相连，也充分保障了数据库端的数据安全。
大容量数据处理
数据库分表技术
计费话单的入库是整个计费结算系统中最耗费时间的部分，为保证批价系统的整体性能，合理地设计数据库（表）的结构是至关重要的。为此，我们按照以下的原则实现数据库详单表的划分：
原则1：按照IMSI码段（或其它标准）划分详单表；
原则2：按照手机号码段划分表；
原则3：码段的划分要与各地市所分配的码段保持一致；
原则4：按照时间划分；
其中原则1和原则2中只能选择一种。
按照上述原则，系统可选择如下具体的分表标准：
日期：不同天的话单被插入到不同的天表中；
归属地市：归属局为不同地市的话单被放置到不同的表中；
手机号码段：按照手机号码中的某些位划分表；
这些标准被存储在配置文件或数据库表中，系统定时读取这些标准建立或删除相应的表。按照以上原则，每个话单表的表名可能具有如下的形式：
本省话单： GCDR_XXQ00_L_19990120；
国内漫游来访： GCDR_XXQ01_NRIN_19990120；
国内漫游出访： GCDR_XXQ00_NROUT_19990120；
国际漫游来访： GCDR_XXQ00_IRIN_19990120；
国际漫游出访： GCDR_XXQ00_IROUT_19990120；
重复话单： GCDR_ALL00_DUP_19990120；
错误话单： GCDR_ALL00_ERR_19990120
其中：
G： GSM话单；
CDR： 详单；
19990120： 年月日
XX01： 地市代码 + 分区代码，；
L： 本地话单；
NRIN： 省际来访漫游话单；
NROUT： 省际出访话单；
IRIN： 国际来访漫游话单；
IROUT： 国际出访漫游话单；
DUP： 重复话单；
ERR： 错误话单；
按照以上标准划分表，使每个表所存储的话单数减少，从而提高数据的录入、查询、读取的速度，并进一步提高系统整体的效率。同时，系统将不同的表分配在不同的物理设备上，在进行数据入库或数据分发时，采用多进程并行操作，使入库、分发的速度大大提高了。此外，对这些表的维护并不需要用户的干预，系统将自动完成。
例如，分表标准可以以如下形式存储在数据库表中：
号码段1
号码段2
所属地市
13008000000
13008009999
XX00
13108000000
13108009999
XX00
13008100000
13008109999
XX01
13108100000
13108109999
XX01
13008110000
13008119999
XX02
13108110000
13108119999
XX02
。。。
。。。
。。。
虽然数据库本身也提供了自动分区的功能，例如自动根据手机号码分区，但与手工分区相结合，将会使系统具有更多优点：
手工分区完全考虑到应用中的要求，它的分区使得对数据库的操作能更有效地分配到不同的进程或线程（多进程、多线程在下节介绍），从而最大限度地保证的负载均衡。
手工分区的原则保存在数据库的表中，用户可以根据不同时间业务量的不同，合理地修改分区原则。例如，对新增加的号码段，用户只需要在表中增加或修改表中的记录即可。
手工分区具有更大的灵活性，它允许用户从多种分区原则中选择一种或多种原则的组合，而形成对本地业务（数据）处理最有效的方式。而相比之下，数据库的自动分区能够提供给用户的选择较少，只能在表中部分字段附加分区原则。
此外，系统的各个部分在处理过程中，也充分考虑手工分区的原则，在很大程度上，进一步提高了系统的整体处理速度。
多线程多进程处理
从另一个角度考虑，系统利用多进程、多线程的并行处理提高处理的效率。下图形象地描述了多进程、多线程之间如何实现批价的并行处理机制。
多进程之间的负载均衡通过第三方提供的CORBA软件来实现，它实时读取保存在内存中关于各个进程负载情况，动态地分配任务，以保证各个进程之间不会存在负载差异较大的情况。同时，在每个进程中又存在多个线程，由于同一进程内的多个线程共享内存中的基本数据（例如费率、优惠率等），这也将节省系统的资源。
用户可通过改变对计费所需话单数据存放目录的划分，灵活地调整各个进程负载，以达到有效地使用整个系统资源的目的。同时，在每个进程中又存在多个线程，由于同一进程内的多个线程共享内存中的基本数据（例如算法、费率、优惠率等），这也将节省系统的资源。
快速入库技术
系统设计中另外一个用于提高性能的方法便是采用快速入库的方式。不同与单条话单的插入（insert方式），快速入库每次将一个话单块直接插入到数据库表中，从而节省了与数据库通讯的时间。经测试，利用ORACLE数据库提供的Host Array方式入库方式，比单条插入的速度快2-3倍。
话单经由批价子系统处理后，按照定制的格式被写入到一话单文件中，入库程序根据目标表详单表的不同，将多个话单文件中的话单放入不同的话单块，然后利用块装载方式将话单成批量插入到数据库中。
将大表划分成多个小表的优势，也充分体现在这里。话单入库程序首先扫描格式化的话单文件，并拆分话单文件，并根据表分区的原则，将不同日期、不同归属局、不同手机号码段（IMSI码段或其它标准）的话单写入到不同的话单块（Block）中，然后对不同的话单块激活不同的线程。这使得话单并行入库成为可能。上述思想可以描述为下图：
分布式处理系统
由于采用的模块化的设计方法，系统内各个模块间的耦合度相应减小，使得系统内的各个模块可以被分布在不同的机器上运行。因些系统具有高可用性、高扩展性和高灵活性：当用户量较小时，可以将整个系统的各个模块运行在相对较少的硬件资源上。而当用户量逐渐增加时，可通过增加新的硬件资源，将原来在同一台机器上的模块分布到不同的机器上来满足新增用户的处理需求。如此就可以实现系统的平滑升级。
内存数据库技术
由于批价计费引擎采用了高度灵活的费率曲线导航（Rate Navigation）技术，能够实现大批量用户的个性化计费算法，这一产品特性对系统的设计提出了更高的要求：对于用户个性化计费的相关资料的访问必须是实时的而且访问刷新的频度极高。依靠传统的数据库技术所以及依靠简单申请大量内存空间保存用户资料的内存映像技术均无法满足这一要求：数据库所能够提供的访问接口的实时性不够，而内存映像技术的可管理性、访问接口标准化以及通用性程度都比较低，使用效果受程序人员编程水平的影响较大。亚信公司通过多年实践，融合了传统的数据库方案以及内存映像方案的优点，实现了高效的内存数据库系统，成功地满足了大容量的融合计费系统进行实时多业务个性化计费的需要。
亚信的内存数据库系统AIMDB是一个高效的内存数据库系统，它提供实时数据访问能力以及方便的C++接口。AIMDB目前还不支持C/S体系结构，所有应用AIMDB的程序必须和AIMDB运行于同一台主机上。AIMDB对受控的读访问模式进行了优化，通过消除数据传输开销以及有效的锁定机制提供高速的数据查询。数据库文件映射到每个AIMDB使用者程序的虚拟内存空间，查询在应用程序的进程空间（Context）被执行，不需要进行进程交换以及数据传输。AIMDB的并发数据访问的同步由一系列的“原子的（atomic）”指令完成，几乎不需要增加查询处理的开销。AIMDB假设所有的数据库存在于内存中并根据这一假设优化查询算法和结构。此外，AIMDB没有数据库缓冲区管理的额外开销，不需要在数据库文件以及数据库缓冲池之间传递数据。
AIMDB同样支持事务、在线备份以及系统崩溃后自动恢复的概念，事务提交协议基于根页面投影算法（Shadow Root Pages Algorithm），进行数据库的“原子的”刷新。数据库的恢复过程也非常快速，为关键应用提供高可用性保障。此外，取消了事务日志提高了系统的整体性能，更加有效地利用了系统资源。
AIMDB是面向应用的数据库系统，数据库表使用应用程序类信息建立，AIMDB支持自动配置的执行功能（Automatic Scheme Evaluation），只允许用户在应用程序类中进行修改。AIMDB提供灵活方便的数据检索接口，使用类似SQL的数据查询语言描述查询操作，提供后关系数据库系统的能力，如：非原子域（Non-atomic Fields）、递归数组、用户s定义数据类型及方法、直接对象间引用等等简化了数据库应用系统的设计并使之更加有效。
尽管AIMDB的优化根据计算机物理内存能够容纳所有的数据文件这一假设进行了优化，使用超过系统物理内存尺寸的数据库还是可能的。如果这种情况发生，标准的操作系统内存交换机制将会发生作用。由于AIMDB的查询算法和数据结构都根据所有的数据驻留物理内存这一假设进行了优化，对于交换出去的内存数据它们的工作效率会受到影响。
总之，使用AIMDB内存数据库系统为应用系统提供了传统关系数据库系统以及简单内存数据映像所不能提供的下列优点：
极高的查询执行速率
“后”关系数据库特点
与C++高度的集成特性
自动配置调整
高效的无日志事务处理
“零”恢复时间
这些特性通过标准、灵活、稳定的AIUMD产品提供，是实现大容量、多业务实时融合计费系统的强有力的技术保障。
批价子系统的外挂算法库方法，使系统对改进已有业务计费算法、实现更多的优惠促销方式更加方便可行。而多进程、多线程及内存数据库、详单数据的分库分表存储等技术又使系统的处理能力及扩展能力得到了保证。标准的数据传输接口，使系统既可以接收原计费系统提供的计费清单数据，又可以接收按标准格式和传递方法发送的其他外部系统的计量清单，扩大批价子系统的处理范围。
AICBS系统功能模块
AICBS体系结构
融合设计
真正的融合计费能力意味着能够适应不同的电信业务的特性和功能，对于这些业务如何组合以及计费并不加以限制。客户、业务以及计费过程之间的关系如图所示：
图 1 AICBS系统业务、客户与计费系统关系
AICBS通过对多种电信业务进行抽象，既保留了各种业务计费之间的共性同时也考虑到其特殊性需求，设计成功了能够完全适应业务之间的差异的计费系统业务接口，例如，AICBS的业务分析器以及费率导航机制提供了智能化的多业务计费接口，能够快速适应并管理任意多种业务、用户属性以及计费参数。该接口也能够对现有的业务和资费政策进行扩展，提供灵活的优惠和促销手段，使计费系统能够在激烈的市场竞争中，帮助运营商立于不败之地。
费率导航机制通过唯一明确的推理树支持计费特性/费率/计费算法的自动选择过程，这一机制允许用户扩展与/或隐藏计费特性、费率的类型以及计费算法模块。计费特性（也称为计费要素）可以组合成各种各样的计费条件，用户可以通过修改计费条件表达式维护计费条件。计费条件与各种费率类型之间存在着映射关系，不同的费率类型通过费率曲线ID进行区分，费率曲线提供了从简单的固定费率到分时段计费、通话/通信累计折扣、通话/通信费用赠予等复杂的可变费率的有效实现手段。计费算法模块提供针对不同计费模型的动态链接库，使用被选择的费率曲线对CDR对象进行计费。因此，费率导航机制最终实现了可变条件、可变费率以及业务无关的计费策略的自动推理选择以及CDR到对应计费算法模块的自动上载功能。
AICBS计费算法选择和费率导航机制的精巧设计允许多种不同业务在单一的界面上同时存在，类似的业务融合技术贯穿于整个AICBS的设计中，同时对于不同业务的特殊需求也能够完全满足，没有因为强调共性而损害了业务的个性特征。
系统架构
不同的电信业务具有不同的业务支撑平台，但其计费和营业的流程是一致的。作为融合计费系统的AICBS根据计费和营业的具体特点，划分为功能相对独立的几个子系统：数据采集系统、计费系统、帐务系统、客户管理系统以及相关的外围辅助系统。各子系统间通过标准的数据访问接口互相联接。各子系统的关系如下图所示：
图 2 AICBS系统结构关系
从图中可以看出，AICBS的数据采集系统对各类电信业务（GSM、WCDMA、GPRS、WAP、拨号IP、xDSL等）的计费原始数据进行采集和处理。通过计费系统的标准数据访问接口，采集系统将经过处理的计量清单传递给计费系统，由计费系统统一的计费引擎按照统一的处理流程，进行计费。通过帐务系统的标准数据访问接口，计费系统将经过计费的计费清单传递给帐务系统进行合帐/出帐等处理。帐务系统还对外提供了销帐、帐单查询等接口，客户管理系统通过这些接口对帐务系统的帐单进行缴费销帐、帐单查询等处理。
AICBS这种松散耦合的结构和各子系统完善的外部接口，使AICBS可以很好的兼容各类计费帐务系统，并且方便其他电信运营支撑系统（如客户呼叫中心、决策支持系统、防欺诈地同等）取得优质的数据信息。
运行环境
系统运行模块分布如下图：
AICBS系统部署图
AICBS主要分为三层，数据核心层包括数据库服务器和存储设备；业务逻辑层包括各业务服务器，提供接入服务，完成所以业务逻辑；接入层提供包括WINDOWS方式和WEB的接入服务。
计费处理功能模块
数据采集
AICBS数据采集系统采用面向对象、多进程、多线程技术设计，各类业务采集对象由一个基类派生而来，具体功能包括：
建立到CDR发生设备的连接
CDR数据采集
建立到应用系统的连接
CDR数据分发
CDR数据校验
CDR数据输入输出映射
域值转换和标志位设置
操作、管理和维护
等内容。
AICBS数据采集系统内部各个子系统采用了模块化的设计特点。输入协议适配器提供外部设备（交换机、网关、路由器）到数据采集系统之间的接口；输出协议适配器提供AICBS数据采集系统到后续应用的数据分发、传输接口；映射/校验/转换器提供输入和输出数据域之间的映射、输入域值的校验和输入域到输出域之间的转换。
数据采集、预处理、传输、备份和配置管理等几部分。
图 3 数据采集系统结构
AICBS对数据源采集进行了抽象和概括，采用通用对象模型（Generic Object Model，GOM）技术实现了CDR采集和预处理的灵活性和通用性。通过这种方法，数据采集系统将所有的数据类型表示为原型数据（Meta data）和实例数据（Instance data）的形式。GOM描述了数据采集系统中使用到的数据类型以及在不同信息模型、协议和应用中的外部表示。输入协议适配器负责外部的数据类型到通用对象模型的映射，这种能力允许采集系统能够与采用不同的协议、信息模型的应用系统进行互连。同时，这一抽象也使次你系统的内部模块不依赖于外部应用系统所采用的的协议、信息模型。输出协议适配器则能够将内部的GOM表示转换成为适应到外部系统的数据类型要求，使采集系统能够和多种使用不同的协议和信息模型的应用系统互连。
建立到CDR发生设备的连接
采集系统到交换机的接口被设计成为一个抽象的层次从而能够将通信协议和信息模型的细节和采集系统隔离开来。交换机接口包括对各种通信协议的支持，包括：FTP、FTAM、TFTP、NSF以及专用协议（Property Protocols）的API接口。对于专用协议接口的采集要求客户使用API编写通信程序，该程序在更高的层次上与GOM提供的抽象通信接口规范保持一致。
CDR数据采集
采集系统通过轮询或RPC的方式采集实时CDR信息。RPC方式要求对方提供标准的RPC协议。一般的，使用最为普遍的方式为CDR轮询，采集程序轮询模块根据配置从交换机下在数据文件或数据块。轮询模块配置信息包括轮询周期和错误恢复。轮询模块也采用了面向对象的设计，提供独立于用于交换机接口底层轮询协议的高层抽象。
建立到应用系统的连接
到应用系统（Billing System）的连接接口同样地被设计成为一个抽象的层次，将应用系统的协议和信息模型的细节和采集系统隔离开来。到下游的应用连接包括标准的网络管理协议SNMP、基于CORBA实现的接口、RPC、API PDU等等。
CDR数据分发
采集系统获得并完成预处理后的CDR数据由数据分发机制分发给下游的应用程序进行处理。数据分发机制支持分发周期、流量控制以及错误恢复等行为。数据分发机制通过与下游应用连接的抽象层次独立于下游应用系统具体所采用的通信协议和信息模型。
CDR数据校验
采集系统允许对每个输入数据域执行校验。没有通过校验的CDR被拒绝接受。基于独立的域的校验规则在采集系统的配置信息数据库中进行配置，校验规则能够在运行时间动态更新而不会中断或影响后续的数据采集和预处理服务。
输入输出域的映射
输入数据域通过映射机制映射到输出数据域。映射机制指明了输入信息模型域到输出信息模型域之间的映射关系。AICBS采集系统的配置信息数据库中的映射配置指明了多种可能的映射关系，包括：
直接映射关系：指单个输入数据域到单个输出数据域的映射方式；
分解映射关系：指单个输入数据域到一个输出数据域集合的映射方式。这种情况下，输入数据域一般为结构类型，映射中结构首先被分解为基本数据类型，再完成到输出数据域的映射。
构造映射关系：指一个输入数据域的集合到单个输出数据域的映射方式。映射中输出数据域首先被分解成为基本数据类型，再完成输入数据域到输出数据域基本数据单元的映射。
确省映射关系：指输出数据域必须包含一个值，即使输入数据域没有提供可供映射的数据。即输出数据域包含缺省值或输入数据域的映射值。缺省值由映射配置信息指明，转换函数指明了转换发生时采用的方法。
屏蔽映射关系：指输入数据域不必映射到输出数据域。映射配置中没有指定对应的输出数据域，输入数据域被丢弃。
域值转换和标志设置
在输入数据流映射到输出数据流之后，输入域值被转换到输出数据域值类型。域值转换包括许多种类的转换方法及其组合。最快的转换为等值转换，即简单的将输入域值拷贝到输出数据域，输入数据流和输出数据流的数据类型完全一致。对于其他类型的组合而言，转换函数实际执行了值的转换或生成，包括两大类，类型转换和语义转换。
类型转换（Type Translation）
类型转换将数值复制到新的数据类型表示（如：ASCII字符串表示整型数据）。 数值意义（Perceptual Value）不变但表示方法因数据类型而异（如：整型数7转换到ASCII数字7，其ASCII数值为0x37，不同于原来的整型数值0x07，而数字7的意义不变）。类型转换也执行一些辅助功能，诸如高精度数据类型转换中的内存填充或低精度数据类型转换中的舍入等。
语义转换（Semantic Translation）
语义转换首先执行类型转换，然后执行输入输出语义的映射。语义转换值可以是一对一的映射或者可以根据其他域的内容执行复杂的映射。
语义转换最重要的应用为标志位的填充。由于计费系统要求预处理能够产生一些原始CDR不能直接提供的标志信息和辅助数据，如：判定业务类型和漫游类型，判定业务发生地的相对位置和漫游类型，用户类型的识别等等，这部分结果必须经过若干判断或计算才能获得，或者需要引用原始输入CDR以外的资料。
操作、管理和维护
AICBS提供配置和控制采集系统行为的手段。前面描述所有的配置信息都能够通过AICBS系统的GUI 和命令行接口修改。系统管理员SA（System Administrator）可以启动、停止和暂停系统操作，系统管理员也能够校验整个系统的运行情况以及能够收集CDR的时、日、周和月处理报告对系统采集数据流量进行监控。
话单予处理
话单格式转换从交换机下载的二进制信息中提取用于计费和统计的信息，并从二进制格式转换为文本格式。格式转换根据原始数据格式的不同（不同交换机、不同业务）采取不同的转换程序。
随着业务的不断增加，转换程序必须适应新的格式标准。为此，系统采用内部统一格式，该格式以部中心规定的格式为标准。所有从交换机下载的原始话单数据以及由部中心下发的话单都首先被转换为内部格式，然后经由格式检查、错误纠正、话单计费等工序，最后再将内部格式根据不同的转换为不同输出格式。
采用内部统一格式使得格式的变更或增加不会引起应用程序较大的修改，最多只需要修改转换程序，而不必对应用程序中的其它模块做改动。系统内部格式一方面综合了不同格式之间的共同点，使得转换之后的各模块的公用成为可能；另一方面，该内部格式也应保持原有格式的部分特点，使得在后期转换时仍能够保持原有的信息量。
预处理功能
原始数据格式规范化处理：从原始计费数据中提取可用的信息，并转换为规范化的格式。
对原始数据的完整性检测。包括：
检查采集系统原始数据文件序号的连续性。
检查每个文件中每条话单之间的连续性。
汇总生成各类异常话单的种类、具体原因、数量等。
原始数据的预处理结果
分拣出各个交换机的正常计费话单。
预处理统计
异常话单统计。
无效话单统计。
错单纠正统计。
对检查出的非正常话单，应存储在数据库或文件中，以备查询。
话单数据文件预处理系统按照我国规范书，交换机在被叫一应答，计费就开始；在接受到一个前向释放信号或者后向的拆线信号后，计费将停止。AMA详单记录首先存放在相关的处理机内存中，然后可以传送到系统中的数据文件或备份到磁带，也可以实时输出。话单数据文件预处理系统主要完成的工作如下：
话单格式转换从交换机下载的二进制信息中提取用于计费和统计的信息，并从二进制格式转换为文本格式。格式转换根据不同交换机原始数据的不同格式采取不同的转换程序。
转换程序采用内部统一的格式，所有从交换机下载的原始话单数据以及由部中心下发(或从其他地市转发来)的话单都首先被转换为内部格式，然后经由格式检查、错误纠正、话单计费等工序，最后再将内部格式根据不同的要求转换为不同输出格式。
采用内部统一格式使得格式的变更或增加不会引起应用程序较大的修改，最多只需要修改转换程序，而不必对应用程序中的其它模块做改动。系统内部格式一方面综合了不同格式之间的共同点，使得转换之后的各模块的公用成为可能；另一方面，该内部格式也应保持原有格式的部分特点，使得在后期转换时仍能够保持原有的信息量。
原始计费数据预处理系统的纠错功能：
原始数据格式规范化处理：从原始计费数据中提取可用的信息，并转换为规范化的格式。
对原始数据的完整性检测
包括：
检查采集系统原始数据文件序号的连续性。
检查每个文件中每条话单之间的连续性。
汇总生成各类异常话单的种类、具体原因、数量等。
原始数据的预处理结果：
话单纠错
当错误话单的数量或比例达到一定程度时，系统产生告警信息提示系统管理员做进一步的检查。
此外，为减少电信部门的损失，在不影响费用计算的前提下，对话单进行适度的修改。具体包括下述可以纠正的错误：
删除对端号码中的非法字符；
修改与计费无关的其它信息；
主叫或被叫号码不完整，这些详单记录可以依据用户提供的修改模式和纠错模式进行修改和纠错。
可以将用户指定模式的错误处理情况在预处理时自动纠正。
数据传输
数据传输功能
数据文件传输系统主要的功能是：
传输采集系统的AMA话单文件交由后续的模块进行处理和传输在系统各个模块之间需交换的各种不同的数据文件。
数据传输系统在功能上具有如下特点：
为提高传输的效率，传输过程中采用高效的压缩和解压缩算法。
整个文件传输系统易于升级、扩展。在技术上采用标准的文件传输技术FTP。在系统升级或扩展的过程中，不影响正常的传输工作。
利用传输日志文件为系统提供历史运行记录和故障记录。
为提高传输的效率，传输过程中采用压缩和解压缩算法。
传输系统支持动态优先级控制，对于优先级较高的数据（如高额报告，租机、租卡业务数据）优先传送。
支持文件传输过程中的断点续传。
利用传输日志文件为系统提供历史运行记录和故障记录。
为保证数据的安全性，系统提供数据加密功能。该功能作为可选项提供。
数据传输与交换系统包括以下多个功能模块：
传输模块：传输模块传送文件到目的地通信服务器，同时接收对方的发送的文件，整个系统以全双工方式工作。对每次文件的传送，数据传输系统在日志文件中记录文件的详细操作过程，如传输协议、文件名、目的和源主机名、文件传送时间、操作成功或失败。
日志记录与管理模块：日志文件提供系统运行历史记录、故障记录是系统安全、控制和审计的主要依据。本模块收集数据文件传输系统的运行信息，按一定的格式记录在相应的日志文件中。每个通信目的地每天产生两个日志文件：发送和接收各一个。日志文件的更新策略可以由用户动态配置，以天或星期为单位定义日志文件更新和保存的时间。日志记录在计费中心通信服务器上集中保存和处理。
数据文件传输系统针对计费系统的特殊需要，进行了相应的优化，与UNIX操作系统现有的网络文件系统(NFS)相比，有两大优势：
能自动处理网络故障，能在网络恢复时
提供图形化的界面，以便实时的提供系统文件传输的状态和出错信息。
数据传输管理
数据传输与综合管理子系统(Data Transmission System)综合管理省计费中心多种业务处理过程中不同文件类型的传输。DTS具有以下特点：
实时、高效和安全可靠传送地地话单数据
DTS能完成计费中心与前置采集机之间的数据接收和发送任务。
DTS能自动处理各种可能的传输错误和故障，在网络传输质量不很理想的情况下，也能高效和安全可靠的传输数据文件，满足系统实时性的要求，保证话单文件实时和可靠地接收和传送到目的地。
集中控制和方便管理多个文件传输进程
DTS与各地市中心或采集机通过TCP/IP + 组成的广域网联结， DTS完成话单文件传输与管理任务的进程有两类：计费中心的通信服务器运行client进程，各地市的通信服务器或采集机运行多个DTS Server进程，分别与对应的计费中心DTS client进程进行文件的传输工作；Client进程不长驻内存，以消息驱动的方式启动。DTS进程组成一个星状结构，由 DTS系统的管理、状态监控进程，在计费中心的通信服务器上集中进行维护与管理。
动态优先级控制话单文件的传输
DTS为每个传送目的地的文件按照产生的先后顺序形成一个基本优先级FIFO队列，而对高优先级的文件，如高额报告、租机、租卡等实时性要求更高的数据文件，为每个传送目的地组成一个高优先级的FIFO队列。
根据漫游结算业务量的大小，DTS为每个传送目的地对应的基本优先级FIFO队列分配不同优先级，以反映传送文件的轻重缓急，平衡整个话单传输系统的负载，合理有效地利用系统资源。
在网络故障恢复后，有必要尽快传输对应站点的FIFO队列中的文件，DTS将这些文件转移到对应的高优先级 FIFO队列中，使系统尽快恢复到正常的文件传输。
支持文件传输过程中的断点重发
DTS支持文件传送过程中的断点续传功能。它能有效地利用有限的网络带宽，特别是对于大文件（比如10Mb）的传送，断点续传功能有特别重要的意义，即使大文件传送过程中发生了网络故障，也不会引发后续文件传送的延迟，有效地保证文件传送的实时性。
支持数据压缩传输
为提高文件传输的效率，DTS对每个话单文件进行有效的数据压缩操作，压缩率可达80％。有效地利用网络带宽，可极大地提高文件传输速度。
DTS系统组成
DTS系统包括以下多个功能模块：
传输模块：传输模块传送文件到目的地通信服务器，同时接收对方的发送的文件，整个系统以全双工方式工作。对每次文件的传送，DTS在日志文件中记录文件的详细操作过程，如传输协议、文件名、目的和源主机名、文件传送时间、操作成功或失败。
队列与缓冲管理模块：队列与缓冲管理模块按照文件产生的先后顺序为每个传送目的地形成一个基本优先级FIFO发送队列，而对高优先级的文件，如高额报告、租机、租卡等实时性要求更高的数据文件，DTS为每个传送目的地组成一个高优先级FIFO队列。基本优先级队列的文件可根据需要转移到高优先级的 FIFO队列中，以暂时提高某个目的地文件传送速度。
对可能网络中断的故障，DTS把文件缓存于FIFO 队列中，投递相应的故障报告和日志记录。队列与缓冲管理模块随时监视网络状态；并在网络故障恢复后，及时恢复文件传输，为了不至于影响后续文件的转送，这时所有缓存的文件都转移到对应目的地的高优先级 FIFO队列中。
对于因网络故障而中断的一次文件传输过程，由队列与缓冲管理模块记录该次文件传送的中断点(Check Point)，并在网络故障恢复后，投递断点续传的通知(Notification)给传输模块，继续完成文件传送的后续部分。
任务调度控制模块：由于各地经济发展的不平衡，反映在计费中心与地市之间的通信量上，也极不平衡。根据漫游结算业务量的大小，各地市分成多个个档次，在任务调度控制模块中分别对相应的FIFO队列分配不同的基本优先级。队列和缓冲区管理模块根据不同优先级来决定传送文件的轻重缓急，平衡整个话单传输系统的负载，合理有效地利用系统资源。
在网络故障恢复后，有必要暂时提高该条传输链路上的优先级，通过队列与缓冲区管理模块，将基本优先级 FIFO队列中的文件动态提升到高优先级的FIFO队列中。
任务调度控制模块支持两种工作模式：
自动模式，在该模式下，DTS根据初始配置自动进行文件传送操作，并进行日志记录和故障告警。
人工模式，在该模式下，由用户启动文件传送操作，对过期话单进行操作。DTS使用ACL(Access Control List)机制，对用户操作的合法性进行口令一级的验证。
日志记录与管理模块：日志文件提供系统运行历史记录、故障记录，是系统安全、控制和审计的主要依据。本模块收集DTS的运行信息，按一定的格式记录在相应的日志文件中。每个通信目的地每天产生两个日志文件：发送和接收各一个。日志文件的更新策略可以由用户动态配置，以天或星期为单位定义日志文件更新和保存的时间。日志记录在计费中心通信服务器上集中保存和处理。
故障告警及性能调整模块：本模块跟踪监视DTS进程的状态，收集日志文件中有关的信息，将统计分析的信息以可视化的界面显示，并告警。
此外，整个DTS系统可调的性能参数如传送优先级，以集中化的GUI界面提供配置和调整的操作。
计费资源管理
计费基本资料是维护计费系统正常运行的各种基本数据和参数。由于AICBS是一个多业务处理系统，同时不同业务的资费处理方式各有不同，因此，亚信的AICBS的计费资源管理系统需要满足包括IP、XDSL、GSM、GPRS、长途等的资费管理要求。
此模块用于维护和管理各种计费规则、计费标准，以及其它用于维护系统正常运行所必须的参数，
资源管理系统的实现
资源管理系统通过由前台程序与后台程序两部分组成，前台进程为微机端的操作界面，它在用户使用时被调用；后台进程则一直驻留在主机端。前台进程通过IDL（Interface Definition Language）与后台进程联系，后台进程与数据库联系。
有效期设置：对费率、优惠率，系统在设计过程中都设置有效起始日期和有效终止日期，因此数据库中可同时存在多种费率或优惠率，计费系统则根据有效起始日期和有效终止日期判断适合的费率或优惠率。这对费率或优惠率的过渡更为容易。
费率的多样性：为适应未来的发展，对费率的管理不仅仅考虑费率一个因素，还同时考虑基本通话时间、基本通话费用、费率计算单位（分、秒，或其它）等因素，以保证费率的变化不会导致数据库表结构的变化。
优惠的多样性：优惠管理除正常的节假日、时间段优惠外，应能针对部分特殊地区，有自己的特殊的优惠时段及日期；
资源的动态更新：各种资源的更新最终将表现在计费系统中，为保证资源的更新立即体现，系统利用回调函数的功能，每当资源发生改变时，都发送消息给计费系统，而计费系统在接收到消息后刷新内存中的数据。
话单资费标准管理
话单资费标准就是通常所说的“费率”，它用来计算每条话单的基本费用。话单资费标准对所有的话单都等同对待，即它不包含任何与客户相关的信息，而话单资费标准的管理也就是对这些费率的管理和维护。
具体包括：
各种业务的基本费率。
各种业务的国际长途费率。
各种业务的国内长途费率表。
费率曲线段表；
个性化计费条件描述定义表；
费率的管理保证在两种费率交替的过程中计费不中断。
优惠策略管理
话单资费优惠在话单基本费用的基础上，按照不同的优惠率对话单的费用进行第计算。通常情况下，此次计算只是在原有结果乘一固定的比率（<1），系统支持以下优惠方式：
时间段优惠：时间段优惠设置在一周7天内不同时间段的优惠率；
节假日优惠：节假日优惠预定义一年内所有的节假日，及其对应的优惠率；
个性化优惠：根据用户的属性定义针对个人的优惠资费政策，包括用户类别定义，用户出生年月定义等；
集团用户优惠：允许定义针对集团内用户之间互打的费率。
交叉优惠：同一用户不同使用不同的服务，系统允许可以针对这种情况相应的在某种服务达到一定的阀值，可以对另外的服务的资费相应的进行优惠。
折线优惠：对于某一种服务来说，系统允许定义在不同的时间段或是在使用量达到一定的阀值时可以实现采用不同的费率。
当多种优惠条件同时满足时，按照相关的优先级规定选取优惠率。
其它资料管理
计费号码段与服务器关系表；
函数信息表；
全国交换机信息表；
全国VOIP网关信息表；
用于保证系统运行的配置参数
国际区域对象表
国际区域对象表
国际国家表
全国省表
全国城市表
号段分配表
通话类型表
费用类型表
通话计费公式表
等等。
批价系统
AICBS计费系统采用多进程、多线程、面向对象以及中间件技术实现。在计费系统中多种业务采用统一的计费引擎进行计费。计费引擎根据不同的业务属性从算法库中选择合适的算法（如普通计费算法、实时反算算法、用户个性化计费算法等）实现计费。算法库是由一组可动态装载的算法组成的，所有算法都提供标准调用接口，因此算法库中的算法可以根据业务变化动态更新，不需要对整个系统进行重新编译。对于计费算法中经常参考的用户定购信息、资费信息、个性化优惠信息等，采用内存数据库的方式来处理，以提升系统效率。而计费后的详单，由于数量较大，采用分库分表技术存储，存储规则动态管理、动态生效。
计费系统结构
AICBS计费系统的具体结构如下图所示。它由数据传输接口、计费引擎、内存数据库、资源管理、详单管理和计费算法库等几个主要部分组成。
其中数据传输接口是外部计费清单数据进入本计费系统的标准通道，采用了解密、解压、断点续传等技术。
计费引擎主要根据资源管理所做的配置选择相应的算法和相应的用户个性化信息对服务进行计费或进行费用的反算。
内存数据库主要用于缓存计费时需参考的用户定购信息、用户个性化优惠信息、资费信息等。
资源管理主要进行各种服务的计费规则管理、计费算法的维护（升级、装载、卸载）、业务同算法的对应关系的配置、详单存储的分库分表规则以及其他一些计费系统本身需要的参数的配置。
详单管理提供了对详单的备份、查询等功能，并为外部系统（如客户管理系统）提供了访问接口。
高效灵活的资费策略
AICBS计费系统采用了业务选择、费率导航和计费方法动态挂接的方法，实现了灵活的动态费率，包括：
对任意一种基本费率，可采用任意的折线来表达，折线可以分任意多段，这些基本费率包括：基本通话费、国内漫游费、国际漫游费、国内长话费、国际长话费、C3费、长话附加费、上网费、Email费、专线费。
可以指定任意费率曲线的任意段的费率、计费单位（对时长为秒的任意倍数，对流量为字节的任意倍数）以及尾数处理方式，如国际长话费打折后要求费率精确到角等。
对同一种费用类型可以设置几条费率曲线，让它们在不同的时间期限内起作用，以便灵活地修改费率和测试。
对同一种基本费率可以设置几条费率曲线，让它们在不同的条件下起作用，以便灵活地适应不同的优惠情况。如普通GSM通话费率为元/分钟，本地通的通话费率为元/分钟，呼转的基本通话费为元/分钟，同属基本通话费，但进行费用计算时可根据不同的条件（普通通话、本地通通话、呼转通话）采用不同的费率。还可以轻松实现如下效果：GSM拨打GSM 元/分钟，GSM拨打固定元/分钟。
同样，长话费率也可以非常灵活，不仅可以指定任意发起地到任意目标地之间的费率曲线，而且任意发起地到任意目标地之间的费率曲线可以同时设置好几套，这样就可以实现在不同的条件下让不同的费率曲线起作用，如GSM拨打固定采用一套长话费率，GSM拨打GSM采用另外一种长话费率。
可以轻松设置单向收费。单向收费执行前一种费率，单向收费后一种费率可以同时包容。
通过可扩展的计费方类型和对端类型可实现非常灵活的费率和优惠。计费系统的许多灵活性和可扩展性都可以通过这种方法来实现。计费方/对端类型的获取有两种情况，一种是通过NUMBER_TYPE表获取，号码由3位组成number_prefix + area_code + number_head，number_prefix可如同17951、17911等，也可以没有，area_code可以没有，可以通配，也可以指定，如0898，number_head如110、120等免费特服号码，也可以是传呼台如127、129等，也可以是1860、1861以及其他催缴费号码，这些种类的费用类型、费率曲线、优惠类型可通过配置条件表任意指定。另外一种是以号段表或其他表来表示的，如本地通的号段，对具有相同属性的号段指定一种号码类型，这个号码类型参与到条件编码表的编码中，从而可以对这些特定的号段执行不同的费率和优惠策略。如某些号段的本地通，执行元的通话费率，而另外一些号段执行元都可以灵活实现。由于采用了非常灵活的条件费率表，IP电话的费率和优惠都可以不用修改程序直接在表中设置，而且具有非常强的可扩展性。基站优惠和小区优惠也是这些表中的一种，通过这些可以实现任意的基站优惠和小区优惠。
4-7的实现都是通过条件表起作用的，条件表是一座桥梁，将费率条件和费率曲线有机连接在一起。由于精心的设计，不同的呼叫类型、漫游类型、对端机型、对端位置类型、计费方号码类型、对端号码类型都参与影响费率的计算以及优惠的实现，因此扩充费率种类以及条件以及实现不同的优惠都非常容易。而且，计费方类型和对端类型都是可扩展的，因此具有非常广泛的灵活性。
可以实现个性化的优惠，如集团用户优惠、家庭/朋友优惠、生日优惠。
可以实现积分优惠，积分的条件可以定义，积分的策略也可以定义，积分满足一定条件给予一定的优惠或转化为金钱或其他资源。
可以赠送免费资源，如对预付费用户每月免费赠送50分钟的基本通话费。
AICBS计费系统的统一计费引擎、外挂算法库的方法，使AICBS对新业务计费的支持、对已有业务计费算法的改进、实现更多的优惠促销方式更加方便可行。而多进程、多线程及内存数据库、详单数据的分库分表存储等技术又使系统的处理能力及扩展能力得到了保证。标准的数据传输接口，使系统既可以接收由AICBS采集系统提供的计量清单数据，又可以接收按标准格式和传递方法发送的其他外部系统的计量清单，扩大AICBS计费系统的处理范围。
错单处理
送到计费批价引擎的话单进行计费时，由于话单本身的信息不全或是不正确，或是由于计费系统的资源信息不全造成的无法进行对话单计费，需要将该类话单进行单独处理，系统支持将该类话单写入一个单独的LOG文件，或是单独对该类话单进行入库，提供GUI界面可以对该类话单进行修改，保存，同时系统支持对由于计费系统的资源信息不全造成的错误话单在补全计费资源信息后重新对该类话单进行计费、入库处理。
为了对错单的数量、类别能够进行分析，系统提供了对错单的统计功能，帮助用户对错单产生的原因分析提供一个参考。
重计费处理
重计费与错单的重处理是完全不同的两个概念，它们之间的联系也并不多。错单一般是由于话单本身资料不全或系统提供的资料不全造成从预处理到批价之间某一步不能正常进行下去，这种话单会被当成错单输出到文件中，不会被入库。而重计费主要是对出现以前没有察觉的错误而被正常入库的话单进行处理。
重计费与错单的联系是，当错单与累计资源相关时，它可能会使以前认为正确的话单现在认为不正确了，造成许多正确话单的重计费。
重计费的产生
造成重计费的原因有以下几个方面：
资料表维护不正确，造成张冠李戴。这种错误一般会是大批量的。
客户在月中更改产品，而所更改的产品会要求全部重新计算该客户在本月的累计资源。这种更改一般是局部的。
程序的分析出错，没有正确地判断出话单的基本信息，但又没有判断成错单。这种错误可能会小批量地出现。
基本信息分析正确，但计算话费出错。不过这种错误一般可能是跨时段打折等极少数没有完全测试到的地放产生。这种错误一般也是小批量地出现。
某种有累计资源或免费资源的订购，如果有大量话单被当错单剔除，即使将错单重新处理也可能影响正确性，这时也需要将以前正确的话单一并找出重新批价。
相关模块的处理
计费程序
没有复杂的不良影响，只不过多处理了一些话单，当然特别大批量的话单量会影响效率。重计费的设计一定要保证它们只管处理话单，不要由于哪条话单是重计费的话单就特殊对待。
免费资源和累计资源
有相当的影响。重计费如果涉及到它们，不是影响单条话单，而是可能会影响其它正确话单。基于这种影响，要考虑定期备份和恢复。
帐务系统出帐
影响很大。出帐的一个重要数据源是详单，详单出问题帐务将不准确。基于对帐务的影响，重计费可以考虑在合适的情况下出反单消除影响；在出反单困难的情况下，帐务方面需要考虑重出帐。
重计费后怎么出帐，考虑三种方式。对这三种方式，重计费都会实现，将来可根据实际情况选择。当然我们不能解决所有的情况。
反单重出
计费出反单，出帐仍按常规
譬如计费发现了需要重计费的话单，这些话单在详单中的金额是80元，重计费不删除这些话单，也不对这些话单的基本信息加以改变，而是在详单中加入与这些话单金额相反的话单，插入反单的合计金额应是-80元。这时如果再出帐，80元的错单相当于完全没有。然后等重计费运行完后，这些话单被正确批价，入库，这时如果再出帐，这些话单的正确费用将被出出来。
如果发现错误已是在下一个帐务周期了，上一个周期的错误不可能被更改，但是可以将上一个周期的错误在本周期的帐务中改正过来。
本周期要消除上一个周期的影响是有条件的，如果帐务的费用与周期累计使用情况相关，那么上一个周期的错误将不可能在本周期消除影响。（如果要解决，简单的重出帐也不可能办到，只有复杂的重出帐才能办到）
这种方式可以解决大多数的情况，即使跨帐务周期，只要不涉及累计问题也可以消除影响。
由于由计费来实现帐务的平衡，出帐将非常简单。但这种方式对计费的压力较大，当话单量很大时，对数据库的写操作非常频繁。
错单删除
计费删除错单，简单重出帐
这种方式是计费不管帐务平衡，只简单将错误话单删掉，然后批出正确话单再放进去。由重新出帐来得到正确的帐单。
这种方式的作用有限，它只能算出正确的费用和帐务，不能消除上一个帐务周期的错误。所以这种方式只能用在同一个帐务周期里。
这种方式需要有周期内的重出帐的功能。
复杂重出帐
计费出反单，置record_property，复杂重出帐
对于跨帐务周期的错误，又涉及到累计使用值对帐务有影响时，只有这种方式可以解决。
这种方式重计费仍按出反单的方式做，这样做是为了保留以前的错误信息，而且record_property可以标出话单的重计费性质。
重出帐需要同时考虑两个周期的关系和影响，因为前一个周期的帐有误，需要将这些错误的话单销弃（record_property= -1），反单其实在这里并没有用，但重计费后的正确话单需要被加进来（这时需要record_property = 1），这种重计费后的话单按常理会出在下一个周期，但出帐需要判断出它们再交给上一个周期，这样，两个周期的帐就都平了。
帐平了还有问题，就是上一个周期的帐单可能已经下发，这样就还需要将上一个周期的错误帐单和现在计算出的上一个周期的正确帐单做比较，将差额放到本周期的帐单上去。
这种方式对重计费和重出帐都要求做更多的工作。重计费以前不对重计费后的话单施加影响，现在需要将它们的recprd_property设为 1。重出帐需要做更多的工作。
其它
最复杂的情况，递归影响（可不考虑）
因为上一个周期的费用可能对累计资源有影响，重计费和重出帐即使有能力消除这种帐务上的影响，这种影响的消除依赖重计费的正确性，但这种影响还可能影响下一个周期的计费，重计费当然也可能被影响，本身就不可能正确。
这种影响应当如果要解决，需要重计费和重出帐两次。首先重计费和重出帐上一个周期的话单和帐单，然后再将上一个周期的帐务对计费的影响带过来，再一次重计费和重出帐本周期的话单和帐单。
稽核
有相当的影响。重计费会使稽核在某一步出现话单增多的情况，这种影响与错单不完全一样。这种影响的消除需要分不同情况采用不同的方式解决，譬如出反单和不出反单需要考虑它们对稽核的不同影响。
重计费功能说明
重计费的第一步与为什么要重计费密切相关。当通过观察或其它告警信息得知计费流程出现错误，而这些错误经过分析，需要重计费才能解决时，就开始了重计费。当然还有客户更改订购也造成需要重计费。
首先需要判断哪些话单需要重计费，确定下来找出这些话单的原则后，重计费模块的找话单部分有足够灵活的功能，可以根据各种不同的条件组合找到这些话单在备份文件中的位置。注意找话单并非只找有错误的话单，当错误对免费资源和累计资源产生影响时，需要找到所有相关的话单。找话单部分还需要将这些话单集中起来形成一定规范的文件名，留待备份和进一步处理。对这种话单和文件我们可命名为重计费的原始话单和原始话单文件。
重计费还需要对找到的话单进行分析处理，这种处理包含几个方面，首先是确定话单的idr_id，这是话单的唯一性标识。
最关键的是对详单的处理。对详单的处理依采用的策略不同而不同。如果是用出反单的方式，需要找到这些话单在详单表中的位置（可能有两条），增加相应的反单在详单库里，并设置正确的时间和必要的标志。如果出帐采用重出帐的方式，就可以简单地将这些详单删除掉。
还需要有剔除重单库中相应话单的功能，可根据idr_id找到这些话单在重单表中的记录，将它们删除掉。
另外还需要将话单的original_file进行相应的处理，以保证稽核的正确性。这种处理与对详单的处理相关，还与重计费的原始话单类型相关，错单和计费成功的话单处理方式是不一样的。
将修改过的话单送给批价模块再批价，这种功能不需要写程序，只要扔过去话单就行了。
重计费后稽核一般需要重做，这也没有新程序去完成，只要运行相应天数的稽核就可以了。
除了各部分的功能外，重计费在结构上还需要有好的日志输出。它经常需要由idr_id去查找数据，也存在数据库的transaction操作。当没有找到匹配项或事务提交不成功时，有完整的日志。
重计费不能控制的部分是，当帐务周期已过，帐单已经下发，重计费没有能力对那些帐单发生作用。重计费只能在本周期内起作用。
重计费性能说明
重计费的各部分准确性是非常重要的，批量的错误处理人工干预是很难的，而重计费要是再出问题将更难处理。
大批量的话单重计费时需要考虑速度问题，特别是对详单的操作，比较费时。如果数据量太大，考虑不要采用出反单的方式，而是直接删除，减少处理量，让出帐去重出帐。
稳定性是需要注意的问题，重计费的一些步骤不象其它模块一样可以方便地重新处理，譬如处理详单地部分，如果处理了一部分还剩一部分，应当能够在找到问题原因之后可继续执行。
重计费系统结构
重计费的大流程如下：
从重计费需要开发的部分看，它有如下几个部分：话单查找部分，计算idr_id部分，详单处理部分，重单处理部分，为稽核的修改部分。可以将话单查找和计算idr_id部分合为一个部分，也可以将详单处理和重单处理部分合为一个部分。
重计费的处理过程
重计费过程始终存在人为的分析、判断、干预，程序只是辅助工具而已。
首先，需要判断重计费的准确原因，一旦确定确实需要重计费，就停下计费模块等待进一步的处理。
分析这些原因是否会影响免费资源和累计资源。
分析错误对帐务的影响，是否跨帐务周期，是否对帐务的累计值有影响。确定采用何中方式处理重单。
找话单。同时删除多余的备份话单。还生成idr_id。
处理详单和重单。
如果涉及到免费资源和累计资源，需恢复免费资源和累计资源。
如果对稽核有影响，需消除影响。
重批价。
入库系统
处理机制
数据库分区技术只有结合了多进程多线程技术，才能充分利用数据库服务器SMP体系结构并行处理能力的优点，对多个子表并发进行数据访问，提高数据库操作的效率。
多进程之间的负载均衡通过CORBA（Common Object Request Broker Architecture，公用对象请求代理结构）网络应用代理软件来实现，它实时读取保存在内存中关于各个进程负载情况，动态地分配任务，以保证各个进程之间不会存在负载差异较大的情况。同时，在每个进程中又存在多个线程，由于同一进程内的多个线程共享内存中的基本数据（例如费率、优惠率等），这也将节省系统的资源。所有的数据查询操作和写入操作均可通过多进程/线程在多个数据库子表上实现，由于在数据库结构上（甚至物理磁盘上）将数据库表分散成为各不相关的子表，大大缩小了每一个子表的规模，由支持并发的读写操作，降低了锁表概率，所以能够极大地提高数据库系统的性能。
快速入库
数据库系统设计中另一个用于提高性能的方法便是采用快速入库的方式。不同与单条话单的插入（insert方式），快速入库每次将一个话单块直接插入到数据库表中，从而节省了与数据库通讯的时间。经测试，利用ORACLE数据库提供的Host Array方式入库方式，比单条插入的速度快2-3倍；与之近似，利用SYBASE数据库提供的BulkCopy方式入库，比单条插入的速度快2-3倍。
话单经由计费处理后，按照定制的格式被写入到一话单文件中，入库程序根据目标表详单表的不同，将多个话单文件中的话单放入不同的话单块，然后利用块装载方式将话单成批量插入到数据库中。
将数据库的分区分表及手工分区分表相结合的技术，使得可以将大表划分成多个小表，从而充分利用多进程多线程的入库方式，提高入库速度。话单入库程序首先扫描格式化的话单文件，并拆分话单文件，并根据表分区的原则，将不同日期、不同归属局、不同手机号码段（IMSI码段或其它标准）的话单写入到不同的话单块（Block）中，然后对不同的话单块激活不同的线程。这使得话单并行入库成为可能。上述思想可以描述为下图：
图 话单入库设计
重单处理
采用快速入库的方式考虑到出现重复话单的情况，系统将通过如下的方式来处理：话单批价完成后，需要提取话单中的某几个字段（以GSM语音话单为例），起始呼叫号码，起始呼叫时间，对端号码，采用HASH算法，将这三个字段的值进行进一步的计算得到一个该话单对应的唯一性标志码，并将该标志码保存到文件中，同将该标志码也保存在内存中，下一条话单计费完后，同样进行这个HASH算法，如果得到的唯一性标志码与已有的标志码相重复，则表示该话单是重单，将该话单入库到重单数据库进行分析，查询。采用HASH算法来实现重单的检验，比用数据库的唯一性索引来检查重单，极大的提高了话单的入库速度，主要体现在两个方面：采用HASH算法，对于检验话单的重复提高了速度；入库时可以完全采用块操作的入库方式，不需利用数据库的唯一性索引来检验数据的唯一性，也提高了话单的入库时间。
综合帐务管理模块
帐务系统结构
帐务子系统采用表驱动方式进行帐务处理，即需要进行出帐/合帐的业务通过可配置的表来标识需要处理的科目。帐务子系统也采用了多进程、多线程技术，并且帐单的存储根据用户的信息、服务的特性等进行了合理的分库、分表存储，存储规则可以动态管理，动态生效。
AICBS帐务系统的具体组成如下图所示，主要具有出帐/合帐、销帐、帐户平衡检查、帐户查询、帐单输入输出、帐单调整、预存费销帐、欠费管理、坏呆帐处理等功能。同时提供了外部销帐接口、外部查询接口等。
其中出帐/合帐及固定费用生成是具体的生成帐单的过程，在生成帐单的过程中，可以进行多业务的交叉优惠处理。
帐单输入输出API是本系统的帐单托收及其他系统帐单的代收或合帐的标准数据访问接口。
销帐API、帐户平衡检查API既是帐务系统进行帐单调整、预存费销帐、欠费管理、坏呆帐处理的接口，也是外部系统（如客户管理系统、银行业务系统）等访问AICBS帐单的接口。
资源管理负责定义帐务系统的帐单内容、帐单存储规则、出帐的方式（定时、定日、周期、实时等）、坏呆帐的定义等。
AICBS系统提供了多种出帐方式，可以支持运营商开展多种业务（如预付费业务、卡业务等）；AICBS还提供了多种销帐方式，可以支持缴费销帐、银行托收销帐、预付费销帐、部分销帐（即对用户的多业务帐单中的某类业务进行缴费）等；AICBS帐务系统丰富的API接口，可以与外部系统进行各种信息交换；AICBS帐务系统帐单内容的可配置性，为支持多业务处理提供了有利的保障；AICBS帐务系统最重要的特点是(一个用户的多种业务，一张帐单。
出帐功能说明
由批价后详单、业务办理费用和由出帐程序计算出的各种费用生成各种普通帐单，在普通帐单基础上根据帐务优惠政策产生各种优惠帐单，最后进行帐单产生后的各种可能的处理（如预存费销帐）。
支持由批价后详单驱动的实时出帐、周期整体出帐和周期间按需批量出帐。
帐务主要设计思想
框架化的设计思想
为满足功能可扩展性和包容性的要求，本子系统采用框架化的设计实现思想。
所谓框架化设计实现就是将实现最终系统的过程视为一个随着领域功能定义的分类细化和最终明确逐步将基础框架递增地实现至最终系统的过程。这是对领域功能的分层分类细化的抽象分析过程和逐步扩展框架的实现过程。实际上我们一直就在进行框架的扩展工作，因为“main() {}”就是我们不自觉行为的基础框架，虽然这种扩展过程通常都是无序和缺乏考虑的。
通过总结某领域集合的共同功能并将这些功能实现于框架中，可提供适合于该集合中任一领域的框架，具体到某一领域将是此基础上的进一步框架扩充或仅仅是框架剩余部分的简单填充或配置。我们试图以此达到代码和行业处理逻辑的最大共享和面对新需求、新业务情况下的快速实现和部署。
针对移动公司业务的不断发展，包括移动公司提供IP服务的需求等等，我们试图实现一个包容这两个领域的某些共同功能的帐单生成子系统框架，以图将移动和IP等领域具体业务的实现过程简化，为此框架上增加处理线、修改配置、配置新的SQL语句和存储过程等设计策略，以及允许在不得已情况下增加新的二进制代码。因此，亚信的BOSS产品模块AICBS帐务子系统采用了框架设计和功能模型设计，目前AICBS主要包含如下共同功能模型：
☆ 基本的分布协作处理模型
☆ 任务定义及故障恢复模型
☆ 进度控制模型
☆ 业务资料模型、帐单模型和它们的分表逻辑
☆ 其他公用服务
模型控制的采用极大的降低了复杂帐务功能开发的难度，使亚信AICBS帐务处理更加灵活、可靠和高效。
框架中的主要功能模型
☆基本的分布协作处理模型
帐单生成子系统中的进程分为主控调度进程和任务处理进程。进程之间主要通过数据库进行同步协调。
任务处理进程（包括实时任务处理进程和批量任务处理进程）工作方式基本相同。从任务控制角度而言，每一任务处理进程均有一个当前处理顺序号，进程启动后首先根据运行参数基于任务号和处理顺序号进行全局回滚恢复或者进行局部恢复以实施前滚处理，由此进入一致的数据状态，随后进程根据任务定义依次执行各子任务（一个SQL语句、一个存储过程、或一个二进制代码函数），并在状态表中标识子任务的完成情况，完成所有子任务后标识整个任务的完成，随后退出运行。从数据流角度而言，每一任务处理进程均采用自己独一无二的标记来标识自己的处理踪迹，即标记费用项目数据源表（包括各种批价后详单表、各种业务费用表）中的若干记录以加锁这部分费用源，随后以这部分费用源为基础与其他任务进程互不干扰地生成各种帐单，进行相关帐务处理，在此过程中同步标记自己对数据库的更改。考虑到性能问题，可能引入中间记录表来实现标记，以减少处理环节之间的数据竞争，并通过避免数据库更新操作来提高处理性能。
主控调度进程对任务处理子进程进行全局协调。具体地，该进程负责控制处理进度，发动、协调和监控任务处理进程、完成其他全局操作。
同一主控调度进程下的任务处理进程共享由主控进程管理的处理序号，可根据处理负荷和性能要求配置多个任务处理子进程。最初的版本可能只支持在单一节点上启动主控进程和所有任务处理子进程，考虑到帐单产生负荷绝大部分在数据库操作方面，可分担到多个db server上，这种方案是可行的。万一因处理的复杂性增加而导致单节点上的非数据库处理负荷上升，通过在节点上设置代理也可方便地将任务处理进程分布到不同节点，且不影响系统结构。
主控进程分两种，即周期批量出帐主控进程和实时出帐主控进程。前者控制批量任务处理进程进行周期批量出帐，后者控制实时任务处理进程进行实时出帐。一般全系统只有一个批量主控进程，但根据情况可配置多个实时出帐主控进程。
批量任务处理进程分两种，即原始费用累加进程和帐单生成进程，前者将原始费用进行累加，后者基于累加结果产生帐单。批量累加和批量出帐是两种独立的任务，两种进程不同时存在，均由主控进程协调控制。
实时任务处理进程同样分两种，即原始费用读取和累加进程及实时出帐进程，前者将详单从详单表读取到中间临时表、并累加临时表中因各种原因未能出帐的详单，后者使用临时表中的记录进行实时出帐。实时读取和实时出帐是两种独立的任务，两种进程不同时存在，均由主控进程协调控制。
☆任务定义及故障恢复模型
程序运行过程中任何事故都可能发生，帐单生成子系统应确保在任何故障情况下确保数据的正确性和一致性，这依赖于框架的故障恢复功能，任何加入这一框架的模块均应遵循这一故障恢复模型。
系统的运行以任务为单位进行，与数据库中的事务概念一致，每一任务中的所有操作要么全部执行要么全不执行，以此确保整体数据的正确一致性。每一任务由一顺序号唯一标识，任务的跟踪和恢复即以此顺序号为依据进行。系统重新启动后，根据运行配置参数，对因任何故障情况而终止的任务有如下两种选择：
先执行全局回滚恢复以清除被中断任务的所有影响（这依赖于任务顺序号进行），从而进入正确一致的数据状态，尔后重新执行任务
执行局部回滚恢复使被中断任务进入子任务一致状态（这主要依赖于数据库事务概念），尔后顺次执行被中断任务未完成的子任务
☆进度控制模型
这是针对批量帐务处理而言，首先明确几个概验，固定出帐点提供了帐单周期的概念，两个固定出帐点之间为一个帐单周期，帐单周期影响与周期有关的费用。整体累加点分布于固定出帐点之间，整体累加累加截止该点为止未被出帐的各项费用，目的在于提高最终进行帐单生成的速度。即时按需出帐将指定范围用户截止按需出帐点为止的未形成帐单的各项费用形成帐单。从历史的角度看，若我们将固定出帐点和整体累加点称为阶段点，则批量出帐历史是由一个个阶段点和随机分布于阶段点之间的若干即时按需出帐点组成的。框架提供代码让主控进程确保上述历史图景并进行操作延时控制，以避免已批价详单等费用项的遗漏。框架提供公用函数根据上一次固定出帐点和相关配置（出帐方式，按月周期出帐时的出帐日和按定长周期出帐时的周期长度）计算下一次固定出帐点。
☆ 业务资料模型、帐单模型和它们的分表逻辑
我们用用户、帐户、设备来概括业务资料模型，一个用户可拥有多个帐户，一个帐户可拥有多个设备，由此形成树型结构。在设备一级首先形成原始的服务级帐单（service bill）。基于服务级帐单和用户、帐户、设备的各种属性可完全定义各种优惠条件，基于这些优惠条件可产生所需要的各种优惠帐单。按照生成优惠帐单的service bill所属的范围，优惠帐单分别属于以下三种：
设备级优惠帐单：所有service bill属于同一设备
帐户级优惠帐单：所有service bill属于同一帐户，但不属于同一设备
用户级优惠帐单：所有service bill属于同一用户，但不属于同一帐户
按所属的用户、帐户和设备，各种帐单逻辑上挂接到相应的业务资料节点。在分表方面，将同时考虑逻辑上的严整和自然、性能的保证（如不造成实时任务的阻塞等待）、规模的可扩充性和管理方便性方面的权衡，具体遵循以下几个原则：
业务资料按用户id分表，这符合逻辑上从根到叶子的自然和严整，易于扩充，便于将大规模业务分成逻辑上的多个子业务，便于基于稳定的用户、帐户信息对设备的改号过户等变更进行灵活操作。在面对实时帐务从设备查找相关帐户和用户信息方面，可增加从设备到用户组的映射索引予以解决。
各种帐单用户id分表，分表逻辑与业务资料按用户id分表的分表逻辑一致
service bill同时根据如下因素分表：按实时和非实时、按service种类、按时间
优惠帐单同时按时间分表
任一级优惠帐单根据具体的优惠规则可有多种，具体体现为有各自的表名前缀（指去掉时间后缀后的剩余部分）。每一种帐单有各自的按时间分表逻辑。
原始费用表可进一步按是否实时进行分表，或不分表但需有hot accouting标志字段，对两种情况，在可操作性和性能方面本子系统均有相应考虑，具体在进度控制方面将采用原始记录标记法和处理记录表标记法。
☆其他公用服务
这部分提供其他一些公用的服务：
每一帐单均有帐单月这一属性，框架提供公用的帐单月计算函数从给定日期计算出帐单月。
原始费用表进度控制。由于原始费用表通常按时间分表，框架提供公用函数读取费用表的当前进度用于生成真正的表名，也提供公用函数修改费用表的当前进度。原始费用表按时间分表有以下几种情况：按年分表、按月分表、按天分表和不按时间分表。
总体结构
客户出帐管理
帐前核对
出帐前的核对包括按客户类别提供本月所有客户的统计报表，如正常使用状态的客户、欠费客户等；提供初入网用户和退网用户的报表与清单，以根据入网日期和退网日期核对月租费；提供纳入月帐单的各项费用，如入网分期费、手机分期费、过户费、改号费、停/开机费、业务增改费、附加业务使用费等；
一般情况下，出帐前的核对包括以下两部分：
系统数据完整性的检查，包括当前计费话单数据的完整性检查和客户资料数据的完整性检查等。
生成系统当前月各分类报表和统计报表，如正常使用状态的客户、欠费客户以及分期付款用户等；提供初入网用户和退网用户的报表与清单，以根据入网日期和退网日期核对月租费；提供纳入月帐单的各项费用，如入网分期费、手机分期费、过户费、改号费、停/开机费、业务增改费、附加业务使用费等。
在核对数据时，系统根据业务特点核定数据的完整性，并将不符合完整性的数据返回给操作员，在数据无误后，可生成各报表，从系统提供的报表的数据分析数据的准确性。为配合出帐的需要，可对部分客户数据进行核对，以提高系统的效率。
客户出帐
根据客户在户时选定的资费方案，即时或按月对所有的或个别客户进行正常出帐；
帐单费用包括月租费、频占费、各类资源使用费、业务功能费、各类营业受理费用、分期付款以及各类手续费等，并反映实际优惠的费用。
在出帐时，操作员选择出帐方式，并输入所需的信息，系统出帐完毕后，将出帐有关的信息返回给操作员。
出帐模式支持以下方式：
实时出帐：话单计费之后立即出帐；
周期出帐：以天的整数分割为周期出帐；
定时出帐：定日/定月出帐；
允许多个设备在同一帐户下出帐；
支持以下方式的合帐：
定日出帐方式的合帐：
周期出帐方式的合帐；
合帐周期内的按需合帐；
实时合帐；
错误处理
对本月由于各种原因没有统计的费用，可以在下个出帐月内统计；
如果本出帐月的合帐已经完成但费用有误，采用补差递减的方式在下一出帐月内对费用进行修改，以反映之间的差额；
对定日/定时方式，如果发生帐务错误，可以只对这一天内的话单重新出帐（不存在累计的因素），或者只对本出帐周期内后续的时间重新出帐，而不需要对整个出帐周期内所有数据全部重新出帐；
提供完备的事务处理机制，保证即使在在任何导致系统停止运行的故障情况（如数据库故障、掉电停机等）下均需确保数据的正确性，直观表现为帐单总是正确的，不会因系统故障引发多收费、重复收费、少收费等情况。
周期出帐设置
允许用户设置不同的出帐日（以月为周期）；
更改修改出帐日；
允许用户设置不同的出帐周期：系统根据上一次固定出帐点和相关配置（出帐方式，按月周期出帐时的出帐日和按定长周期出帐时的周期长度）计算下一次固定出帐点；
系统同时提供按需出帐接口。
系统提供相应的API接口，可以实现对第三方的帐单或是向第三方进行帐单的转发，完成帐单的统一。
帐单管理
帐单费用核对
帐单核对是指在客户出帐后，首先需核对纳入月帐单的各项费用是否正确，同时打印不同资费方案的客户的帐单，核对客户实际帐单和优惠额的准确性；若出帐有误，可调整后再次出帐或对某个客户群、客户、个人用户修正出帐。
在帐单核对的过程中，主要是随机抽取有代表性的各类用户进行帐单的各项费用的核对。系统提供帐户、信用的平衡检查、帐户资金平衡等功能。
帐单调整和管理
帐单调整是指在客户帐单费用核对完成后，可即时改变客户缴纳话费的付款方式和帐单类型(如现金改信用卡或现金改托收等)；可根据客户需要对帐单进行合并或拆分；对费用有误的帐单可进行对费用的逐项调整，同时打印具体的调整内容(包括月租费调整、频占费调整、各类通话费调整、业务功能费调整、各类营业受理费用调整、分期付款调整以及各类手续费调整)以供查询用。
帐单调整时，操作员选择所需调整的帐单，调整完之后进行保存，为保证系统的安全，系统对调整前的帐单进行备份保存。
帐单的管理涉及帐单的查询、打印、数据交换及帐单的变更情况查询等方面。系统提供按帐单类型、客户手机号码、IMSI号码、客户代码、客户名称、月付款类型和资费方案等方式进行查询、打印或输出数据文件与其它系统交换数据，帐单上的内容应包括月帐单的各项费用(如月租费、频占费、各类通话费、业务功能费、各类营业受理费用、分期付款以及各类手续费等)、所选资费方案与具体优惠内容、根据资费方案的优惠额以及其它信息(如感谢词或促销活动或提示客户修改资费方案等)，还可根据客户的要求在帐单后附上客户的详细通话记录；帐单可用单页打印或用连续纸打印；可用磁盘、光盘的方式储存客户帐单和话单信息，或以E-mail的方式为客户提供帐单和话单信息。
帐单格式帐单条目的可扩性
以科目形式记录帐单各条目，通过增加科目实现对帐单条目的扩充，采用纵向的帐单记录方式，一个帐户的帐单是由多条该用户的科目费用组成，每个科目对应该用户该科目的实际使用费用及相应的优惠。例，一个用户的实际帐单组成：
用户分户帐号
科目名称
科目费用
优惠积分
13905716155
频占费
5
0
13905716155
月租费
50
-8
13905716155
市话费
168
-18
13905716155
长话费
299
-19
13905716155
IP拨号
199
-20
帐单格式定制
生成包含优惠、调整、用户出帐前剩余预付话费、欠费、预付话费抵扣金额、本次应缴费用金额、各种代收费详细、本次帐单简短说明或用户通知等内容格式的帐单
帐单存储
支持以文件形式存储帐单数据，交于第三方代扣代缴
帐单调整
支持生成与要调整的费用项目相对应的调整单(补收或减收)，用户的实际应收变为帐单费用与调整单费用之和。
提供第三方帐单处理功能
提供发送帐单至第三方帐务系统的功能
帐单查询
可以查询原始帐单（帐单调整前）对应话单的详细信息，包括通话类型[主叫、被叫、呼转]、对端号码、起止时间、时长、话费、通话地点、话费类型等内容
可以支持不同通话类别查询。
帐单打印
打印未交费的帐单或在一定时间内的历史帐单。
核销管理
核销是指帐务处理部门在规定时间内对电信用户使用电信业务的应缴费用进行的收取、核算等一系列事务。核销的目的是对各项电信资费进行正确结算和及时回收，其主要内容包括出帐以后的收费/退费、网点结算、汇总稽核、银行托收、银行划帐、银行对帐、财务统计等所有与财务相关的事务。出帐后形成的帐单挂在各自的帐户下，经过前台收费后，将收银结帐的帐目整理、标识为已结帐目的过程称为销帐。销帐管理系统应完成的功能包括：
现金收费：用户以等额 的现金、现金支票、信用卡、电子记帐等方式结算对应帐户上的现金。
银行转帐或其他机构代收：定期由银行或其他金融机构转帐、划拨帐目实现结算，并打印兑帐单文件或电子文本。
销帐的定期整理与统计：定期将已销帐目整理到历史资料数据库中，并提供统计数字。判断剩余帐目是否为呆帐划归到呆帐处理子系统处理。
缴费管理
系统支持灵活多样的缴费方式，包括：
支持预存款/预存款+现金/支票等多种组合形式
支持多帐户、多个周期的帐单同时缴纳，以帐户为单位打印发票
支持只缴欠费帐单
支持只缴多条未缴帐单的其中部分帐单费用（以一条帐单为单位）
支持取整、圆整缴纳
支持计帐
另外，还可支持满足业务要求的灵活缴费处理：
支持将多缴的部分转为预存款
支持将帐单费用+滞纳金的零头结转
支持计算活期、定期利息
支持帐单明细和平衡
缴费管理，即对客户缴纳月帐单和实时帐单的管理，主要分为营业厅缴费和银行代收款缴费，缴话费时完成零头结转功能，对用户多缴费用在用户同意下可以不退且作为预存话费转入用户帐户，对话费部分打印发票，对预存部分打印收据。对缴费用户的发票和收据只提供一次机打机会，否则必须手开发票。所有业务都有备注记录项，具体含以下内容：
用户缴费
流失用户缴费
预缴话费（可收可退）
押金管理（可收可退）
用户撤单
退网缴费
银行代收话费
银行重缴费确认
补缴话费
用户缴费
把同一帐户编号下在该日允许缴费的所有已出帐的未结帐单进行集体销帐，滞纳金允许可调，对可调滞纳金或涉及到的结转零头只计入该笔业务涉及的其中一条帐单记录的滞纳金项。同时可以记录备注信息，对操作员是否具有可调滞纳金权限可通过操作员菜单权限来设定。在欠费停机用户缴费后可以进行开机处理。对存在拆机停机手机号的用户不允许结转零头。用户缴费可以满足多种付款方式（比若现金，信用卡，同城特约）。
流失用户缴费
指对被强制拆机销号的用户进行缴费，原理也同用户缴费。但不同的是对流失用户缴费时不用对用户进行开机处理但在该用户已缴清其所有手机号码的费用时须对用户进行黑名单取消处理。
预缴话费（可收可退）
用户预缴话费时显示用户名称，证件类别，证件号码，预缴话费和预缴话费销帐情况，上次结余情况，同时按一定方式缴费和收费。
押金管理（可收可退）
收取用户押金时显示用户名称，证件类别，证件号码，结余押金和收退押金明细情况。
用户撤单
对用户在本营业厅缴费帐单进行撤单。对用户撤单分二种情况，一种为对当天缴费的用户要求当天撤单，它既可以选择记录原有缴费信息在还原也可以选择所有缴费信息都还原到原来状态。另一种为隔天撤单的考虑到报表的一致性它必须记录原来的缴费信息。该用户撤单也可以对在银行缴费（也被默认为一个营业厅）且已返回缴费资料的帐单进行撤单。
退网缴费
退网缴费是指客户申请退出服务网络时的通话费用的结算及缴费功能，其特点是将客户的通话费用一次清算，缴费信息包括所有未缴月份的帐单和预存话费等；退网缴费必须在营业点办理，且必须是在冻结退网用户的号码以后。
银行（或邮储）代缴费
银行（或邮储）代收缴费可委托某一银行（或邮储）代收话费也可委托不同的银行代收话费，可采用Socket或CORBA机制通过双方约定的格式进行银行（或邮储）代收话费和实时销帐：
传给银行的格式：依据约定的格式和不同的代收话费的银行(在新装开户时让客户选择代收话费的银行)列明本月客户出帐的帐单明细，包括手机号码、客户代码、帐单类型、付款帐户、各项费用、欠费金额以及滞纳金等信息；
接收银行的缴费信息：依据约定的格式银行方列明当日客户在银行的缴费信息，包括手机号码、客户代码、缴费类型、缴费合计、缴费日期以及银行垫支款等信息；
欠费停机客户开机：依据约定的格式银行方列明欠费停机客户缴纳话费的信息，并实时传送给系统，内容包括手机号码、手机使用状态和总欠费额等，系统自动或人工为欠费停机用户进行开机处理；
银行垫支结算：若有银行垫支的情况，则每段时期内会有与银行结算垫支款的需求，两方出具各自统计的在某段时期内的未解决银行垫支款和已解决银行垫支款的信息供核对。
系统根据银行方传回的缴费信息自动进行处理，处理内容包括正常缴费、欠费补缴以及反销帐等，记录详细的缴费信息，内容包括缴费日期、缴费行、缴费月份、费用信息(包括月租费、频占费、各类通话费、业务功能费、各类营业受理费用、分期付款以及各类手续费等)、缴费金额、受理营业员工号姓名。
补缴话费
补缴话费是指实现客户缴纳当前缴费月以前话费的功能。对于拖欠多个月话费的客户，补缴话费必须从最早拖欠的月份开始补缴，否则系统不予处理；补缴话费时，客户按照其选定的月付款方式(如现金、同城特约以及信用卡等)进行缴费；对于补缴话费的记录，系统记录客户的补缴话费日期时间、缴费点、月付款方式、实际付款方式，受理营业员姓名、补缴月份、补缴话费信息(包括月租费、频占费、各类通话费、业务功能费、各类营业受理费用、分期付款、各类手续费以及滞纳金等)、补缴金额等。
销帐管理
销帐处理
用户的销帐过程如下：
可以键盘或条形码输入进行销帐。对托收客户、信用卡客户等实行自动销帐（批销帐），托收客户、信用卡客户或预约客户扣款不成功时可作反销帐。
销帐时如遇重复帐单，计算机给予提示，并且打印重复帐单的清单。
销帐时需输入组号、客户代码（或电话号码）、年月日、金额，系统自动累计总张数、总金额。每日销帐后打印销帐日明细表。
无论是销帐或反销帐，都有恢复原状态的功能,并要将曾作过的恢复动作作详细记录。
反销帐处理
对误收或错收用户的通话费用需作反销帐处理。
对于反销帐，有两种处理方式：
如果还在缴费周期内，则对于银行转帐失败的用户继续进行银行转帐，对于误收话费的客户则将以误缴话费的客户作反销帐处理，并将已缴的话费对实际客户进行冲帐。
如果已在缴费周期外，对银行转帐失败的用户作反销帐处理和欠费处理，对于误收话费的客户则将以误缴话费的客户作反销帐处理和欠费处理，并将作欠费处理的实际客户恢复到正常使用状态，用已缴的话费对实际客户进行冲帐。
反销帐处理需记录受理营业员工号、实际手机号码、误缴手机号码、月付款方式、销帐日期、冲消费用(包括月租费、频占费、各类通话费、业务功能费、各类营业受理费用、分期付款、各类手续费以及滞纳金等)以及反销帐原因等。
总的来说系统的反销帐处理可以恢复帐单未缴状态，回溯帐单的缴纳方式，返销缴纳的滞纳金，可按原销帐形式返销缴纳的现金或预存款；并可自定义返销形式。
业务退费
系统支持多种科目的费用退还
发票、收据打印
系统支持发票格式的定制，并可以记录发票打印次数。
代扣代缴接口
系统预留了代扣代缴的接口，从而保证系统具有充分利用系统外资源实现缴费处理的能力。
欠费管理模块
欠费管理模块是对未缴纳话费的客户的管理，主要的功能可概括如下：
月欠费用户确认
月欠费确认是指自系统出帐之日起，对在规定期限内未缴费的客户，在缴费周期的结束时作为欠费客户处理，其中缴费的依据来自于前台营业和银行等第三方的交换数据。
对客户的欠费催缴可形成欠费信息数据文件，通过自动催缴系统(如人工信息台或短消息或语音信箱等)提示客户，也可打印欠费催缴通知单邮寄给客户。
根据客户的类别对客户进行相应的欠费停机处理。
催缴欠费
对欠费客户反映客户欠费月份，每月所欠费用明细。
对当前欠费客户，产生欠费催交数据文件，提供给自动催交系统。并可选择打印欠费催交清单和欠费催交通知单。
对欠费到一定数额的客户，可进行停机处理，系统提供自动停机或根据需要人工控制停机功能，并自动生成滞纳金，停机费，产生停机客户清单。对客户可设定停机等级。可通过与交换机相连的数据链路进行停机操作。
可打印欠费客户清单，包括欠费的月份、电话、金额、户名、地址、联系电话、经办人、总户数、总金额等，要有根据客户欠费金额选择进行打印功能。
系统对欠费用户实现即时催缴话费，可采用语音催缴、电话催缴、发催缴单、上门催缴等多种方式，催缴欠费的处理功能如下：
按天（而非按出帐周期）计算欠费时间。
从欠费到采取催缴行动，可根据欠费的多少、所欠费用的种类及以往付费的情况设定催缴时间的长短。
为了便于将欠费资料转交给催缴机构，按客户的类别及欠费的多少，把客户分类。
系统将追踪每笔欠费在催缴过程中的进展，并统计每个阶段的任务及欠费的户数及金额。
对不同类别的客户可采取不同的催缴措施。
每种催缴措施都具备以下功能：
可根据情况对某客户产生多封催缴信；
催缴信的文字内容及每个催款步骤之间的间隔长短是可以改变的；
可设置催欠金额的上限与下限；
可以将某些客户暂时或永久性地排除在催缴处理之外，但必须在跟踪审计中标明；
系统可在帐单上打印一段催款文字，以代替催款信。
系统自动征收由限制通话、停机、电话催款或其它催缴措施引起的手续费。
系统对每天催欠的结果有记录。
欠费用户处理
电话通知或邮寄或传真书面通知单或以CHINANET网络通知，限在规定期限内缴款；
超过规定期限停去话并进一步电话通知用户限在停机期限内缴款；
超过停机期限，对用户进行停机处理并进一步电话通知用户缴款；
超过拆机期限，对该用户作销号处理并列入黑名单。
欠费客户查询和统计
可按帐单类型、客户手机号码、IMSI号码、客户代码、客户名称、月付款类型和资费方案等方式查询和打印欠费客户信息，欠费信息包括客户名称与联系地址、联系电话、欠费月份以及欠费明细和欠费总额等；可分类统计所有欠费用户的欠费费用。
有纠纷客户管理
系统对有纠纷的客户进行管理：
对长期欠费被销户的客户资料要进行保存，形成有纠纷客户资料。
有纠纷客户资料除记录客户信息外，还保留客户发生欠费的通话记录、欠费总金额等信息。
客户入网时，查询其是否为有纠纷客户，以防止类似情况发生。
坏帐、呆帐处理
对已停机、长时间欠费，而又不可能收回的话费，在业务主管部门批准的情况下，做呆帐处理。对此的处理，由于涉及到财务、单位的制度等各方面，具体的调整方式待定。
一般的处理方法是设置一个处理坏帐和呆帐的最大月份，在这个月份之外的无法收回的长期欠费可打印统计报表，内容包括手机号码、客户姓名、联系地址和邮编、联系电话、欠费起始月份、欠费金额、欠费费用分析(即对各类通话费用进行统计)，报财务和主管部门审核，正式确认后对该手机号码的帐单进行销帐处理，同时记录审核部门的详细信息。
呆帐的判断
对长期未付请的帐单，根据约定的期限（移动局自定写如系统配置文件中），由定时启动的系统程序查询，标识相应的帐目为呆帐。对后来缴清帐单的帐目，系统自动更改呆帐标记。呆帐不计入日常的帐务统计内容中。对于统计出的呆帐的处理目前尚需人为判断。
呆帐处理
对于计算出的帐单，原则上用户均能将费用付清。但是，实际中部分帐单无法付清。产生呆帐的原因有多种，如由于错误帐户信息、错误设备信息的录入以及入网信息未能及时录入数据库等原因产生无主帐单，无主话单。又如某些客户长期拖欠帐目等。这些帐目称为呆帐。对于呆帐，应将其从普通帐务中划分出来，以进行查询、统计和打印。
呆帐的查询与统计
查询并统计指定范围内的呆帐的数量、金额及详单，并分别形成文件，打印统计结果。其实现与不同的帐单的查询与统计雷同。
无主户的管理
理论上经过合帐后，话单应都被标记。但实际上，经过一定时间仍有部分话单未被标识。这些以IMSI码或MIN码为索引的话单在转换中无法找到相应的设备号（手机号），即产生了无法收取费用的统计结果，称为“无主话单”。
无主话单产生的原因有如下几种可能：
操作员对手机或SIM卡的测试话单；
操作程序的延误导致手机开机后未能将客户的信息插入到客户信息库中；
操作员的失误导致设备号码与IMSI/MIN码的对应关系错误；
操作员的欺诈行为，如非法出售手机或SIM卡；
经过系统定期的监测，将无主话单分拣整理到专门的信息库中，并打印统计结果。
对无主话单的处理
根据计费号统计无主户的帐务，打印帐单明细。并列入呆帐数据库中，以备分析处理。对于设备信息错误等造成的纠正信息后或补入资料后自动转成正常用户处理。对于长期无主的话单进行停机处理。
对无主帐单的处理
根据帐单的出帐最大周期限制查询帐务内容，标记呆帐标识。定期统计送入呆帐数据库中，以备分析处理。对于帐务信息错误等造成的纠正信息，转入帐务催缴系统处理。
记录无主户每月新产生的各项费用、首次通话时间。
可进行无主户清除和费用调整处理。
每月开帐前可进行无主户转为合法客户的费用导入，并根据其具体开通日期，自动补收月租费。
对连续几月出现的无主户或未转为合法客户却消失的无主户，能够提供详细话单。
帐务级优惠与资费管理
系统中提供多种优惠方式供运营商选择合适的资费优惠方案，系统提供的主要优惠方式包括：
按通话总时长优惠
按特通话时间优惠
按特定用户类别优惠
按特定付款方式优惠
按特定使用功能优惠
按用户入网时间优惠
按累计积分优惠
业务受理费用优惠
不同业务使用的交叉优惠
进行优惠的方式可以是通话次数，通话时长，话费金额或累计积分。系统中控制优惠的主要手段是优惠资费套餐，优惠资费套餐由开户资费包，使用资费包，月话费基本资费包，话费资费包构成。
开户资费包：主要是对开户时所需应收取的费用和允许优惠费用进行定义，同时允许定义手机或入网费的分期付款规则。如定义以下内容：
开户资费包代码 开户资费包名称 入网费分期付款次数 入网费分期付款费手机费分期付款次数 手机费分期付款费 选择该资费包要求收取的各项费用，定义超过某一阀值的费用允许选择的优惠方式和优惠金额等。
使用资费包：主要是对手机用户的一些特殊费用在每次帐单中的收取方式进行定义，比如对基本费（或租金），频占费，功能使用费等的收取方式进行定义，比如定义在开户多少天后才开始收基本费，频占费，功能使用费，是按日，按月，按年还是按间距来收费。
话费资费包：主要是在用户出帐时对用户实际发生的各项费用定义批价的实际应收比率，若对话费费用项不定义收取比率则指全额收取，若定义了比率，对不收取费用的部分则算优惠费用。比如在出帐时定义基本费（或租金）的收取比率，频占费的收取比率，通话费的收取比率，国内漫游费的收取比率，国际漫游费的收取比率等。另外对只准月出帐的用户还可以定义分包月制。分包月制对优惠部分都算相应费用优惠。
开户资费方案维护
开户资费方案维护是指对在新装开户时客户所缴纳的一次性费用进行定义，费用包括入网费(可提供分期付款)、手机费(可提供分期付款)、频占费(可根据入网日期定义不同的频占费)、选号费、SIM卡费、预存话费、预存押金和开户手续费等。开户资费方案可以预先设置，在新增优惠资费方案时可选择使用。
业务方案维护
业务方案维护是指定义不同的业务使用方案供客户选择使用，业务内容包括附加业务、承载业务和增值业务，同时定义所使用的业务方案的开通费和月使用费。业务方案可以预先设置，在新增优惠资费方案时可选择使用。
下表所示的是常用的附加业务、承载业务和增值业务：
附加业务编码
附加业务类型
11
主叫号码显示
12
主叫号码显示限制
13
显示中继线
14
不显示中继线
20
所有的呼叫限制
21
无条件呼转
28
所有的有条件呼转
29
用户忙呼转
2A
无应答呼转
2B
不在覆盖区时转移
31
呼叫传送
41
呼叫等待
42
呼叫保持
43
至忙用户呼叫完成
51
多方会议
61
闭合用户群
71
计费提示（计费）
72
计费提示（信息）
81
用户间发信号
90
所有的呼叫限制
91
所有的呼出呼叫业务限制
92
呼出呼叫限制
93
国际呼出限制
94
国际呼出（除家区）限制
99
所有呼入业务限制
9A
呼入限制
9B
漫游时限制所有呼入
月通话方案维护
月通话资费方案维护是指对在月出帐时根据客户的通话类别作出的通话费用和基本费用的优惠，费用包括月租费、频占费、基本通话费、市内长途费、国内长途费、港澳台长途费、国际长途费、国内漫游费和国际漫游费等，并区分拨打邮电用户和联通用户，区分主被叫。月通话资费方案可以预先设置，在新增优惠资费方案时可选择使用。
优惠资费方案维护
在优惠资费方案维护中，新增优惠资费方案需定义优惠资费方案的名称、使用起始日期和终止日期、月通话资费方案使用的有效期限和后续月通话资费方案、可使用的操作权限级别以及已预先定义的开户资费方案、业务方案和月通话资费方案，完成上属内容的定义后，就可在新装开户的功能中供客户选择所需的优惠资费方案；在此功能中也可删除已过终止日期的优惠资费方案。
优惠资费方案查询
优惠资费方案查询是供管理员查询或统计优惠资费方案的数量和详细内容，查询或统计在某一段时期内使用各类优惠资费方案的客户数，供决策分析用。
实时限额
实时费用累计
本模块完成对用户实时使用限额的信用控制，考虑到系统的性能和数据准确性和安全性的平衡。采用实时进行内存汇总，定期进行数据库汇总的方式进行。在的共享内存中进行用户详单费用的实时累计时暂不考虑其帐务级的优惠处理，当完成数据的定期汇总后重新装载内存中的汇总数据，其重新装载的时间最大不超过15分钟。本模块需要常驻内存并需要进行并发处理。结构如下图所示。
软件结构图
说明：
图中的ABCDEF分别是本模块几种相关处理
定时帐单汇总：定时生成详单的费用汇总数据并成批更新数据库中表的数据，一般是按天生成，生成完成后将费用汇总数据重新装载内存中。表中的数据将会被出帐处理作为中间结果使用。
实时费用累计：实时更新共享内存中的费用累计数据，同时用更新后的累计费用额与限额（此处的限额为月限额，基于简化结构的原因对日限额的处理暂不考虑）和信用额按照帐单总额＋实时费用累计<＝可使用余额＋月限额的关系进行比较，如不满足条件，则将该记录加入到F所处理的队列中。
实时费用查询：查询内存中的实时费用累计额，目前只支持基于主计费号作为查询的条件。对于用户查询实时帐单费用的情况，根据boss规范的规定，除了查出实时费用累计额外，还需要查出截至到查询时间前一天的周期费用额和第三方合帐的费用。
限额更新：由于用户所享有的限额会被销帐，缴费和业务变更的过程所修改，因此，所有涉及更新帐单总额、可是使用限额和月限额的操作都应更改数据库和内存中的数据。该接口以corba和动态库的形式提供给业务模块使用，在进行了更新后需要根据B处理中的逻辑式判断后对不满足条件的记录加入到F处理的队列中。
汇总数据清理：出帐后需要对数据库中实时累计汇总数据进行清理，处理逻辑为。帐单总额＋＝新增帐单总额，实时汇总额－＝帐单总额。
超限数据处理：将超限的数据加入超限处理的队列，具体的超限处理根据信用度模型进行判断后异步进行。
I和II分别是内存和数据库中存储的数据，III是帐务部分使用的日志及进度控制表，请参考帐务部分的定义。
数据结构
对图中I和II的数据给出说明。
标识符
类型
有效范围
描述
I．内存数据结构
Bill_Id
String
无
主计费号，对于无线业务来说，为IMSI号
Account_ID
Longlong
无
帐户代码，如不考虑基于帐户级别的服务控制，可暂时不要
Service_id
Long
参考服务定义表
服务代码，如不考虑单独控制一个计费号上的各种服务，可暂不考虑
Account_code
Long
参考科目定义
科目代码，如不考虑基于科目的服务控制，可暂不考虑
Bill_total
Long long
帐单总额
Realtime_total
Long Long
实时费用累计，以分为单位记录
Balance
Long long
可用余额
Month_Quota
Long Long
使用限额
II．费用汇总表
Bill_ID
Varchar2(64)
无
主计费号
Account_ID
Number(10)
无
帐户代码，如不考虑基于帐户级别的服务控制，可暂时不要
Service_id
Number(5)
参考服务定义表
服务代码，如不考虑单独控制一个计费号上的各种服务，可暂不考虑
Account_code
Number(5)
参考科目定义
科目代码，如不考虑基于科目的服务控制，可暂不考虑
Bill_total
Long long
帐单总额
Realtime_total
Number(12)
实时费用累计，以分为单位记录
Balance
Long long
可用余额
Month_quota
Number(12)
使用限额
帐务稽核
销帐流程
帐务稽核是对销帐过程中费用的审核，也就是对应收费用与实收费用之间关系的审核。从宏观上分析，销帐可以分为以下几个过程：
接收：即获取费用的过程，它因缴费方式的不同而不同。例如，在营业厅，营业员通过用户缴纳现金获取费用；对于托收方式，营帐系统通过与银行的接口获取费用；
标记：即传统意义的销帐过程。通常营帐系统在用户应缴费的帐单上做标记，以标识是否已经缴纳费用，同时在业务受理表中记录这一比业务；
发送：即讲营业系统缴纳的所有费用转交给财务系统的过程。同样，它会因接受方式的不同而不同，例如营业厅组长讲现金缴至财务相关人员，财务人员在财务系统中做确认；或者，通过与银行之间的接口做资金的转帐；
虽然从程序的设计上讲，每个环节都是正确的，但由于操作员失误、系统的意外故障、系统之间的不同步等原因，都可能会导致数据的不一致。
我们的帐务稽核就是基于以上考虑而设计的。
下图描述了营帐系统中与帐务稽核相关各个环节的数据。
其中：
A：前欠是在缴费周期结束后，用户应当缴纳但未及时缴纳的费用；
B：应收是系统按照用户对网络、服务的使用情况，而向用户收取的费用；
C：实收缴费是用户通过不同方式缴纳其费用的状况，其中包括预存缴费；
D：实收预存是用户方便缴费和服务的限制，而预存在系统中的费用；
稽核功能
在稽核过程中，我们以核对实收的一致性为主要目标。事实上，实收可以从两个途径分别计算；
基于营帐系统本身：从营帐系统的业务受理表中统计出所有与费用相关的记录，包括缴费、退费、预存、业务受理费用收取等；
基于财务系统：从财务系统同样可以统计出每阶段（日、月）的实收，这些实收的途径包括：营业厅、银行转帐、支票等；
我们的稽核就是要检查从两个不同途径计算结果之间的一致性。
在这其中，需要注意：一些非同步的操作因存在时间上的差异，也可能会导致结果的不一致。例如托收方式，在接受到托收文件后，营帐系统立即进行销帐，并算为实收；但银行之间的转帐要延迟一段时间；
按照不同的要求，我们的营帐系统还支持其它分类细化的核对，这包括：
基于时间段的核对，包括日、月、季、年；
支持周期的核对与累计的核对。如果是累计核对，则必须指定一个起始点，而且该电必须是财务周期的起始点；
基于不同地区的核对；
基于不同缴费方式的核对，包括托收、代收、支票、网上支付（如果系统支持）、营业厅缴费；
按照预存和非预存核对；
帐务结算
按照BOSS规范的要求，营帐系统中需要考虑与以下实体之间的结算：
银行（和邮储）：与银行的结算又分为托收结算与代收结算，运营商要根据业务量的不同付给银行一定的费用；
邮政：与邮政的结算只在运营商通过邮政的营业厅办理业务时发生，运营商要根据业务量的不同付给邮政一定的费用；
第三方帐务系统：例如运营商为信息台代理缴费业务，第三方帐务系统需要更具业务的不同支付运营商费用；
与代销商之间的结算：代销商为运营商发展用户，并办理业务。运营商要根据业务量的不同付给邮政一定的费用；
与银行（邮储）之间的结算
结算数据
托收方式：银行与营帐系统间交互的文件，一般包括托收文件和回执文件；
代收方式：营帐系统中的销帐记录。该数据直接从数据库中获取；
结算方式
支持对不同银行不同的比率；
支持按照总次数（销帐记录数）的结算；
支持按照总费用的结算；
对托收和代收不同的结算原则；
与邮政之间的计算
结算数据：
营帐系统业务受理记录中通过邮政受理的记录，直接从数据库中获取。
结算方式
按照不同的业务类型（例如开户、销户、缴费）结算；
按照业务受理产生的费用结算；
与第三方帐务之间的计算
结算数据：
第三方营帐系统发送的文件，以及营帐系统的反馈文件；
结算方式
按照次数结算；
按照费用进行结算；
按照不同的结算方，定义不同的结算规则；
与代销商之间的计算
结算数据：
营帐系统业务受理表中所有与代销商相关的数据。
结算原则
针对不同的代销商类别制订不同的结算原则；
根据代销商发展的用户数；
代销商所作的业务数（不同的业务不同的结算原则）；
根据代销商发展用户的情况进行进行结算：
用户发生费用情况；
用户缴费情况；
用户欠费情况；
综合营业管理模块
综合营业是系统与操作员和最终客户的接口。操作员通过综合营业子系统进行业务管理和响应客户的业务请求；客户通过综合营业业务功能实现定购和缴费。
AICBS的综合营业管理系统采用三层体系结构设计，提供了Windows 和WEB自助服务两种界面，其主要功能模块包括：包括开户管理、定购管理、业务变更、大客户管理、查询管理、缴费管理、资源管理、资费管理、信用管理、系统管理等几部分。
开户管理：开户即为客户建立用户、帐户、设备档案以及针对用户的要求进行产品或计划的定购的过程。开户管理支持批量开户、预开户、同一客户重复定购同一产品或多个产品、受理回退、预开户、日志记录、黑名单检查等。
定购管理：定购就是根据客户的选择，将相应的产品或计划信息记录到该客户对应的用户下的过程。对于未产生费用的定购可以进行取消定购操作。
业务变更：业务变更包括过户、分户、合户、销户及对客户定购的产品或计划中某个服务的特征进行是否需要或特征值的改变，也包括用户资料及帐户资料的更改。业务变更支持批量销户、服务批量停开、服务实时停开、受理回退、支持帐户平衡检查、操作轨迹记录、用户历史资料记录、日志记录等；
大客户管理：大客户、客户群的支持，是一种市场发展的需要。大客户管理主要对大客户的资料进行统一的维护。
储值卡用户管理：系统支持对移动智能网用户的入网、智能网卡的销售等。系统同时支持对预存卡用户、予付费卡用户的管理，提供对预存卡用户、予付费卡用户的话费的充值、触发服务开通等功能。
黑名单管理：系统提供的黑名单管理支持对外来黑名单用户资料的接收，转换为系统所能识别，查询、稽核的黑名单列表，对于系统内长期欠费的用户根据预先设定的黑名单用户标准进行用户黑名单处理，对于一个身份证多次入网的用户进行黑名单登记，提示操作员是否允许该用户继续入网或是业务、用户资料更改等。
查询管理：系统提供了丰富的查询方法，支持客户资料、客户帐单、客户详单、用户欠费、用户资费情况、用户缴费情况、用户历史资料等的查询。
资源管理：管理系统中所有涉及到的资源，包括实在的资源，例如手机、SIM卡、代销商；也包括虚拟的资源，例如号码段、价格等；
资费管理：AICBS引入全新的服务、产品、计划及促销的概念。其中服务定义为系统所能提供给最终客户的可以使用的业务单位；产品定义为服务加上相应的定价及优惠，是提供给用户的直接使用的单位；计划定义为多个产品的组合，同时追加相应的优惠策略；促销就是从有效时间、适应的客户群等方面，对计划、产品的定购进行规定。资费管理就是对产品、计划及促销的管理，也就是对服务的价格及消费范围和时间进行管理。
信用管理：系统为了更好的控制用户使用网络资源，采用了信用度控制来对全网用户进行管理，将用户的历次缴费情况通过一定的算法折算成用户的信用积分，根据预先设定的不同信用等级的阀值来确定用户的信用度等级。它管理所有与信用相关的信息，包括根据用户的一些属性（类别、消费积分等）进行初始信用度的设置、设定信用度积分升降的标准、不同信用度对应的处理等；同时系统提供手工/自动两种方式进行用户信用度的调整。
系统管理：为了便于对整个系统的管理，AICBS引入行政域、节点、角色、操作员、操作员组的概念，系统管理主要负责对以上概念的内容进行管理；
客户管理系统主要是围绕客户信息进行处理，由于电信运营商的客户数目非常庞大，所以为了提高系统性能，AICBS客户管理系统对客户信息的存储是按一定规则分库分表存储的。分库分表技术的灵活采用既提高了系统运行的效率，又提高了系统的灵活性，便于系统扩充。另外客户管理系统的三层体系结构，使客户管理系统的界面是可以灵活定制，从而可以满足运营商的不同使用方式。
综合业务系统的特点
用户数高速增长
在系统中需要存储大量的用户信息数据以及相应的用户的帐务数据，而且对数据的存取粒度要求需要到明细话单一级。
数据的特殊性
综合业务系统存储的均是用户的个人隐私信息。
服务性
移动电信业从垄断行业转换为服务行业后，哪家企业的服务好就会赢得更多的用户。只有通过更强大的服务功能才能吸引用户。
业务变化多
移动通信的业务已从单纯的通话服务，扩展到了数据传输，语音信箱，三方通话等，而且，将来业务的服务数量，服务方式，费用的计算方式也将越来越多。
营业系统的总体设计思想
亚信AICBS系统的设计宗旨是：对外提供优质的服务，对内加强优质的管理。优质服务体现在，系统的实时响应速度要快，系统的数据资料要准确，系统要灵活适应业务的发展，系统要提供灵活的优惠方式及出帐方式。对内加强优质的管理体现在系统的资料的特殊性决定了对系统的安全性要求要高，对系统的使用记录要有完善的监督功能。因此整个系统的设计遵循以下的思想：
准确性
营业子系统直接面对用户，系统运行的正确与否直接影响用户的直接利益及公司运营商的形象，所以准确性是系统设计的基础。
灵活性
软件系统要满足最大程度的灵活性。包括对业务扩展的灵活性，计费的灵活性。由于整个系统是采用的面向对象的设计思想，并采用了多层体系结构，对中间层的业务对象可以灵活地装载、卸下、替换、更新及进行二次开发以适应变化的业务功能。中间层的使用保证了系统在不同的软硬件平台上均具有良好的伸缩性和移植性。
可扩展性
移动通信用户的高速增长，其用户信息的增长是非常之快的，客观要求整个系统具有可扩展性。硬件上可以增强单机性能，也可以增加系统的结点数，软件上的各个子系统一定要能适应这种扩展。多层体系结构的动态均衡负载，异构数据库支持及分布应用的能力保证了用户业务增长时系统的平滑无缝升级。
高可靠性，高安全性
本系统的特殊性决定了可靠应作为系统设计的出发点。除了数据传输要可靠外，系统必须具备良好的备份机制，重要数据一定要备份。系统应有效地防止非法用户的入侵，保护系统数据。系统发生的各种事件记录在数据库及日志文件中，以备系统恢复用。
实时性
从业务受理到出帐、缴费、开关机全过程的实时服务，使用户享受到更加方便及时的服务，使营运商更加快捷、细致的了解实际运营情况。
易用性
Client端的操作采用Windows和Web界面相结合的模式，操作更加方便。减少系统的使用成本。
营业系统的总体架构
客户管理层次结构
综合营业子系统的核心功能是维护客户记录，管理与客户相关的业务信息。系统采用了层次化的客户结构，如图所示。
其中，最高的两层分别为商业集团与子公司，子公司与客户通过合同相互联系，规定相互之间的权利与义务，同时合同也是运营商对客户进行计费，出账，收缴费用的法律依据。每个子公司管理具体的客户，下属的合同用户的数量十分巨大。每个合同又可以包含各种类型的业务定购。对于团体客户来说，它与服务供应商之间的合同可能包含了客户团体所属不同个人用户的各种业务定购；而对于纯粹的个人用户而言，他（她）与供应商之间的合同很可能仅包含了个人的有限的业务定购。
为了提供出帐日期和多业务账单样式的灵活性，出帐和账单样式以与业务定购相关的基本费用为单位进行。在一个融合的计费系统中可以存在多种不同的基本费用，这些基本费用使用不同的名称区分并且可以由运营商定义，出帐系统和账单样式不必考虑这些业务的细节（由底层的计费模块实现，向上提供统一形式的帐务记录），只要根据用户的需要定制出帐时间以及在账单样式中引用这些基本费用即可。
营业系统的系统架构
AICBS综合业务系统模块间的结构关系如下图所示：
本系统中的主要模块包括：资源管理，业务处理s，查询统计，优惠资费管理，用户资料管理，系统参数管理。其中用户资料管理（帐户资料），系统参数管理（帐户部分的参数）与帐务系统的数据有关。
综合营业子系统采用分布式多层体系结构设计，整个系统的设计以对象为基础，通过指定的输入输出接口在网络上提供对象服务，当系统要增加新的业务功能时，由于原有的服务对象可以复用，大大减轻了系统开发代码的重复缺点。
系统提供了Windows 和WEB两种界面。
网上营业的实现
主要构成
亚信AICBS采用基于CORBA的中间件技术，并采用C++与JAVA语言进行系统开发，WEB模块主要采用JAVA作为开发工具，构建JAVA组件JAVABEAN来实现WEB对数据库核心应用的接入，因此无论对WIN或者WEB接入模式，我们的业务应用服务器都是一个。从而进一步降低了系统开发难度，提高了系统的可维护性和灵活性。
WEB界面由四层体系（用户Browse、WEB Server 、Application Server和 DB）构成，如下图：
第一层为客户机，可支持任意浏览器，可由PC、NC或工作站实现，静态界面由HTML实现，动态界面接口由SERVLET完成，由应用服务器处理客户端的所有应用需求。
第二层为WEB Server，可支持任意浏览器，可由PC、NC或工作站实现。
第三层为应用程序服务器，由多个组件组成。我们的应用逻辑将由此实现，包括用户登录验证、开户、用户帐单查询和详单查询等等。
第四层为数据仓库，该层定义、维护、访问和更新数据，并管理和满足业务对数据的请求。
安全问题
一般情况下，对WEB的攻击主要有三种手段：
盗窃或馔改数据，直接盗用服务器更改有效数据；
恶意的程序代码，恶意程序由WEB侵入系统破坏数据；
窃听，拦截系统登录信息或有效数据；
因此，我们从以下方面实现WEB安全：
网络安全
该界面由防火墙实现第一层网络安全保护，限制所有TELNET、FTP等权限。
WEB SERVER 安全
第二层的WEB安全由WEB SERVER提供，具体由如下机制实现
基本身份验证
该机制要求进入系统的用户必须输入用户名和口令，只有通过访问控制检查，才能访问某个主页和相关资源。这种基于身份验证的访问控制与物理上及操作系统紧密配合，有效防止与控制盗窃或馔改数据等直接攻击。
数字鉴定
采用数字方式传输用户信息。
SSL服务器身份验证、SSL隐私保护
在网络环境下，一种能确认当前给他们发送数据的服务器就是他们所要求的服务器的机制，HTTPS URL可使用户知道服务器身份。同时HTTPS协议使所有服务器与客户间传送的数据都是经过加密的，如果窃听者无密钥，即使得到这些数据也无法得到原有效信息。
用户和用户组领域管理
将系统的许多的用户，划分为相应的用户组、领域，控制相应的权限，从而简化系统管理，减少系统安全漏洞。
访问控制列表管理
访问控制列表描述了用户访问服务器资源的具体信息：
每个用户都有各自帐号、口令和相应目录权限
用户可分配到不同组中
各用户组分别有不同的权限
用户、用户组的作用范围是一个Realm，不同的Realm中的两个用户即使同名也不会相互发生冲突。
沙盒保护
采用SEVRLET实现的应用程序服务器，具有严谨的JAVA的安全机制，使我们的应用实现在沙盒之中，恶意的程序代码攻击不能对沙盒之外的数据产生破坏，有效保正了系统资源和DB的安全。
沙盒模型：
另外界面的四层体系结构的实现方式，使得WEB Server并不直接与数据库相连，也充分保障了数据库端的数据安全。
业务管理功能说明
客户新装功能
客户新装功能的具体业务如下所列：
客户新装
客户改名
客户过户
更改客户信息
更改资费组合方案
换号
停/开机
退网拆户
挂失/补发
换机
租机
客户新装功能特点
优良的用户身份和手机合法性校验机制
在开户时可以对用户是否内部黑名单用户，外来黑名单用户，多手机用户进行身份鉴别，对手机的合法性也可以进行校验，包括检查黑身份证号码、黑银行帐户号，并可根据规定受理或拒绝受理。从而可以有效的控制各种恶意行为。
方便灵活的用户资料分级管理机制
系统允许一个多手机用户建立多个付款帐户，一个付款帐户又为多部手机服务的付款机制。并且一个多手机用户可以包括一个或多个多手机用户，并可根据用户要求确定出帐级别。
可定制的业务流程
系统对客户新装业务中的受理，收银和发机既可以采用”一席清”一次性完成，也可以设置成分台处理。
支持多种网络，多种业务，多种受理方式
业务管理中针对客户的不同需要，按网络制式(GSM/TACS)对客户进行分类。可以受理的业务类型有：全球通、本地通、本省通、租机、租号、分期付款、公务机、测试机等，另有其它套餐业务，在某些业务类型可有其子类（如不同的分期付款期限）。支持多种营业受理方式（代销商，营业厅，传真电话，协议录入）。支持单一客户开户多部手机的功能。
实时的高效HLR接口
客户新装可以做到“即买即通”。可以在入网时，预置相应默认的业务功能，可根据业务规定不同的用户业务类型，允许或禁止用户同时选取修改某些业务功能。综合营业子系统提供高效实时的接口与江西联通现有的实时停开机系统联接，实现用户的实时业务开关功能。
灵活多样的优惠方式
业务受理时不但可以使用优惠资费套餐优惠，可以支持新装时的即时优惠，并可记录优惠原因、设置优惠权限。
客户新装业务说明
业务定义
客户新装指新装客户用新的合同号（客户编号）开户，该客户编号由系统自动生成。客户新装需输入操作员资料、客户本身资料、客户账务资料、手机的相关资料。新装受理结束后，系统自动打印发票以及产生受理回执交用户留存。
业务流程
典型的客户新装的业务流程如下图所示：
功能描述
操作人员需输入以下几组资料：
操作员资料：包括用户编号、受理日期、受理人、登录工号
用户本身资料：包括用户类别、用户信用度、用户名称、证件类别和号码、联系地址和邮编、联系电话、用户查询密码，个人用户的初始信用度等级一般为最低一级
用户账务资料：包括购机付款方式(现金、支票和信用卡的组合)、月付款方式(现金、支票、预存话费、信用卡和同城特约)、开户银行、银行帐号、帐户地址和邮编以及联系电话、优惠套餐、出帐周期及方式、发票号码等
手机的相关资料：手机的开通日期、手机号码、手机型号、手机机身号、SIM卡号、附加业务、承载业务、增值业务和手机使用证号等资料操作人员需进行以下的选择：用户类别：分为普通用户、公免公纳用户、重要用户三类，操作员进行选择后，窗口会进行一些变化：★选择公免公纳用户及重要用户后，系统会考核操作员有无此权限，当操作员有权处理公免公纳用户时，系统会将各种费用均设定为可以修改。反之，则会提示操作人员无此权限。
用户性质：分为个人用户及集团用户两种情况。★如为集团用户，系统会自动生成一个用户编号，如果该集团用户已有开通的手机，输入用户编号后系统会显示出相关的用户资料，并显示出该集团用户的已开户手机数量及今次已经开户的手机数量。
资料录入有两种基本方式，远程登录的方式进行新装受理和代理商将相关资料交给营业厅，由操作人员录入用户资料。
新装受理结束后，系统可根据用户要求产生受理回执(包括购机入网用户的保修卡)或发票交用户留存，同时系统记录资料录入的方式。
当用户为集团用户时，用户可以在同一用户编号下开多台手机，并用同一帐号交费。公免公纳用户的新装受理可根据需要选择不同的资费套餐决定计算费用还是不计开户费用，并要用户出具成为公免公纳用户的证明，并打印或不打印发票。
重要用户的新装受理，由具有相应操作权限的管理人员，根据用户出具的证明对该用户开户申装的各项费用进行优惠处理，并在优惠处理后保留操作员信息和优惠原因。
客户改名
业务定义
用户改变名称，不改变使用权的称为“改名”，客户改名不更改手机所有者
业务流程
填业务申请登记卡
营业员核对用户旧资料
营业员录入用户新资料
计算费用
用户缴费
打印申请登记卡、发票、受理回执
功能描述
输入客户的手机号或用户编号，系统会显示客户资料：
客户本身资料：包括客户类别、客户名称、证件类别和号码、联系地址和邮编、联系电话、客户查询密码。
根据需要可对上述内容进行修改(一般系统只修改用户姓名和联系名址信息),处理完毕后打印改名费发票。
客户过户
业务定义
客户过户更改手机的所有权 (付款人)，即更改手机所对应的客户编号或客户付款帐号。在过户之前，须结清原客户的一切费用或声明由接受过户的客户承担。
业务流程
同”改名”流程
功能描述
输入客户的手机号或客户编号系统会调出与此手机相关的资料供修改之用，具体资料包括：
客户本身资料：包括客户的类别、信用度、名称、证件类别和号码、联系地址和邮编、联系电话、客户查询密码。
客户账务资料：包括购机付款方式、月付款方式、开户银行、银行帐号、帐户地址和邮编以及联系电话、优惠套餐、出帐周期及方式、发票号码等
手机的相关资料：手机的开通日期、手机号码、手机型号、手机机身号、SIM卡号、附加业务、承载业务、增值业务和手机使用证号等资料。
根据需要，对上述资料进行修改，确认后，系统会将老的客户资料存入客户历史资料，由于已过户，客户的信用度等级重新被置成较低级别，并打印过户费发票业务回执等。
更改客户信息
业务定义
更改除客户名称外的客户信息
业务流程
填业务申请登记卡
营业员核对用户旧资料
营业员录入用户新资料
打印申请登记卡、受理回执
业务说明
用户出示合法证明下对用户的资料进行修改或更换月付款信息，即既可更改所有权用户资料和新建用户的内部帐户编号又可只修改该帐户编号下的部分信息。
用户资料修改说明如下：
1、用户在存在未结帐单时不予修改资料。
2、提供修改用户名称，用户证件类别和证件号码、用户联系地址和邮政编码、联系人姓名、联系人证件类别和证件号码以及联系电话等用户信息。
3、此项业务可以完成单手机用户帐户，也可完成多手机用户全部手机的帐户修改和部分手机的帐户转移及修改。
4、在预以修改为新帐户的手机列表的手机的帐户应全部替换为新帐户的帐户编号，同时新建或修改帐户信息。
5、原帐户若还有需付款的终端则不予删除。
6、原用户信息记录于历史资料表中，以便查询历史信息。
7、具有一定权限的操作员可对用户实行费用优惠，并在备注中记录优惠信息。
更改资费组合方案
业务定义
用户申请变更套餐类型。
业务流程
填业务申请登记卡，选某种套餐类型业务
营业员检查是否附和允许变更规定。
营业员修改用户套餐类型
营业员录入该种套餐业务所要求的用户资料
计算费用
用户缴费
打印发票、受理回执
向HLR/MSC接口派工单变更有关业务功能
功能描述
受理用户更改资费方案，输入用户的手机号或用户编号，系统显示下述资料：
1、用户本身资料：包括用户类别、用户名称、证件类别和号码、联系地址和邮编、联系电话。
2、用户账务资料：用户当前通话资费方案。
3、手机的相关资料：手机的开通日期、手机号码
根据用户要求，选择新的通话资费方案，收取用户更改通话资费费，并打印发票。
更改资费组合方案应满足如下的限制：
1、只允许在原类型套餐所用的网内（指模拟网或数字网）变更。
2、一般只允许用户从较低收费的套餐类型改换到较高收费的套餐类型。
3、在允许用户从较高收费的套餐改换到较低收费的套餐时，用户应在开户时规定的使用期后，才允许申请改动其套餐类型。
4、用户新的套餐类型在下月生效。
5、套餐业务一般有其固定的业务功能和服务，用户无需人工再选择取舍，由系统自动完成。
换号
业务定义
用户的名称和电话使用权均不改变，只改变移动电话号码的称为“改号”。
业务流程
营业员核对用户有关证明资料
用户在屏幕直接选号
计算费用
用户缴费
打印申请登记卡、发票、受理回执
模拟手机编程
向HLR/MSC接口派工单
功能描述
用户换号不改变用户资料和任何业务功能。旧号进入冷号状态。规定的冷号期结束后，可重新调配使用。系统记录旧号与该用户的对应关系，以备旧号码未结费用下帐。
停/开机
业务定义
受理用户停机或开机的业务申请，可实时或延后停开机。用户停机后，须经用户再次申请并结清相关费用后，才能开机。
业务流程
营业员核对用户有关证明资料
营业员对该用户号码执行
打印受理回执
向MSC/HLR接口派工单
功能描述
进入模块，系统根据手机的当前状态，显示出所办理业务为停机申请或开机申请。
输入手机号或用户编号，系统显示出相关资料：
用户本身资料：包括用户类别、用户名称、证件类别和号码、联系地址和邮编、联系电话。
手机的相关资料：手机的开通日期、手机号码、手机型号、手机机身号、SIM卡号、附加业务、承载业务、增值业务和手机使用证号等资料
停机申请：操作人员选择用户的申请停机时间，系统形成停机保号费、停机费及所欠话费，用户缴纳费用后打印发票并形成电子工单停机。
开机申请：用户停机后，须重新申请才能开机。
系统形成开机费及所欠保号费，用户缴费后形成电子工单开机。系统记录用户申请的停机时间。系统中用户的欠费停机和欠费单向停机相区别（包括停机标志、停机时间等）
退网拆户
业务定义
用户申请退网，但应保留或收取用户的押金或预付话费一段时间，适用于全部各种收费用户，记录用户退网的原因，同时退回部分款项(包括入网费、开户费等)，待用户完全缴纳通话费用后销户，销号后的号码保留一段时期(冷冻号)后自动释放。
业务流程
营业员按业务规定需收取押金或预付话费
用户缴费押金或预付话费
打印申请登记卡、押金收据、受理回执
向MSC/HLR接口派销号处理工单
功能描述
由于漫游数据的延迟性，因此用户拆机销号应先提出申请，立即停机，过一段规定期限，待漫游话单全部返回后，用户再去办理拆机销号的相关手续。
输入用户的手机号或用户编号，系统显示以下资料：
用户本身资料：包括用户类别、用户名称、证件类别和号码、联系地址和邮编、联系电话。
手机的相关资料：手机的开通日期、手机号码、手机型号、附加业务、承载业务、增值业务。
记录用户退网的原因，确认后，形成电子工单，对用户进行停机处理，系统记录预销号的时间。同时，打印回执给用户，通知用户在规定期限后来办理拆机销号手续。
输入用户的手机号或用户编号，系统计算出费用总计，费用总计为：应退还用户的费用（入网费、开户费等）减去应缴纳的费用（用户所欠话费及占频费等），用户应补交款项时，打印发票给用户；应退给用户款项时，打印退款凭条并需用户签字方可退款。销号后的号码，须先冷冻一段时间后才能重新释放，加入号码资源库。
挂失/补发
业务定义
对用户丢失手机或SIM卡的情况进行登记并根据实际情况作停机处理，如用户只丢失手机，则进行换机处理，如SIM卡丢失，则进行换卡处理；
业务流程
营业员核对用户有关证明资料
营业员对该用户号码执行
打印受理回执
向MSC/HLR接口派工单
功能描述
输入用户手机号或用户编号，系统自动显示出相关资料：
1、用户本身资料：包括用户类别、用户名称、证件类别和号码、联系地址和邮编、联系电话。
2、手机的相关资料：手机的开通日期、手机号码、手机型号、手机机身号、SIM卡号、附加业务、承载业务、增值业务和手机使用证号等资料
与用户提供的证件核对无异后确认，系统自动形成电子工单停止使用原SIM卡，随后用户可选择新的手机及SIM卡，并缴纳报失费、手机费及SIM卡费等，然后打印发票给用户，系统形成电子工单开通新的SIM卡。用户凭发票到领机领卡。
换机
业务定义
受理用户手机的更换业务，并记录更改原因；
业务流程
营业员核对用户有关证明资料
营业员操作
打印受理回执
向MSC/HLR接口派工单
功能描述
输入用户的手机号或用户编号，系统显示出相关资料：
1、用户本身资料：包括用户类别、用户信用度、用户名称、证件类别和号码、联系地址和邮编、联系电话。
2、手机的相关资料：手机的开通日期、手机号码、手机型号、手机机身号、SIM卡号、附加业务、承载业务、增值业务和手机使用证号等资料
可更改手机型号、手机机身号、SIM卡号、附加业务、承载业务、增值业务和手机使用证号等资料，用户须选择新手机的相关资料，其需交纳的费用为换机费、新手机的相关费用、返还旧手机的折价费之和，用户缴纳完各项费用后领机领卡。如用户更换了SIM卡，系统会自动形成电子工单停用原SIM卡，启用新SIM卡。
租机
业务定义
受理出租手机业务，完成退租、续租和转普通客户，记录退机时间、漫游限制、附加业务、承载业务等客户信息。
功能描述
租机开户的处理与客户处理基本相同，但采用不同的资费方案来满足租机的业务要求。在租机开户时可以设置收取押金和预存话费，在用户的总发生费用大于其预存话费时可以通过后台进行查询并做停机处理，让用户来补交预存话费或结清已出帐帐单后按情况做开机处理，在退租时可以退还全部押金和剩余预存话费。
完成租机用户手机的回收，押金和剩余预存话费的退还和未结话费的收取功能。用户在退租前要结清租机期间发生的所有话费。注意：用户退租时必须先结清话费才允许退还押金和所有预存话费。
受理方式
受理界面在系统中采用web风格，系统支持三种基本的受理方式：
远程营业终端通过网络远程登录到系统进行营业受理的处理。
营业点或代理商通过传真、电话等方式将相关资料传递给资料管理中心，由操作人员录入客户的资料。
客户事先预定，现场调出客户的预定资料进行营业受理。
业务受理结束后，系统可根据客户要求产生受理回执(包括购机入网客户的保修卡)或发票交客户留存，同时系统记录资料录入的方式。
用户资料管理
用户资料管理是对单个用户（或用户群）的客户资料，每一客户所对应的帐户资料，及所辖的各项设备资料进行管理。
用户资料查询
用户帐单查询
用户欠费查询
用户历史资料查询
用户统计
用户资料修改
预售用户查询
用户资料查询
可以根据用户群代码、用户代码、用户手机号码、SIM卡号、用户名称、开户日期、开户用户编号、月付款方式、开户所选资费方案以及通话资费方案等方式对用户的详细资料进行查询和统计；
用户话单查询
可以根据用户群代码、用户代码、用户手机号码、SIM卡号以及用户名称等方式查询并打印在一定时期内的用户详细通话记录和通话类别统计，可以单独对某类通话类别(如只对国内长途或国际长途)进行查询和统计，也可对某些通话类别(如对国内长途和国际长途)进行综合查询和统计；
用户帐单查询
可以根据用户群代码、用户代码、用户手机号码、SIM卡号以及用户名称等方式查询并打印某年月用户月帐单的详细信息、使用的月通话资费方案和月通话优惠额；并且支持帐单明细的查询，支持每条话单的优惠记录查询，可查看每条话单适用的优惠方案，优惠金额等。
用户欠费查询
可以根据用户群代码、用户代码、用户手机号码、SIM卡号以及用户名称等方式查询并打印在某年月以前用户欠费的详细信息；
用户历史资料查询
可以根据用户群代码、用户代码、用户手机号码、SIM卡号以及用户名称等方式查询并打印用户当前的资料及进行增改业务前后的详细资料以供比较；
具体操作如下：
输入查询代码（可以是用户群代码、用户代码、用户手机号码、SIM卡号以及用户名称等），系统会根据其特征自动判断其为哪一类代码并提示给操作员，同时还会判断其有效性。
也可以根据开户日期、开户用户编号、月付款方式、开户所选资费方案以及通话资费方案等方式进行查询。
查询项确认后，系统会显示出相应的用户资料，包括用户本身的资料、用户账务资料以及用户手机资料等。
用户统计
按用户群代码、用户代码、用户手机号码、SIM卡号、用户名称、开户日期、开户用户编号、月付款方式、开户所选资费方案、通话资费方案以及使用状态等方式对现入网用户和租机用户进行综合查询和打印，按用户手机号码、SIM卡号、用户名称、开户日期、开户用户编号和流失原因对流失用户进行统计；
用户资料修改
对人为造成的用户资料的错误，可通过用户资料修改模块来完成，主要是针对用户的详细资料(如用户名称、证件号码、联系地址和联系电话等)以及用户的付款信息等。
输入用户的手机号码或用户编号，系统会显示出相应的用户资料，包括：
用户本身资料：包括用户类别、用户信用度、用户名称、证件类别和号码、联系地址和邮编、联系电话、用户查询密码。
用户账务资料：包括购机付款方式、月付款方式、开户银行、银行帐号、帐户地址和邮编以及联系电话、优惠套餐、出帐周期及方式、发票号码等
手机的相关资料：手机的开通日期、手机号码、手机型号、手机机身号、SIM卡号、附加业务、承载业务、增值业务和手机使用证号等资料
操作员可以用编辑方式对所资料进行修改。
预售用户查询
操作人员需选择所需查询为有效的预售用户还是流失的预售用户。根据输入的用户类别，列出该类别所有预售用户的资料，并进行统计。
大客户管理
大客户包括重要客户、商业大客户、集团客户和战略客户。
重要客户是指党政军、公检法、新闻等国家主要部门客户。重要客户可分为：党政军重要客户、公检法重要客户、外事机构等重要客户、工商、税务、物价、新闻等单位客户。
商业大客户是指使用业务量大、通信费用高的用户。商业大客户具体选择标准由运营商按实际操作情况由低到高分为不同等级，并制定不同等级相应的服务标准。
集团客户是指具有隶属关系、同系统或有密切经济关系的单位和集体办理业务的客户。集团客户可分为：信息产业部所属企事业单位客户、国内企业事业法人单位客户、外企、外事法人单位客户。集团客户的确定各省、自治区、直辖市移动通信公司可根据本省实际情况按客户的购机数量和月平均通化费来核定集团大客户不同等级，并制定相应的服务标准。
战略客户是指经过市场调查、预测、分析，具有发展潜力，会成为市场争夺对象的用户。战略客户具体选择标准由运营商按实际操作情况选择并确定相应数量，对战略客户要积极跟踪、加强联系，寻找这一群体的业务使用特性及突破口，推出刺激、稳固其消费的措施，保持其忠诚度。
大客户业务受理
大客户管理业务受理可通过营业窗口、客户服务中心、大客户经营服务部门、大客户接待室、大客户经理等进行，其业务受理流程与一般用户业务受理流程基本相同，但需要营业人员提供优质、优先服务。
大客户资料内容包括：单位大客户代表姓名、用户类别、用户级别、大客户类别（个人、单位）、现在工作单位名称、单位地址、单位联系电话、传真号码、现任职务、家庭电话、E-Mail地址、现在住址、邮编、手机号码、何时成为大客户、每月平均话费、享受过的待遇和优惠、喜欢何种优惠方式、对公司提过的意见和建议及处理情况、历史上有无欠费、次数、数额及原因、喜欢使用哪些新业务、单位、职务、住址变动情况、单位大客户代表变动情况、单位手机持有情况及变动情况（包括异网用户）、手机使用、维修、配件情况、至少1年以上的话费情况（包括详单）和缴费记录、是否需要寄送账单的服务、帐单寄送的地址、身份证号码、性别、年龄、大客户其它资料、负责的客户经理姓名、客户经理联系电话、传真电话
其中用户类别可分为：(1)党政军；(2)公检法；(3)外事机构；(4)工商、税务、物价、新闻机构；(5)信息产业部企、事业单位；(6)外企、外事法人单位；(7)商业大客户；(8)战略客户；(9)其他。
用户级别可分为：(1)省级；(2)地市级；(3)县市级。
大客户资料统计
大客户资料统计包括大客户的构成情况、业务情况、通话构成、大客户业务收入情况、大客户收入的比重情况等。
大客户资料查询
大客户资料查询是指对已登记和未登记的大客户按一定条件进行查询，以便更好地服务于客户。
代销管理
代销商信用度管理
代销商类别管理
代销商资料管理
代销商资源分配管理
佣金分配及信用考核
代销商代销情况统计及代销日志管理
代销商管理支持营业厅经销、个人直销和代理商代理三种方式，营业厅经销是指自主经营销售手机；个人直销是指销售人员直接上门销售手机；代理商代理是由销售代理商以代销的形式销售手机，对代销商的管理主要是通过佣金结算来控制。
代销商信用度管理
代销商预付金管理：代销商预付金管理是指代销商在领机和领卡时应预付的押金或定金，可根据实际需求在系统中定义，其管理方式有两种：
1、以现金的方式表现，直接定义代销商领卡和领机时的预付押金或定金，如每卡元，每机元;
2、以百分比的方式表现，此方式可根据SIM卡和手机的实际费用不断变化，如可定义实际预付每卡为实际卡费的100％，预付每机为实际手机费用的100％。
代销商信用度管理：代销商的信用度主要由代销商预付金管理、佣金管理、信用度升降条件和信用度降级的处理方法四个方面构成，具体构成分述如下：
代销商预付金管理的具体构成见上；
代销商佣金管理的具体构成见上；
信用度升降条件主要有升级条件（月销售量连续在某个范围、总销售量超过某个范围、连续正常预付款和回款与客户投诉小于某个范围）和降级条件（月销售额连续低于某个范围、在一定时期总销售量低于某个范围、连续未正常预付款和回款与客户投诉小于某个范围），其中升级条件是’与’的关系，降级条件是’或’的关系；
信用度降级的处理方法主要有是否提出警告、是否停止供货、情节严重者是否诉诸法律等。
代销商类别管理
代销商分为营业厅经销、个人直销和代理商代理三种方式。每种方式又分为初级，中级，高级三种类别。
代销商资料管理
包括管理代销商名称、法人代表及相应的证件、负责人及相应的证件、公司地址及邮编、营业地址及邮编、联系电话、销售方式等。包括对代销商资料的增删改及查询。
代销商资源分配管理
根据代销商的类别及营业规模分配或回收操作员工号及系统使用权限、号码资源、SIM卡资源和手机及配件资源等。同时可以对代销商的资源使用情况进行查询。代销商可根据系统分配的权限进行远程营业受理和查询资源使用情况。
代销商资源使用查询是指可根据所选定的日期、代销商代码、代销商名称、销售类别和资源使用状态查询及打印代销商使用资源和库存的情况，其中代销商使用资源包括号码资源、手机资源、SIM卡资源和配件资源，
号码资源的查询内容包括号码分配时间、分配数量、销售情况、操作人员以及号码使用状态等；
手机资源的查询内容包括手机的分配时间、分配数量、销售情况、操作人员、手机使用状态以及库存数等；
SIM卡资源的查询内容包括SIM卡的分配时间、分配数量、销售情况、操作人员、SIM卡使用状态以及库存数等；
配件资源的查询内容包括配件的分配时间、分配数量、销售情况、操作人员、配件使用状态以及库存数等；
佣金分配及信用考核
根据代销商的信用度和实际销售情况与代销商进行佣金结算，并根据代理商的销售情况以及客户投诉情况进行考评，并对其信用级别作出相应的调整。
代销商销售情况统计及销售日志管理
☆代销商销售统计
代销商销售统计是指根据代销商的销售情况提供日营业和受理业务表、月营业和受理业务表以及年营业和受理业务表，同时可提供折线图对各代销商的销售情况进行分析。
☆代销商信用度调整
代销商信用度调整是指根据代销商的销售情况、客户投诉情况以及代销商预付押金和回款的情况人为地调整代销商的信用度，使达到监控代销商的目的。
资源管理
号码资源管理
号码资源管理包括本地网号和H0H1H2H3的维护、基本选号模式的维护、预留号的生成、预配号和开通号在各营业点的分配与回收、冷冻号的重新启用、特殊号码选号费修改和本地号码查询功能，以保证在任何时候预留号、预配号、开通号、使用号和冷冻号在数量上的一致性。另外，还可根据实际情况提供远程查询异地号码资源使用状况的业务。具体包括下述内容
网号和明码维护
预留号生成
开通号生成
预配号生成
选号费标准管理
选号费修改
销号管理
号码使用查询
号码使用查询
异地号码查询
☆ 网号和明码维护
网号和明码维护是指对本地网号（如0139，0138，0137。。。）和本地手机明码（H0H1H2H3）的维护，在此功能中可增加或修改或删除本地网号和本地手机明码，号源的生成就依据系统录入的网号和明码，对于不符合本地网号和本地手机明码的手机号码系统将不予承认。如果手机号码升位，只需在此功能中将本地网号和本地手机明码作相应的调整即可。
☆ 预留号生成
预留号生成是指根据本地网号和本地手机明码以及需要生成的手机号码范围自动生成预留号码，其中手机号码范围必须符合系统定义的本地网号和本地手机明码，选号费将根据系统定义的选号模式自动录入。
☆ 开通号生成
开通号生成是指将某一范围内的预留号预先开通，即将手机号与SIM卡号一一对应，记录开通号码的数量和时间。
☆ 预配号生成
预配号生成是指将预留号码根据需要分配到各营业点中，或将营业点中的号码根据需要回收，记录分配或回收号码的数量和时间，预配号的类别主要有非租机非传真号、非租机传真号、租机非传真号和租机传真号。
☆ 选号费标准管理
选号费标准管理是指在预留号生成前预先设置或修改或删除特殊号码的选号费（如末尾是‘8’或‘88’的等等），在预留号生成时系统将根据选号模式和需生成的号码自动将选号费录入。目前系统支持以末尾数匹配，多个匹配时，选择选号费大的一个。
☆ 选号费修改
选号费修改是指对于生成的预留号或开通号或预配号，可以根据实际需求进行选号费的个别调整。
销号管理
对已拆机、换号等不再使用的电话号码，可在空闲号码段中封存一段时间后，由系统自动释放，供客户使用。
☆ 号码使用查询
号码使用查询是指根据所输入的查询的号码段和营业点代码，显示出手机号码、号码当前的使用状态(即预留号或预配号或开通号或使用号或欠停号或冷冻号等等)、该号码实际启用时间以及对应的SIM卡号等信息。
☆ 号码使用统计
号码使用统计是指根据所输入的查询的号码段和营业点代码，对各使用状态的号码(即预留号或预配号或开通号或使用号或欠停号或冷冻号等等)进行统计，保证各使用状态的号码在总数和分类统计上的一致性。
☆ 异地号码查询
异地号码查询是指提供可以查询异地号码使用状态的功能，其内容包括手机号码、所属营业点、号码使用状态以及对应的选号费等，并提供各使用状态的号码统计数。
SIM卡管理
SIM卡管理包括SIM卡类别和SIM卡型号代码的维护、SIM卡入库与出库登记、SIM卡的报损登记以及SIM卡入库出库和库存查询，以保证在任何时候SIM卡在入库、移库、销售和报废数量上的一致性，并能够按SIM卡类别或SIM卡型号统计入库、移库、销售和报废的SIM卡数量和具体使用信息。
具体包括下述内容：
SIM卡入库
SIM卡出库
SIM卡出入库查询
SIM卡使用查询
SIM卡入库
SIM卡入库是指根据记录SIM卡资料的文件登记SIM卡信息，并录入指定的库房中，SIM卡信息包括SIM卡型号代码、SIM卡型号名称、SIM卡号、IMSI号、PUK1码、PUK2码、PIN1码、PIN2码、SIM卡容量、SIM卡使用寿命、SIM卡数量以及SIM卡的销售价格等。
☆ SIM卡出库
SIM卡出库是指将指定库房中的未使用SIM卡转移到另一指定的库房中，SIM卡信息包括SIM卡型号代码、SIM卡型号名称、SIM卡号、IMSI号、PUK1码、PUK2码、PIN1码、PIN2码、SIM卡容量、SIM卡使用寿命、SIM卡数量、SIM卡的销售价格、源库房名称、目的库房名称以及SIM卡的出库日期等。
☆ SIM卡出入库查询
SIM卡出入库查询是指按营业点代码、SIM卡型号、出入库时间和使用状态查询和打印SIM卡出入库的详细信息，其内容包括SIM卡型号代码、SIM卡型号名称、起始SIM卡号、终止SIM卡号、出入库时间、出入库数量、源库房、目的库房以及操作员等。
☆ SIM卡使用查询
SIM卡使用查询是指按营业点代码、SIM卡型号、SIM卡号和SIM卡使用状态查询SIM卡的详细信息，其内容包括SIM卡型号代码、SIM卡型号名称、所属库房名称、SIM卡号、IMSI号、PUK1码、PUK2码、PIN1码、PIN2码、SIM卡容量、SIM卡使用寿命以及SIM卡的销售价格等。
手机管理
手机管理包括各种手机品牌和手机型号代码的维护，手机的入库与出库登记、手机的折旧和报损登记、手机的保修期管理以及手机入库出库和库存查询，以保证在任何时候手机在入库、出库、销售、折旧和报废数量上的一致性，并能够按手机品牌或手机型号统计入库、出库、销售、折旧和报废的手机数量和具体使用信息。
具体包括下述内容：
手机入库
手机出库
手机出入库查询
手机使用查询
手机价格修改
☆手机入库
手机入库是指登记外购的手机信息，并录入指定的库房中，手机信息包括手机型号代码、手机型号名称、手机机身号、手机数量以及手机的销售价格等。
☆手机出库
手机出库是指将指定库房中的未使用手机转移到另一指定的库房中，手机信息包括手机型号代码、手机型号名称、手机机身号、手机数量、手机的销售价格、源库房名称、目的库房名称以及手机的出库日期等。
☆手机出入库查询
手机出入库查询是指按营业点代码、手机型号、出入库时间和使用状态查询和打印手机出入库的详细信息，其内容包括手机型号代码、手机型号名称、手机机身号、出入库时间、出入库数量、源库房、目的库房以及操作员等。
☆手机使用查询
手机使用查询是指按营业点代码。手机型号、手机机身号和手机使用状态查询手机的详细信息，其内容包括手机型号、手机机身号、所属库房代码、出入库时间、操作员以及手机的销售价格等。
☆手机价格修改
手机价格修改是指对某个手机型号的销售价格进行修改。
配件管理
配件管理包括各种配件品牌和配件型号代码的维护，配件的入库与出库登记以及配件入库出库和库存查询，以保证在任何时候配件在入库、出库和销售数量上的一致性，并能够按配件品牌或配件型号统计入库、出库和销售的配件数量和具体使用信息。
配件入库
配件出库
配件出入库查询
☆配件入库
配件入库是指登记外购的配件信息，并录入指定的库房中，配件信息包括配件型号代码、配件型号名称、配件数量以及配件的销售价格等。
☆配件出库
配件出库是指将指定库房中的未使用的配件转移到另一指定的库房中，配件信息包括配件型号代码、配件型号名称、配件数量、配件的销售价格、源库房名称、目的库房名称以及配件的出库日期等。
☆配件出入库查询
配件出入库查询是指按营业点代码、配件型号、出入库时间和使用状态查询和打印配件出入库的详细信息，其内容包括配件型号代码、配件型号名称、出入库时间、出入库数量、源库房、目的库房以及操作员等。
统计报表
统计报表管理模块除提供固定模式的统计和分析报表外，还提供报表生成工具，使操作员可按需求形成所需的统计报表，可按任意条件进行统计。
其中固定的统计报表细分为：
营业厅营收统计
营业厅业务受理统计
在网客户统计
信用度统计
资源使用统计
另外，我公司提供一套报表生成系统，可以自定义报表的格式。
营业厅营收统计
根据操作员工号、营业点代码和查询时间对各操作员、各营业点、各代理商的营收情况作出统计分析，给出日/月/年报表，其内容包括开户费用(如入网费、手机费、SIM卡费、频占费、选号费以及手续费等)、增改业务费用(如过户费、改号费、改名费、改号费以及业务增改费等)、预收款(如预定号码费用、预交话费以及预交押金等)、缴纳话费(如月租费、频占费、通话费、国内长途、国际长途、漫游费以及信息费等)、缴纳欠费(如月租费、频占费、通话费、国内长途、国际长途、漫游费、信息费以及滞纳金等)和退还费用(如退还入网费、退还手机费以及退还押金等)等；
保持以前的销售记录和销售统计，以折线图、饼图的方式对不同时期的销售额进行比较。
营业厅营收统计报表
单位： 统计人：
时间： 年 月 日——年 月 日 统计日期： 年 月 日
费用类型
数量
数量
开户费用
入网费
手机费
SIM卡费
频占费
。。。
增改业务费用
过户费
改号费
。。。
预收款
预定号码费用
预交话费
。。。
缴纳话费
月租费
频占费
。。。
缴纳欠费
月租费
频占费
。。。
退还费用
入网费
手机费
。。。
开户费用合计 ： 元 支票： 元 笔 现金： 元 笔
增改业务费用合计： 元 支票： 元 笔 现金： 元 笔
预收款合计 ： 元 支票： 元 笔 现金： 元 笔
交纳话费合计 ： 元 支票： 元 笔 现金： 元 笔
缴纳欠费合计 ： 元 支票： 元 笔 现金： 元 笔
退还费用合计 ： 元 支票： 元 笔 现金： 元 笔
总合计 ： 元 支票： 元 笔 现金： 元 笔
营业厅业务受理统计
(1) 统计各操作员、各营业厅、各代理商的业务受理情况，给出日/月/年报表，其内容包括开户业务统计(如新装开户、代销商开户、公免公纳开户以及潜在用户登记等)、增改业务统计(如过户、改名、改号、换机、申请停开机、业务增改以及帐户修改等)、缴费业务统计(如营业点缴费、银行代缴以及欠费缴费等)、退还业务统计(如潜在用户取消、拆机销号等);
营业厅业务受理统计
单位： 统计人：
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
业务名称
业务数量
业务金额
开户业务统计
新装开户
代销商开户
。。。
增改业务统计
过户
改名
。。。
缴费业务统计
营业点收费
银行代缴
。。。
退还业务统计
潜在用户取消
拆机销号
。。。
开户业务合计 ： 元 支票： 元 笔 现金： 元 笔
增改业务合计 ： 元 支票： 元 笔 现金： 元 笔
缴费业务合计 ： 元 支票： 元 笔 现金： 元 笔
退还业务合计 ： 元 支票： 元 笔 现金： 元 笔
总合计 ： 元 支票： 元 笔 现金： 元 笔
(2) 根据营业点的业务受理情况，提供各营业点业务负荷量的分析报表，使之成为考核操作员业务量的标准，并监控各营业点的受理情况。
在网客户统计
(1) 统计即时在网客户数、各类业务客户数及某段时间内的客户净增数，并能对在网客户作出分类统计，其内容包括客户名称、手机号码、客户类别、客户信用度、联系地址和邮编、联系电话以及月付款方式等;
在网客户统计
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
客户名称
手机号
客户类别
客户信用度
联系地址
邮编
电话
付款方式
客户总数：
客户类别： 统计人：
(2) 按销售量、销售额或时间段分类统计直销人员发展客户情况，其内容包括直销人员代码、直销人员名称、直销人员信用度、查询时间范围、发展用户数、发展用户分析以及在查询时间内应得的佣金；
销售人员业绩统计
时间： 年 月 日 — 年 月 日 统计日期： 年 月 日
姓名
代码
信用度
发展用户数
应得佣金
统计条件:
统计人：
(3)按销售量、销售额或时间段分类统计代理商的销售情况并计算相应的业务酬金，其内容包括代理商代码、代理商名称、代理商信用度、查询时间范围、发展用户数、发展用户分析以及在查询时间内应得的佣金。
代理商业绩统计
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
代理商名称
代理商代码
信用度
发展用户数
应得佣金
统计条件：
统计人：
信用度统计
1．按信用度、客户类别、时间段等方式分类统计客户信用度及客户数，其内容包括客户名称、手机号码、客户类别、客户信用度、联系地址和邮编、联系电话、月付款方式以及通话费用统计、通话次数统计、通话时长统计、缴费次数统计和欠费次数统计、欠费额等，对信用度极低的客户给出告警信息提供给管理部门;
客户信用度统计报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
客户名称
手机号码
客户类别
信用度
联系地址
邮编
电话
付款方式
通话
费用
通话
次数
通话
时长
缴费
次数
欠费
次数
欠费
额度
告警
指示
统计条件：
客户总数： 统计人：
2．按信用度、客户类别、时间段等方式分类统计客户信用度调整情况及客户数，其内容包括客户名称、手机号码、客户类别、客户信用度、原信用度、联系地址和邮编、联系电话、月付款方式以及通话费用统计、通话次数统计、通话时长统计、缴费次数统计和欠费次数统计、欠费额等，对信用度极低的客户给出告警信息提供给管理部门；
客户信用度调整统计报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
客户名称
手机号码
客户类别
信用度
联系地址
邮编
电话
付款方式
通话费用
通话次数
通话时长
缴费次数
欠费次数
欠费额
告警指示
统计条件： 客户总数： 统计人：
3．按信用度、客户类别、客户信用等级或时间段等方式分类统计防欺诈情况，其内容包括客户名称、手机号码、客户类别、客户信用度、联系地址和邮编、联系电话、日通话限额、月通话限额、日透支限额、月透支限额以及客户日通话额、月通话额等，对超过日通话限额和月通话限额的客户可提出警告，对超过日透支限额和月透支限额的客户可作要求客户预交话费或停去话或停机处理；
防欺诈统计报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
客户名称
手机号码
客户类别
信用度
联系地址
邮编
电话
付款方式
日通话限额
月通话限额
日透支限额
月透支限额
日通话额
月通话额
告警指示
统计条件： 客户总数： 统计人：
4．按时间段或欠费情况分类统计黑名单客户，黑名单客户是面向全市的，其内容包括客户名称、客户类别、客户证件信息、联系地址和邮编、联系电话、欠费额、欠费起始时间以及欠费情况分析等；
欠费情况统计报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
客户名称
客户类别
证件信息
联系地址
邮编
电话
欠费额
欠费起始时间
客户总数： 统计条件 统计人：
资源使用统计
1．按营业点代码、手机型号、出入库时间和使用状态查询和打印手机出入库的详细信息，其内容包括手机型号代码、手机型号名称、手机机身号、出入库时间、出入库数量、源库房、目的库房以及操作员等。
手机出入库统计报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
手机代码
手机型号名称
机身
号码
出入库时间
出入库数量
源库房
目的库房
操作员
统计条件：
统计人：
2．按营业点代码、SIM卡型号、出入库时间和使用状态查询和打印SIM卡出入库的详细信息，其内容包括SIM卡型号代码、SIM卡型号名称、起始SIM卡号、终止SIM卡号、出入库时间、出入库数量、源库房、目的库房以及操作员等。
SIM卡出入库统计报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
SIM卡代码
SIM卡型号名称
起始SIM卡号
终止SIM卡号
出入库时间
出入库数量
源库房
目的库房
操作员
统计条件： 统计人：
3．按营业点代码、配件型号、出入库时间和使用状态查询和打印配件出入库的详细信息，其内容包括配件型号代码、配件型号名称、出入库时间、出入库数量、源库房、目的库房以及操作员等。
配件出入库统计报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
配件型号代码
配件型号名称
出入库时间
出入库数量
源库房
目的库房
操作员
统计条件： 统计人：
4．按营业点代码、器材型号和查询时间查询和打印器材的库存数，其内容包括器材型号代码、器材名称。器材库存数和结余日期。
器材库存统计报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
器材型号代码
器材名称
库存数
结余日期
统计条件： 统计人：
5. 按营业点代码。手机型号、手机机身号和手机使用状态查询手机的详细信息，其内容包括手机型号、手机机身号、所属库房代码、出入库时间、操作员以及手机的销售价格等。
手机详情查询报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
手机型号
机身号码
所属库房代码
出入库时间
销售价格
操作员
统计条件： 统计人：
6．SIM卡使用查询是指按营业点代码、SIM卡型号、SIM卡号和SIM卡使用状态查询SIM卡的详细信息，其内容包括SIM卡型号代码、SIM卡型号名称、所属库房名称、SIM卡号、IMSI号、PUK1码、PUK2码、PIN1码、PIN2码、SIM卡容量、SIM卡使用寿命以及SIM卡的销售价格等。
SIM卡详情查询报表
时间： 年 月 日— 年 月 日 统计日期： 年 月 日
SIM卡型号代码
SIM型号
名称
所属库房代码
SIM卡号
IMSI号
PUK1码
PUK2码
PIN1码
PIN2码
SIM卡容量
使用寿命
销售价格
统计条件： 统计人：
系统维护
操作员管理
操作员管理模块支持对各类代销商分配或取消操作员及系统使用权限，对不同的操作员，可设置不同的使用权限(包括系统菜单、功能选项和录入数据等类别)，各使用权限所能使用的应用软件模块可按要求自由组合，由系统管理员统一修改；对不同的操作员可实行不同的密码管理；对操作员的登录和当班管理由系统操作员统一修改。
主要管理功能分述如下：
系统权限级别设置
操作员资料管理
操作员权限设置、登录及当班管理
操作员密码修改
系统权限级别设置
由系统管理员根据操作员的工种定义不同的操作权限。包括对系统功能菜单(即操作员使用的菜单选项)、功能选项(即在操作界面中可使用的功能键)和操作数据项(即在操作界面上的输入域、选择域等)三类使用权限的增加、修改、删除、查询和打印功能，系统操作权限由操作权限代码、操作权限名称以及所属模块名称组成。
操作员资料管理
记录或取消操作员资料，包括操作员工号、操作员姓名及证件信息、联系地址及邮编、联系电话以及权限级别等。登记的操作员的详细信息包括操作员工号、操作员姓名和证件信息、联系地址及邮编、联系电话、所属营业点、权限级别、操作范围(即操作员允许登录的地点)以及查询范围(即操作员允许查询的范围)等。除了登记操作员资料的功能以外，还提供修改操作员信息和取消操作员的功能，其中取消操作员相当于是屏蔽操作员，使操作员在正常操作中不可视，待到一定时期后才正式删除操作员信息。
☆ 操作员权限设置、登录及当班管理
对系统给定的操作员权限进行再调整；监测操作员的登录信息和当班设置，使即使在计算机出错的情况下，非授权者也不能进入系统；提供安全报警信息给系统管理员，并提供正确的系统恢复方法。
在操作员登记中，已预先设置操作员的权限级别，即已赋予操作员一定的操作权限，在本功能中可根据操作员实际的工种和工作情况对其操作权限作进一步的调整。可以预先设置操作员登录系统的时间，操作员在允许登录时间内登录视为合法，在不允许登录时间内登录视为非法。
☆ 操作员密码修改
操作员可随时修改密码，并提供两种修改下级操作员密码的模式。在新登记操作员时，系统不设置密码，而让操作员在第一次登录系统时自行设置密码。操作员随时可修改自己的密码，或根据其权限级别在规定时间内没有修改密码系统将强制操作员修改密码，上级操作员修改下级操作员的管理模式主要有两种：
允许上级操作员有权限不输旧密码就可直接修改下级操作员的密码;
只有系统操作员才有权限不输旧密码直接修改下级操作员的密码。
器材代码管理
维护各类器材的类别，品牌，型号，并给各类器材编码，具体包括如下功能。
器材类别维护
器材品牌维护
器材型号维护
器材类别查询
器材品牌查询
器材型号查询
器材库存查询
☆器材类别维护
器材类别维护是将销售的器材进行分类，新增或修改器材类别的信息，信息包括器材类别代码和器材类别名称。
例如：器材类别代码由一位数字表示，其中’1’手机，’2’代表SIM卡，’3’代表配件。
☆ 器材品牌维护
器材品牌维护是将销售的器材品牌进行分类，新增或修改器材品牌的信息，信息包括器材品牌代码、器材品牌名称和所属器材类别代码。
例如：器材品牌代码由三位数字表示，其中第一位代表器材类别代码，第二、三位表示器材品牌代码，可以从’01’定义至‘99’。
☆器材型号维护
器材型号维护是将销售的器材型号进行分类，新增或修改器材型号的信息，信息包括器材型号代码、器材型号名称和所属器材品牌代码。
例如：器材型号代码由六位数字表示，其中第一位代表器材类别代码，第二、三位表示器材品牌代码，第四位至第六位表示器材型号代码，可以从’001’定义至‘999’。
☆器材类别查询
器材类别查询是指查询和打印器材类别的信息，内容包括器材类别代码和器材类别名称以及建立日期等。
☆器材品牌查询
器材品牌查询是指根据器材类别查询和打印器材品牌的信息，内容包括器材品牌代码、器材品牌名称、所属器材类别名称以及品牌建立日期等。
☆器材型号查询
器材型号查询是指根据器材类别或器材品牌查询和打印器材型号的信息，内容包括器材型号代码、器材型号名称。所属器材品牌名称以及型号建立日期等。
☆器材库存查询
器材库存查询是指按营业点代码、器材型号和查询时间查询和打印器材的库存数，其内容包括器材型号代码、器材名称。器材库存数和结余日期。
操作轨迹管理模块
操作轨迹管理模块主要记录系统操作过程中与安全、责任相关的重要操作，其内容包括操作的日期时间、地点、操作员、操作代码、操作说明等信息，主要记录的详细信息如下：
前台营业业务受理
后台帐务、缴费及欠费处理
代销商和操作员管理
号码资源、手机及配件、SIM卡及各类票证管理
客户资料增改记录
具体功能详述如下：
操作轨迹查询
前台营业业务查询
后台帐务业务查询
操作轨迹查询
操作轨迹查询是指对操作员在系统中的所有操作可按营业点代码、操作员工号、受理业务以及某一时间范围进行查询和打印，其内容包括操作员工号、操作时间、受理业务内容、增改系统参数或客户资料的详细说明以及操作是否成功等。
前台营业业务查询
前台营业业务查询是指对操作员在营业受理时的所有操作可按营业点代码、操作员工号、受理业务以及某一时间范围进行查询和打印，其内容包括操作员工号、操作时间、受理手机号码、受理业务内容、受理金额、增改客户资料的详细说明以及操作是否成功等。
后台帐务业务查询
后台帐务业务查询是指对操作员在帐务处理时的所有操作可按营业点代码、操作员工号、受理业务以及某一时间范围进行查询和打印，其内容包括操作员工号、操作时间、受理手机号码、受理业务内容、受理金额、增改客户资料和帐单的详细说明以及操作是否成功等。
机房管理
主要是完成停开机业务的查询和再次处理功能。在网络故障时可以通过打印工单的形式通知交换机人员直接操作，在操作完成后再作确认处理，对失败命令可以通过命令修改再次提交。
系统参数维护
对一些控制程序执行的参数进行维护，比如缺省帐单月的维护，对某些增改业务是否一定要结清所有帐单或由操作员来决定是否继续的参数设定等 。
系统基本资费维护
主要是对一些电信行业规定的增改费率的维护，主要有以下资费：
费用名称
资费金额
过户费
分户费
合户费
改名费
改号费
换机费
换电子串号费
报失补机手续费
停机费
开机费
修改帐户费
功能增改手续费
拆机停机费
拆机销号费
信用度管理
信用度是用来衡量用户信用的等级，不同等级的信用度对应不同的积分区间。
信用度管理是指对用户信用度的级别和级别升降条件的管理。信用度用于欠费管理，在欠费管理中，可根据不同信用等级设定滞纳金的起算时间、停服务的启始时间、停服务的先后顺序等。
信用度最根本的目的是通过信用额度管理来控制不良话费、提高话费收缴率
信用度管理用户需求
由于移动与IP市场的竞争将日趋激烈，对客户的个性化、人性化管理将淘汰以往一刀切的管理模式。信用消费，将成为各移动、IP供应商争夺市场的利器。
然而，信用消费，是一把“双刃剑”。在提供信用消费，争夺市场的同时，各移动、IP供应商必须面对潜在的信用风险。
在这样的市场情况下，信用度管理的需求便产生了。
简而言之，信用度管理必须满足两个最基本的需求：
尽可能高的提供信用额度以争夺客户
尽可能及时的控制信用风险
AICBS信用度管理设计目标
实用性：
严格的讲，个人（或团体）的信用度是一种信用指标的集合，牵涉到的范围极其广泛，其数据采集源非常多。按照我国目前的情况而言，要建立一套绝对完整的信用度管理系统几乎没有什么可行性。
因此，在这里所要建立的是一套真正实用的，能够满足各移动、IP供应商实际要求的信用度管理系统。
灵活性：
由于目前各个省市都陆续发展信用评估机构，进行信用评估服务，但各地的发展参差不齐。本系统应具备输入接口、输出接口，以便与外部系统接轨，减少升级成本。
及时性：
能否及时的调整信用度，保持信用度管理系统的长期有效性，是各移动、IP供应商控制信用风险的关键。
角色严密性：
个体的定义：有且仅有一份用户资料，一个帐务编号的消费单位。
团体的定义：共享一份用户资料，同时，拥有一个以上帐务编号的消费单位。
可见，个人只是团体的一种特殊情况、一个子集。
信用建模
信用度管理系统的成败，关键便在于建模。
前面，在信用度管理设计目标中已经提到，本套信用度管理系统的首要设计目标是实用，而不是大而全。
相关因素分析
◆信用评估
原则：尽可能高的提供信用额度以争夺客户
个体形象评估
客户类型：普通客户、大客户、重要客户
担保情况：担保/免担保
付款方式：普通付费、可靠付费（如信用卡付费、托收）
出生日期：一般风险年龄、高风险年龄（70岁以上）
个体公众形象评估
外部接口输入数据，如银行提供的信用度、黑名单等。
个体支付信用评估
历史支付情况：信用期限内付费、过期付费
◆风险评估
原则：尽可能及时的控制信用风险。
个体支付风险评估
历史支付情况：欠费
社会地域风险评估
入网地区：信用危机地区、信用危险地区、一般风险地区、信用良好地区。
社会经济风险评估
反映各个地区的客户人均支付能力，包括：GNP/GDP指数、通胀指数、恩格尔系数、物价指数、银行利率。
信用度计算方法
信用度计算方法
信用度点数 = （个体形象点数+个体公众形象点数+个体支付信用点数-个体支付风险点数）*社会地域风险加权*社会经济风险加权
信用度点数与信用金额的换算方法
信用金额 = 信用度点数*换算常量（默认为50）
◆个体形象评估计算方法
目标：体现客户本身的个体性质差异。
客户类型分：普通客户（4分）、大客户（40分）、重要客户（100分）
担保风险分：担保（10分）、免担保（0分）
付款风险分：普通付费（0分）、可靠付费（如信用卡付费、托收）（10分）
用户年龄分：一般风险年龄（0分）、高自然风险年龄（70岁以上）（- 4分）
个体形象点数 = 客户类型分+担保风险分+付款风险分+入网年限分+用户年龄分
◆个体公众形象评估计算方法
目标：提供外部数据入口，为今后与外界数据接口做准备。
外部接口输入数据，如银行提供的信用度、黑名单等。在本系统中只保留入口，具体算法将视具体情况而定。
◆个体支付信用评估计算方法
目标：体现用户信用与正常缴费时间的密切关系。
（最近24个月）支付情况加权：信用期限内付费加权(6%)、过期付费加权（3%）
消费信用分：最近12个月内已支付的最高月消费金额*(1+Σ支付情况加权)/ 换算常量
个体支付信用点数=消费信用分
◆个体支付风险评估计算方法
目标：体现对用户累计欠费敏感性。
（最近12个月）欠费情况：欠费月消费金额/换算常量 取整
个体支付风险分=Σ欠费情况
◆社会地域风险评估计算方法
目的：对各地的不同信用情况区别对待。
入网地区加权：信用危机地区50%、信用危险地区80%、一般风险地区100%、信用良好地区120%。
社会地域风险加权 =入网地区加权
◆社会经济风险评估计算方法
目的：反映各地的经济变化趋势，以衡量各个地区的客户人均支付能力。
反映各个地区的客户人均支付能力，如GNP/GDP指数、通胀指数、恩格尔系数、物价指数、银行（存、贷款）利率、央行贴现率。
具体计算建模方法待定。
角色定义与相关分析
在上面已经提到过，个体信用度只是团体信用度的一种特殊情况、一个子集。因此，信用度计算公式可扩展为
扩展后的信用度点数计算方法
信用度点数 = （个体形象点数+个体公众形象点数+Σ个体支付信用点数-Σ个体支付风险点数）*社会地域风险加权*社会经济风险加权
黑名单管理
黑名单管理主要是为了阻止欠费预销号用户，信用条件不过关的客户的再次入网。黑名单管理主要应包括黑名单接收，黑名单发送，黑名单查询等几个功能。
黑名单发送
黑名单发送是指生成黑名单文件并向全国中心进行传送的过程。黑名单文件由黑名单用户资料和被取消的黑名单用户资料组成。
黑名单接收
黑名单接收是指系统接收全国中心下发的黑名单或系统外黑名单的录入过程。
黑名单查询
黑名单查询是根据各种条件进行查询的过程，查询条件包括客户名称、身份证号码、计费号等。
信用度管理
信用度管理是指通过对用户初始信用度的设定、在用户使用服务的过程中根据用户的属性、缴费情况、服务使用情况等因素对用户的信用度进行调整以及一系列的信用规则、算法和动作的定义，对用户的服务使用进行限制，以达到控制不良话费、提高话费收缴率的目的。信用度管理又可以分为服务限制规则管理、信用度初始化规则管理、信用度调整规则管理、黑名单管理。
AICBS系统中的信用度管理最大的特点是基于规则的管理，这些规则是可以灵活配置的，而不是内置于应用程序内部的，这意味着可以给用户最大的灵活性，进行规则调整将会非常方便，而且可以很快达到效果，在AICBS系统内部内置了规则解析器，完成规则的解析功能。
AICBS系统中的信用度管理分两级，一级在帐户上，一级在定购上，用户在开户时可以根据自己的需要决定使用那一种信用度管理模式。
服务限制规则管理
服务限制规则管理是对累计欠费告警上下限、日费用额的告警上下限、月费用额的告警上下限等进行定义，同时对每个信用级别规定其帐单在欠费多少天后开始计算滞纳金、帐户欠费多少天后对其订购开始人工停去话或自动停去话、多少天后开始人工停机或自动停机、欠停多少天后开始欠费预销号上黑名单，在日发生额到达告警下限时是进行电话催缴或自动催缴、人工停去话还是自动停去话处理，在日发生额到达告警上限时是进行人工停机还是自动停机处理，在累计欠费到达告警下限时是进行电话催缴还是进行自动催缴、人工停去话还是自动停去话处理，在累计欠费到达告警上限时是进行人工停机还是自动停机处理等。
AICBS综合营帐系统是数据集中、管理分散的系统，因此允许各地市都可以定义自己的服务限制规则。另外，AICBS综合营帐系统是融合的营帐系统，可以同时承载无线语音业务、无线数据业务、IP业务等，可以每种服务都分别定义服务限制规则。
信用度初始化规则管理
对新开户的用户按其客户类型、客户职业、月付款方式、帐户类别、开户日期、预存款、选购产品、归属服务商、归属行政域、归属营业厅等因素计算其初始的信用度。
同一信用度可以作为多个条件的初始信用度出现，在前台开户时当其条件可以选择到多个初始信用度时，取最大的信用级别，当没有满足要求的信用度时选择最小的信用度。
AICBS的信用度初始化是基于规则的，而规则是用条件表达式表达的，例如：
(职业 = 教师) & (付款方式 = 预付款) & (产品 = 388元套餐) credit_value = 200
(职业 = 工程师) & (付款方式 = 预付款) & (产品 = 388元套餐) credit_value = 300
信用度调整规则管理
对在网用户，根据其客户类别、帐户类别、职业、历史缴费情况、历史欠费情况、服务使用情况、归属服务商、归属行政域、归属营业厅等要素计算其信用度调整值。
可以选择的条件因素有：
客户类别满足什么条件
帐户类别满足什么条件
帐户结余预存款在多少元以上，多少元以下
帐户下含有什么产品
帐户已连续正常缴费多少个月
帐户累计销帐金额在多少元以上，多少元以下
帐户累计欠费金额在多少元以上，多少元以下
帐户累计发生额在多少元以上，多少元以下
帐户月付款方式满足什么条件
帐户平均月通话费在多少元以上，多少元以下
帐户在最近多少天中累计欠费停机的用户在多少次以上，多少次以下
客户职业满足什么条件
帐户归属服务商是什么
帐户归属销售商是什么
帐户归属营业厅是什么
帐户的开户时间在什么时间和什么时间之间
…
同样，信用度调整也是基于规则的。
黑名单管理
黑名单管理主要是为了阻止欠费预销号用户、信用条件不过关的客户的再次入网。黑名单管理主要应包括黑名单登记、外来黑名单登记、部中心下发黑名单入库、本省黑名单出库上发、黑名单查询、黑名单删除等几个功能。
在信用度管理中定义了用户欠费多少天、多少钱后上黑名单的规则。
代理商管理
代理商是对替系统运营商发展用户、开办业务的各类代理、代销机构的统称。在AICBS系统中，代理商开展业务可以有很多种模式：
代理商从移动公司批发一定数量的记名卡或不记名卡，为移动公司办理移动电话卡销售业务，代理商发展用户后返回用户资料，由管理营业厅录入用户资料和代理商的销售记录。
系统运营商为代理商提供营业终端，代理商直接接入系统进行卡的销售，并录入用户资料，实现即买即通，同时系统记录代理商的销售记录。
代理商可以开办系统运营商开办的各项业务，代理商发展的用户为代理商的用户，并且可以带有代理商的特殊标识。此时，代理商不再是普通意义上的代理商，而是变为AICBS系统的服务提供商（SP）。
代理商管理主要有代理商资料管理、代理商资源分配、代理商权限管理、代理商费用结算和代理商业绩考核等管理功能。
在AICBS系统中，将代理商是看作营业厅的一种实例模式。亦即，营业厅不再是普通意义上的营业厅，而是可以体现业务办理、代理、代销等各种业务模式的机构的集合，从而纳入统一的管理模式，实现资源分配回收、权限管理、费用结算等各项功能。
在AICBS系统中，通过sp、region、office三位一体的垂直管理模式，加上各sp、region、office之间的授权管理，可以非常灵活的实现代理商的管理以及未来的功能的扩展。
AICBS面向未来，在架构上实现了通过互联网、接入终端、客服、银行等各种开展业务的模式，只要有操作员和营业厅（即使是虚拟的），就可以办理业务，当然也可由别的营业厅代理办理各种业务（如果已经授权的话）。
代理商资料管理
代理商资料管理主要是在代理商资格认证之后，在系统中为代理商定义相应的资料，用于代理商的业务操作和管理。AICBS系统提供对代理商资料进行增、删、改、查维护界面。代理商信息包括：标识、名称、类型、地址（公司地址、营业地址）、法人代表、负责人、联系人、联系电话、税号、押金、合同、等级、归属服务商、归属行政域等。
在移动业务中代理商可以代理的业务种类有：SIM卡、号码、神州行卡、缴费卡等，一个代理商可以代理一种或多种业务。
代理商资源分配
代理商可以通过AICBS综合营帐系统管理自己的资源。代理商的上级（行政域）可以分配资源给代理商，并记录资源销售的历史。代理商的上级可以回收分配给代理商的资源。在资源销售记录表中，记录了资源数量、承销类别、资源的单位价格、买断价格、所交押金、手续费、结算周期等各种信息。
为提高对代销商的管理，对代销商已购买的卡或号码可以做批量开通与停机操作，或者对卡进行批量激活或冻结的操作。
根据代销商、资源种类、分配时间、分配区间和分配方向等还可以查询代销商资源分配的历史记录、各种资源数量和明细内容。
代理商费用结算
根据代理商的代理业务种类、代理业务的销售情况和费用结算方法计算代理商的佣金或手续费，结算费用。
根据代理业务（如记名卡和不记名卡）的种类，可以采用不同的结算方法。代理记名卡可以采用代理商先领卡，然后定期根据代理商等级和销售情况（以返回的用户资料为基准）结算手续费的方法；而代理不记名卡则可以采用在领卡时就根据代理商的等级和销售数量或领卡数量结算手续费的方法。
代理商费用结算要素包括：
代理商编码；
代理业务种类；
代理商等级；
资源销售数量；
结算周期；
代理费结算方法：按比例或者固定金额。
AICBS综合营帐系统中采用公式化规则对代理商费用结算进行管理。
代理商权限分配
代理商如果需要接入AICBS系统完成资源的销售和业务办理功能，就需要对代理商的权限进行管理。
通过权限配置，可以精确管理到代理商可以办理何种业务、接入到哪一个营业厅、对哪些菜单具备操作权限、可以卖哪些产品等等。也可以让代理商进行自己的业务统计。
如果代理商愿意，也可以将自己的业务功能授权给其他营业厅代为办理，自己只是进行资源的销售。
代理商业绩考核
为引入优胜劣汰的竞争机制，对代销商实行分类分级管理，根据代销商的销售情况、用户发展情况以及客户投诉情况进行考评，并对其等级作出相应的调整。
代销商业绩考核要素包括：
代销商编码；
代销业务种类；
代销业务考核时间范围；
资源销售情况（销售数量、金额）或用户发展情况（包括用户种类、入网数量、欠费数量、脱网数量等）；
客户投诉情况。
代销商的等级直接影响到其费用的结算比例。
统计分析模块
统计分析子模块提取出详单表中的数据，形成各种中间数据，为前台快速形成报表打下坚实基础，中间结果也为决策系统提供信息。统计模块提供诸如业务统计报表、话单文件分类统计、话务量统计、用户数统计报表、汇总对帐统计报表（移动业务）、高额统计报表、图形报表、其它报表等系列统计信息。
生成方法：根据漫游类型和指定的基站号标识得到本年自年初截止至本月的基站所有通话次数比较图；
数据源表：基站信息表；
可选统计方式：月段统计、日段统计、时段统计；
可选‘考虑基站方向’；
可选择填入‘基站号标识’。数据仓库作为决策支持系统的数据核心，其中的数据是以面向主题的形式组织的。具有数据的抽取、清洗、转换到数据仓库的综合管理
实现原始报表数据的自动收集及应用的集中化。
提供灵活的动态报表功能。当用户的要求及各种报表的需求改变时，或有新的报表要求时，提供快速、灵活的开发手段，提高IT人员的生产率，减少应用开发人员的维护量。
能够提供灵活的联机分析(OLAP)能力。对原始的报表数据能够进行多角度、深层次的分析。
满足移动通信运营商未来发展的要求，具备可伸缩性和可扩展性，可以和计费及综合管理等的其它计算机系统紧密集成，保证技术上的先进性。
系统管理员既可以操作生成各种报表视图，也可以发布文档供各级操作员浏览；
各级操作员客户端基于浏览器方式通过广域网向省局中心数据统计查询服务器(包括OLAP SERVER)发请求,接到请求后,服务器将分析运算的结果下发.然后在各级操作员客户端进行数据呈现，也可以去浏览共享资料库中的发布的报表及文档。
分析主题
统计分析的数据核心是面向业务主题的，因此数据是以面向主题的形式组织的。结合这种面向主题的数据组织形式和移动通信业务的业务管理需求，该系统主要功能模块是依据主题的划分来确定。我们将统计分析主题定义为：
业务量分析
业务量分析主要是针对各业务量数据(主要为通话次数、通话时长、通话费用)进行分析，发现它们与时间、地区、业务类型等之间的相关关系。
通话次数分析
通过通话次数分析，可以反映各个时间段内用户发起呼叫次数的多少，从而反映移动交换系统各个时间段的繁忙情况。可以按照各种分类情况，得到相应的分类情况下的用户通话次数分布特征。
用户通话次数主要包括以下分析内容：
1．按照通话次数的档次分类：
可以得到各种档次的每个用户的通话次数，以及该档次的用户所占的比例情况。
2．按地区分类：
可以得到各个地区通话次数的分布以及所占的比例情况。
3．按照通话类型分类：
可以得到不同的通话类型的通话次数的分布情况及其所占的比例。
如：
按照长话类型分类（省内长途、国内长途、国际长途）
按照漫游类型分类（本地、省内漫游、省际漫游、国际漫游、漫游来访、漫游出访）
按对端类型分类（移动、CDMA、固定、联通等）；
按业务类型分类（语音、承载业务、附加业务）；
按话务流向（信息台、BP、移动、固定等）；
以上的各种分析结果可以用各种图形进行展示，例如折线图、饼图、直方图、立体图等，用户可以方便地了解各种分类的分布及其所占的比例情况。并可以结合时间参数了解通话次数的分布趋势。
通话时长分析
可以分析用户的通话时长的分布，了解用户通话时长的分布规律。可以用各种图形来展示各个通话时长内，各种类型的用户的分布情况及其所占的比例。
通话费用分析
用户通话费用的分析，可以反映各类用户呼叫产生的费用的多少及其所占的比例。据此，可以了解各类用户单次呼叫产生通话用户单次呼叫产生叫产生通话费用的分布规律。
通话费用分布分析包括以下各分类分析：
按地区分类的通话费用分析
按主被叫分类的通话费用分析
按长话类型分类的通话费用分析
按漫游类型分类的通话费用分析
按对端类型分类的通话费用分析
按业务类型分类的通话费用分析
按业务代码分类（service_code）；
按话务流向的通话费用分析
以上的各种分析结果可以用各种图形进行展示，例如折线图、饼图、直方图、立体图等，用户可以方便地了解各种分类的分布及其所占的比例情况。并可以结合时间参数了解通话次数的分布趋势。
最高业务量分析
对最高通话次数、通话时长、通话费用进行分析，从而了解各个分析指标的峰值。主要包括以下分析内容：
1．呼叫频率分析
可以找出呼叫频率很高的主叫号码、对端号码或是主被叫组合，从而分析其产生的原因，以便于制定各种促销政策和优化网络。
2．最高通话时长分析
可以找出通话时长最高的号码，从而分析其产生的原因。
3．通话费用比较分析
分析最高通话费等各种最高通话费用的特征，从话费类型（本地通话费、漫游费、国内长途费、国际长途费、信息费、附加费等）进行比较分析，并可以把分析结果用各种图形进行展示，例如折线图、饼图、直方图、立体图等。
网络状况分析
通过基站配置与话务量分布情况的分析，帮助企业优化现有设备组合以及基站建设，提高企业的效益。
比较分析各基站的业务量，分析各基站的话务特征，分析各个时段各基站/交换机的负载情况。
网络状况分析包括以下分析内容：
网络收益分析：从通话时长分布、呼叫类型分布、呼叫地点分布进行分析。
包括
各个基站通话次数的比较分析。
各基站通话时长比较分析
各基站通话费用比较分析
各基站的时段/次数分布分析
各交换机的时段/次数分布分析
各基站业务量比较分类分析
网络用户分布分析
按地区分析
按时间分析
网络容量分析
网络容量分析主要包括以下内容：
按地区分析：分析不同交换区域网络分布情况
按时间分析：分析不同交换区域不同时间网络发展情况
可以根据以上分析的结果，预测以后网络的发展情况，据此为以后网络扩容提供依据。
热点小区分析
通过对呼叫详细记录的统计分析，从不同的角度（如通话指标、通话繁忙程度等）来划分热点小区，为制定相应的政策服务。
路由分析
路由分析是针对各话单中出入路由进行分析，分析它们与时间、地区等相应因素的关系，由此了解各出入路由的负载情况。
路由分析主要包括以下内容：
各出入路由通话时长比较分析
各出入路由通话费用比较分析
各路由的时段/次数分析
网络安全分析
对网络的安全状况进行分析，了解网络的。
错单分析
分析交换机原始话单的错单率，并以此为依据对交换机进行检查。
错单分析主要包括以下内容：
各种错单情况的损失费用比较分析
各个时间段的错单情况的比较分析
各种错单情况按交换机分类分析
业务收入分析
（一）业务收入分析
按收入种类、用户类型等分析收入的各类来源，帮助企业决策者分析，选择发展新的收入增长点。
业务收入分析可以分析业务收入与各种分类之间（如用户类型、地区分类、业务类型、付款方式等）的关系。包括以下内容：
业务收入分析：
可以分各种区间段分析用户收入，及各个区间段收入的分布情况。
各种收入结构分析：
包括基本费、频占费、基本通话费、通话附加费、国内漫游费、国际漫游费、国内长途费、国际长途费等。
各种业务收入分类分析
分析收入与用户类型的关系
可以分析不同的用户类型（性别、年龄、行业、消费层次、是否重要客户、是否大客户）的业务收入状况。
分析不同地区的业务收入状况
分析不同付款方式的业务收入状况
分析不同品牌的业务收入状况
分析不同业务类型（语音、承载业务、附加业务）的业务收入
（二）业务收入发展分析
可以分析业务收入的发展状况，并可以进一步根据历史的业务收入状况来作趋势预测。
业务收入发展状况分析
各种分类发展分析：
不同用户类型的业务收入发展分析；分析收入与用户类型的关系
不同地区的业务收入发展分析；
不同付款方式的业务收入发展分析
不同品牌的业务收入发展分析
不同业务类型的发展分析
销帐分析
1. 销帐结构分析
分析各种销帐状态（正常出帐、预缴话费销帐、立即销帐、正常销帐、银行垫支、欠费、反销帐、坏帐呆帐、欠费销帐）的分布情况。
2．各种销帐状态分类分析：
不同用户类型的销帐状况分析：分析销帐与用户类型的关系
不同地区的销帐状况分析
不同付款方式的销帐状况分析
欠费分析
欠费分析主要分析与欠费相关的因素，通过对用户的欠费金额、欠费时长、累计欠费金额与已缴话费比等相关数据，并与用户种类、地区、信用度、缴费方式、缴费习惯等资料相联系，分析欠费用户的特征，从而制定出相应的缴费策略，加速话费的回收，降低欠费率。
欠费分析主要主要包括以下内容：
欠费金额分析
分析欠费所占应收费用、已收费用的比例变化，以及不包括滞纳金后的欠费金额及其比例情况。
欠费户数分析
分析欠费户数及所占总户数、已缴费户数的比例变化，以及不包括滞纳金后的欠费户数的比例情况。
欠费周期分析：分析不包括呆帐的欠费周期
欠费金额分析：分析不包括呆帐的欠费金额
累计欠费比分析：分析累计欠费金额与已缴话费比的比例情况
累计欠费比的分类分析：
按时间分析：分析不同时间欠费用户的情况
按地区分布分析：分析欠费用户在各地区的分布情况
按用户类型分析：分析欠费用户的用户类型；
按信用度分析：分析欠费用户的信用度；
按缴费方式分析：分析欠费用户的缴费方式；
按新开户用户分析：分析新开户用户的缴费方式（现金、话费预寸款、银行待交、邮储划帐代交、工行划帐代交、银行托收等）
按品牌种类分析：分析各种业务品牌（全球通、大众通、模拟）的用户的欠费情况。
按号段分析：分析不同号段的用户的欠费情况
按预存/预付话费分析：分析欠费用户与预存/预付话费的关系。
按新开用户分析：分析新开户用户的欠费情况；
欠费回收分析
主要分析回收率、异地话费回收率、旧回收率、欠费日回收率、欠费停机客户率以及这些指标的分类分析。
高额/欺诈分析
通过对用户的通话费用以及高额话费的历史数据、用户欠费情况、用户信用度进行统计分析，分析高额用户的各种特征与趋势，区别正常高额与欺诈行为，分析出合适的高额话费界限，降低运营部门的风险。
高额分析：分析高额用户中合法用户的用户特征
呆帐分析：分析呆帐用户的用户特征；
欺诈分析：分析各种欺诈类别的用户特征；
费用分析：分析由于欺诈而导致无法收取的费用；
以及这些指标的分类分析：
按地区进行分析；
按用户类别进行分析；
按代理商进行分析；
结算统计分析
通过分析结算后的业务收入、运营收入，了解各种结算支出、结算后的收入占总收入的比率情况。
用户分析
根据用户的各种特征（如年龄、地区、性别等）对用户进行分析。
用户分析主要包括以下内容：
按地区进行用户分析
按年龄段进行用户分析
按性别进行分析
按付款方式进行分析
按在网时长进行用户分析
按帐单（发票）收取方式进行分析
大客户/重要客户分析
通过对大客户/重要客户的话费分析（包括费用、漫游特征、用户结构等），确定大客户的特征、行为，从而制定针对大客户/重要客户的优惠策略，并进行潜在大客户分析，吸收引导部分具备大客户特征的客户。
大客户分析
大客户是指拥有多部移动电话的单位或个人，有相同用户名或相同的付款帐号的移动电话群体，均可称之为大客户。但是有时大客户的消费金额并不多，分析大客户的各种特征，为其制定相应的措施，引导其消费，使之成为重要客户。
1．大客户资料管理：包括大客户资料的录入、存档管理等
2．大客户分析
大客户用户构成分析
大客户话费分析
大客户漫游分析
大客户话务流向分析
大客户通话习惯分析
潜在大客户分析
大客户向重要客户转化分析
大客户离网分析
大客户在网时长分析
大客户/普通用户比例分析
大客户信用度分析
大客户营销费用分析
以上指标的分类分析：
按时间分析
按地区分析
按品牌分析
重要客户分析
重要客户是指每月的消费金额超过一定数目的用户以及有相同用户名或相同的付款帐号的用户群。重要客户是移动业务收入的重要组成部分，他们人员虽然不多，但产生的业务收入比重较大。因此分析重要客户的各种特征，为其制定相应的方便、优惠措施，积极引导其消费，保证其客户忠诚度。
1．重要客户资料管理：包括重要客户资料的录入、存档管理等
2．重要客户分析
重要客户用户构成分析
重要客户话费分析
重要客户漫游分析
重要客户话务流向分析
重要客户通话习惯分析
潜在重要客户分析
重要客户向重要客户转化分析
重要客户离网分析
重要客户在网时长分析
重要客户/普通用户比例分析
重要客户信用度分析
重要客户营销费用分析
以上指标的分类分析：
按时间分析
按地区分析
按品牌分析
外来用户分析
外来用户是指从外地漫游来访的用户。对外来用户，特别是在某个特殊节假日对某特定场所外来用户的呼叫业务量、通话费用进行分析，可帮助决定是否在此场所进行网络改造或扩容，并进行相应的促销活动。
外来用户业务量（如通话次数、通话时长、通话费等）分析
外来用户话费收入及回收分析
模拟用户分析
模拟用户业务量（如通话次数、通话时长、通话费等）分析
模拟用户话费收入及回收分析
模拟用户离网情况分析
储值卡用户分析
储值卡用户包括神州行银卡、金卡以及其他尚未推出的业务种类。主要从业务量方面分析其对总的业务量和业务收入的影响以及此类用户的忠诚度（在网时间）。
储值卡用户分析主要包括以下内容：
储值卡用户业务量（如通话次数、通话时长、通话费等）分析
储值卡用户话费收入及回收分析
储值卡用户离网情况分析
储值卡用户号码保留期限分析
潜在用户分析
潜在入网用户分析
潜在离网用户分析
零次用户分析
对零次用户进行分析，以为制定相应的策略提供依据。
一户多卡用户分析
一户多卡用户是指同一用户名、同一身份证号码的用户。分析一户多卡用户的欠费、离网情况，可进一步了解用户的消费心理和消费习惯，特别是用户选择网、流动的特征。
一户多卡用户业务量（如通话次数、通话时长、通话费等）分析
一户多卡用户话费收入及回收分析
一户多卡用户离网情况分析
市场分析
市场占有率分析
客户发展情况分析
营业方式分析
通过营业方式了解各种营业方式（营业厅/代理商/网上营业/其它代理等）的特性与客户种类的变化和关系，各种营业方式对各种业务服务收入的贡献度和趋势，营业方式的业绩排名和信用风险分析。通过分析，了解各种营业方式的特性与业绩、话务量、客户租期、贡献度和风险程度之间的关系，发掘低风险和高利润的营业方式，作为发展业务的政策。
营业方式分析主要包含以下内容：
1．营业方式结构分析
各种营业方式的比较分析，比较各种营业方式所占业务总量的比重。
各种营业方式的开户分析；
各种营业方式的缴费分析；
各种营业方式的收入分析；
以及各种营业方式的分类分析：
按用户种类进行开户/缴费/收入分析
按地区进行用户开户/缴费/收入分析
2．营业方式发展分析
各种营业方式的发展分析，比较各种营业方式所占业务总量的比重变化情况。
各种营业方式的开户发展分析；
各种营业方式的缴费发展分析；
各种营业方式的收入发展分析；
以及各种营业方式的分类分析：
按用户种类（年龄、性别、性质等）进行开户/缴费/收入发展分析
按地区进行用户开户/缴费/收入发展分析
3. 营业厅结构分析
各营业厅的比较分析，比较各营业厅所占营业厅业务总量的比重。
营业厅结构分析主要包括以下内容：
各营业厅的开户分析；
各营业厅的缴费分析；
各营业厅的收入分析；
以及各营业厅的分类分析：
按用户种类（年龄、性别、性质等）进行开户/缴费/收入分析
按地区进行用户开户/缴费/收入分析
4．代理商结构分析
各代理商的比较分析，比较各代理商所占代理商业务总量的比重。
代理商结构分析主要包括以下内容：
各代理商的开户分析；
各代理商的缴费分析；
各代理商的收入分析；
以及各代理商的客户信用度分析：
5．其它代理结构分析
各其它代理（如银行）的比较分析，比较各其它代理所占其它代理业务总量的比重。
各其它代理的开户分析；
各其它代理的缴费分析；
各其它代理的收入分析；
以及各其它代理的分类分析：
按用户种类进行开户/缴费/收入分析
按地区进行用户开户/缴费/收入分析
按年龄进行用户开户/缴费/收入分析
按使用目的进行用户开户/缴费/收入分析
按月收入进行用户开户/缴费/收入分析
缴费分析
缴费分析主要包括以下内容：
1．缴费方式分析
分析用户的缴费方式（现金/托收/银行代收），从而决定是否增加/减少营业窗口、是否鼓励用户通过非现金方式缴费、是否增加联网的银行等；分析不同缴费方式所占比例；不同的缴费方式会影响话费回收的情况，通过对各种缴费方式的分析，业务部门可以引导不同的用户群体采用不同的缴费方式，以提高话费的回收。
缴费方式用户数分析；
缴费方式收入分析；
缴费方式的话费回收率分析
缴费方式的结构分析：
按用户类型（年龄、性别、性质等）进行用户数/缴费/收入分析
按地区进行用户数/缴费/收入分析
缴费时间（段）分析：
分析在每日缴费的用户数，以及在高峰缴费日各时段的缴费用户数；已决定是否增加新的营业厅，或是修改营业时间。
按用户种类进行缴费时间分析
按地区进行用户缴费时间分析
按年龄进行用户缴费时间分析
按使用目的进行用户缴费时间分析
按月收入进行用户缴费时间分析
缴费地点分析
分析每日不同营业场所的缴费情况（用户数、话费收入额），以了解缴费用户最集中的地点，以为营业厅的定点提供以及。
客服分析
投诉分析
针对不同的投诉情况进行分析，找出投诉的原因，以利于提高服务质量。
各种投诉类别的分类分析：
按地区进行投诉分析
按营业厅投诉情况分析
按营业员投诉分析
大投诉比例分析
电话咨询分析
电话业务受理分析
资源分析
对使用的各种资源进行分析（如手机、SIM卡、配件等）。
（一）仓库资源使用分析
1．SIM卡使用分析
按地区进行分析
按厂家进行分析
2．手机使用分析
按地区进行分析
按厂家进行分析
3．配件使用分析
按地区进行分析
按手机型号进行分析
（二）手机维修分析
按地区进行分析
按营业厅进行分析
按厂家进行分析
按手机型号进行分析
（三）手机销售分析
地区进行分析
按营业厅进行分析
按厂家进行分析
按用户类别进行分析
按手机型号进行分析
（四）号码资源分析
按地区进行分析
按号段进行分析
业务受理分析
对用户与业务受理之间关系的分析
用户选择业务种类分析，分析各种业务种类所占比重
以及业务受理的分类分析。
按地区进行业务受理分析
按营业厅进行业务受理分析
按营业员进行业务受理分析
促销分析模块
当今各电信运营商，为了开拓市场，使用各种促销手段如特定时间段的打折优惠、资费包的选择等等。但是如何来评价某种促销手段的贡献?如何选择适当的促销方式更有利于市场的竞争?促销分析就是满足用户这种潜在需求的决策支持工程。
广告分析
广告成本分析
促销成本分析
用户满意度分析
用户调查资料管理
用户满意度分析
竞争分析
（一）与各竞争对手竞争分析（联通、CDMA）
对于各竞争对手，我们可以从用户通话号码中进行总结分析，根据每月的竞争对手的用户号码进行分析，可以得到竞争对手的用户发展趋势，了解各竞争对手的发展情况，以便制定各种竞争措施。
（二）各竞争对手的用户发展分析。
各竞争对手的市场营销分析。
与各省竞争分析
与各市县竞争分析
综合决策分析模块
综合决策分析模块是把各种分析结合起来对主要关键值进行综合决策。
1．业务量综合决策
对影响业务量的各项因素进行综合评估，决定发展业务量的主导因素。影响业务量的发展因素有：地区分布、业务分布、资费措施、用户结构等。
2．业务收入综合决策
对影响业务收入的各项因素进行综合评估，决定发展业务收入的主导因素。影响业务收入的发展因素有：地区分布、业务分布、资费措施、用户结构、收费方式、欠费等。
3．用户发展综合决策
对影响用户发展的各项因素进行综合评估，决定发展用户发展的主导因素。影响用户发展的发展因素有：地区分布、资费措施、用户结构、广告宣传、新业务、竞争等。
新业务分析
电信运营商采用一些新技术，开通一些新业务，如短消息、WAP等，也是吸引用户的一种手段。对新业务进行有效的评估，判断新业务带来的效益，是衡量一项新业务推出是否成功的标准。
1．新业务的评估
评估新业务对电信运营商带来的经济效益，可以从评估中获得新业务主要的发展方向、对象，从而指导市场部门对新业务进行针对性的宣传。
新业务对通话次数的影响
新业务对通话时长的影响
新业务对通话费用的影响
新业务对用户发展的影响
新业务对手机销售的影响（主要是指与新业务相关的手机，如WAP手机等）
新业务的发展分析
以及这些指标的分类分析：
按地区进行分类
按用户类型进行分类
按用户年龄进行分类
按用户月收入进行分类
按用户使用目的进行分类
2．新业务预测
通过因新业务使得用户发展或业务量发展而获得的收益进行分析，来预测新业务给电信运营商带来的经济效益，可以从预测中获得新业务主要的发展方向、对象、带来的经济效益，模拟运行，从而保证新业务能够顺利实施。
预测新业务对通话次数的影响
预测新业务对通话时长的影响
预测新业务对通话费用的影响
预测新业务对用户发展的影响
预测新业务对手机销售的影响（主要是指与新业务相关的手机，如WAP手机等）
预测新业务的发展分析
以及预测这些指标的分类分析：
按地区进行分类
按用户类型进行分类
按用户年龄进行分类
按用户月收入进行分类
按用户使用目的进行分类
此功能建议在适当时机采用SAS软件进行深层次分析及预测实现，详见附录。
3.新业务的宣传渠道分析
分析各种渠道影响用户接受和使用新业务的情况，寻找出最佳宣传渠道。
4．WAP业务分析
WAP是电信新业务，可以对该新业务进行以下的分析：
时段分析
时长分析
新增用户分析
URL分析
报表及即席查询系统
在系统中，不同的用户类只看到与他们有关的信息，采取严格的用户权限和等级控制，系统的安全性有充分的保障。用户利用分析和报表的功能获得他们所需的信息，而不会失去对信息、数据完整性、系统性能和系统安全的控制。
使用Cognos的Impromptu报表制作工具，可以根据用户的业务逻辑，组织客户需要的基本元素（数据库已有数据及其汇总后的数据），从而形成报表制作的基本构件，在此基础上用户可以任意组合，制作出自己需要的报表。
复合报表通过用各种不同的形式（交叉表、图表、表格或以上几种形式的组合来表现分析结果，对工作进行概括。同时还可以用优美的格式来展示商用报表 。用户可以将报表结果存成 HTML 超文本文件，从而通过浏览器查看或打印。
另外，还可以利用摸板，创建邮件标签和‘套用信函’。邮件标签是一套框架，每一个框架都包含，利用系统数据库中客户的信息，自动、快速地制作信函封面或者、内容。这样的报表能够快速而轻松地打印基于数据库中顾客信息的邮件标签。
即席查询模块
利用本报表系统，可以在报表中定制过滤条件、提示项等。这样，在生成报表时，用户就可以临时指定数据筛选条件。例如，可以建立两个为报表中的数据指定时间日期的区间提示：
“请输入开始日期：”
“请输入终止日期：”
这样，报表就仅仅输出用户要求的日期范围以内的报表数据。
另外，本报表系统还可以指定在特定的时间和日期运行报表、程序和宏。例如，
每个月自动运行一次报表集合的宏语句，生成需要的报表，然后将这些报表发送给一组用户。
创建统计分析应用的策略及原则
统计分析系统是一个非常重要的系统，直接影响到运营商的业务开发策略，AICBS对此提供了DSS级别的考虑与支持，以最强大的统计分析功能支持BOSS系统。并作好了向决策支持系统DSS平滑过渡的准备。
移动通信运营商最高领导层的领导及支持
确定清晰的业务需求
基于现有的操作型业务系统
定义目标体系结构
分析现有系统与目标间的差距
制定开发策略
原型的开发和认证
实施策略
系统结构建设投资
技能培训投资
构建数据仓库
开发实施分析工具
用户培训
依据新技术，改进业务处理流程和调整组织结构
系统投入运行
持续不断地改进
网间结算模块
亚信AICBS网间结算模块为一个相对独立的网间结算系统产品（AIICCS）构成，具有非常灵活、高效的网间结算功能。主要特色如下：
表驱动设计，结算标准及起用时间可以自由设定。
除了支持必须的结算报表外，系统还支持结算分析报告，如与上一结算周期各种结算费用的比较分析，平均单价、同一周期参与结算的话务流量、业务收入占总量的比例等等。同时，系统还支持从网间结算的数据中，按要求灵活统计分析出竞争者的用户情况和话务情况。
系统在保证结算结果的正确性及一致性基础上，对于漫游结算除了满足集团公司的相应上报和下发规范外，对来访漫游结算中，稽核结算金额与产生的来访文件中应结金额完全一致；在出访漫游结算中，结算金额与扣除错误后的出访文件应结金额完全一致。
网间结算的功能结构
如图所示，网间结算系统包含了下列功能模块：
图 结算流程
系统结算范围：
国际漫游结算。
与国内其他电信运营公司结算 。
省间漫游结算。
省间长途结算。
省内漫游结算。
省内长途结算。
梦网结算。
代收费结算。
数据采集系统
数据采集系统从交换机上采集原始话单，并通过数据传输系统传输到计费结算中心，为数据的后续处理准备数据。
数据采集系统支持TCP/IP、MTP、FTAM、HDLC、等多种采集协议，从而保证了良好的兼容性。数据采集系统具备断点续传功能和较好的容错能力，能够保持采集的实时性和准确性。
话单预处理系统
话单预处理系统从交换机采集的原始话单中提取用于计费和统计的信息，并从二进制格式转换为文本格式。由于现在国内使用的交换机品种繁多，而且各种交换机厂商所提供的原始通话话单格式也有较大的不同。如果直接由计费程序对各种不同的交换机原始话单进行计费处理，就会造成计费程序与交换机相联系，对计费程序的修改和升级造成不利影响。因此预处理格式转换根据原始数据格式的不同（不同交换机、不同业务）采取不同的转换程序。
随着业务的不断增加，转换程序必须适应新的格式标准。为此，系统采用内部统一格式，所有从交换机下载的原始话单数据以及其它计费装置提供的原始话单都首先被转换为内部格式，然后经由格式检查、错误纠正、话单计费等工序，最后再将内部格式根据不同的转换为不同输出格式。
采用内部统一格式使得格式的变更或增加不会引起应用程序较大的修改，最多只需要修改转换程序，而不必对应用程序中的其它模块做改动。系统内部格式一方面综合了不同格式之间的共同点，使得转换之后的各模块的公用成为可能；另一方面，该内部格式也应保持原有格式的部分特点，使得在后期转换时仍能够保持原有的信息量。
话单批价及结算系统
话单批价及结算系统对格式化后的话单进行各项费用的计算，由于计费与结算功能是整个网间结算系统的核心部分，其实现的准确性、安全性、高效性直接关系网间结算系统的整体表现，所以话单批价及结算系统也体现了设计者的诸多考虑和技巧。
话单批价及结算系统具备非常强的规范性和灵活性：
在尽量短的时间内适应计费原则、计费标准、结算策略的更新，以及其它资源的改变（例如，新增交换机、IMSI码段的变更等）；
对结算规则采用公式化描述，如(T-(140*D))+E 表示将长话费按每分钟元自留，剩下的长话费给对方，并且长话附加费全给对方。
结算对象可任意扩充，保证在新增运营商时不用修改源代码即可完成结算功能的扩充。
一条话单的结算次数可允许最多达到三次
系统的回调（call back）功能，使得计费和结算资料的改变立即体现在话单的计费和结算过程中；
由于对结算策略采用参数化和公式化管理，网间结算系统具有很强的描述性和很强的灵活性。
话单入库系统
话单批价及结算后形成的结算话单按照话单类型、归属局的不同，被放置在不同的目录下不同的文件中。系统定时将这些具有特定格式的文件插入到数据库中，同时利用数据库表上索引检查重复话单。
话单入库模块由服务器端和客户端构成，服务器端长期驻留在内存中，客户端定时搜索指定的目录下是否有新的已计费话单文件。每当发现新的计费文件，客户端便将话单文件拆分，并发送给服务器端，由服务器端完成话单的入库操作。
统计分析系统
统计分析子系统提取网间结算详单表中的数据，形成各种中间数据，为前台快速形成报表打下坚实基础，统计分析子系统提供的中间结果也为决策支持系统提供信息。
统计分析子系统的功能包括对各业务区、各结算运营商、各种漫游类型、各种呼叫类型、各种长话类型、各种对端类型的各种费用（通话费用和结算费用）进行归类统计。
操作员管理和维护系统
网间结算系统维护模块完成如下功能
操作员和权限管理
可管理多个操作员
可管理多种权限
对口令和权限同时进行加密处理
系统配置参数管理
管理缺省数据库和表的设置
管理计费起始日和其他相关参数
操作日志的查询和管理
查询某操作员在某段时间的某种类型的历史操作记录
资源管理系统
资源管理系统用于维护和管理各种计费规则、计费标准、结算策略，以及其它用于维护系统正常运行所必须的参数，包括：
国际费率及相关参数表（国际运营商表、国际长途费率表等）；
国内费率及相关参数表（如全国城市表、国内长途费率表、全国交换机代码表）；
省内相关参数表（如路由表、C3表、基站表等）；
优惠资费管理表；
系统信息表
网间结算策略表和运营商表
统计报表系统
统计报表系统为运营商提供各种统计和结算报表。亚信的AIICCS提供给用户一个非常实用的自动报表生成系统，用户可以通过该系统自由定制各种风格的报表。
自动报表生成系统为用户提供一个集可视化报表设计、调试、打印、转Excel于一体的报表生成环境。用户设计的报表可以象系统提供的固定报表一样使用。事实上，系统提供的大部分固定报表都可以利用自动报表生成系统来设计。
自动报表生成系统生成的报表为表格式，可根据数据量的大小自动打印多页并自动打印页码。报表的首页由报表题头、统计日期、打印日期、列题头和数据组成。报表的其它页由列题头和数据组成。在报表的式样中，下列内容可由用户修改：
报表的纸张类型。如A4、A3、B4、B5等所有操作系统提供的纸张样式；以及用户自定义的纸张样式（纸张宽度和纸长）；
报表的左边界、右边界、上边界、下边界、打印方向（横向和纵向）；
报表的题头和题头的字体、题头的高度；报表的题头可合并、分裂
标识数据列的列题头、列题头高度、每一列的宽度；
数据列每一列的打印对齐类型。对齐类型可分为左对齐、右对齐、居中；列题头为居中打印。
可任意增加的标签
网间结算系统的技术特点
AIICCS产品具有下列技术特点：
高效数据处理能力
AIICCS系统可完成大容量数据的实时处理。既可以将大批量的数据集中起来一个月处理一次，也可以每天定时处理这些数据；
AIICCS系统采用应用数据分割 + 数据库分区技术，从而使系统具有高度并行处理能力，充分利用主机CPU、内存资源以及磁盘阵列的I/O资源；
AIICCS系统采用多进程／多线程处理技术，从而使系统具备分布式的处理能力，也可进一步提高系统处理的速度。
数据库优化设计
数据库是应用系统中数据交互最频繁的部分，如何保证数据库在任何情况下都能够保持较高的吞吐能力，是我们解决问题的第一个出发点，综合以往的经验和全国中心计费结算系统的要求，我们的首选解决方案是数据库分表技术。
话单的入库是整个计费结算系统中最耗费时间的部分，为保证结算系统的整体性能，合理地设计数据库和表的结构是至关重要的。为此，我们按照以下的原则实现数据库详单表的划分：
按照手机号码段划分表，号码段的划分要与各省、自治区、直辖市所分配的码段保持一致；
按照时间划分表；
大的省份按照号码段进行更细级别的分区。
必要时，也可以按照漫游类型来进行划分。
按照上述原则，系统可选择如下具体的分表标准：
日期：不同天的话单被插入到不同的天表中；
归属省：不同归属省的话单被放置到不同的表中；
手机号码段：按照手机号码中的某些位划分表。
这些标准被存储在系统参数表中，系统读取这些标准定时创建或删除相应的表。按照以上原则，每个话单表的表名可能具有如下的形式：
XX省话单： CDR_XX00_19990120；
按照以上标准划分表，使每个表所存储的话单数减少，从而提高数据的插入、查询、读取的速度，并进一步提高系统整体的效率。同时，系统将不同的表分配在不同的物理设备上，在进行数据入库或数据统计时，采用多进程并行操作，使入库和统计的速度大大提高。此外，对这些表的维护并不需要用户的干预，系统将自动完成。
虽然数据库本身也提供了自动分区的功能，例如自动根据手机号码分区，但与手工分区相结合，将会使系统具有更多优点：
手工分区完全考虑到应用中的要求，它的分区使得对数据库的操作能更有效地分配到不同的进程或线程，从而最大限度地保证负载的均衡；
手工分区的原则保存在数据库的表中，用户可以根据不同时间业务量的不同，合理地修改分区原则。例如，对新增加的号码段，用户只需要在表中增加或修改表中的记录即可；
手工分区具有更大的灵活性，它允许用户从多种分区原则中选择一种或多种原则的组合，而形成对业务数据处理最有效的方式；同时手工分区使得不同详单表中的记录数尽可能相近。而相比之下，数据库的自动分区能够提供给用户的选择较少，只能在表中部分字段附加分区原则。
此外，系统的各个部分在处理过程中，也充分考虑手工分区的原则，在很大程度上，进一步提高了系统的整体处理速度。
结算规则参数化和公式化
结算规则的管理和维护是体现网间结算系统设计的最重要的部分。AIICCS系统结算规则的管理和维护的特点表现在：
多项参数参与结算：基本通话费/漫游费、长话费、长话附加费、本地网费、总费用、通话时长、通话次数均可参与结算；
通配符和组合性：通配符和组合功能使得一条规则能描述多种情况的组合，从而使结算公式达到最少；
优先级：使永远能满足特例的要求，只需将特例要求的优先级提高；
结算规则的公式化：采用公式来描述结算规则，如：(T - (140*D)) + E表示将长话费按每分钟元自留，剩下的长话费给对方，并且长话附加费全给对方；
多参数：充分考虑影响结算的各种因素如话单类型、主被叫类型、长话类型、漫游类型、路由类型、结算地区、对端地区，他们之中的任何一个或几个因素的组合都可以参与单一结算公式的指定；
客户化的维护界面设计：美观简便的操作界面，用户只需要用鼠标操作就可完成绝大多数的功能。
多方和多次结算
AIICCS系统允许多个运营商对同一条话单进行多次结算。在AIICCS系统中，一条话单允许结算三次。实际上，有接近45%的话单不许要参与结算。在参与结算的话单中绝大多数的话单只需要结算一次，极少数话单需要结算两次。
AIICCS系统中结算的运营商可以任意扩展，我们通过网间结算运营商表来管理参与结算的对象。
一条话单支持最多结算三次，每次可定义不同的结算对象和不同的结算公式，而且每次结算的收费方和付费方可不同。
可维护性和可扩展性
AIICCS系统的设计充分考虑到未来的结算需求，它的整体设计思想的灵活性保证了它在将来增加新功能时只需要改变系统参数表中的参数和规则即可，而且在总体设计中，我们始终坚持模块化和面向对象的设计思想，这使系统具有良好的可维护性和可扩展性。
通过上述设计方法，AIICCS达到了理想的性能指标。AIICCS系统容量和处理能力完全能够满足千万级用户的业务要求。
系统监控模块
BOSS系统监控模块EagleSight概述
亚信公司为BOSS系统定制的监控模块EagleSight提供的主要功能是监控BOSS应用软件系统的运行情况。
多数应用软件系统的核心程序运行在UNIX平台，对维护人员来讲，完全属于黑箱操作，无法得知其运行状况，要判断其运行是否有异常产生，往往要进行复杂的人工操作，并且运行错误也很难及时发现。通用监控系统则可以对应用软件系统的运行情况进行实时监控并对其运行情况做出统计。EagleSight是独立的软件系统，并配套提供所有亚信公司开发的应用软件的代理模块。
总体设计思想
可靠性
任何一个系统设计的前提都是可靠性，特别是7*24小时运行的关键性的任务。基于这种思想设计的系统要求它首先具有良好的可追溯性、良好的结构以及可预见的输入输出。因此，在进行设计的时候，需尽量保证监控系统基本结构的简单，实现核心部分和非核心部分充分分离，核心部分也尽量模块化，减少各模块之间的耦合性。
灵活性
对监控系统而言，灵活性意味着在不改变系统结构（或尽量小地改变系统结构）的情况下方便地实现功能的扩充或删减。例如，增加一种消息类别，增加一个运行实例等，增加一些外挂的扩充功能等。
调试能力
调试能力是经常容易被忽视的。事实上，可调试能力非常重要，在不影响系统性能的前提下，增加程序的调试能力可以在不直接去现场的情况下快速的查找原因，也便于工程维护人员在系统出现异常时可辅助分析原因，尝试解决问题。事实上，我们很多工程问题的解决都是通过分析应用程序日志而得到解决的。
实时性
监控系统要求对各代理程序和各应用程序发出的监控消息可尽量快速到达监控服务系统，但一般来说，这种实时性远可以商量，到底响应时间为多少合适，没有硬性的规定，一般要求在5分钟以内。监控系统同时也要考虑在大容量数据下的处理能力，虽然一般来说通过其他途径可限制监控系统的信息量。
各应用程序尤其应该注意，发送大量的监控信息是无意义的，这些监控信息会很快淹没其他有用的信息，造成监控系统部分无法使用。所以，应该严格限制应用程序发送大量重复的告警信息（如处理一个文件发几十万条告警信息），取而代之的应是，每处理完一个文件，发送一个汇总的告警信息。
例如：
计费入库程序在进行入库，可能它会发现某些表没有创建，那么，每一条话单都发送一条这个表没有创建的告警信息是没有必要的，如果有必要，可以在这个文件处理完毕，发送一些汇总性的告警信息，有哪些表没有创建，每一个没有创建的表一条告警信息（告警信息中包含有多少条话单引发这条告警信息）。
批价：
有些HLR找不到，可以在处理一个文件的过程中对每一个HLR进行计数，在该文件处理完毕，对每个HLR发送一条汇总性的告警信息，告知有多少条话单属于这个HLR找不到的错误。
Eagle Sight总体结构
系统必须实现对应用软件系统的各模块进行监控，并且对这些模块的监控是可拆卸、重组的。另外，也可以对系统的磁盘、进程、用户、系统日志、数据库、网络链路状况等进行监控。其技术特点如下：
通用性：可监控各种应用系统，同时对系统中普遍关注的部分，如磁盘、进程、系统日志、数据库、网络链路状况等实现监控。
灵活性：可自由加载、扩充被监控对象。
接口的标准化：对不同的操作系统、以及不同的应用，使用统一的接口。
稳定性：监控系统运行情况、配置参数的更新，以及监控系统的替换都不影响被监控软件系统的正常运行。
高性能、可靠性：监控消息的处理速度不低于50条/秒，另外，杜绝由于链路情况、进程挂死导致监控消息丢失，有效剔除重复数据。
实时告警，在链路正常的情况下监控消息5分钟以内到达监控服务器。
告警信息的有效性。
前台操作的简便性。
快速的响应能力，指前台的消息刷新速度。
多种告警方式，如电话、Email等。
功能结构
一个完整的监控系统主要由以下功能模块组成：
监控代理
包括应用程序监控信息代理模块、进程监控代理模块、磁盘监控代理模块、系统日志监控代理模块、数据库监控代理模块、链路监控代理。
消息传输
包括消息发送模块、消息接收模块。
监控消息分捡、处理、入库
包括对各种监控消息分类、将不同类别的信息入到不同的表中、以及告警升级、超时检测、传输速率检测、序号连续性检测等消息处理模块。
前台
包括进程消息显示模块、主机消息显示模块、监控告警模块、监控统计报表模块、监控配置管理模块。
监控代理模块
作为监控软件的代理模块(Agent)，向监控管理端(Manager)提供代理端主机的系统信息（处理器，内存，磁盘，进程，登录用户,各应用程序运行，数据库）状态，在监测到有越界状态时则向管理端报警；代理端也可接受来至管理端的控制命令。代理端的监测进程作为守护进程，需要常驻系统中，这部分模块将跑在被监控的机器上。它包含以下几个模块：
应用程序监控代理
应用程序使用监控代理接口，并按照规定的监控错误代码定义、格式，向传输模块发送消息。监控信息的发送情况，应不影响被监控应用本身的运行。
进程监控代理模块
检查进程的运行状态。该在运行的没有运行或没有定时启动的进程，都要发告警信息。
磁盘监控代理模块
发送磁盘的占用率信息。超过上限时，发告警信息。
系统日志监控代理模块
扫描操作系统日志，发送告警信息。
数据库监控代理模块
监控数据库设备和日志，发送告警信息。
链路测试代理
定时测试链路是否畅通。监控指定机器集的链路情况。如发现异常，产生一条告警信息，并将此信息入库。
消息传输
这部分模块将监控信息从各代理机器传送到监控服务器上。
监控消息发送模块
接收各代理发送过来的监控消息，发送给监控消息接收模块。采用同步和异步并行的发送方式。发生阻塞时，先将监控数据存盘。待阻塞消除后，优先发送高级别的消息。
监控消息接收模块
接收监控消息，并将信息传送给分捡模块。发生阻塞时，先将监控数据存盘。待阻塞消除后，优先传送高优先级的消息。
消息分拣、处理、入库子系统
监控信息分捡模块
根据事先的设定，将消息分类。对于需要进行特殊处理的消息，发送给消息处理模块。否则，发送给入库模块。
监控消息处理模块
根据各应用的实际需要，处理信息，然后入库。例如采集数据处理在收到采集监控消息后，分解出采集名称和采集文件序号和生成时间，判断序号连续性。当发现序号不连续时，产生一条告警信息，并将它入到数据库中。
监控消息处理模块目前包括监控告警升级、超时检测、采集序号连续性检测、下发文件处理序号连续性检测、传输速率检测等。
监控消息入库模块
接收到监控消息后，进行消息分解，最后根据消息类型，入到实时告警数据库或日志数据库的相应表中。
前台子系统
这是与用户直接交互部分，包括：
进程消息显示模块
实时显示各机器各模块的运行状态。
主机消息显示模块
以图标形式显示各主机的监控告警情况。
监控消息统计报表模块
生成监控信息统计报表。
配置管理模块
管理监控系统的各种配置表。
消息告警模块
将告警信息的通过电话/Email发送出去。
监控信息管理子系统
监控信息管理子系统实时显示应用系统中的各个重要模块的监控信息，同时也对系统的磁盘、进程和非法用户等进行实时显示监控，并在30秒后定期刷新。
主机监控管理子系统
监控系统对应用系统中指定的单个主机或主机群进行重要信息的监控，这些信息包括高级别事件的发生的最新时间、发生次数以及其他信息。
前台实时告警子系统
监控前台实时告警系统对应用系统中的各个重要模块所产生的告警消息用电话、Email或声音的方式通知用户，并在用户设定的时间内刷新记录、发送消息。
前台报表查询子系统
监控前台报表查询系统对应用中的各个重要应用有条件的查询，例如移动计费系统中的采集、传输、预处理、批价、入库、出库、部中心和统计等，同时也对系统的磁盘、进程和非法用户等进行查询显示并可以打印。
资源配置管理子系统
资源配置管理子系统对监控系统用到的各种资源配置表进行管理，使得监控系统能够方便、快捷地得以配置，从而系统能够正确、方便地运行。
监测系统功能结构
监控系统的功能结构如下图所示，其各部分的具体功能在下面详细阐述。
监控代理
监控代理执行在被检测的机器上，实现对磁盘剩余空间，进程存在状态，系统日志状态的检测，在发现有不正常现象时告警。
监控代理系统的功能主要为物理资源监测、进程检测、系统日志监测。
物理资源监测，检测物理资源的消耗情况，若剩余资源小于设置的阀值，则告警。可以设两个级别的阀值。
进程检测对用户关心的进程监测其运行状态，进程是否存在，不存在，则告警。可以设置每个进程的个数和参数。
系统日志检测查看系统日志文件，若文件中有用户关心的事件发生，则告警。可以是多个文件，每个文件可以有不同的关键字。
监控代理接口
监控代理接口供各系统向监控系统发送监控信息使用，所有通过此监控代理接口的程序都会被监控系统监控。
整个接口按功能分为两个部分,参数设置模块和参数发送模块。
监控代理接口程序在内存中有一个含有参数值的缓冲区，参数设置模块将更新这些参数的值，在调用参数发送函数之前，一直有效。在调用参数发送函数之后，缓冲区的数据将清空。
参数发送模块将含有参数值的缓冲区的数据整合起来，形成一条监控信息，然后发送到监控代理守护进程。
如果代理接口程序没有初始化或需要重新初始化(如配置文件内容更新),程序将自动初始化。
数据库监控代理
数据库监控代理检测数据库SERVER：是否连接正常。如不正常，发告警信息。
并同时监控关键进程（如对于ORACLE：PMON、DBWO、LGWR、CKPT、SMON、RECO）是否在运行。如果不在，发告警信息。
注：在后台进程跟踪文件中发现严重错误记录时，发告警信息。该功能可由系统日志代理实现。
另外还可以检测数据库剩余空间：如果被监控数据库的剩余空间比例（或大小）小于阀值，发告警信息；如果被监控数据库的日志空间比例（或大小）小于阀值，发告警信息。
链路测试模块
将待测试的ip地址load到内存。
ping目标地址。
对ping的结果进行分析，并发告警：
当链路状态发生改变（由连接正常转成断开，或由断开转成连接正常）时，发告警消息。
对于链路断开，且需要发告警的情况，需找到第一个断开点的地址（如，在某个路由器断开）。
当链路断开状态持续一段时间（如1天）后，发告警信息。
该模块需长驻内存，并用sleep的形式调整扫描间隔。
监控代理守护进程
监控代理守护进程向监控系统数据服务器发送监控信息，其具体功能为：
准确无误接收监控代理接口发来的监控数据,然后传送到监控数据服务器。
将监控代理接口保存的监控数据文件的监控数据传送到监控数据服务器。
将向监控数据服务器发送监控数据时遭遇阻塞时的监控数据文件中的监控数据发送到监控数据服务器。
整个进程按功能分为两个部分,监控数据接收模块和监控数据发送模块。
监控数据接收模块负责从消息队列中读取监控代理接口传送过来的监控数据。
监控数据发送模块负责发送来自以下几处的监控数据：监控数据接收模块，监控代理接口保存的监控数据文件，监控数据发送遭遇阻塞后保存的监控数据文件。
监控数据发送模块必须判断监控是否完整地传送到监控数据服务器。判断方法：接收到返回到的数据，此数据为监控数据服务器本次接收到的监控数据字节数。
监控数据接收守护进程
监控数据接收进程运行于监控数据服务器上，负责接收监控代理机器上监控代理守护进程发送过来的监控信息，并且传送到监控数据分拣程序。其功能为：
准确无误接收监控代理守护进程发送来的监控数据,判明发送机器地址，合成新的监控数据，然后传送到监控数据分拣进程。
在向监控数据分拣程序发送监控数据遭遇阻塞时，监控数据将被保存到文件中,待阻塞故障排除后，再将监控数据重新发送到分拣程序。
整个进程按功能分为两个部分,监控数据接收模块和监控数据发送模块。
监控数据接收模块负责从socket中读取监控代理守护进程传送过来的监控数据，并且从socket返回读到的字节数。。
监控数据发送模块负责发送来自以下几处的监控数据：监控数据接收模块，因发送阻塞保存的监控数据文件。
监控数据发送模块必须判断数据分拣守护进程是否就绪，以及消息队列是否阻塞，判断是否可以传送数据。当不能传输数据时，监控数据存盘。
监控消息分拣守护进程
消息分拣守护进程从监控数据接收守护进程接收监控信息，根据要求分发到其他处理进程。其功能为：
准确无误接收数据传输接收守护进程发送的监控数据，并将接收到的监控数据根据要求发送到其他守护进程。
整个进程按功能分为两个部分,监控数据接收模块和监控数据分发模块。
监控数据接收模块负责从消息队列中读取监控传输接收守护进程传送过来的监控数据。
监控数据分发模块负责将监控数据发往其他监控数据处理模块：监控数据入库模块，监控数据特殊处理模块等。
监控消息入库守护进程
消息入库守护进程从监控数据分拣守护进程接收监控信息，录入日志数据库中，同时经过过滤后，定时录入实时数据库中。其功能为：
准确无误地从监控数据分拣守护进程读取监控数据。
将读取到的监控数据根据分解的配置参数分解后录入日志数据库中。
将读取到的监控数据进行过滤后，保存在内存中。
定期将保存在内存中的过滤后的监控数据录入到实时数据库中。
整个进程按功能分为三个部分,监控数据接收分解模块和日志入库模块及消息过滤及实时入库模块。
监控数据接收分解模块负责从socket中读取监控分拣守护进程传送过来的监控数据,并将各个关键字分解开来。
日志入库模块负责将监控数据录入日志数据库。
消息过滤及实时入库模块将监控数据过滤后，保存在内存中，定时写入实时数据库中。
消息数据错误响应进程
消息数据错误响应进程从监控数据库中找出需要响应的监控信息，根据具体设定执行远程命令。
监控系统任务管理模块
监控系统中的任务管理模块实现后台进程维护和管理。
对于在后台运行的指定进程，如果用户关心该进程的运行状态，一般都需要在后台运行ps命令来查看进程的运行情况。这种操作对于用户来说并不方便，尤其是用户所关心的进程的数量为数较多的情况下，关心这些进程运行状态的工作就显得繁琐而难于统一管理。
虽然Windows有自己专门的任务管理器，但是她只监视本机上运行的进程，并且她会罗列出所有的进程而无法突出你想要关心的进程，这对于特定进程的关心者来说，任务管理器并不方便。
如果能够提供通用的后台任务管理软件，这将会极大地方便用户进行快速、准确而灵活地监视自己所关心的进程。甚至可以操作其他主机上的进程，重新启动或将其杀死。从监控的角度来说，不仅可以及时的关注应用的运行情况，而且能加强应用的远程控制维护能力。
任务管理模块可帮助维护管理人员管理不同机器上运行的各种任务，定时启动和停止某些进程。整个程序按功能分为两个部分,任务管理服务器(任务定时执行及检测部分)和任务管理界面(任务配置、任务手工管理及状态显示部分)。其具体功能描述如下：
从前台执行后台的程序。（可以考虑使用 rexec端口，或者自行开发服务程序）
从前台停止后台的程序。（执行后台kill命令，要求给出pid及是否使用SIGKILL信号）
判断常驻进程是否存在，判断依据：关键字，其中可用%date[+|-M][+|-D]%代表指定日期(执行后台ps命令，注意system V格式和BSD格式)。+|-M代表本月的后或前几个月，+|-D代表本日的后或前几日。注意date为关键字，代表当天日期。
任务碰撞检测：检测给定的几台机器某一任务的实例的总个数是否满足要求，如果不满足，按照优先级别启动或停止后台进程。
任务的定时调度
执行方式：常驻，每天，每周第X天，每月第X天。从1开始，负数为倒数。
有效时间段：起始时间，终止时间。
任务执行情况：是否正在执行，是否已终止。
任务执行日志：管理任务调度的执行日志。
运行机制：一台机器上管理所有机器的任务。
任务管理模块的前台界面。
任务状态：执行状况。
任务配置：配置任务。（配置好的任务并非一定要执行，可以设置是否有效状态，譬如某台机器上的某个进程被暂停执行几天应当不需要删配置）（可以对某些属性进行批量设置，譬如不同机器上的统计它们的执行时间等配置是相同的，或者以时间为序编排任务。）
任务操作：执行或停止任务。
任务日志：浏览，查询，管理日志。
任务特性：任务的执行时间，所占CPU,内存
任务管理模块的操作人员权限管理
给操作员赋权限包括任务的增，删，该，执行，查看日志等，一般操作方式是选定某个操作员，将相应的权限赋给他，但由于任务是可以增加的，所以是否应提供一个选定权限，将它赋给多个操作员的操作。任务被删掉时的操作员权限处理。
后台检测到的异常状况可以根据设定传送到监控系统。
系统数据结构
整个监控系统以监控系统数据库为信息流的中枢。
各个监控代理，含监控信息的应用程序，以及通用检测程序通过信息发送模块发送监控信息。监控系统服务器上的信息接收模块收到监控消息后，经过消息分捡，然后将消息存入数据库中。
各个监控告警程序、统计程序、前台程序都是以数据库上的监控数据作为数据来源的。
监控系统涉及到的数据包括：配置数据、实时告警信息、日志信息。它们都将储存在数据库中，以便由前台统一管理、查询。三种数据可采用同一个数据库，也可采用不同的数据库。 监控系统以数据库为核心。
配置数据库
主要存放监控系统的配置及维护信息。
实时数据库
在这个数据库中主要储存从当前时刻起的一段时间内的告警信息。这些信息是前台的告警显示的来源，并在用户干预后改变状态。这部分数据需要定期（如3天）备份，以备统计。
数据库的特点如下：
数据量小：
实时告警数据以每天最多1万条，保存三天计，存储量为3万条。
响应速度快：
由于是实时告警，所以无论是入库速度，还是查询速度（前台查询的依据）、修改记录的速度都有较高的要求。
数据删改频繁。
为保证数据库的响应速度，需不断删除过期告警信息。同时每一次发出的告警，都可能改变告警的级别。
实时数据库包含两张表，即实时告警信息表和实时运行信息表。实时告警表包含所有告警级别不为0的告警消息，实时运行信息表包含所有告警级别为0的运行信息。
在实时数据库中，告警信息可能是经过压缩的，这种压缩主要针对那种大量的重复的告警信息，告警信息的压缩在入库时完成，要求告警信息的压缩功能做成可选项，即可以使用配置文件中的开关决定是否使用告警信息的压缩处理。
如果告警信息无压缩，则实时数据库具备完整的剔重能力。如果告警信息有压缩，则实时数据库不具备剔重能力。一方面，监控系统不象计费系统，主要考虑告警的功能和性能，在实时数据库中剔重能力并不重要，另一方面，监控系统出现重单的概率很小。监控系统之所以出现重单，主要是业务流程比较复杂，要求精确，任何一个环节出现错误，就要求重复处理，这种情况在监控系统不存在。
监控系统的精确性可由日志数据库保证。
日志数据库
所有的监控数据都会录入此数据库中，入库后，不再删改，只做统计、查询用。
日志数据库具备完全的剔除重单能力和追溯能力，所以日志数据库中的数据可以用来做统计和分析。
Eagle Sight网络结构图
海南BOSS监控管理
海南移动三期BOSS扩容工程的监控管理，将采用多种监控产品和手段，实现系统监控。
其中，Eagle Sight主要应用于亚信AICBS应用软件相关的系统监控上，在本期系统建设中，我们还推荐了另外两个监控软件，HP OPENVIEW NNM主要应用于主机网络节点的管理和监控，CISCO WORKS2000主要应用于网络设备的监控，从而海南三期BOSS工程的系统监控将是一个全面、细致、可靠的BOSS监控系统。
服务器的监控
海南移动三期BOSS扩容工程组成系统各个部分包括采集、批价、帐务、营业等等系统运行环境中的所有服务器都在监控之列。服务器的监控内容包括磁盘监控、内存监控、CPU监控等物理资源的监控，数据库、系统日志的监控以及服务器上进程的监控等。实现的方法为：由EagleSight在各服务器上的相相应代理依据事先设定的阀值和监控内容，实时扫描服务器的运行情况，并实时上传异常信息至监控服务器，并触发实时告警。
应用系统的监控
应用系统的程序运行情况的监控由EagleSight的应用进程监控代理实现。在业务支撑系统各部分中每一个被监控的进程都内嵌一个监控的API，可实时将进程自身的运行信息输出到监控代理，由代理负责将信息发往监控服务器，由服务器对信息进行分拣和分析，入库或触发告警。
采集系统的监控
海南移动采集系统采用亚信公司的采集产品。硬件平台为SUN Ultra5/10,操作系统为Solaris。亚信采集产品的程序中已内嵌监控API，可直接实现监控。监控的内容包括：
实时显示每个采集进程的运行状况，对每个采集机包括：采集机名称，交换机名称，
最新的采集文件，采集时间，采集错误名称（如果有）。
采集故障显示：实时显示采集故障，包括超时检测产生的故障和采集文件序号检测产生的故障。
系统故障及处理：进程，磁盘等监控及故障的响应交由前台实时告警子系统来完成
报表处理：产生故障及运行的统计报表。
批价系统的监控
批价应用的特点是几乎所有进程皆为实时运行，所以系统进程的实时运行状态为监控重点。目前批价系统本身已开发一个针对预处理、批价、漫游文件处理等进程的监控界面，在本次集中监控的建设中，将定义一个统一的数据接口，将批价系统各程序的运行信息同时输出到集中监控系统，进行统一的告警管理。该系统应用程序的监控内容包括：
预处理部分
实时显示每个预处理进程的运行状况，对每个预处理进程包括：实例名称，交换机名称，最新的处理文件，处理时间，预处理错误名称（如果有），有效话单，可计费错单，不可计费错单，其他话单。
预处理故障显示：实时显示预处理故障，包括超时检测产生的故障和及文件延时检测产生的故障（需要新增加文件延时检测代理）。
系统故障及处理：进程，磁盘，传输等监控及故障的响应交由前台实时告警子系统来完成
报表处理：产生故障及运行的统计报表。
批价部分
实时显示每个批价进程的运行状况，对每个批价进程包括：实例名称，交换机名称，最新的处理文件，处理时间，批价错误名称（如果有），有效话单，可计费错单，不可计费错单，重单，其他话单。
批价故障显示：实时显示批价故障，包括超时检测产生的故障。
系统故障及处理：进程，磁盘，传输等监控及故障的响应交由前台实时告警子系统来完成
报表处理：产生故障及运行的统计报表。
漫游文件处理包括 部中心下发和出库
实时显示每个漫游文件处理进程的运行状况，对每个漫游文件处理进程包括：实例名称，最新的处理文件，处理时间，漫游文件处理错误名称（如果有），有效话单，无效话单。
漫游文件处理故障显示：实时显示漫游文件处理故障，包括超时检测产生的故障，时间与序号检测产生的故障。
系统故障及处理：进程，磁盘，传输等监控及故障的响应交由前台实时告警子系统来完成
报表处理：产生故障及运行的统计报表。
帐务系统的监控
帐务应用的特点是实时运行进程少，大多数进程为定时周期性运行，所以监控重点在于进程运行的准时和准确性。目前帐务系统有部分监控功能，可将程序的运行信息输出，关键是约定一个统一的数据传输格式。该系统应用程序的监控内容包括：
实时显示每个帐务处理进程的运行状况，对每个帐务处理进程包括：实例名称
处理时间，帐务处理错误名称（如果有）。
帐务处理故障显示：实时显示帐务处理故障，包括超时检测产生的故障，数据库操作的故障。
系统故障及处理：进程，磁盘，传输,数据库等监控及故障的响应交由前台实时告警子系统来完成
报表处理：产生故障及运行的统计报表。
营业系统的监控
营业受理应用的特点是系统的外部接口多，数据库连接多为随机性，同时业务高峰集中在出帐后的缴费期内。该应用的监控重点为业务峰值期的数据库负载情况，各外部接口的畅通情况等等。目前系统尚不具备监控功能，需在原程序中开发监控代理。
客服系统的监控
监控的内容包括三方面：接入及转换（IVR），话务分配（CTI），应用（CICS）。其中IVR和CTI的运行情况现有系统已配备专用软件进行监控，本次建设的内容是确定两系统之间的数据接口，以及告警内容的确定。亚信的监控系统充分考虑了各客服系统的特点，具有良好的客服监控接口。
缴费系统的监控
缴费系统的监控主要为数据库状态、进程运行状态、以及中间件的监控。
多样实用的告警输出
监控系统的实时告警窗口的数据可以同步发送到大的数字显示屏上。
需要调用数字显示屏生产厂家提供的一个动态连接库，名称为。它提供了下述两个接口：
ScreenEnable(long nCode) 激活或关闭数字显示屏
ScreenTextOut(COLORREF Color,long x,long y,LPCSTR lpText)在数字显示屏上在指定位置用给定的颜色显示字符串。
这样系统的告警信息都可根据告警程度及预先的定义，实时显示在大数字屏幕上，使得系统及网络的当前运行状态一目了然。
另外系统还可根据应用的需求情况定义声音、电话、mail、短信等多种告警方式。
不同级别的告警可通过定义不同的声音加以区别告警。
可通过跨接电话平台，将告警通过电话发送到指定的维护人员。
可利用已建成的客服系统中的模拟中继线将定义好的告警信息发送给相应的维护人员。
也可将一些特定的告警信息或系统运行的实时报告实时发送到特定的信箱。
另外，系统的三层结构设计（Agent－Server－Client），可支持多个Client端，只要在网络可达的终端上，都可运行系统客户端，这样不仅支持多人不同地域同时监控系统运行，而且可解决人员移动办公的需要。
通过这些手段，可突破系统维护在地域上的限制，解决机房分散造成的维护人员人手紧张，故障响应滞后等问题。实现全面的远程掌控系统，在一个地方就可以实时的掌握全部系统及网络运行的当前状态，最及时的发现系统故障和故障趋势，真正做到主动控制系统的运行。
系统配置建议
由于本系统的代理程序都运行在被监控的服务器和设备上，故本系统需配备的设备主要为一台监控服务器（监控数据库服务器）。推荐配置为2CPU/2G内存/40G硬盘的服务器。因为监控的负载相对来说较小，如现有应用的设备负载不满，也可与之共用设备。
外围系统
AICBS系统还提供了一些辅助系统，以提高系统的安全性、可靠性和易维护性。这些辅助系统包括：自动停开机系统、监控子系统、稽核子系统、日志管理、任务管理、配置管理、数据传输、数据装载、数据分发、数据处理、数据管理等模块或子系统。、
自动停开机系统ASOG
亚信的自动停开机系统有下面几个模块组成：
通信接口模块（ASOGCOM）
业务命令生成模块（ASOC）
业务命令自动处理模块（ASOA）
营业数据库接口模块（RQS）
日志记录和管理模块（ASOGLOG）
调度和冗余管理模块（ASOGHA）
通信接口模块（ASOGCOM）
ASOG提供到不同的移动通信系统的联结方式，通过独立的通信接口模块ASOGCOM，屏蔽网络协议的差异，使ASOG系统与移动通信网络设备之间的通信好像使用普通的进程通信机制IPC（Inter Process Communication）一样简单。针对不同的交换机/HLR接口，我们只要提供相应的ASOGCOM模块及正确的配置文件，就能够建立ASOA到交换机/HLR虚拟的IPC消息通道。对于大部分交换机/HLR来说，RS-232或协议通信已能满足要求，并且不同种类的交换机/HLR服务接口只要使用相同的通信协议，它们的通信接口模块是完全一样的，这使得通信模块的开发和维护变得非常简单。
业务命令处理模块（ASOA）和业务命令生成模块（ASOC）
ASOC提供了一组功能，实现将移动通信计费系统发出的请求转变成ASO命令，转交给相关的ASOA，并且记录执行结果，通常我们选择数据库作为移动计费网和ASOG之间的接口。ASOC的工作原理如图所示：
ASOC 运行在自动用户服务请求服务器（RQS，ReQuest Server）上，该服务器负责汇总来自所辖营业区域的移动计费系统发出的所有用户服务请求，存放在数据库的“自动用户服务命令表”中（详见附件1）。抽象的自动用户服务命令作为请求的主要部分，由各个发出请求的模块（如前台营业、统计、反欺诈）根据抽象命令语法产生，用户服务请求入库时被分配了唯一的请求ID号。由于服务器所辖的营业区域内可能存在多个交换机用户服务命令接口，ASOC要根据“号码资源-交换机映射表”为每个请求确定对应的ASOA的ID号。
营业数据库接口模块（RQS）和抽象服务命令（ASO）
RQS并不一定是独立的数据库服务器设备，它可以是专门配置的自动用户服务请求数据库服务器，也可以安装在其它数据库服务器中，以独立的表的形式存在。RQS主要提供数据服务功能以及ASOC的运行环境，RSQ包括了两个主要的数据表：“自动用户服务请求提交表”和“号码资源-交换机映射表”。“自动用户服务请求提交表”用于记录本营业区内近期所有的请求内容，包括：请求ID号、自动用户服务命令、请求者、请求时间、完成时间、返回代码等等，由于服务请求发生十分频繁，该表应该定期清理，将已经完成的请求记录进行备份，然后清除。“号码资源-交换机映射表”用于帮助ASOC进行服务接口选择，确定请求数据的传输方向，记录中包括：号码段描述、接口（ASOA）ID号等内容。
ASO遵循亚信公司抽象移动用户服务命令语法ASOS（Abstract Subscriber Order Syntax，详见附件2），将移动用户和服务属性封装成为抽象的类，这个类应该能够覆盖目前所有的服务选项，由于类的实现完全基于具体的交换机接口，所以它的定义和方法是虚拟的，有赖于ASOA的设计。对于今后可能产生的系统扩展，我们只要修改ASOS的定义和ASOA的实现代码，就能够方便地扩展类和方法的定义。
日志记录和管理模块（ASOGLOG）
ASOG系统日志包括两个部分：一个是保存在“自动用户服务请求提交表”中的记录，它们详细记录了来自业务系统的业务命令，包括请求者代码、ASO命令、提交时间、完成时间、命令优先级、命令完成状态、错误返回代码等内容。另一个是ASOA执行过程中生成的HLR操作轨迹文件，它详细记录了每条ASO命令对应的HLR指令组及其执行过程，以便管理维护人员对ASOG系统的执行情况进行跟踪，及时发现问题。通过这两部分的日志记录内容，能够对ASOG系统进行性能统计和安全核查，为系统的性能优化和故障检查提供直观可靠的数据。
日志记录和管理模块还能够提供管理界面查询已提交的ASO的状态，如果发现有未执行成功的ASO命令，可以将它们的状态修改为“未执行”，提交ASOG系统重新进行尝试。这一功能使管理人员能够对由于系统中断（通常由于HLR或交换机端口或链路故障引起）而导致的业务命令失败及时进行补救。
调度和冗余管理模块（ASOGHA）
为保证ASOG系统的高可用性能（High Availability），我们可以选择使用ASOG双机备份以及到交换机/HLR的冗余通信链路，ASOG双机和冗余电路的调度和管理通过ASOGHA模块实现。
ASOGHA模块同时支持双（多）机备份方式和双（多）链路冗余方式以及它们的组合，即我们既可以在一台ASOG设备上使用多条冗余电路实现链路级的冗余，也可以在多台ASOG设备上通过多条到交换机/HLR的通信链路实现系统一级的冗余。在ASOG双机冗余方案种，ASOGHA模块将ASOG双机定义成为主-从工作方式，ASOG双机到交换机/HLR之间的物理链路均处于活动状态，但只有主ASOG设备到交换机/HLR之间的对话活动，从属ASOG设备只是定时测试到交换机/HLR的对话能否正常建立，如果建立对话失败，将产生告警提示信息。当ASOGHA模块检测到主ASOG设备出现故障，无法继续执行业务命令时，立即将从ASOG设备设置为当前活动的状态，将主ASOG设备未完成的业务请求以及后续的业务请求发送到从ASOG设备上执行，同时产生告警信息，通知维护人员检查系统故障。故障排除后，通过ASOGHA的复位功能回复故障前的主从关系或保持现状，直至下一次故障发生再进行反向切换。
查询系统
话单查询/报表模块提供给用户完备的界面，根据用户输入的各种条件查询/输出结果。用户输入的条件可以组合，以实现复杂的查询。系统利用数据库高效的并行处理和数据库的优化和分区，对数据库进行快速、准确的查询，从而可以满足用户的不同需求。查询包括：
话单查询：查询原始话单、已计费话单、错误话单，对已计费话单的查询，应当可以在界面上准确定位到该条话单所对应的原始话单文件，以便对原始话单文件进行查询，可以在用户发生话单纠纷等原因时提供原始话单文件进行技术分析；
用户详单查询：用户可以通过查询界面查询自己的详单，对于采用网上自助方式进行的话单查询，需要用户输入相应的用户名、口令，查询自己的详单、帐单等。
结算数据查询：查询同其它电信网间的结算数据；
统计结果查询：查询与业务相关的各种统计数据；
资料查询：查询用户信息、各种资费标准、优惠率，以及为维护系统正常运行的资料（例如号码段、省会长途区号等）；
系统包括对本系统内各级管理部门提供的查询服务和对外部用户提供的查询服务。
话单转发
话单转发系统将已计费的话单中的漫游来访话单从数据库中提取出来，按照规定的格式形成文件，并将这些文件放置在总部清算中心设置在各省、市、省的通信服务器上。
话单转发过程中的关键因素是：如何记录数据库表中那些话单已经处理完，那些话单还未被处理。为保证话单分发的效率和实时性，系统采用如下的方式：
在入库的过程中，利用数据库本身的功能对每条记录附加唯一的标号，该标号根据入库的顺序严格递增，并且不因记录的修改或删除而改变；
每次从表中提取记录时，记录本次过程中标号的最大值；
下次提取时，只提取那些标号 > 上次标号最大值的记录；
话单转发的流程如下图所示：
与全国移动电话计费结算中心进行交互的话单文件格式，以全国移动电话计费结算中心及相关部门制订的标准为依据。
自动报表生成系统
自动报表生成系统为用户提供一个集设计、调试、预览、打印、转Excel于一体的报表生成环境。用户设计的报表可以象系统提供的固定报表一样使用。事实上，系统提供的大部分固定报表都可以利用自动报表生成系统来设计。
自动报表生成系统生成的报表为表格式，可根据数据量的大小自动打印多页并自动打印页码。报表的首页由报表题头、统计日期、打印日期、列题头和数据组成。报表的其它页由列题头和数据组成。在报表的式样中，下列内容可由用户修改：
报表的纸张类型。如A4、A3、B4、B5等所有操作系统提供的纸张样式；
以及用户自定义的纸张样式（纸张宽度和纸长）；
报表的左边界、右边界、上边界、下边界、打印方向（横向和纵向）；
报表的题头和题头的字体、题头的高度；
标识数据列的列题头、列题头高度、每一列的宽度；
数据列每一列的打印对齐类型。对齐类型可分为左对齐、右对齐、居中；
列题头为居中打印。
高额话单检测系统
如果在规定的时间段内，同一用户的通话费用之和大于规定的金额，则称该用户为高额用户；该用户在上述时间段内产生的话单为高额话单；对检查到的高额用户，以及对应的高额话单，形成具有规定格式的高额报告。
高额话单检测系统在规定时间内，检查高额话单，并按照规定的格式生成高额话单报告。
高额话单统计对实时性要求较强，为保证能在尽短的时间内对高额话单做出反应，并生成高额报告。目前系统采用定时统计的方法。该方法将高额统计同话单入库完全分离开来，即定时对某一时间段内所有话单按照手机号码码分类进行费用统计。因为插入与查询/统计可能会在同一时间对同一表进行操作，这种方法对入库速度有一定程度的影响。
采用这种方法需要根据系统的运行状态，决定两次统计之间的时间间隔，以避免统计对话单的入库产生较大的影响。时间间隔作为参数存储在参数库中，用户可以根据需要随时修改。也可以通过判断数据库的负荷状态，在系统处于非忙碌状态时进行高额统计，例如在深夜或凌晨等时段。
安全性管理
对整个计费系统而言，安全性管理是整个系统中非常重要的组成部分。亚信公司的集中式计费系统提供了比较完善的安全性管理机制。
我们对操作员权限的管理采用数据库的权限管理+亚信的权限管理的双重保护机制。在数据库的权限问题上，通过对计费系统的分析，将数据库中的详单表和各种中间结果表进行归类，设置各种角色，分别具有不同的读、写、删除的权限，这些权限以
