GIS Fundamentals – Gentran Integration Suite – Day 1

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 is allowed to order the product they are trying to order. All of these checks can be moved to the GIS system, although not with ease! There is going to be a learning curve to figure out the system and to transfer logic into a working business process.

We dove into BPML and how GIS utilizes this with the Graphical Process Modeler. Essentially the GPM builds the BPML for you, you can edit the BPML manually (and in some cases you have to).

Again, we only covered the basics today. I’ll report back with more later this week.

Has anyone else made the Gentran to GIS jump?

Author: John Burmeister
Read more about John here: http://editalk.com/contributors/

EDI Chargebacks!!!

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 Coordinator
Read more about Craig here: http://editalk.com/contributors/

EDI documents & KISS

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 hub (i.e. a retailer that starts the EDI process), I have great and tremendous power over My suppliers.. Geez, now “He-Man: Master of the Universe” is running around My brain with “by the power of Grayskull… I HAVE THE POWER!!!!” as he turns from meek and mild Prince “what’s-his-name” into He-Man – Master of the Universe.. and yes, I’m digressing again. But still, as the retailer, I do “have the power” to control the way that EDI works. I’m the one that specifies what information is important to Me and what information I’m going to send and how I’m going to send it and you can either accept it or not. But if not, then you’re probably going to be dropped off of our “active vendor” rolls.

But then it makes Me think – even more – about how that power can be used – or abused – depending on how willing I am (as the hub) to force the issues. We’ve all heard the horror stories of this hub or that supplier and how they make EDI painful..

In our product mix, we have some of the big-big heavy hitters and also some small little mom-n-pop kinds of suppliers.. If you read My other blog about “How Do You EDI” – I mention about a supplier that provides us with one product, but it’s the best damn version of that product on the market, you understand what I mean about mon-n-pop suppliers. But still.. I have to be considerate of all of My vendors and suppliers – of all of My trading partners. I have to be flexible in what I will and will not send, and in what I will and will not accept in a return document.

We buy a lot from one of the biggest names in Camping Goods that you can know – they do it all – from coolers to lanterns to sleeping bags to those folding chairs and then even more.. When we first implemented our EDI ASN, I was asked by their EDI mapper if they could send additional information in the ASN – information that our spec didn’t call for; hell it didn’t even mention it. Like the PID segment. The reason? because he sends that segment to other hubs/retailers and was looking to keep as few maps around as possible. This would be a classic example of the KISS philosophy I mentioned previously. And it’s something I’m quite OK with.

It’s the same thing that many of My trading partners have to deal with when they receive My 850 PO – in that I send along information that they may never use in their own system. For example, in the PO1 segment, I send along our SKU (important for the return ASN and for pre-ticketing), but I also send the product UPC, the vendor style number, a generic item description, case pack information, item sizes, etc.. Some of the vendors fill the order completely on the UPC. Others use their style number. Others use the size and the style.. So there are different needs out there.

But the point is – we only use one document map for our outbound PO and for the inbound ASN. And the same will hold true for our inbound 810 Invoice (once completed). As EDI trading partners, we’ve come to an agreement of what will work best and we’re working together and thinking together with a common goal – transmitting information back and forth without major headaches. We’ve both made changes on each side of the EDI equation to help out the other partner to implement the data. We’ve accepted alternatives to our own documents and changed what we needed to change in order to use those alternative documents. Much like we could (as a people and as a country) make changes to accommodate those alternative fuels..

There are, as I said, a couple of the big “heavy hitters” in the supply chain that hold to the credo of “my way or the highway” type of thinking. You – if you want to trade documents with them – must comply to their way of thinking. There is NO deviation. Resistance is futile. You will be assimilated. We are BORG.. oh, wait.. more nonsense.. But still. Many of you may have had to have dealt with these hubs and suppliers – the EDI “trading partners” that will not accept anything but total compliance with their specs. No deviation from their ways of doing business and doing EDI. You cannot mix styles on an order. You cannot send extra data. You must send via AS2. And on and on and on and ..

These heavy hitters are the stumbling blocks and the hurdles to making this all easy and painless. They’re the ones that don’t want to accept an alternative way of thinking. They don’t want to make accommodations to a different way of thinking. They’re the villains of this piece, much like some of the automakers and oil companies are the villains in the alternative energy ways of thinking. They only want what they know and they only want the way they do it and there will be no deviation. There will be no alternatives. It’s Pink Floyd and “The Wall“.. It’s “Us or Them“..

In the cavern of arcane and sometimes useless (and other times useful – like in a great game of Trivial Pursuit!), another thought is bouncing around off of the lobes and valleys and bumps of My brain – “Can’t we all just get along?”

Author: Craig Dunham – EDI Coordinator
Read more about Craig here: http://editalk.com/contributors/

