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

Vietnam Receipt Voucher Report

Receivables

The Vietnamese statutory receipt voucher (Phiếu thu) — each cash receipt in the local voucher format with payer, accounts, amount, and approver, as Vietnamese cash rules require.

Related  The receipts counterpart to the Vietnam Payment Voucher Report.

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 Receipt Voucher Report — reconciled, and rendered tool-neutral so it runs in Power BI, ThoughtSpot, or Tableau.

Vietnam Receipt Voucher Report
Sample build · illustrative
Filters
P Cust Num
1003
P From Date
2026-02-28
P Receipt
Sample
P To Date
2026-02-28
1,900
Receipt vouchers
$11.40M
Received
8
No approver
Voucher NoDatePayerAccountAmountApprover
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 AR receipts tied to their XLA accounting in the Vietnamese receipt-voucher layout.

flag

Eight vouchers have no approver recorded — Vietnamese cash rules require an authorized approver on every receipt voucher.

root cause & next step

Enforce the approval step on receipt 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 
 hp.party_name PAYER_NAME  ,hca.account_number customer_num
,acra.comments
,acra.receipt_number
,to_char(acra.receipt_date,'DD-MON-YYYY','nls_date_language=American') receipt_date  
,gcc.segment4 CASH_ACCOUNT
,ieba.bank_account_number CUST_BANK_ACCOUNT
,ieba.bank_name CUST_BANK_NAME
,acra.amount RECEIPT_AMOUNT

,acra.currency_code CURRENCY 
,(case when rcta.COMMENTS is not null then
    rcta.trx_number ||'-'|| rcta.COMMENTS
 else
     rcta.trx_number 
end)  Narrative 
,araa.amount_applied --,acra.amount * nvl(acra.exchange_rate,1) functional_amount
,araa.amount_applied * nvl(acra.exchange_rate,1) functional_amount
,gcc.segment4 DR_ACCOUNT
,b.segment4 CR_ACCOUNT

from gl_je_lines gjl , gl_code_combinations b 
,gl_je_headers gjh
,gl_import_references gir
,xla_ae_lines xlal
,xla_ae_headers xlah
,xla_transaction_entities xlate
,xla_distribution_links xladl
,ar_distributions_all ada
,ar_receivable_applications_all  araa
,ar_cash_receipts_all acra
,gl_ledgers gl
,ce_bank_acct_uses_all cbaua
,ce_bank_accounts  cba
,gl_code_combinations gcc
,hz_parties hp
,hz_cust_accounts hca
,iby_ext_bank_accounts_v ieba
,ra_customer_trx_all rcta

where 1=1
 and gjl.code_combination_id=b.code_combination_id 
--and gjl.je_header_id in (149065,149066)
and gjl.je_header_id=gjh.je_header_id
and gir.je_header_id = gjl.je_header_id
and gir.je_line_num = gjl.je_line_num
and xlal.gl_sl_link_id = gir.gl_sl_link_id
and xlah.ae_header_id= xlal.ae_header_id
and xlate.entity_id =xlah.entity_id
and xladl.ae_header_id = xlal.ae_header_id
and xladl.ae_line_num = xlal.ae_line_num
and xlal.application_id =222
and xladl.source_distribution_type ='AR_DISTRIBUTIONS_ALL'
and xladl.accounting_line_code ='RCT_DEFAULT_APP'
and xladl.source_distribution_id_num_1 = ada.line_id
and ada.source_id = araa.receivable_application_id
and araa.display='Y'
and xlal.ledger_id = gl.ledger_id
and gl.ledger_category_code ='PRIMARY'
and gl.name ='PL VIETNAM VND GAAP'
and acra.cash_receipt_id = araa.cash_receipt_id
and acra.remit_bank_acct_use_id = cbaua.bank_acct_use_id
and cbaua.bank_account_id = cba.bank_account_id
and cba.asset_code_combination_id=gcc.code_combination_id
and acra.pay_from_customer = hca.cust_account_id
and hca.party_id = hp.party_id
and acra.customer_bank_account_id  =ieba.bank_account_id (+)
and araa.display = 'Y'
and araa.applied_customer_trx_id = rcta.customer_trx_id 

and acra.receipt_date between :p_from_date and :p_to_date
and acra.receipt_number = NVL (:p_receipt,acra.receipt_number)
and ((hca.account_number  IN (:p_cust_num)) OR COALESCE (:p_cust_num,null) is null )

AND  acra.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 Receivables Inquiry')
					AND BU.SHORT_CODE ='VN BU VND'
							
			  )
:p_cust_num :p_from_date :p_receipt :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.

AR_RECEIVABLE_APPLICATIO…dimensionXLA_AE_LINESdimensionGL_CODE_COMBINATIONSdimensionHZ_CUST_ACCOUNTSdimensionAR_CASH_RECEIPTS_ALLfact · one row per source transactionAmount
●— fact → dimension join
ElementTypeDefinition
AR_RECEIVABLE_APPLICATIONS_ALLdimensiondimension
XLA_AE_LINESdimensiondimension
GL_CODE_COMBINATIONSdimensiondimension
HZ_CUST_ACCOUNTSdimensiondimension
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.
Receivables 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
AR_CASH_RECEIPTS_ALL259
AR_RECEIVABLE_APPLICATIONS_ALL352
XLA_AE_LINES2317
GL_CODE_COMBINATIONS761
HZ_CUST_ACCOUNTS1443
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.