> 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
> 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
U2-Users mailing list