Is there such a thing. We have been using a 3rd party sofware and
flatfiling the information from our MVbase to this 3rd party ofr years.
Is there any PICK software that does EDI for the automotive industy or
does EDI period

FWIW we have also used 3rd party software from companies like GE & IBM
(who basically "own" the EDI networks), and I don't see a problem with
this approach.

Their software is relatively easy to integrate with, is proven (heck,
we use the software from the people that provide the EDI backbones),
stable, and used by more people than are likely to use an mv-only
solution.

What would you hope to gain by using an mv-based solution, which may
not exist on mvBase anyway?

Why bother swapping one 3rd party tool (which is probaby supplied by
the EDI vendor) with another?

We have always used the software provided by the gateway vendors
(typocally IBM & GE) - relatively easy to interface to, tried, tested &
poven.

What do yoiu hope to achieve by having a native mv based solution
(which, if available, is unlikely to be in mvBase I would think)

shaun wrote:
Dave Taylor has EDI software and I believe it runs directly from
mvBASE and other platforms. Hey Dave! Prospect alert!

Most MV developers do the flatfile thing, but most of these solutions
follow the same pattern:
- The flatfile is crafted for a particular 3rd party tool, so rather
than taking the time to use the 3rd party's API in the first place the
MV developer now finds himself with an extra tier of data that's
vendor-specific anyway, which is what they wanted to avoid in the
first place.
- Many developers want an elegant solution, but end up writing a
unique X12 document processor for each of their trading partners.
That is, where there are 3 trading partners, there are 3 850's, 3
856's, 3 810's, etc. Before writing a solution from scratch take some
time to plan it out. Your existing 3rd party tool may have already
solved this problem for you.
- It's possible to process data from mvBASE as though it were
happening directly, even though mvBASE does not have the sockets or
other communications interfaces that other products have. I've
written some connectivity tools, mv.NET works with mvBASE, and there
are others.

There are lots of ways to approach EDI. Rather than assuming you want
to do it direct from MV, my advice is to just figure out exactly what
you want to do from a business perspective, then work out the tools to
make it happen. Why is it that you don't like your 3rd party tools?
Cost? Features? Have you shopped around for others? Are you aware
that some trading partners, perhaps your auto manufacturer partners
may insist that you can only use specific products?

Anyway, your answer is 'yes'.

Tony
TG@ removethisNebula-RnD.com

I'm in late on this thread and may be repeating a response but these guys
have been doing it forever.

http://www.glenbriar.com/software_mms_software.php

Good folks to work with, unlike some of their customers.

Dave

Tony,

You are right, as I deal with the BIG 3(automotive) I flat file
incoming/outgoing files all day long and I have something like 110
trading partners as I am the 3rd party warehouse and the 862's and
DELFOR's are a little large.

Yes I could still use IBM, Gies...etc as I could FTP the data
staight to them, but I need something were I can see and manage all of
the data coming in and out, without using a 3rd party's software to
manage and to create the layout of x12 and EDIFAC. And the also turn
around and create it on the MV side so that it flatfiles in correctly.

10 years ago it was fine, only 5 trading partners but now it has
gotten out of hand.

P.S. Tell dave taylor to send me an email

Tony,

You are right, as I deal with the BIG 3(automotive) I flat file
incoming/outgoing files all day long and I have something like 110
trading partners as I am the 3rd party warehouse and the 862's and
DELFOR's are a little large.

Yes I could still use IBM, Gies...etc as I could FTP the data
staight to them, but I need something were I can see and manage all of
the data coming in and out, without using a 3rd party's software to
manage and to create the layout of x12 and EDIFAC. And the also turn
around and create it on the MV side so that it flatfiles in correctly.

10 years ago it was fine, only 5 trading partners but now it has
gotten out of hand.

P.S. Tell dave taylor to send me an email

I'm in late on this thread and may be repeating a response but these guys
have been doing it forever.

http://www.glenbriar.com/software_mms_software.php

Good folks to work with.

Dave

Shaun,

Thank you for expressing your interest in an EDI translator running on
mvBase.

We are glad to offer our EDI translator, the EC/EDI*Wizard(R), that is
a fully
map-based, multi-user translator that runs on mvBase and that we are
currently porting
to Universe.

It has been in use on mvBase and expanding since 1996 and in one
installation it
currently supports almost 100 Trading Partners, 13 types of EDI
documents with
multiple versions and over 300 individual TP/Document maps and four
communications
protocols connecting with two VANS and directly with Wal-Mart.

