RE: Order Type 9 - Post to GL? -- BPCS-L

BPCS mixed mode 405 CD modified
We use DRP re-supply orders also modified

You might check your assumptions * There may be GL stuff that came from resupply order activity, but not because of AR * Depending on the process by which the resupply orders get entered into your system (ours is heavily modified, involving human beings who make mistakes), some of your resupply orders might not be correctly coded When our re-supply orders are shipped, they create "B" inventory transactions, just like any other shipments, and all "B" transactions get posted to GL along with other inventory transactions ... check "B" in your transaction effects ITE file.

When the shipments BBL file drives Billing, the re-supply order shipments are in there, but we get no Invoices or A/R hits on them, so no GL post because no Invoice no AR, due to the Billing process, but as shown here, there are GL posts due to OTHER resupply order activity.

When the RO items are received at the other facility, they are received into inventory .... we use the wrong transaction code, one of our modifications ... but check what your transaction effects have for what transaction you use ... some transactions are invisible to the GL, such as transfers between locations within a facility. This should lead to another hit on GL due to the resupply order inventory arriving at the facility that needs it.

If you do not want customer order type 9 transactions posting to GL, you might look at if they are uniquely identified in ITH inventory history ... we have a situation in which we have some ITH transactions we not want going into GL, but we do want to leave the ITH transaction intact ... basically when certain types of too-frequent human screwups are identified, we want to prevent BPCS from propagating the screwup to other places in BPCS.

You see there is a process to post ITH transactions to the GL and BPCS knows which transactions need to be posted due to their transaction effect ITE rules and the status of the GL posted flag ... SO ... if you had a program to look at ITH transactions that are candidates for going to the GL, to see which are related to resupply orders, then flip their GL posted flag, before running the program to post to GL, then the resupply orders would never get there, because you would have fooled the transfer to GL into thinking they already done.

If you want to go that route, you might check on how the GL knows what is the value of your inventory ... there is also the related topic of your GL trying to track the $ value of your total inventory ... we have a problem there keeping our GL in sync with the total standard cost of the quantity of our inventory, requiring monthly adjustments to keep them in sync.

If you block resupply inventory transfers from getting into your GL, then you could also run into the $ value of your inventory accounting concern.

- Al Macintyre http://www.ryze.com/go/Al9Mac Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/ -

BPCS mixed mode 6.00.04. Heavily modified.

WE use drp re-supply orders.

Did not do anything for AR; but we did use an identifiable financial reason code. Am pretty sure our finance people did something in GL so that it did not post.

-----Original Message-----
From: PyleD@xxxxxxxxxxxxxxx

Hello all -

We have just started using order type 9 (for DRP re-supply orders).  We set
the Order Entry parameter so invoices from these orders won't post to AR.
My understanding is that because they don't post to AR, they also shouldn't
post to GL.  However, in our case, they did.

Two questions:
1.      Is my assumption correct?  No AR post means no GL post?
2.      If I'm wrong, is there any way around this?  I thinking of using a
macro-able event in CEA to prevent the order type 9's from posting to GL.
Any other ideas?

Thanks,
Duncan Pyle
Senior Business Systems Analyst
Malden Mills Industries
pyled@xxxxxxxxxxxxxxx