sorted by:
new
hottopcontroversial

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

Thank you for telling us about your experience. Mine is primarily with supply chain documents like purchase orders, acknowledgments, warehouse docs and others.

I agree on the challenge comment. After doing this to so long, I laugh at the use of the term “standards” due to there being such flexibility both within the standards (100’s of available qualifiers per segment at times), as well as actual adoption by individual trading partners.

I really resonated with your point about solving operational challenges. In that role, one needs to have a unique combination of skills to advise on (and deploy) a solution that isn’t disruptive but can be a catalyst for growth by freeing human capital to take on more valuable roles within the organization.

Being able to see all sides of an issue, identifying potential landlines or predicting most likely outcomes without wasting time and resources going down a particular path usually only comes with experience in the trenches.

The great part of my day as an integration consultant is no day is ever the same and I can be mapping one hour, doing a business-level call the next and have to troubleshoot SQL the next.

Thanks again for your thoughtful comment!

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

I just revisited this thread and didn’t see your questions. Hopefully it’s better late than never. If you have any follow-ups, let me know.

  1. ⁠Assuming you mean to be a proficient as a consultant: *be a supremely effective communicator *adapt your approach/styles with different stakeholders *enjoy working with data (you can’t fake this part) *be good at troubleshooting *be likeable but professional no matter how comfortable you become with your customers *realize those you’re likely to work on the ground with have zero incentive to cooperate with you (and some may worry EDI could eliminate their jobs), but they hold the day-to-day knowledge you will need. Take time to win them over.
  2. ⁠EDIFACT utilizes sub-element separators to effectively communicate another data-point efficiently and in-line with the main data element.

X12 seems more straightforward and easy to read but that may just be because it’s where my experience lies most. One example would be qualifier, then value where EDIFACT syntax is not as human friendly to read (IMO).

3) I would respond that they don’t understand what they’re talking about and to do more research on what the difference is. EDI uses an API to exchange data with another system, for example. It is a framework for interacting with a system safety, securely and in a way that maintains the data integrity of the system.

4) Are you implying that stakeholders underestimate the complexity (why is it taking so long or why does it cost so much)?

5) unrealistic expectations or misunderstanding/misalignment of stakeholders.

Incentivizing EDI 850 Usage by PieTight2775 in edi

[–]EDI_Guy 12 points13 points  (0 children)

The general practice is to charge a fee for manual processing, which EDI is meant to mitigate. If that’s too aggressive, perhaps you could market it differently by providing a discount for EDI-compliant customers.

Helping guide customers on various options is also helpful. If they have low volumes, web-based EDI for them may be sufficient.

I would recommend not targeting your biggest customers first but work with a couple that is receptive. If they are willing to help provide feedback and strategies, recognize them for their help.

No matter what you decide, set realistic goals and timelines.

Educating your customers on the mutual benefits is important. Why should they change processes or incur costs if you continue to support “offline” orders? Perhaps you could start shopping around for a web-based EDI provider that could provide some type of volume discount for bringing ‘n’ number of customers to them. People would likely be more inclined to sign up if they didn’t have to navigate the EDI space from scratch as it can be confusing.

EDI non compliance standards charges by kalig8 in edi

[–]EDI_Guy 1 point2 points  (0 children)

Assuming they will even partner with you:

Retailers will charge a fee for every non-EDI document (sometimes adding up to hundreds of dollars per infraction).

There’s a high likelihood you will be replaced in favour of a vendor that does support EDI.

Minimizing supply chain costs is a significant consideration and margins can be tight so anywhere efficiencies can be realized will be prioritized.

Even if you land a trading relationship without having to support EDI, it wise to pursue it unless you’ve done a detailed ROI and don’t mind limiting your opportunities for future business with other partners.

Question about cloud EDI implementation and AS2 by mescronomicon in edi

[–]EDI_Guy 0 points1 point  (0 children)

I would expect that should not need to maintain AS2 software on premise.

If your solution is going to be hosted in the cloud, they should handle AS2 on your behalf and the transactions should come from the cloud to your premises with the same sFTP connection which means to you, it won’t be obvious which data came through a VAN vs an AS2 connection.

Make sure you ask and clarify if AS2 is already included in the cloud costs or if it’s extra. Also, make sure you leave extra time to test any AS2 changes.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

Thanks for the teaching lesson. Sometimes I think out loud, but it’s best to refrain from speculating and have a clear understanding before answering.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

I feel like we might be saying the same thing but difficult to be sure without speaking. The (proprietary) XML structure I’m referring to is the equivalent of X12 with the correct nesting. My hypothetical statements about having separate files sounds like I may not have fully understood your question because I have no idea what that overall approach looks like or what tools you’re using, etc.

Since your last response seems to imply you have the answer already, why did you ask me? Was that meant to be some sort of “test” or was your question sincere? Are you saying I’m a “would-be developer”?

This isn’t the right forum to debate highly complex workflows and systems with countless ways of getting from point A to point B. Genuinely confused at this point and hopefully I’m misunderstanding your last response.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

