Archive for the 'Other Blogs' Category

17
Jul

Doctor, doctor, give Me the news…

I’ve got a bad case of … EDI VIRUS BLUES?

The other day - on, yes, the EDI-L Yahoo Group - I read a post about how an Information Security department of a company was worried about the concepts of viruses and hackers gaining access through the EDI system and the documents we trade via EDI.  Most of the replies were, as you would suspect, “is your infosec group smoking crack..?!?” or something to the same thought..

But it does beg the question - how susceptible to a virus attack, a trojan horse, a hack or some other kind of attack are we through our EDI processes?  There are no virus scanners and other system tools to scan the data as it’s coming into the system via our AS2 or bisync communications sessions.  There’s not much to stop the virus or hack or trojan from getting into the system, now is there…?

Sure, you may have a firewall set-up and the data must pass through the firewall, but you’ve basically given it permission to travel through that wall, anyway, simply by virtue of the face that you’ve given permission to the connection that the data (virus laden or otherwise!) is traveling along.

But that’s about the place when their concept of the attack falls flat…

Look at the way the data is transmitted - more or less as text - viewable as either the hex format or the text format.  And then your translator will go and take those characters and put them, based upon your mapping specs, into your system and populate the various files and data fields that you’ve mapped them to.  That traffic cop of EDI translation is directing the data flow into your system(s) to create orders, receive orders, and so on.

And it’s truly your translator and your map that will end up acting as the virus defense line - by virtue of the fact that the data that they could be sending (that virus code!)  will fail in the translation and never make it into your back-end system.  Even if they use one of the simplest hacks - a buffer overflow - you’re still pretty much safe - simply by virtue of the fact that they can send all the characters and data that they want in the element, but you’re only looking at 10 characters.  Or 12 characters.  Or however long that data field is.

The other thing to remember about these files that we trade back and forth, however, is that they’re treated and send (basically) as a text document.  Nearly all virus programs and worms and trojan horses are programs… They’re EXECUTABLE files.  They’re sent as screen-savers or zip files or whatever - but, at their root - they’re an executable file - a program.  This concept was brought up in the thread on the group, too.  And of course, the doomsday nay-sayers kept on about how you could get the malicious code into your system.

The best counter example to this, however, was the concept that I could create a wonderfully wicked virus - something that would truly erase all of your files on the hard-drive, recreate your “Favorites” (for Internet Explorer) with porn sites all about farm animals, recreate the Unabomber’s manifesto (as written by you, of course) and change all of your image files to naked images of the gender you least want to see naked…  And they’ll all be over 400 lbs of fleshy beauty.  Oh, yes, and your computer will blast - not just play - show tunes and 20s-flapper jazz at full volume…  Yeah, now that’s a VIRUS!!!

But the truth is, I could create this showstopper virus and send you the code - as a .txt file that you could open and view in Notepad or Word (or whatever writing program you use).  But will it cause any harm to your system..?  Nope…  Will those aforementioned show tunes and nudie shots render your system a disaster area..?  Nope.  All because it’s a set of instructions, but they’re not presented in a way that the computer will actually process them and follow them.  They’re nothing more than words - letters, numbers, symbols - characters - that you can view.

EDI documents are the same thing - they’re just characters that you (or your system) reads and populates into those certain fields and files.  They don’t do anything other than that.  It won’t open your ports, start the modem in a receive mode or anything else that could compromise your system.  It won’t go digging into your financial data and give access to any of the credit card data you’ve got stored or give the hacker the keys to your checking account.  They’re just text - readable collections of characters. 

So, go ahead.  I dare you.  I double dare you.  I triple-ripple, double-dog dare you.  Create a virus to be sent via EDI.  And see how many systems you infect.

One of the other things to consider - even if it WAS possible to create a virus and send it via EDI - would it be truly worth it..?  One of the bombs that often shows up on the battlegrounds of the Apple Mac vs. Windows PC wars is how safe the Macs are from viruses and attacks.  And it’s not that they’re truly safer or more secure.  Instead, it’s the law of “supply & demand”.  You’ve got hundreds of thousands of Windows PCs out there in the world.  Millions.  But only a few thousand Macs (by comparison).  So, where are you likely to get the most “bang for your buck” when creating a virus, hack or trojan horse?  By infecting 10% of the population?  Or is it by doing the 90% of the population?  That’s right - it’s the 90% group you’re going after…  You’ve got the most chances for your seeds of evil to dig in and root and create the mayhem and carnage you’re hoping for.

