审批流程中的疑问解答(下)[原创]_Hadoop,ERP及大数据讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  Hadoop,ERP及大数据讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 4502 | 回复: 0   主题: 审批流程中的疑问解答(下)[原创]        下一篇 
Gavin
注册用户
等级:少校
经验:878
发帖:130
精华:1
注册:2011-7-21
状态:离线
发送短消息息给Gavin 加好友    发送短消息息给Gavin 发消息
发表于: IP:您无权察看 2011-8-18 11:05:31 | [全部帖] [楼主帖] 楼主

原文:

Question 3 - What happens if lines on a PO are cancelled while the order is still in the approval process?
Answer - If one line on a multiple line order is cancelled, the remaining lines continue through the approval process. If the cancelled line is the only line on the order, no lines will be seen in the orders awaiting approval application.
BUG: 10730057 fixed problems with cancelled lines. The way the application works after the fix is as follows:
If a line is being cancelled before being approved then the Approval Status in the Held Orders (F4209) will remain '3N' and will be displayed in the Orders Awaiting Approval (P43081) screen. See Section Change to Existing Order Question 10
If a line has already been approved (Approval Status of '3N' in Held Orders (F4209) file) then is cancelled; it will not re-enter the Approval process and a new record will not be written to F4209 at an 'Awaiting Approval' status (2A) and then never get approved.
Back to Top
Question 4 - What changes on a Purchase Order line cause a line to go back through the approval process?
Answer - Prior to Release 8.9, a change to one or more of the following fields will cause an order that is at an approved status to go back through the approval process. Note: A change is considered a different value. Retyping a value that currently exists in a field is not considered a change. The value must be new to be considered a change.
Extended Cost (AEXP)
Account Number (AID)
Subledger (SBL)
Subledger Type (SBLT)
Landed Cost (PDP5)
Promised Delivery Date (PDDJ)
Requested Date (DRQJ)
Payment Terms (PTC)
Discount Factor (DSPR)
Project Business Unit (OMCU)
In E1 8.9 and above, an order will go back through Approval Processing depending on the value in specified in P4310, 10-Approvals Tab, Option 4. Reapprove Changed Lines.
Options are:
Blank = Do not reapprove
1 = Reapprove on change to any field
2 = Reapprove on change to user-activated critical fields only
3 = Reapprove on change to standard critical fields only
Back to Top
Question 5 - Is there a way to keep orders that are changed from going back through the approval process once they have been approved?
Answer - Some companies need to make changes to existing lines, but do not want to send the order back through the approval process. If the order is still at the approved or pending approval status, changes should be made in a version of Purchase Order Entry that has approval processing turned off by leaving the Override Next Status blank AND remove the Route Code from processing option #1 on the Approvals tab. It is recommended that change order processing be turned on for that version, to keep a history of the changes being made after the approval process.
Note: 8.9 completely changed the way that this is handled. (See Changes to Existing Order Question 4)
Back to Top
Question 6 - What happens if a change needs to be made once the order is beyond the approved status?
Answer – in Xe and 8.0, once an order has been approved, it is now at the approved status. If another process is done (i.e. Print Purchase Orders) the order status is update beyond the approved status. Any changes made to detail lines that are at a status BEYOND the approved status, will not send the line/order back through the approval process, unless an override next status, processing option #4 in the Defaults tab of Enter Purchase Order (P4310), is used to put the next status back to an Awaiting Approval Status. When a change is made to a line with an override next status, only the changed line will reflect the override next status. For example, Print Purchase Order is run, the status is changed from 280 to 400, changes made to the order after Print Purchase Order (R43500) will NOT cause the order to go back through the approval process, unless an override next status of 230 is specified in the processing option # 4 of the Default tab of Enter Purchase Orders (P4310). A Held Orders (F4209) record is created, but the order will not be able to be approved, since the order status is incorrect. If using override next status, Order Revisions must also be turned on by setting processing option #1 in the Order Revisions tab of Purchase Order (P4310) to a value of 1 or 2.
Another options is to make the changes in a new version of Purchase Order Entry (P4310) with change order processing turned on, accessible only to a manager or an approver, can be used to change the existing order lines that are beyond the approved status. Set the processing options to not allow change after the approved status on the original version of Purchase Order Entry (P4310).
In E1 8.9 and above, a new processing option was implemented were the user can specify if an order should go back to Approval Processing if a change is made to an approved order (P4310, 10-Approvals Tab, Option 4. Reapprove Changed Lines).
Back to Top
Question 7 - Is there a way to prevent changes once the order has been approved?
Answer - Some companies do not want to have lines changed after the order has been approved. To accomplish this, set the processing options to not allow changes after the approved status in P4310, Display Tab – Detail Line Protection. This only prevents changes to existing lines.
Back to Top
Question 8 - A new line is added to an existing PO all lines including those partially received all rerouted for approval. Is this correct?
Answer - Yes, this is functioning as designed. Approval processing is an order based process so all lines that are not closed will be sent back through the approval process. Please note that we do not split lines when partial quantities are received, so the partial line is still open. This also gives the approver a quick way to see the whole order and know what they are truly approving.
Back to Top
Question 9 - A cancelled line still shows in Orders Awaiting Approval, how should this line be handled?
Answer - Lines that are cancelled before they are processed through the approval route will still show in the Orders Awaiting Approval. When the approver goes to the order, the cancelled line will be shown with a line through the extended price. Cancelled lines may impact the approver's decision to approve or reject an order; hence, this same line needs to be represented in the Orders Awaiting Approval screen. However, cancelled lines are not approved or reject, instead the Remove Msg row exit is used to process the cancelled line once the approver has determined that the cancelled line is OK.
3N records are written to the Held Orders (F4209) file as notification to the Originator of the Purchase Order. Notification states that the Purchase Order has been approved in one of two ways:
Approvers using the approval route, or
Order amount is below the first approver's limit.
The second case includes orders where the line(s) have been cancelled, leaving the order total at zero, or at a level below the first approver's limit. The originator must then remove this message by using the row exit Remove Msg. Approvers cannot remove these 3N messages.
Note: Cancelled lines on the PO are forced to go back through approvals. None of the critical fields have changed. This is functioning as designed (Bug: 10958586) to prevent users from entering in credit lines to bring the amount under the approved amount. So when a line is cancelled, the order still goes through the approval processing algorithm to determine if after the change the order is over or under the approval amount. If it is under, it will automatically approve all lines on the order. If it is over, all lines on the order will go through the approval route. This gives visibility to the approver to know that someone did something to the order. For example, a first level approval is set to $1,000. A person enters a purchase order for net $900 by entering line 1 for $1,500 and line 2 for $-600. The order is auto approved and approval processing has taken place. Then they cancel the $-600 line - this should trigger re-approval. If the client does not want this, then users can cancel lines in a version of P4310 that does not have the approval processing options turned on.
Back to Top
Question 10 - Approval route is being determined by the Branch Plant, however when the user changes the Branch Plant in update mode the approval route does not change, why does this happen?
Answer - Upon initial order entry, the approval code (ARTG) can be established several ways based on the processing options. User can define an approval code in Purchase Order Entry (P4310) processing option, in the branch plant constants, from the user profile or it can be retrieve it from the user's address book. It does not matter how the user retrieve it (based on the processing option) and populate it on the order, once the order is created, the value in the ARTG field cannot be changed. The reason is to keep integrity within the system. This is one field we do not allow the user to change (in any way) once the order has been entered. We do not allow the ARTG field to be changed once the order is established. The only way to change it is to cancel the order and create a new order with the correct MCU. As a work around, we have a copy function in purchase order entry. If there is an MCU change, copy the order created to a new order and change the MCU in the header and detail. Because this is a new order, the new approval route will be applied to the order. After the order is copied, the original order can be cancelled.
Back to Top
Question 11: Originator Change: Change to an order by one of the approvers on the route.
Answer 11: There is no way to track an originator of an order and an originator of a revision to an order. Hence, the approval process has been changed in the EnterpriseOne 8.9 so that whenever a person revises an existing order, then that person would be treated as the originator. The person who revised the order will then get the messages sent when the order is approved or rejected, since that person is now the most recent originator. @Bug10983165


