Analytics Catalog/Oracle Fusion ERP/Payables/Vietnam Payment Voucher Report
Explore the catalogReportsModulesEnterprise modelOTBI subject areasBICC PVOs
Oracle Fusion · Payables

Vietnam Payment Voucher Report

Payables

The Vietnamese statutory payment voucher (Phiếu chi) — each payment in the local voucher format with payee, accounts, amount, and approver, as Vietnamese cash-payment rules require.

Run note · Performance  The subledger (XLA) join — especially Projects-to-XLA — is a known BI Publisher performance trap on large ledgers. Pre-join it in the warehouse, or apply tight ledger, period, and source filters before running online.

Sample build of the Vietnam Payment Voucher Report — reconciled, and rendered tool-neutral so it runs in Power BI, ThoughtSpot, or Tableau.

Vietnam Payment Voucher Report
Sample build · illustrative
Filters
P From Date
2026-02-28
P Payee Name
Globex Holdings
P Payment
Sample
P To Date
2026-02-28
2,400
Payment vouchers
$9.20M
Disbursed
11
No approver
Voucher NoDatePayeeAccountAmountApprover
10012026-04-30Sample1000-2100-000$1,240,500.00Sample
10022026-03-311000-5400-000$842,150.75
10032026-02-28Sample1000-1410-000$96,400.00Sample
10042026-01-312000-2100-000$1,005,233.10
10052025-12-31Sample1000-6300-000$58,720.40Sample
10012026-04-30Sample1000-2100-000$1,240,500.00Sample
AI Analyst · active
reading

The report reads AP payments tied to their XLA accounting in the Vietnamese payment-voucher layout.

flag

11 vouchers have no approver recorded — Vietnamese cash-payment rules require an authorized approver on every payment voucher.

root cause & next step

Enforce the approval step on payment vouchers; a missing approver invalidates the statutory voucher.

Illustrative data. The live interactive version — drill-through, filters, export, and the AI Analyst — runs on your warehouse. See it live →

This is the report's BI Publisher data model — the SQL data set BI Publisher runs against Oracle tables to produce the output. The same SQL becomes a dbt model in your warehouse, so one definition drives both the formatted report and the analytics layer.

Data sources

How it interconnects: this data set reads the physical tables above. Those same tables surface in OTBI as subject areas and in BICC as PVOs — three lenses on one source. Open any table to trace its subject areas and View Objects.
SQL data set · genericized · parameterized · no hardcoded segments
Show / hide SQL
select  
iby.payee_name
,ac.description
,ac.check_number payment  -- iby.paper_document_number
--,iby.payment_date     -- ac.check_date
,to_char(iby.PAYMENT_DATE,'DD-MON-YYYY','nls_date_language=American') PAYMENT_DATE
,iby.ext_bank_account_number sup_bank_account
,iby.ext_bank_name sup_bank_name
,iby.payment_amount
,iby.payment_currency_code
,(case when aia.description is not null then
    aia.invoice_num||'-'||aia.description
 else
     aia.invoice_num 
end) narrative
,sum((nvl(xdl.unrounded_entered_dr,0)- nvl(xdl.unrounded_entered_cr,0))) entered_amount
,sum((nvl(xdl.unrounded_accounted_dr,0) - nvl(xdl.unrounded_accounted_cr,0) )) accounted_amount
,xal.CURRENCY_CODE Entered_currency
,(case when xal.ENTERED_DR is not null then
    gcc.segment4
 when xal.ENTERED_CR is not null then
     gcc.segment4 
end) Liability_account
,gcc2.segment4 cc_account
,gcc2.segment4 cc_account2
,xdl.accounting_line_code

FROM ap_invoice_payments_all aipa
     ,ap_checks_all ac
	 ,ap_payment_hist_dists aphd 
	 ,xla_distribution_links xdl
	 ,xla_ae_lines xal
	 ,xla_ae_lines xal2
	 ,ap_invoices_all aia
	 ,gl_code_combinations gcc
	 ,iby_payments_all iby
	 ,gl_ledgers gl
	 --,ce_bank_accounts  cba
	 ,gl_code_combinations gcc2 
	 
WHERE 1=1
AND ac.check_id = aipa.check_id
AND ac.ORG_ID =  aipa.ORG_ID
AND aipa.invoice_payment_id = aphd.invoice_payment_id  
AND xdl.source_distribution_id_num_1 = aphd.payment_hist_dist_id
AND xdl.source_distribution_type = 'AP_PMT_DIST'
--AND xdl.accounting_line_code = 'AP_LIAB_CLEAR' --'AP_LIAB_PMT'
AND xdl.accounting_line_code in ( 'AP_LIAB_PMT','AP_LIAB_CLEAR')
AND xdl.ae_header_id = xal.ae_header_id
AND xdl.ae_line_num = xal.ae_line_num
AND xdl.application_id = xal.application_id

