2013年9月9日星期一

GL>Journal approval

•Journal Approval uses Oracle Workflow to control and monitor the approval process, sending notifications to journal batch preparer’s and approvers when needed.
•Before you use Journal Approval, you must::
  1. –Enable journal approval for your Ledger.
  2. –You must also set up your journal sources to use journal approval.
  3. –You must create an approval hierarchy and define your approver authorization limits.
  4. –Set the two profile options Journals: Allow Preparer Approval and Journals: Find Approver Method. See: Setting General Ledger
  5. –Configure the GL Journal Approval Process in Oracle Workflow Builder.
  6. –You can change the default settings for “Request Approval From Approver timeout” and the “Reached Manager Notification Resend Limit”.
•To enable Journal Approval for your Ledger: When defining your Ledger, mark the Enable Journal Approval check box on the Define Ledger window.
•To specify journal sources that require journal approval: On the Journal Sources window, mark the Require Journal Approval check box for each journal source that should be subject to approval.
•To create an approval hierarchy: Use the Enter Person window in Oracle General Ledger to enter all of your employees who are involved in preparing and approving journal entries and batches. When you enter an employee, you also enter the employee’s supervisor or manager name. The supervisor is the default next approver for journal entries and batches. Likewise, the supervisor’s manager is the next approver after the supervisor.
•To define authorization limits:
  1. Navigate to the Journal Authorization Limits window.
  2. Enter the Employee name, or select it from the list of values.
  3. Enter the amount of the employee’s Authorization Limit.
  4. Repeat the previous two steps for each employee for whom you want to define authorization limits.
  5. Save your work.
•Submitting Journal Batches for Approval
–1. Navigate to the Find Journals window.
–2. Query the journal batch you want to submit for approval.
–3. Select the batch from the Enter Journals window.
–4. (Optional) Choose Review Batch or Review Journal if you want to review the batch information or journal details before you submit it for approval. Note: The Status region on the Batch window will display the current statuses for Posting, Funds reservation, and journal Approval.
–5. From either the Enter Journals, Batch, or Journals window, choose the More Actions button.
–6. Choose the Approve Batch button.
–After you submit your journal batch for approval, you should receive a message indicating the result of your request. The message will inform you that your journal batch:
»Was self–approved, if you are authorized to approve your own journal batches, or
» Has been sent to an approver, or
» Was invalid.
•Approving or Rejecting Journal Batches –
–1. Check your notifications. Journal approval requests will display the following in the Subject field of the Notifications Summary window:
“A journal batch for < batch amount> requires your approval”
–2. Open the notification that requests your approval.
–3. (Optional) Review the batch information or journal details before you approve or reject it. If your current responsibility allows you access to the journal batch’s set of books, you can drill down from the Notifications window to the Enter Journals window to review the batch. Otherwise, you can use General Ledger’s journal inquiry feature to review the batch.
•The journal approval notification you receive will include the batch name, total batch amount, functional currency, preparer’s name, monitor URL, and preparer’s comments. Use this information to query the journal batch.
–4. With the journal batch approval request displayed in the Notifications window, choose the Respond button.
–5. Select Approve or Reject from the Action pop list.
–6. (Optional) Enter a Comment.
–7. Choose OK to save your work.
•PROFILE OPTIONS –
–Request Approval From Approver timeout — the standard setting is 7 days. After this time has expired, Journal Approval notifies the preparer that no approver response has been received.
–Reached Manager Notification Resend Limit — the standard setting is 1 notification. Journal Approval will resend notifications to the approver until the limit is reached.

2013年9月8日星期日

OPM Demo Flow

转载请注明出处:http://blog.csdn.net/pan_tian/article/details/8907106

GL>Accounting Manager>Legal Entity

What is a TIN/EIN?

Taxpayer Identification Number (TIN) and Employer Identification Number (EIN) are defined as a nine-digit number that the IRS assigns to organizations. The IRS uses the number to identify taxpayers who are required to file various business tax returns. TIN/EIN are used by employers, sole proprietors, corporations, partnerships, nonprofit associations, trusts, estates of decedents, government agencies, certain individuals, and other business entities.

