Developer Resources

<?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>
      </wsse:UsernameToken>
    </wsse:Security>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <AcctHistSrch
      xmlns="http://jackhenry.com/jxchange/TPG/2008">
      <SrchMsgRqHdr>
        <jXchangeHdr>
          <JxVer/>
          <AuditUsrId></AuditUsrId>
          <AuditWsId></AuditWsId>
          <AuthenUsrId/>
          <ConsumerName/>
          <ConsumerProd/>
          <Ver_1/>
          <jXLogTrackingId>{Insert}</jXLogTrackingId>
          <Ver_2/>
          <InstRtId>011001276</InstRtId>
          <InstEnv>TEST</InstEnv>
          <Ver_3/>
          <BusCorrelId/>
          <Ver_4/>
          <WorkflowCorrelId/>
          <Ver_5/>
          <ValidConsmName>{Insert}</ValidConsmName>
          <ValidConsmProd>{Insert}</ValidConsmProd>
          <Ver_6/>
        </jXchangeHdr>
        <MaxRec>350</MaxRec>
        <Cursor>0</Cursor>
        <Ver_1/>
        <Ver_2/>
        <Ver_3/>
      </SrchMsgRqHdr>
      <InAcctId>
        <AcctId>8318033</AcctId>
        <AcctType>D</AcctType>
        <Ver_1/>
      </InAcctId>
      <StartDt>2017-04-22</StartDt>
      <EndDt>2018-05-23</EndDt>
      <LowAmt>0.00</LowAmt>
      <HighAmt>20000.00</HighAmt>
      <MemoPostInc>only</MemoPostInc>
      <SvcPrvdInfo/>
      <Custom/>
      <Ver_1/>
      <XferKey/>
      <Ver_2/>
      <IncXtendElemArray/>
      <Ver_3/>
      <TrnRcptId></TrnRcptId>
      <Ver_4/>
    </AcctHistSrch>
  </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>
      </wsse:UsernameToken>
    </wsse:Security>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <AcctHistSrch
      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>011001276</InstRtId>
          <InstEnv>TEST</InstEnv>
          <Ver_3/>
          <BusCorrelId/>
          <Ver_4/>
          <WorkflowCorrelId/>
          <Ver_5/>
          <ValidConsmName>{Insert}</ValidConsmName>
          <ValidConsmProd>{Insert}</ValidConsmProd>
          <Ver_6/>
        </jXchangeHdr>
        <MaxRec>35</MaxRec>
        <Cursor>0</Cursor>
        <Ver_1/>
        <Ver_2/>
        <Ver_3/>
      </SrchMsgRqHdr>
      <InAcctId>
        <AcctId>5500</AcctId>
        <AcctType>L</AcctType>
        <Ver_1/>
      </InAcctId>
      <MemoPostInc>Only</MemoPostInc>
      <SvcPrvdInfo/>
      <Custom/>
      <Ver_1/>
      <XferKey/>
      <Ver_2/>
      <IncXtendElemArray/>
      <Ver_3/>
      <TrnRcptId>JVDBC75MD8</TrnRcptId>
      <Ver_4/>
    </AcctHistSrch>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Q: How can I determine if an account is currently delinquent?

A: Below is the available loan account statuses. Statuses 5, 6, 7, and 8 are useful for your question on delinquency.

1. The loan is active. Transactions will be accepted.
2. The loan is closed. Transactions will not be accepted.
3. The loan is matured. The system will not allow advances to post.
4. The loan is new today. Transactions will be accepted.
5. The loan is open but not accruing. Transactions will be accepted.
6. The loan is accruing, but frozen. Transactions will not be accepted.
7. The loan is frozen and not accruing. Transactions will not be accepted.
8. The loan is charged off. It is not accruing. Transactions will be accepted.

The status code should be left at 4 for all new loans. The ability to enter status codes 5,6,7, and 8 is provided primarily for the purpose of adding charged-off loans to the system after conversion. Some servicing companies do not carry charged-off loans in their database and they are not, therefore, converted to the JHA system.

