Troubleshooting FAQ

General Topics

Why am I unable to see my SYM when I restart SymXchange in symop?

Internal SYM-level services are not running on your SYM.

Select option (25) Restart Internal Sym Level Services in symop for your SYM to restart the services.

When I restart Parameter Server, why is my SYM not allowed to restart?

You need to add your SYM number to the /SYM/CONFIGURE/PARAMETERSERVICE.CFG file.

# PARAMETERSERVICE.CFG
#
#This file specifies the SYMs that are configured to run the Parameter 
#Service. A single three digit SYM number should be listed per line.
#
#SYM
#123

Once you add your SYM to the file, you will be able to restart Parameter Server for your SYM.

Why am I receiving an error when I start System Web Console through https://<servername>?

If you receive the This webpage is not available ERR_CONNECTION_REFUSED error message, System Web Console is not running and needs to be restarted.

Use the $ USERS WEBCONSOLE.EXE command to verify that the System Web Console process is running.

If System Web Console is running, you will see the System Web Console process similar to the following:

symitar 28377400 31523182 0 Nov 24 - 29:37 /SYM/SYMPR/WEBCONSOLE.EXE -system

If it is not running, select RESTART option (*) Restart Web Console in symop to restart.

When I start System Web Console using a browser, why is my SYM not listed in SymXchange Web Services?

Confirm that your SYM number is added to the /SYM/CONFIGURE/PARAMETERSERVICE.CFG file.

You should see your SYM listed:

# PARAMETERSERVICE.CFG
#
#This file specifies the SYMs that are configured to run the Parameter 
#Service. A single three digit SYM number should be listed per line.
#
#SYM
#123

Confirm that the Parameter Server for your SYM is running using this command: ps –ef | grep SYMxxx (where xxx is your SYM number).

If it is running, you will see the Parameter Server process similar to the following:

root 17760960 33554544 0 13:42:44 pts/68 0:00 /SYM/SYMPR/symitarParametersDB -sym=SYMxxx

If it is not running, select RESTART option (*) Restart Parameter Server in symop to restart.

Your SYM should now appear in System Web Console.

When I select SymXchange in Device Control, why can’t I see my SymXchange instances?

Confirm that you have an instance created in System Web Console.

If the instance exists in System Web Console, confirm that the Parameter Server for your SYM is running using this command: ps –ef | grep SYMxxx (where xxx is your SYM number).

If it is running, you will see the Parameter Server process similar to the following:

root 17760960 33554544 0 13:42:44 pts/68 0:00 /SYM/SYMPR/symitarParametersDB -sym=SYMxxx

If it is not running, select RESTART option (*) Restart Parameter Server in symop to restart.

Your SymXchange instances should now appear in Device Control.

When I select SymXchange Client Parameters in the Parameter Manager work area, why does it say the Parameter Service is not active?

The Parameter Server of your SYM may not be running.

Confirm the Parameter Server for your SYM is running using this command: ps –ef | grep SYMxxx (where xxx is your SYM number).

If it is running, you will see the Parameter Server process similar to the following:

root 17760960 33554544 0 13:42:44 pts/68 0:00 /SYM/SYMPR/symitarParametersDB -sym=SYMxxx

If it is not running, select RESTART option (*) Restart Parameter Server in symop to restart.

When I select SymXchange in Device Control, why do my SymXchange instances appear in red with a missing status?

If your instances have the No such file or directory status, the SymXchange instance has not been started.

Select RESTART option (*) Restart SymXchange in symop to restart your SymXchange instances.

When I run a SymXchange operation, why does it say SymXchange is not on host?

If you are receiving the SymXchange is not on host error, use Device Control to bring SymXchange on host.

When I restart SymXchange, why does it say SymXchange couldn’t start and a timeout occurred?

SymXchange took longer than expected to start all the services. If this error is persistent, you should notify the SymXchange support team.

When I run a SymXchange operation, why does it say the service is not available?

Please enable the service you are trying to run in System Web Console. You also need to restart Parameter Server and SymXchange.

When I run a SymXchange operation, why does it say the operation is not allowed for the credential type and device information provided?

You enabled the service you are trying to run, but you also need to enable the operation.

Navigate to the SymXchange Parameters in Parameter Manager. Select the service and then enable the operation for the credentials you are trying to use. Make sure to save your changes.

After you are enable the operation, use Device Control to refresh the SymXchange instance.

When I run a SymXchange operation, why am I receiving a soap fault exception?

There are many reasons why a soap fault exception may occur.

This exception includes a Detail field that has an ErrorCode field and, in some cases, a ProposedSolution field too. If the proposed solution exists, please follow the steps mentioned in the ProposedSolution field. If there is no ProposedSolution field and you cannot figure out what went wrong from the faultstring, contact Support with all the information you have.

A sample soap fault response appears as follows:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:Client</faultcode>
         <faultstring>[MessageId=Test] The argument DeviceNumber in your request was not 
         initialized correctly.</faultstring>
         <detail>
             <ErrorCode>1.17</ErrorCode>
            <ProposedSolution>Please be sure to set this argument correctly and try the process 
            again.</ProposedSolution>
         </detail>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

How do I install Enhanced Loan Application (ELA)?

ELA functionality is not available for Fintechs. If a Fintech would like to utilize ELA, it is best to work with a Credit Union who has purchased this solution. There are many versions of ELA being used by clients because ELA is so highly customizable. “Enhanced Loan Application (ELA), Enhanced Member Application (EMA), or Enhanced Account Revision (EAR) in the production SYM using Symitar PowerFrame Docs.”

When should a Clearing Code be used, when should a Check Disbursed code be used and when should an external code be used? What is the thought process for the respective account fields?

Use the following logic, if the funds are check use CheckDisbursedCode or CheckDisbursedAccount, cash use ClearingCode or ClearingAccount. Use the ExternalCode or ExternalAccount when dealing with External loans or tracking records. Only send one GL code or account, do not send both in the same request.

Why is a transfer failing with a “13027 - No Transaction Access” error between two accounts with the preference record setup to allow such transfers?

Credentials that use the preference record may are not being used, such as the Account number or Home Banking credentials. Admin or User credentials could also be used to bypass the access records completely.

For more information, please reference the section under Error Codes. error 13032 - This service is not available.

Does getDocumentNumber give the last used check number or the next available check number and does a call need to be made to update that number using updateDocumentNumberByID after getting the DocumentNumber?

The getDocumentNumber does return a check number that is ready to be used. Make sure to send a call with updateDocumentNumberbyID to increment that number so the next time getDocumentNumber is called it is a valid number that hasn’t been used.

The system can also calculate the check when a transaction is performed. The following functions in the transactions service can create checks when called:

• Withdraw
• glToGlPost
• newLoan
• loanAddOn
• deposit
• payLoan

In those calls a check number can be specified or the system can calculate the check number if a printer is assigned; a document number is setup.

What is the go live process for SymXchange integration?

There is currently no certification process for SymXchange integrations but that will be changing in the next couple of months. Once the application is ready, the Fintech will complete a SymXchange Blueprint document to provide to the Credit Union or the Symitar SymXchange team if the Credit Union is a Symitar Hosted client. This document will allow the Credit Union or the SymXchange team be able to create the Symxchange instance for the Fintech application to consume.

Click to download the SymXchange Blueprint document.

What are the endpoint details to retrieve the primary name and address related to a MICR account?

The findByMICR call in the findBy service should be used. It will return an account number, share or loan type, and share or loan ID. That information would then be used in an Account service call, getAccountSelectFieldsFilterChildren. With that, all of the Name, ShareName, and LoanName records can be retrieved and that is where the address information resides.

The primary name would be in the Name record, NameSelectableFields section with the Type field returning the value of Zero (0) which is the primary name record on the account.

When retrieving a response, why is data not being returned?

SymXchange does not return blank fields. Please confirm that data exists for that field within that Account or Share record.

Can I reset the SymXchange Vendor SharePoint password?

The Vendor SharePoint password reset functionality is not working correctly and using it could compromise the current password. If a password needs to be reset, please send an email Developer Relations. Passwords expire every 90 days. Remember to set up reminders to sign-in to prevent the password from expiring.

Where can I find newer Symitar Quest versions?

The Symitar Quest software and each version update is posted on the Vendor SharePoint. A message may occur when launching Symitar Quest that a newer version is required. Access the Vendor SharePoint and download the updated version of Symitar Quest.

Does the findByLookup return one account or multiple?

The findByLookup API only returns a single account.

How do I to fix the error message attempting to login to the Symitar VIP Host: “Logins not allowed from host: [Host name of local workstation]”?

The local workstation hostname must be added to the Symitar Host configuration file for access to be allowed. Once the local hostname has been added to the Symitar Host, the user will be able to sign onto the Symitar Host.

Adjust the Logging Level

How to change the amount of data that is retained in the SymXchange logs and the type of retention, using a symXchange.log4j.xml file.

1. Log in as root.
2. Change directory to /SYM/SYMXXX.
3. Execute the jar xf command to export the symXchange.log4j.xml file.
4. Modify the file to set the desired logging levels and sizes (and remove control characters).
5. Execute SYMACLSETALL SYMXXX.
6. RESTART SymXchange from symop for the change to take effect.

Default logging will show the entire message if the processing time exceeds the threshold set on the web console (normally 1000 ms) or if there is an error in the response.

The DEBUG level will log the entire message for all the messages of the desired types (poweron, crud, transaction, and other logs).

The amount of data that is retained varies significantly with different interfaces, so determine how much data to retain (number of back-up files, and size of each file.)

To create the symXchange.log4j2.xml file, complete the following steps:

1. Log in as root on the server.

​​$ sym root

Enter ROOTACCESS password

2. Change directory to the SYM where the SymXchange logging level is to be changed.

For example: 

# cd /SYM/SYM000

3. Execute the jar xf command to unzip a copy of the symxchange log4j2 file.

# ​jar xf /SYM/SYMJAVA/com.symitar.symXChange.jar symXchange.log4j2.xml

# jar xf /SYM/SYMJAVA/com.symitar.symXchange.jar symXchangeInstances.log4j2.xml

4. Using vi, edit the file to set the logging attributed desired. Note: When the file is unpacked the Control Characters that were added will need to be removed.

# vi symXchange.log4j2.xml

To remove Control Characters once inside vi (in ESC mode), type:

:%s/^M//g

Note: To enter ^M, type CTRL-V + M. That is, hold down the CTRL key, then press V and M in succession.

5. Execute SYMACLSETALL SYMXXX to set permissions on the new file.

# SYMACLSETALL SYMXXX (where XXX is your SYM number)

6. RESTART your SymXchange instance from symop.

# symop

Password: 0.<ROOTACCESS>

> RESTART

Once the logging changes have been made, the symXchange.log4j2.xml file may be removed because it will stay forever (including after release loads) and the new logging levels will be set for each instance on their next restart. Then, if the format of the logging changes with a release load, the outdated symXchange.log4j.xml file can impact the logging with the new release.

There is no way to set the log4j file for an individual instance – any instances for the sym in question will get the updated logging values when the instance is restarted. However, if the log4j file was set up, restart the desired instance, and then move the log4j file, only the one instance will have the modified log settings.

Most of the symXchange log files are specific to a particular sym, and the controlling symXchange.log4j.xml file will be placed in the /SYM/SYMXXX directory. To change the log location of the symXchange.SYSTEM.log file, copy the symXchange.log4j.xml file to the /SYM/ONHOST directory.

Buffer size parameter:

• Unless the application produces log events quite fast, there is no reason to change the value.

Property Value

The size of the cyclic buffer used to hold the logging events.

The BufferSize option takes a positive integer representing the maximum number of logging events to collect in a cyclic buffer. When the BufferSize is reached, oldest events are deleted as new events are added to the buffer. By default the size of the cyclic buffer is 512 events.

If the BufferSize is set to a value less than or equal to 1 then no buffering will occur. The logging event will be delivered synchronously (depending on the Lossy and Evaluator properties). Otherwise the event will be buffered.

Check Printing

SymXchange uses the SymConnect client numbers 0-19 in the check source list.

There are three parts to setting up the SymXchange instance in relation to check issuance. For example, after confirming SymConnect client 19 is not being used, client number 19 would be configured as follows:

1. In Web Console set the instance client number to 19.
2. In the sym/ SymXchange parameters choose SymXchange client number 19 for that instance.
3. In the sym/ SymConnect client specific parameters choose SymConnect client number 19 and change the client system name which will reflect in the check source list.

Also, using SymXchange client numbers above 19 have been known to cause issues in general.

This only affects checks that are being printed through Check Manager, not if they are being sent directly to a printer by SymXchange. So, if you have a kiosk or ITM printing checks it will use the Check Printer setup in the SymXchange Client Parameter.

If checks are not immediately printed and someone in the back office issues them, this is where the problem comes to light.

Check Withdrawal through SymXchange Cannot Be Reversed

A withdrawal that was completed through SymXchange that issues a check cannot be reversed.

​The workaround is to reverse the withdrawal; A deposit would need to be performed.

Clearing SymConnect-SymXchange Totals

1. Take SymConnect Offhost
   • Navigate > Information Systems > Device Control
   • Click the dropdown arrow on the Device field
   • Select SymConnect or SymXchange
   • Click the icon with the finger pressing the red button. SymConnect/SymXchange is now Offhost.
2. Clear SymConnect Totals
   • Click the icon with the trashcan and piece of paper.
   • Select the SymConnect/SymXchange clients. Choose between all SymConnect/SymXchange clients or a specific client.
   • Click OK. Totals have just been cleared. The SymConenct/SymXchange posting Journal’s third section, which is a summary of SymConnect/SymXchange activity since the last time totals have been cleared which in turn is usually a month, will be all zeroes.
3. Bring SymConnect Onhost
   • Click the icon with the finger pressing the green button. SymConnect/SymConnect is now Onhost.​

SymConnect Totals can be cleared in either of the two following manners.

1. From the Episys Windows Interface (one time):

   • Select the Device Control icon from the tool bar or select Navigate > Information Systems > Device Control
   • Take SymConnect off host by clicking the Off Host Button
   • Clear SymConnect by clicking the trashcan/paper icon (two icons to the right of the off host button)
   • Select (0) to clear totals for All SymConnect Clients, or select each SymConnect client individually
   • Place SymConnect back on host by clicking the On Host Button

2. From Batch Control (create job file):

   • Select the Batch Control icon from the tool bar or select Navigate > Information Systems > Batch Control
   • Select the Job Wizard icon to begin creating the Clear SymConnect Totals job file.
   • At the Job File Wizard dialog box, select Create a new job file. Click the Next button to proceed.
   • At the Job File Type dialog box, select Answers for a batch program. Click the Next button to proceed.
   • At the New Job File Name dialog, for example, enter CLEARSYCTOTALS. Click the Next button to proceed.
   • At the Job Run Dates dialog box, click the Next button to proceed.
   • Select Batch Host Control from the list of programs and click the Next button to proceed.
   • At the Next Event prompt, select Take SymConnect Off Host. Click the Next button to proceed.
   • At the Next Event prompt, select Clear SymConnect Totals. Click the Next button to proceed.
   • At the Next Event prompt, select Bring SymConnect On Host. Click the Next button to proceed.
   • At the Next Event prompt, click the Next button to proceed.
   • At the Placing batch program answers in job file CLEARSYCTOTALS, click the Finish button.

NOTE: Click the Back button to return to the previous screen at any time.

Excessive Cash Report

The Currency Transaction Report (CTR) Processing Batch Program and Cash reports only looks for cash transactions in certain System Defined GL Codes.

• SymConnect: System Defined GL Codes 56
• SymXchange: System Defined GL Codes 98

This issue has been brought up by several other clients and Product Development is aware that changes are needed.

In the interim, If these transactions are to be reflected in these system reports, make sure all cash transactions performed through SymConnect and SymXchange use these GL Codes.

To achieve this, set the GL Code field in the SymConnect/SymXchange Client Specific Parameter to 0 and make sure vendors are not passing a GL Code in the transaction request.  Also make sure that the right GL Account(s) translated in the GL Translation table for System Defined GL Code 56 or 98.

Using the System Defined GL codes is very limiting as to how these transactions can be translated.  Translation cannot occur by user number or leverage GL account branch accounts.

An alternative to using the System Defined GL codes would be to use a PowerOn specfile to supplement the cash reporting.  You can use RB.CORP.INTRADAYGLBALANCE as an example.

In 2022.01 a new Miscellaneous Parameter was added to provide more flexibility for which GL codes can be used.

Support User-Defined GL Codes for CTR and Excessive Cash Reporting

The Cash Reporting User-Defined GL Codes Miscellaneous Parameter was created to allow credit unions to add user-defined GL codes for certain cash handling devices, such as NEXT kiosks, to the list of GLs that are currently used for CTR processing, CTR reporting, and excessive cash reporting.

