Glad I did not insult you. I am not qualified either, but hopefully some of
my remarks helpful.
In case you were not already aware of this, in 405 CD:
ORD420 = Pickable Orders Report
ORD410 = Order Exception Report
ORD550 = Pick Slip Release
ORD560 = Pick Slip Printing
ORD570 = Pick Slip Confirm
ORD590 = Print Shipping Documents
I would advise against modification, or clone modification here, if you do
not have access to AS/Set.
However the Bill of Lading and Pack List programs are pretty simple ORD595
and ORD596 old fashioned pre-AS/Set easy to modify.
ORD105 = Trading Partners Maintenance
ORD115 = Trading Partners Listing
You need to setup Trading Partners for things like truck lines, UPS, etc.
EDI also has something called Trading Partners, for stuff like the VAN where
you get the EDI transmission. You may need to have 2 files, one for BPCS
Trading Partners, another for EDI Trading Partners. If same outfit both
places, probably smart to use same reference #.
If I were you, I would check out EDI web sites to locate standards for 866.
I would also ask people at the company, if they know, does the customer that
needs the 866, have a reputation of obeying standards, or violating them ...
it could be that no one is left at the company who knows this.
My memory of the EDI standard concept is that there are many different
record types, with different layouts, and you do not know in advance what
sequence they will arrive in, but the first few characters of each record
can tell you what type is coming next.
So you have to have the mother of all CASE statement lists, which identifies
which subroutine will process what kind of record, then most start with
overlaying a humongous string of data into a file layout, or data structure
designed for that format, in which you have to define it variable length,
because you cannot predict in advance how long the individual fields will
be. Sometimes you cannot properly process some content, until you find some
field from a record you have not read yet, so separate routines are needed
to search thru records not yet read, to find the next ones of particular
types.
The above assumes you working with EDI I. If you have EDI II and customers
who adhere strictly to the standards, much of the mapping is handled for
you.
As soon as the program identifies what customer this is for, and maybe some
other variables, you may need special subroutines to handle stuff where this
customer is violating the 866 standards. When I was in this, we had
different customers with different violations of the same standards.
Also, need to make allowance for customer requests which are lead time
violations, or other instances needing human attention. In other words
automate delivery of the Ok stuff, and have a second work file for problem
input which cannot be dumped into BPCS without human attention. Then some
way for users to process what can be processed.
EDI expects to send an acknowledgement to customer "Hey we got your data"
but maybe you need to delay that until you can include something about their
data that is no damn good (if any).
While in theory, all of a particular kind of data is to arrive using a
particular EDI standard, we had customer personnel calling us up, sending
faxes etc. with "corrections" to their EDI data, sometimes arriving before
we saw the EDI data.
Many of our customers have asked for code #s on all our documents to them,
which both use certain phraseology, and we see no logical place in BPCS to
enter them. Towards this end, it is absolutely critical to have a BPCS
field reference manual (or XRF dump) because many fields are logically
populated within programs, so GO CMDREF won't get everything. The goal of
this is to determine what fields in BPCS are safe to use for purposes other
than BPCS defaults. For example, we found some fields that show up on top
of INV300 BOM300 etc. which we were not using, and were already accessible
via INV100 and other standard update programs, so we used the BPCS literals
renaming utility to give them meaningful names relevant to our users. Plus
you need to document what you have done to avoid conflict with other
programmers, and future Infor releases. We found it useful to put our mods
in a separate message member, so that after a new release wipes out our
work, we merge our mods back in.
Fans of query and other tools need to be able to cope, because the
substitutions do not occur at the IBM OS file level.
We modified INV300 where the list price is, to insert a field from item
master if there is a price break on the item, and show the first couple
entries (that is all which would fit nicely), so assuming our data is
up-to-date consistent, people can more rapidly find out if there is a price
break, than using the cumbersome price break inquiry program in every case.
We use customer part # as our item #, which works for 99% of our business,
so the item description defaults to same as item # for end item. In
customer order entry, the description defaults to same. We have been
substituting there some info requested by some customers, for which we found
no other field in BPCS which made sense.
Because we have different customers playing by very different rules of what
they are demanding, we have variants of many BPCS modifications, tailored to
the different sets of rules.
Into BPCS, we look for a "hook" where it makes sense to input data with
minimum upheaval. For example, if this data was to come in the old
conventional way, perhaps the program which a human might use to key it in
could be cloned, and have the data instead come from a standard file's data
which was derived from the EDI data. Do not try to clone and modify ORD500
unless you have AS/Set. If the company has decent pockets (don't need to be
excessively deep), you might consider getting FoxTrot which is a PC overlay
for any BPCS user program to actually get its data from any other source
which a user can see on-screen, such as Excel, Internet Web Page, you name
it.
Be very careful about inserting data to BPCS files without going thru BPCS
checks and balances. Many files have "sequence #s" cross-indexed to many
other files. Many BPCS programs walk down sequence #s 1 2 3 4 etc. then if
they get to a gap or mismatch, they don't look for the next higher #, they
just quit, so you need to know all the other places the sequence #s need to
be in synchronization.
We have a lot of crashes where someone PC go down leaving some order in-use
which can mess up a lot of things, particularly when user forgets order #
they were in, or in case of shipping it can be all orders on one customer.
We have query to list orders currently in-use, and a mass update menu option
to take everything out of in-use, after confirming all possible users are
off relevant programs.
I checked our shipping and order preparation menus ... I had vague memory of
some modification we did with picking orders, but now I cannot find it.
-
Al Mac
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of Pete
Helgren
Sent: Wednesday, October 20, 2010 5:29 PM
To: BPCS ERP System
Subject: Re: [BPCS-L] EDI 866 record
"You are not qualified for this assignment"
You are preaching to the choir on that one! I have most of the 866
parsing routine fleshed out based on other EDI programs they have. I
don't have sample data yet so I haven't been able to test it. I am
pretty sure I can parse all of the data just fine. Getting it into BPCS
and then figuring out how to print a pick list with sequence numbers is
another challenge.
Making some progress but I still have a long way to go.
Pete Helgren
Value Added Software, Inc
www.asaap.com
www.opensource4i.com
On 10/20/2010 10:28 AM, Al wrote:
You are not qualified for this assignment. The person to do this work
needs
to be experienced in both BPCS and EDI.
I worked on EDI maybe 15+ years ago. It is a complicated unique
application
like BOM and MRP and GLD. My company got EDI I out of ignorance with the
application and our customer vendor needs. We should have got EDI II.
If you had EDI II and it was up-to-date, there would be no need to
implement
an EDI ANY record, because implementation comes with EDI II. If you have
EDI I, it is probably physically impossible to implement any added record
type in 2 weeks, let alone 2 months.
I am sure the technology has vastly matured since I last touched it.
I know 4.05 CD ... in our conversion to it in 1998, from an earlier
version,
my company decided to drop EDI because the hassle with our customer vendor
needs not following any EDI standard, was more than we could stand.
Education in BPCS is far in excess of 15 hours.
-
Al Mac
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of
Pete
Helgren
Sent: Monday, October 18, 2010 2:15 PM
To: BPCS ERP System
Subject: [BPCS-L] EDI 866 record
Folks, for a complete noob in BPCS I have my work cut out for me. The
company that I am doing some "emergency consulting" with has a need to
implement an EDI 866 record in a couple of weeks (!) I have never done
EDI and have about 15 hours of BPCS knowledge under my belt. Doing a
bit of searching I found this in the archives:
http://archive.midrange.com/bpcs-l/200011/msg00115.html
Which seems to indicate that BPCS doesn't handle "sequencing". I am not
exactly sure what that means since as I understand the process, the
manufacturer will send an 866 to this company (supplier) and that will,
theoretically result in an order and eventually, a pick list that states
the sequence in which the items need to be packed (all done in BPCS).
So do I understand that BPCS doesn't have a place to enter a "sequence"
number in the order/pick list and therefore there wouldn't be a way to
signal the warehouse/shop floor that the order must be packed in a
certain sequence?
Has anyone implemented an 866 in BPCS 4.05 and could share a pointer or
two on how they accomplished it?
midrange.com
