I have a mechanism whereby a csv file can be fed to our EDI system and loaded in the same manner as EDI. There are upsides and downsides.
The downsides are excel's formatting itself and the submitters lack of understanding of data requirements of a computer. I have to educate them how utterly and completely stupid computers are and how what is so easy for their brain to interpret, literally something a child would understand, is beyond the capacity for a computer. Excel makes a bunch of decisions about how to display data that are useful to the average human and not explicitly apparent. Even when you save as a csv file it puts a collection of blank lines (commas no data) at the end of the data and I have found that GIS/SI chokes on those blank lines. The computer also struggles with dates. 4 digit or 2 digit years matter, the format matters. Excel may display the data on the screen differently then it saves it. For instance they format it as yymmdd and save it as a csv it will be yymmdd in the csv file. However if they open that csv again to look at something even though they changed nothing excel will alter that date to yyyymmdd if they say yes when it asks if they want to save. To say yes is the common impulse. We had it the other way for a while but that wasn't consistent either mostly because the data would come as yymmdd from the source. Then there were the countless times that two people thought they used the same spreadsheet format but in fact one had the columns in a slightly different order than the first. Even the same person would send me data with the columns not consistent from day to day, or worse with nice decorative headers and blank lines at the top. I have a script that runs through the csv file records now, discarding blank records, re-ordering columns, cleaning up date format and supplying default values where missing so that what I feed my translator is clean data. Even so if they failed to group the PO records together the system will think that the second, non-contiguous instance of that PO number is a separate order which comes with another set of headaches. I could spend all my days coding around the various different ways someone could screw this up but I won't. After a certain reasonable effort at converting a sheet to data if it fails I throw it back for them to try it again. All that aside it saves our customer service group an enormous amount of data entry time to be able to drop a csv file in a folder to be loaded into our ERP system even after the time they spend up front to format it. That is the goal, after all. On Wed, Sep 22, 2010 at 9:55 AM, Chris Johnson <[email protected] > wrote: > > > Quoted text is from <094d7ebded3440df8750df79a77f4...@acerpc>, by jkcedi > <[email protected] <jkcedi%40triad.rr.com>> > > >Fax to EDI > > I think Howard was kind in his critique of this. We have found it to be > a complete nightmare, even when requiring senders to fill in a standard > form to fax. It needs manual intervention to complete and correct the > information sent. With a large volume of faxes this might be preferable > to direct data entry, but we have never had a client unfortunate enough > to be in this position > > In fairness I should say that the last time we looked at this was nearly > ten years ago, and there may be OCR software available now which reduces > the pain. > > >Excel to EDI > > We have many clients who receive 'EDI' as spreadsheet generated csv > files [1]. Our software regards csv as 'just another EDI standard' and > so they can be taken through mainstream processing. If this is not > possible then conversion to conventional EDI has the advantage that you > run the data through the error detection mechanisms of the EDI system. > > Occasionally we have had requirements to process data sent as an Excel > spreadsheet in one of the docx formats. This can be unzipped and then > processed as (very verbose) XML. > > >WebForms > > That seems to be what many hubs provide for non-EDI-enabled suppliers. > It has been around for a while, so you will not be on the bleeding edge > of technology. I suspect it should be the preferred approach. > > Regards > Chris > > [1] This was an approach which some firms took in the late 90's, when > XML was going to conquer the world, and it seemed wise not to invest in > conventional EDI, but wait until XML use had matured and become > mainstream. Wry smile. > -- > Chris Johnson mobile:+44 (0)7785 302122 Fax: +44 (0)870 0519 818 > EDI website http://www.edimatrix.co.uk > EDIMatrix Ltd work: 0845 126 0680 or +44 20 8778 1402 > Registered in UK no. 2777624 Reg.Office: 34 Sydenham Rd, London SE26 5QF > > [Non-text portions of this message have been removed] ------------------------------------ ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix.Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/EDI-L/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
