This week's blog was written by a member of our amazing tech support team, David Aird. SDQ (Ship Destination Quantity) purchase orders are also referred to as spreadsheet or explosion orders. These types of EDI orders can create efficiency gains by eliminating redundant data that would need to be sent on multiple non-SDQ orders. This reduction of data is accomplished by sending the header data only once as opposed to sending it multiple times on multiple orders. SDQ orders also need a way to send multiple locations for the items being ordered. This is where the SDQ segment comes into play. The SDQ segment is essentially a set of grouped fields that contain a location number and an order quantity for that location. This allows one SDQ order to potentially be expanded into multiple orders.
Photo appears courtesy of Dean Hochman. This week's blog was written by Art Douglas. Millenia ago, Og went into his cave looking for his deer-antler hatchet. But alas, he was unable to find it, for he had many belongings, and a very small cave. After hours of searching, the hatchet was discovered. Later, Og pondered how he could store the hatchet where it would be easier to find. At that moment, Og remembered his friend, Kow, who had a very large cave with many chambers. The two friends struck a deal. Kow would store Og’s weapons in one of his many chambers, so when Og needed them, he didn’t have to search for them in his own cluttered cave, he knew he could find them in Kow’s cave. Moreover, should Og wish to share his weapons with others in the community, he only had to notify Kow of the fact, and Kow would share Og’s stuff with whomever Og has allowed.
Over the years as EDI consultants, we have done modifications to many maps-ones we created and ones created by others. We have seen a great variety of maps, from well thought out and well constructed to "what were
they thinking!" Once an EDI map is written, tested, and in production it should run with no errors that were caused by the map. (Please do not get me started on errors
caused by incorrect or missing data from the ERP system!) So why have we spent so much time "fixing" maps that are in production and have been running fine for a long time? All of the examples below are emergency
situations, which always seems to occur when there is a big rush order.
Maps made of Straw: The prime thing we see in these maps is that the original author of the map hard coded data that should have been retrieved from the database. Sure, you only sell to one department of a company today so why bother trying to find out where that data is on the database? And if it is not stored on the database, why be the squeaky wheel who insists that the data should be a field on the invoice file?
Maps made of Wood: Another "fix" we have done many times is to add segments for discounts and allowances. Again, the map had been working and now it does not cross-foot. What is happening in reality here is changes in business processes – these maps didn’t suddenly "break.” But Management does not see it that way. Another issue is 3rd party testing. Management has had to pay extra to go through testing the EDI documents for a new customer. They
expect the maps to work perfectly as soon as that testing is done. It is hard to explain that testing with "Widgets" (rather than real items), is not the same as testing with real data. In other words, this 3rd party testing is not truly testing the maps, it is really only testing the connection. Unless you have built this post-testing phase into your budget, you will have issues defending the
additional time it takes to get a map running smoothly.
Maps made of Brick: These are the maps where the map author took the time to hard code as little as possible, did a careful review of the mapping specifications to ensure all segments are coded properly and tested for as many situations as possible. Granted, you cannot anticipate every situation and you cannot guarantee that your trading partners will adhere to their own standards, but focus on what you can control and take the time to integrate the map as closely as you can to your ERP system. This will result in a map that has a solid foundation, and will avoid some of these pitfalls described above.
Picture appears courtesy of D.C. Atty. This week's blog was written Aurora team member Kim Zajehowski. Many of our clients ask: How can I track our customers’ product sales and on hand inventory? The answer is the EDI 852, also known as the Product Activity Data transaction. This document can be used to convey that very information to you directly from your customers. The 852 transaction is structured so the customers provide a report to you via EDI with inventory figures for week ending dates typically ending on Saturdays. The transmissions usually are generated by customers on Sunday-Tuesday for the previous week’s snapshot. Quantity Sold (QS), Quantity On Hand (QA), Quantity Returned (QU), Quantity on Order (QP), Quantity in Bonds (QF), and Quantity Inventory Adjustment per physical inventory (QT) are the standard quantities that you may see provided for by your customer. The two most used are the Quantity Sold and Quantity on Hand. The Quantity Returned or a negative Quantity Sold may have to be considered as reducing the overall Quantity Sold on a given product if provided.
Most people know that the Advance Ship Notice (ASN), known in EDI language as ANSI X12 856 and in EDIFACT circles as DESADV, is used to communicate details about a shipment to your trading partner. The ASN typically contains information about the shipment and order details - products shipped with the order, type of packaging and carrier information. The ASN is somewhat similar to a Bill of Lading (BOL), except that rather than accompanying a shipment like a paper BOL, the ASN is sent via EDI when the order is shipped. Timing is critical here as it must arrive before shipment does, which is why it’s called the Advance Ship Notice. And it must be accurate - missing data such as the BOL# and the Pro# can result in costly charge backs. The value of the ASN lies in the fact that when the receiving dock scans the GS1-128 bar code label on the carton, their system can access the previously received ASN to determine the carton contents, thereby saving time by not having to open the carton. Secondly, the ASN informs the receiving party of any difference between what was expected (from the PO) and what was actually shipped, helping the supply chain move along more accurately and efficiently.
Most of that is common knowledge. There are a few things though that can differentiate one 856 from another that are much less widely understood. The first is the difference between Standard Pack, Simple Pack, Pick & Pack and Tare Level. With a Standard Pack 856, the hierarchy goes from shipment to order to item to pack, in other words, only one type of item (UPC) is in a carton, but there may be more than one pack (carton) of those items. A Pick & Pack 856 is slightly different because the hierarchy goes from shipment to order to pack to item, meaning each pack (carton) can have several different item types (UPCs). Less common but another type we see occasionally is the Tare Level ASN. The Tare Level hierarchy goes from shipment to order to pallet (tare) to pack to item, so it's similar to a Pick & Pack with one extra level. Depending on the items being shipped, the Pack (Carton) level may not be required, which brings us to the Simple Pack, also known as the No Pack. This type of ASN has no pack level information and the hierarchy goes from shipment to order to item.
In many, if not most, supply chain EDI relationships, one of the required documents is the Advance Ship Notice. The EDI 856 Advance Ship Notice is what is sent in response to the EDI 850 Purchase Order. If YOUR EDI relationship includes the 856, there is a good chance that you are using the UCC 128 label. UCC 128 labels, or now known as the GS1 128 label, allow your customer to scan the label's bar code and find out what the contents of the carton are before opening it.
An emerging trend in the world of EDI is the disappearance of traditional EDI purchase orders. This is due to a new way of doing business called Vendor Managed Inventory (VMI). What does this mean for the supplier? Before I address that, let’s look at what Vendor Managed Inventory is. The website www.vendormanagedinventory.com defines it as, “A means of optimizing Supply Chain performance in which the manufacturer is responsible for maintaining the distributor’s inventory levels.” So what this means for the supplier or manufacturer is that rather than receiving the 850, which is the traditional EDI purchase order, they will instead receive the EDI 852 point of sale report. Based on the sales information the 852 point of sale provides, they will send the appropriate product to replenish the shelves. The retailer then receives an EDI 855 purchase order acknowledgement from the supplier, notifying them of the order. Occasionally, the 856 advanced ship notice serves this purpose.