ElectronicChecks Discussion Page
We invite you to discuss the content on the ElectronicChecks page. To preserve the commentary of others, please enter your comments in the next available space below. Enter a title and the body of the comment on separate lines. The code (at)SIG(at) following your comment will automatically insert your signature.
Anyone interested in contributing new content to xTupleWiki should send an email expressing their interests to wiki (at) xtuple (dot) com.
A developer's first thoughts
ACH data security?
My biggest concern reading this spec is for security of third-party bank account and routing numbers. Configuring security is a pain but we should consider it here. These data should be treated with the same respect as credit cards. The application should use the same mechanism for encryption as it already does for credit cards. There are usability and usage questions:
- Will the same end-users who need credit card usage access also need ACH access? If so then using the same encryption key file isn't a problem. If not then it would be safer to allow but not require using a different key file.
Configuration of encryption handling is a pain both internally and for the user. Should this task be moved off the Credit Card configuration window and onto a new System -> Master Information -> Encryption window? At least then the logic would be consolidated. Both Configure Accounting and Configure Credit Cards could have buttons that would bring up the Configure Encryption window.
- Should the system allow for both encrypted and unencrypted account and routing numbers?
Printing and other check data manipulation
What should happen if the user prints a check run that contains both ACH and non-ACH vendors? The spec calls for giving the user a choice whether to print checks for these vendors or not but doesn't say what happens if the user says not to. Does the application print the checks for non-ACH vendors? If so, what happens to the ACH 'checks'? Does the user have to click the PRINT button again, this time for just ACH? Do we want to support 'mixed-mode printing'? That might be more up-front work but save on support later.
Is the act of creating an entry in an ACH file equivalent to creating a physical printed check? Can the 'printed' field reasonably be overloaded to handle these two cases? A file can be edited after it's created. In a sense this is similar conceptually to 'printing' with print preview instead of to paper.
Do we need to change the concept of check posting in any way?
Limited to Vendors?
Why is the ACH implementation limited to vendors? With the current support for tax authorities and returns, the system supports writing checks to more than just vendors so the ACH functionality shouldn't be limited in this way either.
Gil
I agree with the notion that it would probably make sense to encrypt routing numbers. I do worry that this makes implementation significantly more complicated, but probably better safe than sorry. Since this is a sensitive area, it is probably best that the encryption not be optional, but in that case the set up steps should be well documented. I think ACH data should share encryption key and code with credit card since the biggest security threat is really the database falling into the hands of a hacker outside the walls of the organization; more so than internal security which can be controlled with privileges.
The sponsoring customer is only interested in vendor checks as far as I know. I think we can invoke the 80/20 rule here and stick with vendors as checks are typically written to customers only on an exception basis (i.e. Returns). I don't envision that many folks will have direct deposit set up with customers or tax authorities, but we can of course always extend the functionality later if the need arises.
My thought on mixed checks was that the options are simply to proceed or cancel. Trying to keep the interface simple here. If printing to printer on a check run and ACH supported vendors are in the run, then the message is simply a "heads up" warning that both ACH enabled and regular vendors checks will be printed. The warning gives the user an opportunity to back out. Generally, in a mixed vendor scenario, users should print ACH checks first, then print another check run to the printer. Perhaps messages could advise something to that affect? I think allowing mixed mode printing, though it sounds slick, would be more likely to lead to confusion. Printing checks is usually a deliberate action and a case where I think it is more important to make sure the action is clear and singular in purpose than it is to save a click.
John
What are the ramifications of offering multiple formats? As we have been collecting bank information from our vendors, some of the larger ones are requiring a different format for them to receive electronic deposits. I have convinced our bank to handle the new format, so the question is can we have multiple formats that could be set at the transmit tab for each vendor, or could we upgrade to the new format and cover everyone with that?
Greg
The ramifications differ significantly based on the nature of the various banks' requirements. In some cases no changes are necessary at all. For example some banks might require a company name while others require a company tax id number (EIN or similar) for the destination - this is already handled the initial implementation by allowing the xTuple ERP user to enter the company ID. For other cases we might have to add a couple of check boxes to the user interface and corresponding switches in the logic to build the ACH file. At the other extreme we might have to add addenda records (perhaps a day or two), add support for international banking transactions (a few days), or even use an entirely different EDI format (almost as much work as the initial implementation).
Can you be more specific about the format differences you refer to?
Gil
I tried to upload the spec (for the new format) from our vendor but got an error when I tried to upload it in the attachments section of this wiki. I will send it to you directly and maybe you can get it uploaded for all to review. Thanks,
Greg