AX2009 SP1销售增值税的问题

客户销售订单的数据量比较大，一个销售订单有3000多行的样子，用代码插入后，查看增值税没动静了，以为死机了强行关掉，如此往返几遍问题依然。于是在TradeTotals的calc方法里加一段代码写日志文件的代码，记录处理时间和条数。发现日志文件还是在不断增加的，于是知道它没死循环或者死锁，应该是速度慢，于是放之让其自己跑，大约过了2个小时，终于跑完了，分析日志文件，前1000条记录还凑合，运行时间不是很长，从1000条开始就需要1S才能处理一条记录的销项税，等到了2000条，就需要2S才能处理一条数据了。

应该是里面有一段代码的效率有问题，把TradeTotals的calc翻了一遍，应该是下面这段代码有问题：

this.sumAmountByItemType_BR(lineAmount);

下面是它的实现：

// <GBR>
protected void sumAmountByItemType_BR(AmountCur _amount)
{
    SalesCalcTax_Sales  salesCalcTax;
    Common              line;
    ;

    salesCalcTax = this.constructCalcTax();

    salesCalcTax.parmSalesTotals_BR(this);
    salesCalcTax.initCursor();

    line = salesCalcTax.nextLine();

    while (line)
    {
        if (line.RecId == salesParmLine.salesLine().RecId)
        {
            this.amountByItemType_BR(salesCalcTax.baseAmount());
            break;
        }

        line = salesCalcTax.nextLine();
    }
}
// </GBR>

从上面的实现来看，在计算每一个销售订单行的增值税的时候，它都要循环遍历一次之前的销售订单行，找到与当前行匹配的行，这样效率越到后面就越低也在情理之中了。
从代码的注释看，这段逻辑应该是给巴西本地化使用的，属于巴西本地化的功能，AX2009发布的时候GLS层是合并的，各个国家的特性通过配置项去设置，采用合并GLS层的方式发布各个国家的特性这个做法很容易理解，因为AX只有一个GLS的AOD文件，如果写在GLS层的各个国家特性不合并成一个GLS文件的话，一个公司在不同的国家有分公司，比如巴西和中国有分公司，就不好统一部署了。问题是如果都在一个GLS文件里，代码的控制就需要格外小心了，就拿这个例子来说吧，这个导致效率下降的方法是巴西特性的，我没有启用巴西特性，但它依然运行了这段代码，问题在于它运行前忘记判断是否启用巴西特性了，将calc的这行代码加个判断就可以了。

 // <GBR>
            if (BrazilParameters::isEnabled())
            {
                this.sumAmountByItemType_BR(lineAmount);
            }
            // </GBR>

至于里面这段有效率问题的代码，偶就不管了，让巴西的弟兄们去改吧，呵呵。