博客园_Farseer

WPF DataGrid格式化数字类型

2012-02-18T22:28:00Z

对于数字类型，WPF里的DataGrid不像AX那样可以自动格式化，需要写代码自己处理，AX这样的小众平台都能做到，WPF为啥要每个程序员自己折腾，可能是要考虑每个人的喜好吧。

主要是Bingding里的StringFormat和Setter。

本文链接

数据库日志

2012-02-16T12:06:00Z

很多时候需要追踪记录的变更情况，AX里有数据库日志来完成这件事情，操作路径为:系统管理->设置->数据库日志.
如果按照向导添加后没看到相应的记录，可以尝试如下方法，选中生命科学电子签名。

系统管理->设置->系统->配置->生产系列1->生命科学电子签名

本文链接

WPF DataGrid UpdateSourceTrigger

2012-02-13T13:55:00Z

WPF通过Binding实现控件和ViewModule（Module）数据源的双向同步，如果想在数据源中的数据变更时及时通知控件，需要类实现INotifypropertychanged接口，如果数据源是个集合，在集合中的数据变更时也想刷新控件，则该集合需要是Observablecollection。

如果用户更改前台控件的值，什么时候通知后台的数据源呢？
这个就是UpdateSourceTrigger这枚举类型来决定的。
关于此枚举的具体类型，可参照

http://msdn.microsoft.com/zh-cn/library/system.windows.data.binding.updatesourcetrigger.aspx

本文链接

AX2009直接交运的bug

2011-08-21T10:02:00Z

最近遇到一个直接交运过账的问题，应该是AX2009系统的bug。
背景：
如果需要把采购的物料直接由供应商交付给客户，需要用到直接交运功能，AX2009的实现方式是采购订单收货的地址直接写客户的地址，在采购订单过账装箱单时自动过账销售订单的装箱单。
问题重现:
环境：

操作系统：Windows 2003
AX2009: SP1+RU7 5.0.1500.4570
数据：使用AX2009的DEMO数据库的CEU公司
1.创建一个销售订单

2.创建销售订单行
选择1000和5008两个物料

3.设置销售订单为直接交运

4.创建直接交运的采购订单,功能->创建直接交运
5.自动产生两个采购订单，分别对应销售订单的一行

6.通过应付账款->期间->过账装箱单，同时过账两个采购订单

7.点击确定，问题出现如下：

原因分析：
整个过程采用的都是AX2009的标准功能，从整个操作看也没有什么不妥之处，从业务上看，创建销售订单，直接交运，两个供应商同时发货给了客户，于是在系统里选择这两个采购订单过账装箱单，这个在业务上也是合情合理的，但是AX2009为什么给出了这么一个奇怪的报错，超交？让人有点丈二和尚。
1.查看采购订单和销售订单行的过账情况：
采购订单：

销售订单：

从上面两个图看，第一个采购订单000385及其对应的销售订单行已经顺利过账，事务已经提交，问题出在过账第二个采购订单时。从系统的报错看，过账第二个采购订单的时候，它在尝试过账1000这个物料，但是第二个采购订单关联的物料是5008，这个采购订单跟1000物料没有一毛钱的关系。
从这里猜测看应该是在过账第二个采购订单关联的销售订单时错误地选择了销售订单行，把本不应该过账的1000再次过账了，其实只过账5008这个行就可以了。
代码分析
AX2009的代码称这种直接交运的过账为internalPosting，因为这个过账是在同一个公司下，对于不同公司间交易的过账称之为externalPosting。
过账采购订单对应的销售订单的代码在PurchFormLetter_PackingSlip的intercompanyPost，如果采购订单是直接交运的，就会调用InterCompanyPostSales过账相应的销售订单.
接下去看类InterCompanyPost的formletterCollect方法，整个方法执行后的最终结果是找到需要过账的销售订单，查找的逻辑是根据VendPackingSlipTrans的

