×
Discuss about OFS, Temenos Connectors, Various OFS modes, OFS with Versions, OFS performance, Logging, EB.PHANTOM, OFS.SOURCE etc…
OFS SS Validation
- andibaso
- Topic Author
- Offline
- New Member
-
Less
More
- Posts: 10
- Thank you received: 0
7 years 6 months ago #20288
by andibaso
OFS SS Validation was created by andibaso
Hi,
I just realized that when I send OFS message to T24, for example FT, When I send multivalue OFS message for DEBIT.ACCT.NO or CREDIT.ACCT.NO, it will create multiple field in FT Application for respective field. The worst thing, T24 create account with multi value @ID.
IMHO, T24 should validate OFS again SS. But, HD told me that it should be our middleware or client validate it before send T24.
FUNDS.TRANSFER,WS.TRF/I/PROCESS//,INPUTT/123456/,/,DEBIT.ACCT.NO:1:1=1010049918,DEBIT.CURRENCY:1:1=USD,DEBIT.AMOUNT:1:1=10000,CREDIT.ACCT.NO:1:1=USD1527900010001,CREDIT.ACCT.NO:2:1=USD1527900010001,IN.PRM.ACC.NO:1:1=0812110010101,IN.STAN:1:1=000034,IN.CHANNEL.ID:1:1=6018,IN.TRNS.DT.TM:1:1=100215205732,IN.TERMINAL.ID:1:1=00000034,IN.LOCATION:1:1=JMNNN,IN.UNIQUE.ID:1:1=400101000118,IN.REVERSAL.ID:1:1=6018000034100215205732,TRANSACTION.TYPE:1:1=ACAT
This FT is accepted by T24 and T24 create account with @ID "USD1527900010001 USD1527900010001"
Please kindly advice.
I just realized that when I send OFS message to T24, for example FT, When I send multivalue OFS message for DEBIT.ACCT.NO or CREDIT.ACCT.NO, it will create multiple field in FT Application for respective field. The worst thing, T24 create account with multi value @ID.
IMHO, T24 should validate OFS again SS. But, HD told me that it should be our middleware or client validate it before send T24.
FUNDS.TRANSFER,WS.TRF/I/PROCESS//,INPUTT/123456/,/,DEBIT.ACCT.NO:1:1=1010049918,DEBIT.CURRENCY:1:1=USD,DEBIT.AMOUNT:1:1=10000,CREDIT.ACCT.NO:1:1=USD1527900010001,CREDIT.ACCT.NO:2:1=USD1527900010001,IN.PRM.ACC.NO:1:1=0812110010101,IN.STAN:1:1=000034,IN.CHANNEL.ID:1:1=6018,IN.TRNS.DT.TM:1:1=100215205732,IN.TERMINAL.ID:1:1=00000034,IN.LOCATION:1:1=JMNNN,IN.UNIQUE.ID:1:1=400101000118,IN.REVERSAL.ID:1:1=6018000034100215205732,TRANSACTION.TYPE:1:1=ACAT
This FT is accepted by T24 and T24 create account with @ID "USD1527900010001 USD1527900010001"
Please kindly advice.
Please Log in or Create an account to join the conversation.
- jpb
-
- Offline
- Moderator
-
- TAFj-R20 - 'unix'
Less
More
- Posts: 2854
- Thank you received: 649
7 years 6 months ago #20295
by jpb
Replied by jpb on topic OFS SS Validation
Very ridiculous behaviour, even setting FIELD.VAL to YES in OFS.SOURCE doesn't work.
I suppose the generated ACCOUNT (a total empty record in $NAU) has its origin in the process for automated opening of internal accounts (so it won't happen with 2 customer accounts?).
Only workaround I see is attaching a IN.MSG.RTN to your OFS.SOURCE and do verification against SS yourself if you can't stop the source routine from generating wrong OFS messages.
I suppose the generated ACCOUNT (a total empty record in $NAU) has its origin in the process for automated opening of internal accounts (so it won't happen with 2 customer accounts?).
Only workaround I see is attaching a IN.MSG.RTN to your OFS.SOURCE and do verification against SS yourself if you can't stop the source routine from generating wrong OFS messages.
Please Log in or Create an account to join the conversation.
- andibaso
- Topic Author
- Offline
- New Member
-
Less
More
- Posts: 10
- Thank you received: 0
7 years 6 months ago #20298
by andibaso
Replied by andibaso on topic OFS SS Validation
Hi JPB,
This is the firs time I realized that such behavior exists. Anyway, generated account in LIVE file and related file for FT such as STMT.ENTRY>ACCOUNT.NO will refer to new created account. Did you have some experience?
We are working on workaround by validating very high risk field, such as FT>DEBIT.ACCT.NO and FT>CREDIT.ACCT.NO because it screw ACCOUNT, STMT.ENTRY, etc and avoid performance bottleneck. And it is not only happen to IA but also customer account.
This is the firs time I realized that such behavior exists. Anyway, generated account in LIVE file and related file for FT such as STMT.ENTRY>ACCOUNT.NO will refer to new created account. Did you have some experience?
We are working on workaround by validating very high risk field, such as FT>DEBIT.ACCT.NO and FT>CREDIT.ACCT.NO because it screw ACCOUNT, STMT.ENTRY, etc and avoid performance bottleneck. And it is not only happen to IA but also customer account.
Please Log in or Create an account to join the conversation.
Time to create page: 0.101 seconds