The Cash Reporting User-Defined GL Codes section in Miscellaneous Parameters contains the Cash Reporting User-Defined GL Codes parameter which lists GL codes for cash transactions that do not post to the system-defined GLs. Additionally, it contains the Add GL Codes for Cash Rpt and Remove GL Codes for Cash Rpt parameters which are used to add GL codes to, or remove them from, the list. The Cash Reporting User-Defined GL Codes parameter defaults to NONE until GL codes have been added.

Both the CTR Processing batch program and the Close Day Processing batch program for the Excessive Cash Report will include the user-defined GL codes listed in the new Cash Reporting User-Defined GL Codes section of Miscellaneous Parameters.

GL codes entered in this parameter should be defined in the GL Translation Table Parameters and should only be used for cash transactions. This parameter, the CTR Processing batch program, and the Close Day Processing batch program will not validate that the GL code has been defined or translated.

The origin assigned to a user-defined GL code for transactions not performed via Teller Transactions (not including via ATM, Point of Sale, Miscellaneous Posting, Shared Branching, SymConnect, or SymXchange) is GLU: General Ledger User-defined code. Affected reports include:

• CTR Transaction Detail – Incomplete
• CTR Transaction Detail – Exempt
• Excessive Cash: Amounts over $10,000

A PowerOn cannot be used to perform file maintenance on this parameter, but it can be used to read the information for generating reports.

Find Account Logic (MICR Edit)

If a SymConnect or SymXchange interface is going to use MICR credentials (SymXchange) or a MICR message (SymConnect), there MUST be a SYCPOST MICR edit with the appropriate logic for the message to successfully process. That includes the cases where the only MICR format in use is the MICR number in the MICR Account Number field in the share/loan record. The edit is also used by the findByMICR SymXchange call, and for check verification in the transaction service. 

For iPay - these implementations MUST have a MICR edit coded for them.  

Most Credit Unions have used a number of MICR number formats over the years, and should be asked what specific logic to include in the SYCPOST MICR edit. (Some of the formats used in the past may be obsolete.) For credit unions that use NetTeller for their home banking interface, the Credit Unions should be specifically asked to verify if the MICR formats in the JHADRIVER.INFO file should be included in the SYCPOST MICR edit. The edit should be coded to reflect all valid MICR formats the CU has, not just those that are used by the vendor for the “current” case.  

All the MICR formats should be tested prior to going live - we typically don’t do this testing ourselves, so our involvement here would usually be limited to requesting that the Credit Union/vendor do so. Note that leading 0s matter for MICR numbers - 01000 and 1000 are not equivalent MICR numbers; it is a good idea to mention this to the Credit Union/vendor, so that they can adjust the logic they provide for the SYCPOST MICR edit if necessary, and so that they can test accordingly.  

If implementing a change to the MICR edit once an iPay interface is live, it is wise to test the updated logic prior to the next set of transactions (which start at 0800 and 1500 Eastern). This logic can be tested using SYCNETTEST and a MICR message - preferably in a test sym, and IQs only if testing in the live sym. For a SymXchange implementation, use SYCNETTEST to test the account-finding MICR logic, because SymXchange and SymConnect use the same code for this function.

Home Banking-Online Banking down

Home Banking/Online Banking down. SymConnect Port logs showing “The password has expired and must be changed”.

For both SymConnect and SymXchange, the issue is typically encountered by newly migrated/converted client to EASE.​

1. Check all the Ports assigned for the Vendor and confirm that each request using the home banking username/password is encountering the issue.
2. Login to the Client’s SYM and go to Parameter Manager > Miscellaneous Parameter
3. Go to the HB User Name/Password Control area and check the HB Password Max Age.
4. Get a sample Account Number and check the Preference Record > Home Banking Information > Last HB Password Change.
5. Compare the date when the HB Password was last changed vs the days assigned for the HB Password Max Age. Check a couple more Accounts to confirm if they all have the same last HB Password Change.
6. If the HB Password Max Age and the last HB Password Change are the same, that is the issue.
7. Advise Client to update the HB Password Max Age to 0 so it will not be restricted or update to more than 90 days (default value). Value for this fields is up to the Client’s discretion thus it is up to them to decide.
8. Changes to the Miscellaneous Parameter is real time. No need for any restarts.

HTTP Anonymous

403 Error

Error:
System.AggregateException: One or more errors occurred.

(The HTTP request was forbidden with client authentication scheme ‘Anonymous’.)

Check the connection details and verify:

• Device type
• Device number
• Admin password
• Service not enabled
• public IPs/WL IPs

Leading Zeros in Audio Access Code

Leading 0s will be counted only if the PIN is 4 digits long, as 4 is the minimum accepted by Symitar for a PIN number.

If you have any number longer than 4 digits, leading 0s will be ignored.

Maximum Number of Records That Can Be Returned

NumberOfRecordsToReturn is the maximum number of records which can be returned in a SymXchange response.

Currently, it is restricted by the “Maximum Search Response List Count” parameter set in the SymXchange Instance Details page of WebConsole. The maximum value is 10000.

Example:

NumberOfRecordsToReturn control in getShareTransactionPagedListSelectFields?

<PagingRequestContext>
<!--Optional:-->
<NumberOfRecordsToReturn>?</NumberOfRecordsToReturn>
<!--Optional:-->

Maximum Number of SymXchange Instances

As of 02/14/2024, the maximum number of SymXchange instances that can be created per sym is 24.

Memo Mode - Holds - Available funds

The funds available to a Share while in memo mode have the following behavior:

• Funds available to a Share starts with the Share Available Balance on the Share in the Memo SYM (divert SYM if memo is diverted).
• Deposits and withdrawals (financial transactions) do affect the funds available for that Share while in memo mode.
• If the SymConnect or SymXchange parameter Hold Days for Cash Dep/Pmts and Grace Amount for Cash Dep/Pmts are set and a hold is created as a result, the hold amount is used to reduce the funds available for that Share while in memo mode.
• If a Hold is created by a File Maintenance request (SymConnect FM request or SymXchange createHold request) the hold amount is NOT used to reduce the funds available to that Share while in memo mode.
• When memo mode is exited and posted, all holds are considered when calculating the funds available to that Share.

Modifying Statement Generation Descriptions

Select the Transaction Source code in SymConnect/SymXchange Client Parameters

• (H) Home Banking
• (A) ATM
• (T) Telephone (Audio Response)
• (S) Kiosk
• (0-9) User-Defined Source Codes

Statement Generation

The new Transaction Source Code Descriptions must be defined in the Statement Generation batch prompts. If they are not pre-defined, the source description of the transaction will not be displayed in transaction history and on standard notices. This does not mean the statements must be produced, just that the description for the new Transaction Source Codes should be defined.

1. Log on to the live SYM to set the Statement Generation Transaction Source Code Descriptions.

2. Click the Batch Control icon on the toolbar or go to Navigate > Information Systems > Batch Control.

3. From the Program drop-down menu, select Statement Generation.

4. At the Modify Statement Parameters prompt, select Yes and click the Next button.

5. Click through the prompts. After reaching the Modify Statement Descriptions prompt, select Yes and click the Next button.

6. Click through the prompts. After reaching the Transaction Code Statement Description prompt, enter the specific description associated with the Transaction Source Codes. If no description is to be added, leave the description field blank.

7. Click OK to save the changes.

Multiple Accounts with the Same Lookup

Multiple accounts can have the same lookup number in them. A warning is displayed when the second lookup is created, but the system will allow it to be created.

In Quest, when using Lookup to find the account, the system will display both account numbers that contain the lookup with that number. 

In SymXchange, using the findByLookup WSDL, the response only provides one of the account numbers. This is intentional - modeled on how SymConnect works, not Quest.

ODT Override Setting

Several Credit Unions are excluding the Source Code of B (Bill Pay) for Overdraft Tolerance over the ATM and Shared Branching networks.  Since iPay also uses the Source Code of B in their SymXchange requests, this is blocking Overdraft Tolerance from being used with iPay.

If the client wishes to allow iPay to override the opted out source code setting in the share, the client can use the ODT Auth/Fee Ovr SRC Codes parameter in the SymXchange Client Parameters.

The ODT Auth/Fee Ovr Src Codes parameter in the SymXchange Client Parameters will allow vendors (i.e. iPay) to override the opted-out B source code.

This parameter specifies the source codes that determine how to authorize and apply a fee to overdrawn transactions that are authorized and posted via SymXchange. The source codes specified in this parameter will authorize and apply a fee to overdrawn transactions ignoring the ODT Auth/Fee field settings of the Share record.

To make these updates, please follow the below instructions…

1. Log in to quest and navigate to Parameter Manager > SymXchange Parameters > iPay > SymXchange Client 0 > Client Parameters.
2. Then change the ODT Auth/Fee Ovr Src Codes parameter to B.
3. Save the changes and refresh the iPay SymXchange instance for the change to take effect.

Reg D Overview

The general (or global) behavior for Regulation D is defined in the Miscellaneous Parameters Reg D Limiting Method and Reg D Limiting Type List.

• The Reg D Limiting Method allows the Credit Union to further define what types of transactions are allowed up to the 6 withdrawal limit.  While there are 4 choices, we only recommend one.

• The Reg D Limiting Type List is where the Credit Union defines their savings share types that should be considered for Reg D limiting.

SymConnect and SymXchange use these same parameters to determine the Reg D Limiting Method used and Share Types that are impacted.  However, there is also an option in SymConnect and SymXchange to not use Reg D Limiting when processing withdrawals.

Specifying Reg D within the SymConnect/SymXchange message

The first option is to specify in the SymConnect or SymXchange message as to whether Reg D should apply to the transaction.  

SymConnect

035 = TRREGD

This field allows a client to specify whether or not a Share Withdrawal (SW) transaction is subject to Regulation D limiting.

​A result of the regulation is a limitation on the number and kind of withdrawals a member can make from a savings-type share.

The TRREGD field supports the following values:

• Select REGD (1) for a Regulation D check or transfer withdrawal. Other fields in the SymConnect transaction determine whether the transaction is via check or transfer.
• Select REGDNONE (0) if the transaction is not subject to Regulation D limiting.

Selecting one of these values overrides existing SymConnect Regulation D parameters. 

​SymXchange

<dto:RegulationDLimited>?</dto:RegulationDLimited>

This field allows a client to specify whether or not a Share Withdrawal (SW) transaction is subject to Regulation D limiting.

​A result of the regulation is a limitation on the number and kind of withdrawals a member can make from a savings-type share.

The RegulationDLimited field supports the following values:

• Select TRUE for a Regulation D check or transfer withdrawal. Other fields in the SymConnect transaction determine whether the transaction is via check or transfer.
• Select FALSE if the transaction is not subject to Regulation D limiting.

Selecting one of these values overrides existing SymXchange Regulation D parameters. 

Using Reg D parameters

The second option is to use “Reg D Limiting” and “Overdraw Reg D Limiting?” in the SymConnect and SymXchange Client Specific Parameters.

Reg D Limiting

The Federal Reserve Board’s Regulation D requires a “depository institution” (such as a credit union) to keep on reserve a certain percentage of its assets. Assets held in savings-type shares (“time deposits”) are exempt from this requirement, which applies only to transaction shares (checking type shares).

To maintain accurate separation of these share types, the Federal Reserve Board sets a limit on the number and type of transfers and withdrawals a member can make each month from designated types of savings shares.

Indicate whether or not Regulation D limiting applies to transactions through the SymConnect interface for this client:

• Enter Y if Regulation D applies to transactions through the SymConnect interface for this client.
• Enter N if Regulation D does not apply to transactions through the SymConnect interface for this client. ​

Overdraw Reg D Limiting

Reg D limiting applies only to overdraw transfers from shares with a Share Type that appears on the Reg D Limiting Type list in the Miscellaneous Parameters.

The Overdraw Reg D Limiting? parameter determines if Symitar increases the Reg D Transfer Count or not, unless the count is at the 6 per month set at the Reg D Limiting Method parameter in Miscellaneous Parameters. This prompt behaves as follows:

• If the Reg D Transfer Count field in the Share record is at 6, Symitar does not clear overdraw conditions with that share. If available, Symitar attempts to clear the overdraw condition with other shares. If any of the following conditions occur, Symitar excepts out and does not increase the Reg D Transfer Count field on the Share record, regardless of the value set at this parameter:
  • There are no other available shares.
  • The Reg D Transfer Count field in the other Share records is also at 6.
  • There are insufficient funds available in the shares.
• If Yes is selected and the Reg D Transfer Count field is not at 6, Symitar proceeds with the overdraw transfer to clear the overdraw condition and increases the Reg D Transfer Count field on the Share record.
• If No is selected and the Reg D Transfer Count field is not at 6, Symitar proceeds with the overdraw transfer to clear the overdraw condition and does not increase the Reg D Transfer Count field on the Share record.​

Special Case

If you are withdrawing funds from a member’s share and depositing them to a GL Account SymConnect and SymXchange will not apply Reg D limiting regardless of the message content or parameter setting.  There is a workaround for this scenario by using the TRANPERFORM procedure in a PowerOn specfile.

Setting a Null Value

In SymXchange, when blanking out a date value, the XMLSchema-instance needs to be included in the header request as well as specifying the nil value.

An example of how a request would look is below with the specifications highlighted in yellow:

<soapenv:Envelope
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:acc="ht​tp://www.symxchange.generated.symitar.com/v2/account"
  xmlns:com="http://www.symxchange.generated.symitar.com/v1/common/dto/common"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"\>
   <soapenv:Header/>
   <soapenv:Body>
      <acc:updateShareByID>
         <Request MessageId="?">
            <ShareId>2</ShareId>
            <ShareUpdateableFields>
               <CloseDate xsi:nil="true" />
            </ShareUpdateableFields>
            <AccountNumber>1</AccountNumber>
            <Credentials>
               <AdministrativeCredentials>
                  <Password>KIM</Password>
               </AdministrativeCredentials>
            </Credentials>
            <DeviceInformation DeviceType="DRAC" DeviceNumber="20601"/>
         </Request>
      </acc:updateShareByID>
   </soapenv:Body>
</soapenv:Envelope>​

Setting Withdrawal Limits

1. Through SymXchange Parameters there is only one method for limiting cash withdrawals.  This can be enabled in the SymXchange parameters using the Use Cash Withdrawal Limits that are tied to the member’s Preference record on their account.  The Credit Union (or vendor) would need to update all their member’s preference records for the Cash W/D Limit field.  This limit would be per day.

   • Note: If the Credit Union has other SymConnect or SymXchange vendors using these parameters they will all be tied to the same limit.

2. Another option (probably the better option in most cases) is to use the Account Limit Parameters.  These parameters allow custom limits to be created by Source Code that are tracked at the Account level. To have this work with a SymXchange instance, make sure that the Source code in the Account Limit Parameters matches the Source code using by the instance. To use this feature the Limit fields in the Account Record would need to be updated/maintained. 

There is information on Account Limit Parameter and Account Limit fields in eDocs.

Note: There are only 6 limits that can be set, so it’s possible these are already being used by another channel (i.e. ATM).

Issues with SYCPULLCREDITREPORT in a Test SYM

If a client is having issues with SYCPULLCREDITREPORT in a test SYM:

• When installing SYCPULLCREDITREPORT, verify that the CRS Credit Report System is installed in the SYM. Most of the time it will be on a client test SYM.
• If it does not show in the SYM, transfer the case to Symitar Support, as CRS is billable for additional SYMs.

Symop

> CONFIGCRS                                                                    

06/02/15 19:07:54 CONFIGCRS                                                    

Configure CRS Command                                                          

----------------------------------------                                       

(0) Revise the Current CRS Configuration                                       

(1) Restore a Previous CRS Configuration                                       

Selection :0                                                                    

Revise CRS Configuration                                                       

----------------------------------------                                       

(0) Revise an Existing Network                                                 

(1) Create a New Network                                                       

Selection :0                                                                   

**CRS Networks:**                                                                  

Seq   Network #       Syms                                                      

------------------------------------------------------------------------------ 

(00)  Network 01:     000,214                                                  

(01)  Network 02:     508                      

SymXchange Instance Import Tool Instructions

This solution will import most of the setting required for a Banno SymXchange instance.  It will only create a brand-new instance or overwrite an instance with the same name.  It will not add a device to an existing SymXchange instance (this is typically how MDT configures SymXchange).

Import Tool Instructions

1. Upload the following file from /SYM/SYMITAR/SYMCONNECT/SYMX_TEMPLATES to the client site (/SYM/OP) from symmodem:

SYMX.<PRODUCT>.YYYY.VV.TMPL