EDI provides that same kind of safety, as well.  There has to be so much forethought and planning on the part of the hacker - he’d have to create a document format in a document you trade AND he’d have to create the map with the specific communications parameters (qualifer, ID, network, etc.) and all of it in a format that your system would allow to translate AND move into your production fields and files. 

Sorry - ain’t never gonna happen….

But, what’s YOUR take on the chances of virus attacks in EDI..?

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/
13
May

say what you mean, mean what you say…

That’s a pretty simple and straightforward kind of thing to say, isn’t it?  I mean, it … says … what it means…   and if we follow the concept, life would be so much easier for all of us…  No more lying politicians or smarmy sales-pitches…  No more “hey, this product was supposed to do this, but it doesn’t” kind of problems.  No more hurt feelings because you answer “does this (dress, shirt, tie, bathing suit, whatever) make me look (old, fat, ugly, whatever)” kind of questions truly - yes, your butt looks like a Buick in that silver sequin thing.  Sorry - a digression.

But you get My meaning, right?  I mean it would be so much easier if we said what we mean and meant what we said and we weren’t mean about it, either.

For example - I’ve been away from the office for about a week, helping My mom - My dear, 73 year old mom - move.  She semi-retired from being a programmer/analyst last year.  I say semi-retired because now she works for the same company - but as a consultant instead of as a salaried employee.  But she also works remotely, with a nice little wifi/broadband modem card stuck out of the side of her laptop.  We’re moving her from Las Vegas, Nevada to the Palm Springs, California area (Rancho Mirage, to be exact).  Now, My mom is a bit of a … collector … OK, pack rat.  Anyway, she’s got about 1800 square foot of furniture - plus 2 car garage, back yard and closet storage of stuff - to move into another 1800 square foot property, but on a smaller lot and partially furnished…  UGH.  I’m also the youngest of 5 kids.  The point?  You’ll see in a second.

My oldest brother also offered to help with the move.  But in the weeks leading up to the actual move, his level of involvement seemed to shift and change and morph from his original “I’ll help you move” to “I’ll come down for a few days and help unload” to…  And of course, he griped and whined and complained and yakked about how much stuff mom has and how she needs to get rid of stuff and blah, blah, blah.

The point is that he didn’t say what he meant and didn’t mean what he said - “I’ll help you move” - and he was mean about what he said, too - “oh, what is all this … stuff?!?”. 

In another yahoo! group I belong to - one related to HTML and website topics - a post appeared about a ‘free giveaway’ of software that was only good for a day.  And the poster was then called a spammer and a hack and told how worthless the post was, blah, blah, blah.  And the poster got a little … miffed … over the responses he received.  But the problem, you see, is that he then bristled - got more miffed - and ranted on how people should just ignore it if they didn’t want it and shouldn’t slam him for posting and all of that…

On another website, I was chatting with a friend and we veered into how often times humor and sarcasm and irony are lost in the written word and how - many times - in a face to face conversation, we can use expressions and voice tones and gestures to imply a meaning - adding a smile or a chuckle to show that something is funny or having a wide-eyed look of fear to imply that meaning of being scared or rolling your eyes to show annoyance or bother or how tired of all of it you are.

Luckily, in EDI, we have a set of standards or a governing body (whether X12, ANSI, VICS, UCC, Tradacom, and more) that tells us what we can say and how we are to say it and what it all means.  We have a document and a set of hierarchy levels and segments and elements and sub-elements that allow us to say “I’m ABC Inc., and I’m ordering from you, XYZ Company, this widget A-12 in size small and in color blue and I want them all to ship to this address and will pay you this money”.  Or whatever information we’re trying to convey.  The meaning and the “tone” of the document is all there - in neat black and white (or rainbow colors if you’re using a color printer).  It’s giving us the “Ws” of the world - the WHO, WHAT, WHERE, WHEN and WHY.  It gives us all the information and the data we need to do what we need to do.

