|
|
这个做法基本可以接受，但仅仅下面一点有不同意见。【不含税单价】是计算库存成本的重要依据，怎么能说不起任何作用呢？只不过基本不影响就是了。
其实这个问题，根本在于软件系统的算法和税控机的算法不同，有时候客户也觉得税控机的系统算法不合理，可是这也是没有办法的事情。
在龙特ERP(http://www.longter.com)的算法前部分是差不多的，如果是按【不含税单价】报价及计算，什么事情也没有。
关键是按【含税单价】计算的时候，算法是这样，
【不含税金额】=【含税金额】/(1+税率),
【税额】=【含税金额】-【不含税金额】 （这条公式，基本上所有的税控机都是能够满足的）
所以在【含税金额】确定的时候，可以调【不含税金额】和税控机一致，这样就能保证3者一致。
[未税单价]：=[未税金额]/数量
随便算吧，手工改了[未税金额]后，就联动计算[未税单价]，单价一般在保留两位小数位时，是不会出现误差的。就算有也无足挂齿。因这东西在ERP后续的处理中不起任何作用(但愿您也把它设计成不起作用。如果您把它设计成计算的依据，哪您就歇菜了)。
原帖由 georgefan 于 2007-7-5 17:31 发表 ![]()
我们来看：
[商品]：这个字段没有问题；
[数量]：这个字段也没有问题；
[含税单价]：这个字段也没有问题，国内我们通常向客户报的价格就是含税的价格，本例也以此为样本讨论，我以价内增值税=17%来讨论。
[含税金额]：=[数量]*[含税单价]，这也不会有问题；
其实我更习惯称之为“价款”或“价税合计”
[未税金额]：=[含税金额]/1.17；
麻烦就是因这步而引起的。
国内增值税17%，必须按这样的算法来计算未税金额。
但这样计算结果就是除不尽，涉及到小数位的处理。
不同的硬件平台，不同的软件编译系统，或者不同系统的设计师的取舍不同（或者取舍相同），都有可能会造两个不同的系统按同一公式计算，但在最后一位小数位上出现差异。
我记得上世纪九十年代后期，刚实行增值税时，当时全都是手工开增值税票，我们的会计在这栏上都不写具体的数字，直接就是写“XXXX/1.17”
没关系，我们有办法处理。
[税额]：一定要设计成=[含税金额]-[未税金额]
算法必须设计成这样。
因企业的数据中，[含税金额]、[未税金额]、[税额]是必须和金税系统中开出的票保持一致。如果不一致的话，你就得象祥林嫂讲阿毛的故事一样，得谁给谁解释，没完没了。
哪么这三个数中，[含税金额]双方系统是不会有出入的，是定值。问题就是[未税金额]可能双方系统计算出来有差异。
没关系，手工更改[未税金额]，改成和金税系统中的一致。
[含税金额]正确、[未税金额]正确、[税额]是减出来，必然正确。
[未税单价]：=[未税金额]/数量
随便算吧，手工改了[未税金额]后，就联动计算[未税单价]，单价一般在保留两位小数位时，是不会出现误差的。就算有也无足挂齿。因这东西在ERP后续的处理中不起任何作用(但愿您也把它设计成不起作用。如果您把它设计成计算的依据，哪您就歇菜了)。
我们来总结一下联动关系：
[数量]、[含税单价]变动，联动计算更新[含税金额]；
[含税金额]变动后，是否反算[含税单价]，可以设置参数来控制。
[未税金额]是计算项，但结果可手工更改。
其=[含税金额]/1.17，但要注意，改动后不得反算税率及含税金额，这是死规则，必须设计成这样。
[税额]是计算项，=[含税金额]-[未税金额]；
可改，改后会反算[未税金额]，但不能动[含税金额]；
打字很辛苦，剩下的就不说了，最关键就是[含税金额]、[未税金额]、[税额]这三项要和金税系统一致，而这三项中的后两项也是最易出问题的。
哪么，与这相关的规则还有：
价格不含税时的处理方式。
税还分为“价内税”，“价外税”，处理也有不同。
每个发票行计算出来了，在计算整个发票各栏目合计数值时，在某些情况下也要考虑特殊的处理规则（很重要，处理不好，合计统计销售收入及税额时，或者分配计算时，还会有尾差问题）。
这些规则都是上世纪九十年代中后期成熟得掉碴的规则了。
说得太多了，但愿能帮上楼主。 |
|
楼主: wo23le
IP卡
狗仔卡
发表于 2008-4-22 16:04
显身卡
