Good morning Rob,

Well, I'll start with a prayer that CertainTeed won't need an enormous
number of move transactions to clean out their bad/fictitious locations.
Even if they only have 65 transactions to assemble, there still is a
simplicity and efficiency to start the data collection in spreadsheet ...
you know, carry the laptop right out to the warehouse and type in (or gun)
the list of items sitting in this location. Excel copy tools can populate
the warehouse and location columns instead of typing those in for each line.
Then with some research, figure out valid locations where they can be moved
and gradually populate the spreadsheet with those new locations.

Then, (assuming there's Wi-Fi in the warehouse) fire up Lickety-Split and
the BPCS INV500 entry process will be finished (with zero key-punch errors)
long before you can walk back to your desk. Immediately try to deactivate
the bad location before some other process adds more inventory to that bad
location. Print out the spreadsheet, sign it, and give it to a material
handler to execute. You've crossed off one of the bad locations and you've
only had to key in the move information once.

It's slick. With some luck finding valid places to move the inventory, your
coffee will still be warm when you get back to your desk.

Peace to you and God bless,
Milt
Unbeaten Path International
(+USA) 262-681-3151
(888) 874-8008





From: Rob Berendt
Sent: Friday, April 28, 2017 6:13 AM
To: BPCS ERP System
Subject: Re: automating the manual data entry pain: Lickety-Split

But, thinking back to the original question, how does this help him
deactivate a location?

Rob Berendt





From: "Milt Habeck" <mhabeck@xxxxxxxxxx>
To: "'BPCS ERP System'
Date: 04/28/2017 07:11 AM
Subject: automating the manual data entry pain: Lickety-Split

Good morning ...

Norman .... many thanks, and yes, if a particular row of the spreadsheet has
data that fails an edit check in the BPCS/ERP LX program, the error message
off the bottom of the display screen is captured and written back into the
spreadsheet on the same row as the data that caused the error. That "bad
data" row is then skipped and Lickety-Split goes on to process the next row.
When the job is done, all of the successfully entered rows are timestamped
with the instant the data was entered. Save that result spreadsheet for the
auditors.

Take a copy of the result spreadsheet and in that copy isolate the error
rows with a quick sort. Delete the successful rows. Then tackle the errors
one at a time, fix them in the spreadsheet, and then re-run the corrected
lines into BPCS again using Lickety-Split. Save that final clean result
spreadsheet for the auditors.

We are fine-tuning a new version of Lickety-Split right now which will
actually save a screen print when any error occurs and record the picture
file name into the problem Excel row. To be transparent, it's not quite
ready for delivery yet but it's much, much, much further along than we could
have hoped when development work on the improvement started after
Christmas.

I agree with Norman about the benefits of the spreadsheet approach which
allows for supervisor review of the entire set of data before entry. You
know, think about loading up new prices. The controller has done a zillion
calculations and sorts to make sure the new prices are perfect in the
spreadsheet. He signs the bottom of the spreadsheet. Then all that data can
be entered flawlessly with Lickety-Split. No accidently skipped lines when
the keypuncher gets distracted, no $411.44 prices keyed in as $41.44, no
two-day wait to get all the new prices entered. Ditto for new standard
costs.

Lickety-Split can do much fancier things too .... like entering multi-line
customer orders. For example, if your customer can send their orders to you
in a table with a header row for each order and then an additional row under
the header for each line item, you can develop a Lickety-Split script to
enter those orders automatically. It's a slick poor-man's "EDI" order entry
system.

The product also works at iSeries shops that never heard of BPCS.

Peace to you,
Milt Habeck
(+USA) 262-681-3151
mhabeck@xxxxxxxxxx








From: Norman Boyd
Sent: Thursday, April 27, 2017 6:53 AM
Subject: Re: Deleting an Inventory Location -- automate the manual data
entry pain

I have used Lickety-Split and as many of you know filling out a spreadsheet
with intended transactions is a little easier than manually keying every one
of those into the inventory transaction screen. Fewer keystrokes if nothing
else AND the ability to review the transactions as a set.

Lickety-Split uses the native BPCS screens and records back into the
spreadsheet whether or not a transaction was successfully posted. If I
recall correctly, Milt please correct me if I'm wrong, it can record the
reason a transaction did not post. Even if it doesn't record the reason,
you can manually key a handful of FAILED transactions and see why they
failed. If you would hit the F13 key to override the error, you can go back
and program that into Lickety-Split and re-run the missed transactions. Or,
if you keyed something wrong and that's what's causing the errors, fix the
data in the spreadsheet, removing the successfully processed records, then
re-run the process.

My conclusion, if you have a LOT of transactions to manually key on a
regular basis, key them in a spreadsheet where you can review them for
accuracy then run Lickety-Split.

As a note - we've used Unbeaten Path for BPCS training and have several of
their software packages making the maintenance and some analysis of BPCS MRP
data easier.

Norman K. Boyd
MIS Administrator
Keihin Thermal Technology of America, Inc









From: Rob Berendt
Sent: Wednesday, April 26, 2017 5:47 PM
Subject: Deleting an Inventory Location -- automate the manual data entry
pain

Nice plug, but wouldn't you have to key the data into Excel?

So, I can key the data into INV500 manually, with its interactive edit
checks, or, I can key the data into Excel without any edit checks and then
pump it up with your software and then let the edit checks happen.

I can only see this being an advantage if I had some method of an
intelligent automated process which would dump out the necessary
corrections, convert that into Excel, and then pump it up with your
software.

Rob Berendt











From: "Milt Habeck"
Date: 04/26/2017 05:43 PM
Subject: Deleting an Inventory Location -- automate the manual data entry
pain

Dear Robert,

Replies from Mr. Bilgen and Al Mac confirm our conclusion that a
considerable amount of manually-entered inventory transaction activity will
be needed to solve this.

There is no way within BPCS to prohibit the use of an active location by
specific items. So, it's necessary to deactivate your bad locations and to
do that, all inventory quantities will first have to be removed or moved.
The simplest method would be to remove or zero out invalid locations with a
cycle count type of transaction, but that does not handle actual inventory
that may exist. So a better alternative would be to transfer any existing
inventory found in the bad/fictitious locations into valid locations.

Here's an idea to greatly reduce the pain of manually entering a high volume
of transactions. Our Lickety-Split software transports rows of Excel data
into iSeries green screen apps (in this case INV500) as if it were being
keypunched. It's lightning fast with zero fat thumb errors .... and .... all
the edit checking in the green screen application is still performed. It's
slick.

More information --->

www.unbeatenpath.com/software/dataentry/Lickety-Split.pdf
Reference letter ---->

www.unbeatenpath.com/references/away02stewart.pdf

Automating the INV500 entry effort with Lickety-Split makes the inventory
clean-up extremely quick .... before more inventory arrives in the bad
location by accident.

Additional research may be needed to see what is causing your inventory to
get into the bad locations in the first place. If it is arriving from open
shop orders or allocations, those may also need to be taken care of before
locations can be deactivated.

Warmest regards,
Milt Habeck
Unbeaten Path International
mhabeck@xxxxxxxxxx
(888) 874-8008
(+USA) 262-681-3151
www.unbeatenpath.com









From: B Bilgen
Sent: Sunday, April 23, 2017 8:06 AM
Robert, You can always run INV970 which will delete all records from the
lot, location, and container files (ILN, ILI, and YCI) that do not have any
inventory and do not have any activity. However it doesn't sound like that
is the activity you want to do. There is no system program available to
remove a single item from the location inventory - you will need to do this
manually. Here are the steps that BPCS takes before removing records (in
INV970). It would be a good idea to follow the same edit checks for the
records you want to remove manually.

<snip>









From: Robert G. Hermann
Sent: Friday, April 21, 2017 12:44 PM
Subject: [BPCS-L] Deleting an Inventory Location

A manager at one of our plants sent me the question below. As far as I Know
the answer to his question is No, but I thought I'd ask the experts here on
BPCS-L.

We are on BPCS 5.1.

(Unfortunately, we moved our headquarters to a new building a year ago and
were forced to ditch all hard-copy BPCS documentation prior to the move.)
Thanks in advance.

Best regards,
Bob Hermann
CertainTeed Corporation

=======



Is it possible to delete an inventory location in BPCS for an individual
part number? If so, please advise.

Background Info: We have numerous parts with multiple locations that are no
longer used. We also have a couple of a couple of fictitious locations
(e.g., BAN and PAN) we want to get rid of. We think we know how to mass
delete location from the system, but all items have to be at zero qty. We
would like to remove the locations as we come across them for individual
items. An example is part number U35A02001. You can see from the
transactions below that we reported a shop order on 3/21 and then
transferred the inventory from BAN to FM0105 on 3/27. It would have been
great at that time to the delete BAN as a location for this line item.

Trans Ref No Whse/Loc Quantity Date

Balance Lot T 30 FM0105
1.000 3/27/17 1.000
T 30 BAN
1.000- 3/27/17
PR 52698 30 BAN 1.000 3/21/17
1.000


FYI - we have recently started an aggressive cycle counting program and are
constantly running into these BAN and PAN locations, which have no physical
location in the warehouse. Inaccurate or poorly labeled warehouse
locations, part identification, and shop order reporting issues so far have
been the primary reasons for our count discrepanices. We want to clean up

the locations both in BPCS and in the plant.

Thanks in advance for the assistance.


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