In the written word - we don’t have those standards.  And we don’t have the help of the voice tone, facial expressions and other “standards” that we can use to decipher the words and - yes - the data being conveyed.

The written word is … flat …  There are no real peaks and valleys.  It’s a monotone.  It’s the same level all over.  It takes a talented writer - and there are many of them out there - to convey a feeling via the written word.  Stephen King, Dean Koontz, Anne Rice - all are masterful at conveying fear and horror in their written word.  Barbara Taylor Bradford, Sydney Sheldon, Jackie Collins - they were all good at conveying lust and longing in their romance novels and steamy stories.  But it is still up to us - as readers - to decipher what they’re trying to say and what information they’re trying to impart and what they’re meaning with those words.

And again, we have EDI standards to tell us what that information means.  We don’t have to decipher what it means, because we have a guide - those standards - to tell us what each piece of information - what each bit and byte of data - means.  The document, through translation, says what it means and means what it says.

Imagine how much simpler one of the most well known bits of data in the world - used by thousands and millions of people around the world - The Bible - just imagine how much easier it would be to comprehend it if there was some kind of standard or guide telling us what it all meant.  We’d know exactly what it meant when it says “Love thy neighbor” or “honor thy father and mother” or whatever.  We’d know - without any doubt - what it was all about, Alfie.

Think about how many times that book has been translated over the centuries - from Aramaic to Greek to Latin to German to French to English to … And each time it’s translated, it COULD change a bit.  Think about how in English alone there are three words that all sound the same and have vastly different meanings and spellings - they’re - there - their.  Or wear - where - were (as in wolf).  I can say any one of those words - and without some kind of guidance - or a translation - a standard, if you will - you don’t know what I mean.  Without some inflection or tone of voice, what do I mean to say..?

Those very standards that can be so difficult to understand and implement - and have, let’s face it, a wide degree of variation - still simplify the entire process for us and for EDI and all that we do.  It doesn’t limit us to a single way of thinking and a single line of thought, but it does allow us to say what we mean and mean what we say with a very moderate amount of confusion down the line.

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

ID? We don’t need no stinkin’ ID!

Over on the EDI-L Yahoo group, a poster was talking (ranting?) about some issues they were having with possibly having to change their client’s EDI ISA/GS IDs and all the “trouble”(?) that would cause.  It was a long and convoluted tale about Company A selling a division (that did orders via EDI) to Company B and maintaining that EDI connectivity and activity - using the same ISA/GS qualifier and ID - and something about another division of Company B now going EDI and what ID and . . . well, it was very confusing to read and is still a bit muddled in My head, so maybe go and read it for yourself, here.  Oh, BTW, the ID in question was the DUNS+ ID - where you use your DUNS number and add some number to it.  I don’t know about that, as we use a phone number for our EDI ID.

Company B has also purchased other “divisions” over the years - some EDI, and I guess, some not.  And now some of these divisions may be trading with a whole new set of clients - and maybe even some of the same? - as the original division acquired oh-so-long-ago from Company A.

But I had replied to the original post with the concept that, “way back when” (the poster mentioned that this has been going on for over 10 years!), Company B should have created a NEW ISA/GS qualifier and ID set up for Company B and not continued to use Company A’s ID for so long, even if Company A was not doing any EDI.  It even becomes more of a situation because the ID being used IS, in fact, the DUNS number of Company A being used by Company B, which, presumably, has their OWN DUNS number.  Do you follow?

Anyway, all those years ago, Company B should have changed all of their IDs and alerted ALL of their trading partners to the fact that the ID was changing.  If they had done this, then our poster would have not had any issues right now with their trading partners - new, existing, old, future.  It would be SO much easier now.

The poster also questioned about the “meaning” or the “use” of the ISA/GS qualifier and ID and how it should only be (is?) used to signify a mailbox being used for EDI.

One of the other things that truly captured My attention was when the poster mentioned that “acquisitions and mergers happen every day” and questioned “Do companies really change their EDI ISA and GS IDs every time something about their company changes?”.  And this is something I see on a semi-regular basis.

Going back to the original concept - Company A sells out (a division or a product line or the entire company!) to Company B.  Both are EDI capable.  What does Company B do with Company A’s IDs..?  How do they “merge” the two (or more?) EDI systems and mailboxes together..?  How do they reconcile all of this data being pushed and pulled..?

