老规矩先看APICS关于Firm Planned Orders的定义，这样做不是要死读书的意思，只是觉得APICS字典实际上是从很多企业运作场景中提炼出来的，有其实际的意义，另外一个言简意赅的定义也便于大家沟通，不要各说各话，大家就不好交流了，这点类似于GoF的设计模式，并不见得GoF的定义是创建了一个新的设计思维，只是取了个名字让大家便于沟通。
APICS理论
firm planned order(FPO)---A planned order that can be frozen in quantity and time.The computer is not allowed to change it automatically;this is the responsibility of the planner in charge of the item that is being planned.This technique can aid planners working with MRP systems to respond to material and capicity problem by firming up selected planned orders.In addition,firm planned orders are the normal method of stating the master productoin schedule.
翻译一下大体的意思，一个计划订单在数量和时间上被冻结，不允许计算机自动对其修改,这是负责计划该物料的计划员的职责。这个技术可以帮助计划员通过确认选择的订单的方式来对物料和能力问题做出反映。除此之外，一确认订单也是标识MPS状态的一个通常采用的方法。
在<<MRPII Standard System>>中有两章专门论述Firm Planned Orders，第9章和第15章。这两章对Firm Planned Orders有比较详细的论述，下面摘录总结如下：
已确认计划订单给计划员提供了一个覆盖MRP系统逻辑的工具。在大多数情况下，正常的计划逻辑工作的很好，计算得到的计划订单的交货日期是所需要的，订单的开工日期是交货日期减去物料的提前期，计划订单数量应该是按照该物料的订购策略得到。在某些情况下如果通过正常的计划逻辑已经不能反映现实的状况，那么需要提供一种手段让计划员去按照自己的意愿去修改计划订单的日期和数量，并冻结某些订单而不让计算机去修改。
已确认计划订单结合了预计接收量和计划订单的特性，同预计接收量(Scheduled Receipt就是已经下达的生产订单或者采购订单之类)类似，已确认计划订单不会自动重排到一个更早或者更晚的日期，而是产生一个异常信息供计划员浏览。但与预计接收量不同的是，已确认计划订单不产生组件（子物料）的分配(Allocation，也就是AX里的预留)，而是分解为组件的毛需求，组件毛需求的产生机制跟计划订单一样。
计划员应该可以指定一个已确认计划订单的任意的开工或者交货日期，数量或者提前期。或者更改订单的状态，比如把计划生产订单改成计划采购订单，反之亦然(个人觉得，这个没办法反之亦然，原来是生成的是计划采购订单，那么说明这个物料的物料类型是物料，连BOM都没有怎么生产？)
另一段逻辑是，如何处理重排假设(关于重排假设在上一篇文章中有所阐述)，这本书的观点是在重排的时候应该先考虑预计接收量再考虑已确认计划订单，作者提到有些系统采用的逻辑是按照完工日期从早到晚的顺序，这是不对的，作者也提到了，实际上也是没什么问题的，因为很明显，一般已经开工的生产订单显然要比一个还没下单的已确认订单的完工日期要早，所以排在前面的一定是预计接收量而不是已确认计划订单。
AX中的实现
AX的计划订单有个状态，该状态有三个值：未处理，已处理和已审核 三个状态，如下图所示：
我们还以上文使用的物料RA为例说明，创建一个销售订单，交货日期为2009-09-30，数量为200.运行Master Planning.得到计划采购订单如下：
做为测试，把数量改成300，然后把状态改成已处理，如下图所示：
我们看一下把状态改成已处理是不是可以把计划订单变成已确认的计划订单修改完成后，重新运行Master Planning,查看结果：
显然，变成已处理后，计划订单没有变成已确认计划订单，因为我们修改后的记录被删掉了，重新生成了记录，于是我们寄希望于已审核能实现APICS里提到的已确认计划订单。重复前面的步骤，把数量变成300，状态变成 已审核：
重新运行Master Planning,结果如下：
正如我们所期望的那样，已审核的计划订单没有被删掉重建了，也就是说已审核的计划订单应该是APICS里提到的已确认计划订单。
我们还是要验证一下这个已审核的计划订单的重排假设是否符合APICS的说法，因为第二次运行Master Planning的时候，我们把数量修改为300的这个计划订单如果就是APICS已确认计划订单的话，那么AX应该会给一个重排假设，并且按照<<MRPII Standard System>>的说法，重排假设的逻辑应该跟预计接收量的逻辑是一样的，所以按照AX的逻辑，应该产生一个异常消息，告诉计划员把数量减少100个，因为需求是200，我们查看 查询->需求模版
所以这样看来，还是符合APICS的重排假设的。
接下来，我们需要验证如果系统中已经存在了预计接收量也存在已确认计划订单，那么AX是如何做重排假设的。
由于已经存在的已确认计划订单的交货日期是2009-09-30，所以我们做两个测试，一个采购订单的交货日期在此之前，一个在此之后。
我们先创建一个交货日期为2009-09-20的采购订单，数量为100，看AX如何处理，这个采购订单就是预计接收量了，我们运行Master Planning，看AX在处理重排假设的时候，如何处理已确认计划订单和预计接收量，按照<<MRPII Standard System>>的说法，应该是先考虑预计接收量，再考虑已确认计划订单.
显然，AX建议把已确认计划订单取消，而把采购订单延后并增加数量，那么如果采购订单的日期在已确认计划订单的后面，结果会怎么样那？我们把采购订单的交货日期改成2009-10-05，运行AX的Master Planning，查看需求模板，结果如下：
从上图可以看出，AX还是建议修改预计收货量，把已确认计划订单取消。
结论
从以上测试来看，已审核状态的计划订单就是APICS里提到的已确认计划订单，至于已处理状态，应该是个中间状态，MRP的逻辑在重算时会删掉已处理状态的计划订单，所以这个状态应该只存在于两次运行MRP之间，让主计划员做标识用的，在运行MRP之前一定要更改这个已处理的状态，要不然就白修改了，因为运行MRP会把它删掉。
从重排逻辑看，如果系统中不存在预计收货量，那么AX处理已确认计划订单的逻辑跟预计收货量一样，会给出针对已确认订单的重排逻辑，提前或者延后之类的，如果系统中存在预计接收量，那么AX会对预计接收量给出提示消息，而要求把已确认计划订单取消，这时AX把已确认计划订单当成了普通的计划订单。我觉得这也是合理的，因为毕竟这个订单还没有下达。
综上所述，我个人觉得AX的已确认订单的逻辑跟APICS的要求还是比较契合的。
APICS理论
firm planned order(FPO)---A planned order that can be frozen in quantity and time.The computer is not allowed to change it automatically;this is the responsibility of the planner in charge of the item that is being planned.This technique can aid planners working with MRP systems to respond to material and capicity problem by firming up selected planned orders.In addition,firm planned orders are the normal method of stating the master productoin schedule.
翻译一下大体的意思，一个计划订单在数量和时间上被冻结，不允许计算机自动对其修改,这是负责计划该物料的计划员的职责。这个技术可以帮助计划员通过确认选择的订单的方式来对物料和能力问题做出反映。除此之外，一确认订单也是标识MPS状态的一个通常采用的方法。
在<<MRPII Standard System>>中有两章专门论述Firm Planned Orders，第9章和第15章。这两章对Firm Planned Orders有比较详细的论述，下面摘录总结如下：
已确认计划订单给计划员提供了一个覆盖MRP系统逻辑的工具。在大多数情况下，正常的计划逻辑工作的很好，计算得到的计划订单的交货日期是所需要的，订单的开工日期是交货日期减去物料的提前期，计划订单数量应该是按照该物料的订购策略得到。在某些情况下如果通过正常的计划逻辑已经不能反映现实的状况，那么需要提供一种手段让计划员去按照自己的意愿去修改计划订单的日期和数量，并冻结某些订单而不让计算机去修改。
已确认计划订单结合了预计接收量和计划订单的特性，同预计接收量(Scheduled Receipt就是已经下达的生产订单或者采购订单之类)类似，已确认计划订单不会自动重排到一个更早或者更晚的日期，而是产生一个异常信息供计划员浏览。但与预计接收量不同的是，已确认计划订单不产生组件（子物料）的分配(Allocation，也就是AX里的预留)，而是分解为组件的毛需求，组件毛需求的产生机制跟计划订单一样。
计划员应该可以指定一个已确认计划订单的任意的开工或者交货日期，数量或者提前期。或者更改订单的状态，比如把计划生产订单改成计划采购订单，反之亦然(个人觉得，这个没办法反之亦然，原来是生成的是计划采购订单，那么说明这个物料的物料类型是物料，连BOM都没有怎么生产？)
另一段逻辑是，如何处理重排假设(关于重排假设在上一篇文章中有所阐述)，这本书的观点是在重排的时候应该先考虑预计接收量再考虑已确认计划订单，作者提到有些系统采用的逻辑是按照完工日期从早到晚的顺序，这是不对的，作者也提到了，实际上也是没什么问题的，因为很明显，一般已经开工的生产订单显然要比一个还没下单的已确认订单的完工日期要早，所以排在前面的一定是预计接收量而不是已确认计划订单。
AX中的实现
AX的计划订单有个状态，该状态有三个值：未处理，已处理和已审核 三个状态，如下图所示：
我们还以上文使用的物料RA为例说明，创建一个销售订单，交货日期为2009-09-30，数量为200.运行Master Planning.得到计划采购订单如下：
做为测试，把数量改成300，然后把状态改成已处理，如下图所示：
我们看一下把状态改成已处理是不是可以把计划订单变成已确认的计划订单修改完成后，重新运行Master Planning,查看结果：
显然，变成已处理后，计划订单没有变成已确认计划订单，因为我们修改后的记录被删掉了，重新生成了记录，于是我们寄希望于已审核能实现APICS里提到的已确认计划订单。重复前面的步骤，把数量变成300，状态变成 已审核：
重新运行Master Planning,结果如下：
正如我们所期望的那样，已审核的计划订单没有被删掉重建了，也就是说已审核的计划订单应该是APICS里提到的已确认计划订单。
我们还是要验证一下这个已审核的计划订单的重排假设是否符合APICS的说法，因为第二次运行Master Planning的时候，我们把数量修改为300的这个计划订单如果就是APICS已确认计划订单的话，那么AX应该会给一个重排假设，并且按照<<MRPII Standard System>>的说法，重排假设的逻辑应该跟预计接收量的逻辑是一样的，所以按照AX的逻辑，应该产生一个异常消息，告诉计划员把数量减少100个，因为需求是200，我们查看 查询->需求模版
所以这样看来，还是符合APICS的重排假设的。
接下来，我们需要验证如果系统中已经存在了预计接收量也存在已确认计划订单，那么AX是如何做重排假设的。
由于已经存在的已确认计划订单的交货日期是2009-09-30，所以我们做两个测试，一个采购订单的交货日期在此之前，一个在此之后。
我们先创建一个交货日期为2009-09-20的采购订单，数量为100，看AX如何处理，这个采购订单就是预计接收量了，我们运行Master Planning，看AX在处理重排假设的时候，如何处理已确认计划订单和预计接收量，按照<<MRPII Standard System>>的说法，应该是先考虑预计接收量，再考虑已确认计划订单.
显然，AX建议把已确认计划订单取消，而把采购订单延后并增加数量，那么如果采购订单的日期在已确认计划订单的后面，结果会怎么样那？我们把采购订单的交货日期改成2009-10-05，运行AX的Master Planning，查看需求模板，结果如下：
从上图可以看出，AX还是建议修改预计收货量，把已确认计划订单取消。
结论
从以上测试来看，已审核状态的计划订单就是APICS里提到的已确认计划订单，至于已处理状态，应该是个中间状态，MRP的逻辑在重算时会删掉已处理状态的计划订单，所以这个状态应该只存在于两次运行MRP之间，让主计划员做标识用的，在运行MRP之前一定要更改这个已处理的状态，要不然就白修改了，因为运行MRP会把它删掉。
从重排逻辑看，如果系统中不存在预计收货量，那么AX处理已确认计划订单的逻辑跟预计收货量一样，会给出针对已确认订单的重排逻辑，提前或者延后之类的，如果系统中存在预计接收量，那么AX会对预计接收量给出提示消息，而要求把已确认计划订单取消，这时AX把已确认计划订单当成了普通的计划订单。我觉得这也是合理的，因为毕竟这个订单还没有下达。
综上所述，我个人觉得AX的已确认订单的逻辑跟APICS的要求还是比较契合的。