jroberts
14th August 2003, 18:38
Our users would like the ability to re-set the status of a production order from 'completed' to 'active'.

This is becuase the users sometime over-book production ('Report Production Orders Completed, tisfc0202m000) and the update the status of the order to 'complete'.

If the order was still active, then a negative quantity could be reported complete, bringing the reported quantity into line with the actual production.

I am going to do some scenario testing,
which may result in a new session that allows the user to reset the status,

but I was wondering if anyone else had run into this problem, and their solution.
Thanks,
John

lbencic
14th August 2003, 19:21
Hi John -
Funny you should ask, we just developed this solution for another client. One problem we had after reversing from complete to active is that whenever they then go to enter a negative quantity then complete again, it was not allowing it. Try that part manually before you go too far, it may have just been a problem with our version. It worked the same manually. We found that using API's we were able to recomplete it just fine, and since our session not only reversed the status but also accepted the negative quantity and recompleted, that was ok with us, but odd.

Let me know if our process is something you would be interested in, we plan on making it a standard offering. It uses the API's, so would be compatible with most versions of Baan IVc4.

Lisa Bencic
RMCis
www.rmcis.com

jroberts
14th August 2003, 20:40
Our system does accept the negative quantity complete.

So the question comes down to,
can I just adjust the status on the order, or are there other tables that need to adjusted as well ?

lbencic
14th August 2003, 21:03
Run a trace when you complete an order and see what is updated, I don't think there was much. Sorry, I didn't do the coding, just the testing.

tjbyfield
15th August 2003, 11:14
John

We have done some work on this for a differrent purpose: Some of the products we produce are measued by weight and it is not feasible to make the exact order quantity (which could involve up to several hundred progressive productin bookings that are each lot controlled/serial numbered and material backflushed).

We have some orders that are a little under and some over. In both cases we need to adjust the eventual quantity ordered to match the quantity produced so that there are efectively no cost variances atributable to the quantity variation. We also have cases where we post negative quantities to effect a transfer lots to different production orders due to quality/grade assessment. All of this is done automatically by our programs rather than the standard interactive programs.

In your case I presume that the the overbooking would be transferred to another order. If this is the case it may be better to stop the overbooking. This would be quite simple to do.
Much less work that allowing the order to be un - completed, posting negative amount and making sure that the correct amount is transferred to another order.

In summary I guess I am suggesting that rather than changing programs it may be better to add some input checks to stop the errors occurring. This would not only same the programming work but would be much more efficient fo the production entry people.

Terry

tjbyfield
15th August 2003, 11:14
John

We have done some work on this for a differrent reason: Some of the products we produce are measued by weight and it is not feasible to make the exact order quantity (which could involve up to a couple of hundred progressive productin bookings that are each lot controlled/serial numbered and material backflushed).

We have some orders that are a little under and some over. In both cases we need to adjust the eventual quantity ordered to match the quantity produced so that there are efectively no cost variances atributable to the quantity variation. We also have cases where we post negative quantities to effect a transfer lots to different production orders due to quality/grade assessment. All of this is done automatically by our programs (which are scheduled by cron ) rather than the standard interactive programs.

In your case I presume that the the overbooking would be transferred to another order. If this is the case it may be better to stop the overbooking. This would be quite simple to do.
Much less work that allowing the order to be un - completed, posting negative amount and making sure that the correct amount is transferred to another order.

In summary I guess I am suggesting that rather than changing programs to accomodate the loose(incorrect)-production reporting, it may be better to add some input checks to stop the errors occurring. This would not only save the programming work but would be much more efficient for the production data entry people.

Terry

rupertb
15th August 2003, 11:15
Lisa I think I can help you there - whenever a negative quantity is to be posted in 'report production orders complete' it searches for the inventory in the 'Receipt' location of the warehouse the inventory was posted to. So if a generate inbound advice was done on the inventory you will first have to do a warehouse order transfer taking the inventory back into the 'Receipt' location from the 'Normal' location before the negative posting can be done.

As far as resetting the status in GTM is concened we regularly do it, however note that reseting it to active manually after it has been closed is out of the question as you will double post the production results when you close it again.

Take a look at ticst0203m000 before you create a custom session.

Regards,
Rupert

lbencic
15th August 2003, 17:25
Thanks for the process Rupert, that probably explains a lot. Your right the un-completing was the easy part, the negative quantity complete was the hard, and our coder spent weeks on that. All of that is HIGHLY dependent on the status of the order when completed. Were there shortages? What's the status of the shortages? Was it backflushed? Were there related purchase orders associated? QMS?
The process we wrote uses that ticst0203m000 session as an api to un-close orders. I would not dare write a custom one for that, but beware - it can take an hour to run all by itself :eek: