求助 古老的问题 发票差一分钱。。。。

mingkesoft

如果用的是用友，有个“修改税额反算税率”的选项，选上之后，直接填写税额，系统会自动把17%税率反算为17.0000001122%之类的数字，但是税率显示和打印位数还是两位17%。

urinator

最初由 mingkesoft 发布
[B]如果用的是用友，有个“修改税额反算税率”的选项，选上之后，直接填写税额，系统会自动把17%税率反算为17.0000001122%之类的数字，但是税率显示和打印位数还是两位17%。 [/B]

学习了，知道了

georgefan

最初由 wo23le 发布
[B]物料代码        发票数量        不含税单价        不含税金额        含税单价        含税金额        税金        取两位小数税金
       
28300020Z        3000.0000000        5.1282067        15384.62        6.0000018        18000.00        2615.3854000        2615.39 [/B]

谢谢。今天事情比较多。

回头我把上世纪我们的处理规则告诉你。

不争高手低手知道不知道，只谈讨论解决问题。

georgefan

最初由 wo23le 发布
[B]物料代码        发票数量        不含税单价        不含税金额        含税单价        含税金额        税金        取两位小数税金
       
28300020Z        3000.0000000        5.1282067        15384.62        6.0000018        18000.00        2615.3854000        2615.39 [/B]

我们来看：
[商品]：这个字段没有问题；
[数量]：这个字段也没有问题；

[含税单价]：这个字段也没有问题，国内我们通常向客户报的价格就是含税的价格，本例也以此为样本讨论，我以价内增值税=17%来讨论。

[含税金额]：=[数量]*[含税单价]，这也不会有问题；
          其实我更习惯称之为“价款”或“价税合计”

[未税金额]：=[含税金额]/1.17；
    麻烦就是因这步而引起的。
    国内增值税17%，必须按这样的算法来计算未税金额。
    但这样计算结果就是除不尽，涉及到小数位的处理。
    不同的硬件平台，不同的软件编译系统，或者不同系统的设计师的取舍不同（或者取舍相同），都有可能会造两个不同的系统按同一公式计算，但在最后一位小数位上出现差异。
    我记得上世纪九十年代后期，刚实行增值税时，当时全都是手工开增值税票，我们的会计在这栏上都不写具体的数字，直接就是写“XXXX/1.17”
    没关系，我们有办法处理。

[税额]：一定要设计成=[含税金额]-[未税金额]
    算法必须设计成这样。
    因企业的数据中，[含税金额]、[未税金额]、[税额]是必须和金税系统中开出的票保持一致。如果不一致的话，你就得象祥林嫂讲阿毛的故事一样，得谁给谁解释，没完没了。
    哪么这三个数中，[含税金额]双方系统是不会有出入的，是定值。问题就是[未税金额]可能双方系统计算出来有差异。
    没关系，手工更改[未税金额]，改成和金税系统中的一致。
    [含税金额]正确、[未税金额]正确、[税额]是减出来，必然正确。

[未税单价]：=[未税金额]/数量
    随便算吧，手工改了[未税金额]后，就联动计算[未税单价]，单价一般在保留两位小数位时，是不会出现误差的。就算有也无足挂齿。因这东西在ERP后续的处理中不起任何作用(但愿您也把它设计成不起作用。如果您把它设计成计算的依据，哪您就歇菜了)。

   
    我们来总结一下联动关系：
[数量]、[含税单价]变动，联动计算更新[含税金额]；
[含税金额]变动后，是否反算[含税单价]，可以设置参数来控制。

[未税金额]是计算项，但结果可手工更改。
     其=[含税金额]/1.17，但要注意，改动后不得反算税率及含税金额，这是死规则，必须设计成这样。

[税额]是计算项，=[含税金额]-[未税金额]；
     可改，改后会反算[未税金额]，但不能动[含税金额]；

    打字很辛苦，剩下的就不说了，最关键就是[含税金额]、[未税金额]、[税额]这三项要和金税系统一致，而这三项中的后两项也是最易出问题的。

    哪么，与这相关的规则还有：

    价格不含税时的处理方式。
    税还分为“价内税”，“价外税”，处理也有不同。

    每个发票行计算出来了，在计算整个发票各栏目合计数值时，在某些情况下也要考虑特殊的处理规则（很重要，处理不好，合计统计销售收入及税额时，或者分配计算时，还会有尾差问题）。

    这些规则都是上世纪九十年代中后期成熟得掉碴的规则了。

    说得太多了，但愿能帮上楼主。