译文:

问题3:当订单还在审批流程中,人为的取消PO上的行,会发生什么?

答:如果多行中某行订单被取消,剩下的行还是会继续通过审批流程。如果被取消的行是订单中唯一的行,那么在订单等待批准程序中将看不到任何一行。

Bug:10730057解决了取消行的问题。在解决这个问题后,这个应用程序的工作方式如下所述:

如果订单在被批准前,其中的一行被取消,那么在订单控制(F4209)中的审批状态将保持为’3N’,并且显示在订单等待审批(P43081)的屏幕上。参考修改存在的订单的第10个问题。

如果一个已经被批准(在订单控制(F4209)的审批状态为’3N’)的行被取消,它将不会重新进入审批流程,新的记录也将不会写入到F4209的等待审批状态(2A)中并且它也永远不能通过审批。

问题4:在采购订单的行上作何修改才会导致一行重新通过审批流程?

答:在版本8.9之前,以下的字段中的一个或者多个被修改后,都将导致审批状态的订单重新通过审批流程。注意:一次修改被认为当一个不同的值。重新输入一个字段中当前存在的值,这不会被看做是一个修改。被当做一次修改的值必须是新值。

●  总成本(AEXP

●  账号(AID

●  子分类账(SBL

●  子分类账类型(SBLT

●  抵岸价格(PDP5

●  约定交货日期(PDDJ

●  请求日期(DRQJ

●  支付条款(PTC

●  折现系数(DSPR

●  项目业务单元(OMCU

E1版本8.9或者以上的版本,订单将会根据在P431010-Approvals标签下的第四选项中指定的值重新通过审批流程。重新审批被修改的行。

选项内容:

空白 = 不需要重新审批;

1 = 改变任何的字段都重新审批;

2 = 只改变用户指定的关键字段后重新审批;

3 = 只改变标准的关键字段后重新审批。

问题5:一旦订单已经通过批准,有没有一种方法可以保存这些重新通过审批流程后被修改的订单?

答:一些公司需要修改已经存在的行,但是有不想要让订单重新通过审批流程。如果订单还在批准或者待批准状态,对订单的修改要通过采购订单输入的一个版本来实现,并且这个版本已经通过将下一个状态置为空和删除批准标签上处理选项#1的通道代码关闭审批流程。推荐为这个版本开启修改订单处理功能,这个功能开启后能保存在审批流程中的历史修改信息。

注意:版本8.9完全改变了处理方式(参考修改存在的订单的第4个问题)。

问题6:怎么样做才能修改正处在批准状态的订单?

答:在Xe8.0中,一旦订单已经被批准,它的状态就是批准状态。如果另外一个程序完成(比如打印采购订单),在审批状态中的订单的状态会被更新。对明细列所做的任何修改都会在审批状态中记录一个状态,并且不会将行或者订单发回到审批流程中,除非在输入采购订单(P4310)的默认标签中的处理选项#4中的重写下一个状态是用来将下一个状态放回到等待审批状态中。当一行使用重写下一个状态做了修改,那么只有被修改的行将反映到重写下一个状态中。比如,打印采购订单正在运行,它的状态由280改成了400,在打印采购订单后之前被修改的订单不会导致它重新通过审批流程,除非在输入采购订单(P4310)的处理选项#4的默认标签中指定重写下一个状态的值为230。一个订单控制(F4209)的记录被创建,但是订单将不会被批准,因为订单的状态不正确。如果使用重写下一个状态,必须通过将采购订单(P4310)的订单修正标签中的处理选项#1置为1或者2来打开订单的修正功能。

另一个选择是将新版的采购订单输入(P4310)改变订单处理的功能打开,并且只有管理员或者审批者才能相对容易的在审批状态中修改已经存在的订单行的状态。在采购订单输入(P4310)原始版本为审批状态后,就不再允许修改处理选项。

E1 8.9或者更高的版本中,出现了一个新的处理选项,即用户可以指定一个批准后被修改的订单是否应该返回到审批流程中去(P431010-Approvals tab, Option 4。重新审批修改过的行)。

问题7:一旦订单被批准,有没有什么办法来避免修改订单?

答:一些公司不希望在完成批准的订单做任何修改。为了达到这个效果,在P4310明细行标签中,将处理选项设置成当为审批状态时不允许做任何修改。这个只能防止修改已经存在的行。

问题8:一个新行被添加到已经存在的一个PO里,所有的行包括那些新行都会接收所有新的审批通道,这是正确的?

答:是的,这个功能就是这样设计的。审批流程是一张基于程序的订单,因此所有没有关闭的行都将被发送回审批流程中去。请注意当接收到部分数量时,我们不会分割行,因此部分行还是打开的状态。这也为审批者提供了一个快捷的方式去查看整张订单,并知道真正被批准的订单。

问题9:一个被取消的行仍然显示在订单等待审批中,该怎么样处理这行呢?

答:在行通过审批通道处理前被取消,那么它们仍然会在订单等待审批中出现。当审批者转到一个订单时,取消的行将通过总价被显示成一行。取消的行可以影响审批者对批准或者拒绝一张订单的判断。因此,相同的行需要再现在订单等待审批的屏幕上。然而,被取消的行不被批准或者拒绝,相反,一旦审批者已经决定取消的行没有问题后,移除信息行出口会用来处理这些取消的行。

3N记录被写到订单控制(F4209)文件中,这些文件被当做通知发送给采购订单的发起人。通知已经被批准的采购订单的状态,在以下两种方式的其中一种:

1.审批者使用审批通道

 2. 订单总数低于审批者首次的限制

第二种情况包括订单中的行被取消,留下订单总数为0,或者在一个低于审批者首次的限制的水平。发起人必须使用行出口删除信息来删除这些信息。审批者不能删除这些3N的信息。

注意:PO上的取消的行要强制返回通过审批。没有关键性的字段已经被修改。这个功能的设计(Bug10958586)用来防止用户在审批总数下,输入信用额度带来总额。因此当一行被取消,订单仍然通过审批流程运算来决定在修改完订单后,数量是在审批总额之上还是之下。如果在审批总额之下,它将自动批准订单中的所有的行。如果在审批总额之上,订单中的所有行将通过审批通道。这能让审批者清楚的看到哪些人对订单做了哪些操作。比如,第一级审批设置为1000美金。一个人通过在第一行输入1500美元,第二行输入-600美元来得到一个净利为900美元的采购订单。订单会自动批准,并且进入审批流程。接着他们取消了-600美元的行,这将触发订单重新批准。如果客户端不想要这些,那么用户可以在P4310的一个版本中取消行,而不用开启审批流程选项。

问题10:审批通道是由分厂决定的,然而当用户把分厂修改成更新模式后,审批通道却不会修改模式,这是为什么?

答:根据初始的订单录入,审批代码可以基于处理选项创建多个方式。用户可以通过用户属性中的分厂常量中的采购订单输入处理选项来定义一个审批代码或者它可以通过用户的通讯录来检索出来。不用在乎用户是怎么样检索它的(基于处理选项),并且将它填写到订单中,一旦订单被创建,在ARTG字段的值将不能被修改。原因是为了在系统内部保持完整性。一旦订单已经被登记,这个字段在任何情况下都不允许用户做修改。一旦订单被创建,我们就不会允许去修改这个ARTG字段。修改这个字段唯一的方法是取消订单并且使用正确的MCU来创建一个新的订单。作为一个解决方法,我们再采购订单输入中有一个拷贝的功能。如果修改了一个MCU,拷贝订单并且创建一个新的订单。并且在订单的头部以及详细信息处修改MCU。因为这是一个新的订单,并且新的审批通道将会被应用于这个订单。在订单完成拷贝后,原始订单就能被取消。

问题11:发起人修改:在审批通道中作为其中的一个审批者来修改订单。

答:没有办法追踪一个订单的发起人以及翻新订单的发起人。因此,审批流程已经在企业通8.9中做了修改。无论何时一个人修正了一张已经存在的订单,那么这个人都将被视作发起人。当订单被批准或者拒绝,修正订单的人将收到信息,因为那个人是当前最近的发起人。@Bug 10983165




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论