And the answer goes back to the concepts of “what is a trading partner relationship” - in that they need to work with their existing trading partners to find the best answer.  But even that will rely upon how Company B plans on merging and integrating the Company A products and EDI systems into their own existing product line and EDI systems.  Does Company B want to keep Company A “semi-autonomous” and keep them segregated?  or does Company B want to completely absorb Company A’s products and systems?

If they want to keep it separate, then all they need to do is - well - nothing.  Just alert the trading partners to the new ownership and how the EDI set-up and communications will not change.  Or how they will change (maybe Company B uses Inovis and Company A was a GXS customer), so that the trading partners can make the necessary changes and take the necessary steps to implement those changes.  But they need to communicate with those trading partners the changes that are to come.

If, however, Company B is going to absorb all aspects of Company A and merge them all together, then they will need to alert all of their Trading Partners of that, so that the TPs can make those set-up changes in their systems - pointing this vendor number to this other vendor number’s ISA/GS address and set-up in their own EDI system and with their networks/VANs.

I see this a lot in My daily EDI life.  I work for a major retailer and it is common for bigger companies to acquire smaller companies.  I’ve got one of those situations happening right now.  It’s also common for a big company - which we buy from directly - to also have other companies producing “their” product through licensing of their names and/or logos.  Not every item you buy with the Nike or Adidas or Reebok logo actually COMES from Nike, Adidas or Reebok.  And then there is also the “overstock” production and items that the big companies sell off to other vendors (close-outs) that I may also buy from.  But the point is, that ISA/GS qualifiers and IDs change frequently for some vendors and suppliers.

One last thing that the poster questioned was if a company that uses, say, their telephone number as their EDI ISA/GS ID, should they change their ID every time their Area Code changes..?  And the answer to that, in My opinion, is NO.  Because they’ve been using an established ID - one that has VERIFIABLE TIES to their history - for years.  And it’s still their “property”.  True, it could be possible that another company may suddenly get that “old” phone number as their own with the change of an area code, but the ISA/GS ID still is “owned” by the original company.  It’s all about ownership.

Tying this back to the original question about the use of the DUNS+4 ID, what if Company A - all the way back up there ^^^ - was still doing EDI with other divisions AND still using their DUNS+4 ID?  Well then, Copmany B would NEVER have been able to continue using that ID for the division they acquired.  They would have had to have created a NEW ISA/GS ID right then and there.  Think of the confusion that would occur if Company A and Company B were both sending orders (or supplying product!) to the same vendors..!  Suddenly, I’m sending an order for Widgets from Company A, but it’s going to Company B - just because they have the same ISA/GS ID..!

In a way, think about your ISA/GS as an e-mail address.  I’ve had one of My e-mail addresses for - oh, well over 20 years now.  Now, if I was to deactivate that e-mail address, and in, say, 6 months, somebody ELSE was to acquire it, think of all the e-mails that they MAY get that were originally intended for Me..?  Same thing could go for a telephone number or even a PO Box or other mailing address..!  Think of when you buy or move into an existing house (condo, apartment, whatever!) and you get mail that is addressed to the previous recipient.  Well, you look at the address, see that it’s not for you, and you cross out the address, write “MOVED!” across the front and stick it back in the mailbox.  The post office then will do whatever they need to do with it.

The trouble with that in the EDI world, however, is that you never “look” at that printed address.  You don’t really see the order that is coming in to your system.  EDI is not an “eyes on” or “hands on” kind of business practice.  It’s system automated.  And the system is looking at values.  And the system will only kick out a value if it doesn’t match.  So, in My example above of Company A and Company B using the same ISA/GS qualifier and ID and sending orders to the same vendor/supplier, the EDI system is going to look at that ID and process the order - and isn’t truly going to know whether that order is for A or B - unless you have it doing a match on other data - such as a sold to, ship to, bill to or other such TP specific information - and the error will not get caught until the order is being picked and packed and shipped.  Or, worse yet, it may not even get caught until the order HAS shipped and Company A calls you up and asks “why did you send this stuff to us?  We didn’t order it!” or Company B calls you up and asks “hey!  where’s our order?”..!