InventRefTransId找到相应的销售订单行,进而得到销售订单。至于VendPackingSlipTrans 的InventRefTransId是从哪里来的，就要去看PurchFormLetter_PackingSlip的writeJournlLine方法了，该方法中有initFormPurchLine的调用，也就是说这个InventRefTransId是从PurchLine的InventRefTransId来的，而PuchLine的InventrefTransId是创建直接交运的时候产生的，整个值也就是对应的销售订单行的InventTransId.
从这段代码看，只是找到了需要过账的销售订单并将其放到Map中，但并未限定只过账本次过账的采购订单对应的行。
接下去看，是否还有地方可以限定，interCompanyPost最终会调用SalesFormLetter的update方法，这个方法是用来过账销售订单的简单的API，该方法会构造出适当的SalesParmUpdate,SalesParmTable，SalesParmLine等记录，用来过账销售订单。
那么产生这些记录的时候会不会有限定只过账本次采购订单对应的销售订单行的语句呢？限定的语句在SalesFormLetter的updateQueryBuild方法中：

if (interCompanyMap)
        {
            mapSalesRecordEnumerator = interCompanyMap.getEnumerator();

            while (mapSalesRecordEnumerator.moveNext())
            {
                localSalesTable = mapSalesRecordEnumerator.currentValue();
                chooseLines.query().dataSourceTable(tablenum(SalesTable)).addRange(fieldnum(SalesTable, SalesId)).value(queryValue(localSalesTable.SalesId));
                noSelected++;
            }

            this.callerFormDataSource(null);

            if (noSelected > 1)
                this.defaultGiroType(NoYes::Yes);
            else
                this.defaultGiroType(NoYes::No);
        }

可以看出这段方法就是把interCompanyPost的formletterCollect得到的SalesId在这里做了限定，也就是让SalesFormLetter只过帐采购订单对应的销售订单。
但是依然没看到过滤销售订单行，让只跟本次过账的采购订单关联的销售订单行过账。
这样错过了第二次机会。
这样就只能依靠在正式过账前的最后一次过滤来限定了，这个过滤发生在创建SalesParmLine时，因为要判断本次销售订单行要过账的数量，如果能在这个时点过滤也是可以的。
创建SalesParmLine的方法是在SalesFormLetter的CreateParmLine方法

if (interCompanyParmId
        && !this.interCompanyParmSelectFromJournal())
        {
            localSalesParmLine.Closed = this.interCompanyParmLineClosed(_salesLineOrig);
            [localSalesParmLine.DeliverNow, localSalesParmLine.RemainBefore      , localSalesParmLine.RemainAfter]        = this.qtySales  (_salesLineOrig, this.interCompanyParmLineQty(_salesLineOrig));
            [localSalesParmLine.InventNow , localSalesParmLine.RemainBeforeInvent, localSalesParmLine.RemainAfterInvent]  = this.qtyInvent (_salesLineOrig, this.interCompanyParmLineQty(_salesLineOrig, true));
            salesLine.SalesDeliverNow = localSalesParmLine.DeliverNow;
            salesLine.setInventDeliverNow();
            if (localSalesParmLine.Closed)
            {
                localSalesParmLine.RemainAfter = 0;
                localSalesParmLine.setRemainAfterInvent();
            }
        }

其中决定本次要过账数量的方法是interCompanyParmLineQty，过账装箱单数量的方法在SalesFormLetter_PackingSlip

select forceplaceholders InventQty, Qty from vendPackingSlipTransLocal
               where vendPackingSlipTransLocal.InventTransId        == salesLineLocal.InventRefTransId
        exists join vendPackingSlipJourLocal
               where vendPackingSlipJourLocal.PackingSlipId         == vendPackingSlipTransLocal.PackingSlipId
               &&    vendPackingSlipJourLocal.DeliveryDate          == vendPackingSlipTransLocal.DeliveryDate
               &&    vendPackingSlipJourLocal.PurchId               == vendPackingSlipTransLocal.PurchId
               &&    vendPackingSlipJourLocal.InternalPackingSlipId == vendPackingSlipTransLocal.InternalPackingSlipId
               &&    vendPackingSlipJourLocal.ParmId                == interCompanyParmId;

