0% found this document useful (0 votes)
10 views3 pages

Charge Calculation Issue for Account 76301054672568

Uploaded by

ARYAN AGRAHARI
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views3 pages

Charge Calculation Issue for Account 76301054672568

Uploaded by

ARYAN AGRAHARI
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

TFS 134808

Charge amount was calculated as zero :


select * from ictb_entries_history where brn = '601' and acc = '76301054672568' and
prod = 'PZGD';

The reason for this is that the SDE "ACCOUNT_TOD_WDAY" was resolved as zero.

And this is because the earliest FROM_DT in STTB_TOD_LIMIT_VALS_CU is 19.10.2021 ,


which is > than the liquidation date 18.10.2021.

select * from STTB_TOD_LIMIT_VALS_CU where cust_Ac_no = '76301054672568' order by


from_dt;

-------------------------------------------------------

select * from ictb_acc_pr where acc = '76301054672568'; --PZGD

select * from ictb_entries where acc = '76301054672568' and prod = 'PZGD'


select * from ictb_entries_history where brn = '601' and acc = '76301054672568' and
prod = 'PZGD';

select * from actb_daily_log where related_account = '76301054672568';


select * from dqtb_deferred_entries_cu where related_account = '76301054672568';

select * from ictm_acc_udevals where acc = '76301054672568' and prod = 'PZGD'; --20
, 18-10-2021 !!

select * from STTMS_ACCOUNT_TOD_RENEW where cust_Ac_no = '76301054672568' ;

select tod_limit, TOD_LIMIT_END_DATE, account_class from sttm_cust_Account where


cust_Ac_no = '76301054672568' ;

select * from STTB_TOD_LIMIT_VALS_CU where cust_Ac_no = '76301054672568' order by


from_dt;
select * from sttm_cust_account_cu where cust_Ac_no = '76301054672568' ;

ACCOUNT_TOD_WDAY > 0 CHARGE 1

--- SCRIPT 1 ONLINE CALC : from dt TO dt


declare
l_ac_brn varchar2(3);
l_account_no varchar2(20);
l_ic_product varchar2(4);
l_frm_date date;
l_to_date date ;
begin
rollback;
update cstb_debug set debug = 'Y' ;
update cstb_debug_users set debug ='Y' where user_id = 'SYSTEM';
update cstb_param set param_val = 'Y' where param_name = 'REAL_DEBUG';
for k in ( select * from ictb_acc_pr where acc = '76301054672568' and prod =
'PZGD' )
loop

l_frm_date := to_date('26.06.2021','[Link]');
l_to_date := to_date('18.10.2021','[Link]');
l_ac_brn := [Link];
l_ic_product := [Link];
l_account_no := [Link];

debug.pr_close();
global.pr_init (l_ac_brn, 'SYSTEM');

/*
--after
update sttm_cust_account
set tod_limit_end_date = trunc(sysdate) +8000
where cust_ac_no = l_account_no;*/

icpks_test.pr_icalc(l_ac_brn,
l_account_no,
l_ic_product,
l_frm_date,
l_to_date);
end loop;
end;
/

select * from ictw_memo_booking;

