You are more fortunate in your scenario than our reality.
Let's suppose end-fiscal-month date is thru either Sat 7/31 or Sun Aug-1.
Let's suppose Fri 7/30 someone has a pile of labor tickets to be entered,
for production work done 7/30, but overtime is not authorized to be keying
this in. So the labor tickets sit on the clerk's desk over the weekend,
when end-fiscal-month gets done.
There are reports showing grand total into various General Ledger accounts,
inventory valuation figures, scrap percentages, sales, past due, all sorts
of reports on what happened in the month, delivered to company executives,
auditors.
The fiscal month of July is left open, because accounting has some
adjustments that need to be posted, often based on accounting personnel
looking at what got posted into general ledger totals. There's debts for
which we do not yet have invoices, other than inventory unvouchered, like
insurance, outside operations. Reversals, all sorts of stuff understood
only by accounting. Thus, transactions dated in past fiscal period are a
valid date for other people, because BPCS cannot be flagged "back dating
needs accounting authorization or notification".
The clerk who did not get all last week input completely entered last week,
now starts keying in data, on Aug-2, using date of 7/30. BPCS posts this to
the fiscal period of 7/30, which we supposedly just completed. Inventory
opening balance for the month is redone by BPCS to what it would have been,
had the transactions actually been posted before INV900, or physical
inventory if that was involved. General Ledger totals get updated for the
fiscal period that 7/30 falls into, after the auditors have been sent our
official totals for the end of July fiscal.
Similar scenario is people seeing on end fiscal month reports that there is
some problem with the data, then they fix it by keying in a correction that
is back dated to the date that the error occurred.
Similar scenario if a batch is hung 7/30 and we not know it, then gets found
and fixed week after end fiscal. The transactions go in using the date that
was in the transactions when they got keyed in.
You have to know what end fiscal reports to re-run, which will not mess up
the end fiscal process.
If financial people only look at latest month totals, then they do not see
this problem until end of year, when total of each months, prior to
December, do not agree with what they were at the time of their respective
end fiscals.
We found this problem because we have a report showing value of our
inventory based on opening balance times cost, with some executives looking
at this report regularly to evaluate impact of changing cost basis. We were
not expecting opening balance to change after end fiscal month.
The problem I described is historical, since we set various policies to try
to avert in future, unless there is a training break down.
-
Al Mac
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of
Larenzo Alexander
Sent: Monday, August 09, 2010 1:00 PM
To: BPCS ERP System
Subject: Re: [BPCS-L] Unprocessed Labor Tickets
I know what you mean by:
Watch out if this is happening over an
end-month fiscal weekend, where the tickets that get posted on Monday might
carry dates that fall inside the prior fiscal month, and this happen after
you run most of your reports for that fiscal month.
This problem was noticed on our month end reports and the Finance department
is
waiting on some answers from me. :-)
Sounds like fun, fun, fun but thats for the great feedback.
________________________________
From: Al <macwheel99@xxxxxxxxxx>
To: BPCS ERP System <bpcs-l@xxxxxxxxxxxx>
Sent: Mon, August 9, 2010 11:38:37 AM
Subject: Re: [BPCS-L] Unprocessed Labor Tickets
We have clerks who get distracted. They were keying labor tickets from a
particular work station session "side", then forget which side had a batch
that had not yet been taken to a conclusion, so at close of business work
day, there are batches that do not get posted until the following day.
Where do labor tickets get the default date of labor ticket input? If
someone leaves their work station signed on to BPCS menu overnite, then next
morning enters transactions, do the transactions default to prior day's
date? This may be unique to our version of BPCS and our modifications.
There's people who don't get a batch completed by the end of their work day,
so they leave the batch open, and key in the rest of the labor tickets at
the beginning of the next work day. Watch out if this is happening over an
end-month fiscal weekend, where the tickets that get posted on Monday might
carry dates that fall inside the prior fiscal month, and this happen after
you run most of your reports for that fiscal month.
Before resetting anything, you need to be sure that there are no batches
that have not yet been submitted to JOBQ.
Talk with those clerks to get an understanding of their hassles.
Each batch is indexed by a tracking "ticket #" for the batch, separate from
the ticket # in FLT which links to ticket # in ITH for corresponding
transactions. This is used to help the clerk access a particular ticket for
correction before posting. Let's suppose their PC locks up, crashes, while
in middle of keying tickets. The tracking ticket # does not get updated
properly, then if the clerk restarts the job, without any effort to deal
with what got messed up by the crash, the later tickets input can overlay
the prior ticket effort. All sorts of things can get messed up. I have
instructed our people ... any time you have a crash, take that batch to a
conclusion, before starting another batch.
-
Al Mac
-----Original Message-----
From: bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+macwheel99=wowway.com@xxxxxxxxxxxx] On Behalf Of
Kevin Harper
Sent: Monday, August 09, 2010 10:06 AM
To: BPCS ERP System
Subject: Re: [BPCS-L] Unprocessed Labor Tickets
Larenzo,
It sounds like one of three possibilities...
1. Somebody selected tickets to post, but never posted, and
subsequently exited or timed out of their session while still in the labor
reporting program.
2. The posting job was submitted, but never ran (sitting in jobq, held,
deleted, etc).
3. The job was submitted and ran, but ended abnormally before the FLT
record status was updated.
#1 is usually the winner in this situation.
Make sure nobody is in the labor reporting program, and set FLT.LTSTS back
to blank where it is currently '1S'. Then have the user who entered them
(FLT.LTMNUS) try posting again.
Yes, your "unposted" report is correct (status = 1S).
Kevin Harper
On Mon, Aug 9, 2010 at 8:29 AM, Larenzo Alexander <
larenzo_alexander@xxxxxxxxx> wrote:
I have a situation with Labor Tickets in BPCS that aren't getting
processed and
I was wondering if any of you can point me into the right direction of
what
to
check. And if I understand correctly if the labor tickets dont get fully
process
then that means some of the mateiral dont get backflush correct? I
created
a
report that runs at the end of the day that list all the labor tickets
with
a
status code of '1S'. I believe that code represents Locked and waiting to
be
processed? The finished material has beed issued so those records should
have a
P=Posted on them. And when I check the Shop Order on some of them the
qauntity
remainging is zero but some of the Labor tickets dont have a P=Posted
beside the
tickets.
Any idea what could be causing those Labor Tickets not to get posted and
I'm
assuming I would have to go manually posted those tickets to flush the
material
out the system but I would like to determine the cause of the problem.
Thanks in advance,
--
This is the BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.
Delivered-To: kharper@xxxxxxxxxxxxxxxxx
midrange.com