urinator

georgefan说的全都看明白了，是比做凭证方便多了，呵呵

georgefan

最初由 瓷骨MM 发布
[B]quote:

--------------------------------------------------------------------------------

兄弟，你没见过的多了,

本来就是很正常的事情，税务都同意的,财务凭什么说不做啊.

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

这话老木说了我就不再说了。什么用户遍天下啊， U8 的尾差我就见过。 [B]  话不要说的太满了，尤其是在这么多的高手面前。[/B]  [/COLOR]


     出现差异就要从2方面来看，我们曾经发现小数位数跟金税系统里面的一样的时候， 金税系统因为算17％ 的 增值税， 再加上无税的部分，结果就多了1分钱，这个差异是金税系统多算了1分钱。系统算的是正确的。  这时候你怎么办？？  总不能把金税机器砸了吧。 [/SIZE]

  所以啊，不要老是说系统不对，要看是谁造成了差异。
  实在有差异，也就只能月末调帐。 告诉客户，其他客户都是这样的。 这叫[B]行业惯例[/B][/COLOR]  。 [/B]

师傅说了，猫有猫路，狗有狗道。

各人都有自己的绝活，以能让用户满意为最终目标。

如果能说服用户接受，哪也无可厚非。不战而倔人之兵，上之上策也。

我们说服不了用户，反而经常被客户搞倔了，所以用算法搞定。

师傅还说了，象韦小宝和海公公两个人就很有代表性。

海公公一身盖世武功，独门秘技“化骨绵掌”无人能破，无人能招架，可后能又能如何？最后成了疯子，可惜“化骨绵掌”也就此失传。

而韦小宝呢，论武功可谓没有，但凭自己的机灵在皇宫内院上下如鱼得水，有惊无险，最后还搞了七个娘子，谁也奈何不了他，不也很牛叉吗。

所以说，韦小宝不能小看海公公，否则“化骨绵掌”真的结结实实给你来一下，你韦小宝再滑头，下场也是一滩血水。

而海公公也不能不把韦小宝当回事，自古英雄出少年，你海公公整天啥也不干就研究“化骨绵掌”，人都废了，人不风流枉少年，有本事你也象人家韦小宝哪样搞定七个娘子呀。

wo23le

感谢georgefan 这么耐心的讲解。


手工更改[未税金额]，改成和金税系统中的一致。
[未税金额]是计算项，但结果可手工更改。
这两句话，对于我们的系统，计算项是不可更改的，所以我们加了一个调差字段
所以我们现在的操作就是：输入 不含税金额，发票数量，算出所有其它的。出现差异，在调差字段里微调。

ie_cat_zjc

楼上的偶像！

系统都是人做出来，在运用系统的时候还是因该由人来主导，被一分钱憋死跟现在的网游一样被游戏玩而不是人玩游戏。
看来系统在使用过程中最重要的还是逻辑和人。

georgefan

最初由 wo23le 发布
[B]感谢georgefan 这么耐心的讲解。


手工更改[未税金额]，改成和金税系统中的一致。
[未税金额]是计算项，但结果可手工更改。
这两句话，对于我们的系统，计算项是不可更改的，所以我们加了一个调差字段
所以我们现在的操作就是：输入 不含税金额，发票数量，算出所有其它的。出现差异，在调差字段里微调。 [/B]

好，我又学了一招。

又分析了一下，其实做一个调整字段，和我直接改未税金额，是异曲同工的效果。你的做法更简洁。不用苦练“九阴真精”（有人曾为此功而自宫，实在得不偿失呀），轻轻以“乾坤大腾挪”解之，可谓四两拨千斤呀。

不知你后续如何处理。我猜这个调整字段只存在在发票上，后续处理时将以“[未税金额]+[调差]”做为一个字段来进行处理了。

Terrygu0913

学习学习,一分钱的大问题!