SELECT * FROM (
SELECT R.BRANCH_CODE,
R.CUST_AC_NO,
GREATEST(Z.FROM_DT, to_date('26-JUN-21','dd-MON-RRRR')) FROM_DT,
LEAST(
CEPKSS_DATE.FN_GETWORKINGDAY('LCL',
'601',
NVL(TO_DT,
NVL(R.TOD_LIMIT_END_DATE,

to_date('18-OCT-21','dd-
MON-RRRR'))),
'N',
1)-1,
to_date('18-OCT-21','dd-MON-RRRR'))TO_DT,
VAL
FROM STTB_TOD_LIMIT_VALS_CU Z, STTMS_CUST_ACCOUNT R
WHERE Z.BRANCH_CODE = '601'
AND Z.CUST_AC_NO = '76301054672568'
AND Z.BRANCH_CODE = R.BRANCH_CODE
AND Z.CUST_AC_NO = R.CUST_AC_NO
AND Z.FROM_DT >= NVL((SELECT MAX(T1.FROM_DT) FROM STTB_TOD_LIMIT_VALS_CU
T1 WHERE T1.BRANCH_CODE = R.BRANCH_CODE AND T1.CUST_AC_NO = R.CUST_AC_NO AND
T1.FROM_DT <= to_date('26-JUN-21','dd-MON-RRRR')),to_date('26-JUN-21','dd-MON-
RRRR'))
AND (Z.TO_DT <= NVL((SELECT MIN(T1.TO_DT) FROM STTB_TOD_LIMIT_VALS_CU T1
WHERE T1.BRANCH_CODE = R.BRANCH_CODE AND T1.CUST_AC_NO = R.CUST_AC_NO AND T1.TO_DT
>= to_date('18-OCT-21','dd-MON-RRRR') ),to_date('18-OCT-21','dd-MON-RRRR'))
OR
( Z.TO_DT IS NULL AND Z.FROM_DT <= to_date('18-OCT-21','dd-MON-
RRRR') )
)
) WHERE FROM_DT <= TO_DT

ORDER BY FROM_DT;

Common questions

Powered by AI

Deferred entries can affect the calculation of account balances by altering the timing at which certain transactions impact the account's actual balance. Entries in tables such as dqtb_deferred_entries_cu can delay when financial activities are reflected in the account, thereby affecting charge and interest calculations if the balance adjustments are postponed to future dates .

The STTB_TOD_LIMIT_VALS_CU table affects the calculation of account charges by specifying the time limits (FROM_DT and TO_DT) for which certain conditions apply. If the dates in this table do not align correctly with the liquidation or relevant operation dates, as seen in the case where FROM_DT was later than the liquidation date, it could lead to a zero calculation for charges due to the SDE 'ACCOUNT_TOD_WDAY' being resolved as zero .

Updating CSTB_DEBUG and CSTB_PARAM is crucial for enabling debugging and parameter settings that allow system administrators to track and resolve issues. Setting these to 'Y' activates debug mode, which logs detailed operation flows, helping in troubleshooting by providing more visibility into the system's internal workings and transactions during issue resolutions .

Performing a rollback is significant in maintaining database integrity, allowing for the reversal of operations if an error or inconsistency is detected during updates. It is a safety mechanism ensuring no partial or corrupt data updates persist when altering system parameters. This is especially crucial in banking due to the critical importance of data accuracy and reliability .

The global.pr_init procedure is likely used to initialize the processing environment for the bank system under a specified branch and user, in this case, 'SYSTEM'. This setup ensures that subsequent operations, such as icpks_test.pr_icalc, are executed within the correct context, facilitating accurate processing and debugging during problem resolution .

The system determines the appropriate FROM_DT and TO_DT for interest calculations using a combination of the greatest value between the specified FROM_DT and operational dates as well as the least value of calculated workdays or defined TO_DT limits. These dates are fetched based on specific conditions such as matching branch codes and customer account numbers from relevant tables like STTB_TOD_LIMIT_VALS_CU and STTMS_CUST_ACCOUNT .

Having a FROM_DT that is greater than the liquidation date can lead to incorrect calculations of charges or interest rates, such as in the case where ACCOUNT_TOD_WDAY resolves to zero, leading to a zero charge amount. This misalignment implies that the temporal parameters set for charge calculations do not apply correctly, potentially causing financial discrepancies or operational errors in charge handling .

The charge amount was calculated as zero because the SDE 'ACCOUNT_TOD_WDAY' was resolved as zero. The reason for this resolution was that the earliest date in the STTB_TOD_LIMIT_VALS_CU table ('FROM_DT') was 19.10.2021, which was later than the liquidation date of 18.10.2021. This discrepancy resulted in the charge amount calculation as zero .

The STTM_CUST_ACCOUNT table is critical for managing bank accounts as it holds essential pieces of information such as the TOD_LIMIT and TOD_LIMIT_END_DATE. These fields define key parameters like the limit and expiry of certain account privileges or conditions, which directly influence account operations and the application of charges or fees .

Changing TOD_LIMIT_END_DATE during system updates is necessary to ensure the validity of temporal constraints applied to an account. Extending or updating this date can adjust operational limits or charge conditions to correctly reflect current agreements or regulatory requirements, preventing operational issues or incorrect calculations due to outdated settings .

You might also like