I am confused, are TIN/EIN the same thing?

A Federal Tax Identification Number, also known as a "95 Number", "E.I.N. Number," or "Tax I.D. Number", all refer to the nine digit number issued by the IRS. They are different names for the same number.

Why do you need our TIN/EIN number?

NIST is implementing a new financial management system and will be consolidating customer records from many different sources. In an effort to keep the central database manageable we are trying to limit the number of duplicate entries in our customer database. TIN/EIN will serve as a way to uniquely identify a business entity when the precise name of a business entity is unknown or when it is difficult to distinguish it from other businesses with similar names.

The National Institute of Standards and Technology (NIST) is an agency of the U.S. Department of Commerce.

2013年9月7日星期六

MDS, MPS, MRP clarification

转:MRP与MPS的异同
相同点:
功能相同、算法相同          202.96.171.115
不同点:
对象不同:MPS的对象是成品或关键部件,MRP的对象是物料
功能不同:MPS一般用来计算直接需求,并安排一段时间内的生产计划。MRP是保证物料的可用性,计算在什么时间需要采购或生产多少数量,以保证满足需求。
目的不同:
主生产计划的目的是降低库存(包括在制品)成本和提高计划的稳定性
MRP的目的是一方面保证不出现短缺,一方面尽量使成本和资金占用最小化。
其他
A:MPS运算不考虑库存,不考虑在途的采购订单,不考虑未完成生产订单,输入的订单是多少,跑出的需求就是多少。MRP需要考虑库存、在途采购订单、未完成的生产订单。
B:MPS主要是对成品制定生产计划,MRP主要用来指导物料采购
C:MPS- Master Production Schedule的缩写,顾名思义,就是主生产计划表,但主生产计划并不只包含完成品,只要是master schedule item,都可以加入主生产计划表,举例来说,在assembly-to-order的生产方式下,是可以把assembly作为master schedule item对其做MPS。
简言之,MPS是对master schedule item做计算,MRP是对所有的item做计算,MPS驱动MRP的运算。
D:MPS 是完成品的计划表,描述一个特定的完成品的生产时间和生产数量。MPS是一个决定完成品生产排程及可答应量(ATP)的程序。依据MPS,MRP得以计算 在该完成品需求之下,所有组件,零件以至原材料的补充计算。MPS不是销售预测,不代表需求。MPS须考虑生产规划、预测、待交订单、关键材料、关键产能 及管理目标和政策。除了材料外,MPS也是其它制造资源的规划基础。
E:MRP利用BOM将MPS中的成品需求转换为半成品及原材料需求。它利用库存状态如OH及SR等,以及材料主文件中的材料基本资料如LT及SS等,以及厂历,计算出何时需要多少何种材料
MPS 是主生产排程的缩写.计划紧急资源和贵重物料.属于中长期计划.在确定好的MPS以后才进行MRP
MRP 是物料需求计划的缩写.
从后勤链的角度.先有MPS再有MRP,但MRP常有,而MPS不常有。意思MRP是一定要的,但可以根据企业不同的需求可以不运行MPS.例如:按MTO生产的企业自己并不进行中长期的计划。


主生产计划(MPS,Master Production Schedule)
        主生产计划是一个计划的工具,主要针对独立需求的物料进行计划(该做什么,什么时候做),它是市场需求和工厂产能之间的桥梁。其输出结果可以作为MRP的来源。
物料需求计划(MRP,Material Requirements Planning)
        物料需求计划是指根据各种需求(订单、预测、主生产计划),考虑产品结构(BOM)、库存、物料基础资料等信息将需求转化为对物料的需求计划(生产什么、什么时候生产,采购什么、什么时候采购)。
