Archive for the 'training' Category

08
Aug

It’s all for nothing if you don’t have freedom.

One of the things you may have noticed about Me when I blog, is that I tend to find a quote or a saying or a song lyric or a … something … that makes sense and drives My thinking.  The title of this blog comes from the 1995 film by (and starring) Mel Gibson called “BRAVEHEART“.  For those that don’t know, it’s the story about fighting for freedom in Scotland in the … 1500s?  One of the more “famous” quotes is when Mel Gibson yells out something about how they may kill them (the Scots) but they’ll never take their freedom!

Freedom, however, in something as strict and regimented as EDI may seem like a far fetched notion, but it’s there.  Sure, we’ve got those lovely guides - those HUGE books - of standards and “rules” for the data we’re sending - depending on the document - that tell us what we can send and how it should be formatted and all the rest.  Those standards tell us we should send this information in this loop in this segment in this element and it should be between 2 and 30 characters in length.

But in that rigidity - in that structure - there’s still some freedom.  Just look at the last sentence in the above paragraph - we’re given some freedom in the data - that it can be between 2 and 30 characters.  So there’s some freedom right there.  Then there’s is such a plethora of data and information we can include - information and data that just may not seem like it belongs in the document we’re using.  But we can include it.

We can even have some freedom in what we use to separate our data - whether an element seperator, a segment terminator or whatever.  We have a choice of characters we can use and put into the data flow to show where this piece of data ends and the next begins.

Then, of course, we have a wonderful MSG segment - in which we can include all sorts of “free form” data that can be anything we want to include.  Again, more freedom.  More abilities and places to put information that doesn’t “fit” any one of the stricter and defined elements and segments of the document.  We can send anything - and I mean ANYTHING - in an MSG segment that may be of use to us (as the sender) or to them (our trading partner - the receiver)…  It could be a “please pack in pretty pink boxes” or “have a happy Friday” or “this information is solely for the use of the receiver” or … well, you get the idea. 

And that freedom is an important part of EDI.  Just as freedom is an important part of nearly every aspect of our lives - from where we live, what we do for a living, who we love, what we drive, what we wear and so on.  However, there are times that those freedoms can be curtailed.

Maybe your employer enforces a dress code - you can only wear dark colored slacks, white shirts and simple, mono-chromatic ties.  You can’t have facial hair.  You have to wear black shoes.  You can’t have any personal stuff on your desktop.  Shades of “9 To 5” - an 80’s-era gem of a movie with Jane Fonda, Lily Tomlin and Dolly Parton…  Where the workers rebel against their boss and take control of the division and suddenly life is good and it’s a better place to work!  Ties back into that freedom that William Wallace (Gibson’s character in “Braveheart“) wanted so desperately for his fellow Scots.

These attempts at conformity can truly alter - and not always for the best - the way that the job can function.  If, for example, that MSG segment wasn’t allowed in EDI - and if it was confining and restrictive - we wouldn’t be able to send some of the information to our trading partners that ARE important.  For example - we request that many of our vendors apply pricing stickers to our products.  And we request a certain format and that they include certain information - such as our internal CLASS of the item - on that price tag.  And we use a MSG segment to get that information across to them.  We send, in the PO Item loop a MSG segment with that class number as the data - and we even use another MSG segment to let them (our trading partners) what that MSG segment contains - the data needed for “TICKET ID”.

Sure, I could probably find something in the PO1 line item that I could use to get that data transmitted from My side to theirs, but it’s just … easier … to use the MSG segments, instead.  Maybe there’s not a perfect fit in the existing standards that will “match” up to our CLASS code.  There may be similar things - but maybe I’d rather have the freedom to use that element or data code later on.  Maybe I’ll suddenly have to start sending some other piece of data that the “similar” element was originally intended for.  Where’s the freedom in that?

By putting forward too many restrictions - too many rules - too many standards - you limit what you’re able to do.  You limit what can be done with the data or what you’re sending.  You limit your ability to effectively communicate - and to effectively work - and to effectively get your ideas and points across.  What if I wasn’t able to use movie quotes and song lyrics in My thought process?  You’d not be reading this blog - or - worse yet - it would be boring, dry and as exciting as a textbook on “Analyzing Algorithms about Data Trends in Modern Day Accounting” or something just as … exciting.

