|
We are 6.0.02 C/S. We had a similar issue with departments. We resolved it
by using separate reason codes for each department. We were then able to
run all the transactions through the same event and use the reason code for
the macro in the model to determine department. I know you said that that
separate reason codes were not a realistic solution, but because each
department does its own inventory transactions, they only had to learn the
reason codes that applied to their department, so it wasn't as ugly as it
first seemed.
As an alternative, you could set all of these events to bypass the journal
entry, create a file from the ITH through query or other means, and set up
ATP to receive the information from BTP instead of Inventory Processing.
You really haven't stepped far from vanilla BPCS, and could run this
process with the same frequency you planned for INV920.
Martha Bayer
Badger Mining Corporation
920-361-2388
mbayer@badgerminingcorp.com
-----Original Message-----
From: Mark Seaton [SMTP:maseaton@earthlink.net]
Sent: Tuesday, July 27, 1999 7:27 AM
To: bpcs-l@midrange.com
Subject: Subsystem Event Determination
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
+---
+---
| 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
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.