The field PastDueTerm would tell them how many days the account is past due, but each institution could vary on what they consider 'delinquent'.

Q: I am trying to use the account history search operation to provide 2 lists: payments and transactions. I understand that payments are just a subset of the transactions. I did not see a field that identifies that a transaction is a payment. I did notice that in the sample data several TrnCodeDesc values include the word payment. Is this field the only way to determine if a transaction is a payment?

A: TranCodes are core parameter driven and will vary from FI to FI. To obtain a list of all possible TranCodeCode values for a system you can call the ParmValSrch service and pass in ParmName = TranCodeCode. Attached is an example that was run against the SilverLake test bank on the DMZ. Note that TranCode and descriptions would differ for CIF 20/20 and Core Director, the other two Jack Henry cores on the DMZ, as well as banks in Production.

On another tab in AcctHistSrch is the Loan Transaction Affects Codes document listing out all the codes for SilverLake. These are all the possible values of LNPAR3/LNAFFT and should give a better idea of which TranCodes could be considered 'payments'.

Each TranCode returned in the ParmValSrch record of the response has an Affects child that points out the Transaction Affects Code associated with the TranCode:

<ParmValSrchRec>
  <ParmValCode>10</ParmValCode>
  <ParmValDesc>Regular Payment with Computer Split</ParmValDesc>
  <ParmValInfoArray>
    <ParmValInfo>
      <ParmValDetail>L,O</ParmValDetail>
      <ParmValTxt>Account Type</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
    <ParmValInfo>
      <ParmValDetail>C</ParmValDetail>
      <ParmValTxt>Debit/Credit</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
    <ParmValInfo>
      <ParmValDetail>Q</ParmValDetail>
      <ParmValTxt>Affects</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
    <ParmValInfo>
      <ParmValDetail>Y</ParmValDetail>
      <ParmValTxt>Affects Next Pay Date</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
    <ParmValInfo>
      <ParmValDetail>Computer Split</ParmValDetail>
      <ParmValTxt>Affects Description</ParmValTxt>
      <Ver_1>
      </Ver_1>
    </ParmValInfo>
  </ParmValInfoArray>
  <Ver_1>
  </Ver_1>
</ParmValSrchRec>

In the example above, a TranCode of 10 is a loan payment with a Transaction Affect Code of ‘Q’, which represents a “Regular Payment – Computer Split”.

Q: How to retrieve bank routing #, check account #, check tran code using a AcctHistSrch. Also what would be the input parameter to limit check transactions in the AcctHistSrch?

A: Check tran code is going to be different for every FI. You would have to know what tran code that specific FI uses for checks. Routing # and account # would not appear in the response using AcctHistSrch. To search for only check transactions, the user would need to utilize ChkNumStart and ChkNumEnd.

Q: How do I know if the transaction should result in an increase or decrease? Is there any indicator in the response?

A: Please refer to the TrnType element, there are two possible responses that will provide the information you are seeking.

• D = Debit
• C = Credit

Q: IncXtendElemInfo – Can you please provide the entire list and description for this or is there a way I can retrieve it myself?

A: Please refer to the Enterprise Integration Portal, select IDG Products, jXchange Service Gateway, search for the operation you are interested in, Select the provider (i.e. SilverLake) then under the Message Briefs tab for that operation you will find information about any XtendElemInfo request/response that is related to that operation within the brief.

Q: The transactions we get back in the AcctHistSrch response don't seem to have a unique ID associated with them. Is it possible to get back unique IDs in that response or is there another web service method that we should be calling that has a unique ID for each transaction?

A: SeqNum is not unique to the provider’s history file; however it is unique for a given account number / account type. Passing the AcctId (account number) and AcctType (account type) in the AcctHistSrch request will return transaction history for that specific account. The response will include the assigned SeqNum value for a given transaction which would be unique to the account number / account type. An item to be aware of is an FI could potentially issue a memo post only record(s) to an account during a given business day. In this scenario, a SeqNum would not be assigned to the transaction until after the FI’s end-of-day (EOD) processing. The AcctHistSrch response will be returned; however the SeqNum element would be empty.