Some people have claimed that XML is the “NEW FUTURE” for EDI and that we don’t need standards and we don’t need rules and governing … committees … to tell us what we can and can’t send and how to format it.  They see EDI standards as … constricting … and they can’t see the freedom that is allowed them.

There is freedom all around us in EDI.  The trick is to find it and take it.

“It’s all for nothing if you don’t have freedom!”

Author: Craig Dunham - EDI Coordinator @ Big 5
Read more about Craig here: http://editalk.com/contributors/
17
Jun

comparing apples to … fruit salad …?

I can’t believe it’s been almost a WHOLE MONTH since I last posted a blog and My thoughts…  geez.  But, anyway, I was reading - gee, shocker! - another website (actually, My daily mailing of questions posed on the EDI-L group over on Yahoo!) - and the following question was posed:

“I’m working through a client situation where multiple internal SKUs correspond to a single customer item number. Before I get on my high horse and insist that they always ship a complete customer item in a single shipment I thought that I’d ask if it is possible to send a valid ASN or Invoice in this case.

To be specific:

Client offers internal item numbers P0001a, P0001b and P0001c for sale as A0001. It is murphy inevitable that the shipping department will eventually ship P0001a, P0001b and P0001c in separate shipments (on separate days). Is it even possible to:

send an ASN that 1/3 of unit A0001 shipped on June 16, 2008

or

send an Invoice that 1/2 of the cost of unit A0001 is now due for that 1/3 A0001″

Now, here’s the thing to consider - how was it ordered…?  If the trading partner sent a PO for 100 of P0001a, 100 of P0001b and 100 of P0001c, then you need to ship 100 of each item.  If the trading partner wants all of them to ship together - then you need to follow the partner’s shipping instructions or requirements. 

And the same can be said for invoicing, as well.  Don’t invoice a partial shipment of a partial product.  Chances are quite good that you won’t be paid until the full shipment of the entire order (especially if it’s a COMPONENT set - more on that below!).  There are some fine lines here that can and may be crossed, but BOTH sides of this TRADING PARTNER RELATIONSHIP need to communicate about what is going on and what is expected.

One of the answers given over on the EDI-L group was about the possibility of ASSORTMENTS and CASE PACKING issues that are relatively common in the apparel industry.  In some cases, it may be called a “MUSICAL PACK” in which you have a single style of something - a shirt, a shoe, shorts, underwear, whatever - in assorted sizes in a single case.  For example, you’d have a case-pack of 24 and that 24 would be broken down by size, all the same style and color:

  • 5 Small
  • 7 Medium
  • 7 Large
  • 5 X-Large

That musical pack (or here’s the concept of assortment) could be broken down by color, instead of size - so that you’re ordering t-shirts, and they’re also packed in cases of 24, but all of a single size, but multiple colors - either pre-set selections or not:

  • 3 Black
  • 3 White
  • 5 Blue
  • 5 Red
  • 4 Green
  • 4 Yellow

Of course, that case could just be “here’s 24 shirts in colors” and whatever the order picker pulls from the shelf is what’s in the box - and it could be ANY quantity of colors - from 23 black and 1 yellow to 12 of a color and … well, you get the idea.

But it all comes back to shipping and invoicing what the trading partner has ordered or requested.  It still all goes back to the relationship (there’s that word again!) you have with the trading partner and what solutions have been worked out to take care of situations like this - either before they happen or on the fly as they occur.

One of the things I mentioned above was the concept of a COMPONENT set.  This CAN happen a LOT in retail - depending on the product line.  For example, in the sporting goods world, it’s quite common to have a weight set - barbells, dumbells, weight plates and so on - be packaged in 3 or 4 boxes.  But it’s a single COMPONENT that the sporting goods retailer sells.  In apparel, you could have a warm-up set (jogging pants & sweatshirt) or even a 3 piece men’s suit (slacks, vest, jacket) and when you order them up from the factory in ________, you order 100 slacks, 100 vests and 100 jackets and you combine them into 100 complete suits.  When you sell these to your trading partner, you sell them as a complete suit.  But someplace along the line (in your own systems, probably) you’ve converted those 3 seperate and unique - although related - items into a single item - a single SKU or UPC or Item Number.

That’s what we do when we’re ordering those previously mentioned weight sets.

