APPS.PSA_FUNDS_CHECKER_PKG dependencies on GL_BALANCES

Line 279: /* GL_BALANCES */

275: /* GL_PERIOD_STATUSES */
276: /* GL_LOOKUPS */
277: /* GL_USSGL_TRANSACTION_CODES */
278: /* GL_USSGL_ACCOUNT_PAIRS */
279: /* GL_BALANCES */
280: /* GL_BUDGETS */
281: /* GL_BUDGET_VERSIONS */
282: /* GL_BUDGET_ASSIGNMENTS */
283: /* GL_BUDGET_PERIOD_RANGES */

Line 3460: -- between gl_bc_packets and gl_balances in the next two balance update

3456: -- psa_utils.debug_other_string(g_state_level,l_full_path, ' l_max_packet_id -> '|| l_max_packet_id );
3457: -- ========================= FND LOG =============================
3458:
3459: -- Lock dummy table gl_bc_dual in Row Share Mode to ensure Read Consistency
3460: -- between gl_bc_packets and gl_balances in the next two balance update
3461: -- SQLs. This scheme requires posting to lock gl_bc_dual in exclusive mode
3462: -- before it commits, and to wait in a sleep cycle of 15 seconds until all
3463: -- the Funds Check processes release the locks. This prevents the Funds
3464: -- Checker from counting the Balances twice, in case Posting Commits in

Line 3466: -- to gl_balances, where the funds checker would mistakenly treat them as

3462: -- before it commits, and to wait in a sleep cycle of 15 seconds until all
3463: -- the Funds Check processes release the locks. This prevents the Funds
3464: -- Checker from counting the Balances twice, in case Posting Commits in
3465: -- between the two SQLs, and some of the pending balances got transferred
3466: -- to gl_balances, where the funds checker would mistakenly treat them as
3467: -- Posted Balances in the second SQL
3468:
3469: -- When a lock on gl_bc_dual is not available then
3470: --

Line 3717: -- TABLE ACCESS BY ROWID GL_BALANCES

3713: -- NESTED LOOPS
3714: -- TABLE ACCESS BY ROWID GL_BC_PACKETS
3715: -- INDEX RANGE SCAN GL_BC_PACKETS_N1
3716: -- INDEX RANGE SCAN GL_BC_PERIOD_MAP_U2
3717: -- TABLE ACCESS BY ROWID GL_BALANCES
3718: -- INDEX RANGE SCAN GL_BALANCES_N1
3719: --
3720:
3721: -- Due to Bug 5644702 moved the fix of Bug 3243216 here.

Line 3718: -- INDEX RANGE SCAN GL_BALANCES_N1

3714: -- TABLE ACCESS BY ROWID GL_BC_PACKETS
3715: -- INDEX RANGE SCAN GL_BC_PACKETS_N1
3716: -- INDEX RANGE SCAN GL_BC_PERIOD_MAP_U2
3717: -- TABLE ACCESS BY ROWID GL_BALANCES
3718: -- INDEX RANGE SCAN GL_BALANCES_N1
3719: --
3720:
3721: -- Due to Bug 5644702 moved the fix of Bug 3243216 here.
3722:

Line 3799: gl_balances gb

3795: 'EPJTD', nvl(gb.project_to_date_dr, 0) -
3796: nvl(gb.project_to_date_cr, 0) +
3797: nvl(gb.period_net_dr, 0) - nvl(gb.period_net_cr, 0), 0))
3798: from gl_bc_period_map pm,
3799: gl_balances gb
3800: -- ## selecting the latest open period
3801: -- ## Changes made For fix in Bug 3243216
3802: /* (select effective_period_num e, period_name n,quarter_num q,
3803: period_year y, ledger_id s, application_id a from gl_period_statuses

Line 3822: -- based on latest open period and accordingly joining with gl_balances on query_period

3818: or gb.budget_version_id = pm.budget_version_id)
3819: -- ## Bug 3243216 replacement below
3820: AND GB.period_name = PM.query_period_name
3821: -- commented out below part as now we are selecting transaction period
3822: -- based on latest open period and accordingly joining with gl_balances on query_period
3823: /* AND GB.period_name = decode (PM.boundary_code, 'S', PM.query_period_name,
3824: decode(GB.actual_flag,
3825: 'B', PM.query_period_name,
3826: 'A', decode(GREATEST(BP.period_year*10000+BP.period_num, l_effective_period_num),