APPS.PSA_FUNDS_CHECKER_PKG dependencies on GL_BALANCES

Line 290: /* GL_BALANCES */

286: /* GL_PERIOD_STATUSES */
287: /* GL_LOOKUPS */
288: /* GL_USSGL_TRANSACTION_CODES */
289: /* GL_USSGL_ACCOUNT_PAIRS */
290: /* GL_BALANCES */
291: /* GL_BUDGETS */
292: /* GL_BUDGET_VERSIONS */
293: /* GL_BUDGET_ASSIGNMENTS */
294: /* GL_BUDGET_PERIOD_RANGES */

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

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

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

3496: -- before it commits, and to wait in a sleep cycle of 15 seconds until all
3497: -- the Funds Check processes release the locks. This prevents the Funds
3498: -- Checker from counting the Balances twice, in case Posting Commits in
3499: -- between the two SQLs, and some of the pending balances got transferred
3500: -- to gl_balances, where the funds checker would mistakenly treat them as
3501: -- Posted Balances in the second SQL
3502:
3503: -- When a lock on gl_bc_dual is not available then
3504: --

Line 3792: -- TABLE ACCESS BY ROWID GL_BALANCES

3788: -- NESTED LOOPS
3789: -- TABLE ACCESS BY ROWID GL_BC_PACKETS
3790: -- INDEX RANGE SCAN GL_BC_PACKETS_N1
3791: -- INDEX RANGE SCAN GL_BC_PERIOD_MAP_U2
3792: -- TABLE ACCESS BY ROWID GL_BALANCES
3793: -- INDEX RANGE SCAN GL_BALANCES_N1
3794: --
3795:
3796: -- Due to Bug 5644702 moved the fix of Bug 3243216 here.

Line 3793: -- INDEX RANGE SCAN GL_BALANCES_N1

3789: -- TABLE ACCESS BY ROWID GL_BC_PACKETS
3790: -- INDEX RANGE SCAN GL_BC_PACKETS_N1
3791: -- INDEX RANGE SCAN GL_BC_PERIOD_MAP_U2
3792: -- TABLE ACCESS BY ROWID GL_BALANCES
3793: -- INDEX RANGE SCAN GL_BALANCES_N1
3794: --
3795:
3796: -- Due to Bug 5644702 moved the fix of Bug 3243216 here.
3797:

Line 3874: gl_balances gb

3870: 'EPJTD', nvl(gb.project_to_date_dr, 0) -
3871: nvl(gb.project_to_date_cr, 0) +
3872: nvl(gb.period_net_dr, 0) - nvl(gb.period_net_cr, 0), 0))
3873: from gl_bc_period_map pm,
3874: gl_balances gb
3875: -- ## selecting the latest open period
3876: -- ## Changes made For fix in Bug 3243216
3877: /* (select effective_period_num e, period_name n,quarter_num q,
3878: period_year y, ledger_id s, application_id a from gl_period_statuses

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

3893: or gb.budget_version_id = pm.budget_version_id)
3894: -- ## Bug 3243216 replacement below
3895: AND GB.period_name = PM.query_period_name
3896: -- commented out below part as now we are selecting transaction period
3897: -- based on latest open period and accordingly joining with gl_balances on query_period
3898: /* AND GB.period_name = decode (PM.boundary_code, 'S', PM.query_period_name,
3899: decode(GB.actual_flag,
3900: 'B', PM.query_period_name,
3901: 'A', decode(GREATEST(BP.period_year*10000+BP.period_num, l_effective_period_num),