AND xal.ae_header_id = xal2.ae_header_id
--AND xdl.ae_line_num = xal2.ae_line_num
and xal2.ACCOUNTING_CLASS_CODE in ( 'CASH', 'CASH_CLEARING')
AND xdl.application_id = xal2.application_id
AND gcc2.code_combination_id=xal2.code_combination_id

AND aia.invoice_id = aipa.invoice_id
AND gcc.code_combination_id=xal.code_combination_id
AND iby.payment_id = ac.payment_id
AND iby.void_date is null
AND xal.ledger_id = gl.ledger_id
AND gl.ledger_category_code ='PRIMARY'
AND gl.NAME ='PL VIETNAM VND GAAP'
--AND iby.internal_bank_account_id = cba.bank_account_id
--AND cba.cash_clearing_ccid = gcc2.code_combination_id(+)

--and ac.check_number  in ('158','159')
AND ac.check_number  = nvl(:p_payment,ac.check_number)
AND aipa.posted_flag ='Y'
AND trunc(iby.payment_date) between :p_from_date AND :p_to_date
AND ((iby.payee_name  in (:p_payee_name)) or coalesce (:p_payee_name,null) is null )
AND ac.org_id in (
					SELECT  distinct bu.bu_id
					FROM fusion.fun_all_business_units_v bu
					,fusion.fun_user_role_data_asgnmnts role
					,fusion.per_users pu
					,fusion.per_roles_dn_vl pr
					,fusion.per_roles_dn_tl prtl
					WHERE role.org_id = bu.bu_id
					AND pu.user_guid = role.user_guid
					AND pr.role_common_name = role.ROLE_NAME
					and role.active_flag ='Y' 
					and pu.username = fnd_global.user_name
					and pr.role_id=prtl.role_id
					and prtl.LANGUAGE='US'
					and prtl.ROLE_NAME 
					in  ('XXC Accounts Payable Inquiry' 
						,'XXC Accounts Payables Manager'
						,'XXC Accounts Payable Analyst')
				)
group by 
iby.payee_name
,ac.description
,ac.check_number
,to_char(iby.PAYMENT_DATE,'DD-MON-YYYY','nls_date_language=American')
,iby.ext_bank_account_number 
,iby.ext_bank_name 
,iby.payment_amount
,iby.payment_currency_code
,(case when aia.description is not null then
    aia.invoice_num||'-'||aia.description
 else
     aia.invoice_num 
end) 
,xal.currency_code 
,(case when xal.entered_dr is not null then
    gcc.segment4
 when xal.entered_cr is not null then
     gcc.segment4 
end) 
,gcc2.segment4
,xdl.accounting_line_code
:p_from_date :p_payee_name :p_payment :p_to_date

The data-warehouse model — one fact surrounded by conformed dimensions (what you slice by) and measures (what you aggregate), expressed as dbt so it migrates with you. Grain: one row per source transaction.

AP_CHECKS_ALLdimensionXLA_AE_LINESdimensionAP_INVOICES_ALLdimensionGL_CODE_COMBINATIONSdimensionAP_INVOICE_PAYMENTS_ALLfact · one row per source transactionAmount
●— fact → dimension join
ElementTypeDefinition
AP_CHECKS_ALLdimensiondimension
XLA_AE_LINESdimensiondimension
AP_INVOICES_ALLdimensiondimension
GL_CODE_COMBINATIONSdimensiondimension
Amountmeasuremeasure
Runs on your cloud warehouse — Snowflake, BigQuery, Redshift, or Synapse on AWS, Google Cloud, Azure, or any provider. Reconciled to the source control total — 0% variance by design. You own the code, the model, and the data.
How the data gets here: a BICC bulk extract of the source tables above, on the same pattern for every report. See the extraction pattern & data flow →
See the complete model
How this report's fact and dimensions fit the full picture, via conformed keys.
Payables data model →Enterprise model →

Every source object behind this report. Each linked table has its own page with full column descriptions, drawn from the Oracle BICC lineage and articulated for practitioners.

TableReporting columnsSubject areas
AP_INVOICE_PAYMENTS_ALL222
AP_CHECKS_ALL446
XLA_AE_LINES2317
AP_INVOICES_ALL6315
GL_CODE_COMBINATIONS761
Reporting columns = fields the report selects that are exposed as analytics attributes; subject areas = the OTBI subject areas the table appears in. Setup and configuration tables (master data, ledger and book setup, lookups) are referenced by the report's joins but aren't exposed as analytics columns or subject areas — that's expected, not a gap.