上周三下午运营小王在问数平台敲了一句话三号楼这个月收缴率多少。平台回了他一个数92%。半小时后财务老李把月度报表甩进群里三号楼收缴率 87%。差了五个点。群里一下安静了。这件事后来成了我们接问数平台最值钱的一课。把排查过程原样记下来给同样在接园区的同学避坑。图243 左边是园区系统本来的样子右边是后来叠上去的问数入口两边一开始还没真正对上。先确认平台到底算了什么问数平台的好处这时候就显出来了。它只读不写所有回答都带得出处我能直接翻到它跑的那段 SQL。图244 一只手搭在合着的账本封面上只看不翻只读账号就是这个用法。sql-- 平台语义层早期版本算的收缴率 SELECT building_id, SUM(paid_amount) / SUM(due_amount deposit_amount) AS rate FROM fin_bill WHERE period 2026Q3 GROUP BY building_id;财务那张报表的口径长这样。sql-- 财务月度报表里的收缴率 SELECT building_id, SUM(paid_amount) / SUM(due_amount) AS rate FROM fin_bill WHERE period 2026Q3 GROUP BY building_id;两个口径差在一个分母项预收押金。差在哪一处园区系统在录账单时把预收押金单独挂了一个科目不进当期应收。财务做月度报表也按这个来应收只算当期应缴。问数平台刚接进来时语义层那张视图把 deposit_amount 一并加进了分母。平台没算错它只是按当时写进去的口径老老实实算了。问题出在口径两边没对齐。项目财务报表口径平台早期口径修正后应收分母当期应缴当期应缴 预收押金当期应缴预收押金单列科目不进分母混入分母单列科目不进分母三号楼结果87%92%87%图245 一张放大镜压在账本和来源标签上查的就是这一个分母项的出处。三处一起改第一处语义层视图把 deposit 从分母剥离口径对齐到原系统报表的定义。sql-- 修正后的口径与原系统财务报表保持一致 SELECT building_id, SUM(paid_amount) / NULLIF(SUM(due_amount), 0) AS rate FROM fin_bill WHERE period 2026Q3 GROUP BY building_id;第二处在视图上加一行注释写明应收不含预收押金谁后面接手都能一眼看懂。第三处把这条问法补进经验库样例。下次再有人问收缴率平台按统一口径答不会又冒出一个版本。改完重跑小王那句问话三号楼回到 87%和财务报表对上了。我又抽了十号楼和五号楼把两个口径都跑一遍结果一致才收工。这一步别省改一处口径很容易牵动别处。图246 两个高度不一样的柱组就是改之前和改之后的差别。回头看这件事排查全程我没碰原系统一个字段。问数平台连的是只读账号查得再狠也只是看改不了也删不了。原系统照常记房源、记合同、记账单一个字没动。两套系统分工就是这样一个管发生一个管看懂。这次对不上数根子在口径没接稳平台算得没错。把口径焊死在一处重复问题下次就不会再冒出来。图247 老房子、问数入口、小桥连成一圈查完一轮回到业务本身。少等一次取数少做一次重复工作少一次反复解释。这是我们接问数平台最实在的三句话。
上周三下午运营小王在问数平台敲了一句话三号楼这个月收缴率多少。平台回了他一个数92%。半小时后财务老李把月度报表甩进群里三号楼收缴率 87%。差了五个点。群里一下安静了。这件事后来成了我们接问数平台最值钱的一课。把排查过程原样记下来给同样在接园区的同学避坑。图243 左边是园区系统本来的样子右边是后来叠上去的问数入口两边一开始还没真正对上。先确认平台到底算了什么问数平台的好处这时候就显出来了。它只读不写所有回答都带得出处我能直接翻到它跑的那段 SQL。图244 一只手搭在合着的账本封面上只看不翻只读账号就是这个用法。sql-- 平台语义层早期版本算的收缴率 SELECT building_id, SUM(paid_amount) / SUM(due_amount deposit_amount) AS rate FROM fin_bill WHERE period 2026Q3 GROUP BY building_id;财务那张报表的口径长这样。sql-- 财务月度报表里的收缴率 SELECT building_id, SUM(paid_amount) / SUM(due_amount) AS rate FROM fin_bill WHERE period 2026Q3 GROUP BY building_id;两个口径差在一个分母项预收押金。差在哪一处园区系统在录账单时把预收押金单独挂了一个科目不进当期应收。财务做月度报表也按这个来应收只算当期应缴。问数平台刚接进来时语义层那张视图把 deposit_amount 一并加进了分母。平台没算错它只是按当时写进去的口径老老实实算了。问题出在口径两边没对齐。项目财务报表口径平台早期口径修正后应收分母当期应缴当期应缴 预收押金当期应缴预收押金单列科目不进分母混入分母单列科目不进分母三号楼结果87%92%87%图245 一张放大镜压在账本和来源标签上查的就是这一个分母项的出处。三处一起改第一处语义层视图把 deposit 从分母剥离口径对齐到原系统报表的定义。sql-- 修正后的口径与原系统财务报表保持一致 SELECT building_id, SUM(paid_amount) / NULLIF(SUM(due_amount), 0) AS rate FROM fin_bill WHERE period 2026Q3 GROUP BY building_id;第二处在视图上加一行注释写明应收不含预收押金谁后面接手都能一眼看懂。第三处把这条问法补进经验库样例。下次再有人问收缴率平台按统一口径答不会又冒出一个版本。改完重跑小王那句问话三号楼回到 87%和财务报表对上了。我又抽了十号楼和五号楼把两个口径都跑一遍结果一致才收工。这一步别省改一处口径很容易牵动别处。图246 两个高度不一样的柱组就是改之前和改之后的差别。回头看这件事排查全程我没碰原系统一个字段。问数平台连的是只读账号查得再狠也只是看改不了也删不了。原系统照常记房源、记合同、记账单一个字没动。两套系统分工就是这样一个管发生一个管看懂。这次对不上数根子在口径没接稳平台算得没错。把口径焊死在一处重复问题下次就不会再冒出来。图247 老房子、问数入口、小桥连成一圈查完一轮回到业务本身。少等一次取数少做一次重复工作少一次反复解释。这是我们接问数平台最实在的三句话。
