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



I hope this is not off-topic.

Do other BPCS companies feel they using printers productively?
Are you like us with one high quality high speed IBM green bar paper system printer and a passel of cheap PC printers for low volume work at people's desks?


Some questions have come up with respect to whether there are areas where we could reduce the volume of our paper consumption. This is on the occasion of some printers maintenance contracts expiring and discussion whether it is time to trade them in, and what kinds of printer best replacement. I was wondering if our paper consumption is typical for a BPCS site, and where other companies find cost savings in office overhead.

We go through a carton of green bar paper a day, plus various custom forms.
I recognize this is related to size of business and type of business.

Most of our printing is custom reports, and detail reports, rather than figuring out how to make exception reports work, or develop exception reports that only show us the data people need to act upon.

EVERYONE at our company wants detail reports, except a few managers, for whom we collectively have figured out how to digest the data they need into a few summary pages. Even me when doing programming modifications ... Yes I can view compiles on screen, but I find I can do my programming work considerably faster when I have a print out of the compilation, because I need to look at subroutines on several pages, and the cross-reference charts. than when I am looking at this on screen.

Several years ago we did an ABC analysis in which each person tried to estimate how much time they spent each day working with what data on what reports or screens. It was an eye-opener for management that there were some processes in which many people throughout the company were each spending 1/2 hour to 1 hour a day on a related work flow project such that in aggregate it was like several full time staff on something that management thought was a low management requirement ... this led to redesign of several reports.
-
Al Macintyre http://www.ryze.com/go/Al9Mac


I still hoping for feedback to  [BPCS-L] Historical RMA

We are trying to close fiscal year 2004 but have about a dozen RMAs back dated into 2004, with an aggregate of about 100 lines, plus an embarrassing volume of transactions back dated into 2003.

We are on modified BPCS 405 CD mixed mode thru REL 02 and bunch of Y2K BMRs. We are not on OSG. We do not have ROBOT or AS/Set.

I could use an education on how RMA (Customer Returns) are SUPPOSED to work, in particular if an RMA is issued, but customer not return the stuff for months, what date is supposed to go on the returns transaction, and how does that date get there.

I am "the IT guy who works at nite" so various tasks that need to be run when no one else on BPCS are handed over to me, and when I first get those tasks, my understanding of them is limited to following instructions how to run them, then over the years I get an education as we deal with things that go wrong.

My understanding is that file GJW gets populated with stuff representing the work in the rest of BPCS that has Gen Led implications, then when we run the task to post to GL stuff for the current fiscal year period, it removes whatever is in GJW and sends it to GJH_GJD in whatever state of posted, unposted due to unresolved errors, and at that point shows up on GL radar screen such as GLD310 and all sorts of GL reports. Thus, any transactions in GJW not yet posted to Gen Led are invisible to accounting.

However, if any transaction is back dated to a prior fiscal period by any activity in BPCS, that falls below the radar screen of accounting, and we only find out because IT gets curious about the data in GJW after we have supposedly posted everything for fiscal month, so how come there are still records in this file.

So I created a query to count how many hits in GJW by fiscal year, period, and journal type ... I check that when EOM completed, then later check again & sometimes note that there has been an INCREASE in transactions added for a fiscal period that was CLOSED at the time those transactions got added.

The customer service people tell me that when they issue an RMA, they do not enter a date, it is generated by the system ... this seems odd to me because I thought RMAs used exactly the same software as ORD500.

I thought that when the parts are returned, they are SUPPOSED to be credited to the RMA # that has been issued, and I am wondering how much control the materials person has over the date of the transaction.

I had thought that everything in BPCS gets dated based on system date or work station date unless human operator changes it ... and in our case work station date is never more than a few days behind system date because I habitually kick everyone off to run backup/400 several times a week. I saw earlier on BPCS_L that if PC date is whacko, that can get propagated into BPCS but I had thought that did not apply to our version.

Suppose for the sake of argument that an RMA is issued in OCTOBER 2004, and the customer does not get around to returning the product until AFTER we have closed the GL fiscal year for 2004 ... does the returned material get posted with an October 2004 date, or when it was really returned?

It sounds to me like perhaps there should be a step associated with closing the fiscal year that says "List for us all the RMAs for this fiscal year that are still open, and rejigger their dates into the next fiscal year, so that when they come back, we get accurate information into our financial records, albeit perhaps not the right dates."

-
Al Macintyre  http://www.ryze.com/go/Al9Mac



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.