这个语句是查询vendPackingSlipTrans表里的记录，条件是inventTransId等于salesLine的InventRefTransId并且ParmId等于过账采购订单时产生的ParmId。
这个语句可以过滤只过账当前采购订单对应的销售订单行吗？
不能。
因为是同时过账两个采购订单000385和000386，按照AX2009的过账逻辑和数据结构，过账时用的是同一个parmId，这样不论是1000还是5008，在过账第二个采购订单时，上面的语句都会得到过账的数量，这样1000就重复过账了，于是提示超交了。
这样三个地方可以过滤只过账当前过账的采购订单对应的销售订单行的地方都没过滤，于是问题产生了。
解决方法
分析原因后就比较容易解决了，在上述三个地方的任意一个地方进行过滤就可以了。IntercompanyPost类修改比较麻烦，在CreateParmLine的修改属于事后补救，所以感觉在SalesFormLetter的updateQueryBuild这个地方过滤比较好。

本文链接

出差费用管理模块的几个问题

2011-06-01T15:08:00Z

出差费用管理模块主要分为两个部分支出和预付，一般公司称之为报销和请款，也就是出差之类费用的报销和出差前向公司预支一部分现金。AX的出差费用管理模块基本能满足一般公司的请款和报销需求。

一般业务上需要满足如下功能：
1.提供界面让用户可以输入请款和报销
2.提供审批功能
涉及到公司钱的问题，一般需要审批
3.请款和报销需要在总帐上有所体现，也就是生成相应的日记帐和凭证
4.请款和报销需要核销，正如预收和应收需要核销一样。
第1点和第2点介绍跟其他模块没啥大的区别，这里就不赘述了，唯一的区别可能就是出差费用管理模块的输入只能在EP上做。
对于第3点，与其它模块一样，生成的日记帐的借贷科目需要提前设好，不可能要求用户在录入单据的时候自己去选择费用科目，用户更习惯选择的是费用类别之类，至于对应哪个科目是财务要关心的事情，于是很自然借方的科目就有地方设置了，嗯，需要在费用类别那地方挂一个费用科目
AX的操作路径：
出差费用管理->设置->支出条目->支出类别

接下来就是贷方了，贷方也就是这个费用是谁来承担的，一般情况下我们员工报销应该是员工承担了这部分费用，所以一般贷记员工的应付就可以了。
AX费用管理模块如果要贷记员工，需要在员工窗体关联一个供应商帐户，每个员工对应一个供应商帐户，虽然不是很喜欢这种处理方式，因为相当于所有的员工要对应一个供应商帐户，怎么看怎么别扭，但是为了使用标准的应付模块来给员工付款，也想不到更好的实现方式，如果用财务维度做辅助核算，每个公司对维度的使用情况又不同，很难做到标准化，于是这种笨拙的方式也是无奈之举。
出差费用管理->设置->员工详细信息

当然除了贷记员工外，还可以由公司或者第三方供应商帮忙承担了费用，这样的话就需要贷记公司的银行账户或者第三方供应商账户，到底贷记员工还是公司或者第三方供应商，这个也应该有个地方定义。
操作路径:出差费用管理->设置->支出条目->付款方式

付款方式里支出所有者这个字段只是个描述字段不起决定作用，重要的是对方科目类型和对方科目。
员工：如果选择了员工，则对方科目不能选择，因为系统会直接贷记到在员工窗体设置的供应商。
分类帐：选择了分类帐，需要指定一个过账科目，这样就会贷记到一个固定的会计科目。
银行：如果是公司支付了费用，则指定一个银行科目，生成的凭证会直接贷方会记到指定的银行科目。
所以通常情况下，对方科目类型选择员工就可以了。
在支出类别处关联一个默认的付款方式，这样只要用户选择一个费用类别，要生成凭证的借方和贷方科目就都有了。

另外，在安装完EP后，默认的预付功能不能用，说找不到页面之类，这是因为安装程序没有正确创建预付和预付审批对应的子站点导致的，在AOT上重新部署一下就可以了。

本文链接

远程启动SSIS包

2011-06-01T01:43:00Z

