Transitioning from Gentran to GIS... From what I hear this is going to be quite a big task migrating from Gentran, partly because its a whole different beast. I am in Lowell, MA this week to attend the GIS Fundamentals class, its a 5 day class that covers quite a bit of the main functions of the software. Today was day 1, and it was filled with a solid introduction of the basics and benefits of the Gentran Integration Suite. In addition to the introduction we covered the Graphical Process Modeler (GPM) and dove into BPML (Business Process Modeling Language) concepts and functions. After the introduction was finished I felt I had a strong understanding to what GIS can do. It made me really start to think of all of the logic and business processes that we currently have in place on our AS/400 that are "hard coded" which take place after the translation process. It seems GIS will be able to handle all of the various checks and balances we have in place before dumping an order into our system. For example, on a 850 purchase order we check to see if a customer's store exists in our customer master file or if that customer ...

WHOA!!!  In My readings, I just came across this article over at EC-BP.org!  Looks like we all get to start paying for our EDI transmissions!!  Author: Craig Dunham - EDI CoordinatorRead more about Craig here: http://editalk.com/contributors/

I was reading The Inovis Blog - yes, I do read other things! - but Meg Suggs (Inovis) talked about how McDonalds (over in Europe!) is "going green" with their fleet of delivery trucks. I commented (of course!) on how it would be great if the US and our automakers could be as forward thinking about the acceptance of alternative fuels and energy sources (such as bio-diesel). My own car is a Chrysler PT Cruiser. Chrysler sells the PT Cruiser over in Europe, and offered (at least at one point) electric versions of the PT, as well as a CRD powered PT Cruiser. CRD is the acronym for COMMON RAIL DIESEL and it actually is a very viable diesel motor - with great performance and low emissions - not anything like the diesels we all may remember from the 80s.... Jeep even offers the CRD engine in their "Liberty" truck-ette in the US. But I digress from My original thought and point. Reading that post (at Inovis) and My comment on same made Me think of how much better and easier (!) EDI could be if more hubs and suppliers - and even EDI providers - were to be more open and accepting to other ways of thinking.. How much more we could all get done. As a ...

Over on the Inovis blog, Bill Chessman ponders about the human readability of XML vs. EDI.  A different take on an old debate.  Ah, the old "EDI vs XML" debate rears it's enormous jumbo head of dissent again...  *sigh..... XML is simply a language for possibly trading information in a human readable format.  Much like HTML (the language of the Internet), you use "tags" that tell you what the next piece of information is.  So you can have a simple tag of <NAME> and then a person's name and then the closing tag </NAME>....  You can continue to use these simple kinds of tags for the rest of the information you're sending (sending maybe an address, a 2nd line of address, a city, a state, a zip and more) and the human eye can read it as John Smith 123 Main Street Suite 123 Anytown ST 92345 In his post at the Inovis blog, however, Bill makes an excellent point - and one I've touted before in other comments - in that XML may be easier (in the layout of tags and direct information) to read then EDI formats, but it's all dependent upon the DTD and the schema.  It's easier because there is no rigid, solid standard to follow.  "Data A" can be ANYWHERE in the document, as long as it's labeled as "Data A".  ...

Well, guess what - I was reading (go figure!) a newsletter from another site - E-Commerce Best Practices (ec-bp) - and they had an article - that itself - was excerpted from the EDI ACADEMY - all about "EDI to FAX and FAX to EDI" types of communications. And it got Me to thinking. Yes, again. One of the things that I've always had and dealt with in the past with My own EDI program for My employer.. First off, we have our own in-house solution for EDI. We use the Inovis TrustedLink i-Series program - and have for years - and pull directly from our merchandising system on our AS/400 - sorry - Series-i system. We populate back into that merchandising system (Island Pacific) and also our WM system from the inbound ASN documents. And with the new 810 Invoice that I'm working with our accounting department on, I'll populate from that document, too. But, again, in the beginning, there was the expansion of our program - trying to net as many of our vendors and suppliers and getting them on-the-hook and in-the-basket for EDI document trading. Now, it should be said that of our 1700-plus vendor rolls, there are some duplications - in that this product line from Big Vendor A is set up differently ...