今天才知道年终奖一次性计税的惊天 bug

2024-02-02 20:05:33 +08:00
 unt
36100 拿到手比 36000 少,请问大家真的是这样吗,上小学时的一道数学题成了现实了。
24803 次点击
所在节点    职场话题
170 条回复
mschultz
2024-02-04 19:42:13 +08:00
@cmdOptionKana #98
「但我有没有说过,我这个函数,它的计算结果是首尾相连的?我没说过。」
「注意,首尾相连这个要求,是你希望,不是我的承诺。」

实际上你「几乎」承诺了。

首先,根据国税发〔 2005 〕 9 号文的一个链接,https://guangdong.chinatax.gov.cn/gdsw/zjfg/2011-02/23/content_739bbfc1f7364a4a9b6091fc025662a2.shtml
我们进而找到对应的政策解读: https://guangdong.chinatax.gov.cn/gdsw/wzjd/2009-05/07/content_f354ca0442354599a94fc028217ed3d6.shtml

其中有一句:「计算方法是:用全年一次性奖金总额除以 12 个月,按其商数对照工资、薪金所得项目税率表,确定适用税率和对应的速算扣除数,计算缴纳个人所得税。」而这里的「工资、薪金所得项目税率表」,明显是指当时个税法里面的税率表,而个税法明确写了工资薪金所得适用超额累进税率。

也就是说:你引用了超额累进税率表中的数据,还引用了在超额累进税率计算中有特定数学意义的词汇「速算扣除数」,眼看就让广大群众都「觉得」你就就要按照超额累进税率的明确规则计算了 …… 但是一转头,在计算过程中悄悄埋陷阱多收税,导致计算结果根本不是超额累进税率,反而接近全额累进税率。

这就好比你给我一个函数 continuous_function( ),然后说:“我这个函数起名叫 continuous function ,但这只是个惯用名字,我并不保证它在数学意义上是连续的,多想了是你的责任”

怎么说呢,也许这不违法,但在普罗大众眼里,肯定是耍赖了。被喷的话不冤枉。

@chairuosen #99
cmdOptionKana
2024-02-04 19:44:40 +08:00
@gtx990
@chairuosen
@anzu
@mschultz

为什么大家会认为不够优美的缝合怪就等于 bug ?

这显然证据不足,因为还有一个重点:这个缝合怪能避免吗?

如果这个缝合怪是必须存在的,不能避免的,也就是说,如果必须要做一个速算表/速算公式,那么关键就会变成:你能设计一个更优美的缝合怪吗?如果不能,那凭什么说缝合怪是 bug 呢?
fzls
2024-02-04 19:46:59 +08:00
@cmdOptionKana #122 扣除数*10 不就符合逻辑了吗,同样也是缝合怪
fzls
2024-02-04 19:53:37 +08:00
@snw #120 很简单啊,年终奖单独适用一套累进计算额度不就好了- -现在这个不就是这样,每年其他部分累加计算,年终奖这部分可以选择使用这个方案单独计算,唯一奇葩的就是按照单独纳税额度来计算的扣税额使用的是 12 个月的,而速算扣除数却用了单个月的
mschultz
2024-02-04 19:56:41 +08:00
@cmdOptionKana #122 如果要求只是让函数给人感觉「更优美简洁」、不考虑国家税收收入数额问题(我的权力地位还没到考虑这个问题的地步😂)的话 —— 方案微调一下就可以的。

1. 如果想多收税,那就直接明说一次性奖金适用全额累进税率,36000 以下全额 3%,36000 - 144000 全额 10%,依此类推,没有扣除数的概念。
2. 如果不想多收税,想给人民群众优惠,那就一次性奖金直接单独适用 3% - 45% 的超额累进税率。

不用搞弯弯绕的参数,计算也方便好理解,也不怎么缝合。

====
现行的缝合怪方案与上述方案 1 有多大区别呢?感觉就是做了一个「超额累进」的样子,让人民群众观感好一点?
但实质上不是超额累进,然后就被看出端倪的群众骂。反正方案 1 也是挨骂,哈哈。可能骂的人会更多吧。
snw
2024-02-04 20:01:56 +08:00
@fzls
要是速算扣除数乘以 12 ,曲线是顺眼了,但离业务逻辑差远了。
乘以 12 翻译成业务语言是:“把年终奖分成 12 个月,每个月重新从最低档税率开始重新累进个税”,相当于额外给了 12 个月给你分摊年终奖,而不是把年终奖摊到月度工资上面。

至于你说年终奖单独适用一套累进计算额度......个税的税率表是写进税法的,那得修改税法才行。

至于你说现在年度综合所得纳税+年终奖可以单独计算......我前面说过了,改成年度综合所得纳税之后,理论上就没必要继续给年终奖单独计算了,无非是现在经济不好,所以打着延续政策的名义给个税优惠罢了。这是暂时补丁,不是应该有的东西。
changnet
2024-02-04 20:05:11 +08:00
@snw 我都不知道你们在争什么,我觉得 snw 说得很清楚了。

很久以前,年终奖是合并到当月工资里计算的。假设 12 月工资为 0 的情况下,年终奖要扣 4410 ,即到手 36000 - 4410 = 31590

于是大家觉得这计算方式不够好,改进一下,变成:应纳税额=全年一次性奖金收入×适用税率-速算扣除数 12 ,即 36001 ,平均到 12 个月,税率 10%,速算 210 ,则税为 36001×10%-210=3390.1 , 到手 32610.9

你看,改进后,工资是独立算的,年终奖 32610.9 也比原来的算法的 31590 多,这不是优惠了吗?