Let’s assume that ACME Weights and Bars is selling a 100 pound weight set.  There are 4 five pound plates, 4 ten pound plates and 2 twenty pound plates.  Plus then you have the long and short bars that you hang the weights from and then you have the locking ring or collar that holds them on the bars.  And you package all of this in 4 boxes - 1 box for the collars, 1 for the long bar, 1 for the two short bars and 1 more box for the 10 plates.  Chances are, however, that the collars and the bars are probably universal and you would use them for nearly all of your weight sets - whether 100 lbs, 150 lbs, 200 lbs or whatever.  So you probably don’t limit the item name/number to just be with the 100 lbs set.

Anyway, now Willy’s World of Weights orders ten of your 100 lb sets.  And when they order them, they have to order 10 of item A (100 lb plates), 10 of item B (bars long), 10 of item C (collars) and 10 of item D (bars short).  But when Willy’s World of Weights SELLS those sets, they sell them all under one item number or SKU.  It’s now up to Willy’s World of Weights to convert those 4 different items into 1 item for sale.

That’s what we do when we order weight sets - we order them by four unique SKUs and Item Numbers (which are also 4 unique UPCs).  The vendor ships them - hopefully all at once (more on that below) - and we receive them.  Then we assemble them (virtually) by transferring all of the ordered and received stock of Items A, B, C and D into our single SKU 100 LB Weight set.

Now, one of the other questions or concepts posed by our poster is the concept that it is “inevitable that the shipping department will eventually ship P0001a, P0001b and P0001c in separate shipments (on separate days). “  This, however, falls on the fault of the vendor.  It then becomes the issue of the vendor (supplier) to be sure to quickly and accurately - and with GREAT COMMUNICATIONS - alert the trading partner to this dilemma.

In the retail world, it’s not such a huge issue if you have parts of a component set ship and have back-orders for the other parts; you just hold on to parts A, B and D until part C arrives and then you can sell them. 

