sun-web.xml之痛

去年开发的系统，突然出现了问题，问了原来的开发的成员，说时间太久忘了，只要找我，其实我也差不多忘了。

错误主要是在显示系统中详细信息和保存项目的时候，很快就定位是iplanet端数据库连接池配置问题。

于是，让DBA检查，将密码重新设置，没有成功。
让DBA发过来日志有如下错误，可能是sun-web.xml文件有问题，是不是UNIX下字符出现错误，将我本机的这个文件发过去给DBA，没有成功。

WEB0120: XML error parsing deployment descriptor [/~~~~~~~~/wwwroot/WEB-INF/sun-web.xml]
Failed to create the XML-DOM Document. Check your XML to make sure it is correct.
java.net.ConnectException: 连接超时 at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3376) at org.apache.crimson.parser.Parser2.externalParameterEntity(Parser2.java:3064) at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1347) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:656)

最后，重新考虑这个日志的时候，忽略了“java.net.ConnectException: 连接超时 ” 这个错误。怎么会网络访问，重新检查sun-web.xml，发现DOCTYPE节点，其声明的dtd文件是指向http://www.sun.com/的，可能这就是问题所在。以前从来没有注意这个问题，对于DOCTYPE，PUBLIC指定DTD文件是在系统之外，需远程访问；如果是SYSTEM，就在本地找寻dtd文件。虽然在我机器上将网络断开，没有重现这个错误，但是比较肯定系统就是遇到这个问题。将这个节点去掉，将sun-web.xml发给系统管理员，果然成功了！


<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 8.1 Servlet 2.4//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_2_4-1.dtd">

另外，将系统迁移到iplanet的时候，磕磕碰碰，花费了以整体的时间，记录下来以备忘。

1）Iplanet的版本。
从sun的官方网站下载要注册，我原来有帐户但是忘了，于是从别的地方下载了一个。本来是要6.1版本的，下来发现是6.0的，这就是后面很多错误的根源。
部署完成之后，访问系统的时候，总是出现如下错误：
“"No WebApplicationContext found: no ContextLoaderListener registered"”
在web.xml中增加如下内容，可以Iplanet可以成功启动。

<servlet>
<servlet-name>context</servlet-name>
<servlet-class>
org.springframework.web.context.ContextLoaderServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>



但是访问系统的时候，出现Servlet 2.2中不支持setCharacterEncoding() 错误。乖乖，原来IPlanet只支持Servlet 2.2，而我需要的是2.3版本。于是从Sun上下载了6.1颁布，不需要在web.xml增加上述那段，部署成功。

2）数据库连接池的建立
在Iplanet端建立了连接池，出现总是找不到驱动程序的错误，而实际上classes2.jar已经在WEB-INF/lib路径下。最后在JVM Path Settings中将JDBC的路径直接出入，解决这个问题。








3）Iplanet程序的部署。

首先是将Web程序打包成war。但是Iplanet部署war文件的时候有大小限制，可以先不降lib目录打包，待部署完成再拷贝过去。
部署应用。其对应的路径为：
Administration Server > MyServer > vsclass1 > WebApplication。
其中MyServer是系统默认建立的服务器，vsclass1是系统默认建立的虚拟class。可以同时管理n个服务器，一个服务器上又可以建立n个vsclass1，一个vsclass可以对应多个WebApplication。所以，从左到右都是1:n的关系。为什么会有vsclass1的概念呢？ 这是因为对于某些Web Application，其配置可能绝大部分相同，所以可以统一在vsclass层次定义就可，这些Web Applications共享这些设置。这个设计应该是为哪些提供hosting服务的机构设定的吧。但是看看现在hosting，绝大部分都在使用LAMP。
然后就是在vsclass层建立，数据库链接池和JDBC的Resource。
最后别忘了将lib拷贝到Web Application的WEB-INF目录下。


总结，
1) 最初发现问题的时候，虽然大概定位，但是没有再深究问题的根本，再加上时差的问题，问题解决效率不高。
2) 没有模拟服务器环境，而开始只在Tomcat上测试，而sun-web.xml在Tomcat环境下是不需要的，对问题的重现带来困难。
3) 在定位sun-web.xml文件的错误之后，没有静下心来研究文档结构，而是意味怀疑字符问题，耽误解决问题的时间。