where:

• <PRODUCT> is the product name.  For example: BANNO
• YYYY is the Symitar Release year
• VV is the Symitar Release versions (either 00 or 01)
• Example file name: SYMX.BANNO.2021.01.TMPL

2. Make sure Parameter Server (symitarParametersDB.EXE) is running for the SYM to import the Banno instance template.

# USERS symitarParametersDB.EXE | grep SYMxxx

where:

• xxx is the SYM to import the instance

NOTE: If no output is returned then the Parameter Server isn’t running

3. If Parameter Server (symitarParametersDB.EXE) is running, skip to step 5.

4. If Parameter Server (symitarParametersDB.EXE) is not running, there are two choices:

1. Add the SYM to /SYM/CONFIGURE/PARAMETERSERVICE.CFG and RESTART parameter server from symop.
2. Login to WebConsole and create a shell of the Banno instance in the destination SYM.

5. Run the following command to import the Banno Instance template:

 Note: Use the ROOTACCESS password at the Enter Password prompt and SYMxxx below is the destination SYM for the Product instance

# symXInstanceImportExport -file=/SYM/OP/SYMX._<PRODUCT.????.??>_.TMPL -sym=_SYMxxx_ import

Enter Password:

Parse import file

Start parameter import .

Set heap size

Done with import.

#

If a message is received stating ERROR! Failed to connect to Parameter Server. Exit., that is a good indication parameter service is not running for that sym and verification is needed that the sym is listed in PARAMETERSERVICE.CFG.

Manual Changes after Import (Instance Creation)

The instance creation process leaves several fields that will need to be set manually either by Episys SymXchange Support (at EASE), Service Bureau staff (MDT, Synergent, etc) and the client.

Please refer to the Vendor’s blueprint document for these settings. 

Symitar WebConsole Settings

1. If the instance is using HTTPS, create the appropriate Keystore and import the required certificates.
2. Log in to WebConsole SymXchange Web Services – Enhanced
3. Reference the Vendor Blueprint for setting that need to be input

These are the typical values:

1. HTTP(s) Port Number
2. Protocol
3. Key Configuration Name
4. Key Alias
5. Device Number
6. Client Number

Symitar Quest Settings

1. Log in to Quest Parameter Manager SymXchange Parameters
2. Reference the Vendor Blueprint for setting that need to be inputted
   • These are typically identified by the term “Set Accordingly” or “CU Preference”

SymXchange and Symconnect Clients Check Issues

SymXchange and Symconnect were only designed to work with Clients 0-19 when it comes to check processing, creation and printing.

Setting a Client over 19 will cause issues if the Symconnect or SymXchange interface performs transactions that issue checks. The issue appears​ to be with the available source codes on the Check record.

Important: Requests using client numbers greater than 19 are unable to perform transactions that post a check

You can find it here: eDocs > SymXchange Developers Guide > SymXchange Interface > SymXchange Transaction Samples.

SymXLogAnalyzer Utility

The /SYM/SYMPR/SymXLogAnalyzer utility is available in Episys Release 2019.01 and later.

