For those of you that are doing electronic AP payments in Epicor, do you do anything special with security to keep the bank information secure?
E.g. Mask or hide the bank account info fields on the Supplier Entry page based on user/security group? Hide the tab except for the select few? Something else?
Thanks!
Secure from your own emoyees?
While I take security seriously, just remember that the bank account and routing numbers appear on every printed check you issue. I know you said “electronic payments”, but info often appears on invoices as remittance info.
Just saying that there’s only so much you can do.
@askulte I hide the bank remit tab on the supplier by a security group that only has the accounting AP team.
@ckrusen To your point those invoices come into the AP groups email, so they are somewhat sequestered from the general public.
I didn’t realize he was talking about the suppliers info. I guess I’m too self centered 
In Europe, where they don’t use cheques, every invoice displays the bank and Swift number for payment. Since it’s a lockbox that only accepts money, they don’t worry about it. 
I would argue there is nothing confidential about bank account and routing numbers they are printed at the bottom of every check.
There is nothing you can do with a bank account number except maybe deposit some money.
They figuratively print that sh*t on a book of post its and ask you to hand it out to anyone you need to pay 
I would go on to argue that trying to keep them a secret leads to some social engineering attacks where someone calls in a new number to steal payments.
However, this is only true for lock boxes. Unfortunately, we use the same routing/bank number to both deposits and withdrawals for most personal accounts here in the US. So, hiding employee bank information is probably a good idea until we change the entire US banking industry. 
still written at bottom of your personal checks and withdrawals require at least one if not several forms of ID so I say let it all fly lose. Do like the LifeLock guy and plaster it on the side of your truck 
Thanks @ckrusen @gpayne @Mark_Wonsil @josecgomez!
Good to hear this common sense. I like to keep things more locked down than not, usually.
I’ve been wanting to brush up on my COBOL and do some C# interop.
It saddens me to say I actually knew COBOL… what a wordy language… but still one of the few high level languages that has no decimal rounding issues
It’s a good skill to have. At least to understand it.
I find the best part of knowing multiple programming languages is
that I’m not really good at any of them.
Looking around for my COPYLIBs… Oh, look at those comp-3 numbers! Good times.
I never learned COBOL. I did start to try and learn FORTRAN, only because there was some literature for complex signal analysis, done in FORTRAN. Not to use FORTRAN, but to implement the signal processing algorithms in C.
Luckily I found that “Numerical Recopies in C”, had most - if not all - the same algorithms.
In college, our first language was FORTRAN. Well, it was a FORTRAN preprocessor called RATFOR: Rational FORTRAN. They were trying to teach us to do Structured Programming (no GOTOs). RATFOR was used in the book by Kernigan and Plauger (of C programming language fame): Software Tools. The school switched to Pascal and K&P also had a version for Pascal. These have been a couple of the most applicable programming books my entire career despite being written in 1981. Build small tools that do one thing well and build bigger tools from the smaller tools.