Kathy ...
You can see from these exchanges that my company (IMC) and Franck's
(Infor) don't agree on how best to approach the issues you have raised.
There is a lot more we could say, but the BPCS-L forum is not the place
for it.
As it is not considered polite to mine these discussions for sales
prospects, the ball is in your court.
Please call if we can help.
Regards,
John G Dyer
Vice President
Information Management Consultants, Inc
http://www.imcedi.com
jdyer@xxxxxxxxxx
812.421.0045 x 203
From:
Franck Guillet <Franck.Guillet@xxxxxxxxx>
To:
BPCS ERP System <bpcs-l@xxxxxxxxxxxx>
Date:
01/13/2010 01:48 PM
Subject:
Re: [BPCS-L] BPCS EDI advice
Sent by:
bpcs-l-bounces+jdyer=imcedi.com@xxxxxxxxxxxx
Hello Kathy,
As an EDI consultant at Infor since 1996 and having worked with both
TLE/400 and TLi, here are my thoughts.
Version 3.201 is the last version that Infor will provide for TLE/400 yet
it is still supported.
As Karen correctly mentioned, although TLE/400 allows more flexibility
that many other translators, the mapper is not as user friendly as TLi.
Infor has a partnership with Inovis that has allowed us to develop
standard TLi maps for ECM including the most widely used ANSI-X12 and
EDIFACT documents. TLi is the upgrade path we are providing for customers
currently using TLE/400 and the standard maps will be provided with the
translator.
I agree with Karen that any custom business functionality should not be
integrated into EDI maps. For this purpose, ECM allows you to add custom
programs as ECM adapter functions without modifying base code. This ECM
functionality is very useful.
As you know, the ECM application acts as a gateway to the BPCS application
files, preventing data corruption and allowing for optimal data integrity.
Having another set of files used as an interface between ECM and any EDI
translator is redundant and will add confusion to the EDI process.
I will be happy to discuss the ECM inbound order process and answer any
questions you may have. You can reach me at the number below or via
e-mail.
Best regards,
Franck Guillet | Principal Technical Consultant, Professional Services |
Infor | cell: 773-610-7375 | e-mail: franck.guillet@xxxxxxxxx
Franck Guillet | Principal Technical Consultant, Professional Services |
Infor | cell: 773-610-7375 | e-mail: franck.guillet@xxxxxxxxx
-----Original Message-----
From: bpcs-l-bounces+franck.guillet=infor.com@xxxxxxxxxxxx [
mailto:bpcs-l-bounces+franck.guillet=infor.com@xxxxxxxxxxxx] On Behalf Of
jdyer@xxxxxxxxxx
Sent: Wednesday, January 13, 2010 11:13 AM
To: BPCS ERP System
Subject: Re: [BPCS-L] BPCS EDI advice
Kathy ...
Our associates John Greer and Karyn Young weighed in with some additional
comments that may be helpful ...
My questions: Basically do we implement our own programming integration
into BPCS **OR** upgrade Trusted Link?
**OR** continue with current TLE/ECM versions and automate the inbound
documents?
I would focus on eliminating the manual input first. You'll need to
decide if it makes economic sense to upgrade TLE. If you do not have much
EDI maintenance activity then it might make sense to wait to replace TLE
until they phase it out. It might also make sense to move forward with
programming integration into BPCS, depending on your future plans.
However, you would want this to be generic so that it would work with TLE
or another translator. We have programs and files that we collectively
call "The Toolkit" that serve this function and we do this type of
integration if you would like more informaiton.
Regarding Trusted Link Enterprise and BPCS ECM see below versions, what
are the abilities or lack of abilities when it comes to inbound
integration? Pros and cons?
We are using TLE Version 3.2 Rel: 01
BPCS Version 6.0 Release 04
I asked Karyn Young here at IMC to respond to your questions and here is
what she said:
No matter what they have to use ECM ... that is the batch processing
of orders ... but the question is whether to map directly to ECM file or
to another set first and run programs (like the ToolKit) to load the ECM
files.
You can load directly ... but what I have found is that you have to do a
lot of "programming" to get all of the fields loaded correctly. We've
always stressed the idea of keeping maps simple and putting programming in
programs (not imbedded in the maps or in user exit programs within the
maps). TLE would actually let you chain to any file you wanted to pull in
a field here and there that you might need ... customer master, item xref,
item master, etc ... you can do it in TLi or user exits ... but it makes
for (at least to me) long and complicated maps.
TLE, to me, made it kind of easy to just chain to a file whenever you
needed to ... TLi is not as easy in that respect ... I don't see it as a
downfall however, b/c we don't do our chaining and data lookups in the map
... we put it in a program.
TLE made it very easy to open a document (like an 810 or 856 that was
ready to be sent) and just edit it ... right on the screen. For one, I
don't like that ... manipulating data means the map or data or programs
didn't work and they need to be fixed ... but it does come in handy when a
user accidentally keyed a - or something on the end of a PO# and you just
need to remove that and send the ASN. There are ways to manipulate the
raw data in TLi but you have to go into the database files ... and you
better be careful! But you can do it if you have that kind of authority.
The TLi mailbox screens are much more dynamic ... allow for easier
document lookup and holding and releasing. TLE's transaction and comm
session screens are not as easy to navigate or regen docs or resend comm
sessions. I think the T/P setup is easier in TLi too ... but that's just
my opinion. There may have been issues with networks too ... I think it
was much easier to setup new networks in TLi vs TLE.
TLE allowed you to copy standards and make them specific to customers ...
I'm not sure how to explain it ... but it was kind odd. We have a client
that is using 4010 version but sending an NTE segment (which should no
longer use the NTE segment ... it was chgd to MSG ... but they use it) ...
in TLE you could just add the segment to the copied standard. I can't
remember how we got around that ... I actually think we asked them to fix
it on their end. There may be a way to handle that in TLi ... but I've
never done it ... I've found out a lot more about the TLi mapper since
helping them convert from TLE b/c we needed it to do things I've never
tried to do before.
The TLi GUI is nice ... and is definitely better than the mapper in TLE
... but again the TLE mapper let's you practically code little programs
into the map. They also let you set up subroutines in a source file and
then you assign them inside the map and it will run those as part of the
map. When you compile the map it actually creates an RPG program that you
can debug if you have trouble figuring out why your map doesn't work (that
helped me when I was first learning how to map in TLE).
Hope this helps.
John Greer
Information Management Consultants, Inc.
jgreer@xxxxxxxxxx
(812) 421-0045
-----Original Message-----
From: bpcs-l-bounces+davejfuller=btinternet.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+davejfuller=btinternet.com@xxxxxxxxxxxx] On Behalf
Of
Kathy Steigerwalt
Sent: 17 December 2009 03:29
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] BPCS EDI advice
Hi All!
I am looking for advice.
The shop has been using Trusted Link Enterprise EDI integration with BPCS
(ECM module) for the outbound documents for years and it is stable.
They have also been receiving EDI transmissions from customers BUT
dumping the inbound EDI to paper for human re-keying.
My questions: Basically do we implement our own programming integration
into BPCS **OR** upgrade Trusted Link?
**OR** continue with current TLE/ECM versions and automate the inbound
documents?
Regarding Trusted Link Enterprise and BPCS ECM see below versions, what
are the abilities or lack of abilities when it comes to inbound
integration? Pros and cons?
We are using TLE Version 3.2 Rel: 01
BPCS Version 6.0 Release
04
Thank you for all opinions.
Respectfully,
Kathy~
--
______________________________________________________________
Confidentiality Notice: This E-mail (including attachments) is
confidential and the property
of Information Management Consultants, Inc. (IMC).
If you are not the intended recipient:
Reading, copying, disclosure or any action based on this message is
prohibited. IMC retains
copyright and intellectual property rights and objects to misuse.
IF YOU HAVE RECEIVED THIS E-MAIL IN ERROR, PLEASE CONTACT THE SENDER
TO ADVISE OF THE ERROR AND PERMANENTLY DELETE THIS E-MAIL.
______________________________________________________________
midrange.com