主生产计划(MPS)及物料需求计划(MRP)系统是ERP管理软件的核心,也是ERP系统发展的基础。通过MPS/MRP系统将企业外部销售市场对企业 的销售需求转化为企业内部的生产需求和采购需求,将销售计划转化为生产计划和采购计划。MPS/MRP管理方式可以解决“需要什么?什么时候需要?需要多 少?”三大难题。相对与手工管理来说,MPS/MRP计划可以大大提高计划下达的效率,并大大增加计划的准确性、及时性,从根源及计划层面杜绝不必要的库 存,减少浪费。

Oracle中MDS与MPS的理解.
MDS(master demand schedules)与MPS(master production schedules)的区别
MDS就是你说的销售计划预测计划备货计划等,是MPS的输入.
MPS本身不是计划,是一个过程,输入是MDS,输出的是一个需求的结果,这个结果驱动MRP展开

MDS是需求汇总,如: A订单成品xx需要10个,B订单成品xx需要20个。MDS会进行合并汇总(不需要其它判断过程);
MPS: 根据MDS的需求,根据BOM, 结合库存,在途,已下PO,生成物料生产计划。

(MDS有自己特定的应用场景,涉及到多组织的生产模式,多组织的多分销渠道的模式。
在多组织多分销渠道环境下,多数时候MDS是必须的。
单组织应用时,可以在MDS中录入独立需求的MPS件(当然,也可在别的地方录入,条条大路通罗马)。)

(1)、MDS只是需求的平衡,不考虑能力;
(2)、MPS根据需求需要考虑能力;
(3)、MRP可以来源MPS也可以直接来源MDS;
(4)、MDS展BOM时,只会展到MDS件的需求,并且不考虑库存、在制、在途用,只是计算出需求;

MDS-->MPS-->MRP,MDS在销售发运的时候冲减,MPS在下达任务的时候就冲减。MPS假设是通过MDS直接覆盖过来,任务已 做完工(我又手工在下达销售订单之气定义离散任务),销售订单还未做发运,这个时候又将销售订单导入MDS,这时候根据供需平衡供应应该减少就可以满足需 求,但实际上系统不会考虑这个手工的任务,导致生产过剩。


