It's actually a great process once you understand it and both ends of the exchange understand it (or tell you that you'll do it their way, as you've found).
10 minutes is a nice leisurely window, do not complain. I set up the 862/856 process for two plants in Mexico that were across the dirt road from each other and the customer's line worker would push a button (well, not exactly) when they ran out of parts and expected the supplier plant guy to walk over more parts on a hand cart. And, yes, the ASN had to be there and processed into the ERP before he finished his walk. We told him to walk s-l-o-w-l-y...... I was so tempted to hard code the SCAC = FEET. Leah ________________________________ From: Jim Greeney <[email protected]> To: "[email protected]" <[email protected]>; Brian Lehrhoff <[email protected]> Sent: Thursday, December 1, 2011 10:23 AM Subject: Re: [EDI-L] Re: EDI Software and handling the 860 (PO Change) business process Thanks. When you look at the automotive industry and have to deal with 830 forecast and 862 shipping schedule transaction combinations for either JIT or Kanban/JIT it can become interesting to say the least. I had one automotive supplier that was literally 10 minutes down the road from the automotive manufacturing operation and they required an 856-ASN be received before the shipment was delivered. We created a set of real-time process triggers to accomadate the customer's requirements. In another case Chrysler was sending multiple 830's for the same forecast periods and they did not arrive in chronological order. We succeeded in getting it right because it was just a SMOP (Simple Matter Of Programming) (sarcasm intended). Honestly it took significant time and expertise to pull it off, I was lucky to be working with some of the best in the industry. --- On Thu, 12/1/11, Brian Lehrhoff <[email protected]> wrote: From: Brian Lehrhoff <[email protected]> Subject: Re: [EDI-L] Re: EDI Software and handling the 860 (PO Change) business process To: "J" <[email protected]>, "[email protected]" <[email protected]> Date: Thursday, December 1, 2011, 7:30 AM that's actually a very nice assessment. i would like to point out that the canban process is specifically designed to integrate with edi, but that process is built on scheduled deliveries, lead times and uninterrupted processes. your typical WD can fall into many categories - from "order now, deliver next season" to "ship fedex today for shelf tomorrow." the arenas that i play in (where 860s trade) typically have a disconnect between the EDI process and the warehouse. and sometimes an 860 arrives after the merch is on the truck, causing all sorts of other nightmares. your mileage may vary, because these company's business processes vary. Brian Lehrhoff, EA ([email protected]) Messaging Consultant 201-913-4506 Upgrade your Quickbooks for 20% off at http://ea.brianlehrhoff.com Circular 230 Notice is located at http://ea.brianlehrhoff.com/230notice.html ________________________________ From: J <[email protected]> To: [email protected] Sent: Wednesday, November 30, 2011 6:08 PM Subject: [EDI-L] Re: EDI Software and handling the 860 (PO Change) business process Although this narrative has been covered before I will post it here for educational purposes. For those of you that feel you understand the process for determining if 860 transactions could and should be electronically integrated with the back office system you can stop reading here. Integrating the 860 with the back office application can be accomplished; the real questions revolve around a number of factors that for the most part are outside of the EDI process. These are some of the questions that need to be answered before you can make a case for seamlessly integrating the 860 transactions with the back office system How many 860 transactions do you receive during the sample periods? Select sample periods based on any seasonal peaks and valleys of transaction volume. As an example if company A builds widgets and they supply company b and company b's customers only buy widgets during the second quarter of the year and you require a 30 day lead time from Order to Delivery you would want your sample period to start March 1st and continue until May 31st. This sample period should provide enough data to determine whether the volume of changes warrants further research. For this discussion we will assume that the volume is great enough during the `peak' period to warrant this additional research. The second sample period would be the period of the year with the smallest number of transactions. We will assume that the ratio of 860's to 850's is roughly equal to the ratio identified during the `peak' period. Warning: Business Decision Ahead. Now that we have the metrics on volume we need to determine how long it takes and how much it costs currently to successfully manage these changes. Let's say the number of changes per 100 orders is 30 and it takes 6 minutes to provide that change information to the responsible human and have that human process it. This human makes $20/hour and they can process 10 (60/6) changes in an hour, each change costs $2. If the total number of transactions per day is 1000, the number of changes is 300, multiply that by $2 (the human resource cost) giving you a cost of 600.00 per day, multiply that by 5 (days in a week) time 13 (number of weeks in a quarter) to give you an unburdened cost of $39,000 for the peak quarter. Now I will assume that the other 3 quarters of the year are equal in transaction load and that load is 50% of the peak period load. So we now have $39,000 + (19500*3) = $97,500 unburdened human resource cost. To roughly calculate the burdened cost we'll multiply the unburdened cost by 1.25 to give us a burdened cost of $121,875 (roughly 2.5 FTE's). The business now needs to decide if it is worthwhile to spend the capital to go to the next step. This next step is very critical to the success of the initiative and the burden should be on the order entry and order change personnel. This step will be best accomplished with as much raw data from the peak period and at least one of the other 3 quarters. As we analyze the 860 transactions relative to the originating 850 and the specific business requirements pertaining to if, when where, how and why the changes are processed. We are going to group these changes into these 3 groups: 1) 860's that meet all the current criteria to enter the transaction against the originating PO/SO. 2) 860's that have to be modified to meet the criteria Document what modifications needed to be made (example the Sales order has line numbers 1,2,3,4 and the 860 transaction uses a,b,c,d) 3) 860's that are rejected (no associated 850, closed SO, S0 beyond the point of no return (built, picked, packed, or shipped depending on the business process rules governing sales order changes) Let's assume that 80% of the 860-transactions fall into group 1, 10% fall into group 2, and 10% fall into group 3. In addition you will want to document the transactions into these 3 groups for use in the design phase of the initiative if you get that far. . 1) 860's that include all of the information in the originating 850 with the changes incorporated 2) 860's that have only the changed information. 3) 860's that don't fall into group 1 or 2. An example would be an 860 that completely changes the original 850 and the business decides that it is better to cancel the original order and create a brand new one. Now that we have the metrics we have to do the math. 860's that can be processed electronically are those in groups 1 and 3, group 1 meets the criteria and a sales order acknowledgement needs to be transmitted to the customer documenting the acceptance of the change and group 3 are rejected and a rejection notice has to be transmitted to the customer. These two groups can be dealt with programmatically Group 2 contains the 860's that need to be modified to meet the acceptance criteria this can often times be done programmatically utilizing a rules based EAI (Enterprise Application Integration) process. For those changes that cannot be processed programmatically an exception report needs to be created and provide to the responsible human. This process is referred to as management by exception. So now we have all the data we need to make a viable decision on what is the best way to move forward. Currently it costs $121,875 to process these changes. We know that 90% of the 860 transactions can be dealt with programmatically (meets criteria or rejected) and let's say that 50% of the 860's that need modifications to meet the criteria can also be done programmatically. So now 95% of the 860 transactions have been processed electronically without human intervention. Upon implementation of an integrated process the cost savings per year would be $115,791.25. Now we have to determine how much it will cost to build the integration module, test it, train the users on the new process and acquire any additional materials. For our discussion we will have the following numbers. 1) Research – 10hrs/week for 26 weeks @ $25/hr = 260 * 25 = $6,500 2) Design, build and test interface module - 320 hours @ $60.00/hr = $19,200 3) Training - 16 hours @ $60.00/hr. = $960 4) EDI Mapping and testing tasks – 160 hours @ $60/hr = $9,600 This brings us a grand total of $36,260 to implement the integrated exception managed 860 process with an ROI of approximately 90 days and you are in a position to re-task the current resources to other endeavors. Obviously these numbers are for educational purposes only, your numbers may be different. If you think this is a pain try integrating the 830/862 transaction combination for automotive replenshment changes. Jim --- In [email protected], David Frenkel <frenkel@...> wrote: > > Don't forget your friends in telcom who use the 860 for their unique purposes. > http://www.atis.org/obf/docs/esoc/edi/sosc/elms4/elms4860.pdf > > > David Frenkel > > > > > ________________________________ > From: Michael Mattias/LS <mcmlserve@...> > To: EDI-L <[email protected]> > Sent: Tuesday, November 29, 2011 3:06 PM > Subject: Fw: [EDI-L] Re: EDI Software and handling the 860 (PO Change) > business process > > >  > 11/29/11 > > FWIW, this is a reasonable thing in my client's operation... "processing > inbound orders" - the ones which are not canceled - > results in immediate preparation of master pick lists, shipping labels, FedEx > manifests, customer-logoed packing slips (these are > all drop-ship orders) , generation of order acknowledgments (ANSI '855') and > allocation of inventory. > > Total elapsed time between "start processing orders" and all this stuff being > completed? Maybe 10 minutes depending on volume. > > That is, it really is true that an order reaches a "not possible to cancel" > status quite quickly! > > Michael C. Mattias > Tal Systems Inc. > Racine WI > mmattias@... > > > Just for the heck of it, but not "generally" applicable... > > > > I have one client who has a customer who *frequently" uses the '860' to > > cancel an '850 PO'.... > > > > We only pick up mail from this customer once per day and it's not unusual > > that the same "batch" of inbound documents will contain > > both the '850' ("please enter our order for...") *AND* the 860 (" never > > mind that order I sent earlier"). > > > > What I do is scan the inbound 'batch' and delete any '850' for which I find > > a cancelation '860' > > > > What my client (the seller) did is make a business rule that says "if you > > have not sent the cancelation by the time we process > > purchase orders each day at <whatever time it is> , we cannot accept a > > cancelation of that order." > > > > It works in this trading relationship. YMMV. > > > > Michael C. Mattias > > Tal Systems Inc. > > Racine WI > > mmattias@... > > > > > [Non-text portions of this message have been removed] > ------------------------------------ ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix.Yahoo! Groups Links [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] ------------------------------------ ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix.Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/EDI-L/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