在前面介绍的一篇文章中介绍了用代码启动SSIS包的方法,http://www.cnblogs.com/Farseer1215/archive/2010/11/08/1871464.html,其中第二种方法必须在安装了SSIS组件的服务器上运行.

如果这样处理的实用性不是很强,不可能在每一台客户机上都装一个SSIS组件,所以最好的办法是在安装了SSIS组件的服务器上安装一个服务,其他客户端调用即可,于是可以考虑用WCF写一个小程序来运行SSIS包,其他的客户端直接调用服务。
1.创建WCF服务
在VS2010中选择创建WCF服务库,这时VS会用WCF库的模板创建一个项目,配置文件，接口和类实现都已经创建好，唯一要做的是事情是实现自己的逻辑。
要想启动SSIS需要用到ManagedDTS这个类库，添加对Microsoft.SqlServer.ManagedDTS这个DLL 的引用。

在接口定义中定义相应的操作和数据契约，在类中实现这些接口，定义了如下两个方法：

public SSISPackageResult ExecSSISPackage(string _packageName)
        {
            SSISPackageResult result = new SSISPackageResult();
            try
            {
                Application application = new Application();
                Package package = application.LoadFromSqlServer(_packageName, ".", null, null,null);
                result.Execresult = package.Execute();

                if (result.Execresult == DTSExecResult.Failure || result.Execresult == DTSExecResult.Canceled)
                    result.ExecInfo = string.Format("SSIS包{0}运行失败，请查看包运行日志！",_packageName);
                else
                    result.ExecInfo = string.Format("SSIS包{0}运行成功",_packageName);
            }
            catch (Exception ex)
            {
                result.Execresult = DTSExecResult.Failure;
                result.ExecInfo = string.Format("SSIS包{0}运行失败，具体异常信息为:"+ex.Message.ToString());
            }

            return result;
        }

public SSISPackageResult ExecSSISPackageWithParam(string _packageName, string _variableName, string _variableValue)
        {
            SSISPackageResult result = new SSISPackageResult();
            try
            {
                Application application = new Application();
                Package package = application.LoadFromSqlServer(_packageName, ".", null, null,null);
                package.Variables[_variableName].Value = _variableValue;
                result.Execresult = package.Execute();

                if (result.Execresult == DTSExecResult.Failure || result.Execresult == DTSExecResult.Canceled)
                    result.ExecInfo = string.Format("SSIS包{0}运行失败，请查看包运行日志！",_packageName);
                else
                    result.ExecInfo = string.Format("SSIS包{0}运行成功",_packageName);
            }
            catch (Exception ex)
            {

                result.Execresult = DTSExecResult.Failure;
                result.ExecInfo = string.Format("SSIS包{0}运行失败，具体异常信息为:"+ex.Message.ToString());
            }
            return result;
        }

2.创建承载WCF服务的Windows服务

WCF服务的宿主可以是IIS,Windows Services,Windows Form甚至控制台命令程序，考虑到并不是所有服务器都会安装IIS，SRS2008也不再依赖于IIS，Windows Form和控制台命令程序控制起来不方便，所以采用Windows Services做为WCF服务的宿主程序。
在解决方案中加入一个新的项目WS_SSIS，项目模板采用Windows服务,添加对项目WCF_SSIS和System.ServiceModel的引用,在OnStart方法中添加启动WCF服务的代码:

ServiceHost serviceHost = new ServiceHost(typeof(SSISService));
serviceHost.Open();

因为System.Configuration不支持库的配置文件为服务增加一个配置文件，把WCF服务的配置文件内容拷贝过来。

为了安装服务，增加如下类，需要添加对程序集System.Configuration.Install的引用：

[RunInstaller(true)]
    public class SSISServicesInstaller:Installer
    {
        private ServiceProcessInstaller process;
        private ServiceInstaller service;

        public SSISServicesInstaller()
        {
            process = new ServiceProcessInstaller();
            process.Account = ServiceAccount.LocalSystem;

            service = new ServiceInstaller();
            service.ServiceName = "SSIS Service";
            service.Description = "该服务用来执行SSIS包完成相应的数据整合任务";

            Installers.Add(process);
            Installers.Add(service);
        }
    }

