eTRM uses javascript that opens and focuses a separate window to display reports. Your browser does not appear to support javascript. This should not prevent you from using eTRM but it does mean the window focus feature will not work. Please check the contents of other windows on your desktop if you click on a link that does not appear to do anything.

APPS.CN_NOTIFY_ORDERS dependencies on CN_NOT_TRX_ALL

Line 98: -- We need to use CN_NOT_TRX_ALL instead of CN_NOT_TRX because this

94: IS
95: col_flag VARCHAR2(1) := 'Y';
96: BEGIN
97:
98: -- We need to use CN_NOT_TRX_ALL instead of CN_NOT_TRX because this
99: -- procedure is being called by Adjust_Order, which processes orders
100: -- from all orgs. This should be OK because we are selecting based on
101: -- header_id, which for Orders are unique identifiers across all orgs.
102:

Line 105: FROM cn_not_trx_all a

101: -- header_id, which for Orders are unique identifiers across all orgs.
102:
103: SELECT collected_flag
104: INTO col_flag
105: FROM cn_not_trx_all a
106: WHERE a.source_trx_id = hid
107: AND a.source_trx_line_id = lid
108: AND a.org_id = x_org_id
109: AND a.not_trx_id = ( SELECT max(b.not_trx_id)

Line 110: FROM cn_not_trx_all b

106: WHERE a.source_trx_id = hid
107: AND a.source_trx_line_id = lid
108: AND a.org_id = x_org_id
109: AND a.not_trx_id = ( SELECT max(b.not_trx_id)
110: FROM cn_not_trx_all b
111: WHERE b.source_trx_id = hid
112: AND b.source_trx_line_id = lid
113: AND b.org_id = a.org_id );
114:

Line 136: -- This means that new rows inserted into CN_NOT_TRX_ALL must get the

132: -- Note. Whereas Regular_Col_Notify is run for each Org, Notify_Line
133: -- is part of the Update Notification process, of which there is only
134: -- one instance for the installation - because we only have one
135: -- Notification Queue which passes us updates to orders from any Org.
136: -- This means that new rows inserted into CN_NOT_TRX_ALL must get the
137: -- Org_Id of the updated order rather than just defaulting to the
138: -- client Org-Id. (The defaulting is OK in regular_col_notify because
139: -- that procedure only selects orders for the Client Org anyway). For
140: -- this reason, we use CN_NOT_TRX_ALL here, rather than just CN_NOT_TRX

Line 140: -- this reason, we use CN_NOT_TRX_ALL here, rather than just CN_NOT_TRX

136: -- This means that new rows inserted into CN_NOT_TRX_ALL must get the
137: -- Org_Id of the updated order rather than just defaulting to the
138: -- client Org-Id. (The defaulting is OK in regular_col_notify because
139: -- that procedure only selects orders for the Client Org anyway). For
140: -- this reason, we use CN_NOT_TRX_ALL here, rather than just CN_NOT_TRX
141: -- and we explicitly set the Org_Id during our insert.
142:
143: -- History
144: --

Line 173: -- already a 'to-be-collected' record for the line in CN_NOT_TRX_ALL.

169: FETCH batch_size INTO l_sys_batch_size;
170: CLOSE batch_size;
171:
172: -- Call to Check_Last_Entry makes sure that there is not
173: -- already a 'to-be-collected' record for the line in CN_NOT_TRX_ALL.
174: IF Check_Last_Entry
175: (p_header_id,
176: p_line_id,
177: x_org_id) = 'Y' THEN

Line 178: INSERT INTO cn_not_trx_all (

174: IF Check_Last_Entry
175: (p_header_id,
176: p_line_id,
177: x_org_id) = 'Y' THEN
178: INSERT INTO cn_not_trx_all (
179: org_id,
180: not_trx_id,
181: batch_id,
182: notified_date,

Line 288: -- already a 'to-be-collected' record for the line in CN_NOT_TRX_ALL.

284: FETCH batch_size INTO l_sys_batch_size;
285: CLOSE batch_size;
286:
287: -- Call to Check_Last_Entry makes sure that there is not
288: -- already a 'to-be-collected' record for the line in CN_NOT_TRX_ALL.
289: IF Check_Last_Entry
290: (p_header_id,
291: p_line_id,
292: l_org_id) = 'Y' THEN

Line 293: INSERT INTO cn_not_trx_all (

289: IF Check_Last_Entry
290: (p_header_id,
291: p_line_id,
292: l_org_id) = 'Y' THEN
293: INSERT INTO cn_not_trx_all (
294: org_id,
295: not_trx_id,
296: batch_id,
297: notified_date,

Line 339: -- This procedure collects order line identifiers into cn_not_trx_all

335: ---------------------------------------------------------------------------+
336: -- Procedure Name
337: -- notify_affected_lines
338: -- Purpose
339: -- This procedure collects order line identifiers into cn_not_trx_all
340: -- of lines affected by a change to an order sales credit.
341: -- Design Note: A Top Model Line will have its own line_id in its
342: -- top_model_line_id column.
343: --

Line 590: -- Notify_Line then adds a new row in CN_NOT_TRX_ALL for the

586: -- and then act appropriately.
587: -- The general strategy is simply to call Notify_Line for each
588: -- existing order line which is affected by a change to an Order
589: -- Header, Line or Sales Credit.
590: -- Notify_Line then adds a new row in CN_NOT_TRX_ALL for the
591: -- order line. That strategy takes care of changes to existing
592: -- lines and addition of new lines. However for a line deletetion,
593: -- Notify_Line would not add a record for it in CN_NOT_TRX_ALL, because it
594: -- requeries the line to get more details,

Line 593: -- Notify_Line would not add a record for it in CN_NOT_TRX_ALL, because it

589: -- Header, Line or Sales Credit.
590: -- Notify_Line then adds a new row in CN_NOT_TRX_ALL for the
591: -- order line. That strategy takes care of changes to existing
592: -- lines and addition of new lines. However for a line deletetion,
593: -- Notify_Line would not add a record for it in CN_NOT_TRX_ALL, because it
594: -- requeries the line to get more details,
595: -- which would fail. We must have this record because
596: -- the collection process will use its presence to Reverse
597: -- the existing line in CN_COMM_LINES_API. That is why we call the special