• Subject: Re: Subsystem Event Determination
  • From: "Paul Holstein" <holstein13@xxxxxxxxxxx>
  • Date: Wed, 28 Jul 1999 20:07:02 PDT

Mark,

I'm going to go out on a limb here with a crazy suggestion.  What would 
happen if you wrote a small program to change the company number to some 
number tied to the warehouse and then you set up Subsystem Event 
Determination to look at the psuedo company number?  After you posted your 
inventory transactions, you could use a simple SQL statement to change the 
company back.

--Paul Holstein
SSA Southeast


----Original Message Follows----
From: "Mark Seaton" <maseaton@earthlink.net>
Reply-To: BPCS-L@midrange.com
To: <bpcs-l@midrange.com>
Subject: Subsystem Event Determination
Date: Tue, 27 Jul 1999 07:26:43 -0500
X-List-Name: BPCS Users Mailing List (BPCS-L@midrange.com)

My client is on 6.1 mixed mode.

I am interested in knowing how other clients get around the limitations of
the relationship between Subsystem Event Determination and Events.  Here
are the criteria we are looking for:

1. Single Database environment
2. Single company due to company master, vendor master, etc.
3. A separate ledger or a separate book for each facility.

The problem exists in Subsystem Event Determination where the keys are (1)
program, (2) reason code, (3) company.  Since company is the same that is
not a key that we can use to get to a specific ledger/book.  If you
consider the inventory post program you would have (1) the program INV920
and (2) a reason code such as "A 01".  This by itself does not give you
anyway to identify this transaction from one facility to the next.  The
only option that I can see that BPCS provides is to create a macro-able
event.  If you macro in warehouse into Subsystem Event Determination from
ITH then you create an event equal to the warehouse code.  This is ok if
you only had one transaction effect code and or one reason code.  Since the
reason code does not flow through to Event Setup all you have is the event
name and subsystem origin as keys in Event Setup.  Another option, since we
have configurable macros is to concatenate two fields together such as
warehouse and something else.  This does cut it either because you
essentially need to have three fields concatenated together - warehouse,
transaction type, and reason code to make this work.  Unfortunately you
cannot create a configurable macro from a configurable macro.

I have an idea through a trigger program on how to do this but if I there
is a way I can do this through vanilla BPCS that I am missing I would like
to know what it is.  Also if all else fails maybe they can be convinced to
be a single ledger, single book with security rules setup to prevent their
decentralized plants from booking transactions on the wrong facility.

P.S.  I didn't mention using separate reason codes for each transaction in
subsystem event determination because that is not a realistic solution.

Thanks for your help,
Mark Seaton
+---
| 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
+---


_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
+---
| 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
+---


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].