EDI Related Posts
You are either doing EDI in-house, in which case let the group know which tool your are using. It would be also interesting to know the systems you are translating for (E.g. SAP ERP) and which standards / versions you are using.
Or you are outsourcing your EDI services in which case who are you using?
Mar-Kov provides Electronic Data Interchange (EDI) Functionality to the Process Manufacturing Industry
NEW YORK, N.Y., July 15, 2015 (GLOBE Newswire) -- via PRWEB - Mar-Kov has announced it now provides Electronic Data Interchange (EDI) functionality as an integrated part of its software suite.
Mar-Kov serves Process Manufacturers in a variety of industries including Food and Beverage, Paints and Coatings, Cosmetics, Pharmaceuticals, Flavor and Fragrance.
The core functionality provided by Mar-Kov includes inventory, traceability, and batch recording software for process manufacturers. Mar-Kov has seen a greatly increased customer base in the Food and Beverage industry over the past several years, as traceability, regulatory compliance, GMP and HACCP have increased in importance.
Mar-Kov software can be deployed either as Software as a Service (SaaS) or as an installed client/server application.
As Mar-Kov's footprint in the Food and Beverage industry has grown, adding EDI capabilities was a natural extension. Mar-Kov provides standard transactions for Customer Purchase Order (850/875), Customer Invoice (810/880), Customer Credits (810/880/812), Customer ASN (Advanced Shipping Notification) including GS1-128 labeling (856), Supplier Purchase Order (850), and Supplier Invoice (810).
Read the full release at Global News Wire.
Take this short survey and share thoughts on this topic. In return you will receive the results for FREE. Click https://www.research.net/s/VBR7SC8 to take the short survey.
Customers that transact Orders to you via an EDI X12 850 often need you to send certain, customer specific, fields back to them on subsequent documents. This is often a requirement at both the header and item levels of the order. A common example of a header field would be the department number. It makes sense for the customer to have the department number returned on subsequent documents but we don't have any use for that number in our SAP system other than to store the details and pass it to subsequent documents.
In this example I am going to use the Internal Vendor number as my example at the header level and Customer's PO item number as my example at the item level.
Note: Best practice is to map the Customer PO number to the "Purchase Order Item" field as shown in the diagram below.
The decision tree for customer required fields is as follows:
The ANSI X12 850 from the customer has the following 2 segments:
The REF segment is qualified by the 1st field (REF01) as "IA" which implies that the customer's internal vendor number for us is "115". The customer would like for this number to be returned on the REF segment in the associated 810 Invoice. We can achieve this by updating the external reference field for this customer in master data, but for the purposes of this paper we will map it in and out of text.
The PO1 segment indicates that the customer's PO item number is "20". Once again the customer requires us to pass back this number in subsequent EDI transactions. For the purposes of this paper we will map it in and out of text.
I have used Gentran Server NT's mapping tool to demonstrate what I am doing here.
to the diagram below you can see that when I am mapping the REF segment
I am looking at the first field (the qualifying field for the segment).
If I find the value to be "IA" then I know that I am dealing with the
Internal Vendor number so I need to map field REF02 to my EDI technical
text with the prefix of "Internal Vendor:" (stored in temporary element
REF_IA). The prefix is important because we will be looking for this
text exactly as is when we map the outbound INVOIC IDoc to the 810 in
STEP 7. Element REF_IA is mapped to TDLINE in the E1EDKT2 segment.
REF01 = “IA”;
REF02 = E1EDKT2-TDLINE+17(20); "Starting at position 17 read for 20 chars
IT101 = E1EDPT2-TDLINE+7(10); "Starting at position 7 read for 10 chars
With this technique you can do this for any fields that the customers needs back for any outbound EDI message to them that come from SAP and linked to the Sales Order document flow. I.e. The requirement for an ASN 856 can be met the same way. Advantages of this approach include:
If you have any comments or suggestions just leave a comment below.
It is now so much easier to create and share content with a broad audience and it's with this in mind that I reach out to you, the EDI community...
I am looking for EDI technical experts that are willing to share their tips and tricks with a greater audience. No sales pitches, just raw content with you as the author. If folks like what you put out there they will contact you directly for clarification or potentially setting up an engagement. The first part of getting your next contract is to get noticed. By publishing quality articles on EDIGenie.COM you can get that exposure that you need.
If you have the skills in EDI and wish to get involved in the EDI community then shoot me an email and I'll take it from there - Good luck!" Kevin Wilson - Founder EDIGenie.COM
I read this great post by Faith Lamprey on how EDI is very suited to connecting to the Internet Of Things...With devices and gadgets being Internet, RFID and GPS enabled you can imagine there would be enough information to control every aspect of that device. Faith uses the vending machine as an example. Normal IoT says that a vending machine can take payments and sense the preference of drinks that the current user is looking for. You can offer discounts and provide up-sell or cross-sell opportunities... So how does EDI play a role? Well the vending machine can also manage it's own inventory and potentially place an order for items that have reached their safety stock level. The vending machine has a GPS physical location and the machine itself can have it's own GLN (Global Location Number) assigned, which can be used as the PO ship to address. This is all the information needed to send out a simple X12 850 or EDIFACT ORDERS message to the supplier to replenish the inventory. Once the machine receives the inventory I would imagine it would also be used to send a Goods Receipt (MBGMCR) message to the ERP system managing the Vending machine which would release payment against the invoice for the order. No human touches, no errors, ... plenty of challenges though to get around all the nuances that would be involved in making this seamless. Standards, shortages / overages, incorrect product received, ... Check out Faith's take on it here.
I found this interesting blog post written by Kristen Kearns, Manager of EDI Services for Aurora Technologies. She quite correctly describes some of the nuances in EDI that is overlooked by folks that aren't too engaged in the implementation of EDI. The theory of EDI with it's communication protocols, standards, elements, segments, separators is all good and fine but at some stage it runs in to the brick wall called REALITY!!!To summarize the points that Kristen has made I have compiled the following bullet points:
There are many nuances in an EDI implementations and these are but a few key ones. Check out Kristen's article.
Posted by Shandra Locken on http://www.auroraedialliance.com
Welcome to the first in a series of blogs where we will briefly describe the history of EDI in several different industries. In this first one, we will discuss the history and evolution of EDI in healthcare. Everyone knows about the Health Insurance Portability and Accountability Act (HIPAA) but what many don't know is that in 1991, the Workgroup for Electronic Data Interchange (WEDI) was formed as an answer to the Bush Administration's concern for rising healthcare costs. Essentially, WEDI paved the way for HIPAA to become a reality and many of HIPAA's provisions are based on the recommendations of WEDI. So in 1996, everything changed in the healthcare industry when President Clinton signed HIPAA into law. Before HIPAA, there were over 400 different medical forms used in the healthcare industry. While EDI implementation had been attempted in various manifestations (i.e. WEDI), HIPAA actually mandated it.
EDI was quite simply something that needed to happen in the healthcare industry. Using paper was inefficient and the cost due to human error was significant. One study estimated that EDI could save the healthcare industry $20-$43 billion. Like any major changes in big industry, EDI implementation has been a very slow process. The area that has seen the most changes with the HIPAA mandate is within health insurance. The most common EDI healthcare forms being used are the 837 (Health Care Claim), 835 (Health Care Claim Payment), 834 (Benefit Enrollment), 270 (Health Care Eligibility/Benefit Inquiry), 271 (Health Care Eligibility/Benefit Response), 276 (Health Care Claim Status Request) and 277 (Health Care Claim Status Notification). In spite of all this, many providers have not yet adopted EDI because they are only required to IF they send ANY information electronically. With HIPAA, it's all or nothing. Unfortunately, they don't realize the potential cost savings EDI can offer! See this link for more information about who falls under HIPAA.
Read Shandra's full article at http://www.auroraedialliance.com