Any way，问题总算解决了，休息一下，休息一下。

拷贝定时执行的任务

测试机器上的定期运行的任务停止运行已经有快两个星期，最后一次运行应该是感恩节前了。主要的问题是通过执行程序“Start ClientVantage.exe”再也不能生成计划任务 “Standard Transactions” 了。重新启动，OS升级，杀掉系统中的相关进程都不能。虽然是测试机器，但是数据有时候还是有一定参考意义，今天暂时找到一个方法。

1. 从别的机器上将Windows/tasks下的“Standard Transactions”任务拷贝到测试机器的Windows/tasks目录下。
2. 执行的时候应该会出现“Can not start”的错误，那么就编辑这个任务，将开始时间更改一下，系统会提示让你输入这个操作系统的密码，输入完成确定之后，任务就可以正常执行了。


这只是一个暂时的方法，对于每天重新启动，还是不能应付，再想办法。

怎样disable掉Supplier Item Catalog Window中的标签页

怎样disable掉Supplier Item Catalog Window中的标签页
在采购模块中，如果从菜单Supplier Item Catalog进入，输入条件，点击Find，就会进入如下的界面。在这个界面中，如果我只想要用户只能够看到“Requisition Templates”，应该怎样设置呢？ 手册有这么一段，但是没有说具体怎么做：

========================
There are four tabbed regions in the upper screen of this folder window,but Function Security can be used to determine whether a user will beable to see all of them.

































Metalink的一文：
=============================
Subject: How To Restrict Access To Specific Form's Tab In Oracle Applications 11i?
Doc ID: Note:189420.1 Type: HOWTO
Last Revision Date: 05-AUG-2003 Status: PUBLISHED



Goal: How to restrict access to specific form's tab in Oracle Applications 11i?
Fact: Oracle Application Object Library 11.5


Fix:

Every form's tab represents a function. Function security is controlled by Responsibilities. A system administrator should exclude the form's tab Corresponding function from the menu structure assigned to a responsibility, users belong to this responsibility will not be able to access this form's tab anymore. As an example, the following steps will disable the Costing tab in Orgination Items form for some users:
1. Create a new responsibility and attach INV_NAVIGATE menu to it.
2. Assign the new responsibility to users that will not access the above tab.
3. From System Administrator-->menus-->query INV_NAVIGATE and display the menu tree, drill down items -->Organization Items-->get the display name
of the function corresponding to the Costing tab 'Items:Costing Group'.
4. System Administrator-->Responsibilities-->Define, query the new responsibility and use the Menu Exclusions tab to exclude the function in step 3.
5. Logon to Applications using the new responsibility and navigate to
Organization Items form, the Costing tab is disabled.

采购 -> AutoCreate

Action：
可以将请购单新增文档或则添加到已存在的文档。有两种方式，一种是Create，一种是Add To。




Add To
将新的请购单创建到采购文档T_ClosePoint1，新增加的采购行序号2。



















是否可以将请购单Add To已经存在的采购单，必须依据采购文档的安全设置。如果Access Level为View Only。




那么当点击Manual按钮进行创建的时候，系统提示你选择一个已经存在的文档。如果当前用户原来没有创建采购订单，系统将找不对应的采购订单（因为采购文档的安全设置）













如果采购文档的安全设置为可以修改。那么这个时候再Add To，可以找到你需要将请购单提交进去的采购文档。



Document Type：
已经审批的请购单，可以创建如下4种。未审批的请购单只能创建RFQ。







如果针对为审批未通过的请购单创建Standard PO/Planned PO/Blanket Release，那么将会提示如下提示（Manual和Auto略有不同）。










Grouping：
如果是分组方式Default，在创建采购订单行的时候，将会根据请购单行的Item，Item版本，行类型，单位等进行分组。如果是Requisition，那么每一个请购行将会对应一个采购行。





针对如下两个请购行。




如果Grouping = Default，那么创建采购单的时候，将会分组到一个采购订单行上，采购数量为两个请购数量之和。也就是将两者合并了。

如果Grouping = Requisition，一个采购单行就会对应一个请购单行。上述的两个请购单行，创建了两个采购单行。