Since there have been a number of comments re: the use of VAN (usually
PC-based)
translators, I'd like to share with the group the reasons for replacing
PC-based
translators with a translator running on the User's business database
and integrated
with the User's businesss software.

Then, I will send you separately some specific information about our
EDI translator,
the EC/EDI*Wizard(R).

There are three levels at which a business can engage in EDI:

1. The local EDI service bureau that acts as an EDI Trading Partner on
your
behalf, establishes a VAN account for you and passes messages to/from
you via courier,
fax or snail mail.

2. The inhouse PC-based EDI translator that connects with your VAN,
prints all
incoming EDI messages for your manual reentry and the provides for your
manual reentry of all outgoing messages ("Rip 'n Read").

3. The fully integrated EDI translator that converts POs to Sales
Orders,
Bills-of-Material to Advanced Ship Notices and/or Warehouse Shipping
Orders and
Invoices to Invoices, etc.

We have only installed our software once for a customer who did not
already have a
PC-based EDI translator. In all other cases, the customer chose to
replace their
PC-based translator with our translator running on mvBase. Why was
that?

The key advantages of using a multi-user EDI translator installed on
your business
computer and database are:

1. All Users of EDI can perform functions with the EDI translator from
their
regular offices on their regular business software workstations rather
than going to
the "EDI room" and (possibly) waiting in line to use the "EDI computer"
one at a time.

2. Multiple EDI activities (receive mail, process mail, send mail; for

different customers and warehouses; assigned to different Users in the
same or
different departments) can be launched, all concurrently/or not, as the
need demands.

3. Communications between multiple VANs using multiple protocols can
be supported independently of the whims of the VAN whose EDI translator
you happen to
have chosen - ProcommPlus for dial-up modem async protocol connection,
3780Plus for
dial-up modem bisync protocol connection (was demanded in the past by
Wal-Mart and
McLane), ftp internet protocol now offered at much lower cost than most
dial-up
connections, AS2 internet protocol demanded by Wal-Mart, and directly
with Wal-Mart,
today using only Wal-Mart approved AS2 communication software, etc. I
don't know of
any VAN that offers 3780Plus and only a few that offer AS2
communications. AS2 is the
emerging choice of more and more Trading Partners and it can be
extremely expensive.

4. Communications that can be launched by the User automatically from
any
business workstation without direct knowledge about or interface with
the
communication software on the business server (just press a button and
it's done).

5. EDI messages are moved automatically and reliably between the
business
database and the NT file structure on the same computer without the
introduction of
network issues between two computers.

6. EDI documents are transformed directly to/from mvBase records,
which
eliminates the additional flat file transform layer and transformation
logic and
associated opportunity for errors and failure.

7. Business rules logic can be built directly into the APIs between
the EDI
translator and the business software so that manual intervention in
message processing
is only necessary on an exception basis - eg. automatically approved
POs can be
dropped directly into the Open Orders file without the User involvement
normally
associated with manual Order Entry and its associated business rules
logic.

8. All EDI data is backed up along with your business data at the same
time
and in the same database rather than backing up EDI data on the "EDI
computer"
separately, if at all.

9. If you have a standby business computer, then you have a standby
EDI computer, whereas few businesses have a separate standby EDI
computer for the sseparate "EDI computer" without significant cost and
support time and effort.

10. Complete control over your EDI translator is ensured thru
the source code installed on your system in languages that your
understand.

The worst bisiness situation any of us can find ourselves in is
receiving a demand
from one of our good customers for some new feature in our business
relationship that
we can not deliver, or can not deliver in accordance with their time
table, or at a reasonable cost, because the vendor of our software
hasn't provided this feature, or
is charging more than the cost of a competitive product, because the
vendor of our
software thinks that we are a captive customer of theirs.

Business is all about maintaining and strengthening our customer
relationships, and a
multi-user EDI translator running on our business server and integrated
with our
business software and business database is a critical tool in achieving
that
objective.

Of course, there is no "right" or "best" solution. The "right" or
"best" solution
depends on your needs - both today and in the future. The challenge is
to define your
current needs and anticipate your future needs so accurately that you
spend enough money on the first solution that you to avoid scrapping it
later, but not more money
than you need to meet your future needs.

We look forward to any inquiries about this or other software or
services that we may
offer.

Rgds,

Dave

Dave Taylor
President
Sysmark Information Systems, Inc.
49 Aspen Way
Rolling Hills Estates, CA 90274
800-SYSMARK (800-797-6275)
(O) 310-544-1974
(P) 800-339-1497
(F) 310-377-3550
Your Source for Integrated EDI Translation and DataSync Integration
www.sysmarkinfo.com