没错,这算法是有问题,人家也没否认。至于为什么有问题也这样做 snw 不也解释了吗?但是比原来的算法有进度不是。而且现在不也有新的税法了吗?按年总收入来算。

然后一帮人在 2024 的角度对这算法口诛笔伐有什么意义?就好比大家都在说 md5 算法有问题,会出现冲突。人家是有问题,但是在当时简单够用。
snw
2024-02-04 20:05:44 +08:00
@mschultz
见 126 楼,你提的方案相当于额外给了 12 个月用来分摊年终奖(即从 3%开始适用累进税率),这就是我说的看起来很好看但离本质差很远的东西。
mschultz
2024-02-04 20:32:58 +08:00
@snw #119 你说问题的本质是「(应该)摊到每月收入上再超额累进」,我可不可以进一步解读为「月度收入高的人,其年终奖的税率应该更高一些;月度收入低的人年终奖税率也低一些」。也就是说,新税法的做法最接近问题本质。

只是 19 年前财税界电算水平不高,「最大的问题在于(每个人月度工资不同,所以在快捷计算上)没有实操性。」,所以才实行国税发〔 2005 〕 9 号补丁。

这个补丁其实做了一个隐含的、非常粗糙的假设:就是年终奖越高的人,他的平时工资大概也越高,如果将年终奖均摊到 12 个月(本质算法),均摊过来的这部分更可能直接适用高税率。

因此,年终奖直接适用「全额累进税率」更接近问题的本质。现行方案约等于在全额累进税率的基础上做了一定的「扣除数」补偿。

====
那么现在剩下的主要问题是:这个「扣除数」补偿的*数值选择* 和 *名词选择* 极具误导性,给补偿的解释也挺牵强的。不排除是官方刻意误导(?)。最后也免不了挨骂,这个帖子里那么多回复就是例子。
106npo
2024-02-04 20:38:09 +08:00
@changnet 有点小错误是, 国税发〔 2005 〕 9 号 之前用的是 国税发〔 1996 〕 206 号.
一次性奖金是单独作为一个月的工资计算纳税的,不需要假设 12 月的工资为 0.

这也可能是 国税发〔 2005 〕 9 号 算法中减除一个月的速算扣除额的隐藏原因,因为之前就另外给了一个月用于缴税.
liuweiqing
2024-02-04 21:34:31 +08:00
持保留态度
snw
2024-02-04 21:37:04 +08:00
@xmumiffy
谢谢,这解答了我的困惑。
看起来像是政策升级(从“视同单独一个月计税”升级成“视同在 12 个月均匀取得”)过程中,为了兼容旧政策所以留下的“祖传代码”😂
chairuosen
2024-02-04 22:09:50 +08:00
我本身也是开发,我非常讨厌开发在面对自己写出的 BUG 时,各种狡辩这不是 BUG 的行为。
在楼上我看到了:
1 ,历史继承的所以不是 BUG
2 ,占了便宜所以不是 BUG
3 ,人家专业的所以不是 BUG
4 ,需求就是人家出的所以不是 BUG

我是用户,我用着有问题,就是 BUG
chairuosen
2024-02-04 22:27:59 +08:00
@chairuosen #133 这个问题根本不需要从过程分析。只需要从结果分析:发的多,拿的多,发的少,拿的少。跟多劳多得一样,是理所应当的。 发的多拿的少,我付出多奖金高到手的反而少,我凭什么付出。违背历史发展规律,你不认为是 BUG 无所谓,历史会把你淘汰。
skull
2024-02-04 22:36:10 +08:00
36001~38566.67 是禁区,38566.67~41775 是低效区
snw
2024-02-04 22:43:41 +08:00
@chairuosen
我是(半个)业务部门,我很讨厌开发用“代码优雅性”、“我觉得应该怎样怎样”来试图直接篡改业务逻辑。
由业务逻辑导致的意外结果,而且有 workaround 的情况下,应该先制定业务逻辑的改进方案,而不是想当然地直接改代码。
chairuosen
2024-02-04 23:25:07 +08:00
@snw #136 有意外结果的业务逻辑不就是 BUG 么。业务逻辑的改进方案不就是改 BUG 么?
kkbblzq
2024-02-04 23:55:30 +08:00
@snw 这种所谓的唯权威论是不能让我信服的,这种无论从数学角度还是实际执行上都有明显问题的算法,单纯以有优惠就是对的来解释是很强行的;像极了那种"领导说的就是对的,错的也是对的",我完全没有从你的说法中找到任何可以佐证的证据,而是直接以“官方给的算法一定是对的”的角度,然后自圆其说的拿一些所谓的背景来找补。
mschultz
2024-02-05 00:26:54 +08:00
@changnet #127 至今还在讨论的原因是:1.新税法虽最合理,但新税法下很多人税负增加了,还不如用那个有问题的算法。
2.官方允许老算法继续应用到 2027 年。现行的政策就应该容许批评的声音。
3.这个补丁算法虽然是比更老的算法优惠,但人们永远希望它能更优惠。诶,它不是长得有点儿像超额累进税率吗?人们希望它真的是。毕竟那样又可以交更少的税咯。啊,仔细一看原来不是啊,遗憾,批判一下。

“如何让自己少交点钱” 这个话题别说 2024 年,4202 年也可以热烈讨论啊,如果那时候人类还没灭亡的话
KgM4gLtF0shViDH3
2024-02-05 01:30:01 +08:00
没有年终奖就没有烦恼了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1013749

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX