关于汉化后订单不能在中文状态下审核和打印的原因及处理建议

jianjian1354

    无论是用Alec_H兄弟的翻译成果，还是从WEBERP网站上下载的完整翻译文件，只要是翻译了采购的审核这个栏目的词语的，放到本地目录后，选用中文操作，都不能进行正常的审核和打印操作，经反复测试，也没找到方法，各版本的都有这个问题，后来打开数据库，发现在中文操作下，订单的审核状态是用中文表述的，即表 purchorders 里的字段status里的内容成了中文，由于程序并没有对应中文的判断语句，因此后续的操作都不能进行。
    目前的对策是，修改本地语言文件messages.po，把有关审核的选项的翻译都去掉，如新订单，取消，审核，不可修改等，然后重新生成messages.mo文件，重启系统，这样，相关的操作的选项仍是英文的，后续的操作就可以正常进行。
    至于程序为什么会出现这样的结果，我没看明白，希望高手予以指点。

   后记：该问题已经在4.0版本中解决。

LinOx

是不是你的mo和数据库对汉字的编码方式不一样啊？
应该都设置成 zh_CN.utf8
程序中是有对数据库中中文判断的处理的。
是通过 _() 函数实现的。

jianjian1354

回复 LinOx 的帖子

    我还是没有搞明白，关于程序中对数据库中中文判断的处理的 _() 函数在哪，能不能明确下。

LinOx