Return Requistion：
Path: AutoCreate（M）-> Tools （M）->Return Requisition（M）













Modify：
AutoCreate（M）-> Tools （M）->Modify（M）
将原来的一行分成两行。












完成之后，在AutoCreate窗口只能看到新创建的两行。

但是从Requisition Lines Summary可以看到新创建的两行，和原来存在的一行。

采购 -> Notification Routing Rules

如果审批者由于出差不能及时审批订单，这时候采购员叫天天不应，叫地地不灵。那就叫系统管理员。
一种方法通过“Mass Forwarding Documents”功能，将提交给某一个审批者的订单，批量转发给另外的审批者。

这里讲述的是另外一种方法——Notification Routing Rules。这个功能按钮存在Notification页面上。主要功能就是创建一个Notification路由的规则，对于接收Notification，采取转发，重新分配，或者审批等。如果是系统管理员，那么可以针对任何用户接收的Notification可以创建规则。如果是普通用户，那么只能针对自己的接收的Notification创建规则。
假定，现在你要出差，对于出差这段时间，对所有提交给你审批的采购订单都需要转发到另外一个审批者代劳。那就，开始设置：

1. 点击Notification Summary打开Notification页面，点击页面上的Routing Rules按钮。




2. Routing Rules列表中，点击“Create Rule”来创建一个新的Rule。
在Notification的窗口，有创建Create Notification Rule的按钮。










3. 创建Rule的第一步，选择Item Type，可以选择PO Approval或者Requisition，或者两者。













4. 创建Rule的第二步，设置Notification的格式。












5. 创建Rule的第三步，设置Rule的有效日期，收到Notification后采取的动作。




















6. 点击Submit。收拾东西出差吧，出自己的差，让别人去烦审批的事情吧。

7. 其他，测试过程中，不要将Forward To的用户设置为提交审批请求的Buyer，因为在文档类型中设置了Buyer不能审批，最后在系统中出现大量的提示信息——invalid forward-to person，界面也在提交审批界面Pending住，最后只要重新来过。

采购设置 ——> 3 财务选项

还是没有图片

Supplier – Entry

Path：Setup (M) ->Organization (M) ->Financials Options (M)
是针对Supplier定义的相关设置。对于RFQ Only Site，Hold Unmatched Invoiced，Invoice Match Option等选项，这里的设置会默认到供应商以及供应商地点上对应选项值的设定。Supplier Number，是设置供应商编码的规则。

a. RFQ Only Site
如果Disable这个选项。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

对于新创建的供应商地点，这个选项默认也是Disable的。
Path：Supplier Base (M) –> Suppliers (M) -> Sites (B)

如果Enable这个选项。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

对于新创建的供应商地点，这个选项默认也是Enable的。
Path：Supplier Base (M) –> Suppliers (M) -> Sites (B)

如果供应商地点一旦被设置为RFQ Only，那么创建采购订单的时候将不能从Site中选择这个供应商地点。
Path：Purchase Orders（M） -> Purchase Orders（M）

b. Hold Unmatched Invoiced

如果Enable这个选项。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

对于新创建的供应商以及地点，这个选项默认也是Enable的。
Path：Supplier Base (M) –> Suppliers (M) -> Sites (B)

c. Invoice Match Option

如果选择Purchase Order。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

对于新创建的供应商以及地点，这个选项默认也是Purchase Order的。
Path：Supplier Base (M) –> Suppliers (M)

d. Supplier Number
供应商编码的编码规则。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier Entry (T)

e. Supplier – Payables

默认供应商定义窗口的Payment页上相关域的值。设置。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier - Payables (T)

从供应商Payment页检查。
Path：Supplier Base (M) –> Suppliers (M) -> Payment （T）

f. Supplier – Purchasing

默认供应商定义窗口的Purchasing页上相关域的值。设置。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Supplier - Purchasing (T)

默认值被带入供应商定义窗口。
Path：Supplier Base (M) –> Suppliers (M)

g. Inventory Organization

创建主组织（000）创建新的Item，不将其分配给其他组织。将Inventory Organization更改为C10（非主组织）

创建采购订单，可以看到系统不能找到对应的采购编码。
Path：Purchase Orders（M） -> Purchase Orders（M）