这样在用InstallUtil.exe安装服务时会自动添加相应的服务，在Win7或者Windows2008上安装服务时要注意使用管理员运行InstallUtil，否则会出错。

运行后会在服务中添加SSISService：

安装时让SSIS服务木运行在本地服务帐户下，可根据实际情况修改服务的运行帐户，让其可以正确访问SSIS，然后启动服务。
3.创建WCF客户端调用WCF服务完成操作
可以用多种方法来实现在AX中调用WCF服务，可以先用C#写个DLL，使用添加服务生成代理类，然后用代理类调用WCF服务，然后在AX中引用该DLL。AX2009也支持直接添加服务引用，自动生成代理类供调用WCF服务使用。
AOT->References->添加服务引用

填写正确的信息:

其中WSDL URL就是WCF向外提供服务的URL地址，具体的详细信息参见WCF的相关知识。
.NET 代码命名空间在AX生成的代理类的命名空间，这个可以按照自己的习惯随便取名。
点击确定：

这样正确生成了调用WCF服务需要的客户端程序。
4.调用服务
写一个类调用WCF服务

static server void main(Args _args)
{
    InterOpPermission                   interop = new InterOpPermission(InteropKind::ClrInterop);
    SSISClient.ISSISServiceClient       ssisServiceClient;
    SSISClient.SSISPackageResult        packageResult;
    str bb;
    ;
    interop.assert();

    ssisServiceClient = new SSISClient.ISSISServiceClient();
    packageResult = ssisServiceClient.ExecSSISPackage("InventTable");

    info(packageResult.get_ExecInfo());

    CodeAccessPermission::revertAssert();

}

运行结果如下：

本文链接

AX2012安装

2011-04-17T08:16:00Z

从Partersource上当了AX2012的Beta版，安装了一下，顺便记录一下安装过程。
由于AX2012的的结构有了比较大的变化，比如把Application files移到了SQL Server中，不再支持Oracles数据库，Workflow的运行时直接集成到AOS中，而不再需要放到IIS站点中，安装程序也有了相应的变化，安装手册里列举了几个安装程序的几个改进。
比如提供了一个一次性校验安装AX2012组件所需要提前安装的程序。

选择想安装的组件，点击验证按钮：

会出现很多个组件让你安装：

1.安装数据库
正如前面提到的AX2012把AOD之类的源文件放到了数据库中保存，并且使用了Module的方式，这个还不是很明白怎么玩的，稍后再看看。

其中BaseLine Database Name是将X++代码升级到AX2012或者在应用补丁前进行分析用的，暂时不知道这个数据库怎么用，安装之后，AX2012和AX2012Module两个数据库的表完全相同，只不过AX2012Module这个数据库没数据。
由于把Application和Database的安装整合到了一起安装，所以速度有些慢，装了差不多10分钟的样子。

2.安装AOS
AOS的安装界面改变得不多，只是多了两个服务端口。

安装完客户端后的初始化CheckList如下：

安装好的AX2012如下图所示：

可能是Beta版的缘故，截面显得有些丑陋，并且与AX2009差异比较大。
另外安装组件里有Office的Add-in，安装完成后，会在Excel和Word里多一个Dynamics AX的标签页，如下图所示：

本文链接

AX2012学习笔记-Date Effectiveness(有效期间)

2011-04-10T09:16:00Z

这是个很有趣的更新，虽然不是必需的，但确实会给开发带来一定的便利，统一代码的书写方式。
在ERP中很多数据是时间相关的，比如贸易协定，汇率，利息等，都有一个有效期的概念。
一般我们的处理方式是增加两个字段FromDate和ToDate,用来表示这个当前记录的有效期间，然后在ValidateWrite或者insert方法中通过代码防止多条记录间日期重叠和间隔的问题。
AX2012在系统层面增加了对这个功能的支持，在表的属性中增加了ValidTimeStateFieldType，有些类似于现有的CreatedBy之类的属性，选择了之后会自动创建ValidFrom和ValidTo两个字段，结合索引的使用，可以自动对日期的重叠和间隔做处理。
虽然增加了一些平台本身的复杂度，不过可以统一代码，对这类问题有个统一的处理方式，也算是个不错的更新。

