Developer Resources
Details
| SoapAction | http://jackhenry.com/ws/TrnAdd |
| Input Name | TrnAdd |
| Output Name | TrnAddResponse |
| Input Namespace | http://jackhenry.com/jxchange/TPG/2008 |
| Group Name | Transaction |
| Container | TPG_TransactionMaster.xsd |
Operation Summary
Transaction Add (TrnAdd) is a jXchange service designed to allow the consumer to create either a debit or credit to any standard account type supported by the provider. A consumer submits the account ID and type along with the complexes and simple elements containing values used to create the transaction.
- Transactions are not real time posted, they are memo posted until end of day processing occurs. For more information on this behavior see the Memo Posted Transactions page.
- When using the TrnAdd API the cores do not automatically create offsetting entries. It is recommended that a consumer of the TrnAdd API also review the Creating Balanced Transactions page.
- The TrnAdd API response will contain an
<RsStat>element indicating the result of the operation, with a value of Success when completed normally or the operation will return an HdrFault if the provider was unable to complete the request. - The TrnMod operation allows the modification or removal of a pending transaction. Posted transactions do not allow modification.
Special Considerations
- Only the TrnAdd operation allows a consumer to create a General Ledger transaction.
- If an Available Balance Calculation Code
<AvlBalCalcCode>is not passed in on the TrnAdd call, any debit or credit calculations/validations will be performed against the current balance rather than the available balance. - Banking Cores SilverLake and CIF 20/20 support the
<MemoPostHldOvr>element. The behavior is as follows.- When MemoPostHldOvr is set to true:
- The memo post record AND processing record will be written to core.
- During processing that night the memo post record will be cleared but then re-applied until the next processing run.
- The processing record will be fine and picked up during the next processing run.
- If the MemoPostHldOvr is set to false or not included in the request
- The memo post record AND processing record will be written to core.
- During processing that night the memo post record will be cleared but NOT re-applied.
- The processing record will be fine and picked up during the next processing run.
- When MemoPostHldOvr is set to true:
XML Examples
TrnAdd Deposit 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>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<TrnAdd
xmlns="http://jackhenry.com/jxchange/TPG/2008">
<MsgRqHdr>
<jXchangeHdr>
<JxVer/>
<AuditUsrId>Test</AuditUsrId>
<AuditWsId>Test</AuditWsId>
<AuthenUsrId/>
<ConsumerName/>
<ConsumerProd/>
<Ver_1/>
<jXLogTrackingId>9876543211</jXLogTrackingId>
<Ver_2/>
<InstRtId>011001276</InstRtId>
<InstEnv>TEST</InstEnv>
<Ver_3/>
<BusCorrelId/>
<Ver_4/>
<WorkflowCorrelId/>
<Ver_5/>
<ValidConsmName>VCN</ValidConsmName>
<ValidConsmProd>VCP</ValidConsmProd>
<Ver_6/>
</jXchangeHdr>
<Ver_1/>
<Ver_2/>
<Ver_3/>
</MsgRqHdr>
<ErrOvrRdInfoArray>
<ErrOvrRd>
<ErrCode/>
<Ver_1/>
</ErrOvrRd>
<ErrOvrRd>
<ErrCode/>
<Ver_1/>
</ErrOvrRd>
</ErrOvrRdInfoArray>
<AccountId
Rstr="">
<AcctId>471524</AcctId>
<AcctType>D</AcctType>
<Ver_1/>
</AccountId>
<TrnInfo>
<Amt>1.00</Amt>
<TrnCodeCode>9</TrnCodeCode>
<EffDt>2023-05-30</EffDt>
<Ver_1/>
<Ver_2/>
<Ver_3/>
<Ver_4/>
<Ver_5/>
</TrnInfo>
<Ver_1/>
<Ver_2/>
</TrnAdd>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
TrnAdd General Ledger 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>{{X-UserName}}</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">{{X-Password}}</wsse:Password>
<wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2024-02-12T14:54:39Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<TrnAdd xmlns="http://jackhenry.com/jxchange/TPG/2008">
<MsgRqHdr>
<jXchangeHdr>
<JxVer/>
<AuditUsrId>{{X-AuditUser}}</AuditUsrId>
<AuditWsId>{{X-AuditWorkStation}}</AuditWsId>
<AuthenUsrId/>
<ConsumerName>{{X-ConsumerName}}</ConsumerName>
<ConsumerProd>{{X-ConsumerProd}}</ConsumerProd>
<Ver_1/>
<jXLogTrackingId>55946e6d-cbe2-449d-8af2-180a57d80ce6</jXLogTrackingId>
<Ver_2/>
<InstRtId>011001276</InstRtId>
<InstEnv>TEST</InstEnv>
<Ver_3/>
<BusCorrelId>a7911f59-d7f8-4f2c-aa5c-2ad2bcf8bd53</BusCorrelId>
<Ver_4/>
<WorkflowCorrelId/>
<Ver_5/>
<ValidConsmName>{{X-ValidConsumerName}}</ValidConsmName>
<ValidConsmProd>{{X-ValidConsumerProduct}}</ValidConsmProd>
<Ver_6/>
</jXchangeHdr>
<Ver_1/>
<Ver_2/>
<Ver_3/>
</MsgRqHdr>
<AccountId>
<AcctId>1091</AcctId>
<AcctType>G</AcctType>
<Ver_1/>
</AccountId>
<TrnInfo>
<Amt>50</Amt>
<TrnCodeCode>20</TrnCodeCode>
<BrCode>1</BrCode>
<GLCostCtr>500</GLCostCtr>
<GLProdCode>100</GLProdCode>
<Ver_1/>
<Ver_2/>
<Ver_3/>
<EFTTrnId>6a7049fa-a1b1-480e-8929-6ed878f6a7fc</EFTTrnId>
<Ver_4/>
<Ver_5/>
<Ver_6/>
<Ver_7/>
</TrnInfo>
<Ver_1/>
<Ver_2/>
</TrnAdd>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
TrnAdd GLInterfaceCode 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"/>
</wsse:UsernameToken>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<TrnAdd xmlns="http://jackhenry.com/jxchange/TPG/2008">
<MsgRqHdr>
<jXchangeHdr>
<JxVer></JxVer>
<AuditUsrId></AuditUsrId>
<AuditWsId></AuditWsId>
<AuthenUsrId></AuthenUsrId>
<ConsumerName></ConsumerName>
<ConsumerProd></ConsumerProd>
<Ver_1/>
<jXLogTrackingId>{Insert}</jXLogTrackingId>
<Ver_2/>
<InstRtId>011001276</InstRtId>
<InstEnv>TEST</InstEnv>
<Ver_3/>
<BusCorrelId></BusCorrelId>
<Ver_4/>
<WorkflowCorrelId></WorkflowCorrelId>
<Ver_5/>
<ValidConsmName>{Insert}</ValidConsmName>
<ValidConsmProd>{Insert}</ValidConsmProd>
<Ver_6/>
</jXchangeHdr>
</MsgRqHdr>
<ErrOvrRdInfoArray>
<ErrOvrRd>
<ErrCode>300043</ErrCode>
<Ver_1/>
</ErrOvrRd>
</ErrOvrRdInfoArray>
<AccountId>
<AcctId>8003238</AcctId>
<AcctType>T</AcctType>
<Ver_1/>
</AccountId>
<TrnInfo>
<Amt>10000</Amt>
<TrnCodeCode>80</TrnCodeCode>
<EftType></EftType>
<EffDt>2021-03-03</EffDt>
<SrcCode></SrcCode>
<BatchNum>123</BatchNum>
<ChkNum>23</ChkNum>
<DrCr>C</DrCr>
<TrnDescArray>
<RmkInfo>
<Rmk>Time Deposit check test</Rmk>
<Ver_1/>
</RmkInfo>
</TrnDescArray>
<RefDescCode></RefDescCode>
<OffCode>BMS</OffCode>
<BrCode>1</BrCode>
<GLCostCtr></GLCostCtr>
<GLProdCode></GLProdCode>
<GLInterfaceCode>1090</GLInterfaceCode>
<RunNum>0</RunNum>
<RtNum>0</RtNum>
<FltSchedCode></FltSchedCode>
<FltDays>0</FltDays>
<ImgNum>122123123</ImgNum>
<MemoPostOnly></MemoPostOnly>
<SrcFundsCode>2</SrcFundsCode>
</TrnInfo>
<Custom></Custom>
<Ver_1/>
<AvlBalCalcCode>3</AvlBalCalcCode>
<Ver_2/>
</TrnAdd>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
TrnAdd LoanPayoff Request
<TrnAdd
xmlns="http://jackhenry.com/jxchange/TPG/2008">
<MsgRqHdr>
<jXchangeHdr>
<AuditUsrId></AuditUsrId>
<AuditWsId></AuditWsId>
<ConsumerName/>
<ConsumerProd/>
<Ver_1/>
<Ver_2/>
<Ver_3/>
<Ver_4/>
<Ver_5/>
<Ver_6/>
</jXchangeHdr>
<Ver_1/>
<Ver_2/>
<Ver_3/>
</MsgRqHdr>
<ErrOvrRdInfoArray>
<ErrOvrRd>
<ErrCode/>
<Ver_1/>
</ErrOvrRd>
</ErrOvrRdInfoArray>
<AccountId>
<AcctId>87980</AcctId>
<AcctType>L</AcctType>
<Ver_1/>
</AccountId>
<TrnInfo>
<Amt>5511.88</Amt>
<TrnCodeCode>28</TrnCodeCode>
<EffDt>2005-01-17</EffDt>
<BatchNum>1414</BatchNum>
<ChkNum/>
<DrCr/>
<TrnDescArray>
<RmkInfo>
<Rmk/>
<Ver_1/>
</RmkInfo>
</TrnDescArray>
<BrCode/>
<MemoPostOnly/>
<ColBalAmt>0.0</ColBalAmt>
<AvlBalAmt>0.0</AvlBalAmt>
<LdgrBalAmt>0.0</LdgrBalAmt>
<Ver_1/>
<Ver_2/>
<Ver_3/>
<Ver_4/>
<Ver_5/>
</TrnInfo>
<Custom
xsi:nil="true"/>
<Ver_1/>
<AvlBalCalcCode xsi:nil="true"/>
<Ver_2/>
</TrnAdd>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
FAQs
TrnAddFAQ-General
Question: How do I get the transactions codes?
Answer: You may use the ParmValSrch API to look up the transaction codes passing in the following:
SilverLake and CIF 2020
- All transaction codes: ParmName = TranCodeCode
Core Director
- Credit transaction codes: ParmName = TranCodeCode
- Debit transaction codes: ParmName = DrTrnCodeCode
Question: Let’s say a customer is at a bank and wants to deposit 500.00, but 400.00 of it is cash and the other 100.00 is a check. The 400.00 in cash should be immediately available. Does TrnAdd have to be called twice, once for the check deposit and once for the cash deposit? Or can TrnAdd can be called with Amt = 500.00 and AvlBalAmt = 400.00 to memo post the cash and make it immediately available?
Answer: If any of the transaction breakdown fields are used (Avl/Cur/Col), all of the breakdown fields must be populated for each to change the corresponding balance. If you wanted to reduce the Avl by 50.00, Cur by 100.00, and Col by 100.00 you would have to populated each portion with 50.00/100.00/100.00. If the breakdown section are all sent as zeros, then each is populated with the entire amount of the transaction.
Question: Attempting to execute a regular deposit transaction (TrnAdd) against one of the test accounts identified in the SilverLake-DDA tab of the DMZTestAccounts_SL_2020_CoreDirector spreadsheet. The request was modeled after the example on the site, except omitting optional override and remark nodes. The error message is “Account is not in a valid state to post transactions” in the response XML.
Answer: The account that you are testing is currently in a dormant state (AcctStat = 3) due to inactivity. Any attempts to post a transaction against it will result in an error. However, since it is categorized as a “Fault” and not an “Error” you can pass the error code into the ErrOvrRdInfoArray to override the error. Accounts with AcctStat=1 are active.
Question: Is there support for User Defined Fields (UDF)s, maybe via TrnDescArray/RmkInfo elements?
Answer: UDFs are not available for TrnAdd.
Question: Core Director What is usage of SvcPrvdInfo?
Answer: Core Director doesn’t do anything with SvcPrvdInfo.
Question: What are the minimum elements for a L type and D type transaction?
Answer: The minimum elements required on a TrnAdd request involving a loan (AcctType=L/O) or deposit (AcctType=D/S/X) account are as follows:
- AcctId
- AcctType
- Amt
- TrnCodeCode
Question: How can we send an amount with more than two decimal places? If we wanted to accomplish this, how could we do this? We are interested in crediting accrued interest, which is 5 decimal places in core.
Answer: The TrnAdd operation will not allow for more than two decimal places when debiting or crediting an account. There is no parameter that would control this, it is standard code within SilverLake.
It’s not possible. Accrued Interest is a calculated field in core, that’s why you’re seeing 5 decimal places. It then gets rounded to the nearest cent. TrnAdd doesn’t allow for the posting of fractions of a cent. It’s possible to credit accrued interest using TrnAdd, but it would only be possible up to 2 decimal places
Question: For a wire with Fees, we will send to TrnAdd request back to back, one for Principal amount and next for Fees debit. Is this the correct way or we need to use a different service for Fee Posting.
Answer: The fee and the principal amount can all be accomplished in one call with WireTrnAdd, there is a separate element for the fee (WireFeeAmt) and it won’t show on the account until the wire has been completed.
Question: I see that there is “Batch” number needed in some of these cases, where do I get the batch number from?
Answer: Batch number is just an arbitrary value that can be assigned to a transaction for tracking purposes. Since batch numbers can be used by institutions to identify groups or sets of transactions, they may assign a batch number for your use. We recommend adding this to your onboarding process. Oftentimes you’ll find that BatchNum will be unique to an individual bank employee.
Question: SilverLake Is the available balance adjusted in both accounts immediately with TrnAdd?
Answer: Yes, but an Available Balance Code <AvlBalCalcCode> must be passed in the TrnAdd/XferAdd call otherwise any debit or credit calculations/validations will be performed against the current balance and not reflected in the available balance.
Question: Core Director How does the AvlBalCalcCode work in Core Director?
Answer: It doesn’t since AvlBalCalcCode is not used in Core Director.
Question: Is the current balance adjusted immediately with TrnAdd?
Answer: No, it will be adjusted during End-Of-Day (EOD) processing.
Question: SilverLake We send two TrnAdd request to Jack Henry i.e. one for Demand Deposit ‘D’ account and another for General Ledger ‘G’ account. Now, when the user cancels the wire same day, eWire we send TrnMod requests to reverse the wire. When sending TrnMod request for ‘G’ account we got an error. Can’t a TrnMod be done on ‘G’?
Answer: TrnMod does not exist for AcctType=G so a separate TrnAdd needs to be run to reverse the initial transaction.
Question: SilverLake We are using TrnAdd for adding transaction and then TrnMod for reversing the transaction with <Dlt> tag true. Jack Henry will delete this transaction right away and then do not consider it during EOD hard posting process. No entry will be visible for this transaction on account statement?
Answer: Yes
Question: Is the EOD transaction file required to be sent?
- Core Director If they are adding the transactions via TrnAdd and are not setting them as memo post only, then these transactions get memo posted and stored in the ‘suspense’ file from which they will hard post during day end. If this is the case, these would not need to be sent to Core Director in a posting file.
- CIF 20/20 If they are wanting transactions to post to accounts, then they will need to send the transaction file to 20/20 so it can be included in processing.
Question: SilverLake Our team is trying to get a better understanding of how our SilverLake core handles the Reg D counter. It looks like the DR6 field in DDMAST is what we needed to increment the Reg D counter but isn’t available through jXchange. If this is the case, does SilverLake natively handle taking care of the Reg D counter when submitting transaction that fall into a Reg D (Savings or Money-Market) account?
Answer: The short answer is yes, SilverLake will take care of the Reg D counter. The longer answer is that the trancode is what determines whether Reg D is incremented on an account or not.
Question: SilverLake What happens to a TrnAdd posting to a specific Stop Payment record when there is a stop payment on a check?
Answer: From a core perspective having a Stop Payment record on an account, then running TrnAdd specific to that Stop Payment record will not result in an error or fault. It would result in a non-post during nightly processing.
Question: SilverLake Recently we added a new TranCode for specific use to trigger positive pay violation messages. This new TranCode is triggering another error message which states “Host Transaction code with and EFT description is required”. If the TrnInfo.TrnDescArray.RmkInfo.Rmk field is left out of the XML then the error does not appear. Is there a way to keep that XML field while not receiving the EFT description message?
Answer: TranCodes have attributes that determine the behavior of a transaction. Allowing a Rmk (EFT Description) is an attribute that is not available on all TranCodes. The error you are seeing has to do with how the TrnAdd business service deals with EFT Type TranCodes. The business service will only accept EFT descriptions for a transaction code that contains a value other than blank in the EFT Type Code of the transaction code parameter file. If the transaction code includes a value in that field and you do not pass in a remark, it will result in an “EFT transaction must have a description” error.
Conversely, if the transaction code does not include a value in that field and you pass in a remark, it will result in a “Transaction code with an EFT description is required” error.
You can check whether a trancode is configured to require an EFT remark or not by using the SvcDictSrch operation. For example, you might see the following being returned for a trancode:
<CanocValInfo>
<CanocValDetail></CanocValDetail>
<CanocValTxt>EFT Type Code</CanocValTxt>
<Ver_1></Ver_1>
</CanocValInfo>
Here EFT Type Code has a blank value, so if you try to pass in a remark you will get the “Transaction code with an EFT description is required” error.
In contrast, you might see the following being returned for a trancode:
<CanocValInfo>
<CanocValDetail>ATM Transaction</CanocValDetail>
<CanocValTxt>EFT Type Code</CanocValTxt>
<Ver_1></Ver_1>
</CanocValInfo>
Since EFT Type Code has a non-blank value, “ATM Transaction”, you must pass in a remark otherwise you will get the “EFT transaction must have a description” error.
Since you are getting the “Transaction code with an EFT description is required” error you would need to have the FI place a case with Silverlake Support to either modify EFT Type Code for the trancode in question, so you can pass in a remark, or setup a different trancode for you to use that allows remarks.
Question: Do you have any recommended way for us to detect if we’ve already posted a transaction, so that we don’t post a duplicate transaction in scenarios where we may be having issues such as intermittent network issues?
Answer: The best way to tell if a transaction went through successfully immediately after running the TrnAdd would be to perform an AcctMemoPostSrch call, which will look in the deposit memo post transaction file for transactions that will be processed with EOD.
Question: Core Director We seem to get error 1001. Do we need something in ConsumerName?
<ErrCode>1001</ErrCode>
<ErrCat>Error</ErrCat>
<ErrDesc>Vendor Record not defined in MNTJXC.</ErrDesc>
<ErrElem>TrnAdd.MsgRqHdr.jXchangeHdr.ConsumerName</ErrElem>
<ErrElemVal>JHA</ErrElemVal>
<ErrLoc>TrnAdd</ErrLoc>
Answer: Yes, for Core Director transactions (i.e. TrnAdd, XferAdd) the ConsumerName is required. Please check your Quick Start Guide for your correct ConsumerName, or reach out to Product Adoption for your assigned value.
Question: 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 tran code 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 tran code of 980. Shouldn’t a transaction with MemoPostOnly set to Y and a tran code of 981 show up in the transaction history with a tran code of 981? We are talking about the time between the transaction and EOD processing.
Answer: It appears that CIF 20/20 assigns a temporary trans code 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.
Question: Is the BatchNum element required?
Answer: If a consumer sends a TrnAdd operation without specifying a value for the BatchNum element, the core services will assign a default BatchNum value to the transaction. CIF 20/20 cores will default to a value of “0”, which will cause an error with the transaction, because the core checks to make sure the value is not zero or a negative number. The BatchNum element is not required based on the contracts, but in practice you will be required to provide a non-zero value for CIF 20/20 cores.
Question: Core Director What happens when we create a transaction with an Amt with more than 2 decimal places? Example 50.135.
Answer: The transaction will be created but the amount will be rounded up if the last decimal place >=5 and down if <=4. So in the example the amount of the transaction would be 50.14.
Question: When using the EffDt in the Trnadd request we are getting a 100060 - Effective date cannot be past posting date, or before last statement date . What does this error mean?
Answer: This means that the posting date for the core is less than the effective date you are trying to use. The processing date can be retrieved from the FinIstInfoInq and can be found in the NxtProcDt .
OR
The date last statement on the account you are using is greater than the EfftDt trying to be used. The LastStmtDt can be found on an AcctInq request.
TrnAddFAQ-GeneralLedger
Question: Is it possible to get rid of handwritten GL tickets?
Answer: TrnAdd would need to be run multiple times to credit/debit the different GL accounts. You just need to make sure that the batch is balanced after making these calls, or in other words the debit(s) from the account(s) has to equal the amount of money being credited to the other account(s).
Question: For a transaction against a D account, for example, accountID and accountType are enough to identify the account. In order to transact against a GL account using TrnAdd, what info does the TrnAdd operation require to properly identify the target GL account?
Answer: The minimum required to post a successful TrnAdd to a GL account is:
- AcctID
- AcctType
- Amt
- TrnCodeCode
- BrCode
Question: If I want to reduce the balance in the AccountId.AcctId account, and increase the balance in the GL account, should that be a “D” or “C”?
Answer: The DrCr field is only used when adding memo posts. If trancode <TranCodeCode> is blank the business service will look at the DrCr field and set it to a specific trancode depending on if it is D or C. Otherwise, if you pass a trancode it runs off the trancode ONLY and ignores the DrCr element.
Question: SilverLake We are using TrnAdd to fund a new CD (TimeDep) account, then debit Cash Clearing, and then crediting the settlement account. We found an issue where the batch numbers are not matching. We are passing a value of 100 and the response has an RsStat of “Success” but returning a <BatchNum> of 907. Why would it not be accepting the value we are sending for the TrnAdd request?
Answer: For GL Transactions, FIs have the option to not map the Batch number. If it’s not mapped the SilverLake provider service defaults to batch 907 for all GL transactions from jXchange. You may also receive error 100395 “Batch Number for Source Code JX must default to 907” if you provide a batch number. If the FI would like to use batch numbers, update the jX source in GLPAR option 6 to either Extend or Override and include their batch #.
Question: SilverLake If we use TrnAdd to reverse transactions since GL accounts don’t use TrnMod, should we use only TrnAdd for reversals for all types of accounts?
Answer: Yes. You may, though to cut down on confusion for the customer we recommend using TrnMod with the <Dlt> flag for reversing items that are not hard posted at end of day when no GL.
Question: Core Director We are going to test sending up the GLInterfaceCode value in TrnAdd for Core Director. Do you have a valid value for GLInterfaceCode?
Answer: 111805
Question: If we use the TrnAdd.TrnInfo.GLInterfaceCode field for the GL account? Do we still need to perform two transactions (Debit/Credit)?
Answer: No, normally using TrnAdd you need both. But when you are using the GLInterfaceCode for the GL account you only need one. You can look at the example in the XML GLInterfaceCode Request above.
Question: Can we use a specific GL Account, in the format 090-280300-0000 for the GLInterfaceCode?
Answer: The TrnAdd request element GLInterfaceCode must be a valid GL interface code not a GL Account number. GLInterfaceCode only allows valid GL interface codes to be populated and must have specific source code that coincides with the GL Interface Code for Faster Payments, Clearing House Payments and Third Party Payments in the request element SrcCode. When submitting in the GLInterfaceCode and SrcCode combination it allows the system to know to create the GL entries.
Question: CIF 20/20 Where can I find a list of TranCodes to use for performing GL transactions?
Answer: There are no GL TranCodes in CIF 20/20, to perform a GL transaction in CIF 20/20 you need to omit the TranCode, TrnCodeCode, and instead pass in TrnInfo.DrCr to indicate whether the transaction is a debit (Dr) or a credit (Cr) to the GL account.
TrnAddFAQ-MemoPostOnly
Question: We have a vendor who is performing a check deposit by calling TrnAdd with the MemoPostOnly flag set to ‘Y’. They are not passing in a ChkNum on the request. Later on when they call AcctHistSrch on that account with MemoPostInc = ONLY they see the transaction record and it contains ChkNum = 0.
Answer: Yes that is all correct. when MemoPostInc is set to ONLY on AcctHistSrch, that call is re-routed to call AcctMemoPostSrch and if the ChkNum element wasn’t populated on the initial TrnAdd request then it won’t show as populated in AcctMemoPostSrch.
Question: My understanding is that unless they explicitly pass in a ChkNum on the TrnAdd, the ChkNum will not show up as part of the memo posted record in history. If they had NOT done the TrnAdd with the MemoPostOnly flag set to ‘Y’, then when the transaction goes through item processing, 4Sight will pick it up, scan the check and set ChkNum to the actual check number so that it shows up history?
Answer: While I have limited knowledge of 4Sight, my assumption is that yes it will pick up the check number once it is scanned.
Question: Is running without the MemoPostOnly flag the same thing as not memo posting the transactions at all?
Answer: In SilverLake and CIF 20/20 all transactions are memo-posted as they enter the system. If the MemoPostOnly flag is set to ‘Y’ on a TrnAdd call, the transaction will get cleared during nightly processing and not post. Otherwise, if MemoPostOnly is set to ‘N’ or simply omitted, the transaction will hard post during nightly processing. With that said, if transactions are real-time posting instead of memo posting, the SilverLake and CIF 20/20 customer in question may have a Real Time Posting (RTP) enhancement enabled which is an additional charge.
Question: Do you have to have an amount when doing a MemoPostOnly?
Answer: CIF 20/20 <amt> can be zero. For Core Director and SilverLake <amt> does need a value above zero.
Question: My response of memo post does not contain the sequence number. If I do not set MemoPostOnly, response always has the sequence number. What’s up?
Answer: The sequence number for the memo posted items will go away when the transaction is hard posted during processing. A new sequence will be assigned during nightly processing. It will have a unique batch and sequence number when you see the transaction in the next day’s posting when you do a AcctHistSrch.
Question: CIF 20/20 We are seeing a discrepancy with use of the <Rmk> tag with CIF 20/20 when performing a TrnAdd (memopost). We use this tag with Core Director and have no issue but I am getting reports the same operation it not working with CIF 20/20. Is there a missing functionality between the two core systems?
Answer: In CIF 20/20, when MemoPostOnly=Y, the record gets created in the DDMEMA core file which doesn’t have any fields for remarks. If MemoPostOnly=N then the record gets created in the DDTRAN file which has the first 2 remark fields, and if the test utilizes 3 or 4 remark arrays, those extra remark fields can be found in the TRNEXTD file.
Question: SilverLake and CIF 20/20 Is there a way to not show the memopost and just hard post on a TrnAdd? If so how?
Answer: No, all transactions run thru TrnAdd are memo-posted and become hard-posted after EOD processing.
Question: How do I modify or reverse a transaction that was passed in with the MemoPostOnly = true attribute?
Answer: There are different behaviors depending on the core:
- SilverLake and CIF 20/20 do not provide a TrnRcptId or SeqNum with transactions where the MemoPostOnly = true attribute is utilized. To modify or remove the transaction a user would need to pass in an opposite transaction using the MemoPostOnly = true attribute (i.e. If original transaction was a credit, the second transaction would need to be a debit of the same amount).
- Core Director provides a SeqNum with transactions when MemoPostOnly = true. Thus the TrnMod operation may be used with the SeqNum to remove or modify the MemoPostOnly = true transaction.
Question: When doing a MemoPostOnly for Core Director a description can be added in TrnInfo.TrnDescArray.RmkInfo.Rmk element. Does SilverLake and CIF 20/20 have a description field for MemoPostOnly?
Answer: No.