Developer Resources
Details
| SoapAction | http://jackhenry.com/ws/TrnSetItemSrch |
| Input Name | TrnSetItemSrch |
| Output Name | TrnSetItemSrchResponse |
| Input Namespace | http://jackhenry.com/jxchange/TPG/2008 |
| Group Name | Inquiry |
| Container | TPG_InquiryMaster.xsd |
XML Examples
Request
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <wsse:Username>INSERT</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">INSERT</wsse:Password> <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2018-01-09T17:53:46Z </wsu:Created> </wsse:UsernameToken> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> <TrnSetItemSrch xmlns="http://jackhenry.com/jxchange/TPG/2008"> <SrchMsgRqHdr> <jXchangeHdr> <JxVer/> <AuditUsrId>INSERT</AuditUsrId> <AuditWsId>INSERT</AuditWsId> <AuthenUsrId/> <ConsumerName/> <ConsumerProd/> <Ver_1/> <jXLogTrackingId>INSERT</jXLogTrackingId> <Ver_2/> <InstRtId JHANull="" Rstr="">INSERT</InstRtId> <InstEnv>TEST</InstEnv> <Ver_3/> <BusCorrelId/> <Ver_4/> <WorkflowCorrelId/> <Ver_5/> <ValidConsmName>INSERT</ValidConsmName> <ValidConsmProd>INSERT</ValidConsmProd> <Ver_6/> </jXchangeHdr> <MaxRec>20</MaxRec> <Cursor/> <Ver_1/> <Ver_2/> <Ver_3/> </SrchMsgRqHdr> <ImgNum JHANull="" Rstr="">INSERT</ImgNum> <Custom/> <Ver_1/> </TrnSetItemSrch> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
<?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <wsse:UsernameToken xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <wsse:Username>INSERT</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">INSERT</wsse:Password> <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2018-01-09T17:53:46Z </wsu:Created> </wsse:UsernameToken> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> <TrnSetItemSrch xmlns="http://jackhenry.com/jxchange/TPG/2008"> <SrchMsgRqHdr> <jXchangeHdr> <JxVer/> <AuditUsrId>INSERT</AuditUsrId> <AuditWsId>INSERT</AuditWsId> <AuthenUsrId/> <ConsumerName/> <ConsumerProd/> <Ver_1/> <jXLogTrackingId>INSERT</jXLogTrackingId> <Ver_2/> <InstRtId JHANull="" Rstr="">INSERT</InstRtId> <InstEnv>TEST</InstEnv> <Ver_3/> <BusCorrelId/> <Ver_4/> <WorkflowCorrelId/> <Ver_5/> <ValidConsmName>INSERT</ValidConsmName> <ValidConsmProd>INSERT</ValidConsmProd> <Ver_6/> </jXchangeHdr> <MaxRec>20</MaxRec> <Cursor/> <Ver_1/> <Ver_2/> <Ver_3/> </SrchMsgRqHdr> <ImgNum JHANull="" Rstr="">INSERT</ImgNum> <Custom/> <Ver_1/> </TrnSetItemSrch> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
FAQ
TrnSetItemSrchFAQ
TrnSetItemSrch Questions
Q: During recent testing the bank noticed that when we use the queries needed to pull back Deposit&Check images, there are instances where the ABA is missing, an ABA that is not used by the bank is presented, or the leading zero has been stripped off of the ABA. Could you help us determine why the ABA is missing, incomplete, or incorrect in some instances? Or, if we should be using a different value provided by 4sight to populate this field?
A: The RTNum field will contain the routing number from the item itself. It may or may not be the banks TR, depending on if the item is a check, or is a transit item or On-Us item. Some scanned documents don’t have TR numbers. In addition, sometimes the TR is translated on the check into a different TR (this is the case when the bank has purchased another bank, and they import old items from that bank, it will translate it to the new, correct, TR number).
The deposit ticket with the “wrong” aba number is actually showing the encoded ABA number. This could be a GL or something the bank has encoded on the ticket in the TR spot as a place holder. It’s either being accepted as a valid TR because the bank has entered that in as a valid number for deposit slips (most likely) or the system has rejected it, and an operator overrode it in and forced it to pass through. We don’t really know which is the case without doing some research.
If the user wants leading zero’s, and there isn’t one, then somewhere along the way it was stripped out. The checks come from many places – vendors, tellers, other banks as in clearings, etc. They can always detect that it’s too short and add the leading zero if needed.
TrnSetItemSrch Questions
Q: During recent testing the bank noticed that when we use the queries needed to pull back Deposit&Check images, there are instances where the ABA is missing, an ABA that is not used by the bank is presented, or the leading zero has been stripped off of the ABA. Could you help us determine why the ABA is missing, incomplete, or incorrect in some instances? Or, if we should be using a different value provided by 4sight to populate this field?
A: The RTNum field will contain the routing number from the item itself. It may or may not be the banks TR, depending on if the item is a check, or is a transit item or On-Us item. Some scanned documents don’t have TR numbers. In addition, sometimes the TR is translated on the check into a different TR (this is the case when the bank has purchased another bank, and they import old items from that bank, it will translate it to the new, correct, TR number).
The deposit ticket with the “wrong” aba number is actually showing the encoded ABA number. This could be a GL or something the bank has encoded on the ticket in the TR spot as a place holder. It’s either being accepted as a valid TR because the bank has entered that in as a valid number for deposit slips (most likely) or the system has rejected it, and an operator overrode it in and forced it to pass through. We don’t really know which is the case without doing some research.
If the user wants leading zero’s, and there isn’t one, then somewhere along the way it was stripped out. The checks come from many places – vendors, tellers, other banks as in clearings, etc. They can always detect that it’s too short and add the leading zero if needed.