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



We have packaging, tape and solder set to a Y for must single issue in
the Bill of Material - it does not backflush - instead we do and IE
transaction when a "bundle" of boxes is issued to the production floor.
We have the IE transaction tied to the WIP GL account - basically it is
an issue to wip but not to a shop order.

Boxes come in - Po receipt done - counts as inventory as long as in
Stores, request from floor - do an IE transaction - removes inventory
from perpetual inventory and puts the value in "wip"

When Finished goods are completed - components not set to "Y" will
backflush CI (credit raw at frz std for each component, debit wip for
the same) and the PR puts the finished goods on hand (credit wip for FG
frz std cost, debit FG for FG frz std cost) - the "boxes" value are
already in wip from the IE transaction. You may have a Wip adjustment
at month end if more boxes were issued to Wip than "used".... Ends up
being a Material Usage Variance.



----------------------------------

message: 1
date: Wed, 14 Oct 2009 14:31:05 -0400
from: Bud North <bnorth@xxxxxxxxxxxxxxxx>
subject: Re: [BPCS-L] 6.00.04 Backflushing

In ERP LX, there is a package/box size that does exactly this - and it
even works. In your case, it sounds like you'd set it to 1 (box). But
alas, LX doesn't help you at 6.4. If you're on maintenance, maybe you
can get LX and take a look at the code and retrofit it or maybe just
call the helpline and ask them to send you the code. I'm not technical,
but it can't be that complicated - as Al Mac suggested.

At 6.4, my only suggestion is to consider the Usage Code associated with
the BOM Item. The default is 'blank' (which actually means variable
based on the quantity of the parent you are producing - typical for most
BOM items) - but a Usage Code of '0' means Fixed Quantity. In your
example it would always be 1. That solves the decimal problem - but if
you really needed more than 1 box - this setting doesn't scale - it is
always 1 regardless of the quantity of the parent item you are making.


That said, you use the word 'ship' - so I'm now thinking that maybe you
are using a batch size on your BOM of 15. This, of course, would
present a problem if you produce and 'ship' only 2 pieces for
backflusing items like the box. In this case, and if you are using a
batch size on your BOM, consider changing the batch size to 1. It
doesn't fix the problem when you make 15 as it will scale everything
baed on 15 - but in conjunction with what I've mentioned above, this may
help.

Maybe I've at least generated some thought processes for you!

Bud North
PHOENIX Business Consulting, Inc.
Cell: 508-572-9701
PHOENIX Email: bnorth@xxxxxxxxxxxxxxxx

________________________________________
date: Wed, 14 Oct 2009 09:33:17 -0400
from: Norman.Boyd@xxxxxxxxxxxxxxxxx
subject: [BPCS-L] 6.00.04 Backflushing

We have an issue where we SOMETIMES packages fewer items in a box than
the box was intended to hold. The BOM was setup for 15 pieces per box.
If we only ship 2 pieces, only 2/15 or .13333 pieces get backflushed.
Is there anyway to cause, other than entering an alternate BOM, the
backflush process to automatically round up to a full unit?

Thank you

Norman K. Boyd
MIS Administrator
Showa Aluminum Corp. of America

------------------------------

message: 2
date: Wed, 14 Oct 2009 21:07:59 -0400
from: cfgwizard@xxxxxxx
subject: Re: [BPCS-L] 6.00.04 Backflushing


Norman,



If I understand correctly, you want 2 units of the finished goods item
in inventory and you want to relieve component inventory as if 15 were
produced. Perhaps you could report 15 FG which will backflush the
components. Then reverse the transaction for 13 units. This should leave
you with the net difference in FG and no adjustment for component
issues. You will have to determine if this yields an acceptable result
for accounting and labor reporting. Also need to analyze who you want to
authorize for this adjustment process.



Larry Costain


-----Original Message-----
From: Bud North <bnorth@xxxxxxxxxxxxxxxx>
To: bpcs-l@xxxxxxxxxxxx <bpcs-l@xxxxxxxxxxxx>
Sent: Wed, Oct 14, 2009 1:31 pm
Subject: Re: [BPCS-L] 6.00.04 Backflushing




In ERP LX, there is a package/box size that does exactly this - and it
even orks. In your case, it sounds like you'd set it to 1 (box). But
alas, LX oesn't help you at 6.4. If you're on maintenance, maybe you
can get LX and ake a look at the code and retrofit it or maybe just call
the helpline and ask hem to send you the code. I'm not technical, but
it can't be that complicated as Al Mac suggested.
At 6.4, my only suggestion is to consider the Usage Code associated with
the BOM tem. The default is 'blank' (which actually means variable
based on the uantity of the parent you are producing - typical for most
BOM items) - but a sage Code of '0' means Fixed Quantity. In your
example it would always be 1.
hat solves the decimal problem - but if you really needed more than 1
box - his setting doesn't scale - it is always 1 regardless of the
quantity of the
arent item you are making.
That said, you use the word 'ship' - so I'm now thinking that maybe you
are sing a batch size on your BOM of 15. This, of course, would present
a problem f you produce and 'ship' only 2 pieces for backflusing items
like the box. In his case, and if you are using a batch size on your
BOM, consider changing the atch size to 1. It doesn't fix the problem
when you make 15 as it will scale verything baed on 15 - but in
conjunction with what I've mentioned above, this
ay help.
Maybe I've at least generated some thought processes for you!
Bud North
HOENIX Business Consulting, Inc.
ell: 508-572-9701
HOENIX Email: bnorth@xxxxxxxxxxxxxxxx
________________________________________
ate: Wed, 14 Oct 2009 09:33:17 -0400
rom: Norman.Boyd@xxxxxxxxxxxxxxxxx
ubject: [BPCS-L] 6.00.04 Backflushing
We have an issue where we SOMETIMES packages fewer items in a box than
the ox was intended to hold. The BOM was setup for 15 pieces per box.
If we nly ship 2 pieces, only 2/15 or .13333 pieces get backflushed. Is
there nyway to cause, other than entering an alternate BOM, the
backflush rocess to automatically round up to a full unit?
Thank you
Norman K. Boyd
IS Administrator
howa Aluminum Corp. of America
-
his is the BPCS ERP System (BPCS-L) mailing list o post a message email:
BPCS-L@xxxxxxxxxxxx o subscribe, unsubscribe, or change list options,
isit: http://lists.midrange.com/mailman/listinfo/bpcs-l
r email: BPCS-L-request@xxxxxxxxxxxx
efore posting, please take a moment to review the archives t
http://archive.midrange.com/bpcs-l.
Delivered-To: cfgwizard@xxxxxxx



------------------------------

--
This is the BPCS ERP System (BPCS-L) digest 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.



End of BPCS-L Digest, Vol 7, Issue 160
**************************************

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.