结论：一旦财务选项中定义了Inventory Organization，那么对于整个OU，对应采购订单行上所有的Item只能这里定义的Inventory Organization上来。而对于Shipment上的Org，包括定义Item的Org以及分配了这个Item的Org。例如，如果将这个Item分配给C10，查看Shipment行，可以看到Org可以选择000或者C10。

发运行上的Org可以选择两个组织。
Path：Purchase Orders（M） -> Purchase Orders（M）-> Shipment （B）

h. Supplier – Encumbrance

尚未使用。
Path：Setup (M) ->Organization (M) ->Financials Options (M) -> Encumbrance (T)

i. Supplier – Tax

Path：Supplier Base (M) –> Suppliers (M) -> Sites (B)
这里设定的Tax Code带入到新创建的供应商和供应商地点。同时可以在采购选项中设定采购文档的Tax Code的继承层次。
Path：Setup (M) ->Organization (M) ->Purchase Options (M) -> Tax Defaults (T)

j. Enable Recoverable Tax
这里的设置会影响到新建的Tax Code，新建编码默认值从财务选项中带入。而创建的采购订单的Distribution行的Recoverable Tax会根据Tax Code的设定而来。

实际上，Recovery Rate的设置比较复杂。
首先Enable财务选项中的“Enable Recoverable Tax”以及设置“Default Recovery Rate”。
第二，在Purchasing Look Up Code中设置Vendor Type，并在Vendor定义中将Vendor Type分配给对应供应商。
第三，在Tax Recovery Rate中定义Tax Rule，指定帐户访问，以及条件，这里设定对“风险”类型的采购商，可退回税为50%。


第四，在Recovery Code中设定对应的Recovery Rate或者Rule Name。
如果是Rate会默认从财务选项中带入。

如果Rule Name，可以选定步骤三中新建的Rule。

第四：针对上述供应商创建采购订单，检查其Recovery Rate就是定义Rule中定义中的50%。

第五，如果需要对Tax Code和Recovery Rate 进行更改，可以设定两个预置文件。Tax: Allow Override of Tax Code和Tax: Allow Override of Tax Recovery Rate。

结论：财务选项中所设定的Recovery Rate只是会默认带入Tax Code中定义，可以在定义Tax Code的时候进行修改。
在定义Tax Code的时候也选择Recovery Rule来定义Recovery Rate。
最终决定采购文档上Recovery Rate是由Tax Code所定义的Recovery Rate而决定。
而采购文档上的Tax Code是根据采购选项中设定Tax Code的优先次序决定。有可能来自于财务选项，有可能来自于Item层，供应商地点层等。

采购设置 ——> 2 接收选项

不再贴图，图片太多实在太耗费时间。

a. Receipt Date

设定接收日期的允许偏差。下面设置不能早于或者晚于计划接收日期5天。如果超过，出现提示信息。
Path：Setup（M）-> Organization （M）-> Receiving Option（M）

如果接收日期超过上述接收接收日期允许范围，将会出现如下提示错误。
Path：Receiving（M） -> Receipt（M）

结论：用于控制供应商交货日期。是否真的需要退回给供应商需要根据采购物品已经返回给供应商。如果需要，可以通过Correct窗口对采购订单进行订货。
问题：采购接收的接口部分应该也考虑了这里的选项，如果插入接口表的数据中，接收日期超过允许的范围，那么应该不会成功导入接收表。

b. Over Receipt Control

控制是否可以超过采购数据进行接收。
Path：Setup（M）-> Organization （M）-> Receiving Option（M）

如果超过允许超过的数量，将会有如下的提示。
Path：Receiving（M） -> Receipt（M）

结论：只会限制超过采购数量的接收，不会限制低于采购数量的接收。因为如果限制低于采购数量的接收，那么对同一个采购行接收将不能够进行分多次接收。




c. Receipt unordered

可以接收没有采购单的物料。
Path：Setup（M）-> Organization （M）-> Receiving Option（M）

