Re: EDI TLE USERS ONLY -- BPCS-L

>From Al Macintyre

>  From:        jcannon@antigua.com (Jim)
>  
>  Be advised, this question is coming from a BPCS novice, and an EDI 
>  neophyte. I know I should take the class, and will! But my assignment 
>  precludes waiting till then. So I am strugglin through it alone.

You are probably headed for a disaster.

Better get in writing who is asking what should be done without the proper 
training, because heads will roll when the disaster arrives & you need 
insurance against your head being among them.

Thanks to marketing hype, sometimes there is a disconnect between a corporate 
decision to buy something & the people who have to implement it, so for 
example we have all seen where a department buys a $ 200.00 PC printer then 
spends thousands of dollars to interface it to the network, and cope with 
operational hassles, when for perhaps $ 750.00 they could have bought a 
network-ready printer and spent a tenth of as much money on operating it.  
EDI is like that except on a grander scale.

Companies are tempted to spend say $5,000.00 on a low end EDI package then 
add to their payroll 2-3 people to do the work that EDI did not do 
automatically because they did not buy a high end package, or invest in the 
training to learn how to use it economically.

>  It is my impression that TLE somehow magically maps info from and to the 
>  database. 

Nothing happens by magic - some human being has to manage the system.
It is like security & the rest of IT - when you have a new hire, can they 
sign onto BPCS like magic, or does someone have to set up what they are 
allowed into?

Are the products in your factory manufactured by magic without human hands, 
or do you have employees except their wages get to their bank accounts by 
magic?

Read the thread on "Why did you buy BPCS?" and think of EDI as being like a 
slow boat compared to the Client/Server ocean, that sucks up a mountain of 
costs & administrative burdens with no end in sight.

>  For example, if I receive a PO, it will eventually extract the 
>  information from the '850' transaction and post it to BPCS.
>  
>  How do I know, or how can I find out, what fields are being mapped from 
the 
>  '850' and what fields in BPCS are being updated?

Skim the manuals - you do have documentation don't you?

Plan on accepting EDI orders into a test data base & see what happens.

Implementing EDI is like implementing several BPCS modules or doing a PTF 
upgrade.  You will probably need a project team of people from the 
departments that enter customer orders, process shop orders, purchase your 
material, manage your MRP & CAP, just like you need when implementing any 
other major upgrade.  They will do testing to see what changes in corporate 
practices are needed, and what reports are essential for this to work 
satisfactorily.  Think in terms of at least half a dozen people spending at 
least a day a week for several months until the EDI is working to the 
company's satisfaction.

Everything will go so much more smoothly if the entire project team gets the 
relevant EDI education before the project is launched.  IT & management 
personnel ought to get the EDI education a few months in advance of everyone 
else, so you have some idea what this is going to cost in time & effort & 
finances, and how many additional people will have to be added to the payroll 
to make it work right.

If the company can only afford to send one person to EDI school, it should be 
the person who wants EDI implemented, so that person can be given the job of 
getting it done, not delegating it to you, after they have had the 
appropriate training.

>  I am looking at a report from TLE, SET189 "Module Mapping Definition 
>  Print".
>   
>  If I read it correctly, listed under the heading "LIST OF USED FILES' I am 
>  seeing the various DB files used, and each field in that file.
>  
>  After that is an "INDENTED LIST" of the "850" and all its records.
>  
>  After the 'INDENTED LIST' is what I am guessing is a further breakdown 
>  into its elemets each line of the above.
>  
>  So my question is...is there something that tells me how they are mapped?
>  Am I missing a report? 
>  
>  Again, please remember, I am relatively new to BPCS, and have never 
>  touched EDI in my life.

OK - some definitions

EDI I vs. EDI II

EDI I = a means of getting data into a format that is intelligible to your 
people who have to transcribe it into your system, like a fantastically 
expensive fax machine.  Plan on writing a bunch of modifications to make the 
process as painless as you can for the staff who will be transcribing from 
the EDI report into BPCS.

With EDI I you are more flexible on choice of package - it does not have to 
be a good match to BPCS or the hardware platform that you are running BPCS 
on, but that does help a lot - an awful lot.

EDI II = the data arrives & goes through a set of rules that you can change, 
so that some data is automatically transcribed into your customer orders, or 
wherever you want it, while data that is in violation of your corporate rules 
is rejected into a report that humans will need to massage then you have some 
choices of doing what with it.  This is best comprehended with some real 
world examples from when we were doing EDI & had to abandon it because the 
operational costs were far in excess of what management felt was reasonable.

Customer-A says We want you to get this implemented & make all the changes 
that any of our people ask of you & we will reimburse your implementation 
costs.  As we implement pieces of what they have asked for, we send them 
progress reports, then one day, a high level manager at Customer-A pulls the 
plug on financing because "they have already paid us far more than they 
thought was a reasonable budget for this" & meanwhile we still have a steady 
flow of modification requests from personnel at that customer, in which they 
are basically wanting us to massage the data that comes from their official 
reports, before it goes into our system - why can't they massage it before it 
is sent to us?  Well their own people do not have the clout with their own 
MIS dept, so they demand that vendors massage the data at the other end, and 
this comes under the umbrella of an open-ended project that no one has put 
any reasonableness cap on.

Customer-B identifies some field within the international standards & says 
they are going to use this field to have some significance that is totally 
outside the system - we ask them why they do not use this other standard EDI 
set that is better suited for that project, but no, they are going to do it 
this way, and the customer is always right, even when there is a hole where 
their brains belong.

Customer-C sends an EDI order for a new part but they have not yet approved 
our samples & this order is in violation of their own contract, but some 
customers verbally tell us to violate their own printed contracts.  Some 
customers tell us that we must manufacture to the specifications of the 
latest blue print revision that they have sent us, while their EDI is 
ordering a revision number that they have not yet delivered specifications to 
us.  Do we produce the old revision?  Do we stop the order & seek 
clarification?  Different customers divisions have different rules they want 
us to follow in this circumstance.  Other customers EDI is calling for an 
older revision - in some cases they really do want the older revision, in 
other cases the revision # field is not being kept current in the customer 
data base.  You have to know which is which.

Customer-D sends us an order in which the date they want delivery is such 
that we will have to air freight raw materials & work second shift over the 
weekend in order to meet their short deadline ... do they really want that 
high added cost or will they want us to call them & negotiate a compromise?

With EDI II there's some place where you spell out rules for rejecting 
incoming orders for human intervention because of scenarios like I have given 
you from our real life business.  You need to check your EDI documentation & 
print the report on your current rules settings.

With EDI II, you have to have something that works with BPCS on your 
particular platform for all the different kinds of EDI standards that are 
essential to your business - expect different kinds of EDI "forms" like POs & 
releases, and changes to POs & releases, Advance Ship Notices, Invoices, 
Funds transfer, in which there are various revision levels of the EDI 
standards & different customers will be sending their EDI forms at different 
versions & expecting you to communicate with them at different versions of 
the international standards.

For every combination of transaction set with customers & vendors, that 
should be married to your BPCS manufacturing applications, there has to be 
tech support & rules, and you will have to have corporate policy what you are 
going to do when some customer or vendor asks for an EDI connection that is 
not supported by your package.

Al
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---