Where this can and WILL cause problems, however, is in the manufacturing sector.  Take a look at the coat or jacked you wore today (or just have hanging around your desk, office or cubicle.  There are probably a few different kinds of material involved - there’s the outer shell (say 100% cotton) and then there is the inner shell or lining (nylon or polyester) and then there may be cuffs adn collars (50% cotton, 50% Lycra) and then maybe even more in a liner/filling (50% cotton, 50% polyester).  And then there are the plastic buttons or metal zippers and the possible sewn on decorations….  and then there are the labels and the … again, you’re getting the idea? 

Well, let’s say that Cozy Coat Mfg is making that line of jacket.  And they’re ordering all of the supplies to make that jacket from FM Fabrics and Materials Inc.  Of course, common sense suggests that Cozy Coats isn’t ordering the materials in the just-in-time way of thinking - that they’re going to make 1000 jackets an order the materials - just in time - to put those 1000 jackets into production.  No, chances are they’re going to have mounds of the filling, boxes of buttons, bolts of the fabrics and … z … z … what’s a container that starts with z…?  Anyway, they’re going to have much of it around and in stock to produce what they need.

But still, if they’re ordering enough materials and parts to make their finished product, they’re keeping most of it on hand at any given time to not have any production delays that will result in their Summer 2008 line of jackets getting out late and not being in the stores until November of 2008 - thereby missing the concept of seasons…

But back to partial shipments - and the poster’s question - the answer to his question would be an almost absolute NO - but with some qualifications and possibilities of a “yes”.  It all comes back to communicating the problems - beforehand or as they occur - with your tading partner and coming to an agreement or compromise that benefits both parties.

And watch out for those 20 pound weight plates - they’re killers on the toes!

Author: Craig Dunham - EDI Coordinator @ Big 5
Read more about Craig here: http://editalk.com/contributors/
09
Apr

Ch-ch-changes…

Ch-ch-changes… Turn and face the strange…” - David Bowie belted out back in 1972.  Well, 1971, actually, but the song wasn’t released until 1972.  And, as usual, I digress in the details.  But still, some of the lyrics are quite appropriate today.  And especially in the world of EDI.  Good ol’ Ziggy Stardust (aka Bowie) sang out:

                                   “Still don’t know what I was waiting for..

That’s something we hear a lot in the EDI world - once somebody finds out how well EDI can help them.  They don’t know what they waited for - or balked against - when given the option of EDI.  Once they’ve seen-the-light, it suddenly becomes a no-brainer.  But at the time, it was strange and unknown and a change.  And we all know what people can be like when it comes to change.. Don’t we?

  • Change is hard!
  • What’s wrong with the way we’ve always done it?
  • Oh, great!  Now what do I have to learn?

Right now, I’m working with our Accounting group in getting them to embrace and accept the 810 EDI Invoice.  And, for the most part, I’m lucky that they’re open and willing to “face the strange” and go with it..  However, where it’s making My life a living hell is that they expect everything to be done.  Now.  2 Minutes ago.  Yesterday.   ASAP.  Jump!  Jump!  JUMP!!!

Think about the time that you first began to become a part of the EDI world  You probably came from some kind of MIS position - either an operator or a programmer or an analyst or .. Or, you came from another group that your EDI program touches - either the accounting group or the buying group or the warehouse group  or .. Well, you get the picture.

                                        Embrace the change..

And think about the changes (Ch-ch-changes) that you encountered along the way.  Think of how you had to ch-ch-change the concepts that you held and others kept of the way things were and how they were going to be.  Think of how you and others in your organization had to ch-ch-change the way you did things - things that had been done “that-way” for years (or even longer?)..

Some of the pods of flesh on this planet are pretty adept at change.  Others - well, not so much.  No, they’re like the stubborn mule in the old Western-Comedy, leaning back, digging in their heels and not budging.  It takes a lot of force to get that immovable object to take that step forward and “embrace the change”..

Then you sometimes have to try and keep up with those changes..  In recent articles, we’ve touched on many of the changes coming to and infecting EDI as a concept.  Things like AS2, XML, E-Catalogs..  Ch-ch-changes, indeed. 

But are any or all of these changes going to help or hurt you..?

And how good are you at accepting and going with change..?  How good are you at accepting change and working with it and finding the solution to the newest ch-ch-change coming at you..?  Think about your daily commute to and from work.  There’s an accident at this highway and that street.. or the road is closed because of “police activity”..  Or there’s some guy protesting ________ (the war in Iraq, China’s hosting of the Olympic Games, gays in the military, our government’s failed policies, the new Wal*Mart coming to town, whatever - fill in the blank) from that bridge, hanging a sign over the highway..  How quick are you to think - “hmmm.. I can detour here at Main Street, go down 3 blocks to Fifth Avenue, hang a left and be back on the freeway beyond that problem”..?  Or do you just sit there with a bunch of other commuters, waiting for your turn to squeeze through the half open lane to pass by the wreck, not willing to deviate from the norm?

How well you handle change means a lot - both professionally and personally.  Change is an integral part of life.  It’s something that creeps up on us on little tiny quiet feet or comes barrelling into the china shop and disrupting lives all around.  But change is inevitable - just like death and taxes.

And change is big in EDI - no matter how static and stable the platform and concept may be.  There are - and will always be - changes to the way we do things.  Standards are often being updated.  Segments are added or deleted from the document specs.  Suppliers and buyers are often requesting new information to be sent or received.  New applications are added to your back-end systems and now you have to map this segment/element to this other file and record over there.   The PO box you use to received payments or invoices has altered names, and the data in your documents (POs, Invoices) must reflect that new alteration.  You’ve adjusted your factor or payment “lock-box” location or service provider.  You’ve signed up with a new VAN/Network and have a new qualifier and ID..  All of these are ch-ch-changes.

               “I watch the ripples change their size But never leave the stream..

These are just a few examples of the ch-ch-changes you may face.  And there will be many more, too.  I’ve had our EDI program up and running - well - WE’VE had our EDI program up and running since the very late 90s.  About 5 years ago, we changed our translator (upgrade) and then added a new document (the ASN) and added and expanded our trading partner count by .. well .. multitudes.  Then we added some information to our PO (requested by some of our suppliers) and changed a terms code and .. well, you get the idea.

Ch-ch-changes are important and everyday.  Expect them, plan for them and implement them.  And do not be afraid of them. 

Author: Craig Dunham - EDI Coordinator @ Big 5
Read more about Craig here: http://editalk.com/contributors/
31
Mar

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/



Contribute to the Community

EDITalk.com is run by EDI guys for EDI guys. Want to write a article or blog post? Just let us know on the fourms and become a contributor today! All credits given to any article posted on the web site.

Categories

 

August 2008
S M T W T F S
« Jul    
 12
3456789
10111213141516
17181920212223
24252627282930
31