如果需要进行unordered的接收，首先必须将Receipt Option中enable unordered receipt 选项。这样在Receipt窗口中Receipt Unordered的按钮才是enable的。 同时指定能够进行未订购接收的供应商，具体是在供应商属性中enable receipt unordered。
然后如果Item层次如果的Allow Unordered Receipts没有设置覆盖上述两个选项的话，那么可以针对这些Item进行未采购接收。
Path：Items（M）-> Master Item（M）

通过unordered按钮进入接收窗口，接收20个，此时无订单。
Path：Receiving（M） -> Receipt（M）

然后创建采购订单TunorderRev3，然后通过Match Unordered Receipt窗口，进行Match。采购订单的采购数量必须大于Unordered Receipt的接收单的数量。
Path：Receiving（M） -> Match Unordered Receipt（M）

Match完成之后，可以继续进行后续检验入库操作了。
Path：Receiving（M） -> Receiving Transactions（M）

剩下的6个采购订单，可以还可以做正常的Receipt操作。
Path：Receiving（M） -> Receipt（M）

结论：进行没有采购单的接收，可以处理哪些供应商已经送货，但是实际上系统中下采购订单或者没有审批完成，可以系统中对供应商的送货进行接收，记录数据。待采购订单完成审批完成之后，再进行Match。
问题：在采购订单完成审批之前，这种接收不能入库，从而不能其他库存业务操作，例如生产发料，库存转移等等，后续流程不能还是不能在系统中完成。

d. Express Transactions

设置允许快速接收，提高接收的效率。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)

查询处对应需要进行快速接收的采购订单
Path：Receiving (M) -> Receipts (M) -> Find (B)

点击Express按钮，会让选择快速接收的Final Destination
Path：Express (B)

从Receiving Transaction Summary刚才快速接收的事务。因为选择的为Final Destination，所以同时将Receipt和Deliver两步同时完成。
Path：Receiving（M） –> Receiving Transaction Summary（M）

是否进行快速接收存在一定的条件，对于不能快速接收的必须手动完成：
• The item revision/subinventory/locator is required and not obtainable as a default from the item definition and the destination is Final
• The early/late receipt date tolerance is exceeded and the exception control is Reject
• Lot/serial information is required
• Ship–to location is not available and the destination is Receiving
• Location is not available for Expense destination type and the destination is Final Destination
• Purchase order supplier and receipt header supplier do not match
• other receipts are pending for the specified shipment

结论：快速接收能够加快接收的效率。但是存在一定的前提，业务部门是否需要对接收的步骤进行的严格的控制。例如，必须进行了检验之后才入库。同时，要保证快速接收的效率，必须满足上述的条件，对于不满足条件的订单，必须手工完成。

e. Cascading Receipt

“级联”功能便于将从单个供应商处接收的指定物料数量在多个发运和分配之间进行分配。如果在“查找预计接收”窗口中指定了供应商和物料，并在“接收选项”窗口中启用了“允许级联事务处理”，则将可以在“接收”窗口中使用此功能。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)

针对某一个供应商和物料编码进行查询接收，下面的接收行来于三个订单。
Path：Receiving（M） -> Receipt（M）

点击Cascade按钮，输入需要接收的数量以及单位。
Path：Receiving（M） -> Receipt（M）-> Cascade（B）

确定之后，发现系统自动计算5000数量所需要的接收行，注意最后一样的数量由2250更改为750。然后再进行接收。
Path：Receiving（M） -> Receipt（M）

如果实际的接收行为5000，而输入接收数量为5100，将会出现如下的提示。
Path：Receiving（M） -> Receiving Transactions（M）

结论：“级联”功能便于将从单个供应商处接收的指定物料数量在多个发运和分配之间进行分配。如果在“查找预计接收”窗口中指定了供应商和物料，并在“接收选项”窗口中启用了“允许级联事务处理”，则将可以在“接收”窗口中使用此功能。如果在“查找接收事务处理”窗口中指定了物料，则将可以在“接收事务处理”窗口中分发物料时使用此级联功能。在行中执行任何人工事务处理将禁用“级联”按钮，并且在您于相应的“查找”窗口中再次选择“查找”按钮之前，此按钮将一直处于禁用状态。

如果选择“级联”按钮，采购管理系统将显示“级联明细”窗口，您必须在其中输入级联数量和单位。选择“确定”按钮，系统将启动级联流程。