下面列出Oracle的计划层次及其一些特点:
1.        Forecast
来源:手工录入、复制/合并已有预测、历史信息生成、外部装入
对象:独立需求件、计划和模型BOM的父项目及组件
冲减方法:销售订单
2.        MDS
来源:手工、来源清单、预测装入、装入/复制/合并已有、外部装入
对象:独立需求件、计划和模型BOM的父项目及组件、相关需求件
冲减方法:销售发货
3.        MPS
来源:手工、来源清单、MDS生成、装入/复制/合并已有、外部装入
对象:独立需求件、计划和模型BOM的父项目及组件
冲减方法:下达计划
4.        MRP
来源:预测、MDS、MPS、外部装入
对象:采购件、加工件、无库存项目件
冲减方法:下达计划
计划内容和冲减条件:
1.        Forecast
至少包括的内容:物料编码、日期、原始数量、当前数量
冲减:销售订单冲减
冲减前提:预置文件,MRP预测冲减选“是”;在预测集中选择“预测冲减”选项。
2.        MDS
至少包括的内容:物料编码、日期、需求数量
冲减:发货冲减
冲减前提:同上,不同的是冲减MDS。
生产计划的逻辑非常复杂,涉及多很多要考虑的因素,而且一旦发生变化,会引发一系列的变化。下面对各层次的计划的冲减逻辑做一分析:
1、Forecast:   
预测冲减规则:在一个预测集中,预测冲减只会进行一次,即一个订单不会对一个预测进行一次冲减,然后又对同一预测集中的另一个预测进行一次冲减。但是,如果一个预测中的数量小于订单数量,不够的部分会在同一预测集的另一个预测中进行冲减。
在同一预测集中,如果有多个预测存在,冲减的先后次序按预测名称的子目排列顺序进行。
预测冲减逻辑:
预测冲减过程,涉及三种数量概念:
原始数量、当前数量和过量冲减数量。如果销售大于预测,当前数量为0,同时,为了记录超出的数量,预测冲减流程会创建额外的预测条目,这些预测条目具有一下特征:
这些条目出现在预测集中,而不是某个预测中
预测条目的来源将是过量预测
原始数量将是0
当前数量是定大那超出预测的数量,但是将以负数显示
期间类型将按日显示
日期是销售订单行计划日期
预测冲减系统逻辑:
在创建了一个新的销售订单行时,也就创建了一个实际的销售需求。使用预测冲减,可以避免已包含在预测中的销售订单行需求被重复计算两次。
在创建了销售订单后,计划管理器后台进程会自动进行预测的冲减。
预测冲减基于销售订单行上物品的计划发运时间进行,如果在预测行中有物品的预测时间同销售订单行上物品的发运时间匹配,则在该预测行减少与销售订单行上相同的数量,实现预测冲减。此外,预测行的时段类型、预测的倒冲和前推天数都会影响实际的预测冲减。
对于订单的创建时间比预测创建的还早的预测冲减 ,需要在Oracle计划模块中提交一个名叫冲减预测集的后台进程,来进行预测冲减。
2、MDS:
MDS冲减逻辑:
计划管理器会定时检查Oracle库存管理系统中的供应/需求信息,以便发现是否有销售订单需求被消除(即被发货)。
计划管理器在所有定义的、冲减选项设为“是”的主需求计划中寻找是否有来源该订单、该物品的主需求计划条目。如果有,就减少相应的主需求计划当前数量,并在计划中注明发货信息。由于这个流程和日期无关,因此实际发货时间是否提前,还是延迟,都不会对冲减产生影响。
如果计划管理器无法在需要冲减的主需求计划中找到相同来源、相同物品的条目,他会根据以下流程对来源类非销售订单的条目进行冲减:
减少与销售订单计划日期相同的条目。
如果没有相同日期的条目,或者发货数量大于可冲减数量,则从主需求计划的最早日期开始,向前顺序冲减那些非销售订单来源的条目。
如果到达主需求计划的终止日,发货仍然没有冲减完,则停止冲减流程。

所谓MPS,就是指主生产计划,主要是对成品一级的需求安排计划。而MRP是指物料需求计划,针对主生产计划,根据BOM,展开所有材料的需求。

MRP一般是由于MPS引起的,比如你有一个部件A MRP type=M0(MPS部件),它下面一个子部件B MRP TYPE=PD( MRP部件)。系统跑MPS的时候,只跑A部件,然后算出A的PL ORDER, 然后产出对B的DEPENDENT REQUIREMENT,然后系统跑MRP(当然对B了),系统根据那个DEPENDENT REQUIREMENT,跑出对B 的需求


MRP有三种:
1、MPS/2、MRP/3、基本消费计划
MPS包含(M0、M1、M2、M3、M4)
MRP包含(PD、P1、P2、P3、P4)
基于消费计划包含(重订货点、基于预测计划、基于时间物料计划)

补充一点:

如果物料主数据维护为M0、M1、M2、M3、M4等MPS类型,那么用MD40,MD41,MD42,MDBS等事务码来运行;MRP类型物料用MD01,MD02,MD03,MD43,MDBT等事务码来运行。

如果使用MD40或者MDBS运行MPS物料时候,可以选择是否同时运行下层MRP物料。

不管MPS物料还是MRP物料,运行的原理都是相同的,都是依照我们俗称的MRP逻辑计算

2013年9月1日星期日

INV>Guide To Resolving Pending Transaction Issues