Q: If we only want to show transactions that will for sure post at EOD, what would you recommend we use from the response to only display those transactions? Is there a unique value that we can use to determine the difference?

A: Remember, everything memo posts that enters the system. But there is no way of knowing if something is going to post without doubt, there is always a chance that a memo posted transaction may not make it to processing and not actually hard post. Likewise, there is also no way to differentiate between a transaction that was memo posted versus ones that have been memo posted with MemoPostOnly = ‘Y’. This has all been confirmed by the Core Dev team.

My recommendation would be to simply present to the consumer all memo posted transactions (AcctHistSrch with MemoPostInc = ~Only~) as “Pending” since you do not know if they have posted until the next processing time.

Q: SilverLake and CIF 20/20 Is there a way to determine the type of grouping in all instances?

A: BatchNum would be the same for all transactions within the group. SeqNum would also be the same for all transactions within the group. And PostSeq would increment by 1 for each transaction in the group.

Q: SilverLake and CIF 20/20 For the postSeq, if there are two transactions within the same day, does the postSeq get reset to 1 for each batch or is the postSeq reset per day?

A: Batch PostSeq numbers get reset every day.

Q: I need clarification on the sort order of AcctHistSrch response. We’re seeing the transactions sorted in chronological descending order. I’d like to confirm if JX does a deterministic sort for the transactions.

A: SilverLake and CIF 20/20 If this is for deposits (AcctType= D, S, or X) and the SrtMthd has not been defined in the request, the program defaults to return records by TrDate, PstSq#, then Serial. The response set should use the LIFO (Last In FirstOut) method for date sensitive search requests thereby providing the consumer with the most recent activity specific to the search request.

Q: SilverLake and CIF 20/20 We would like to show the running balance for loan accounts. Does the JXchange interface provide a running/current balance with each transaction response from AcctHistSrch with MemoPostInc=true? We would like to see the current balance next to each transaction including memo posted transactions.

A: Yes, memo posted items for loans are reflected in the running balance, <TrnHistBalAmt>, in AcctHistSrch when MemoPostInc = true.

Q: SilverLake and CIF 20/20 In executing AcctHistSrch for both memo posted and hard posted transactions we are getting discrepancies with the values returned in the <TrnHistBalAmt> value.

• Some transactions in the past have the current days balance value in this field • The value of this field can change from day to day for the same transactions that occurred in the past.

How is the running balance calculated throughout the day?

A: <TrnHistBalAmt> looks like it only updates with transactions that affect Principle. The sort order and running balances should match what is being done in green screen when viewing account history. The default SrtMthd is PostDt, since it isn't defined on their requests. Also, the records are being returned in LIFO order, which is standard for Srch services.

Q: We are using AcctHistSrch service with the extended element x_EFTCardHistSrchRec to retrieve EFT Card Transactions. We could not identify the MOTO indicator field in this service.

Definition: MOTO has been around a long time (originally meant Mail Order / Telephone Order), but you don’t hear it very often any longer. In today’s world it’s really just any transaction where “card is not present”.

A: This seems to be determined by the PAN entry mode. PAN entry mode is returned in EFTCardCapType.

• Keyed
• MagRead
• BarCode
• OCR
• ChipRead
• Trak
• ElecMer
• CertMagRead
• UnCertChipRead

Q: When displaying transaction information, they are trying to order transactions correctly but the deposit accounts Posting Sequence is not populated but Loans it is. Can you help us determine why?

A: There is no PostSeq element in AcctHistSrch for Deposits (DDHISTSRCH). That's why it's not showing up for deposit accounts.

Q: SilverLake and CIF 20/20 We would like to pull deposit transactions that have an effective date of the current business date. We currently are using the AcctHistSrchRequest and are setting the StartDt and EndDt to the current business date. This appears to be giving us only transactions posted on the current date, but not transactions posted on a previous date with the current effective date.

What's the best way to get the transactions for the desired effective date?