流程从第一个显示的行开始执行，并按您输入的相应级联数量为该行分配可用于接收/分发的供应。然后，流程将转至下一行继续执行并再次分配可用于接收/分发的数量（依此类推），直至查询到的最后一行或者用尽级联数量。由于这些行按承诺日期/需要日期顺序显示，因此流程的运行过程类似于先进/先出过程。如果输入的级联数量大于可用于接收/分发的数量，采购管理系统将显示一个对话框窗口以说明流程最多只能分配的数量；如果级联数量小于可用于接收/分发的数量，则最后一行分配到的接收/分发数量可能只是部分级联数量。为了明确表示级联数量已用尽，采购管理系统会将剩余行的事务处理数量显示为 0。

级联功能不会修改任何目的地信息；它使用由接收方式定义的，以及自发运默认的信息。

如果某发运行包含多项分配并且该行的接收方式默认为直接接收，级联流程将展开该行，并根据各项分配的可用供应将发运行的可用数量在其组成分配之间进行分配。如果超量分配某指定行，采购管理系统会将发运的所有剩余供应分配至最后一项分配；如果超量分发的事务处理先前已具有接收或事务处理，则该流程将使用非期望值来填写这些行；这种情况下，您可以在级联流程完成后进行重新分配。

在级联流程执行期间，系统会禁用记录验证以加快级联流程的运行；但在保存记录时，系统将对所有记录进行验证。数量将按默认接收方式对行的预期处理方式分配至各行。但您可以人工改写这些值。

f. Allow Blind Receiving

运行Blind接收保证接收的数量和采购的数量精确匹配，从而采购接收录入员没有机会更改接收的数量。接收的数量会显示为0。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)


采购订单发运行的实际数量为1000。
Path：Purchase Order（M） -> Purchase Order Summary（M）

针对上述的采购订单发运行进行接收，系统显示的数量为0。
Path：Receiving（M） -> Receipt（M）

结论：通过这种方式，接收更为死板，不可能考虑分批次接收的情况。但是保证了接收数量与采购数量的一致性。同时一旦设置这个参数。

问题：现在系统中若进行这种业务，为什么会有错误？

g. Enforce Ship-To

确保接收的地点和采购订单的地点一致性，如果不一致，可以选择警告，拒绝或者忽略。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)
采购接收的时候，发运地点从采购发运行上默认而来。
Path：Receiving（M） -> Receipt（M）

如果对其进行更改，更改为如下的地点。
Path：Receiving（M） -> Receipt（M）

保存，系统将会出现如下的警告提示。
Path：Receiving（M） -> Receipt（M）

结论：只是对于接收时候要确保地点的一致性，如果到了采购入库的步骤，可以更改而不会出现警告。

h. ASN Control
没有使用

i. Receipt Routing
设定接收的时候是否需要检验，这个选项可以被供应商/地点/物料属性/发运行的属性覆盖。
Path：Setup (M) ->Organization (M) ->Receiving Options (M)

查询一个客户退货，可以看到Routing字段为“Inspection Required”。
Path：Receiving（M） -> Receipt（M）

采购设置 ——> 1采购选项 ——> 1.2 Default/Accrual/Number

Default

顾名思义，就是设定采购默认值的设置，这些默认值将会再创建请购单，采购等文档的时候，相关域从这里得到默认值。











a. Requisition Import Group-By

设定从请购接口表导入请购单的时候，请购单的分组规则。存在ALL，Vendor，Buyer，Item，Category等选项。这里的设置会影响到从MRP，WIP以及其他外部系统导入请购单的时候，请购单的分组。下面的例子以Requisition Import报表为例。测试，设置不同的分组，运行这个请求的时候，参数的默认值。

如果分组值设定为Buyer。



提交请求的时候，默认分组参数为Buyer。









如果分组值设定为Vendor。




提交请求的时候，默认分组参数为Vendor。








b. Rate Type:
设定Corporate。



请购单一旦设定非本位币，存在汇率转换的时候，可以看到默认汇率类型。







c. Minimum Release



在Blanket Purchasing Agreement 中的Term窗口检查默认值。








d. Price Break Type



在Blanket Purchasing Agreement 中的订单行上检查默认值。





e. Price Type



在请购行的Price Reference页检查默认值。