这是 PO_Header.php 中的一段代码，目的是判断根据当前订单的状态给出恰当的状态下拉菜单选项

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
        switch ($_SESSION['PO'.$identifier]->Stat) {
                case '':
                        $StatusList=array(_('New Order'));
                        break;
                case _('Pending'):
                        $StatusList=array(_('Pending'), _('Authorised'), _('Rejected'), _('Cancelled'));
                        break;
                case _('Authorised'):
                        $StatusList=array(_('Pending'), _('Authorised'), _('Cancelled'));
                        break;
                case _('Rejected'):
                        $StatusList=array(_('Pending'), _('Authorised'), _('Rejected'), _('Cancelled'));
                        break;
                case _('Cancelled'):
                        $StatusList=array(_('Pending'), _('Cancelled'));
                        break;
                case _('Printed'):
                        $StatusList=array(_('Pending'), _('Printed'), _('Cancelled'));
                        break;
                case _('Completed'):
                        $StatusList=array(_('Completed'));
                        break;
                default:
                        $StatusList=array(_('New Order'), _('Pending'), _('Authorised'), _('Rejected'), _('Cancelled'));
                        break;
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

其中多处用到了 _() 函数。这个函数是 getext 项目的函数，用来将函数值转换成相应的语言，也就是在mo文件中的相应的定义。
这里所有的判断都是根据用户当前语言的。
前提条件是数据库中存储的状态值所使用的语言必须与当前浏览的用户使用的语言相同。

问题来了，不同语言的用户无法操作对同一个订单。
也就是中国人修改了订单的状态，其它国家的人来看都会出问题。

PS
Reject 应该翻译成驳回更恰当一些，而不是不可修改。

jianjian1354

原来如此，为方便使用，看来还是不翻译的好。或者程序不应该处理，像这样需要在程序中使用的数据，建议不要更改原文，而是通过显示的时候翻译过来，可能会更方便些，这样不同语言下的操作就能通用了。

tj198

这是对于webERP的误解。每个登入用户可以选择他自己的语言。gettext会根据用户选择的语言决定显示语言。除非数据库里只有一种语言，对于业务流程而言，根本不存在这种问题。您可以到www.minghao.hk这里看看演示版的实际状况是怎样的。

jianjian1354

回复 tj198 的帖子
        经验证，确实不能进行多语言的互操作，就是登录这个网站，www.minghao.hk，如在英文状态下审核的订单，在中文下打印时，提示“只有授权的采购订单才能够被打印. 此订单目前的状态是 Authorised”，请再核实下。不过审核的状态倒是可以正常更改的。

   

tj198

Jianjian1354兄：

              您说得对。这是系统的一个bug. 已经报告给webERP的开发者列表。
              对于前面的疏忽，非常抱歉。

              

LinOx

昨天晚上抽时间看了看源代码，感觉只要数据库 status 字段中存储英文信息，将上面引用的源代码段 case 后面的 _() 函数去掉，直接用英文字串，再在更新数据库的语句中将 stat 翻译回英文，这样不同语言的用户就都可以查询、更新状态了。
这么修改 会话的PO状态属性应该是用系统指定语言描述的，而不是统一的英文。这样的做的缺点就是频繁地调用 _() 函数，降低系统效率。
如果要将会话的所有不在界面显示的变量都统一成某一种文字（比如英文）只在需要显示的时候调用 _() 函数翻译，那改动估计就大了。

jianjian1354

回复 LinOx 的帖子
        我觉得，一般来说，数据库中的数据大体上有两类，一种是内容性的，如文本或数字，一种是状态性的，内容性的一般来说是什么字符都可以的，只要浏览器支持就可以，而状态性的，由于涉及到判断操作，建议都用数字或英文字母(最好只用数字)，否则就很容易出现上面的这种问题，也给编程带来难度。

   

LinOx

回复 jianjian1354 的帖子

其实改程序也并不麻烦，麻烦的是得找到要改的页面。
另外还得翻译要改相应的内容。
另外会计科目，是不是也要这么处理。
数据库里在建库时预先插入的内容也得处理。
   

jianjian1354

会计科目也是这样的情况，那麻烦就大了，如果会计报表不能多语言同时显示，意味着WEBERP只能在一些区域性的小公司用了。

LinOx

关于会计部分的问题是这样的。
我国的会计体系与欧美的会计体系不同。我国会计体系采用6要素体系，而欧美则是10要素。
因此，会计科目会不同，会计科目的编码更会不同。
看看  weberp/sql/mysql/weberp-new.sql 文件，找找 INSERT 数数插入的判断性数据。
这些都是需要处理的。
这些修改的工作量是不小的。需要建立项目组，多个人共同完成，包括熟悉会计、采购、销售的多方人才。
而最终的修改需要汇入weberp官方发布包，得到weberp的官方认可。或者以项目组的名义发布patch。而所有的工作都是没有报酬的。

tj198

LinOX兄和Jianjian1354兄：

            非常佩服二位对开源项目的热衷与贡献。向您们二位致敬。
              对于会计科目的问题，我的看法如下：
             会计科目是采用会计科目编号的方式引用的。所有的会计科目均设置了会计科目的id,这个大家只要看看会计科目那个栏目就知道了。总帐转账的时候，全部使用的是会计科目编号。包括会计要素，也是如此。唯一一个不同的是科目组，但是这个在资产负债表中查询中，没有发现因为语言的问题导致的影响。因为最终参与运算的，并不是这些项目。至于会计要素是多少，需要设置会计科目，会计账户，这个webERP并没限制的。
       另外，我看到webERP在日本，在西班牙，印度，香港都有使用，它应该有极大的灵活性与适应性。
       个人觉得webERP，同其他非中国原生ERP的一起，系统设置了标准成本法作为主要推广的方法，（当然webERP也支持实际成本法）。这与现在的会计实践有些不同，反而是我们应该重点考虑的。
       其实，前面那个关于订单审核状态的bug,也同样可以将状态定义为状态ID，只是当时webERP的开发人员忽略这个问题。
        其他比如税收设置等，这个问题全被顾及到了。
        一孔之见，仅供大家参考。
        恭祝 六时吉祥！
                                                         

LinOx

就说会计科目，确实有科目编码，但是中国的编码与外国的不同，采用系统设置的外国名称和编码，中国人看不懂，采用中国的名称和编码，外国人看不明白。
而会计要素不同，导致整个的会计基础不同。这个差异就太大了。
如果系统一个实例仅给一国人员使用，遵从一国的会计制度，这没有什么问题，也不会有楼主提出的问题。如果按照12楼提到的非区域性的小公司，恐怕就麻烦喽。看来只有公司总部在哪国就执行哪国的会计制度，这样麻烦就会少一些，而会计科目等判断性数据都用英文，并在mo中进行翻译。
weberp不是不能在中国实施，而是实施需要大家的努力和参与。有大量的二次开发的工作要做啊。

tj198

回复 LinOx 的帖子

LinOx兄：

           关于您讲的会计制度，这已经超出了webERP做为一个工具的范围。每个公司只要在当地运作，都需要遵守当地的法律。我想这个不会有什么疑问。否则问题就太远了。会计模块肯定是有地域性的。

            会计模块只是ERP其中的一个模块，如果需要在各个国家运作的话，这部分不像前面那个订单状态的问题，如果您仔细分析会计科目的设置，引用判断的时候均用会计科目编号，而描述部分全部是字符类型，也就是可以通过gettext翻译的，这不影响系统本身的处理和各个国家的工作人员看到自己属性的文字且具有相同的意义。

             具体问题具体分析，不能因为有一个bug就认为其他的地方也是这样。

             仅供参考！
   

jianjian1354

LinOX和tj198二位兄弟：
        我前面仅仅提到会计报表的多语言同时显示，主要还是各不同语言的操作环境的问题，并不考虑同时提交不同系统的会计报表，这个问题，基本上是在哪纳税，就出具哪的格式的报表，可能需要财务人员单独编制。其实不少专业会计都清楚英文会计名词，所以这部分不翻译也行，只是苦了半路出家的。

tj198

在官方即将发行的新版本中，这个问题已经修正。