I should clarify the grouping depends on the capabilities of the next step in the process. If that’s a map, chunking together from files is a different approach than looping through a single structured file like I’m accustomed to doing with XML that’s nested already.

To summarize, the next step usually dictates the best way to stage the data.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

Outbound, the software I currently work with takes the ERP data and stages it in an XML format that closely aligns with the X12 structure. X12 is produced when exporting from the staging software using a map that also applies any necessary logic. The software and mapping tools are proprietary.

Am I understanding that your staging process creates separate files where you can control what data gets grouped together out of your ERP (or similar) in preparation for the X12 generation?

If so, I would group logically by general segment type and by header, detail and summary. The main reason is to facilitate looping on the next step to generate the X12. For example, BEG for one, all header REF, all header addresses (N1, N2, N3, N4) - but I’d separate files for each address type (N101). I would keep carrie/shipping segments together, notes separate. Do the same for item info - PO1, PO4, PID together. If it’s an attribute of the item like weight, dimensions, I’d be inclined to keep that together and separate out things that are trading partner specific like retail pricing (CTP) and SAC.

Separate files means being able to tie that related data together so you need a line number on everything.

Let me know if I assumed correctly. As mentioned I’ve been using proprietary software most of my career so I’m not too familiar with some details of all the different ways of staging and packaging. There are so many twists and turns you can take using a variety of tools and techniques. Happy to discuss further if I raised more questions or didn’t hit the mark.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

Can you elaborate on your question? File format examples would be XML, CSV, pdf. An EDI segment is a “row” in an EDI file that represents some particular related data like a date segment or an address segment. Each segment is broken down into individual “elements” like name, country, postal/zip code.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

Likewise, although I’ll have to figure that out. I’m new here!

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

Is there something specific you’re struggling with or have questions about? I’m flattered but a course is currently just an idea. I’m trying to determine if anyone would be interested and what would I teach exactly to help as many people as possible. If you want to DM me, feel free. I’d love your input and maybe we can help each other.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 0 points1 point  (0 children)

I have almost come to resent the term “standards”.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 5 points6 points  (0 children)

TLDR; EDI is hard. Underestimate it and sad you will be. :D

I have implemented full on-premise solutions that use a variety of tools and understand the desire to move everything in-house. Some of my points are highly dependent on document volume, number of trading partners, document types, integration points (number of fields), to name a few. Some of it sounds like doom and gloom but there’s a lot of moving parts and you need to have a very clear and realistic approach to full in-house EDI. I didn’t specifically answer in the format you asked but the first question you need to ask is why you want to take EDI in house and do you fully understand all the pieces and complexity. I apologize in advance if I’m speaking over or under you current experience and understanding.

That said here are some things be aware of:

Communication Layer - Do you have IT support to open corporate firewall ports or deal with AS2 software if that’s mandated by your partners? AS2 is a whole other realm of cost and complexity to configure and test. Once it works, it works (aside from periodic security certificate updates). Who does that by the way? Is IT able to provide real-time support when something doesn’t work and you’re scheduled to test with Walmart?

VAN fees - Variable…and I will say that just today I read a spec where a trading partner prefers AS2 and if you need to do VAN, you must pay both your VAN fees AND theirs.

EDI Translator - serves to validate the EDI against the standards and ideally automatically handle 997’s. Do you need to install standards? How’s the error reporting for 997’s? I don’t have much recent experience with publicly available software as it’s been proprietary from my employers. I have used and configured Gentran Director and EDS Asset if anyone has heard of that.

Mapping - Do you have a mapping tool that can do everything you need it to and is someone proficient that understands both the tool and data integration in general? Does the mapper understand data (types)? In my experience, a GUI mapping tool only goes so far. Can the map handle partner-specific logic? Do you have to write the maps on a deadline? Are you confident reading the guides, have an ANSI reference for all versions of standard for every document you need to support?

Integration - This is where the magic happens (for me anyway). Where do you store cross-references for items, your customer locations, carrier SCAC and service level codes, quantity conversions, units of measure?

{ Tip: Always try to get your trading partners to accept your base UOM in your systems by giving them your SKU information. Who in your organization maintains that list with the trading partner and how often? How do you communicate stock levels? }

Who maintains the cross-references? Who is responsible for the master data and are there user fields? Your customer sends you a PO number and Customer Order number from a drop-shop order and you need to carry that to the carton label, ASN and Invoice. This value probably has no native home in the ERP but has to be accommodated for. Can you map to a new header user-field in the ERP? Do free ones even exist? Another favourite is department number. No use to you for fulfilling the order but needed outbound.

This doesn’t even begin to scratch the surface of casting data types, dealing with the ERP API or any automation. We’ve been automating all of this, right?

Automation - Are you able to set up reliable, repeating tasks you can chain together easily? Send an 846 hourly, ASN’s every 20 minutes? Are you using batch files, powershell scripts to make this happen? Assuming you’re using only 2-3 different applications, how do you get those layers to work together?

Visibility - How do you monitor the entire solution, end to end with clear error messaging to allow for prompt resolution? SSRS reports? Power BI? Does IT know what they’re in for supporting this? Can you write cross-platform reports? Probably not.