f. Receipt Close/Invoice Close/Line Type/Match Approval Level








在请购行/发运行上检查默认值。




g. RFQ Required



可以在Item层和请购行层覆盖这个选项。

Number
编码方式，可以选择自动生成编号或者手工输入。自动只能选择数字，手工可以是字母和数字。








Accrual
应计的时间点，是在接收的时候或者在期末的时候。对于库存，只能选择在接收时应计。对于费用项目，还可以选择在期末应计。
同时设定应计帐户。

采购设置 ——> 1采购选项 ——> 1.1 Control面板

最近比较闲，开始学习采购设置。

采购设置 ——> 采购选项 ——> Control面板

a. Price Tolerance

通过Requisition Summary查询，请购行单价.9915。

如果采购选项中采购价格百分比做如下的设定。

通过Auto Create将这个请购单创建到标准订单的时候，将价格更改为15（大于20% * .9915，其中.9915为上述请购行的单价），保存，点击Approve按钮提交审批，可以弹出审批界面，证明系统没有因为单价超过容差百分比而限制订单的审批。

如果采购选项中采购价格百分比做如下的设定。

那么将会再通过Approve按钮去访问提交审批界面的时候，将会出现错误提示。

结论：Price Tolerance Percentage和Enforce Price Tolerance Percentage要结合使用。只有Enable了Enforce Price Tolerance Percentage的时候，在Price Tolerance Percentage设定的值才起作用。

如果将设定Price Tolerance Amount。

针对同样的采购订单，如果单价为1.1（累计Tolerance的金额为(1.1-.9915)*100 > 10 ），点击Approve按钮，出现如下错误。

结论：同Price Tolerance Percentage，只是一个侧重采购金额，一个侧重价格百分比。

b. Receipt Close Point

设定这个值，决定在什么时候对订单发运行进行Close For Receiving。一共有三个选型值，对应于采购接收的三个步骤——Receipt，Accept，Delivered。
下面测试这个值的设置，对发运行自动关闭的影响。

在采购选项中设置。

通常和Receipt Close结合使用（这个值在采购选项Default面板设置）。

创建采购订单，检查其发运行，其Closure Status为Open。

采购选项的值被带入发运行。

对审批的采购发运行做Receipt，发运行本来的数量为1000。

这里我们接收(1-10%)*1000 = 900数量，保存。

再检查发运行状态，已经为Closed For Receiving。

结论：这个选项控制在采购接收的什么步骤进行订单的自动关闭，通常需要和Receipt Close选项结合使用。从正常的业务逻辑来讲，设置为Delivery比较合理。

c. Cancel Requisition

这个选项只应用于通过Auto Create创建的订单的请购单。有三个选项Optionally，Always，Never。

Path：Purchasing Option（Menu）->Control（Tab）
设置其值为Optionally。



订单T_ClosePoint1通过Auto Create通过请购单创建而来。
Path：Purchase Order Summary（Window）-> Control （Menu）









从弹出的Control窗口中，有取消请购的选项。











如果设置为 Always



检查Control窗口，Cancel Requisition默认选择，且不让更改。











结论：用户控制在取消采购单的时候，是否取消采购单对应的请购单。
问题：如果取消了请购单，而请购单从MRP创建，对计划的影响（To Do）。


d. Notify If Blanket PO Exists


创建请购单的时候，如果对应Item已经存在BPA，给出提示。

















e. Allow Item Description Update

是否在请购/采购行上更新Item的描述。



Item层的这个属性会覆盖采购选项的属性，所以必须在Item层上设置之后再测试。





请购行上的描述字段变成可编辑状态了。







结论：采购选项关于Item描述的更新设置通常没有什么用，一般在Item层属性都会覆盖采购选项的设置。在Item层应该设计为下拉框，有三个选项（Yes，No，Null）。其中Null表示在Item层不设置这个属性，从而不会覆盖采购选项层的设置。

如果Enable这个选项，对新创建的Item，Item层的可更新描述的选项默认也是Enable的。









f. Enforce Vendor Hold



同时在Supplier的定义的Purchasing也设置Purchase Order Hold。





针对这个Supplier创建采购订单，然后点击提交，系统将会出现如下的提示错误。