Outside operation coding -- BPCS-L

So, what do you guys do?

BPCS 4.05CD.  Roughly 50% of my product line calls for an outside operation.
The routing/process labor step is coded 'C' with a standard cost and queue
time.

The problem is that I'd like to set up a blanket order to fix pricing, which
is individually done now - we'd like some sort of across-the-board pricing.
We'd like to cut down a ton of paperwork and operations - keying printing
and filing the PO, pulling it, matching it with the receiver and invoice,
etc.  When you setup a blanket like this, the identifiability of the item is
lost - customer service can't see that the item has 'left' WIP and is now
rambling about the countryside somewhere.

Should I use some sort of inventory transaction to maintain trackability?
Report labor against a fictitious labor step (so as not to add cost)?

How do you do it, please?
-----Original Message-----
From: bpcs-l-admin@midrange.com [mailto:bpcs-l-admin@midrange.com]On
Behalf Of Al Mac
Sent: Tuesday, July 23, 2002 12:09 PM
To: bpcs-l@midrange.com
Subject: Re: Bandwidth requirement


You might ask IBM.
You might also see if you can find your SSA Sizing Questionairre and see if
anything significant has changed since the last time you updated it.

It is my understanding that a 5250 data screen whether on emulation or dumb
terminal, can handle up to 2k of information sent and received vs. the
screen, but the main issue is heads down keying.  Many of our users have
INV300 SFC300 just sitting there, not rapidly refreshing the info so no
drain on the comm line.  The speed of remote printers might be a
consideration.
Since you have a line right now that you plan to upgrade, take a look at
IBM's performance measurement such as GO PM400 to see what kind of
overloads you might have.

Many years ago remote users complained to our CEO about performance, when
we were on S/36.  He asked me how significant it would improve with a
faster comm line.  I showed him the performance statistics ... stuff got
slowed down only 10% of the time for us due to comm overload, so a faster
comm line would be throwing money away with no appreciable
improvement.  The killer in the performance data was disk access arms, and
it effected all users, HQ as well as remote.  It only stands to reason with
very few arms and very many users that would be a potential bottleneck.  I
explained CACHE to him and the bottom line was that he went along with my
suggestion that we get more memory, and performance did dramatically
improve for everyone.

We used to be leased line but are now on simulated leased line through
frame relay, where one line handles 400, PC, voice, and fax traffic, saving
us a bundle on long distance costs between our sites.

>Dear all,
>
>We're on v.6.1 MM.  We are in the process of upgrading the leased line
>between the AS/400 and a remote site.  Are there any figures from any
>parties, say SSA,  telling the required bandwidth for each 5250 emulation
>session and  clien/server session conecting to BPCS?
>
>Regards,
>Eric Tam

-
Al Macintyre (macwheel99@sigecom.net via Eudora)

_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l
or email: BPCS-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.