× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Fwd: BPCS queries.
  • From: MacWheel99@xxxxxxx
  • Date: Sun, 24 Dec 2000 22:53:46 EST

I can address SOME of your questions, but it would be helpful to some folks 
if you told us

1. What version of BPCS are you on?  We are 405 CD. Various flavors V6 more 
common in users here, but I have also seen questions about V5 & V403

2. What platform are you running BPCS on?  We are AS/400 mixed mode V4R3.  
BPCS can also run on HP Unix or M$ NT & of course other flavors of AS/400.

Your Question-1 about companies & customers & combining payments.
We are not using multiple companies because we want to be able to integrate 
all of our business as one unified whole.  I always thought of multiple 
companies being like you are running some totally separate unrelated business 
entities in which there should be no need to consolidate money or inventory 
between them.  You need to keep the books totally separate.

Your question sounds to me like there is a hole in your Business Requirements 
as opposed to how people are trying to function ... either the BR needs to be 
rewritten, or you are trying to violate it.  We have four separate divisions 
and we define them in BPCS using facilities within the same BPCS company.  
But you have to be at a high enough version of BPCS for facilities to work 
that way.  We also use DRP for inter-facility activity so that the inventory 
can be handled same as with vendors & customers, while avoiding the need to 
bill ourselves for transfers & do all that ACR ACP stuff.

For combining payments, we often have customers that have different divisions 
in different cities & a corporate HQ that pays all the bills for the 
divisions.  In this scenario we use corporate customer accounts.  The billing 
& accounting is setup to go to the one corporate account, while the customer 
orders & shipments & production is all keyed to the bill to ship to city.  It 
is like a same customer can have several accounts at the same time in BPCS.
Corporate HQ account gets the bills & A/R reconciliation.
Bill To account shows up on all reports processing the orders through 
shipping.
Ship To account has the actual ship to address.

Your second question on PB, which I am not familiar with, indicates to me 
that perhaps you need to make sure your sizing questionairre has been updated 
to reflect your PB usage.  The sizing questionairre has been jointly 
developed by IBM & SSA to predict what your system needs to perform 
effectively with ALL the stuff you want on your system & it may be that your 
system has been optimized to function without PB because it was not listed on 
the questionairre.  It might be helpful to have a copy of the sizing guidance 
before & after PB in the picture to see what the differences are.

One element of this is the trade off in resources between traditional 
INTERACTIVE (twinax users), JOBQ BATCH, and how PC stuff connects to the 400. 
 Depending on the mixture you using, you need both hardware realities & some 
performance tuning work to avoid being on a system that is setup for one 
connection reality but you are ffunctioning in a different reality.  This is 
a topic that is often not easy to comprehend, which is related to my second 
question of clarification where you are.

I have also noticed on our site that we can take a performance hit if someone 
is running a Query/400 that was inefficiently written to connect two or more 
of the giant files (Cost Master & Inventory History are both over 1 million 
records) then they try to run this interactively.  The same identical job 
will run off JOBQ in under 2 minutes, or lock up the whole system for hours 
if run interactively.  For us, the performance hit is not the size of the 
report (2 pages), but how it is being run & the nature of how the code is 
written, and version upgrades.

For ACR300 it might be helpful if you looked at the documentation that comes 
with BPCS, off of the DOC menu for ACR & ORD & see what it says about the 
ACR300 logic.  Our ORD documentation is too big to view via SEU except by 
using split windows, so we split it into several copies by general topic, 
with the help of PDM.

Is the Open Orders by Customer Report some standard unmodified BPCS option, 
something that has been modified by Y"ALL, or something you created?  We have 
a LOT of reports we have added to standard BPCS & sometimes our people have a 
different way of looking at things than the SSA programmers.  It might be 
helpful if you identified the BPCS ORD-whatever report that is showing 
different figures than ACR300.

We have had problems in some reports not showing that some credit is due to 
unfinished RMA processing, or our shipping folks overshipping some order 
lines & undershipping others, so we have mismatch vs. what the customer 
really needs & what is left to ship, or if you are only looking at regular 
order lines & not seeing the impact of special order lines.  But much of our 
problems are due to people writing Query/400 reports off of BPCS data without 
understanding all of the BPCS nuances, then other people seeing that 
Query/400 disagrees with some BPCS inquiry & want to behave like the Query, 
whose logic they understand, is correct, while the vanilla BPCS data that 
they don't, is not.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838



Please advise on the following four issues.

                 ************

We have four different companies defined in our
existing BPCS setup, as per our business requirement. 
And, we have two similar customers in two different
companies with different customer codes as per the
BPCS requirement.  Is there anyway, that we can define
the credit amount at one place, which would apply to
both the customers in two different companies.

                  *************    

We have a third party tool called Power Builder Ver.5.
 And, we use this tool quite extensively for our
reporting purposes.  We have noticed that whenever we
run certain big reports, the systems performance
reduces drastically.  It is our understanding that
this is due to ODBC interface between PB and OS400. 
Please write to us, that how can we improve the
performance / how can we solve this performance issue.

                *************

Some of our Customer orders goes on credit hold, due
to the wrong reporting of Open order amount in ACR300.
 When we have matched the open order amount in the
ACR300 with that of open orders by customer report, it
does not tally in problem cases.  It is our assumption
that the total value in the open customer order report
should match with that of ACR300.  Please let us know
why these two values do not match in certain cases. 
What is the logic behind it?  

                   ****************

We have a little bit of confusion in understanding the
logic of average paydays for a customer in the ACR300
program.  How does this value will be calculated when
invoices are settled partially.





__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.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 thread ...


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

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.