This utility analyzes the data in the main symxchange log files (symXchange.SYM###..log) and provides statistics on the operations used and how long they took to run.

1. Log in to AIX.
2. Log in to root if you do not have read access to files in /SYM/ONHOST/log.
3. Execute SymXLogAnalyzer utility.

​Usage

commandName -period=value -instance=value -sym=value -startTime=value -stopTime=value -directory=value -Usage -Version -Verbose

​Descriptions

• period: (required)  period in minutes for the analysis [1, 5, 10, or 15]

• instance: (required)  SymXchange instance name

• sym: (required)  SYM name

• startTime: (required)  start time for the analysis in the format MM/dd/yyyy HH:mm

• stopTime: (required)  stop time for the analysis in the format MM/dd/yyyy HH:mm

• directory: (required)  log file directory

• Usage:  Print usage of this command and stop

• Version:  Print version information and stop

• Verbose:  Print detailed execution information

# ​/SYM/SYMPR/SymXLogAnalyzer -period=5 -instance=LIVEOLB -sym=000 -startTime=“03/30/2020 00:00” -stopTime=“03/30/2020 23:59” -directory=/SYM/ONHOST/log

SymXchange Performance Log Analysis

  start time: 03/30/2020 00:00

  stop time: 03/30/2020 23:59

  period: 5 minute(s)

Period                       Operation Name                                                           Num Execs     Min(ms)     Max(ms)     Avg(ms)   Total(ms)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

03/30/2020 10:40

- 03/30/2020 10:45

                             account.2019.00.createComment                                                    1          73          73        73.0          73

                             account.2019.00.createEft                                                        5          23          95        42.8         214

                             account.2019.00.createTracking                                                   1          11          11        11.0          11

                             account.2019.00.getAccount                                                     145          31         369        73.0       10590

                             account.2019.00.getAccountSelectFields                                          96           4          47        10.3         985

                             account.2019.00.getAccountSelectFieldsFilterChildren                          1658           9        1412       103.5      171638

                             account.2019.00.getEftListSelectFields                                           6           5          45        28.7         172

                             account.2019.00.getLoanTransactionPagedListSelectFields                       2477           6         416       111.5      276193

                             account.2019.00.getNameListSelectFields                                        817           6         546        39.7       32471

                             account.2019.00.getPreferenceListSelectFields                                  281           6         286        23.2        6514

                             account.2019.00.getShare                                                         6          69         131        98.2         589

                             account.2019.00.getShareTransactionPagedListSelectFields                     11635           5         689       143.1     1664738

                             account.2019.00.updateAccountByID                                                1          20          20        20.0          20

                             account.2019.00.updateNameByID                                                   1          27          27        27.0          27

                             account.2019.00.updateTrackingByID                                               2           8          11         9.5          19

                             episysinformation.2019.00.getGeneralEpisysInformation                           98           4          37        11.2        1096

                             filemanagement.2019.00.downloadDataFile                                        112           3          30         7.4         832

                             poweron.2019.00.executePowerOn                                                 335         132        1631       366.4      122747

                             transactions.2019.00.deposit                                                     2           8          25        16.5          33

                             transactions.2019.00.transfer                                                   12           6         315        41.0         492

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

Num Execs: Number of executions     Min: Minimum processing time     Max: Maximum processing time     Avg: Average processing time     Total: Total processing time

WithdrawFee GL posting issue

Vendor is using the withdrawFee operation to post stop payments to a GL Account. The payment was posted to GLS022(System GL Code 22)-0000 (Sub Source Code 0).0001 (branch 1) by default.

By design, withdrawFee will always go to the System defined fee GL. A defect was opened and it was deemed working as designed. SymXchange will ignore any GL account or codes that are sent.

The vendor will need to use withdraw, then they can specify the GL account.

Symitar Home Banking Password - Advanced Hashing

Advanced hashing option for storing passwords in Symitar. This is the SLA that was sent when this project was completed.

Details

Symitar® has successfully completed pilot testing of the Member Authentication enhancement. This enhancement lets a credit union store member passwords and audio access codes with an advanced hash that is compliant with current regulations and best practices.

To activate the advanced hash feature, the HB/Audio Password Hash Code field in Miscellaneous Parameters must be set to (2) Use Advanced Hash. This is a system-wide setting that will activate the advanced hash for all your applications—it is not possible to activate only specific applications.

If there any SymConnect™ or SymXchange™ applications using the password or audio access code fields in the Preference record, ensure they are compatible with the advanced hash. For more information about the potential effects, review the SymConnect & SymXchange: Improvements to Episys Member Password Storage document. Symitar strongly recommends that you forward this information to your third-party vendors.

To view a list of specific items to test for this enhancement, download the Member Authentication Client Test Scenario document.

If you have any questions, please open a Jsource support case. Set the Case Type field to Support Question, the Product field to Symitar, and the Problem Type field to SymConnect.

If you are a Symitar EASE™/OutLink Data Center client and use the above product, please follow the instructions in this SLA.

Recommended basic approach for implementation:

1. Test in a test environment until comfortable (including testing step 3 in the test environment).

   • Checklist from pilot testing is below as a guide/reference.

2. Go live for a limited number of users - turn hashing on, hash passwords on a few acccounts, turn hashing off.

   • Test with those accounts; non-hashed accounts will function normally.

3. Go live for all accounts - turn hashing on, update passwords.

Test Checklist

Below is the test checklist from the pilot testing. This could be used by Credit Unions who are considering implementation of this functionality.

Client Test Scenarios

Member Authentication 14.081

This document includes a list of specific items that should be tested during Client Pilot Testing for the Member Authentication project. The list is not complete; it is a guide to help get started. We recommend that each credit union determine additional testing activities after reviewing the business design and release documentation.

Please complete the activities in this document and record the data in the three columns to the right of each activity.

Affected Areas

• Symitar® Quest™, PowerOn®, SymConnect™, SymXchange™, any third-party applications that use the Preference record_

Approximate Time Required

• Setup:    < 1 hr
• Testing: 4–16 hrs

We have based the time estimates on the assumption that the user has a general familiarity with the project. The estimates provide an indication of the effort involved in testing this project, and they do not include execution of the Client Variations section, as those time estimates will vary depending on the credit union.

This document is not, and should not be considered as, legal advice or operational advice. It is presented “as is” and any use or modification by you is strictly your responsibility. No representations or warranties are made or implied.

Examples

​Here is a sample specfile that could be used for that purpose - this is hard-coded for a specific account. To update the entire database, the selection criteria would need to be changed - Credit Unions could work with Symitar Support if they need assistance with this.

[-------------------------------------------------------------------------------
$Workfile: (filename) $
$Revision: 1 $
Purpose: This specfile hashes passwords in the Preference record that
are still in clear text
Notes: Any notes can go here.
Rev Hist:
06/22/2015 WWeissenfels Created file.
-------------------------------------------------------------------------------]

TARGET=ACCOUNT

DEFINE
    TRUE=1
    FALSE=0
    NEWPW=CHARACTER
    UPDATEFIELD=NUMBER
END [DEFINE]

SETUP
END [SETUP]

SELECT
    ACCOUNT:NUMBER="0000119540"
END [SELECT]

PRINT TITLE="PREFUPDATEPWC"

    FOR EACH PREFERENCE  
        DO
            PRINT "ACCOUNT "+ACCOUNT:NUMBER+" MODIFY PREFERENCE LOC "
            PRINT PREFERENCE:LOCATOR
            NEWLINE

            IF PREFERENCE:HBPASSWORD<>"" AND PREFERENCE:HBPASSWORD<>"********************" THEN
                DO
                    PRINT " CHANGE HBPASSWORD FROM "
                    COL=49 PREFERENCE:HBPASSWORD
                    COL=90 "TO"
                    COL=93 LEFT PREFERENCE:HBPASSWORD
                    NEWLINE
                END

            IF PREFERENCE:HBPASSWORD2<>"" AND PREFERENCE:HBPASSWORD2<>"********************" THEN
                DO
                    PRINT " CHANGE HBPASSWORD2 FROM "
                    COL=49 PREFERENCE:HBPASSWORD2
                    COL=90 "TO"
                    COL=93 LEFT PREFERENCE:HBPASSWORD2
                    NEWLINE
                END
        END

END [PRINT]

User Password Hashing and Performance

There is a significant performance decrease when SymXchange is used with User Credentials and User Password hashing is turned on. 

Hashing can be checked the Miscellaneous Parameters in Quest, under User Password Settings -> Password Hashing. If this is set to “Yes” and User credentials are used in SymXchange, all requests could take up to 10 times as long as the same calls with hashing turned off.

​There is no way for the hashing to be turned off, once it is on. 

Options are:

• ​Use another credential type. The easiest would be Administrative Credentials.
• Only use User Credentials for the SymXchange calls that require the User to be recorded in history, i.e. only the monetary Transactions. 
• Use the Token Credentials​​.

Too Many Reports Can Cause SymConnect or SymXchange to Hang

If the REPORT queue is full (i.e. 10,000 items are more) SymConnect and SymXchange will “hang” going on/off host and into/out of memo mode.

Checklist

1. SymConnect and SymXchange open reports when going on host and when going into memo mode, and close those reports when going off host and going out of memo mode. If the report queue is full (10,000 or more) the above steps cannot be completed, and SymConnect/SymXchange will hang. (This causes similar symptoms with a number of other parts of Episys.)

Below are samples of the master console messages that occur with this, If these appear, the case should be sent to Symitar Support to work with the credit union to remove some of the reports. DO NOT DELETE ANY OF THE REPORTS YOURSELF! There may be logons that need to be cleared after the report queue is cleaned up.

This is a good example of why one should always take a look at the master console log as one of the first steps when troubleshooting, including going back to the period immediately before a problem (such as a fatal) occurred, to see what else might be happening on the system. 

Example

From PID 31916084: Batch PID 17825852 SYM001 - Over 9999 Reports

From PID 31981778: Please Delete Unnecessary Reports

Token Credentials

Token Credentials were created because there was a significant performance decrease when User Credentials are used with User Password Hashing enabled and set to Advanced Hashing. 

With Token Credentials, the UserManagement service is called with the User number and password. The logon function will return a Token that can be used in the Token Credentials until it expires. The expiration time is set in Webconsole but has a default setting to expire after 15 minutes of inactivity. A log off request invalidates the token so that it cannot be used in further requests.

To use Token Credentials:

1. ​Enable UserManagement Service in Webconsole
2. Set the Token Expiration time within Webconsole
3. Enable User credentials and the logon and logoff functions within this service withing the SymXchange Client parameters
4. Enable the Token credentials for all functions you will use them for.
5. Refresh SymXchange
6. Formulate a call to the Usermanagement service to logon
7. A token is returned from this call, use it in the Token Credential tag in all requests that would use User Credentials.
8. When the user session is over, make a call to the logoff function in Usermangement

​The purpose of the service is that SymXchange only has to perform the hashing when logging on to get the token and logging off. This significantly increases SymXchange performance.

XML Escape Characters

The vendor needs to escape all of the characters in the following list:

If they are not escaped in SymXchange, the core will usually replace it with ???, as it will not know how to process it.

How to overdraw a share or use Overdraft Protection with SymConnect and SymXchange?

In order to overdraw a share through SymXchange there are two routes in the SymXchange Client Specific Parameters.  Either route could impact member transactions depending on how the ODT auth fields are set in the share record.

Using Overdraft Protection

SymXchange allows for the same Overdraft Protection features that ATM, Draft and ACH posting have. Share and loan transfer and courtesy can be used. The fields that control ODP in SymXchange parameter are pretty much the same everywhere else in the system.  NOTE: Consider using the Online Main Parameters as a starting point.

At a minimum, set these three parameters in the SymXchange Client Specific Parameter for a <vendor to assess a Courtesy Pay Fee.

• Withdrawal Overdraw Option: Option 4 will allow Share, Loan and Tolerance.  Option 5 is Tolerance only

• Overdraw Fee Option: Option 4 will allow Overdraw Protection Transfers and Tolerance.  Option 2 would allow Courtesy only

• Rel 0 Couresy Pay Fee 1: Enter the Courtesy Pay fee to be assessed.

There are other fields that could be considered if using Relationship Pricing or to charge a fee for overdraft transfers from a share/loan.

After making any parameter changes a Refresh to the SymXchange instance from Device Control will need to occur before it will take effect.​​

Allow Shares to be taken negative

This is not a preferred setting to turned on as it may have the unintended consequence of overdrawing members when unwanted or unexpected.

The WD Below Available Option parameter can be set to allow a share to be overdrawn. This would meet the needs for the robbery dispense but probably won’t be ideal for regular member transactions.

As it relates to documentation of the ODP features in SymXchange. Reference the fields in eDocs as a start. Also leverage the Online Main, Draft and ACH ODP settings for reference.

How do check holds work with SymConnect and SymXchange?

Through SymXchange transaction posting logic there are only 2 parameters that can be leveraged in regards to funds availability.  Hold Days For Cash Dep/Pmts allows the number of hold days on deposits to be defined.  Grace Amount for Cash Dep/Pmts allows what amount of funds should be immediately available. These parameters cannot be selectively applied to certain transactions. All transactions leverage these two parameters

In order to tailor fund availability on a per account basis, this can be accomplish 1 of 3 ways:

1. The external application (connecting through SymXchange) evaluates the member/items and deposits the check and then submits an FM request to create the hold record. This could be accomplished by reading a field on the account indicating what amount the member is able to deposit without hold and then creating a hold record with the transaction based on this tier/value.

2. The external application could run a PowerOn specfile through SymXchange after the deposit was posted to calculate and create the hold record. The vendor wouldn’t need to understand the hold logic, the vendor would just need to run the specfile to handle the hold creation

3. Have a batch PowerOn specfile that is run in Op/Con every 15 minutes (or whatever interval) to look for check deposit transactions and waive hold for qualifying deposits/members.

Does SymConnect or SymXchange support KR Hold Base functionality?

SymConnect and SymXchange do not use the KR Hold base functionality that are available in Teller Transactions and ATM Network posting.

SymConnect and SymXchange only use the following two parameters in SymConnect/SymXchange Client Specific Parameters to define check holds and funds availability:

• Grace Amount For Cash Dep/Pmts
• Hold Days For Cash Dep/Pmts

When looking for RDC deposits to use and update the Check Hold and Deposit fields in the Account record then work with the RDC vendor to honor and update them.

• Check Dep Total Amount
• Check Dep Total Date
• Check Hold Base Amount
• Non-Reg CC Check Dep Total Amt
• Non-Reg CC Check Hold Base Amt

How do I get cash transactions performed through SymConnect or SymXchange on my CTR report?

The CTR Processing Batch Program and Cash reports only looks for cash transactions in certain System Defined GL Codes.

• For SymConnect: System Defined GL Codes 56
• For SymXchange: System Defined GL Codes 98

This issue has been brought up by several other clients and Product Development is aware that changes are needed. In the interim, If these transactions need to be reflected in these system reports make sure all the cash transactions performed through SymConnect and SymXchange use these GL Codes.

To achieve this set the GL Code field in the SymConnect/SymXchange Client Specific Parameter to 0 and make sure vendors are not passing a GL Code in the transaction request. Also make sure that the right GL Account(s) are translated in the GL Translation table for System Defined GL Code 56 or 98.

Using the System Defined GL codes is very limiting as to how these transactions can be translated. Translation is not allowed by user number or leverage GL account branch accounts.

An alternative to using the System Defined GL codes would be to use a PowerOn specfile to supplement the cash reporting. You can use RB.CORP.INTRADAYGLBALANCE as an example.

NOTE: When using SymXchange and want the US Cash Disb Amount and US Cash Rcvd Amount (required for eCTR to detect these transaction at the Teller line) updated in the Account record make sure vendors are setting the PureUSCash field to “true” in the request.

How does the Card Credential work in SymXchange?

We have a back door of sorts written into SymXchange/SymConnect that allows the vendor to pass the member account number with a specific prefix and this gives them the ability to perform CRUD operations on the account without needing the homebanking user and password or Admin credential.

In SymXchange the Admin credential has replaced the need to use the Card Credentials to complete operations but because of the outstanding software defect this is a way to work around it for now.

If a credit union has a prefix of 20207. Pass 20207+10 digit member account number in the CardCredentials CardNumber field:

<CardCredentials>
  <!--Optional:-->
  <CardNumber>20207NNNNNNNNNN</CardNumber>
</CardCredentials>

Make sure that Card Credentials are enabled in the SymXchange Parameters for the PowerOn operation that is being used. NOTE: A REFRESH to SymXchange from Device Control is needed for changes to take effect.

Can you create a GL Comment in SymXchange?

SymXchange can only place GL comments when using the GLToGLPost operation.

If funds are being moved in or out of the GL using withdraw, withdrawFee or deposit operations there is no ability to set a GL Comment for those transactions. 

How do you set a custom transaction source code for SymConnect or SymXchange?

To change the transaction description on these transactions two parameter updates in Symitar will be needed to create a custom source code.

1. Modify the Transaction Source Code field in your SymConnect Client Parameters to one of the unused User Defined Source Codes (0-9).  
2. Modify the corresponding User Defined Source Code (UserDef Source Code #) in the Statement Generation parameters accessed through the Statement Generation batch program. The value can be up to 20 characters in length.

After the parameter settings are saved all transactions that use the User Defined Source Code will display the new text in transaction history.

How can a SymXchange operation be completed using User Credential if I don’t have the user privilege?

​When using User Credentials to perform operations in SymXchange we do check the User Privileges for that User Number.

If they are not allowed to complete a task through Quest they will not be allowed to complete it through SymXchange if using User Credentials.

If vendors were previously using Admin Credentials this problem would not have been observed.

There are a few workarounds for this issue:

1. Grant these users privileges in User Control

2. For the SymXchange operations that are having trouble set “Allow No End-User Validation”. This basically bypass the Credential check altogether.

3. Have the vendor switch to Admin Credentials for problematic operations.

How can Overdraft Protection be enabled for SymConnect/SymXchange transactions?

At a minimum, set these three parameters in the SymXchange Client Specific Parameter for a <vendor to assess a Courtesy Pay Fee.

• Withdrawal Overdraw Option: Option 4 will allow Share, Loan and Tolerance.  Option 5 is Tolerance only
• Overdraw Fee Option: Option 4 will allow Overdraw Protection Transfers and Tolerance.  Option 2 would allow Courtesy only
• Rel 0 Couresy Pay Fee 1: Enter the Courtesy Pay fee you wish to assess.

NOTE: There are other fields that could be considered if using Relationship Pricing or to charge a fee for overdraft transfers from a share/loan.

After making any parameter changes a Refresh to the SymXchange instance from Device Control will need to occur before it will take effect.​

In addition to the SymXchange Parameters listed above make sure that the ODT Fields in the Share/Loan record are set appropriately:

• ODT Auth/Fee Option 1 - ODT Auth/Fee Option 4
• ODT Auth/Fee Option Other
• Fee Exemp Courtesy Balance
• ODT Source Code List 1 - ODT Source Code List 4​

Batch

Adding Batch Service to a SymXchange instance

Follow these steps to add to an existing (or new) Batch Job to the SymXchange instance. The service addition will require a certificate.

If the powerOn2Engine Keystore and certificate exist, there is no need to add a new one. 

Batch Job Service Addition in SymXchange

1. Application Server Setup

• In /SYM/CONFIGURE/HOST.CFG check for the last PTTY number used, use the next available number in configuration.
• Log in symop and at > sign type CONFIGURE
• At selection list select 1 (create network device configuration)
• At next prompt select 2 (PC)
• Keep default at next prompt (N)
• At Host Name select a name
• PTTY add the next number available from HOST.CFG
• MCPPT select any number between 1 and 1999 – can be changed later if needed to
• Confirm configuration – this will add the new host name in HOST.CFG

2. Instance Configuration to Add Batch Job

1. Check if a powerOn2Engine keystore and certificate already exist. If available go to step 2 if not, go to CREATE KEYSTORE AND CERTIFICATE section, create the keystore and certificate.
2. In powerOn2Engine keystore, export the certificate in a PEM format and save it.
3. If a keystore for the SYM where the batch job is installed exists then go to the keystore and step 4 if not, go to CREATE KEYSTORE AND CERTIFICATE section and create a SYM# keystore.
4. In SYM# keystore – TRUSTED STORE - select IMPORT and browse to location where the PEM certificate should be saved.
5. Install the certificate and add certificate to keystore trust store
6. Restart Application service (symop option 46). Select the SYM number from list or OTHER if not listed and add the SYM number.

3. Complete Configuration

In WebConsole navigate back to SymXchange Web Services

1. Select the SYM number from the SYM drop down
2. Click the Details hyperlink
3. Change the instance to https
4. Assign the key store configuration that was created previously to the drop down labelled Internal Service Provider Key Store Configuration (powerOn2Engine)
5. Change the Key configuration to powerOn2Engine and Key Alias to poweronweb
6. Click Save
7. Restart SymXchange

4. Create Keystone and Certificate if needed

Keystore and certificates for this service can be created via WebConsole, the service will work fine with a server-side certificate (self-signed). A keystore at SYSTEM level will be needed (for powerOn2Engine – this should be already created as part of release load) and another keystore at SYM number level, where the Batch Job service is installed.

To create a new keystore, log in WebConsole and in Key Management menu select Key Store Configuration. In the new window, click on New Configuration, add the keystore name, a description(optional) and SYSTEM or SYM number in Host SYM selection window (defaults to SYSTEM). The new keystore will be added to the list and can be accessed to perform certificate management (addition, export/import, delete).

Create a Certificate (for powerOn2Engine)

1. Log on to the System Web Console.
2. In the System Web Console window, select Key Management from the menu.
3. The Key Store Configuration List pane appears.
4. In the Configuration Name column, click the PowerOn2Engine key configuration.
5. Select the Key Stores tab, and then, under the Key Store section, click the Open Key Store icon.
6. The Key Management pane appears.
7. Click Create Key.
8. The Create Key dialog box appears.
9. At the Alias prompt, type poweronweb.
10. Be sure to use all lowercase letters.
11. At the Days of validity prompt, enter the number of days for the key to be validated.
12. At the Key Size prompt, select 2048 bits

Respond to the remaining prompts as appropriate:

1. Common Name (CN): This is the host name of the server that this certificate is being installed on (usually FQDN).
2. Organization (0): This is the name of the financial institution.
3. Organization Unit (OU): This is the organization or business unit.
4. Locality (L): This is the city where the financial institution is located.
5. State/Province (ST): This is the state where the financial institution is located.
6. Country/Region (C): This is the country where the financial institution is located.

Click CREATE, certificate should be in the keystore​.

Batch Job Error SymXchange Message Error

When a client is running the batchJobService and gets the following error…

<soapenv:Envelope
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:bat="http://www.symxchange.generated.symitar.com/batchjobs" 
 xmlns:common="http://www.symxchange.generated.symitar.com/common/dto/common">
  <soapenv:Header/>
  <soapenv:Body>
      <bat:executeBatchJob>
         <Request MessageId="1">
            <Credentials common:ProcessorUser="1">  
               <UserNumberCredentials>
                  <UserNumber>1</UserNumber>
                  <Password>(removed)</Password>
               </UserNumberCredentials>
            </Credentials>
            <DeviceInformation DeviceType="INTERNAL" DeviceNumber="20778"/>
            <Async>1</Async>
            <JobName>MY.SYMXCHANGE.BATCH.TEST</JobName>
         </Request>
      </bat:executeBatchJob>
   </soapenv:Body>
</soapenv:Envelope>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
        <faultcode>soap:Client</faultcode>
        <faultstring>[MessageId=1] **There was an unknown exception in the application. The exception is com.symitar.exception.SymitarRuntimeException com.symitar.exception.NotFoundException: poweron2Engine.SYSTEM.ws.port is not registered**</faultstring>
        <detail>
            <ErrorCode></ErrorCode>
            <ProposedSolution>An unknown exception has occurred within the application. Please record all known information about the exception including the error message and what attributes you were submitting to the given process. Report this information through the appropriate application support avenues. </ProposedSolution>
        </detail>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

… check if the symServer is up.

From log:                                                              

2022-04-25 11:04:05,419 [qtp1683626353-73] ERROR com.symitar.symxchange.batchjobs.service.BatchJobsFacade - Exception with execute batch job

com.symitar.exception.SymitarRuntimeException: com.symitar.exception.NotFoundException: poweron2Engine.SYSTEM.ws.port is not registered

at com.symitar.symxchange.batchjobs.utils.PowerOn2ServiceClient.getPowerOn2Port(PowerOn2ServiceClient.java:84) ~[com.symitar.symXBatchJobsWS.jar:2021.01.302560]

at com.symitar.symxchange.batchjobs.utils.PowerOn2ServiceClient.formatPowerOn2Url(PowerOn2ServiceClient.java:102) ~[com.symitar.symXBatchJobsWS.jar:2021.01.302560]

If symServer is not up:

root@CT48ATXEPIPROD #USERS symServer                                     

Processes matching pattern 'symServer':                                       

     UID      PID     PPID   C    STIME    TTY  TIME CMD                       

root@CT48ATXEPIPROD #    

If symServer is up you will get the following:

#USERS symServer

root@PT19ATXEPIPROD #USERS symServer                                            

Processes matching pattern 'symServer':                                        

     UID      PID     PPID   C    STIME    TTY  TIME CMD                       

    root 16777428        1   0 13:13:21 pts/114  0:00 /usr/bin/ksh /SYM/MACROS/CONSOLELOG -LOG=SYSJAVACONSOLELOG -PROC=[/SYM/SYMPR/symServer.EXE]              

    root 33423412 16777428   1 13:13:21 pts/114  0:27 /SYM/SYMPR/symServer.EXE -

SYM=SYM778 -configFile=poweron_core-dc.xml,poweron_core-ps.xml,powerDocs-dc.xml,

powerDocs-ps.xml,powerBatch-dc.xml,powerBatch-ps.xml,overrideServices-dc.xml,ove

rrideServices-ps.xml                                                           

root@PT19ATXEPIPROD #               

Fix for the error if symServer is not up:  

(46) Restart Symitar AppServer          

Cancel a Batch Job

1. Determine the purpose and if the jobs following the running job also need to be cancelled.
2. Do they use OpCon or a job scheduler?
   • If they do, there may be considerations needed if that job completing will trigger other jobs.
3. If there are, take the necessary action prior to proceeding. 
4. Log into the sym where the job is running.
5. Go into Batch Control.
   • On the lower section of the screen the Batch Queues are displayed. 
6. Highlight the job that needs to be cancelled.
7. In the ‘Related Functions’ or the icons select ‘Terminate Running Batch Jobs’.
8. Select proper option, whether to terminate current job and all subsequent jobs, Terminate current job.

Alternate ways to cancel the job without going into the sym. Using qcan may leave a ghost or batch logon. If using this method, ensure there are no remaining ghost or batch logons that could prevent processes from running in the sym.

1. Login symop
2. Display the batch queue to get the number
3. Login as root and then run, qcan -x <JOB#>, where JOB# is the one that needs to be canceled.
4. As Root, run qcan -x <JOB#>

Share Batch Warning

13999 ​Share Batch Warning

Scenario

Error prevented a Deposit Transaction from a Share to a GL Code. The Share has a “No Batch Posting Allowed” warning code.

Client wants to confirm if there is a workaround/bypass to enable NCR ITM (Vendor) to allow transactions given that Share has the warning code.

Solution

Upon testing, Deposit Service doesn’t have the capacity to bypass the Warning Code.

Advised either of the following:

1. NCR ITM add additional process to remove/expire the Warning Code, do the transaction, then add the Warning Code back to the Share.

2. Transact through Teller.

Further testing shows that Withdraw Service can bypass the transaction by updating the following field: 

<dto:ForcePostRequested>?</dto:ForcePostRequested>

The transaction will be posted but will encounter an error of StatusCode = “3999” StatusMessage = Share Batch Warning​

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <tns:withdrawResponse 
       xmlns:tns="http://www.symxchange.generated.symitar.com/v1/transactions"
       xmlns:transactionsdto="http://www.symxchange.generated.symitar.com/v1/transactions/dto">
         <Response 
          MessageId="123" 
          StatusCode="3999" 
          Confirmation="08210000058160" 
          SequenceFrom="126399" 
          TransactionPostDate="2020-02-04">
            <StatusMessage>Share Batch Warning</StatusMessage>
            <transactionsdto:OverdrawInformation>
               <OverdrawToleranceAmount>0.00</OverdrawToleranceAmount>
            </transactionsdto:OverdrawInformation>
         </Response>
      </tns:withdrawResponse>
   </soap:Body>
</soap:Envelope>

Cards

Virtual Card Edit (VCE)

When a SymConnect or SymXchange CARD message arrives, the first checks the SYCEDIT for the credit union to see if it can get on the account with that method. (Typically a prefix+10 digit account number.)

If it cannot find the account with that method, it then checks the “Use Standard Card Lookup” parameter in the SymConnect Client Specific or the SymXchange Client parameters for the interface in question.

• If that is set to “No”, then there will be a “Not found” response.

• If that is set to “Yes”, then the data base is checked for an account with a card record with the card number equal to the number that came in the message.

  • If it finds one, then the message will be processed for that account.

  • If it doesn’t find one, then a “not found” response will be sent back.

When gathering information to have a SYCEDIT created, make sure that it is asked if the interface will be doing cross-account transfers with that prefix, as that requires some additional logic in the edit.

Certificates

Failing to Start Due to Missing Certificate

This is a case where the initial problem was assumed to be the SYM revision incompatibility. Per a log review (instance log, security, configuration file and keystore) the problem was isolated to a missing certificate. The Credit Union had two instances (Wire and Constellation) only WIRE had a certificate in keystore. The logs were showing that the web console was unable to read the certificate information, the configuration file was showing both instances configured to use TLS and keystore was missing the certificate. Per recomendation, the credit union changed the instance configuration to unsecure and was able to restart instance with no other problems.

Root cause was likely a SYM refresh done from Credit Union primary SYM000 to symdev server where the SYM000 keystore was overwritten and deleted the certificate for test SYM.

+12148   2020-02-26 20:00:50,248 \[symXchange\] ERROR com.symitar.symxchange.mainl  
ine.StartupOrchestrator  - Error starting up symXchange.                         
+12149  com.symitar.exception.SymitarRuntimeException: symXchange SYM500.2 confi  
guration error                                                                   
+12150          at com.symitar.symxchange.mainline.StartupHelper.getRuntimeConfi  
guration(StartupHelper.java:121)                                               

  
  +510  2020-02-26 19:58:32,826 \[pool-1-CertificateMonitoring-1\] INFO  com.symit  
ar.security.keystore.monitor.WebConsoleExpirationThresholdFinder  - cannot load  
configuration file: properties system property not set.  no configuration being  
loaded.                                                                          
  +511  2020-02-26 19:58:32,826 \[pool-1-CertificateMonitoring-1\] ERROR com.symit  
ar.security.keystore.monitor.WebConsoleExpirationThresholdFinder  - cannot load  
properties.  using default expiration threshold value of 90    

[root@symdev1](mailto:root@symdev1) #cd KEYSTORE                                                        
[root@symdev1](mailto:root@symdev1) #fs                                                                 
total 40                                                                         
\-rwxrwx---    1 SYM500   SYM500         360 Oct 29 2018  Security.properties     
\-rwxrwx---    1 SYM500   SYM500         240 Oct 25 2018  Wire.keyconfig          
\-rwxrwx---    1 SYM500   SYM500        4100 Oct 29 2018  WireKeyStore.jceks      
\-rwxrwx---    1 SYM500   SYM500          32 Oct 25 2018  WireTrustStore.jceks    
[root@symdev1](mailto:root@symdev1) #                                                                   
\-rwxr-x---    1 SYM500   SYM500       94895 Nov 26 01:29 adminAuthServer.EXE   

 +3030          <Parameter name="KeyStoreAlias" isSubsetReference="false">       
 +3031              <value>wits</value>                                          
 +3032          </Parameter>                                                     
 +3033          <Parameter name\="KeyStoreConfigurationName" isSubsetReference="false">                                                                           
 +3034              <value>Wire</value>                                          
 +3035          </Parameter>                                                     
 +3036          <Parameter name="Protocol" isSubsetReference="false">            
 +3037              <value>https</value>                                         
 +3038          </Parameter>                                                   

  
 +3104          <Parameter name="KeyStoreAlias" isSubsetReference="false">       
 +3105              <value>a</value>                                             
 +3106          </Parameter>                                                     
 +3107          <Parameter name="KeyStoreConfigurationName" isSubsetReference="false">                                                                           
 +3108              <value>SymXchange</value>                                    
 +3109          </Parameter>                                                     
 +3110          <Parameter name="Protocol" isSubsetReference="false">            
 +3111              <value>https</value>                                         
 +3112          </Parameter>    

URL Must Use Certificate Common Name

SymXchange URL must match CN on certificate.

root@symitar1 #openssl s_client -servername symitar1 -connect symitar1:41001

CONNECTED(00000003)

depth=0 C = US, ST = California, L = San Diego, O = MyPoint Credit Union, OU = IT, CN = symitar.mypointcu.com

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 C = US, ST = California, L = San Diego, O = MyPoint Credit Union, OU = IT, CN = symitar.mypointcu.com

-–

Certificate chain

0 s:/C=US/ST=California/L=San Diego/O=MyPoint Credit Union/OU=IT/CN=symitar.mypointcu.com

i:/C=US/O=DigiCert Inc/CN=DigiCert Global CA G2

Error Code Descriptions

1.23 - Please check if the SOAP message is well formed and has the required elements

The Password format is not correct due to the ampersand character.

SOAP does not like the ’&’ in the password. Please remove the ampersand sign or escape the character. Escape sequence &

Reference XML escape characters under the General Topics section.

'https://ease-symx.com:18744/SymXchange/2020.00/account' \--header 'Content-Type: application/xml' \--data-raw '

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:acc="http://www.symxchange.generated.symitar.com/account" xmlns:tns="http://www.symxchange.generated.symitar.com/common/dto/common">
  <soapenv:Header/>
  <soapenv:Body>
    <acc:getAccountSelectFields>
      <Request MessageId="123456">
        <AccountNumber>231972</AccountNumber>
        <Credentials>
          <AdministrativeCredentials>
            <Password>s@f$&g?SD32D@*4dfDS</Password>
          </AdministrativeCredentials>
        </Credentials>
        <DeviceInformation DeviceType="INTERFACEAI" DeviceNumber="20129"/>
        <SelectableFields>
          <IncludeAllAccountFields>1</IncludeAllAccountFields>
        </SelectableFields>
      </Request>
    </acc:getAccountSelectFields>
  </soapenv:Body>
</soapenv:Envelope>'

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Client</faultcode>
      <faultstring>[MessageId=] Bad request.</faultstring>
      <detail>
        <ErrorCode>1.23</ErrorCode>
        <ProposedSolution>Please check if the SOAP message is well-formed and has the required elements.</ProposedSolution>
      </detail>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

1005 Subscriber Code Error

Subscriber code error when using the orderReport WSDL:

<Status>
    <StatusCode>1005</StatusCode>
    <Message>Subscriber Code required for ChexSystems Suite Request</Message>
</Status>

The credit union will need to set the subscriber code (CU code) for the CR agency they are working with (chexsystem in this case).

Subscriber Code

• Data Type: 10 Characters

• Help File: 40103

• Default Value:

  Enter the credit union’s subscriber code (up to 10 characters) that each credit bureau issued. This can include ChexSystems (where it is also known as eFunds Customer ID), Equifax (where it is also known as Customer Number), Experian, or TransUnion. This code is used as the default subscriber code Symitar enters when a CRS request is initiated.

  The Change Subscriber Code privilege is required to change the credit bureau Subscriber Code parameter. Since this code is provided by the bureau, changes to this parameter are not normally made.

SymXchange Error Codes 3003 and 3006

SymXchange error code 3003 and 3006 when adding services

• 3003: Error on Deleting ParameterSet:Operation not allowed! Parameters Service in READ-ONLY mode
• 3006: Error on Deleting ParameterSet:Operation not allowed! Parameters Service in READ-ONLY mode

Check the SYM to see if is in MEMO Mode

If in Memo Mode and need to get out test sym out of memo mode: 

1. Go into console control and confirm the sym is on line
2. Go into Batch Control
3. From the Program drop down select ‘Batch Host Control’
4. Select Post Memo and Exit Memo Mode (next)
5. Take remaining defaults to run

If this occurred in production, A support ticket to Symitar Support should be opened to assist the Credit Union as there may be underlying issues.

100.10000

This error is received when the createAccount call succeeds with creating the records, Account and Name, but there is an error updating one of the Name record fields. The Name record is created, but a particular field is blank.

The response will contain the account number. Another call is needed to update the Name record with the error from the response.

Example response below. The Birth Date field in the Name record would need to be updated. 

<soap:Envelope>  
   <soap:Body>  
      <soap:Fault>  
         <faultcode>soap:Client</faultcode>  
         <faultstring>[MessageId=876543]  Account record created successful (ID 0016960520), but Name record create failed: Failed to create record type Name - Birth Date cannot be in future.</faultstring>  
         <detail>  
            <ErrorCode>100.100000</ErrorCode>  
            <ProposedSolution/>  
         </detail>  
      </soap:Fault>  
   </soap:Body>  
</soap:Envelope>  

10014 - This request did not specify a password

Using an audio access code in the SymXchange call causes an error.

In the sym being used, the SymXchange client parameters “HB Password” is set to a value of Yes, but the audio access code is being sent in the call.

SymXchange is expecting the HB password. If using the audio access code then the HB password parameter needs to be changed to a value of No.

Bounce the SymXchange instance or refresh in device control after the parameter change occurs.

<acc:getAccountSelectFields>  
  <Request MessageId="6e414364-7576-42af-9b5b-734ac4d778ca">  
    <AccountNumber>1117637</AccountNumber>  
    <AudioAccessCode>1111</AudioAccessCode>

<faultstring>\[MessageId=6e414364-7576-42af-9b5b-734ac4d778ca\]  This request did not specify a password : This request did not specify a password</faultstring>
<detail>
  <ErrorCode>100.10014</ErrorCode>  

10104 - Account not found

The account number did not match any account number in the Symitar database.

The HomeBanking username field contains an invalid value, HRET@COMCAST.NET.

Please look at the member’s Preference Record and have them try to log in using the HB username in the Preference record or the preference record does not exist.

    <tns3:getAccountSelectFieldsFilterChildren>  
      <Request MessageId="3f8628d773833a3201e20d488af0dfb6" tns3:BranchId="0">  
        <Credentials>  
          <HomeBankingCredentials>  
            <UserName>HRET@COMCAST.NET</UserName>  
            <Password>XXX</Password>  
          </HomeBankingCredentials>  
        </Credentials>  
        <DeviceInformation DeviceType="BANNO" DeviceNumber="20227"/>  
        <SelectableFields>  
          <AccountFields>  
            <ActivityDate>true</ActivityDate>  
            <EStmtEnable>true</EStmtEnable>  
            <EStmtNotify>true</EStmtNotify>  
            <Number>XXXtrue</Number>  
            <Restrict>true</Restrict>  
            <Type>true</Type>  
          </AccountFields>  

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Client</faultcode>
      <faultstring>
        [MessageId=3f8628d773833a3201e20d488af0dfb6]  The specified account was not found : The specified account was not found
      </faultstring>
      <detail>
        <ErrorCode>100.10104</ErrorCode>
        <ProposedSolution/>
      </detail>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>

10107 - An invalid password was specified

The password in the request message does not match a valid password for the account and user code (if a user code is required).

<ErrCode>10107</ErrCode>
<ErrCat>Error</ErrCat>
<ErrDesc>Symxchange error. An invalid password was specified</ErrDesc>
<ErrElem>SymXchange</ErrElem>
<ErrLoc>SymXchange</ErrLoc>  

1. Verify in the SymConnect/SymXchange client parameters that the correct admin password is being used and that “Use HB Password” is set to a value of Yes.
   • Refresh in device control if changes were made.
2. In Miscellaneous parameters, verify that the “HB Password Maximum Length” is 10 digits.
   • If shorter, the remaining digits are cut off.
3. The preference record “HB Password” field must be set to a value of 8 or greater.
   • The maximum number of characters you can enter in this field is 20.
   • Additionally, a home banking password that contains the value in the “HB Username” field cannot be used.

10108 - This account cannot be accessed by this client system

1. Check if the SymConnect Client number for the Vendor/Device is added to JHA Priv list.

# PARAMFM.UTIL -MODIFY -SYMCONNECT
Parameters File Maintenance

WARNING: This program is exclusively for use by authorized employees
         of Symitar who have the permission and  the training required
         to run this without corrupting the database.
         Additionally, the program requires a special password and logs valid
         and invalid attempts to run!
  
Password :********
  
Shared Page Parameters:
  WARNING - These will be instantly updated!
  
  Enabled SymConnect Clients:     ALL  
  Add SymConnect Clients [NONE] :________________________________________
  Remove SymConnect Clients [NONE] :________________________________________
  JHA Priv SymConnect Clients:    ALL
  Add JHA Priv Clients [NONE] :________________________________________
  Remove JHA Priv Clients [NONE] :________________________________________
  Enabled SymConnect Clients:     ALL  
  JHA Priv SymConnect Clients:    ALL  
  
DB Evolution --
Relational tables supported by SEDB
Prompts disabled for the following Flags:
  
Any changes to the above are now in effect!

2. Issue could be due to the HB Mode being set to (0) No Home Banking. Check the Account Preference Record and advise the client to change to (1) Standard Home Banking.

10115 - This user does not have the required privilege

This error can occur when using the getUser operation.

<soapenv:Envelope
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:user="http://www.symxchange.generated.symitar.com/user"
 xmlns:com="http://www.symxchange.generated.symitar.com/common/dto/common">
   <soapenv:Header/>
   <soapenv:Body>
      <user:getUser>
         <!--Optional:-->
         <Request MessageId="1" user:BranchId="0">
            <UserNumber>1101</UserNumber>
            <Credentials>
               <AdministrativeCredentials>
                  <Password>TRACY</Password>
               </AdministrativeCredentials>
            </Credentials>
            <DeviceInformation DeviceType="TZ201901" DeviceNumber="0"/>
         </Request>
      </user:getUser>
   </soapenv:Body>
</soapenv:Envelope>  

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:Client</faultcode>
         <faultstring>[MessageId=1]  This user does not have the required privilege : This user does not have the required privilege</faultstring>
         <detail>
            <ErrorCode>100.10115</ErrorCode>
            <ProposedSolution/>
         </detail>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>  

Verify that the Allow User File Access parameter for the instance is set to a value of “Yes”.

13010 - An invalid transaction amount was specified

This will occur if:

1. Cash Amount + Check Amount does not equal TRAMOUNT
2. Cash Amount is less than 0
3. Check Amount is less than 0
4. TRAMOUNT is not a number
5. TRPRINCIPAL is not a number

Details

1. The SymConnect transaction amount field is either invalid, the principal amount specified is invalid, the check amount is less than 0, or the cash amount is less than 0, then 13010 error will occur.
2. For SD or LP transactions you can specify how much was received by cash or check by specifying the amount in the message (for example, TRRECP=C4000,K5000 for a $90.00 deposit). If the total of cash and check does not equal the TRAMOUNT the 13010 error will occur.
3. For SW, LA, LN, or GL transactions, specify how much was disbursed by cash or check specifying the amounts in the message (for example, TRDISB=C4000,K5000 for a $90.00 withdrawal). If the total of cash and check disbursed does not equal the TRAMOUNT the 13010 error will occur.

13027 - No Transaction Access

1. This will occur when the account does not have the correct Card Access or Preference Access record.
2. This can also occur when the account DOES have the correct record with the correct CARD ACCESS records underneath it.

Details

1. There needs to be a card record on the account, with a number matching the number sent in Field F of the SymConnect message.

   • Usually this is a “virtual” card record, with the number of 20XXXAAAAAAAAAA (XXX is Credit Union number, AAAAAAAAAA is the 10 digit account number, including leading 0s), but it could be an actual credit/debit/ATM card record, or a virtual card record with a different numbering format.
   • Underneath this card record, there needs to be a valid CARD ACCESS record that is set up for the desired transfer.
   • If either or both of these records do not exist, the 13027 response will occur.

2. The account being accessed has multiple card records with the same card number (which is the number sent in field F of a SymConnect message), but only one of them has the correct access record underneath it.

   • The SYCEDIT code will stop when it gets to the first card record with a card number that matches what was in Field F.
   • If that record does not have the correct card access record underneath it, the result will be a 13027 response.
   • There is no way to force the SYCEDIT to go through the card records in a particular order. 

Example

This is a screen shot of an account where all the card records shown have the same card number, but only the last one has access records - the highlighted one is the correct one for the desired transfer, but the SYCEDIT code doesn’t get to that card record.

13028 - This account does not have the privilege to perform this transaction

If a Transfer In or Transfer Out transaction is attempted, the Preference HB Enable Code must be set to either (1) Transfers or (2) Withdrawals and Transfers.

If a Withdrawal, Add On, or New Loan transaction is attempted, the Preference HB Enable Code must be set to (2) Withdrawals and Transfers.

HB Enable Code

This field stores a code that control the member’s level of access to NetTeller and, if using SymConnect, the level of access to the audio response system.

• Field Number: 013
• Mnemonic: HBENABLE
• Data Type: Code to 2
• Source: User-entered
• Help File: 06613
• Default Control: Yes
• Default Value: 0

Data Type Descriptions

(0) Inquiries Only
Allow the member to perform account inquiries only through the home banking or audio response system.

(1) Transfers
Allow the member to perform account inquiries and transfers through the home banking or audio response system.

(2) Withdrawals and Transfers
Allow the member to perform account inquiries, transfers, and withdrawals through the home banking or audio response system.

Initially all accounts have this field set to 0. As members apply for home banking services, set this field to 1 or 2, depending on the level of access requested.

13029 - This transaction cannot be performed because this loan is overdue

There are three fields in the SymXchange Client Parameters for <interface> that restrict activity on an account when a loan is past due:

• Addon Past Due Days
• Payment Past Due Days
• Withdrawal Past Due Days

NOTE: These fields default to 10 days, but can be set 0-9999.

If there is a delinquent loan (including charged off), the system will restrict access to those three activities once it exceeds the value in the parameter.

If this member with a charged off loan should continue to be allowed to make loan addons, loan payments or withdrawals through <interface>, then increase the days value to something greater than the delinquency days.

Note: If a change was made in the SymXchange Parameters and want the changes to go into effect. Go into Device Control > Device > Dropdown: SymXchange > Highlight the Instance that the changes were made to > Refresh.**

13030 - Invalid Transaction Share

Credit Union is receiving the following error in a SOAP message: An invalid transaction share or loan ID was specified Not able to make a share deposit via SymXchange.

<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/>
    <soap:Body>
        <tns:payLoanResponse
         xmlns:tns=http://www.symxchange.generated.symitar.com/v1/transactions
         xmlns:transactionsdto=http://www.symxchange.generated.symitar.com/v1/transactions/dto>
            <Response MessageId="0" StatusCode="13030">
                <StatusMessage>An invalid transaction share or loan ID was specified </StatusMessage>
                <transactionsdto:OverdrawInformation>
                    <OverdrawToleranceAmount>0.00</OverdrawToleranceAmount>
                </transactionsdto:OverdrawInformation>
            </Response>
        </tns:payLoanResponse>
    </soap:Body>
</soap:Envelope>

This is the Account number and Loan ID the SOAP call attempted to post to.

<dto:RecipientAccountNumber>0009999999</dto:RecipientAccountNumber>
<dto:RecipientId>0000</dto:RecipientId>   

If an invalid share is used to make the Credit Card payment, the server will reply with the provided error.

This can be due to some typo.

Request the Credit Union to provide the transaction message that failed and the member account and Symitar Support can check and see if the share used exists or not.

The full request/response messages for the failed transactions would also need to be provided for further research.

13031 - Cannot use newloan for a loan with a balance

The requested transaction was invalid for the share or loan type (for example, a share withdrawal was requested for a loan, a new loan was requested for a loan that had already been financed, etc.).

Example request:

TR~11111~A20XXX~BMERIDIANLINK~DCARD~F20XXXXXXXXXXXXX~JTRCODE=LN~JTRFMID=0009~JTRFMTYPE=1~JTRDISB=C~JTRAMOUNT=3922295~JTRGLCODE=10~JTRSEQUENCE~JTRCOMMENT=GL 305.00

Example response:

RSTR~11111~K13031:CANNOT USE NEWLOAN FOR A LOAN WITH A BALANCE

Resolution:

LN cannot be used if it checks off one of the following scenarios:

• The loan has a balance
• Something in unpaid interest 
• Open date is not equal to the SYM date

13032 - This service is not available

The 13032 (This Service Is Not Available) error occurs when a Service code necessary to complete a Transfer, Withdrawal or Deposit/Payment through SymXchange is not present in the share or loan record.

In SymXchange, Service codes are used to authorize certain activities at the Share and Loan level.

There are two places that this operation will need to be allowed.

The first is in the SymXchange Client Parameters.

Make sure that value(s) are set in the following fields:

• Services for Transfer In               
• Services for Transfer Out            
• Services for Withdrawal             
• Services for Deposit                     

For example:

• Services for Transfer In: 1,2,3
• Services for Transfer Out: 2,3
• Services for Withdrawal: 3
• Services for Deposit: 1,2,3

The second place that needs to be reviewed is the Share or Loan records involved in the transaction.

Make sure that the Service 1-8 fields have a Service code that authorizes the operation you are trying to complete.

• Service 1:                                       
• Service 2:                                       
• Service 3:                                       
• Service 4:                                       
• Service 5:                                       
• Service 6:                                       
• Service 7:                                       
• Service 8:                                       

NOTE: The eight fields are treated as a list, thus it makes no difference which field of the eight fields a value is in.

For example, based on the parameter settings in the example above, if the member should be able to perform a withdrawal, then a Service code of 3 should exist in one of the Service code fields.

If any changes are made to the SymXchange client parameters a Refresh will need to be performed from device control before the changes take effect.

Error 13036 - ’transaction amount is too small’

Possible cause: If the transaction is more than the Share Minimum Withdrawal OR the amount is less than the Loan Late Charge Due + $0.01, the error 13036 the transaction amount is too small will be returned.

13044 - No Partial Payment

The transaction amount is less than the full amount of a payment, and partial payments are not allowed for the specified loan ID.

Accept Loan Threshold Payment SymConnect / SymXchange parameter set to Yes?

NOTE:​​​​​​​ Once a loan with Interest Type 1 or 8 is one day past due, the member will not be able to make anything except the exact payment through SymConnect and SymXchange.

13302 - Invalid GL Account

An invalid user-defined GL account is used. The GL account for SymXchange should be 14 digits, with no punctuation.

GL Account Number Format

Each GL account has a unique six-digit account number, and may have a four-digit GL account suffix to further identify the account, and a four-digit GL account branch (for use with branch accounting). The format for a GL account number that has all of these elements is shown below.

13305 - An Invalid Transaction Effective Date was Specified

Members are experiencing issues when creating future dated loan payments in online banking using the loan payments form.

f234b533f238~A11308~BQ2~DCARD~F50500000051491~JTRCODE=XF~JTRFMACCT=0000051491~JTRFMID=20~JTRFMTYPE=S~JTRTOACCT=0000051491~JTRTOID=27~JTRTOTYPE=L~JTRAMOUNT=14308~JTRCOMMENTCODE=~JTRCOMMENT=Regular Payment~JTRPAYMENTTYPE=0~JTREFFECTDATE=09/14/2023

2023-09-14 08:02:48.0302    DEBUG   SendMessage:Adapter3 - Unique ID:963cdb86-48c0-4777-8dd0-f234b533f238, Request:TR~963cdb86-48c0-4777-8dd0-f234b533f238~A11308~BQ2~DCARD~F50500000051491~JTRCODE=XF~JTRFMACCT=0000051491~JTRFMID=20~JTRFMTYPE=S~JTRTOACCT=0000051491~JTRTOID=27~JTRTOTYPE=L~JTRAMOUNT=14308~JTRCOMMENTCODE=~JTRCOMMENT=Regular Payment~JTRPAYMENTTYPE=0~JTREFFECTDATE=09/14/2023 

2023-09-14 08:02:48.0302    DEBUG   Is socket pool null? False

2023-09-14 08:02:48.0927    DEBUG   SendMessage:Adapter3 - Response received:RSTR~963cdb86-48c0-4777-8dd0-f234b533f238~K13305:An invalid transaction effective date was specified

Have the vendor correct the format to use standard date format, which should be JTREFFECTDATE=20220422.

100005 - A new account number to create could not be found

Confirm that the following Miscellaneous Parameters settings are correct regarding the account number:

Next Account Number

In Miscellaneous Parameters > “Next Account Number”, choose one of the following:

• Enter 0 for Symitar to not assign new account numbers 

• If Symitar should assign new account numbers, enter the beginning account number (1-9999999999). Symitar starts automatic account numbering with this number, which appears as the default account number when creating the first new account. 

For example, if 6000 is entered for this parameter, Symitar assigns default account number 0000006000 to the first new account created. 

After the first new account is created, Symitar adds the “Next Account Step” increment to determine the next new account number, which then appears as the default account number during account creation. If this account number is already being used, Symitar tries to find the next available account number by incrementing this parameter using the “Next Account Step” parameter and provides the proper default. If this account number is already being used, Symitar tries again for up to 100 account numbers and again displays a default. Symitar continues to do this until an acceptable account number is found or the user escapes out of the file maintenance.

If this parameter is set and then an account is created, Symitar uses the value in the parameter for the account number. When the parameter is viewed after Symitar creates the first account, Symitar does not update the parameter with the next available account number. When a second new account is created, Symitar assigns the next account number and then updates the parameter with that value.  

Important: If account numbers are assigned automatically, and if the RECOVER command is used, remember to reset the “Next Account Number” parameter manually. The RECOVER command returns the setting to its original value as of the last backup. This is also true of document numbers assigned with the Document Number (DN) teller transaction.

Next Account Step

In Miscellaneous Parameters > “Next Account Step”, choose one of the following:

• Enter 0 for Symitar to not assign account numbers.  

• If Symitar should assign new account numbers, enter the increment for new account numbers (1-9999). Symitar adds this increment to the Next Account Number up to 100 times to determine the next default account number to appear when a new account is created.

For example, suppose the “Next Account Number” is 1000 and the “Next Account Step” is 10. Symitar first attempts to create an Account record with account number 1000. If that record is already in use, Symitar next tries 1010, then 1020, etc., until it finds an account number that is not in use or it has exhausted the 100 attempts. 

Symitar automatically updates the “Next Account Number” parameter whenever an account is created successfully with an account number that is within 100 “steps” of the current value of the parameter. The “Next Account Step” parameter must be non-zero for this to work, and the account number must fall exactly on a “step”. For example, if the “Next Account Number” parameter is set to 1000 and the “Next Account Step” is set to 10, the “Next Account Number” parameter is not updated if account number 1052 is created (since it does not fall exactly on a “step”), but is updated (incremented by the step value of 10 to a value of 1060) if account number 1050 is created.

If those are correct then verify the next account number first new account is not already used, above example 6000.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:acc="http://www.symxchange.generated.symitar.com/account" xmlns:tns="http://www.symxchange.generated.symitar.com/common/dto/common">
  <soapenv:Header/>
  <soapenv:Body>
     <acc:createAccount>
        <!--Optional:-->
        <Request MessageId="Test">
           <!--Optional:-->
           <AccountCreatableFields>
              <!--Optional:-->  
              <Branch>101</Branch>
              <Type>1</Type>
              <!--Optional:-->
           </AccountCreatableFields>
           <!--Optional:-->
           <NameCreatableFields>
              <!--Optional:-->
              <First>Test</First>                                       
          </NameCreatableFields>
           <!--Optional:-->
           <!--Optional:-->
           <Credentials >
              <!--You have a CHOICE of the next 3 items at this level-->
              <!--Optional:-->
              <AdministrativeCredentials>
                 <!--Optional:-->
                 <Password>Hr#j9ZZN</Password>
              </AdministrativeCredentials>
              <!--Optional:-->
           </Credentials>
           <!--Optional:-->
           <DeviceInformation DeviceType="TESTSYMX101" DeviceNumber="20048"/>
        </Request>
     </acc:createAccount>
  </soapenv:Body>
</soapenv:Envelope>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
     <soap:Fault>
        <faultcode>soap:Client</faultcode>
        <faultstring>[MessageId=Test]  Error creating the Account record: Failed to create record type Account - A new account number to create could not be found.</faultstring>
        <detail>
           <ErrorCode>100.100005</ErrorCode>
           <ProposedSolution>Please try your request again. If it happens again, please record all information specific to the request and send it to the proper application support avenues.</ProposedSolution>
        </detail>
     </soap:Fault>
  </soap:Body>
</soap:Envelope>  

100005 - An invalid record path was specified

[MessageId=b524532f-dccb-9bec-919c-80e7ffddb9b8]  Error creating the LoanTransfer record: Failed to create record type LoanTransfer - An invalid record path was specified.
</faultstring>
<detail>
  <ErrorCode>100.100005</ErrorCode>

Why can’t the member schedule an external FI transfer from an account other than their login through Banno?

A Preference Access record will need to be created with the Access Type field set to Alternate Account, the ID Type field set to Unrestricted, and the Enable FM field set to FM Allowed.

Source Account:

• Preference Access:
• Access Type: Alternate Account
• Account Number:
• ID Type: Unspecified
• Enable Withdrawals: Withdrawals Allowed
• Enable Deposits: Deposits Allowed
• Enable Inquiries: Inquiries Allowed
• Enable FM: FM Allowed

Note: These settings are not automatically set or maintained by Banno, so it is the credit union’s responsibility to set these values on members’ accounts.

Error: 100.100005 - Error creating the ShareName record: Failed to create record type ShareName - An invalid record path was specified.

<soapenv:Envelope
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:acc="http://www.symxchange.generated.symitar.com/account"
 xmlns:tns="http://www.symxchange.generated.symitar.com/common/dto/common"
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">  
    <soapenv:Header/>  
    <soapenv:Body>  
        <acc:createShareName>  
            <Request MessageId="iQ.createShareName.70aec2e9-df96-43c3-82f9-79268f5995cc">  
                <ShareNameCreatableFields>  
                    <AddressType>0</AddressType>  
                    <BeneficiaryPercent>0</BeneficiaryPercent>  
                    <BirthDate>1979-08-10</BirthDate>  
                    <City>WOODLAND</City>  
                    <DbaNameFormat>0</DbaNameFormat>  
                    <EmployerName>MINIT MART MANAGEMENT</EmployerName>  
                    <First>BOBBI JO</First>  
                    <HomePhone>360-931-0766</HomePhone>  
                    <IdentIdDescription>  
                        <EntryId>1</EntryId>  
                        <IdentIdDescription>WA</IdentIdDescription>  
                    </IdentIdDescription>  
                    <IdentIdExpireDate>  
                        <EntryId>1</EntryId>  
                        <IdentIdExpireDate>2013-08-10</IdentIdExpireDate>  
                    </IdentIdExpireDate>  
                    <IdentIdIssueDate>  
                        <EntryId>1</EntryId>  
                        <IdentIdIssueDate>2008-08-08</IdentIdIssueDate>  
                    </IdentIdIssueDate>  
                    <IdentIdNumber>  
                        <EntryId>1</EntryId>  
                        <IdentIdNumber>JOHNSBJ215NS</IdentIdNumber>  
                    </IdentIdNumber>  
                    <IdentIdType>  
                        <EntryId>1</EntryId>  
                        <IdentIdType>2</IdentIdType>  
                    </IdentIdType>  
                    <IdentIdVerifyDate>  
                        <EntryId>1</EntryId>  
                        <IdentIdVerifyDate>2008-08-08</IdentIdVerifyDate>  
                    </IdentIdVerifyDate>  
                    <Last>JOHNSON</Last>  
                    <MailOverride>0</MailOverride>  
                    <MobilePhone>360-931-0766</MobilePhone>  
                    <NameFormat>0</NameFormat>  
                    <Ssn>****</Ssn>  
                    <SsnOverride>0</SsnOverride>  
                    <SsnType>0</SsnType>  
                    <State>WA</State>  
                    <Street>40202 NW 9TH AVE</Street>  
                    <Type>9</Type>  
                    <ZipCode>98674-3101</ZipCode>  
                </ShareNameCreatableFields>  
                <AccountNumber>****</AccountNumber>  
                <ShareId>21</ShareId>  
                <Credentials tns:ProcessorUser="0">  
                    <AdministrativeCredentials>  
                        <Password>****</Password>  
                    </AdministrativeCredentials>  
                </Credentials>  
                <DeviceInformation DeviceNumber="0" DeviceType="SYMX122DEV"/>  
            </Request>  
        </acc:createShareName>  
    </soapenv:Body>  
</soapenv:Envelope>  

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">  
    <soap:Body>  
        <soap:Fault>  
            <faultcode>soap:Client</faultcode>  
            <faultstring>[MessageId=iQ.createShareName.70aec2e9-df96-43c3-82f9-79268f5995cc] Error creating the ShareName record: Failed to create record type ShareName - An invalid record path was specified.</faultstring>  
            <detail>  
                <ErrorCode>100.100005</ErrorCode>  
                <ProposedSolution>Please try your request again. If it happens again, please record all information specific to the request and send it to the proper application support avenues.</ProposedSolution>  
            </detail>  
        </soap:Fault>  
    </soap:Body>  
</soap:Envelope>  

<soapenv:Envelope
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:acc="http://www.symxchange.generated.symitar.com/account"
 xmlns:tns="http://www.symxchange.generated.symitar.com/common/dto/common"
 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">  
    <soapenv:Header/>  
    <soapenv:Body>  
        <acc:createShareName>  
            <Request MessageId="iQ.createShareName.8ba4ccfe-4e57-4044-9950-ef32225f34fb">  
                <ShareNameCreatableFields>  
                    <AddressType>0</AddressType>  
                    <BeneficiaryPercent>0</BeneficiaryPercent>  
                    <BirthDate>1968-02-05</BirthDate>  
                    <City>VANCOUVER</City>  
                    <DbaNameFormat>0</DbaNameFormat>  
                    <ExtraAddress>SUITE A</ExtraAddress>  
                    <First>STEVEN</First>  
                    <IdentIdType>  
                        <EntryId>1</EntryId>  
                        <IdentIdType>2</IdentIdType>  
                    </IdentIdType>  
                    <Last>LARSON</Last>  
                    <MailOverride>0</MailOverride>  
                    <Middle>D</Middle>  
                    <NameFormat>0</NameFormat>  
                    <Ssn>****</Ssn>  
                    <SsnOverride>0</SsnOverride>  
                    <SsnType>0</SsnType>  
                    <State>WA</State>  
                    <Street>7107 NE VANCOUVER MALL DR</Street>  
                    <Type>9</Type>  
                    <ZipCode>98661-8178</ZipCode>  
                </ShareNameCreatableFields>  
                <AccountNumber>****</AccountNumber>  
                <ShareId>21</ShareId>  
                <Credentials tns:ProcessorUser="0">  
                    <AdministrativeCredentials>  
                        <Password>****</Password>  
                    </AdministrativeCredentials>  
                </Credentials>  
                <DeviceInformation DeviceNumber="0" DeviceType="SYMX122DEV"/>  
            </Request>  
        </acc:createShareName>  
    </soapenv:Body>  
</soapenv:Envelope>  

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">  
    <soap:Body>  
        <soap:Fault>  
        <faultcode>soap:Client</faultcode>  
        <faultstring>[MessageId=iQ.createShareName.8ba4ccfe-4e57-4044-9950-ef32225f34fb] Error creating the ShareName record: Failed to create record type ShareName - An invalid record path was specified.</faultstring>  
        <detail>  
            <ErrorCode>100.100005</ErrorCode>  
            <ProposedSolution>Please try your request again. If it happens again, please record all information specific to the request and send it to the proper application support avenues.</ProposedSolution>  
        </detail>  
        </soap:Fault>  
    </soap:Body>  
</soap:Envelope>

This error occurs if the Share creation is performed while the Credit Union is in Memo Mode.

100005 - Error creating the Card record

Failed to create record type Card - Unable to generate new card number. 

If the Card Creation Wizard Parameters have been setup, enter NEXT instead of a card number in this field. Symitar generates a new card number based on the Card Creation Wizard Parameters for the card type.

If NEXT is entered for a card type that is not defined in the Card Creation Wizard Parameters, Symitar sets the card number to a blank value.

MessageId="GROMessage">

<CardCreatableFields>
  <ChkId>74</ChkId>
  <CreatedAtBranch>31</CreatedAtBranch>
  <Description>DEBIT CARD</Description>
  <EffectiveDate>2022-05-19</EffectiveDate>
  <InstantIssue>0</InstantIssue>
  <IssueCode>0</IssueCode>
  <IssueDate>2022-05-19</IssueDate>
  <NameType>0</NameType>
  <Number>NEXT</Number>
  <ReissueCode>1</ReissueCode>
  <ReissueMonths>36</ReissueMonths>
  <Status>0</Status>
  <StatusReason>0</StatusReason>
  <Type>15</Type>

Received response 
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Client</faultcode>
      <faultstring>[MessageId=GROMessage]  Error creating the Card record: Failed to create record type Card - Unable to generate new card number. </faultstring>
      <detail>
        <ErrorCode>100.100005</ErrorCode>
        <ProposedSolution>Please try your request again. If it happens again, please record all information specific to the request and send it to the proper application support avenues.</ProposedSolution>
      </detail>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>] for request <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header/><SOAP-ENV:Body><ns4:createCard xmlns:ns4="http://www.symxchange.generated.symitar.com/account" xmlns:ns3="http://www.symxchange.generated.symitar.com/common/dto/common" xmlns=""><Request 

100005 - Error creating the LoanTransfer record

Check that the access record is set to allow transfer.

   <tns2:createLoanTransfer>
     <Request MessageId="b524532f-dccb-9bec-919c-80e7ffddb9b8" tns2:BranchId="0">
       <LoanTransferCreatableFields>
         <AccountNumber>20605</AccountNumber>
         <Amount>300.00</Amount>
         <Day1>1</Day1>  
         <Day2>0</Day2>
         <EffectiveDate>2022-08-01</EffectiveDate>
         <Frequency>4</Frequency>  
         <Id>0009</Id>  
         <IdType>0</IdType>
         <NextDate>2022-08-01</NextDate>
         <PaymentType>0</PaymentType>
         <RegE>1</RegE>
         <Type>9</Type>
       </LoanTransferCreatableFields>
       <AccountNumber>28857</AccountNumber>
       <LoanId>0039</LoanId>  
       <Credentials>
         <HomeBankingCredentials>
           <UserName>M166429</UserName>
           <Password>XXX</Password>
         </HomeBankingCredentials>
       </Credentials>
       <DeviceInformation DeviceType="BANNO" DeviceNumber="20749"/>
     </Request>
   </tns2:createLoanTransfer>

<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/>
 <soap:Body>
   <soap:Fault>
     <faultcode>soap:Client</faultcode>
     <faultstring>
       [MessageId=b524532f-dccb-9bec-919c-80e7ffddb9b8]  Error creating the LoanTransfer record: Failed to create record type LoanTransfer - An invalid record path was specified.
     </faultstring>
     <detail>
       <ErrorCode>100.100005</ErrorCode>
       <ProposedSolution>
         Please try your request again. If it happens again, please record all information specific to the request and send it to the proper application support avenues. 

Error - Address already in use

This error means another PID is already using that port number. A lot of times clients will run a backup to a sym that wipes out an instance, but it keeps that port since it was not uninstalled correctly. 

Log example:

2021-03-19 12:51:02,452 [symXchange] ERROR com.symitar.symxchange.mainline.StartupOrchestrator - BeanCreationException: Address already in use

In this example we will use port 65201. There are variations on the commands, but I will run the following:

1. netstat -Ana|grep LISTEN|grep 65201                          

f1000e00157893b8 tcp        0      0  *.65201               *.*               

2. rmsock f1000e00157893b8 tcpcb                                  

The socket 0xf1000e0015789008 is being held by proccess 52560048 (symXchange).

3. USERS 52560048

SYM020 52560048 65339442   0   Jan 25      - 22:32 /SYM/SYMPR/symXchange -SYM=

SYM020 -instanceName=BILLINGTREETest                                          

NOTE: It is currently being used by sym 20 BILLINGTREETest

4. Stop or restart SYMX in SYM20 BILLINGTREETest

NOTE: If the instance does not show on the restart list, just kill the PID since it no longer exists. 

5. kill -9  52560048

General Ledger (GL)

How do I configure GL Category

GL Category is used to add a specific comment when a GL transaction is posted.  The GL Category can store up to a 40 character value.  It applies to all transaction posted through the SymConnect or SymXchange client that it is configured on.​

Setup is relatively simple with updating two parameters in Parameter Manager and refreshing SymConnect/SymXchange.

1. Navigate to Parameter Manager > GL Category Parameter.
2. Set the description in the desired GL Category in the GL Category parameters.
3. Add the GL Category that was defined to the SymXchange/SymConnect Client Parameters (GL Category field).
4. Refresh SymXchange or SymConnect from Device Control for the setting to take effect.

NOTE: This GL Category will be used for all monetary transactions performed through the SymXchange Client parameters.

Can I specify a GL Comment through SymXchange?

There is no way through SymXchange to specify a GL comment on any of the transactions except glToGlPost.

Options are:

• ​If a user defined GL code is used and set to “Detail” in the translation table, the reference field will be populated with the Account number from the transaction. This is usually sufficient for the Credit Union.​​
• Have the transaction broken into 2 parts. Perform the transaction and credit or debit a clearing GL, then perform a glToGlPost from the clearing GL to the GL the funds should be in, specifying a GL comment.

Interactive Teller Machine (ITM)

Personal Teller Machine (PTM) and Interactive Teller Machine (ITM) are devices that allow the credit union’s tellers to interact with the member from a call center using a screen,similar to video chats (Skype and FaceTime). 

The teller can be servicing members at multiple different branches in the same day and is not limited to one machine. The machine itself acts like an ATM, both accepting and dispensing cash, in addition to handling checks. 

Currently all PTM/ITM interfaces with Symitar is done through SymConnect/SymXchange or manually. 

Why can’t we use System GL Code 60 (Cash Received)?

System GL Code 60 is only really used for tellers who have a unique cash drawer. With these machines, the tellers are utilizing the cash in the devices to dispense and take cash, this device can change after every interaction the teller has with the machine. 

That means one user could be transacting on multiple machines at multiple branches in a single day. 

How does it work with SymConnect/SymXchange?

In the past, we have setup one general ledger at each branch for all the machines across the institution. This general ledger is tied to a User GL Code which is placed in the SymConnect/SymXchange code. 

All cash transactions for a particular branch will flow into that one general ledger. SymXchange can send a different branch depending on the machine in the transaction string. 

How do they balance at the end of the day?

While the specific of how the credit union balances at the end of the day is really up to the credit union, the basics are just comparing the total amount in the general ledger to the reports produces from the PTMs and ITMs. The reports produced by the machines will have teller user breakdown, which the credit union can compare to the total showing in the general ledger. 

Note: There is no way to see user breakdown on the Symitar general ledger, remember that currently SymConnect/SymXchange would all post with a reserved user number in the 800s.  

Currency Transaction Report (CTR) and ITMs/PTMs

The CTR Processing Batch Program and Cash reports only looks for cash transactions in certain System Defined GL Codes. 

• For SymConnect: System Defined GL Codes 56 
• For SymXchange: System Defined GL Codes 98 

This issue has been brought up by several other clients and Product Development is aware that changes are needed. 

In the interim, If these transactions need to be reflected in these system reports then make sure all cash transactions performed through SymConnect and SymXchange use these GL Codes.  

To achieve this, set the GL Code field in the SymConnect/SymXchange Client Specific Parameter to 0 and make sure vendors re not passing a GL Code in the transaction request.  Also make sure that the right GL Account(s) translated in the GL Translation table for System Defined GL Code 56 or 98.

Using the System Defined GL codes is very limiting as to how these transactions can be translated. Translation cannot occur by user number or leverage GL account branch accounts.  

An alternative to using the System Defined GL codes would be to use a PowerOn specfile to supplement the cash reporting.  Use RB.CORP.INTRADAYGLBALANCE as an example 

NOTE: If using SymXchange and want the US Cash Disb Amount and US Cash Rcvd Amount (required for eCTR to detect these transaction at the Teller line) updated in the Account record make sure the vendor is setting the PureUSCash field to “true” in the request.  

In 2022.01 a new Miscellaneous Parameter was added to provide more flexibility for which GL codes can be used.

Support User-Defined GL Codes for CTR and Excessive Cash Reporting

The Cash Reporting User-Defined GL Codes Miscellaneous Parameter was created to allow credit unions to add user-defined GL codes for certain cash handling devices, such as NEXT kiosks, to the list of GLs that are currently used for CTR processing, CTR reporting, and excessive cash reporting.

The Cash Reporting User-Defined GL Codes section in Miscellaneous Parameters contains the Cash Reporting User-Defined GL Codes parameter which lists GL codes for cash transactions that do not post to the system-defined GLs. Additionally, it contains the Add GL Codes for Cash Rpt and Remove GL Codes for Cash Rpt parameters which are used to add GL codes to, or remove them from, the list. The Cash Reporting User-Defined GL Codes parameter defaults to NONE until GL codes have been added.

Both the CTR Processing batch program and the Close Day Processing batch program for the Excessive Cash Report will include the user-defined GL codes listed in the new Cash Reporting User-Defined GL Codes section of Miscellaneous Parameters.

GL codes entered in this parameter should be defined in the GL Translation Table Parameters and should only be used for cash transactions. This parameter, the CTR Processing batch program, and the Close Day Processing batch program will not validate that the GL code has been defined or translated.

The origin assigned to a user-defined GL code for transactions not performed via Teller Transactions (not including via ATM, Point of Sale, Miscellaneous Posting, Shared Branching, SymConnect, or SymXchange) is GLU: General Ledger User-defined code. Affected reports include:

• CTR Transaction Detail – Incomplete
• CTR Transaction Detail – Exempt
• Excessive Cash: Amounts over $10,000

A PowerOn cannot be used to perform file maintenance on this parameter, but it can be used to read the information for generating reports.

If any changes are made to the SymConnect or SymXchange client parameters, a Refresh of SymXchange or SymConnect will need to be performed from device control before the changes take effect.

Loans

Loan Due Date and Payment Calculation

When the vendor creates Loans through SymXchange or SymConnect, the values from Loan Defaults are used unless there is instruction in the creation to change them.

If the Loans are created with a New Loan Due Date Code of – One Period, when an advance (LN) is completed for the Loan, the system will default the First Payment Due Date to one period from the system date to the Due Day 1 day.

(0) No Change

Symitar Quest should not update the Due Date field. The Due Date field remains the same as it was before the add-on. Use this option for loans with the Loan Code field value set to (0) Closed End and for loans with the Interest Type field value set to (1) Monthly 360 day.

Important: Do not use this option in this field for a SymChoice Loan. This option can cause a SymChoice Loan to become delinquent if an advance is taken when the loan balance is zero.

(1) One Period

Symitar Quest should advance the due date by one period from the date of the add-on. If a value in the Due Day 1 field, Symitar Quest advances the Due Date field to that date. The period is determined by the value in the Payment Frequency field.

Very similar for payment calculations that may differ from the vendor calculation and what is calculated by Symitar when the loan is added. Symitar will calculate the loan payments based off the Symitar loan payment calculation formula to pay off the loan over the term, and not take the default of what the vendor calculated and sent.

newLoan Multiple Disbursal

Some vendors are performing an initial newLoan request to a holding GL and then performing a glToGlPost to create checks for subsequent disbursals. If the vendor trys to create checks with this call, there is no way for the Credit Union to find the check, since there is no account info in the check.

A workaround for this is to perform the initial newLoan, then the vendor can create the checks using the Check Service. Below is a sample request and reply:

<soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ xmlns:chec=http://www.symxchange.generated.symitar.com/check xmlns:tns=http://www.symxchange.generated.symitar.com/common/dto/common>  
   <soapenv:Header/>  
   <soapenv:Body>  
      <chec:createCheck>  
         <!--Optional:-->  
         <Request MessageId="?" chec:BranchId="0">  
            <!--Optional:-->  
            <CheckCreatableFields>  
               <!--Optional:-->                
               <AccountCode>00</AccountCode>  
               <AccountNumber>0000017111</AccountNumber>  
               <!--Optional:-->  
               <Amount>123</Amount>  
               <!--Optional:-->  
               <Branch>0</Branch>  
               <!--Optional:-->           
               <Id>01</Id>  
               <!--Optional:-->  
               <IdType>0</IdType>  
               <!--Optional:-->  
               <Number>0000001234</Number>             
               <Status>1</Status>  
            </CheckCreatableFields>  
            <!--Optional:-->  
            <Credentials tns:ProcessorUser="0">  
               <!--You have a CHOICE of the next 3 items at this level-->  
               <!--Optional:-->  
               <AdministrativeCredentials>  
                  <!--Optional:-->  
                  <Password>will</Password>  
               </AdministrativeCredentials>  
            </Credentials>  
            <!--Optional:-->  
            <DeviceInformation DeviceType="will" DeviceNumber="20205"/>  
         </Request>  
      </chec:createCheck>  
   </soapenv:Body>  
</soapenv:Envelope>

<soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/>  
   <soap:Body>  
      <tns:createCheckResponse xmlns:common=http://www.symxchange.generated.symitar.com/common/dto/common xmlns:tns=http://www.symxchange.generated.symitar.com/check xmlns:create=http://www.symxchange.generated.symitar.com/check/dto/create xmlns:retrieve=http://www.symxchange.generated.symitar.com/check/dto/retrieve xmlns:update=http://www.symxchange.generated.symitar.com/check/dto/update>  
         <CreateResponse MessageId="?">  
            <CheckCompositeKey>  
               <CheckGlobalSequenceDate>2026-01-01</CheckGlobalSequenceDate>  
               <CheckGlobalSequence>145</CheckGlobalSequence>  
            </CheckCompositeKey>  
         </CreateResponse>  
      </tns:createCheckResponse>  
   </soap:Body>  
</soap:Envelope>  

PowerOns

Using redentials When Executing a PowerOn

If a PowerOn targets an Account, the credentials used in the SymXchange call also need to target an account.

If they do not, the PowerOn will not target the correct account.

For example, if the Admin credentials are used, SymXchange will have the PowerOn target whatever account it has in memory. This is never the desired results.

Specify the Account in SymXchange PowerOns

SymXchange PowerOns aren’t “on” an account when they are initiated, so the account number must be provided as a variable, and the PowerOn will need to read that account. If this is not done, then nothing will be returned for requested fields.

This is different behavior than with most SymConnect repgens. An RG message will be on an account when it is processed, so that account will be read in automatically. (SymConnect AD messages that run a PowerOn are not on an account, and would need to specifically read in the account, similar to SymXchange.)

SymConnect PowerOns can be run by SymXchange, but they may need to be modified to achieve equivalent results.

SpecFiles

Stateless Specfile Discussion

The STATELESS keyword deals with the initialization of variables, so that the results of one run would not affect the next. For this purpose, it does not matter if the specfiles are set to Shared or Individual in the parameters.

This means that when the PowerOn is run, you are not depending on some value that was previously set when the PowerOn was executed. Without STATELESS, variables will not be initialized. Individual vs. Shared just controls how memory is used. With Shared, PowerOn executions that span multiple posters share the actual memory space for variables. Additionally, because memory is shared, the locking mechanism is active so that two posters cannot simultaneous access/change variables. Individual means each poster has its own memory space and it follows that multiple posters can simultaneously execute the same PowerOns (since there is no danger of memory collisions). The Shared load method preserves memory so it is best to use when you don’t expect the locking mechanism to cause problems.

Individual vs shared affects blocking (and where it is loaded, individual specfiles are loaded on the stack of the poster instead of the shared memory for all posters, which is why there is a limit of 40 Individual specfiles).

1. If the STATELESS keyword is found in a PowerOn, all the defined variables will be initialized each time it is run. This is the only thing that happens when a PowerOn is tagged as being STATELESS.
2. In SymConnect Common Parameters, if the Specfile Load Method is set to “Individual” it can be run in parallel across multiple posters and will not be subject to the blocking mechanism (i.e. the same PowerOn can be running simultaneously across multiple posters).
3. In SymConnect Common Parameters, if the Specfile Load Method is set to “Shared”, old functionality will be retained. The shared memory mechanism will remain in effect and PowerOn blocking will happen if different posters try to run the same PowerOn at the same time.

If a repgen is “state-full” and the STATELESS keyword is added, there is potential for that to cause problems. This is why we tell credit unions/vendors that a specfile should be reviewed by their programmers prior to adding the STATELESS keyword.

• STATELESS and Shared: State information would need to be maintained using a method not dependent on PowerOn defined variables. Locking mechanism would be in effect. Not suitable for a “state-full” setup that depends on defined PowerOn variables.

• STATELESS and Individual: State information would need to be maintained using a method not dependent on PowerOn defined variables. Locking mechanism would NOT be in effect. Not suitable for a “state-full” setup that depends on defined PowerOn variables.

• Not STATELESS and Shared: State information could be maintained in defined PowerOn variables. Locking mechanism would be in effect. Since memory is shared, state information must somehow be segregated from session to session (by user). For example, by using the method by which each session (user) has a different slot in an array.

• Not STATELESS and Individual: Not recommended when state information is stored in PowerOn variables – since different posters will have separate memory (and there is no guarantee that the same poster will be used for the entirety of a session). Locking mechanism would NOT be in effect.

Transactions

Configuring a User Defined Transaction Source Code

To change the transaction description on these transactions, two parameter changes are needed in Symitar to create a custom source code.​​

1. Select the Transaction Source code in SymConnect/SymXchange Client Parameters

​(0-9) User-Defined Source Codes

2. Statement Generation

The new Transaction Source Code Descriptions must be defined in the Statement Generation batch prompts. If they are not pre-defined, the source description of the transaction will not be displayed in transaction history and on standard notices. This does not mean the statements must be produced, just that the description for the new Transaction Source Codes should be defined.

1. Log on to the live SYM to set the Statement Generation Transaction Source Code Descriptions.

2. Click the Batch Control icon on the toolbar or go to Navigate > Information Systems Batch Control.

3. From the Program drop-down menu, select Statement Generation.

4. At the Modify Statement Parameters prompt, select Yes and click the Next button.

5. Click through the prompts. Upon reaching the Modify Statement Descriptions prompt, select Yes and click the Next button.

6. Click through the prompts. Upon reaching the User-Defined Source Code 0 – User-Defined Source Code 9 prompts, enter the specific description associated with the user-defined Transaction Source Codes. If no description is to be added, leave the UserDef SourceCode fields blank.

7. Click OK to save your changes.

Note: For the changes to become effective, run the Statement Generation Batch Program to ensure that the newly added SymConnect Transaction Source Code description is applied accordingly. This will affect all history following the completion of these steps.

Optimize Transaction Queries’

When searching for a transaction with a specific date range or transaction amount the search will continue processing until the maximum number of records for the response have been found or the end of the records is reached. This is will perform poorly if the number of matching records is low and the number of overall records is high. The maximum number of records can be adjusted by the “Maximum Search Response List Count” setting for the SymXchange instance. The default value is 1000. The setting is accessible via web console.

If the transaction search is placed into a separate request then one of the operations that support paging can be used, such as searchShareTransactionPagedSelectFields. These operations allow “paging” through the records by an amount set in the request. Once an entire “page” is filled if there are more records to be read the response will include a token that can be used to resume reading at the next record.

If the goal is to retrieve the transactions based on date, especially something like the transactions for the last week or month, it will likely be better to use the standard paged operation without search. E.g. getShareTransactionPagedListSelectFields rather than searchShareTransactionSelectFields / searchShareTransactionPagedSelectFields. The transactions are returned in the reverse of the order they were posted, newest to oldest, and this can be used to avoid searching all transactions. The best performance will likely be achieved by setting the page size such that a single request is generally sufficient and multiple pages can be requested for unusually large responses.

For a date range using the starting date without the end date will ensure that enough records are found to fill the page. If the end date is used and the number of records in the date range is less than a single page then the search will continue to looking through the records to find matches in order to fill the page.

If the request is expected to have a single match, such as a check number or a date and sequence number, then the page size can be set to one to avoid attempting to read additional records.

Searching for newer records will be faster than older records due to the way they are ordered.

Some searches will need to read all records and these may be slow due to the number of records being searched. The performance in these cases will depend on the transaction activity for the share/loan and how often transactions are purged from the system.

Transaction Continuation Flag Overview

In Symitar Transaction History there is a field that is set to indicate that a transaction is related to the previous transaction in history.  These most commonly appear on Share and Loan comment records to attach them to the monetary transaction.  This topic will most often come up for questions about how information is displayed in OLB and member statements.

For example, one could have the following (in reverse order, as one would retrieve doing consecutive IQs):

1. Comment without continuation flag
2. Comment with continuation flag
3. Comment with continuation flag
4. Monetary
5. Comment without continuation flag
6. Monetary
7. Comment with continuation flag
8. Monetary
9. Monetary

In this example:

• 7 is associated with 8
• There is no way of knowing if 5 is associated with 6
• 2 and 3 are associated with 4, there is no way of knowing about 1
• For 1 and 5, they could be manual entries that might be related to the subsequent monetary transaction, but they are not “linked” per se.

One would not see:

1. Comment with continuation flag
2. Comment without continuation flag
3. Comment with continuation flag
4. Monetary

Comments with continuation flags (where the COMMENTCODE=1 and the REGECODE=1) need to be stored until the next monetary transaction.

Standalone comment transactions will always have a COMMENTCODE=1 and REGECODE=0.

Standalone monetary transactions will always have a COMMENTCODE=0 and REGECODE=0 or 1; the reason why the REGECODE is either 0 or 1 is that not all monetary transactions are REG E.

Transaction History Sequence Number

The sequence number in transaction history is only unique within a given postdate. When the date is moved to the next date, the sequence number resets to zero.

Excerpt from searchShareTransactionSelectFields to show how this might be used:

        <SelectableFields>
            <IncludeAllShareTransactionFields>true</IncludeAllShareTransactionFields>
        </SelectableFields>
        <SearchFilter>
            <Query>
                regecode = 1 and commentcode = 1 and (
                    (sequencenumber = 483158 and PostDate = {date:'2017-11-15'}) or
                    (sequencenumber = 409349 and PostDate = {date:'2017-11-15'}) or
                    (sequencenumber = 129200 and PostDate = {date:'2017-11-15'}) or
                    (sequencenumber = 451352 and PostDate = {date:'2017-11-14'}) or
                    (sequencenumber = 370664 and PostDate = {date:'2017-11-14'}) or
                    (sequencenumber = 291428 and PostDate = {date:'2017-11-14'}) or
                    (sequencenumber = 8714   and PostDate = {date:'2017-11-14'}) or
                    (sequencenumber = 59921  and PostDate = {date:'2017-11-13'}) or
                    (sequencenumber = 9518   and PostDate = {date:'2017-11-13'}) or
                    (sequencenumber = 4273   and PostDate = {date:'2017-11-12'})
                )
            </Query>
        </SearchFilter>
    </Request>
</searchShareTransactionSelectFields>

Transactions Reversals Overview

The SymConnect reversal transaction (which is what SymX exposes as well) is very limited.

It posts as an adjustment, it does not void or otherwise remove the original transaction.

In transaction history, the adjustment transaction will post with the adjustment flag set to true, which can be seen in transaction history. Also the comment specified in the SymXchange/SymConnect reversal request will be attached to the adjustment transaction. Unless there is something manually added to the comment, I don’t believe that anything would associate the original transaction with the adjustment posted by the reversal transaction.

The original transaction information is used to limit the maximum amount of the adjustment. For whatever reason, this was not originally designed to be a straightforward adjustment request and must follow rules based on the “original” transaction that is being reversed.

Some rules for the transaction to be reversed:

• Cannot be for a prior posting date.
• Must be one of the five most recent transactions.
• Cannot be prior to another adjustment transaction. E.g. it’s not possible to post two reversals in a row. 
• Must have been performed using the same user number as the reversal request.
• Data from the original SymXchange/SymConnect transaction request and the reversal, like amount and source code, must match.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tran="http://www.symxchange.generated.symitar.com/v1/transactions" xmlns:com="http://www.symxchange.generated.symitar.com/v1/common/dto/common" xmlns:dto="http://www.symxchange.generated.symitar.com/v1/transactions/dto">
   <soapenv:Header/>
   <soapenv:Body>
      <tran:reverseDeposit>
         <!--Optional:-->
         <Request MessageId="123456">
            <!--Optional:-->
            <Credentials>
               <HomeBankingCredentials>
                  <!--Optional:-->
                  <UserName>DANIELTEST</UserName>
                  <!--Optional:-->
                  <Password>ABCD1234</Password>
               </HomeBankingCredentials>
            </Credentials>
            <!--Optional:-->
            <DeviceInformation DeviceType="DSCTEST" DeviceNumber="0"/>
            <!--Optional:-->
            <dto:AccountNumber>1000</dto:AccountNumber>
            <!--Optional:-->
            <dto:ShareId>10</dto:ShareId>
            <!--Optional:-->
            <DepositAmounts>
               <!--Optional:-->
               <dto:TotalAmount>250.00</dto:TotalAmount>
               <!--Optional:-->
               <CheckAmount>250.00</CheckAmount>
               <!--Optional:-->
            </DepositAmounts>
            <dto:Comment>Check Deposit Refersal</dto:Comment>
            <dto:OriginalTotalAmount>250.00</dto:OriginalTotalAmount>
            <!--Optional:-->
            <dto:OriginalConfirmation>2233003312331</dto:OriginalConfirmation>
         </Request>
      </tran:reverseDeposit>
   </soapenv:Body>
</soapenv:Envelope>​  

Transaction Source Code

In SymXchange there are two ways to set the Transaction Source code value for a transaction.

1. Specify the Source Code in the SymXchange message

Specify the Source Code in the SymXchange message, as shown here:

<dto:SourceCode>?</dto:SourceCode>

2. Specify the Source Code in the SymXchange Client Parameters

Transaction Source Code​:

• H: Home Banking
• A: ATM
• T: Telephone (Audio Response)
• S: Kiosk
• 0-9: User-Defined Source Codes

Whether the Source Code is specified in the SymXchange message or in the SymXchange Client Parameters, one can only specify the Source Codes listed as available in the SymXchange Parameters. One can try passing other Source Code values in the SymXchange message, but this can result in errors on invalid data ending up in the Transaction Record on the member’s account.

Source Codes

This field identifies the source of the transaction.

• Field Number: 022
• Mnemonic: SOURCECODE
• Data Type: 1 Character
• Source: System-defined and User-entered

Below is a list of all Transaction Source Codes from the Transaction Record. The ones that are supported by SymXchange and the ones that are optional are indicated.

Examples

This is an example of a message with an invalid Transaction Source Code:

2020-03-09 15:58:25,720 [pool-4-thread-2] WARN  performance.logger.transactions

<LOGENTRY>
  <SERVICE>transactions</SERVICE>
  <OPERATION>loanAddon</OPERATION>
  <RESPONSE_TIME_THRESHOLD>1 ms</RESPONSE_TIME_THRESHOLD>
  <TOTAL_RESPONSE_TIME>11 ms</TOTAL_RESPONSE_TIME>

<REQUEST>
  <s:Envelope
   xmlns:s="[http://schemas.xmlsoap.org/soap/envelope/](http://schemas.xmlsoap.org/soap/envelope/)">
    <s:Body
     xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance](http://www.w3.org/2001/XMLSchema-instance)"
     xmlns:xsd="[http://www.w3.org/2001/XMLSchema](http://www.w3.org/2001/XMLSchema)">
      <loanAddon xmlns="[http://www.symxchange.generated.symitar.com/v1/transactions](http://www.symxchange.generated.symitar.com/v1/transactions)">
        <Request MessageId="ea1dacfb-78d4-49a9-a7d7-47dc3b1a98c9" xmlns="">
          <Credentials>
            <AdministrativeCredentials>
              <Password>yX4gyO6ygCm7sjWxrNTI1WMYrFo2X6WC5Gtir/uWhs9vlNDne5a3yAIgIOoU36Us</Password>
            </AdministrativeCredentials>
          </Credentials>
          <DeviceInformation DeviceType="CENTRIXDTS" DeviceNumber="2"/>
          <AccountNumber xmlns="[http://www.symxchange.generated.symitar.com/v1/transactions/dto](http://www.symxchange.generated.symitar.com/v1/transactions/dto)">1058940</AccountNumber>
          <LoanId xmlns="[http://www.symxchange.generated.symitar.com/v1/transactions/dto](http://www.symxchange.generated.symitar.com/v1/transactions/dto)">31</LoanId>
          <Amounts xmlns="[http://www.symxchange.generated.symitar.com/v1/transactions/dto](http://www.symxchange.generated.symitar.com/v1/transactions/dto)">
            <TotalAmount>122.10</TotalAmount>
            <CashAmount xmlns="">122.10</CashAmount>
          </Amounts>
          <Comment xmlns="[http://www.symxchange.generated.symitar.com/v1/transactions/dto](http://www.symxchange.generated.symitar.com/v1/transactions/dto)">Provisional Credit Reversal N 4292 PIGGLY WIGGLY #266 MCCALLA AL 36</Comment>
          <CommentCode xmlns="[http://www.symxchange.generated.symitar.com/v1/transactions/dto](http://www.symxchange.generated.symitar.com/v1/transactions/dto)">0</CommentCode>
          <EffectiveDate xmlns="[http://www.symxchange.generated.symitar.com/v1/transactions/dto](http://www.symxchange.generated.symitar.com/v1/transactions/dto)">2019-11-01</EffectiveDate>
          <GLAccounts xmlns="[http://www.symxchange.generated.symitar.com/v1/transactions/dto](http://www.symxchange.generated.symitar.com/v1/transactions/dto)">
            <ClearingAccount xmlns="">87700900000000</ClearingAccount>
          </GLAccounts>
          <SourceCode xmlns="[http://www.symxchange.generated.symitar.com/v1/transactions/dto](http://www.symxchange.generated.symitar.com/v1/transactions/dto)">D</SourceCode>
        </Request>
      </loanAddon><
    /s:Body>
  </s:Envelope>
</REQUEST>

<RESPONSE>
  <soap:Envelope xmlns:soap="[http://schemas.xmlsoap.org/soap/envelope/](http://schemas.xmlsoap.org/soap/envelope/)">
    <soap:Body>
      <tns:loanAddonResponse
       xmlns:tns="[http://www.symxchange.generated.symitar.com/v1/transactions](http://www.symxchange.generated.symitar.com/v1/transactions)"
       xmlns:transactionsdto="[http://www.symxchange.generated.symitar.com/v1/transactions/dto](http://www.symxchange.generated.symitar.com/v1/transactions/dto)">
        <Response MessageId="ea1dacfb-78d4-49a9-a7d7-47dc3b1a98c9" StatusCode="13026">
          <StatusMessage>A required transaction field was missing</StatusMessage>
        </Response>
      </tns:loanAddonResponse>
    </soap:Body>
  </soap:Envelope>
</RESPONSE>

SymXchange Transaction Defaults

All functions in the Transactions service default to Check if no amount is specified:

<dto:TotalAmount>?</dto:TotalAmount>  
<CheckAmount>?</CheckAmount>  
<CashAmount PureUSCash="?">?</CashAmount>  

All transactions in SymXchange have to be either cash, check or PureUSCash.

• If CheckAmount or neither is sent, a check record will be created.
• If CashAmount is used a check record will NOT be created.

Sometimes vendors design the interface to just send the following tag:

<dto:TotalAmount>?</dto:TotalAmount>  

This creates a ton of Check records that the vendor did not intend to create.