The point to ALL of this is that the ID in question should remain with the company that originated that ID!  If I set-up an ID of ZZ/CEDEDITEST, then I should keep that ID with Me until such time that I’m no longer using it and cancel that ID and get rid of it.  It is MY qualifer and ID set-up and should remain MY qualifier and ID set-up for as long as I want it.  And if the ID is definitely company specific - as a DUNS number is - then you bet your sweet aunt’s patootie that I’m not going to get rid of that ID becuase it still relates back to and points to Me and My company!

I may be sounding greedy here, but that ID is MINE!

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

e-catalogs - how do you use them?

My take and thoughts from a post over on the EDI-L Yahoo group about the type of data to provide to a Catalog service.

There’s a lot of “push” these days - and has been for years? - about Electronic Catalogs.   Many of the bigger networks/VANs have a catalog service (Inovis & SPS Commerce come to mind) and there are probably more offered out there by companies - big and small - EDI network or not - that can house that data and provide it to your customer base.

This is where you, as a vendor/supplier/manufacturer, can store your product information data - colors, sizes, UPCs, style numbers, descriptions, and more - that can then be accessed by your buyers - the retailers and resellers - for their systems.  Some of the information is used by the end user and some is not.

Then on the flip side - there’s Me - the retailer.  I subscribe to the catalog service provider (in My case - Inovis) and look to that data for product information.  In our case, we’re pretty much only looking to verify the Style Number and UPC information.  Since we decided LONG AGO to not use the NRF size or color codes, that information is irrelevant to us.  Also, we tend to use our own item description that, again, makes your description somewhat irrelevant.  While some of your description is included in ours, we add extra information that may be related to a season (say, Spring, 2008) and other things that may not be included in your description and is very specific to our way of doing business.

The only thing that you provide to the catalog service that we use is the UPC and your published style number.  One of the reasons we don’t use the NRF color codes is that - well, think about your favorite sports team.  Now, think of their colors.  If you’re a San Francisco 49ers fan - it’s Red and Gold.  Oakland (LA) Raiders?  Silver and Black.  LA Lakers?  Purple and Gold.  Philadelphia Eagles?  Green and White.  LA Dodgers?  Blue and White.  So, pick one..

OK, I will.

Let’s say I’m a T-Shirt maker.  And I’m making a line of sports team T-shirts, those “raglan” style ones, where the body of the shirt is one color and the sleeves are another color and meet at the collar.  I think that they’re called “raglan”…  Oh, and the cuffs and color can contrast to the fabric that they’re attached to.  Think of the baseball style T-shirts you see..  Anyway, I’m getting off topic.

So, I’m making team color t-shirts.  And I’m setting up the one for the SF 49ers.  So I make the body of the shirt red - actually, it’s more of a burgandy - and the sleeves are gold.  So I go to the NRF color code list and - hmm - where do I put this shirt..?  Well, it’s red.  No, it’s DARK RED.  Oh, but here’s a number for Burgandy .. and here’s one that is maroon . . . . .

Or we’ll pick the Philly Eagles.  Green and white.  That’s easy.  Oh, wait - maybe not - is it emerald green?  kelly green?  forest green?  moss green? lime green? avacado, string-bean, sage, eucalyptus, clover…?  ARGH!!!!!  What happened to KEEP IT SIMPLE?!?!?!?

Then we get into the NRF codes for size!!!!  ACK!!!  ARGH!!!  Heart stopping.  Hair ripping..  Head exploding..!  While the size doesn’t have as much “wiggle room” as the colors do, there are still some issues to consider.  For example, we sell ammo for firearms.  And we have the caliber of the ammo as the size.  But what if the ammo provider uses the WEIGHT of the round as their size?

One of the things I’d mentioned in a reply to that post - remember the post I mentioned all the way up there at the beginning? - was that I agreed with another reply - in that he needs to follow any hierarchy set up by the catalog provider and to let the buyer - the retailer - to decide what information they were going to use and what information they’re not going to use.  As I said, we don’t pull down the NRF codes nor the description - we look to the STYLE number and UPC information pretty much only.

So, how do you use catalog information?  And do you push or pull the data - i.e. are you the manufacturer or the retailer?

Author: Craig Dunham - EDI Coordinator @ Big 5
Read more about Craig 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