unauthorized Transaction over an account

  • johnnyslife
  • Topic Author
  • Offline
  • New Member
  • New Member
More
11 years 9 months ago #11845 by johnnyslife
unauthorized Transaction over an account was created by johnnyslife
Dear all

I need to know the unauthorized transaction affecting an account is due to which module (MM,TT,FT,etc..) & the ID of this transaction

What i actually do now is taking the account number & go search in unauthorized transaction under each module which really sucks

If any one have a solution , please let me know

Thanks in advance

Please Log in or Create an account to join the conversation.

More
11 years 9 months ago #11848 by durai611
Replied by durai611 on topic Re: unauthorized Transaction over an account
There is a file named FXXX.ENTRY.HOLD. This will help you to get the unauthorized entries for all transactions.

Please Log in or Create an account to join the conversation.

  • jpb
  • jpb's Avatar
  • Offline
  • Moderator
  • Moderator
  • TAFj-R20 - 'unix'
More
11 years 9 months ago #11850 by jpb
@durai
Do you also face the problem that records exist in ENTRY.HOLD / FWD.ENTRY.HOLD which have been delete from the respective application ? Have you ever reported this to the HD ??

And what is the intention of the fields ENTRY.HOLD / FWD.ENTRY.HOLD in ACCOUNT ? They should point to records in the mentioned files but in our installation there is no ACCOUNT with any value in this fields...

Please Log in or Create an account to join the conversation.

More
11 years 9 months ago #11852 by durai611
Replied by durai611 on topic Re: unauthorized Transaction over an account
Do you also face the problem that records exist in ENTRY.HOLD / FWD.ENTRY.HOLD which have been delete from the respective application ? Have you ever reported this to the HD ??

What problem? I can't get you.
The records exist in ENTRY.HOLD / FWD.ENTRY.HOLD is of unauthorized transaction entries. During EOD in job UNAUTH.PROCESSING these records will get deleted if .UNP is set for the respective applications in PGM.FILE.

And what is the intention of the fields ENTRY.HOLD / FWD.ENTRY.HOLD in ACCOUNT ? They should point to records in the mentioned files but in our installation there is no ACCOUNT with any value in this fields...

As of I know these fields are not updated right now. But in help text it's mentioned.

Please Log in or Create an account to join the conversation.

  • johnnyslife
  • Topic Author
  • Offline
  • New Member
  • New Member
More
11 years 9 months ago #11853 by johnnyslife
Replied by johnnyslife on topic Re: unauthorized Transaction over an account
Dear Durai

Thanks for your reply , but FXXX.ENTYR.HOLD , contains all unauthorized entries overall the system with @ ID only (transaction reference) , what am asking for i have account number & want to know the unauthorized debits on this account & their IDs

Please Log in or Create an account to join the conversation.

  • jpb
  • jpb's Avatar
  • Offline
  • Moderator
  • Moderator
  • TAFj-R20 - 'unix'
More
11 years 9 months ago #11854 by jpb
@durai:
The point is that there are records in ENTRY.HOLD / FWD.ENTRY.HOLD pointing to non existing transactions (neither live nor $NAU) which gives the impression that one can't rely on its content ;-)

And yes, I know the doc - that's why I'm asking. These fields would be the easy solution for johnnyslife's problem, but ...
The fields are there since 2004, so it's taking more that 8 years to implement them? Strange !!

@johnnyslife:
the records in Fxxx.ENTRY.HOLD have the layout of STMT.ENTRY, you just have to RAISE each line. I think looping thru ENTRY.HOLD and building an array of pending transactions by account will be much quicker than searching thru different applications...
The following user(s) said Thank You: johnnyslife

Please Log in or Create an account to join the conversation.

More
11 years 9 months ago #11855 by durai611
Replied by durai611 on topic Re: unauthorized Transaction over an account
@jpb
"The point is that there are records in ENTRY.HOLD / FWD.ENTRY.HOLD pointing to non existing transactions (neither live nor $NAU) which gives the impression that one can't rely on its content"

If there is any records like you mentioned then we have to raise it with HD ;-)

"And yes, I know the doc - that's why I'm asking. These fields would be the easy solution for johnnyslife's problem, but ...
The fields are there since 2004, so it's taking more that 8 years to implement them? Strange !!"

They might have not implemented because of write on Account file and locking/performance problems. ;-)

Please Log in or Create an account to join the conversation.

Time to create page: 0.123 seconds