I am curious on what others can provide in the way of recommendations for a business implementing EDI transations. The COTS products are expensive, carry yearly maintenance fees, and then there are costs associated with VANS and such. Also, bridging software is also needed to facilitate communication with software receiving transations and software sending out invoices. This is a complicated, expensive process that I feel can be simplied, or can it? Or is a business moving to EDI a captive audience to expensive implementations and continous fees? Thank you.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Recommendations for EDI Implementations 3
- Thread starter gnozzle
- Start date
-
1
- #2
gnozzle,
most developed software will have costs with it - the initial and the yearly fees. what you are paying for with the yearly fees is for someone else to make sure you can process the data if any changes are made by your TP(s).
you could write your own EDI translator but then you are responsible for any transaction set changes, testing, certification, etc.
as for bridging software you again could write it yourself.
what i would suggest is to find out whor you mrp / erp software provider has certified to interface with their product.
as for VAN fees, the more KCs(kilocharacters) you send and receive the lower your rate will be. many companies allow you to go direct (and thus avoid) these fees but there are concerns with this method also.
you could also see if your TP(s) would be willing to trade flat files with you.
regards,
longhair
most developed software will have costs with it - the initial and the yearly fees. what you are paying for with the yearly fees is for someone else to make sure you can process the data if any changes are made by your TP(s).
you could write your own EDI translator but then you are responsible for any transaction set changes, testing, certification, etc.
as for bridging software you again could write it yourself.
what i would suggest is to find out whor you mrp / erp software provider has certified to interface with their product.
as for VAN fees, the more KCs(kilocharacters) you send and receive the lower your rate will be. many companies allow you to go direct (and thus avoid) these fees but there are concerns with this method also.
you could also see if your TP(s) would be willing to trade flat files with you.
regards,
longhair
-
1
- #3
First, you can't implement EDI in a vacuum. Are you the buyer of products that wants to streamline the procurement process? Or, are you a supplier looking to comform to your customers' requirements?
EDI is a two-way relationship (at least). Efficiencies can be improved and trading relationships enhanced if done properly.
The basic question is - why are you looking at EDI?
EDI is a two-way relationship (at least). Efficiencies can be improved and trading relationships enhanced if done properly.
The basic question is - why are you looking at EDI?
good point RonPro.
there are many efficiencies to be realized.
1) when posting from a file you are going to insert or update records much faster than any human could.
2) you no longer have the issue of human error (on your end) you post the data that your customer has sent you.
3) with invoicing most companies that use the 810 also use EFT so you get your money into your account faster.
these are just some quick examples.
regards,
longhair
there are many efficiencies to be realized.
1) when posting from a file you are going to insert or update records much faster than any human could.
2) you no longer have the issue of human error (on your end) you post the data that your customer has sent you.
3) with invoicing most companies that use the 810 also use EFT so you get your money into your account faster.
these are just some quick examples.
regards,
longhair
- Thread starter
- #5
- Thread starter
- #7
gnozzle,
ok. then one savings you'll see is the ability to automatically post the 850 data into your mrp /erp. this will free up the time (that it takes for a customer service person to hand key the data) to focus on other customers or other duties.
since the customer sent the data to you there will also be no 'that's not what we ordered'. you can go back to them with the raw data and say 'it's exaclty as you sent it'. this should diminish returns due to human errors and thus increase your supplier rating (if they do that in your industry).
regards,
longhair
ok. then one savings you'll see is the ability to automatically post the 850 data into your mrp /erp. this will free up the time (that it takes for a customer service person to hand key the data) to focus on other customers or other duties.
since the customer sent the data to you there will also be no 'that's not what we ordered'. you can go back to them with the raw data and say 'it's exaclty as you sent it'. this should diminish returns due to human errors and thus increase your supplier rating (if they do that in your industry).
regards,
longhair
-
1
- #9
ronhextall
Programmer
Some things I would consider:
If you are a small company I doubt you will see any benefits to EDI. IMO the big boys shove it down your throat and that is why most small suplliers get into it. The time you save by not entering P.O. will not make up for all the time you burn setting up EDI translation maps (everybody does it different and the big boys have a motto, do it my way or we will find a supplier that will). You will also burn time dealing with communications issues, selecting a VAN, and/or dealing with AS2 configuration. AS2 cuts the middle man (VAN) out of the picture buy then you will need 24/7 monitoring of EDI communications. Lets just say some of the bigger players are not real friendly about AS2 problems either.
EDI is like an episode of Threes Company, every problem is a misunderstanding about some stupid missing value. The big boys complain if a zero or a blank is missing, some of them even complain when values they don't even use contain something. Your EDI person will spend lots of time on the phone or emailing customers about the most recent misunderstanding. But of course they are the 800 pound gorilla so they get what they want. Some also like to give you chargebacks if the smallest piece of data is missing or out of place, basically they treat EDI as a revenue source at your expense.
See if you can outsource it, dozens of companys offer this service. If your setup is neat, clean, and quick you might be able to do this. ASN's can be a major league pain in the butt depending on requirements.
If you can't outsource it try and find out what systems work best with your compute hardware situation. If you can't integrate it with your ERP then you will be doing everything twice in seperate databases. Once for your ERP system and once for your EDI system. Ask around, your ERP system supplier might even have some suggestions for you. If your ERP has a user group, milk them for some information. The most important decision you will make will be the first one, what software to get.
We have PRMS on an AS/400 and was able to integrate Inovis TrustedLink to it fairly well. The POs and invoices flow between them very well with few issues. When AS2 came a calling we went with Trailblazer and that is one quality product. It interfaced with Inovis so well that new EDI people can't even tell it is a seperate product.
You really need to do your homework on what packages work best with what you already have. Check their references and see what others are using that are in your same boat.
If you are a small company I doubt you will see any benefits to EDI. IMO the big boys shove it down your throat and that is why most small suplliers get into it. The time you save by not entering P.O. will not make up for all the time you burn setting up EDI translation maps (everybody does it different and the big boys have a motto, do it my way or we will find a supplier that will). You will also burn time dealing with communications issues, selecting a VAN, and/or dealing with AS2 configuration. AS2 cuts the middle man (VAN) out of the picture buy then you will need 24/7 monitoring of EDI communications. Lets just say some of the bigger players are not real friendly about AS2 problems either.
EDI is like an episode of Threes Company, every problem is a misunderstanding about some stupid missing value. The big boys complain if a zero or a blank is missing, some of them even complain when values they don't even use contain something. Your EDI person will spend lots of time on the phone or emailing customers about the most recent misunderstanding. But of course they are the 800 pound gorilla so they get what they want. Some also like to give you chargebacks if the smallest piece of data is missing or out of place, basically they treat EDI as a revenue source at your expense.
See if you can outsource it, dozens of companys offer this service. If your setup is neat, clean, and quick you might be able to do this. ASN's can be a major league pain in the butt depending on requirements.
If you can't outsource it try and find out what systems work best with your compute hardware situation. If you can't integrate it with your ERP then you will be doing everything twice in seperate databases. Once for your ERP system and once for your EDI system. Ask around, your ERP system supplier might even have some suggestions for you. If your ERP has a user group, milk them for some information. The most important decision you will make will be the first one, what software to get.
We have PRMS on an AS/400 and was able to integrate Inovis TrustedLink to it fairly well. The POs and invoices flow between them very well with few issues. When AS2 came a calling we went with Trailblazer and that is one quality product. It interfaced with Inovis so well that new EDI people can't even tell it is a seperate product.
You really need to do your homework on what packages work best with what you already have. Check their references and see what others are using that are in your same boat.
- Thread starter
- #10
Ron Hextall:
First, cool alias as I love hockey and am a Flyers fan, even though they're having a bad season.
Thanks for the very helpful information. You addressed most of my concerns and suspicions about EDI. I definitely will look into oursourcing, I didn't even consider this at all. But you are right, we are pushed to EDI regardless if it really makes economic sense.
First, cool alias as I love hockey and am a Flyers fan, even though they're having a bad season.
Thanks for the very helpful information. You addressed most of my concerns and suspicions about EDI. I definitely will look into oursourcing, I didn't even consider this at all. But you are right, we are pushed to EDI regardless if it really makes economic sense.
- Thread starter
- #11
ronhextall
Programmer
Outsourcing will probably mean doing data entry over the Internet and the outsourcer will take it from there. I don't know much about outsourcing but my phone rings 24/7 from people wanting to do it for me real bad. I am sure outsourcing has its headaches but I would at least do a little research. If you have just one customer pushing for it ask them for a list of third party EDI companies they use and are happy with.
Gnozzle has a good point. Once you get a lot of clients wanting EDI then outsourcing is probably not going to work from a cost standpoint.
If you already have an IT staff then maybe doing EDI inhouse will not be that bad. If you do it inhouse you will certainly have to send them away for training. Maybe it is just the place I work but EDI tend to change jobs a bunch also. I kind of got stuck with EDI for a couple of years and I hated it. I like programming and doing new and interesting things. EDI is a bunch of phone calls and taking crap from your big clients. Thankfully I was able to hand EDI off to somebody who so far seems to enjoy it. I still do help when it hits the fan but for the most part I am done with it. Doing EDI is like doing high tech paper work.
The success of EDI depends on a lot of factors not just a single person and that is probably why I hate it so much.
1. Dial up communications needs to work, if it is old school VAN.
2. Need internet communications to work if doing AS2, which mean exchanging security certificates, firewalls, and a half dozen other things that can go wrong. We had problems for a while that were just killing us, ended up being a Cisco box wasn't big enough at some times to handle all the traffic. That was a real peach.
3. Need to have the maps correct. Different clients use different versions of the same thing.
4. Needs to feed into ERP system correctly.
5. If you are sending ASN's out, the people on the loading dock need to input the correct information exactly right or you might get chargebacks.
6. Invoicing from ERP needs to feed back out for 810's going out.
And since sooner or later you will want to automate all of this you have to code it to handle things like communications issues without any human actions.
If you need to budget for it I would build in a ton of fudge room.
Gnozzle has a good point. Once you get a lot of clients wanting EDI then outsourcing is probably not going to work from a cost standpoint.
If you already have an IT staff then maybe doing EDI inhouse will not be that bad. If you do it inhouse you will certainly have to send them away for training. Maybe it is just the place I work but EDI tend to change jobs a bunch also. I kind of got stuck with EDI for a couple of years and I hated it. I like programming and doing new and interesting things. EDI is a bunch of phone calls and taking crap from your big clients. Thankfully I was able to hand EDI off to somebody who so far seems to enjoy it. I still do help when it hits the fan but for the most part I am done with it. Doing EDI is like doing high tech paper work.
The success of EDI depends on a lot of factors not just a single person and that is probably why I hate it so much.
1. Dial up communications needs to work, if it is old school VAN.
2. Need internet communications to work if doing AS2, which mean exchanging security certificates, firewalls, and a half dozen other things that can go wrong. We had problems for a while that were just killing us, ended up being a Cisco box wasn't big enough at some times to handle all the traffic. That was a real peach.
3. Need to have the maps correct. Different clients use different versions of the same thing.
4. Needs to feed into ERP system correctly.
5. If you are sending ASN's out, the people on the loading dock need to input the correct information exactly right or you might get chargebacks.
6. Invoicing from ERP needs to feed back out for 810's going out.
And since sooner or later you will want to automate all of this you have to code it to handle things like communications issues without any human actions.
If you need to budget for it I would build in a ton of fudge room.
this is where doing your homework comes in.
you are going to have to spend a bit of time looking down the road, in an attempt to gauge the future and in the end hopefully find out that you made the correct decision.
just a few other points:
most vans allow FTP now so you only need to worry about your i'net connection.
there are many systems out there. as i said earlier and others have echoed - find out what systems your erp / mrp provider suggests. then look closely at them and get opinions from users, not just the people in charge - but those on the front line doing the work. they will give you the true worth of the system.
as far as data input, this really should be handled by scanning and other automation processes.
the system that we use, while not the best or brightest is easy to use, easy to configure, easy to manipulate, etc.
regards,
longhair
you are going to have to spend a bit of time looking down the road, in an attempt to gauge the future and in the end hopefully find out that you made the correct decision.
just a few other points:
most vans allow FTP now so you only need to worry about your i'net connection.
there are many systems out there. as i said earlier and others have echoed - find out what systems your erp / mrp provider suggests. then look closely at them and get opinions from users, not just the people in charge - but those on the front line doing the work. they will give you the true worth of the system.
as far as data input, this really should be handled by scanning and other automation processes.
the system that we use, while not the best or brightest is easy to use, easy to configure, easy to manipulate, etc.
regards,
longhair
- Thread starter
- #15
What I seeing here is a lot of smoke. First off most businesses today traffic in edi. To be specific it sounds like you're talking about edi/x12.
Because EDI can come in any format and doesn't follow any standard other that what the trading partners agree on it's moot unless your dealing in x12. Non-x12 data will always come the same way and you can always depend on a static format. Rare surprises.
Unless you have few transactions and few TPs it's silly to think about writing your own application. And not just because of the reasons stated above.
There are venders out there that have spent years of development time building tools that can handle any EDI transaction that comes tru the door and you don't need to spend hundreds of thousands of $$ to get setup. Those same vendors will keep your tools and x12 data definitions up to date and should be able to handle any ligitimate variation in an x12 data-set. Based on that, changes to the way you map your data should be fairly easy and fast.
On data transfers.. Depending on the size of your firm you probably have a team of people that deal with all sorts of connection protocals. They work with the TP to set things up not the development team. And, it shouldn't be the developers job to figure that out. I work at a mid-size healthcare payer. We setup all sorts of connections all the time. Most TPs will agree to transfer data via a protocal of our preference. It's the first time you setup a connection with a new potocal of any sort that's the problem. After that it's easy to do the next. Our most common transfer is FTPS. We also use FTP, HTTPS, AS2..... To date we don't use a VAN. Recently, I called our network security people and said I needed an HTTPS connection setup with a bank, gave them a name and number. Within 24 hours I was testing both the connection and beta files.
Also, if we get a file that fails due to a format issue our development team hands it over to team of 3 people. They work out the details. If the 800 pounder makes us handle their data exception fine, part of the job. Otherwise it's not a programming issue.
Finally, unless there are performance guarantees you usually don't have to deal with charge back due to issues. The only time it's ever happened here is when we've consistantly been the cause of the problem. Typically though you'll run into problems on both ends.
When we looked at outsourcing it was cost prohibitive. Not just because of the charge per transaction. There were other hidden costs. I also looked at more that 5 toolsets for mapping edi/x12 data. We chose to manage the data internally. I don't know if we made the best decision but I can honestly say that it wasn't a bad one. Over the years we've saved a lot of money and the tool we bought opened a lot of unforseen doors (as would 2 or 3 of the others).
One of the things the banking industry learned a few years back is that when you hire someone else to do the work for you it can be difficult and expensive to make a change when things need to. A big service provider isn't likely to give a little guy access to raw code. If you don't like the provider, you have a potentially expensive decision to make. A large service provider can be a bigger pain to deal with than an 800 pound G. I ee that all the time with out TPs.
If it were me I'd define what my objectives were and shop for vendors that will either provide a service or provide a tool. While shopping, chances are you'll learn a lot more about what you want/need to do. You might be surprised by hidden costs and savings.
Because EDI can come in any format and doesn't follow any standard other that what the trading partners agree on it's moot unless your dealing in x12. Non-x12 data will always come the same way and you can always depend on a static format. Rare surprises.
Unless you have few transactions and few TPs it's silly to think about writing your own application. And not just because of the reasons stated above.
There are venders out there that have spent years of development time building tools that can handle any EDI transaction that comes tru the door and you don't need to spend hundreds of thousands of $$ to get setup. Those same vendors will keep your tools and x12 data definitions up to date and should be able to handle any ligitimate variation in an x12 data-set. Based on that, changes to the way you map your data should be fairly easy and fast.
On data transfers.. Depending on the size of your firm you probably have a team of people that deal with all sorts of connection protocals. They work with the TP to set things up not the development team. And, it shouldn't be the developers job to figure that out. I work at a mid-size healthcare payer. We setup all sorts of connections all the time. Most TPs will agree to transfer data via a protocal of our preference. It's the first time you setup a connection with a new potocal of any sort that's the problem. After that it's easy to do the next. Our most common transfer is FTPS. We also use FTP, HTTPS, AS2..... To date we don't use a VAN. Recently, I called our network security people and said I needed an HTTPS connection setup with a bank, gave them a name and number. Within 24 hours I was testing both the connection and beta files.
Also, if we get a file that fails due to a format issue our development team hands it over to team of 3 people. They work out the details. If the 800 pounder makes us handle their data exception fine, part of the job. Otherwise it's not a programming issue.
Finally, unless there are performance guarantees you usually don't have to deal with charge back due to issues. The only time it's ever happened here is when we've consistantly been the cause of the problem. Typically though you'll run into problems on both ends.
When we looked at outsourcing it was cost prohibitive. Not just because of the charge per transaction. There were other hidden costs. I also looked at more that 5 toolsets for mapping edi/x12 data. We chose to manage the data internally. I don't know if we made the best decision but I can honestly say that it wasn't a bad one. Over the years we've saved a lot of money and the tool we bought opened a lot of unforseen doors (as would 2 or 3 of the others).
One of the things the banking industry learned a few years back is that when you hire someone else to do the work for you it can be difficult and expensive to make a change when things need to. A big service provider isn't likely to give a little guy access to raw code. If you don't like the provider, you have a potentially expensive decision to make. A large service provider can be a bigger pain to deal with than an 800 pound G. I ee that all the time with out TPs.
If it were me I'd define what my objectives were and shop for vendors that will either provide a service or provide a tool. While shopping, chances are you'll learn a lot more about what you want/need to do. You might be surprised by hidden costs and savings.
You guys make EDI sound like a royal pain.
Here at a large non-profit hospital, we couldn't do without it. We have around half a dozen people posting payments from medical insurance outfits that don't do EDI (or do it so wrong that we have to go manual). The volume that is posted automatically via EDI is many times as much as is done manually.
Similar savings occur on the billing side.
--
Wes Groleau
Here at a large non-profit hospital, we couldn't do without it. We have around half a dozen people posting payments from medical insurance outfits that don't do EDI (or do it so wrong that we have to go manual). The volume that is posted automatically via EDI is many times as much as is done manually.
Similar savings occur on the billing side.
--
Wes Groleau
- Status
Similar threads
- Locked
- Helpful tip
- Locked
- Question
- Locked
- Question