EDI vs. XML – how readable is XML?

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”.  The DTD and the schema are a lot like the translation specs we use in EDI – in that it tells you what tags will contain what data and what it all means.

But it’s that same lack of a standard that makes XML so much more complicated and so much less a solid answer.  There’s no specific spot for that “Data A” mentioned above.  It can be ANYWHERE… and it’s the job of the DTD or schema to tell you where it is and what it means.

Kay Dietz (of Inovis) offers a great course (through the training roadshow) on XML 101 – giving you the most basics of basics – kind of like a sample when you’re at the store…  “Here, try this cookie.  Isn’t it the best? Aisle 3B, 4.99 a dozen!”  XML is a great thing – offering a lot of possibilities for the transmission of data between partners.  And it’s supposed to be human-eyes readable.

But that’s where the problem comes in….  If (as Bill mentions) you don’t know what this tag is and means, or you don’t know what the abbreviation or code I’m using is, how can you interpret the data.  And sure, the schema or dtd can tell you what that is, but you have to read it and/or format the document to tell you what it means….

XML is, at its most basic, a language.  Just like Cobol and C++ and HTML and Chinese and French and English and…. Well, you get the point.  But let’s take that comparison even deeper….  XML could be very similar to Chinese or English – in that you will have different variations on the same language, all depending upon who is speaking.  There are many different dialects in both languages.  In the Chinese language, if you have two people speaking two different dialects, then there is a lot that they cannot communicate.  In the English language, at least if there are two people and two dialects, most of it can come across.  This isn’t a failing in the Chinese language at all.

XML can be a lot like English or a lot like Chinese.  It can be similar and yet different or it can be different and different.  Let’s say I’m sending you an order.  I can send it with the tag <ORDER> and then the number and the closing tag (don’t forget that closing tag!)…  But what if you use <PURCHASE> in your own system.  Sure, that schema or DTD will let you know that I’m sending you the purchase order number in that <ORDER> tag, but you will have to look at the schema for that meaning.

In EDI, since there is a standard (whether ANSI/X12 or TRADACOM or ________), you know that if I’m sending an order, it will be in the BEG segment at location BEG03.  Always.  If you’re fluent in the “language” of EDI – the standard you’re using – you know exactly what information is in what segment and where to look for it and what format it will be in and all of that.  Just as if you’re fluent in English, you will know that in the Southern Dialect, “y’all” generally means “all of you” in a more formalized version of the language.

In My example above (about the name, address, etc., tags), the same information is carried in the N1, N3 and N4 segments.  And it also gives you a bit more information by the element designator (ST = Ship To, BT = Bill To, etc.) so you can also have the same information – but in a different format:

N1*ST*John Smith~
N3*123 Main street*Suite 123~
N4*Anytown*ST*92345~

And there you have the same information.  Sure, there’s the added symbols of * as an element separator and the ~ as the segment terminator, but it’s still readable, IF YOU KNOW THE LANGUAGE.

One of the things that Bill mentions (in the posting) is that EDI was not really supposed to be “human readable” – as it is/was a way of getting data from a source machine or system to a destination machine or system.  It was transferring data from My systems to yours.  If you want “human readable”, you create a report.  It prints out and has all the “tags” set up as field names (name, address, address, city, state, zip) followed by the appropriate data.

Hmmm… that’s just like the XML format of the data above – in that it’s now suddenly human readable.  But instead of having to have the user (aka the human) try and figure out what they mean – the report tells them exactly what they mean, because the data was transmitted and then translated via the standard spec.

Look at it this way – suppose you’re a maker/seller of … gum…  Just looking at the pack of Trident White on My desk, there are 12 pieces of gum to a pack.  Now, let’s say that you put 12 packs in a box.  Then there are 12 boxes to a carton.  And 12 cartons to a pallet.  That’s a lot of twelves…

Now I send you an order…

XML – <QTY>144</QTY>

EDI – PO1*1*144*EA*UP*445600456729~

In the XML version, I order 144.  But 144 what?  Each? Boxes? Cartons?  Pallets?  In the EDI version I give you My UOM (unit of measurement) in the line item detail.  To get that information to you in the XML format, I’d have to add another set of tags – like <UOM>EACH</UOM> or similar or tell you what that quantity means in the DTD or schema.  As a matter of fact, each element in the EDI segment has to have its OWN SET of tags for EACH piece of information…..  So now I’m sending all of this information to you – think about any kilo-character limits or charges you may have – and that simplicity of XML – that “freedom” now is costing you extra.

The XML for just that simple EDI line would look something like this:

<LINE>1</LINE>
<QTY>144</QTY>
<UOM>EA</UOM>
<UPC>445600456729</UPC>

