|
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-2024 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.