PURPOSE
--------------
There are a variety of reasons for pending transactions. This paper will serve as a guide for
troubleshooting and resolving pending transaction issues which are preventing you from closing
an inventory accounting period.
PENDING TRANSACTIONS
--------------------------------------
I. VIEWING PENDING TRANSACTIONS
You can view the number of pending transactions by navigating to the Inventory Accounting
Periods form.
Nav > Cost > Accounting Close Cycle > Inventory Accounting Periods
Put your cursor on the appropriate open accounting period and click on the [Pending]
button. There are two zones titled “Resolution Required” and “Resolution Recommended.”
The Resolution Required zone displays the number of unprocessed material, uncosted
material, and pending WIP costing transactions existing in this period. Pending transactions
appearing in this zone must be resolved before the period can be closed.
The Resolution Recommended zone displays the number of pending receiving, pending
material and pending shop floor move transactions existing in this period. Pending transactions
appearing in this zone will not prevent closing of the accounting period. However, once the
accounting period is closed, unresolved pending transactions in this zone cannot be processed
because they have a transaction date for a closed period.
Pending transactions in the Unprocessed Material field indicate you have unprocessed
material transactions in the MTL_MATERIAL_TRANSACTONS_TEMP table .
Pending transactions in the Uncosted Material field indicate you have material transactions in
the MTL_MATERIAL_TRANSACTIONS table with unprocessed accounting entries.
Pending WIP Costing transactions indicate you have unprocessed resource and overhead
accounting transactions in the WIP_COST_TXN_INTERFACE TABLE.
Pending Receiving transactions indicate you have unprocessed purchasing transactions in the
RCV_TRANSACTIONS_INTERFACE table. These transactions include purchase order
receipts and returns for inventory. If this condition exists, you will receive a warning but will be
able to close the accounting period. These transactions are not included in your receiving value
if they are not resolved prior to closing the period.
Pending Material transactions indicate you have unprocessed material transactions in the
MTL_TRANSACTIONS_INTERFACE table.
Pending Move transactions indicate you have unprocessed shop floor move transactions in the
WIP_MOVE_TXN_INTERFACE table.

II. RESOLVING UNPROCESSED AND UNCOSTED MATERIAL
TRANSACTIONS
1. Unprocessed Material Transactions:
To resolve unprocessed Material Transactions, you need to determine and fix what is
preventing a record from being processed through the
MTL_MATERIAL_TRANSACTIONS_TEMP table. Details of pending transactions
can be viewed through the Applications by navigating to the Pending Transactions form.
Nav > Inventory > Transactions > Pending Transactions
By using the Pending Transactions window, you can view, edit, correct and resubmit
unprocessed material transactions. There are five selections in the alternate region list of
values: Error, Location, Source, Intransit and Other which provide detailed
information to help you resolve pending transactions. The key fields in these alternate
regions are called out below.
a) The Error alternate region:
- The error code describes the error on the last attempt to process the line
item.
- The error explanation gives a reason for the error.
- The process flag indicates whether the row has been processed by the
concurrent manager. The process flag codes are:
1 = Pending
2 = Running
3 = Error
- The transaction header ID is the number used to group transactions in
the concurrent manager.
- The transaction mode is the method used to process the line item, i.e.,
concurrent processing.
b) The Source alternate region:
- The Transaction Source Type, such as WIP Job or Schedule, is given.
c) The Others alternate region:
- The Department Code for the line item is given.
- The Employee Code identifies the employee who entered the
transaction.
2. Resubmitting Unprocessed Material Transactions:
In the Pending Transactions window either check the transaction’s Resubmit check box
to resubmit one record or chose Select All for Resubmit from the Special Menu. Now
save your work. The records can also be resubmitted via the following SQL statement:
Update MTL_MATERIAL_TRANSACTIONS_TEMP
Set PROCESS_FLAG = ‘Y’,
LOCK_FLAG = ‘N’,
TRANSACTION_MODE = 3,
ERROR_CODE = NULL
Where TRANSACTION_ID = ‘& TRANSACTION_ID’;
3. Uncosted Material Transactions:
To resolve uncosted Material Transactions you need to determine and fix what is
preventing a record from being processed through the
MTL_MATERIAL_TRANSACTIONS table. Details of uncosted transactions can be
viewed using SQL*PLUS.
Using SQL*PLUS you can determine how many records have been costed, are
pending or are in error by selecting the row COSTED_FLAG. The status codes for the
COSTED_FLAG are:
N = Not Costed
E = Error
Null = Costed
The following SQL select statements can be used to determine:
a) The number of erred rows in MTL_MATERIAL_TRANSACTIONS:
select count (*)
from MTL_MATERIAL_TRANSACTIONS
where COSTED_FLAG = ‘E’;
b) The number of unprocessed rows in MTL_MATERIAL_TRANSACTIONS:
select count (*)
from MTL_MATERIAL_TRANSACTIONS
where COSTED_FLAG = ‘N’;
c) The number of processed rows in MTL_MATERIAL_TRANSACTIONS:
select count (*)
from MTL_MATERIAL_TRANSACTIONS
where COSTED_FLAG like NULL;
To resubmit the erred records in the MTL_MATERIAL_TRANSACTIONS table, it
must be done via a SQL statement by updating the costed_flag = ‘N’ and the
transaction_group_id = NULL.
Update MTL_MATERIAL_TRANSACTIONS
set COSTED_FLAG = ‘N’,
set TRANSACTION_GROUP_ID = NULL
where COSTED_FLAG = ‘E’ or COSTED_FLAG = ‘N’;
If there is a record that is in error, look for a concurrent process that has erred. To view
a concurrent process that is in a status of error, navigate to:
Nav > System Administrator > Concurrent > Request
Run the query by entering %ost%orker% in the Name field and Error in the status field
of the Find Requests window.
In some cases, changing the profile option MRP:Debug Mode to ‘YES’, and resubmitting the
erred records may give you more information in the log files. You do this by navigating to:
System Administrator > Profile > System

