The latest EDI money saver? Paper invoices So I was at a Kofax customer and partner meeting last week, where the standard view of the electronic digital world taking over the analogue paper document world was stood on its head. The way for businesses to save buckets of cash is to abandon EDI (electronic document interchange) invoices and revert to human readable …
most people don't know how to use computer systems, paper is just quicker for them.
But not sure I would like to be in a team that uses paper, unless it was the folding kind headed my way. They are not going to be as fast as a team that can use computer systems.
So, there is your marker and there is your divide. If they have to use paper pay them less, if they are good with computer systems pay them more.
"The problem with EDI, Spencer says, is that the standards just keep on changing leaving IT departments perpetually recoding to recover lost ground. "
Eh? What? Once you've developed an interface and it works, why do you want to change it? What lost ground? Why re-code it? If you need to handle additional functionality via the interface then change it, otherwise leave it alone. Is he saying that his wonder software has a psychic interface to handle all future changes in requirements requiring no re-work?
Yet another way of processing human-readable data files is all well and good (and indeed quite welcome, I'm all for competition in the software market), but don't try and claim it's unique or some kind of paradigm-shift.
Yet another "EDI is dead" article. There was a flurry of these back in the 1990s when XML was supposed to be the great EDI-killer. To any CIOs reading this (do any CIOs read El Reg?), try not to believe every bit of marketing puff you see.
Whether you map fields from an EDI file or from a paper/pdf document, you still have to decide on standards, even if internal, and define the mapping processes. Processes which may, and probably will, evolve over time as needs change.
What is the advantage for the vendor to generate a paper invoice from their internal electronic data format , just to have the customer reconvert to their own format for automated processing? Why not just transfer an EDI invoice and eliminate a redundant step or two?
Is this article just an advertisement for a single company who is now in search of a market for their expensively acquired technology?
Whether you map fields from an EDI file or from a paper/pdf document, you still have to decide on standards, even if internal, and define the mapping processes. Processes which may, and probably will, evolve over time as needs change.
What is the advantage for the vendor to generate a paper invoice from their internal electronic data format , just to have the customer reconvert to their own format for automated processing? Why not just transfer an EDI invoice and eliminate a redundant step or two?
Is this article just an advertisement for a single company who is now in search of a market for their expensively acquired technology?
This post has been deleted by its author
Oh a few years ago, a huge software company I worked for elected to keep a system which was unstable, expensive and a security risk directly against their own policies as it was deemed 'the wrong look' to retire it. Going back to paper payslips would have saved around £12,000 a year and solved all the security and related issues. You suggest these things, you get shouted down, so I applaud this wisdom in the face of the paperless office that's created more paper than ever before...
EDI standards do not change. New standards are certainly developed and introduced, but it is totally up to the companies trading with each other whether to adopt a new standard or stick to the old existing one. In my experience very few companies chose to change an existing working system, without good cause; and many of the requirements I see specified are still based on standards developed 10 years ago, or more
Secondly, speed of payment is seldom related to speed of processing of invoices. It is more likely to be dictated by company policy, terms and conditions, and cash flow.
Or should I say without deposit slips. Just put your stacks of checks in the ATM and it reads them and asks you to verify the amount. It just doesn't work all of the time. And if it doesn't happen to be able to read my checks I can't make an after hours deposit. So it costs me money to take time off from work to get done what I used to be able to do after hours with an old fashioned deposit slip.
EDI is a classic case of bad standards being worse than no standards. A inexperienced and inappropriate standards body (the United Nations no less!), too much vendor input, scope creep etc. etc. led to confusing, over complex and ever changing standards.
EDI clings to life in some niche markets, the US where a commercial operation said ballocks to the standards and runs a pay for what you get EDI clearing house, and, the auto industry whose supply chain runs on an EDI standard from the last century, because at some point they just said no to upgrades.
Mines the one with the invoices stuffed in hte pockets.
There is one International EDI Standard - UN/EDIFACT. (ISO 9735) Directories are updated twice a year, but are so stable now that any changes are minor, and you don't need to apply them if your current version works. We still have partners using 1994 versions quite happily.
There are of course national standards, particularly ANSI X12 in the US, and Tradacoms in the UK, so a trader might have to support two standards, but they likewise have been stable for years.
There is no coding involved in a change - we use mapping software and just change the mappings (drag and drop usually)
EDI isn't only about invoices. We handle 10s of thousands of EDI messages a day for bookings, shipping instructions, Bills of Lading and container status messages. There is no way these could be handled completely manually.
I have had 15 years of work out of EDI, even though I was told it was dying when I started.
As the title says, FUD from someone trying to muscle into a market that already has a stable working solution. What next? TCP/IP is always changing, (IPV4 - IPV6) so we should go back to using snail mail with document scanners?
A non-story.
Hi there
I work in the UK book industry and all the Standards used are more or less set in stone so that electronic invoices from suppliers (In Tradacoms / EDIFACT) are all in the same format.
Thousands of hours are being saved in libraries because they have automated receipting by receiving electronic messages.
We have a governing body BIC (Book Industry Communications) who meet regularly to review all standards and their use.
Libraries, library suppliers, booksellers, publishers, distributors and wholesalers all win by trading electronically.
One chain of booksellers receive between 3 - 4 million invoices and credits - when they were receiving paper invoices they employed over 100 staff - this has been drastically reduced !!
To return to paper in our industry would be a disaster and be unaffordable.
Thanks for reading this !
Tony Wareing
TSM Nielsen Book Services
It was no coincidence that the abolition of slavery came at the beginning of the first Industrial Revolution. A steam engine ate only coal, didn't need to sleep, and even the most recalcitrant specimen could be coaxed back to work with naught but a few tweaks of a wrench and a dollop of oil.
But nobody ever had the foresight to mandate that a human being doing a job should never be paid less than the equivalent running cost of a machine to do the job, because it seemed patently obvious. Nobody ever expected chronic underinvestment in energy sources would lead to slave labour undermining the cost of running machines to do the same job.
We're living in interesting times .....
At my last job I had responsibility for the EDI stuff. As a smallish business it was a f***ing nightmare that we used simply to pacify those larger customers that demanded it - or some of them. Yes there are standards, but the standards are so flexible that every implementation is effectively bespoke - one customer puts item X in field Y, another puts it in field Z, another doesn't supply X and puts item C in field G instead.
And then we had those customers that insist on using 'standard' EDI, but demand so much functionality, and with such a complete absence of flexibility, that we end up running the ONE package that they will approve of. To all intents, we were running a customer frontend to THEIR system, manually, on our time, in our office/warehouse - ZERO (actually, negative) advantage to us and making a mockery of the whole concept by preventing us using the (admittedly limited) facilities we already had (at great expense).
Quite frankly, for us, old fashioned paper would have been a lot cheaper and quicker. We'd have happily done more EDI, but customers just kept making it too hard - to the extent were it wasn't worth the investment to make our facilities better.
EDI is great if your supply train is geared up for it, (as in the book trade) , but otherwise it is a nightmare. Capturing the data from paper at the organisations edge so that at least the internal processes can all be electronic is a practical way forward. You can then move to full EDI when suppliers catch up.
Most of the displeasure with customer changes apears to be the end result of a salesperson who can't say no to the customer. Or at least one that can't explain why the changes will cost more.
For example: Customer suddenly doesn't like the "look" of a particular agreed upon "document" format, decides to change it, and when discussed with their EDI suppliers salesdroid he/she says "Sure we'll do that for you, no charge" when all the while the people who actually make things work say "Are you out of your frikkin mind!!!!!! That will take an entirely new map and new fields in the database". This problem is due to the sales department never having to understand HOW something gets done, it just magically "appears".
Customer Rule to Remember... For the 10% of your customers that cause 90% of your problems; tell them to go to hell (nicely) and give them your competitors number. That way you are rid of an unrewarding relationship and have time to find others that make money for your company all the while your competitor is saddled with the worst of all possible customers wasting his time and resources trying to please the impossible dream.
What is bad is the approach that is usually taken to implement. Three points of contention I think:
1- EDI exposes how bad your data is. You just cannot miss EDI mandatory fields, or enter "fictional" data to overcome the limits of your system. You need to be very proactive and look out to fix the problems in your applications.
2- Violation of standards. Often, some big customers place additional demands over the EDI standard (such as "my department ID should be in the ZIP code field") that need expensive customizations. A body is needed that disallows those customers to advertise or demand EDI, just to avoid confusion.
3- Knowledge: so many people go with the most expensive EDI implementation possible. They buy an EDI gateway and pay someone to read or write flat text files. Those text files are the ones that your application uses. This is wrong. Most major packages have EDI modules, no need to do expensive interfacing.
For chuff's sake, how difficult can it really be just to use XML and have done with it?
Incoming data is parsed by means of regular expressions (which have the benefits of being well-understood and implemented in every programming language). Outgoing data is shoved through printf statements (which also are well-understood and implemented in every programming language).
You show your XML-parsing regular expressions to the people who are sending you data, and they in turn base their XML-generating printf statements upon them. Or they show you their printfs and you base your regexps upon them. Either way, everybody ends up happy.
In the absolute worst case, you end up needing a different import routine per supplier and a different export routine per customer. But since your variable names and logic are the same, you just abstract data import and export away into modules. Or, if you're deeply into the object-oriented stuff, you create a "record" object which includes methods for every possible import and export style.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
