G-man:
NACHA isn't a client/server framework. It's more of a file-formatting
framework; like tab-delimited, CSV, XML. So it's, perhaps,
inappropriate to apply a client/server analysis to a file-formatting
problem.
One of the main challenges with NACHA processing is the file has to get
to the file-processor. The banking system, generally, is the recipient
of the file; so most activity goes through them. Therefore, it is the
company's banking relationship that determines how and where the NACHA
file is delivered. Again, client/server analytics are ineffective for
this issue; which is usually no more than drag'n drop, or upload the
file to a web page with an "<input type='file'>" textbox.
So, you see, the first issue with the process is creating the file
(which is the easiest) and the second is how to deliver it to the bank.
Many banks have different ways to transmit the file, so for one bank a
textbox upload is fine, but for another it's not. :-( The software
has to adjust (which makes integration difficult), but it can integrate
the file creation because a NACHA file has a standard format. Using
someone else for ACH requires your data be replicated elsewhere. This
can be automated but it all depends on your banking relationship and
presents all of the problems associated with distributing data to
disparate systems (it takes more time, money, aggravation, etc). :-)
HTH,
Bill
Untitled Page
------------------------------------------------------------------------
----- Original Message -----
*From:* 3xk547...@sneakemail.com
*To:* u2-users@listserver.u2ug.org
*Date:* 6/22/2012 2:16 PM
*Subject:* Re: [U2] ACH Functionality in ManFact
From: John Varney
I've been tasked with writing a bolt on module to give ManFact the
ability to utilize ACH processing. Has anyone done this already? If
so,
any words of wisdom?
Having read the other comments here, I find my approach would still be
the same as for everything else.
You're working with a database. Don't try to turn it into an ACH
client or server or anything else. There are a wealth of tools out
there for doing ACH (Google "ach software"). People spend a lot of
time to make that technology works, and you don't need to reinvent the
wheel, especially since you're not an ACH expert and those other
developers are. (Same words apply to anything, whether TAPI, SAPI,
XML, ECommerce, Faxing, Emailing, weight scales, and all kinds of
other things that people want to do with MV.)
Find a utility or service that matches your skillset in terms of
writing client-side queries, and call from your app to that. If you
later find you need to do something else, your back-end remains
relatively unchanged and you just need to swap out the middle tier.
Trust me, as many of you focus on inventory management or GAAP, I've
been specializing in communications and interfaces between MV and
"anything else" for about the last 15 years. I've written
inbound/outbound socket routines, used cURL for web calls, many
languages and protocols, and I've dabbled with just about every
communications pipe in this industry. For every "how do I do 'this'
with MV", these days there is a better reason Not to do it with MV,
but to use other people's software that is much more rigorous than
anything that we could come up with. Our solutions for 'this' will
always be inadequate compared to something else that's out there.
That's not a statement of the quality of our work but the sheer time
and money and knowledge that we can throw into some of these things
compared to other people who live and breathe this stuff.
Will you pay for third-party solutions? Maybe. If you get FOSS then
you'll pay with your time but you may save some effort. If you pay for
a service then They will focus on things like regulatory issues,
security, and changes in the industry. When your ProjectX is done,
will You have the time for things like that? No, we generally need to
move on to the next ProjectY. For this reason, in the long run it may
cost less to 'buy' than to 'make' as they say in the manufacturing
industry.
http://Nebula-RnD.com/blog/tech/mv/2009/08/mv-to-anything.html
HTH
T
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