III. RESOLVING PENDING MATERIAL TRANSACTIONS.
1. Pending Material Transactions:
Resolving Pending Material Transactions is a process of determining and fixing
what is preventing a record from being processed through the
MTL_TRANSACTIONS_INTERFACE table. Details of pending transactions
can be viewed through the application by navigating to the Transaction Open
Interface form:
Inventory > Transactions > Transaction Open Interface
Using the Transaction Open Interface window, you can view, edit, correct and resubmit
transactions received through the open interface. There are five selections in the
alternate region list of values: Error, Location, Source, Intransit and Other. These
provide detailed information to help you resolve pending transactions. In the Error
alternate region:
a. The error code describes the error on the last attempt to process the line item.
b. The error explanation gives a reason for the error.
c. The process flag indicates whether the row has been processed by the concurrent
manager. The process flag status codes are:
1 = Pending
2 = Running
3 = Error
2. Resubmitting Transactions for Processing:
In the Transaction Interface window, check the Resubmit [] box next to the transaction
you want to resubmit or choose Resubmit All from the Special menu. If you have many
transactions to resubmit, use the Resubmit All button to select all transactions for
processing and then selectively deselect individual transactions you do not want to
resubmit. Save your work to submit the transactions for processing.
The records can also be resubmitted using the following SQL statement:
Update MTL_TRANSACTIONS_INTERFACE
Set PROCESS_FLAG = 1,
LOCK_FLAG = 2,
TRANSACTION_MODE = 3,
ERROR_CODE = NULL
Where PROCESS_FLAG = 3;