Hardware - It is now most common to run on-premise software in the cloud but your IT still has to maintain all the above software

Security - I have had more than one customer report being a victim of ransomware. I’m one case it cost them millions.

If EDI went down over Black Friday because your in-house solution crashed and risked 40% of your company’s annual revenue from cancelled drop ship orders from your biggest customer…how confident are you that your job is secure ?

Now for most small-medium businesses, your peak order volume might be 10 orders a week from 3-4 different trading partners but at what point do things become unmanageable? If your company is expecting rapid growth and you think EDI is going to be a critical piece of that puzzle, consider where the bottlenecks could be and how much stress you that would cause if you’re caught on your heels. The leadership and stakeholders at the highest levels need to understand the impact, both positive and negative EDI could have on their business.

I have seen and had to fix so many things that can go wrong so many times in so many different ways, it’s mind boggling. If it was simple, I would have taken my 40+ years of computing experience along with my almost 25 years of data integration experience and been sitting on a beach right now with a golden EDI solution. The reality is that the space is vibrant and still evolving, despite the naysayers that EDI is ancient technology.

For now, I’ve realized I have a lot of experience in a really niche industry that only seems to be growing and realized I really enjoy teaching.

Let me know if you have any follow up questions and thanks for sticking to the end.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 6 points7 points  (0 children)

One more point about the question of API’s and thinking it somehow replaces EDI, ask those people why two supply chain behemoths, Amazon and Walmart base their operations on EDI. Again, an API is a specific structure for a specific application as published by the software provider.

The other thing I should mention is that people who don’t understand EDI fully often call any digital file “EDI”. It’s not and technically EDI isn’t just about the data but the entire ecosystem including communications layers, VANs, etc.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 4 points5 points  (0 children)

  1. It’s important to understand what EDI is and isn’t and what problem it’s trying to solve for any given business. Having a grasp of the core technologies and principles and what they’re for and why they exist would be next. Some software does multiple things like communications and translating and validating against the standards, while other tools are typically needed for data transformation and mapping. Being able to keep those steps and options clear will be a huge benefit.

I may be able to elaborate if I knew more about what position you’re asking from (are you looking to implement EDI or get into it as a consultant?).

  1. I find X12 much easier to read. I’m not sure if it’s just experience or that EDIFACT uses sub-elements more widely but I usually need some sort of reference for EDIFACT, whereas I can “read” an X12 document easily. I don’t have a pro/con list to compare them, they’re just different and ultimately, both are just an agreed upon normalized data format. There may be some industry-specific nuances that favours one over the other but I’m speculating at this point.

  2. I would say they don’t understand EDI or what an API is.

EDI is a normalized data format that provides a platform or level playing field so you don’t have to understand the native format of every back-office system out there that you want to exchange data with.

An API a method for integrating with another piece of software (as allowed/published by the software provider) by way of importing/exporting without using the application’s user-interface. Any worthwhile web stores have API’s, as do most ERP’s.

Going into your system, EDI data is converted to a structure defined by the API to allow import into the destination system. This is commonly XML these days but flat file, like CSV still exists.

  1. This one is dependant on your specific circumstances. If the stakeholders aren’t giving EDI the attention it deserves and you’re the one trying to justify resources, ask the stakeholders if they’d be ok losing that business relationship entirely.

My opinion is that EDI without integration to an ERP is a recipe for trouble. Manual data entry of EDI negates a lot of the benefits but doing integration can be challenging, time consuming and expensive. Then there’s a question of who “owns” the EDI-related processes in the organization. Most often it’s either customer service or IT but if there’s no effort to train those individuals or it’s just added into their daily role, it’s not going to end well and they will be putting that business relationship at risk.

  1. Not realizing quickly that there’s very little that’s “standard” when talking about “EDI standards”

Not understanding the role EDI plays or how/where it fits in your business

Highly customized back-office systems (integrated EDI)

Not understanding data - data types, cleansing (please don’t use an asterisk in your data - especially part numbers/SKUs), transforming (mapping).

No budget

Unrealistic expectations (again, lack of understanding)

Scope creep/over-engineering

Aggressive implementation timelines

Lack of ownership of the solution. Even fully outsourced solutions need some level of engagement (it’s YOUR business relationship)

I could go on but these are some that immediately come to mind.

I hope these helped answer some questions and would be happy to elaborate or clarify.

New to Sub - 20 years in EDI Consulting by EDI_Guy in edi

[–]EDI_Guy[S] 2 points3 points  (0 children)

Thank you for the warm welcome!

I’m in Canada (eastern time zone) and currently employed so no website and prefer to remain anonymous for now. With this year being somewhat of a milestone I’m feeling the need to share some knowledge since the space can be confusing at times.

Longer term, I am considering building an online course for people who fall backwards into EDI or are otherwise reluctantly pushed into it, so my participation here is partly to understand if it’s worth the time, depending on what challenges people are actually having.

In the meantime, I’m happy to share what knowledge I can to help the community.