User Support Forum

What process should be used if one person's checking account number (using the check reader as the entry point) is improperly associated with another giver's envelope number. I'm assuming that that is where the association is made.

Thanks,
Jeff

To correct, the next time you scan this persons check it will pull up the wrong person, change the envelope number to the correct person and now when you rescan the check it will have the right person associated with it.

Is there a way to just zero an account number for an individual?

Problem:

There are times when a check is mis-read by the checkreader and for some reason the PowerChurch associates the check's account with the wrong person.

This has occurred with two different checks during a single contribution entry session. Each time the mis-read check gets associated with the same person's account. These checks have been commercial in nature (refund checks, gov't checks, etc). (This is why I asked if there was a way to see and edit the checking accounts that are associated with a specific contributor.)

Is there any reason for this?

I've noticed that some checks seem to have the MICR (routing/account) numbers in a different order than a personal check. Is this possible?

I'd appreciate some insight to solving this as using the checkreader is a great time saver.

Thanks,
Jeff

Regardless of the order of the numbers on the check, the check reader interprets what number is what based on other features on the checks themselves that distinguish the number as the routing number or account number. But the check reader is always going to send the information to PowerChurch in the format routing#/account#/check#.

Currently there is no other way of dissassociating a check number from a member other then changing the envelope when the system pulls them up. The only other way would be thru the Database, and unfortunately the routing and account numbers are encrypted so there is no easy way even thru the database.

As a follow-on to this thread, would it be possible to do the following using SQL?

1. Identify the contributor (by envelope number?)
2. Using a SQL statement, pull (to view) the account number associated with a specific contributor (even if it is encrypted), just to ensure that I have the correct contributor.
3. Using a SQL statement, zero or null the appropriate field(s).
4. Pull the same data back out of the database to ensure that it is zeroed.

Make sense? Do-able?

Thanks again,
Jeff

The file involved with the check reader process is called coscan.DBF and its formatted as follows:

KEY (the routing, account, and check # encrypted), ENV_NO , LAST_CO


I am unfortunatly not familiar enough with SQL to be able to give you those commands. There are some commands you could use through the database manager. We generally don't like to publish those commands, so if it something you are not familiar with and don't already know, we would ask that you give us a call to go thru using some of those commands.

Zeb wrote:The file involved with the check reader process is called coscan.DBF and its formatted as follows:

KEY (the routing, account, and check # encrypted), ENV_NO , LAST_CO


I am unfortunatly not familiar enough with SQL to be able to give you those commands. There are some commands you could use through the database manager. We generally don't like to publish those commands, so if it something you are not familiar with and don't already know, we would ask that you give us a call to go thru using some of those commands.

Actually, all you would have to do is delete this entry from that table.

In SQL it should be sometthing to the effect of:

DELETE FROM COSCAN
WHERE KEY = (routing,account,check#)

NeilZ wrote:

Zeb wrote:The file involved with the check reader process is called coscan.DBF and its formatted as follows:

KEY (the routing, account, and check # encrypted), ENV_NO , LAST_CO


I am unfortunatly not familiar enough with SQL to be able to give you those commands. There are some commands you could use through the database manager. We generally don't like to publish those commands, so if it something you are not familiar with and don't already know, we would ask that you give us a call to go thru using some of those commands.

Actually, all you would have to do is delete this entry from that table.

In SQL it should be sometthing to the effect of:

DELETE FROM COSCAN
WHERE KEY = (routing,account,check#)

since this is an encrypted field, I am not sure how well that would work. You could say delete from coscan where env_no = <your persons envelope number>

Zeb wrote:

NeilZ wrote:

Zeb wrote:The file involved with the check reader process is called coscan.DBF and its formatted as follows:

KEY (the routing, account, and check # encrypted), ENV_NO , LAST_CO


I am unfortunatly not familiar enough with SQL to be able to give you those commands. There are some commands you could use through the database manager. We generally don't like to publish those commands, so if it something you are not familiar with and don't already know, we would ask that you give us a call to go thru using some of those commands.

Actually, all you would have to do is delete this entry from that table.

In SQL it should be sometthing to the effect of:

DELETE FROM COSCAN
WHERE KEY = (routing,account,check#)

since this is an encrypted field, I am not sure how well that would work. You could say delete from coscan where env_no = <your persons envelope number>

Yep ... you're right . I missed that encrypted in that field. Using the env_no is easier, and safer !!