sukesh75
7th March 2007, 15:52
Hi Guys,
We are looking for a solution to restrict purchase order receipts from receiving more than whats ordered and sales order deliveries from delivering more than whats ordered in Baan. Right now, we have our own triggers running on pur045 and sls045 tables doing this job but since the volume of data has increased so has there been an increase in fatal errors whenever a client goes through either receiving or delivering.

Is there any other way we could do this, without customizing the form script?? We use Baan 4c4 SP19 on SQL 2000..

sk

yashwant
31st March 2007, 10:37
u can give the form label restriction.no need to write script.

sukesh75
1st April 2007, 09:37
Thanks Yashwant for the reply. However i mentioned in my thread that i was looking for solutions that didnt involve customizing form scripts as we do not have rights to customize scripts or development. Apart from that an application of service pack would have an undesired effect on a customized form script..

sk

EdHubbard
2nd April 2007, 14:32
As long as they are normal Baan users (not super users) you could use Baan database authorisations.

e.g. Maintain Table Data Authorisations ttaad4134m000.

Upside = easy to implement

downside = have to copy the restriction for each user &
supposedly it can significantly slow down your system (but we have never experienced this).

Ed

sukesh75
3rd April 2007, 10:08
Hi Ed,
Although i never did give that session a thought while looking for a solution to my requirement. After investigation however, i found out that there is limitation to what you can put in the Value field. Baan expects constants and not field names. To check how much is being received of the ordered, i have to check the oqua(Ordered Qty) and dqua(Delivered Qty) field. I even went to the Maintain Table Field Data Authorizations {ttaad4135m000} but unfortunately it only gives you provision to check fields from one table and the receipt table doesnt have an oqua field to check what was ordered.
Thus i dont know if your approach would work..IF there is something you know to make this work with the ttaad4134m000 session please do let me know..

As it is i want to stop people from receiving or delivering more than whats ordered. In my trigger i am stopping it by checking whether the sum of delivered qty in tdpur045 table exceeds that of ordered qty in tdpur041..(for the receipts)...

Looking forward to your reply...
sk

EdHubbard
4th April 2007, 15:30
I see what you mean.

I guess you have looked at this other thread relating to your problem:

http://www.baanboard.com/baanboard/showthread.php?t=9081


Going back to table authorisations, if you have particular items that cause problems (we have a few that the unit of measure is different to normal), then you could just add a restriction for those items based on fixed quantities.

Ed

sukesh75
4th April 2007, 16:45
Hi Ed,
Went through that thread and was informative but least helpfull. With regards to the last sentence of your reply..
"Going back to table authorisations, ....."

Unless one is so sure that the ordered quantity of an item will be the same throughout its purchasing cycle, how could a fixed quantity be used?

Sk

EdHubbard
4th April 2007, 16:56
Sorry for not being clear.
What I meant is, say you have an item that has a unit of measure in thousands and you normally purchase something like 12 thousand then you would need the user to purchase receipt 12 [with a unit of a thousand].

However, the user may enter 12,000 not thinking that the thousand part is already included as part of the unit of measure on the item.

Therefore in table authorisations, for this item, you may want to restrict the maximum that can be receipted to something like 50.

sukesh75
5th April 2007, 08:33
That will work when you have a clear idea as to how much you would usually buy of an item. In my setup however it all depends on the requirement and the ordered quantity never the same in all the POs. As far as the deliveries(sales orders) are concerned we have customized items which are sold as per customer requirement and that too never the same in quantity.

Anyway, i appreciate the input on this Ed. I guess i have no other way than to stick to the trigger i have on tdpur45 table.

sk