BOSS系统计费模块全解析：从话单采集到批价出账

简介面向电信行业从业者、运营商计费系统运维人员及通信专业学生这份PPT学习教案系统梳理BOSS系统在移动计费、账务管理和客户服务中的核心作用。内容从系统架构切入介绍用户基站交换机、计费直采系统、DCN网络以及省计费系统的后台管理与前台营业模块并详述直采文件接收、话单检错、标准化、入库、欺诈控制、漫游结算、帐务处理等完整计费流程。教案重点展开不同品牌资费细则涵盖全球通同城特例、呼叫转移计费、欠费违约金规则、停机保号月租收取方法以及动感地带、神州行金卡、大众卡、长话卡和金卡快捷通的资费标准还附有普通GSM、短信、梦网、GPRS、彩信等话单格式示例便于实际对照学习。压缩包内为1个pptx演示文稿仅479KB共22页幻灯片内容精炼、结构清晰。已有70人浏览学习适合作为快速理解电信BOSS计费机制和资费政策的入门参考资料。1. BOSS系统计费模块到底在算什么如果把BOSS系统比作电信公司的收银台计费模块就是收银台背后最复杂的一台算账机器。刚接手计费域的人容易以为难点在计算本身实际上乘除法并不难难的是每一笔费用都能说清楚「为什么是这个数」来自哪张话单、哪个套餐费率、哪一层优惠。BOSS系统的计费链条从网元采集、预处理、批价延伸到出账任何一个环节的口径不一致最终都会变成用户账单上的投诉。这篇文章按一套培训教案的组织方式来讲计费知识聚焦话单从出生到出账的完整路径适合对接计费接口的集成工程师、刚接手话单域的BOSS系统开发以及要给团队做计费知识培训的讲师。读完可以带走一套可复现的批价验证脚本和几个排查算错账的切入角度。2. 原始话单从网元到计费中心的流转链路2.1 采集方式与接口选型BOSS系统计费的起点是「拿话单」。话单由核心网网元生成按业务域划分语音业务看MSC/GMSC分组业务看SGSN/GGSN4G/5G流量看PGW/UPF。与网元对接的方式基本分两类文件型采集和流式采集。文件型采集最普遍网元按固定时间窗口如每15分钟或每小时生成CDR文件通过SFTP推送到采集前置机。采集机只做搬运和落盘不修改原始文件保留完整审计痕迹。流式采集用于在线计费场景通过Diameter Gy接口或IPDR协议把使用量实时送到计费控制点。选型的判断标准很直接后付费用户量大但实时性要求不高用文件型就够预付费用户、需要余额控制的业务必须走流式因为要在使用过程中实时扣费。接口协议上SFTP是主流少数老网元还在用FTP。如果业务允许尽量在采集机与网元之间加一层独立的传输区避免网元的账号直接暴露给计费应用层。文件命名规范在联调阶段就要定死比如{网元标识}_{日期}_{序列号}.cdr后续的幂等处理全靠这个序列号。2.2 预处理四步格式清洗、字段补齐、时间归整、去重话单文件落地之后要先过预处理。第一步是格式清洗不同厂商话单的差异很大同一字段在华为和李氏网元里可能一个用16位长整型、一个用yyyymmddhh24miss变长字符串。第二步是字段补齐漫游话单中缺失的归属地、计费所需的用户号段都要在预处理阶段用基础数据补全。第三步是时间归整按分钟、按6秒甚至按KB为单位归一化。第四步是去重。去重是四个步骤里最容易被忽略的。多数网元在回传失败后会重传整个文件如果采集端不做幂等控制同一张话单会进入批价两次。常见做法是利用文件头序列号记录已处理位置如果网元不支持文件级序列号就用「主叫号码 开始时间 通话时长 被叫号码」拼接业务主键在批量入库前做行级判重。去重不能只靠数据库唯一索引因为批价前的预处理区往往不在同一个库。2.3 一套话单清洗脚本的落地示例#!/bin/bash # 话单预处理示例SFTP拉取 → 行级去重 → 写入待批价目录 BILL_DIR/data/bill/raw STAGE_DIR/data/bill/stage TODAY$(date %Y%m%d) mkdir -p $BILL_DIR/$TODAY $STAGE_DIR/$TODAY # 1. 从网元拉取原始CDR文件只保留当日文件 sftp -b - baitnetwork-element EOF cd /export/cdr/$TODAY mget *.cdr $BILL_DIR/$TODAY/ bye EOF # 2. 对目录内所有文件做去重后合并写入stage区 cat $BILL_DIR/$TODAY/*.cdr | awk -F| !seen[$2|$3|$4|$5] $STAGE_DIR/$TODAY/merged.cdr # 3. 记录已处理文件清单供后续批价任务读取 ls $BILL_DIR/$TODAY $STAGE_DIR/$TODAY/manifest.txt wc -l $STAGE_DIR/$TODAY/merged.cdr这里用SFTP拉取网元目录中的CDR文件mget *.cdr按扩展名匹配awk使用!seen[key]的模式做行级去重key由第2到第5个字段拼接对应主叫、被叫、开始时间和时长。manifest.txt落一份已处理文件清单批价任务读取这个文件就知道本次处理范围。生产环境不要在采集机上直接跑重型awk数据量大时改用分区表批量去重脚本只负责文件层面的事。3. BOSS系统批价引擎的定价树与折扣优先级3.1 产品目录与费率表的关系模型批价是计费的核心环节输入是预处理后的标准化话单和用户订购关系输出是优惠后的应收金额。BOSS系统的产品目录通常按「产品-套餐-附加包-优惠活动」四层组织。产品是用户看到的商品名称套餐绑定基础费率附加包在套餐之上叠加流量包或语音包优惠活动是周期性折扣。费率表是批价的字典。每张费率表至少包含六个要素适用用户群、资源类型语音/流量/短信、计费单位、单价、生效周期和优先级。批价时先根据用户归属找到订购的套餐再按资源类型匹配费率。这里最容易踩的坑是优先级定义不清当一个用户同时有基础套餐折扣和新用户优惠时系统必须明确组合规则否则同一张话单在凌晨和白天会算出不同的应收金额。3.2 批价的三次查找与费用项拆分一次完整的批价会做三次查找。第一次查用户订购关系确定这个用户按哪个套餐、哪个品牌计费第二次查资源单价把话单中的用量转换成费用项第三次查优惠叠加把可用的折扣按优先级逐层作用到费用上。费用项拆分是批价结果的核心结构。一条通话话单可能被拆成本地通话费、长途费、基础套餐减免等多个费用项每个费用项都带有自己的类型编码。这样设计的好处是出账时能够分别统计、分别优惠也能在用户详单里看到每一行的费用来源。3.2.1 批价时序先定位套餐、再叠加优惠批价的执行时序固定为先按用户标识定位产品实例按话单发生时间判断是否在套餐生效周期内然后取基础费率计算出目录价接着检查是否存在集团优惠、时段优惠、充值赠送等叠加项从目录价中扣减。时序一旦颠倒比如先扣优惠再查原价会导致优惠基数和账务统计全部错位。这个时序在代码层面通常体现为嵌套的费率解析器。外部解析器处理套餐级逻辑内部解析器处理附加包和活动。解析器之间通过一个上下文对象传递中间结果比方说duration_remaining、amount_before_discount。3.3 批价费率配置的SQL参考-- 费率配置简化示例语音基础费率 时段优惠 SELECT p.product_name, r.resource_type, r.price AS base_price, r.billing_unit AS unit, d.discount_rate, d.active_start, d.active_end FROM product p JOIN rate_plan r ON p.plan_id r.plan_id LEFT JOIN discount d ON r.plan_id d.plan_id AND d.resource_type VOICE AND :call_time BETWEEN d.active_start AND d.active_end WHERE p.product_id :productId AND :call_time BETWEEN r.effective_date AND r.expire_date ORDER BY d.priority DESC;这段SQL取指定用户在通话时间点对应的基础费率再关联可用的折扣。billing_unit是计费单位语音通常填6或60秒discount_rate是折扣率0.8表示打8折priority倒序排数值大的先命中。实际生产中这个查询会从配置中心加载到内存缓存不会在批价热路径上直接查库。参数典型值含义billing_unit6 / 60计费单位6秒制主要影响取整规则discount_rate0.8折扣系数作用于基础价priority1-99折扣优先级数值小先判定expire_date2099-12-31费率有效期一定要设足够大4. BOSS系统账务处理、账期管理与对账口径4.1 日账和月账怎么分工批价完成之后费用项还不能直接变成账单需要经过账务处理。账务处理在BOSS系统里分两个节奏日账和月账。日账在每天凌晨跑批把当天的话单费用汇总成日累计用于额度提醒和风险控制月账在每月出账日跑批把整个账期的费用项汇总、优惠分摊处理后生成正式账单。日账和月账的差别不仅在时间粒度还体现在优惠结算口径上。日账是临时值用于展示和预警月账是最终值用于出账和销账。月初充值送的话费日账只记录实时消耗月账才做递延分摊。开发时最容易出的问题是拿日账的中间状态去对月账的最终结果两者天然对不齐对不上时先确认口径。4.2 关账流程与账期状态机每个账期都有明确的开关账时间。关账后进入锁定期不再接受该账期的话单补充和批价变更。BOSS系统的账期状态机一般包括OPEN开账期、CLOSING关账中、CLOSED已关账、BILLED已出账、ARCHIVED已归档。# 账期流转伪代码每个状态对应一组允许操作 def run_billing_period(period): if period.state OPEN: close_period(period) # 停止接收新话单 period.state CLOSING if period.state CLOSING: wait_pending_bills(period) # 等待在途话单处理完毕 period.state CLOSED if period.state CLOSED: generate_bill(period) # 执行月账汇总与优惠分摊 period.state BILLEDclose_period要做的核心事情是关闭采集端的写入开关并记录最后一批文件的清单wait_pending_bills是做一次阻塞检查确认没有在途文件。这两个动作如果漏掉任何一个月账结果就会少算一批话单而且很难事后定位。状态允许操作禁止操作OPEN追加话单、批价生成最终账单CLOSING在途话单入库新增网元文件CLOSED出账前核对修改费率或追加话单BILLED查询已出账数据修改出账结果ARCHIVED只读查询所有写操作4.3 和CRM侧对不上账时先查什么BOSS系统按域拆分后计费域和CRM域各自维护一套数据。两边对不上账时先看口径再找数据。常见三类原因一是费用项编码在两侧不一致二是优惠折扣只在计费域生效但CRM侧按目录价展示三是用户投诉调账后CRM侧改了账单但计费域没有同步调账记录。排查时先取一张争议话单比对计费域原始费用项和CRM侧明细的差额判断差额来自目录价层还是优惠层。如果差额正好等于某条折扣记录那就是CRM侧展示口径问题如果差额带有一个费用项编码则大概率是两侧编码映射缺失。5. OCS在线计费与计费准确性的验证手段5.1 OCS和离线计费怎么选预付费用户不能欠费必须用OCS在线计费做实时额度控制后付费用户出账后再收钱离线计费就够。混合场景下一个用户在4G网络用流量、同时在WiFi网络下走VoLTE可能同时触发两类计费OCS负责实时扣减余额离线计费负责出账。选型的判断依据是信控要求有余额阈值检查、有生命周期管理需求的走OCS只做事后汇总的走离线。5.2 一个最小批价验证脚本#!/usr/bin/env python3 # 批价最小回归脚本按阶梯费率断言应收金额 import math import sys def calc_call_fee(duration_sec, rate, unit, setup_fee, free_units): billable_units max(0, duration_sec - free_units * unit) charge_units math.ceil(billable_units / unit) return setup_fee charge_units * rate if __name__ __main__: duration, rate, unit, setup, free map(int, sys.argv[1:6]) fee calc_call_fee(duration, rate, unit, setup, free) print(fcomputed_fee{fee:.4f})参数依次是通话时长秒、每计费单元单价、计费单元长度秒、起步费、免费单元数。这个脚本可以作为批价引擎的回归基准引擎改一版拿同一组话单对比输出。实际使用中把预期结果放在CSV里脚本读入后批量断言比手动核对快得多。5.3 一个排查「算错账」的定位技巧计费不准时不要从头到尾看一遍代码。先找原始话单的归档位置用采集记录的落盘文件名和行号确认这张话单是否被重复处理再查预处理后的标准化话单确认时间归整是否正确最后才看费率。实际案例里大量算错账问题出在时间归整和去重环节真正的批价逻辑错误占比很低。养成先验证数据再验证逻辑的习惯能省下大半排查时间。本文还有配套的精品资源点击获取