IV. RESOLVING PENDING WIP COST TRANSACTIONS
1. Pending WIP Cost Transactions:
Resolving Pending WIP Cost transactions is a process of determining and fixing what is
preventing a record from being processed through the
WIP_COST_TXN_INTERFACE table. Details of pending transactions can be
viewed through the application by navigating to the pending resource transaction form.
WIP > Resource Transactions > Pending Resource Transactions
In the Pending Resource Transaction window you can view, update, delete, and
resubmit resource transactions that have failed validation and remain in the
WIP_COST_TXN_INTERFACE table. You can also resubmit transactions whose
concurrent process has failed and have a processing phase of Complete and process
status of Error. There are eight selections in the alternative region list of values:
Processing, Source, Concurrent Request, Job or Schedule Name, Operation,
Resource, Transaction and Comments.
Erred transactions will have the Transaction ID and Group ID populated and the Status
will be “Error.” Pending transactions will have the Transaction Id and Group ID fields
blank and the Status will be “Pending.”
To view error details for failed resource transactions, select the erred transaction and
click on the [Error] button. The Pending Resource Transaction error window appears.
Column indicates the name of the column in the resource transaction interface table
(WIP_COST_TXN_INTERFACE) that failed validation. Message indicates why the
transaction failed.
2. To resubmit failed resource transactions:
In the Pending Resource Transactions window, either check the transaction’s Resubmit
check box to resubmit one record or chose Select All for Resubmit from the Special
Menu. Now save your work. The records can also be resubmitted using the following
SQL statement:
Update WIP_COST_TXN_INTERFACE
Set GROUP_ID = NULL,
TRANSACTION_ID = NULL,
REQUEST_ID = NULL,
PROCESS_STATUS = 1
Where PROCESS_STATUS = 3;
When you resubmit a record, the system nulls the Transaction ID, Group ID,
and concurrent Request ID and changes the processing status to “Pending.”
3. To delete pending resource transaction records:
In the Pending Resource Transaction window, select the transaction and choose
delete from the edit window or choose the delete icon on the tool bar.

V. RESOLVING PENDING MOVE TRANSACTIONS
1. Pending Move Transactions:
Resolving unprocessed Move Transactions is a process of determining and fixing what is
preventing a record form being processed through the
WIP_MOVE_TXN_INTERFACE table. Details of pending move transactions can be
viewed through the applications by navigating to the pending move transaction form:
WIP > Move Transactions > Pending Move Transactions
Through the Pending Move Transaction window you can view, update, delete, and
resubmit move transaction records that have failed validation. You can also resubmit
transactions whose concurrent process has failed and have a processing phase of
complete and process status of “Error.”
There are seven selections in the alternative region list of values in the Pending Move
Transactions window: Processing, Source, Concurrent Request, Job or Schedule
Name, Operations, Transaction, Comments and Scrap Account.
Erred transactions will have the Transaction ID and Group ID populated and the Status
will be “Error.” Pending transactions will have the Transaction ID and Group ID fields
blank and the Status will be “Pending.”
To view error details for failed resource transaction, select the erred transaction and
click on the error button. The Pending Move Transaction error window appears.
Column indicates the name of the column in the resource transaction interface table
(WIP_MOVE_TXN_INTERFACE) that failed validation. Message indicates why the
transaction failed.
2. To resubmit failed move transactions:
In the Pending Move Transactions window, either check the transaction’s Resubmit
check box to resubmit one record or chose Select All for Resubmit from the Special
Menu. Now save your work. The records can also be resubmitted using the following
SQL statement:
Update WIP_MOVE_TXN_INTERFACE
Set GROUP_ID = NULL,
TRANSACTION_ID = NULL,
PROCESS_STATUS = 1
Where TRANSACTION_ID = ‘&TRANSACTION_ID’;
When you resubmit a record, the system nulls the Transaction ID, Group ID, and
concurrent Request ID and changes the processing status to “Pending.”
3. To delete pending move transaction records:
In the Pending Move Transaction window, select the transaction and choose delete
from the edit window or choose the delete icon on the tool bar.

VI. CONCLUSION
The key steps to resolving pending transactions are:
1. Locate the transaction.
2. Find the error message to determine what is preventing the transaction from
processing.
3. Resolve the error.
4. Resubmit the pending record.
If transactions are pending but not in error, you will need to resubmit them via SQL, using the
relevant SQL statement provided above.

2013年8月26日星期一

Sys>How to change code to corresponding meaning on form

"Generate Messages" for Language: US, Product: XXX

EBS 12 basic process flows

Forecast to Plan预测到计划
Procure to Pay采购到付款
Demand to Build需求到生产
Campaign to Order市场活动到订单
Click to Order点击到订单
Order to Cash订购到付款
Contract to Renewal合同到续订
Request to Resolution请求到解决
Project to Profit项目到利润
People to Paycheck人员到薪水
Plan to Replenish计划到补充
Benefits to Payroll福利到工资单