探究和实现融合计费账务系统的架构与关键功能
最编程
2024-01-21 16:12:59
...
2006年初,融合计费账务系统的发展趋势及其重要性已得到业界的广泛关注,各电信运营商及开发商也开始了相应的讨论、研究和规划,北京联通(原北京网通)在业务和网络的发展驱动下,率先开始了融合计费账务系统的规划与建设,真正建设一个统一支撑大客户、商务客户和公众客户所有客户群,统一支撑北京联通电话、宽带、小灵通、互联网、专线及CP/SP业务等全业务及其灵活捆绑与组合营销,统一支撑在线计费和离线计费,统一支撑预付费和后付费的融合计费账务系统。本文对北京联通融合计费账务系统架构与核心功能的研究与实现进行了介绍,希望对业界融合计费账务系统的建设和发展有所借鉴。
融合计费关键概念研究
业界对融合计费账务系统在概念上具有基本一致的认识,即融合计费账务系统需要实现四个方面的融合:客户的融合,即客户品牌与付费方式的融合;业务的融合,即实现跨业务、跨产品、跨客户的产品捆绑、交叉优惠,实现业务经营与计费策略的完整衔接;计费方式的融合,即在线计费与离线计费的融合;付费方式的融合,即预付费和后付费的融合。
但是,在计费方式与付费方式的关系、付费方式是针对用户类型还是产品属性等相关概念上存在一定的混淆,还需要进行进一步的分析与研究。
在线计费与预付费的关系
在线计费中的“在线”是针对客户通信服务过程而言的,即在客户享受通信服务过程的同时进行计费,而预付费、准预付费与后付费则是不同的付费方式。在线计费是一种在线消息计费,可以实现实时计费、实时信控、实时扣费,并参与到通信服务过程中进行实时的会话控制,所以在线计费可以实现对预付费方式的支撑。同时,在线计费系统在计费方式方面,除了要支持在线消息计费,为了保证异常情况下计费的完整性、准确性,也需要支持CDR计费,因此,在线计费系统在可以支持的付费方式方面,除了可以实现对预付费业务计费账务处理的支撑,同样也可以实现对后付费业务计费账务处理的支撑。
三种计费方式的关系
计费账务处理过程可以细分为鉴权、会话控制、计费、信控、扣款和累账等关键动作,通过对这些关键动作进行分析和研究,我们可以更清楚地看出在线计费、离线计费与融合计费三种计费方式之间的关系,也可以更清楚地看出其与预付费、准预付费、后付费三种付费方式之间的关系,如表所示。
通过动作矩阵我们可以看出,在线计费与离线计费的差异主要在于是否进行实时鉴权和会话控制,而预付费与后付费的差异主要在于是否进行实时扣款,实现了在线计费与离线计费融合的融合计费账务系统则可以实现各种情况下的完整的计费账务处理支撑。
客户、账户、产品(服务实例)与付费方式的关系
目前,在客户关系管理系统、计费账务系统中预付费、后付费普遍作为不同的客户类型在客户级或账户级进行严格的区分,后付费、准预付费客户在计费账务系统实现计费账务处理,预付费客户在网络智能平台或在线计费系统实现计费处理,在计费账务系统实现账务处理。
而在融合计费账务系统中,预付费和后付费在客户级、账户级不再有明显界限,它只是基于产品、账目的一种属性,而不是划分客户群的标准。
客户拥有的一部分产品是预付费的,一部分产品是后付费的,客户可以通过统一的账户同时为这些预付费产品和后付费产品进行费用支付。
客户拥有一个后付费产品,而这个产品附加的某一增值产品(运营商自有的增值产品、智能业务或者合作伙伴SP/CP的产品等)则是预付费的,客户同样可以通过统一的账户同时为这些预付费产品和后付费产品进行费用支付。
融合计费账务系统架构研究
系统按照业务逻辑划分为三层:接入层、核心业务层、数据层。
系统使用内存数据库技术、J2EE、构件技术等,内存数据库保存余额、累计量、累账数据、资料信息等计费相关信息以提高实时处理的速度。系统技术架构、功能架构如图1和图2。
融合计费账务系统核心处理流程研究
融合计费账务系统的核心处理流程需要实现统一计费引擎批价、统一账务处理、统一收费处理,如图3所示。
在线计费和离线计费的处理主要区别在于在线计费需要授权和认证,需要对其进行会话管理(图3的绿色部分),而离线计费一般为对话单文件的计费处理(图3的粉色部分)。
对于预付费和后付费业务的处理区别是预付费业务会进行实时扣款,其它处理和后付费基本一致。
融合计费账务系统核心功能研究
融合计费账务系统需要实现统一的产品和资费管理、统一的客户资料管理、统一的账户和余额管理、统一的账务处理、统一的收费管理等,从而可以实现对预付后付业务提供统一的产品、资费和服务,支持支付关系的灵活设置,支持跨预付、后付的全业务组合营销,而其核心技术主要在于统一计费引擎、统一账户管理和计费控制(如图4所示)。
统一计费引擎
系统采用规则引擎技术建立统一的计费引擎,通过规则定义屏蔽各类计费数据和参考数据的差异,实现通过统一的计费引擎进行在线、离线批价处理。
支持计费对象可配置:按主叫计费、按被叫计费、按第三方号码计费、按计费号码计费等。
支持众多计费因子,并可扩充:客户属性、账户属性、主叫号码特征、被叫号码特征、主叫区域、被叫区域、呼叫范围、呼叫距离、用户组、时段、接入点、接入范围、承载业务等等。
资费条件可配置:资费因子组合成资费条件,资费条件有优先级。
资费计算支持直线和分段折线费率等(封顶、保底、打折、X+Y方式的包月、跳档),并且资费计算公式分为标准资费公式和实收资费公式。
批价处理资费还支持产生赠送处理(包括业务量或金额)、优惠处理(包括优惠条件基于累计业务量、累计金额优惠,优惠算法、分段打折)。
支持大量的针对特殊客户的定制资费。
支持跨月话单晚到分段资费用户的准确计费。
统一账户管理
统一账户管理,预付和后付属性设置在产品级,因此预付后付可以在同一个账户中实现。支持以下业务模式。
●同一账户下预付后付的综合,比如账户下A电话是预付、B电话是后付、C宽带是预付、D手机是后付。
●同一设备下不同产品可以是预付后付的综合,比如A电话的市话是后付、长途是预付。
●多个客户的某些科目可以对应一个账户,如某单位的客户,其市话和月租统一由单位账户支付,长途则由个人账户支付。
●一个账户下支持多个子账户(余额账本)等。
计费控制
基于事件的计费控制:对于短信等事件业务采取先锁后扣模式。
基于会话的计费控制。
●普通会话的计费控制:对于通话等业务基于会话进行计费控制,按照Dcc协议的控制流程,分片申请和锁定余额,在余额不够时,授予能够使用的业务量。
●强拆类会话的计费控制:业务开始时申请鉴权,计费系统进行鉴权,计费系统根据业务类型,授予一定业务量(一般为时间),针对不同的业务、不同的用户可授予不同的业务量,如:套餐用户拨打市话,可以授予较大一个时长,普通用户拨打市话授予3分钟时长。用户余额不够,主动发起强拆消息终止业务。
●分级会话的计费控制:对于声讯业务,一次拨打声讯台,可以分按键选择多个声讯业务,系统按照主会话和子会话分别管理,子会话会关联主会话同时进行控制和管理。
基于文件的计费控制:由接口模块发送计费消息,对预付费业务进行计费、优惠、扣费、累账处理,对后付费业务不需扣费,只需计费、优惠、累账处理。
基于合账的计费控制:对于一些业务已经完成批价只需合账,计费控制模块需要对此业务进行扣费、累账处理。
基于周期费的计费控制:周期费由账务模块生成周期费文件,由计费控制模块进行扣费和累帐处理。
融合计费账务系统的实现
在业务和网络的发展驱动下,根据对融合计费账务系统的研究和规划,北京联通(原北京网通)采用了分步实施的建设方案,进行了融合计费账务支撑系统(IBS)的建设。经过这些年的分步建设,IBS系统已经建设成为一个统一支撑所有客户群、统一支撑全业务及其灵活捆绑与组合营销、统一支撑在线计费和离线计费、统一支撑预付费和后付费的融合计费账务系统,能够很好地满足业务发展的需求。目前已承载客户1350万、账户1500万、服务实例2300万,覆盖了固话、宽带、小灵通、互联网、基础数据、网元出租、ICT、广告传媒产品等8大类117种产品,实现了对91个基本产品、380个增值产品、34类跨业务的套餐、3974个资费计划的计费账务处理,平均市话话单每天约3000万张,长话话单每天200万张,ADSL话单每天450万张,实时消息处理1000CAPS,缴费业务并发数20笔/s,每月的出账时间约为3~4小时。
北京联通融合计费账务支撑系统(IBS)的建设过程分为三个阶段。
第一阶段是2002~2006年:分别建设多业务集中计费账务系统(IBS)、小灵通在线计费系统(OCS)。
第二阶段是2006~2008年:融合小灵通在线计费系统(OCS),进行融合计费账务系统(IBS)的建设,以实现在线计费和离线计费的融合,实现对CP/SP业务、小灵通业务及原来由SCP承载的预付费电话、预付费ADSL业务的融合,真正实现多业务融合、多客户融合、预付费后付费融合。
第三阶段是2008~2009年:进一步进行业务的提升和扩展,更好地支撑融合业务,实现对固移融合业务、预付费捆绑套餐、预付费和后付费交叉捆绑业务的支撑。
融合计费账务系统的发展展望
通过对融合计费账务系统的研究我们可以发现,在线计费离线计费融合、预付费后付费融合的核心是统一,其计费的绝大部分处理过程是相同的,这从技术上保障了融合计费的可行性,北京联通融合计费账务系统(IBS)的成功建设也充分证明了这一点。
对于全业务电信运营商而言,在功能上跨预付后付固移语音、数据及增值业务的融合业务会不断产生,同时,统一客户服务和客户感知、客户主动控制消费需求、细粒度的设置付费方式等适应全业务运营的需求也会相应产生,全面融合的业务需求必将迫使各运营商进行融合计费账务系统的建设。另外,针对全业务价值链的优化与整合,融合计费账务系统也大大增加了对CP/SP合作伙伴的支持,可以吸引更多的CP/SP,为电信运营商、CP/SP、客户创造更多的价值,因此,融合计费账务系统的建设必将成为各电信运营商的必然选择。
转载自:http://market.c114.net/220/a469618.html
上一篇: DIY 云端收费解决方案
推荐阅读
-
openEuler郑州用户组成立!openEuler与hyperfusion携手共建河南地区用户生态 - 开幕致辞 超融合操作系统业务总经理、openEuler委员会成员蒋振华先生为本次活动致辞。 在本次活动的致辞中,他提到,作为openEuler社区早期的成员,超融合见证了openEuler从成立到在各行业商业落地,再到跨越生态拐点的过程,感谢openEuler提供了一个全产业链共同创新的平台,共同推动创新技术的商业落地。 同时,本次活动得到了郑州市郑东新区大数据管理局、郑州中原科技城投资服务局的大力支持。 郑东新区大数据管理局曹光远 在活动致辞中表示,openEuler的应用和*应用设施的深度优化,为郑东新区数字化转型提供了安全、可靠、高性能的技术基础;郑州中原科技城招商服务局王林表示,郑东新区欢迎所有openEuler生态相关企业扎根当地,围绕openEuler社区共同发展,形成合力。 openEuler社区及运维功能介绍 openEuler技术委员会委员胡峰 openEuler技术委员会委员胡峰先生在本次活动中介绍了openEuler社区目前发展的整体情况,并重点从技术层面介绍了openEuler的运维功能。 openEuler 晚会 胡峰先生介绍智能运维工具 A-Ops 和 openEuler gala、 阿波罗 Apollo、智能漏洞管理解决方案等新功能,以及涵盖各种运维场景的精品运维组件。在*交流环节,许多用户就目前使用的 openEuler 在*交流环节,许多用户就自己在使用openEuler过程中遇到的一些问题与胡峰先生进行了进一步的交流。 软硬结合,构建多样化算力操作系统 Hyperfusion 基于 openEuler 的基础上,结合自身软硬件技术积累,推出了富讯服务器操作系统 FusionOS FusionOS. FusionOS 首席架构师张海亮 分享了 FusionOS FusionOS首席架构师张海亮分享了FusionOS的软硬件协同优势、卓越的性能和可靠性,以及FusionOS在金融、运营商、*、互联网等行业的实践案例,引起了众多用户的兴趣,分享结束后,不少参会者就FusionOS的特点向讲师提问并进行了交流。
-
实时音频和视频技术的发展与应用-1.1 双重音频和视频 从架构上看,双人音视频系统相对简单明了。红点代表房间信令服务,房间信令服务的主要功能是管理房间信息,实现容量协商和上下行链路的质量调节,例如当下行信道发生拥塞时,上行线路的码率和分辨率会降低。 在传输信道层面,我们的策略是优先直连,在跨区域、跨运营商的情况下,我们会选择单中转或双中转信道,在策略上尽量保持直连和中转信道同时存在,当其中一个信道的质量不好时,系统会自动切断到另一个信道的流量。 1.2 多人音视频 多人视频通话的产品形态是整个房间不超过 50 人,大盘平均房间规模约为 4.x 人,房间内部最多满足一个大视频和三个小视频(四屏)。根据这一条件,我们在架构中采用了典型的 SFU 小房间设计。 上图中的红点代表房间信令服务,主要用于房间管理和状态信息同步。房间管理主要包括用户列表的管理,例如哪些用户打开了视频/音频,我看了谁,谁看了我,这些都是基于房间管理的信息,然后房间信令服务会将这些信息同步到媒体传输服务进行数据分发。 房间服务的另一个作用是房间级容量协商和质量控制,例如,房间里的每个人一开始都支持 H.265 编码,当某个时刻进来一个只支持 H.264 编码的用户时,房间里所有的上游主播就必须把 H.265 切成 H.264。还有一种情况是,房间里有一定比例的人下行链路信道质量较差,这会导致上行链路房间质量下降。 在传输层面,我们采用的是单层分布式媒体传输网络,大家都选择中转方式,不区分双人和多人,采用 Full-Mesh 传输机制将所有数据推送过去,比如一个节点上的人并不都看另外两个人的视频,但还是会将视频推送给他们。
-
windows下进程间通信的(13种方法)-摘 要 本文讨论了进程间通信与应用程序间通信的含义及相应的实现技术,并对这些技术的原理、特性等进行了深入的分析和比较。 ---- 关键词 信号 管道 消息队列 共享存储段 信号灯 远程过程调用 Socket套接字 MQSeries 1 引言 ---- 进程间通信的主要目的是实现同一计算机系统内部的相互协作的进程之间的数据共享与信息交换,由于这些进程处于同一软件和硬件环境下,利用操作系统提供的的编程接口,用户可以方便地在程序中实现这种通信;应用程序间通信的主要目的是实现不同计算机系统中的相互协作的应用程序之间的数据共享与信息交换,由于应用程序分别运行在不同计算机系统中,它们之间要通过网络之间的协议才能实现数据共享与信息交换。进程间通信和应用程序间通信及相应的实现技术有许多相同之处,也各有自己的特色。即使是同一类型的通信也有多种的实现方法,以适应不同情况的需要。 ---- 为了充分认识和掌握这两种通信及相应的实现技术,本文将就以下几个方面对这两种通信进行深入的讨论:问题的由来、解决问题的策略和方法、每种方法的工作原理和实现、每种实现方法的特点和适用的范围等。 2 进程间的通信及其实现技术 ---- 用户提交给计算机的任务最终都是通过一个个的进程来完成的。在一组并发进程中的任何两个进程之间,如果都不存在公共变量,则称该组进程为不相交的。在不相交的进程组中,每个进程都独立于其它进程,它的运行环境与顺序程序一样,而且它的运行环境也不为别的进程所改变。运行的结果是确定的,不会发生与时间相关的错误。 ---- 但是,在实际中,并发进程的各个进程之间并不是完全互相独立的,它们之间往往存在着相互制约的关系。进程之间的相互制约关系表现为两种方式: ---- (1) 间接相互制约:共享CPU ---- (2) 直接相互制约:竞争和协作 ---- 竞争——进程对共享资源的竞争。为保证进程互斥地访问共享资源,各进程必须互斥地进入各自的临界段。 ---- 协作——进程之间交换数据。为完成一个共同任务而同时运行的一组进程称为同组进程,它们之间必须交换数据,以达到协作完成任务的目的,交换数据可以通知对方可以做某事或者委托对方做某事。 ---- 共享CPU问题由操作系统的进程调度来实现,进程间的竞争和协作由进程间的通信来完成。进程间的通信一般由操作系统提供编程接口,由程序员在程序中实现。UNIX在这个方面可以说最具特色,它提供了一整套进程间的数据共享与信息交换的处理方法——进程通信机制(IPC)。因此,我们就以UNIX为例来分析进程间通信的各种实现技术。 ---- 在UNIX中,文件(File)、信号(Signal)、无名管道(Unnamed Pipes)、有名管道(FIFOs)是传统IPC功能;新的IPC功能包括消息队列(Message queues)、共享存储段(Shared memory segment)和信号灯(Semapores)。 ---- (1) 信号 ---- 信号机制是UNIX为进程中断处理而设置的。它只是一组预定义的值,因此不能用于信息交换,仅用于进程中断控制。例如在发生浮点错、非法内存访问、执行无效指令、某些按键(如ctrl-c、del等)等都会产生一个信号,操作系统就会调用有关的系统调用或用户定义的处理过程来处理。 ---- 信号处理的系统调用是signal,调用形式是: ---- signal(signalno,action) ---- 其中,signalno是规定信号编号的值,action指明当特定的信号发生时所执行的动作。 ---- (2) 无名管道和有名管道 ---- 无名管道实际上是内存中的一个临时存储区,它由系统安全控制,并且独立于创建它的进程的内存区。管道对数据采用先进先出方式管理,并严格按顺序操作,例如不能对管道进行搜索,管道中的信息只能读一次。 ---- 无名管道只能用于两个相互协作的进程之间的通信,并且访问无名管道的进程必须有共同的祖先。 ---- 系统提供了许多标准管道库函数,如: pipe——打开一个可以读写的管道; close——关闭相应的管道; read——从管道中读取字符; write——向管道中写入字符; ---- 有名管道的操作和无名管道类似,不同的地方在于使用有名管道的进程不需要具有共同的祖先,其它进程,只要知道该管道的名字,就可以访问它。管道非常适合进程之间快速交换信息。 ---- (3) 消息队列(MQ) ---- 消息队列是内存中独立于生成它的进程的一段存储区,一旦创建消息队列,任何进程,只要具有正确的的访问权限,都可以访问消息队列,消息队列非常适合于在进程间交换短信息。 ---- 消息队列的每条消息由类型编号来分类,这样接收进程可以选择读取特定的消息类型——这一点与管道不同。消息队列在创建后将一直存在,直到使用msgctl系统调用或iqcrm -q命令删除它为止。 ---- 系统提供了许多有关创建、使用和管理消息队列的系统调用,如: ---- int msgget(key,flag)——创建一个具有flag权限的MQ及其相应的结构,并返回一个唯一的正整数msqid(MQ的标识符); ---- int msgsnd(msqid,msgp,msgsz,msgtyp,flag)——向队列中发送信息; ---- int msgrcv(msqid,cmd,buf)——从队列中接收信息; ---- int msgctl(msqid,cmd,buf)——对MQ的控制操作; ---- (4) 共享存储段(SM) ---- 共享存储段是主存的一部分,它由一个或多个独立的进程共享。各进程的数据段与共享存储段相关联,对每个进程来说,共享存储段有不同的虚拟地址。系统提供的有关SM的系统调用有: ---- int shmget(key,size,flag)——创建大小为size的SM段,其相应的数据结构名为key,并返回共享内存区的标识符shmid; ---- char shmat(shmid,address,flag)——将当前进程数据段的地址赋给shmget所返回的名为shmid的SM段; ---- int shmdr(address)——从进程地址空间删除SM段; ---- int shmctl (shmid,cmd,buf)——对SM的控制操作; ---- SM的大小只受主存限制,SM段的访问及进程间的信息交换可以通过同步读写来完成。同步通常由信号灯来实现。SM非常适合进程之间大量数据的共享。 ---- (5) 信号灯 ---- 在UNIX中,信号灯是一组进程共享的数据结构,当几个进程竞争同一资源时(文件、共享内存或消息队列等),它们的操作便由信号灯来同步,以防止互相干扰。 ---- 信号灯保证了某一时刻只有一个进程访问某一临界资源,所有请求该资源的其它进程都将被挂起,一旦该资源得到释放,系统才允许其它进程访问该资源。信号灯通常配对使用,以便实现资源的加锁和解锁。 ---- 进程间通信的实现技术的特点是:操作系统提供实现机制和编程接口,由用户在程序中实现,保证进程间可以进行快速的信息交换和大量数据的共享。但是,上述方式主要适合在同一台计算机系统内部的进程之间的通信。 3 应用程序间的通信及其实现技术 ---- 同进程之间的相互制约一样,不同的应用程序之间也存在竞争和协作的关系。UNIX操作系统也提供一些可用于应用程序之间实现数据共享与信息交换的编程接口,程序员可以通过自己编程来实现。如远程过程调用和基于TCP/IP协议的套接字(Socket)编程。但是,相对普通程序员来说,它们涉及的技术比较深,编程也比较复杂,实现起来困难较大。 ---- 于是,一种新的技术应运而生——通过将有关通信的细节完全掩盖在某个独立软件内部,即底层的通讯工作和相应的维护管理工作由该软件内部来实现,用户只需要将通信任务提交给该软件去完成,而不必理会它的具体工作过程——这就是所谓的中间件技术。 ---- 我们在这里分别讨论这三种常用的应用程序间通信的实现技术——远程过程调用、会话编程技术和MQSeries消息队列技术。其中远程过程调用和会话编程属于比较低级的方式,程序员参与的程度较深,而MQSeries消息队列则属于比较高级的方式,即中间件方式,程序员参与的程度较浅。 ---- 4.1 远程过程调用(RPC)
-
玩转Java底层:JMX详解 - jconsole与自定义MBean监控工具的实际应用与区别" 在日常JVM调优中,我们熟知的jconsole工具通过JMX包装的bean以图形化形式展示管理数据,而像jstat和jmap这类内建监控工具则由JVM直接支持。本文将以jconsole为例,深入讲解其实质——基于JMX的MBean功能,包括可视化界面上的bean属性查看和操作调用。 MBeans在jconsole中的体现是那些可观察的组件属性和方法,如上图所示,通过名为"Verbose"的属性能看到其值为false,同时还能直接操作该bean的方法,例如"closeJerryMBean"。 尽管jconsole给我们提供了直观的可视化界面,但请注意,这里的MBean并非固定不变,开发者可根据JMX提供的接口将自己的自定义bean展示到jconsole。以下步骤展示了如何创建并注册一个名为"StudyJavaMBean"的自定义MBean: 1. 首先定义接口`StudyJavaMBean`,接口需遵循MBean规范,即后缀为"MBean"且包含getter方法代表属性,如`getApplicationName`,和无返回值的setter方法代表操作,如`closeJerryMBean`。 ```java public interface StudyJavaMBean { String getApplicationName(); void closeJerryMBean(); } ``` 2. 编写接口的实现类`StudyJavaMBeanImpl`,实现接口中的方法: ```java public class StudyJavaMBeanImpl implements StudyJavaMBean { @Override public String getApplicationName() { return "每天学Java"; } @Override public void closeJerryMBean() { System.out.println("关闭Jerry应用"); } } ``` 3. 在代码中注册自定义MBean,涉及的关键步骤包括: - 获取平台MBeanServer - 定义ObjectName,指定唯一的MBean标识符 - 注册MBean到服务器 - 启动RMI连接器服务,以便jconsole能够访问 ```java public void registerMBean() throws Exception { // ... 具体实现省略 ... } ``` 实际运行注册后的MBean,您将在jconsole中发现并查看自定义bean的属性和调用相关方法。然而,这种方式相较于传统的属性/日志查看和HTTP接口,实用性相对有限,可能存在潜在的安全风险。但不可否认的是,JMX及其MBean机制对于获取操作系统信息、内存状态等关键性能指标仍然具有重要价值。例如: 1. **获取操作系统信息**:通过JMX MBean,可以直接获取到诸如CPU使用率、操作系统版本等系统级信息,这对于资源管理和优化工作具有显著帮助。
-
探究和实现融合计费账务系统的架构与关键功能
-
Grid++Report 锐浪报表开发常见问题解答集锦-报表设计 问:怎样在设计时打印预览报表? 答:为了及时查看报表的设计效果,Grid++Report 报表设计应用程序提供了四种查看视图:普通视图、页面视图、预览视图与查询视图。通过窗口下边的 Tab 按钮可以在四种视图中任意切换。在预览视图中查看报表的打印预览效果,在查询视图中查看报表的查询显示效果。如果在报表的记录集提供了数据源连接串与查询 SQL,在进入预览视图与查询视图时会利用数据源连接串与查询 SQL 从数据源中自动取数,否则 Grid++Report 将自动生成模拟数据进行模拟打印预览与查询显示。注意:在预览视图与查询视图中看到的报表运行结果有可能与在你程序中的最终运行结果有差异,因为在报表的生成过程中我们可以在程序中对报表的生成行为进行一定的控制。 问:怎样用 Grid++Report 设计交叉表? 答:Grid++Report 没有提供专门实现交叉表的功能,其它的报表构件提供的交叉表功能一般也比较死板和功能有限。利用 Grid++Report 的编程接口可以做出灵活多变,功能丰富的交叉表。示例程序 CrossTab 就是一个实现交叉表的例子程序,认真领会此例子程序,你就可以做出自己想要各种交叉表,并能提取一些共用代码,便于重复使用。 问:怎样设置整个报表的缺省字体? 答:设置报表主对象的字体属性,也就是设置了整个报表的缺省字体。如果改变报表主对象的字体属性,则没有专门的设置字体属性的子对象的字体属性也跟随改变。同样每个报表节与明细网格也有字体属性,他们的字体属性也就是其拥有的子对象的缺省字体。 问:怎样在打印时限制一页的输出行数? 答:设定明细网格的内容行的‘每页行数(RowsPerPage)’属性即可。另外要注意‘调节行高(AdjustRowHeight)’属性值:为真时根据页面的输出高度自动调整行的高度,使整个页面的输出区域充满。为假时按设计时的高度输出行。 问:怎样显示中文大写金额? 答:将对象的“格式(Format)”属性设为 “$$” 及可,可以设置格式的对象有:字段(IGRField)、参数(IGRParameter)、系统变量(IGRSystemVarBox)与综合文字框(IGRMemoBox),其中综合文字框是在报表式上设格式。 问:能否实现自定义纸张与票据打印? 答:Grid++Report 完全支持自定义纸张的打印,只要在报表设定时在页面设置中选定自定义纸张,并指定准确的纸张尺寸。当然要在最终输出时得道合适的打印结果,输出打印机必须支持自定义纸张打印。Windows2000/XP/2003 操作系统上可以在打印机上定义自定义纸张,也可以采用这种方式实现自定义纸张打印。 问:怎样实现 0 值不打印? 答:直接设置格式串就可以,在“数字格式”设置对话框中选定“0 不显示”,就会得到合适的格式串。也可以通过直接录入格式串来指定 0 不显示,但格式串必须符合 Grid++Report 的规定格式。另一种实现办法是在报表获取明细记录数据时,在 BeforePostRecord 事件中将值为零的字段设为空,调用字段的 Clear 方法将字段置为空。 问:怎样实现多栏报表? 答:在明细网格上设‘页栏数(PageColumnCount)’属性值大于 1 即可。通过 Grid++Report 的“页栏输出顺序”还可以指定多栏报表的输出顺序是“先从上到下”还是“先从左到右”。 问:如何实现票据套打? 答:Grid++Report 为实现票据套打做了很多专门的安排:报表设计器提供了页面设计模式,按照设定的纸张尺寸显示设计面板,如果将空白票据的扫描图设为设计背景图,在定位报表内容的输出位置会非常方便。报表部件可以设定打印类别,非套打输出的内容在套打打印模式下就不会输出。 问:Grid++Report 有没有横向分页功能? 答:回答是肯定的,在列的总宽度超过打印页面的输出宽度时,Grid++Report 可以另起新页输出剩余的列,如果左边存在锁定列,锁定列可以在后面的新页中重复输出,这样可以保证关键数据列在每一页都有输出。仔细体会 Grid++Report 提供的多种打印适应策略,选用最合适的方式。Grid++Report 的多种打印适应策略为开发动态报表提供了很好的支持。 问:怎样实现报表本页小计功能? 答:定义一个报表分组,将本分组定义为页分组,在本分组的分组头与分组尾上定义统计。页分组就是在每页产生一个分组项,在每页的上端与下端都会分别显示页分组的分组头与分组尾,页分组不用定义分组依据字段。 报表运行 问:怎样与数据库建立连接? 答:如果在设计报表时指定了数据集的数据源连接串与查询 SQL 语句,Grid++Report 采用拉模式直接从数据源取得报表数据,Grid++Report 利用 OLE DB 从数据源取数,OLE DB 提供了广泛的数据源操作能力。如果 Grid++Report 的数据来源采用推模式,即 Grid++Report 不直接与数据库建立连接,各种编程语言/平台都提供了很好的数据库连接方式,并且易于操作,应用程序在报表主对象(IGridppReport)的 FetchRecord 事件中将数据传入,例子程序提供了各种编程语言填入数据的通用方法,对C++Builder 和 Delphi 还进行了专门的包装,直接关联 TDataSet 对象也可以将 TDataSet 对象中的数据传给报表。 问:打印时能否对打印纸张进行自适应?支持表格的折行打印吗? 答:Grid++Report 在打印时采用多种适应策略,通过设置明细网格(IGRDetailGrid)的‘打印策略(PrintAdaptMethod)’属性指定打印策略。(1)丢弃:按设计时列的宽度输出,超出范围的内容不显示。(2)绕行:按设计时列的宽度输出,如果在当前行不能完整输出,则另起新行进行输出。(3)缩放适应:对所有列的输出宽度进行按比例地缩放,使总宽度等于页面的输出宽度。(4)缩小适应:如果列的总宽度小于页面的输出宽度,对所有列的输出宽度进行按比例地缩小,使总宽度等于页面的输出宽度。(5)横向分页:超范围的列在新页中输出。(6)横向分页并重复锁定列。 问:如何改变缺省打印预览窗口的窗口标题? 答:改变报表主对象的‘标题(Title)’属性即可。 问:利用集合对象的编程接口取子对象的接口引用,但不是自己期望的结果。 答:Grid++Report中所有集合对象的下标索引都是从 1 开始,另按对象的名称查找对象的接口引用时,名称字符是不区分大小写的。 问:怎样在运行时控制报表中各个对象的可见性?即怎样在运行时显示或隐藏对象? 答:在报表主对象(GridppReport)的 SectionFormat 事件中设定相应报表子对象的可见(Visible)属性即可。 问:报表主对象重新载入数据,设计器中为什么没有反映新载入的数据? 答:应调用 IGRDesigner 的 Reload 方法。 问:怎样实现不进入打印预览界面,直接将报表打印出来?
-
SaaS新十年:餐饮数字化转型的三大趋势- 一体化系统 2012年,亚马逊公司前首席科学家安德里亚斯·维真德表示,数据是新石油,但石油需要加以提炼后才能使用,从事数据处理的公司就是炼油厂。 如今,数据是一种资源已经获得广泛共识,这场竞争的核心就在于数据的占有和应用能力,占有的数据越多、运用数据能力越强的公司就越有价值。 对于to B型企业,只做单点业务很难产生差异化优势,因为数据只有流动起来才有价值,就算CRM功能再好,不能跟收银之类的体系打通也没有意义。 在企业管理层面,由于过往理念、*、各业务的机制不统一,过程标准的规范缺失,导致各系统之间兼容性和集成性难以提高。比如餐饮商家在POS数据、会员管理、供应链管理等不同环节都要面对众多系统供应商,多系统难以融合,由此导致的数据割裂问题日益凸显。 即便前期已实现不同服务商系统间的一体化打通与数据规范统一,但随着餐饮企业发展,不断产生新的功能需求,一家服务商出现软件升级,意味着其他服务商也必须做出对策,这时如果其中任何一家出现应对能力不足或者倒闭情况发生,都会影响餐饮企业的进步发展。 因此,餐饮数字化服务具有天然的all in one属性,没有商家愿意收银用一家的系统,供应链用另一家,资金归集再用另外一家,商户对效率的追求天然决定其必然会选择一家功能最全的系统。 沉淀的数据只是资源,只有用起来,数据的价值才能释放。