Each piece of information for the item being ordered has to have a set of tags to designate it.  And for EACH and EVERY order I send you, you’re getting that same set of tags and data over and over and over again.  For each line item (style) I’m ordering, you’re getting all of those characters that make up those tags – over and over and over and over and….  Whereas with EDI, you get – hey, look – a separator (*)….  So, let’s just do a quick character count of the EDI PO1 segment I’ve got up there…. 29.  29 characters…  The same for an XML version of that line…?  Let’s see .. 14 for the qty line .. um .. carry the one .. divide by .. add .. Where’s that damn calculator..?!?  It came to 64 characters, btw.

 And the more “detailed” I make My tags (use QUANTITY instead of QTY, UNIT OF MEASURE instead of UOM) and you can see how it can REALLY start to add up.  Oh, and then you’re also sending that DTD or schema with EACH and EVERY document.  Imagine if you had to send your translation spec with EVERY document you send..

So, yeah, XML has some benefits in the simplicity department.. and in the “human interface” area.  But with no standards to abide by, no rules to play by, that human readability goes right out the window with whatever dialect you want to speak.

Author: Craig Dunham – EDI Coordinator
Read more about Craig here: http://editalk.com/contributors/

How do you EDI?

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 in our merchandising system than some other product line from the same vendor. What this means, is that I may have multiple vendor numbers assigned to a single trading partner – all based upon a product line or a division. Apparel is different from footwear which is different from hard-goods which is different from cleated shoes which is different from winter snow-wear and .. well, you get the idea.

Then, of course, there are still entries for vendors that we may not be currently doing business with – but we’ve dealt with in the past – and there is a chance (no matter how slight!) that we may just buy from them in the future. So they’re in that 1700-plus listing. Add to this, the “factors” and remit-to entries for all of these vendors, if it’s different form the “main” vendor set-up. In cases of the multiple vendor numbers (as described above) we may have them all pointing back to a single vendor number – the remit to – that we never buy from, but all the checks are sent to for invoices.

And then there are the SMBs – the Small and Medium Businesses – that we buy from. The small mom & pop company that makes the best darn badminton shuttle-cock in the world.. now I’m wondering if I spelled that right. Anyway. They make the best dang _____ in the world – and that’s ALL that they make – and we buy it from them a few times a year in some decent quantities.

Or there’s the case of the one-woman show that we order some cooling necktie bandanna kind of things from – she runs the entire operation with a part-time receptionist/secretary, but takes care of all sales and marketing and manufacturing aspects and dealings all by herself.

These are the kind of small and medium businesses that need a super low cost solution for EDI – these are the kinds of businesses that rely upon something as “un-EDI” as the concept of EDI to FAX and FAX to EDI. And sure, there are often just as inexpensive web-based EDI solutions out there – but these small business owners don’t have the time or the inclination to learn the system. Or they don’t like to get on the net – because they only use it for e-mail and even then it’s through dial-up and it’s slow, but it’s simple.

At the beginning of our EDI expansion a few years ago, it was VERY IMPORTANT that we have some kind of solution for the (very-possibly) less than tech-savvy vendors – that solution for the small guy that only has one computer and doesn’t have the time or inclination to get online to find out “you’ve got orders!” Our provider (remember, Inovis) – well, at that time, they were still QRS – worked on and created a great fax based EDI system for use with these vendors and trading partners. When Inovis took over QRS, they sold off the solution – called MEC (Managed ECommerce) to ICC, who now handles those clients.

A while back on the EDI-L Yahoo! Group, I was involved in a discussion of “what is considered EDI” (don’t remember how long ago and didn’t feel like searching through the old posts to find it), and I commented on how these kinds of documents are still considered EDI. And even being able to find a way to e-mail an order – or whatever documents you’re trading – is still EDI. EDI is Electronic Data Interchange, right? And isn’t, at the MOST basic level, an e-mail or a fax a type of EDI..? We’re sending data, right? It is being done in an electronic format, right? Just as we can trace back the data we’re sending – no matter how sophisticated – back to those 1s and 0s (ones and zeros), we can also trace these back to tones and blips and beeps that are sent over a phone line. Is this an overly simplistic explanation of it? Sure, but so is how I liken “EDI document trading” to “e-mail sending” to those less-than-tech people I deal with in other departments.

Even though many of us are pretty technical in our abilities and our ways of thinking, we need to also remember those that are not that technical. Yet they’re also people that are extremely important in the grander scheme of the WHY we’re doing EDI. They’re the buyers that create the orders. They’re the small mom-n-pop companies that make the product we buy and ship it. They’re the former nurses that work in the records room that send your medical history to the new hospital. They’re the math and accounting bean-counting pros that pay the bills and keep the ship afloat on the financial seas.

Even though we’re looking at EDI to FAX and thinking “how quaint, how archaic”, we have to remember all those other eyes out there that will be looking at and working with the data and the documents we trade without our knowledge and our tech-savvy.

Author: Craig Dunham – EDI Coordinator
Read more about Craig here: http://editalk.com/contributors/