本文链接

AX2010学习笔记-Surrogate Key(代理键)

2011-04-10T04:10:00Z

得到了一些AX2012的What's new教程，但还没拿到AX2012的安装程序，只能根据教程臆断一下，由于只是根据教程，没有程序作测试，所以很难理解它的意思，等拿到安装程序后再测试验证。

关于开发部分，刚看了一下它的第四章Data Access，这一章主要介绍了如下内容：
1.Surrogate Key，代理键
2.Table Inheritance，表继承
3.Date Effective，有效期

感觉AX2012的数据访问部分增加了很多新鲜东西，在很大程度上改变了开发的模式，但是这样带来的复杂度是否会大于便利是值得考量的，我不喜欢无限制地给语言增加复杂度，X++本来就是用于ERP业务的快速开发工具，没必要把它弄成一个大而全的语言，不过微软要把它变成C#，那也没办法。

这篇文章主要介绍一下代理键的内容。
其实代理键不是个新鲜事物，它是针对Nature key提出的，在设计表的时候到底是以业务相关的字段作为主键还是用一个随机的流水号做为主键。我觉得这两种方式其实各有利弊，不能简单地说代理键理论就比自然键强很多。其实很多情况下，自然键和代理键也没有严格的区分。在ERP的经典建议中，有关于物料号的讨论，一般建议用流水号作为物料号，虽然物料号是物料的一个属性，与业务相关，但是用流水号来作为它的值，其实也就是代理键了。
在BI的维度表中常使用自增类型的int（SQL Server 是Identity）作为其代理键。
我想不到在AX里使用代理键的必要性，虽然AX本来就有天然的RecID可以做为其代理键。RecID给我的印象一直是阻碍数据导入速度的东西，如果没有这东西，直接用SSIS系统初始化是非常简单事情，由于RecID要在系统里产生，搞得做初始化只能在AX里做，本来期望这东西能干掉，到AX2012把这玩艺当成主键了，看来是没希望了。
OK，把RecId弄成了代理键，接下来的问题是，不能在客户交易记录窗体里里显示客户信息时用23495867234这样的东西吧？那用户看了估计死的心都有了。AX2012当然会考虑这个问题，看教程里它引入了几个新的属性来处理这事：
1.Surrogate key replacement fields
A set of user readable fields that are displayed instead of the surrogate foreign key. Client forms will use joined data sources to retrieve these fields at query time. The set of fields to use will be defined by a property on the new reference group control.
看这描述应该会给23495867234定义一组值，比如客户编码，客户名称，客户组之类显示在界面上。
2.AutoIdentification Field Group
A new system created field group that is populated by the developer or system with fields that form the default surrogate key replacement fields.
这个组应该类似于现在的AutoLookup组，将来这个组可以显示到界面的相应位置。
截止到AX2009版本，在从表中显示主表信息还是比较麻烦的事情，倒是希望AX2012新引入的表继承和代理键来处理这个问题。但是从教程看窗体上要加入好多个派生的数据源，祈祷速度不会太慢。。。

本文链接

SSRS 2005 400 Bad Request

2010-12-14T12:31:00Z

SSRS2005站点如果全部未分配访问没有问题，如果指定一个IP就会提示400 Bad Request错误，以前也遇到过这个问题，记录一下解决方法：

找到RSWebApplication.config文件，这个文件在SSRS的安装目录下，比如D:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportManager

清除ReportServerVirtualDirectory节点的值，将ReportServerUrl赋值为正确的地址，如下所示：

<UI>
        <ReportServerUrl>http://192.168.0.1/reportserver</ReportServerUrl>
        <ReportServerVirtualDirectory></ReportServerVirtualDirectory>
        <ReportBuilderTrustLevel>FullTrust</ReportBuilderTrustLevel>
    </UI>

本文链接