A: There is not a way to search with the StrtDt/EndDt that reference the effective date for deposit accounts, as that is mapped directly to the posted date on the core side. Your best bet would likely be to expand the date range, then use the SrtMthd element value of “EffDt” to sort by effective date. This will use the “last in first out” sort method against the effective date.

Q: SilverLake and CIF 20/20 When testing the AcctHistSrch and we noticed that when we send the value of 0 for Cursor we get <TotRec> in the response, but any other integer value for Cursor the response does not have the <TotRec>. Is there a way of getting the TotRec element on all calls regardless of the value of Cursor in the request, or is the normal behavior that we get TotRec only when the value or Cursor in the request is 0?

A: This is the normal behavior.

Q: Why would the check number field <ChkNum>702200293</ChkNum> be populated with the confirmation number on a NetTeller transfer from savings to checking?

A: This is normal behavior. The field is not specifically for the check number, it is actually the reference/check number (the confirmation number is considered a reference number). The description of the transaction will indicate that it is related to a transfer.

Q: We are calling AcctHistSrch to get memo posted items, but the check number is blank. In order to get the check number for a memo posted item, am I correct in thinking that we need to call AcctMemoPostSrch when the AcctHistSrch has one or more items where MemoPost is a Y?

A: No, typically the image provider is the biggest variable in whether images are viewable prior to EOD.  If the image provider supplies the image number during memo posting then NT provides the ability to view the image, provided the image provider supports that.

Q: CIF 20/20 We have a customer that is trying to differentiate between transactions that are memo posted from their teller line versus memo posted from our kiosk/atm. They are using a TrnCode of 980 at the teller line and 981 for the kiosk posted transactions. When they look at the transactions for the day before EOD processing occurs they are both showing with a TrnCode of 980. My question is shouldn't a transaction with MemoPostOnly set to Y and a TrnCode of 981 show up in the transaction history with a transaction code of 981? We are talking about the time between the transaction and EOD processing.

A: We have tested and found similar behavior in our DMZ 2020 environment as well. It appears that 2020 assigns a temporary TrnsCode to memo posted items and then enters the true transaction code after EOD processing. The 980 and 981 that the bank uses appears to be an overlap with the default functionality of 2020. Our testing showed that when it is a Memo Debit, the TrnCodeCode is temporarily assigned 980 and when it is a Memo Credit the TrnCodeCode is temporarily assigned 920.

Q: Core Director When getting account transaction history is there a field that we can use to uniquely represent each record?

A: The field that was added to AcctHistSrch to uniquely identify records is HistRecId.

Q: We are attempting to call the AcctHistSrch operation with the extended element x_EFTCardHistSrchRec. The EFTCardHistSrchRec has not returned results. We've also attempted this call outside of the DMZ (client data) with similar findings. What steps are required to return EFTCardHistory when utilizing the AcctHistSrch operation?

A: For EFTCardHistSrchRec extended element to populate, It takes a very specific way of doing things at the bank level and the parameter must have certain values:

• The DDA transaction must have a source code of 'T'.
• The TranCodeCode associated with the DDA transaction must have an EFT type of 'ATM'.
• The bank must be a JHA CPS customer and have CPS present in their environment.

Q: What do the TrnStat values returned in the AcctHistSrch response represent?

A: Core Director The TrnStat element is not mapped in Core Director.

SilverLake and CIF 20/20 The TrnStat element returned in the AcctHistSrch response represents the “state or condition of a monetary transaction”. Possible values for SilverLake and CIF 20/20 are:

Deposit

• A = Active
• D=Delete
• L=List Post
• X=Reversal

Loan

• A=Active
• D=Delete
• F=Fee
• R=Reversal

Q: Is there a way to get the SEC Code and ACH Company ID for an ACH transaction returned through AcctHistSrch?

A: Yes, take a look at ACHTrnSrch. ACHTrnId (from ACHTrnSrch) and EFTTrnId (from AcctHistSrch) are related and can be reliably used for matching up ACH transactions to get the SEC Code (ACHStdEntryClass) and ACH Company Id (ACHCompId) values returned in the ACHTrnSrch response.