In the OnDelete trigger of table 37 (Nav 4.0) there is the following code, which looks quite silly to me:
IF “Document Type” = “Document Type”::“Blanket Order” THEN BEGIN
SalesLine2.RESET;
SalesLine2.SETCURRENTKEY(“Document Type”,“Blanket Order No.”,“Blanket Order Line No.”);
SalesLine2.SETRANGE(“Blanket Order No.”,“Document No.”);
SalesLine2.SETRANGE(“Blanket Order Line No.”,“Line No.”);
IF SalesLine2.FIND(’-’) THEN
SalesLine2.TESTFIELD(“Blanket Order Line No.”,0);
END;
credo che serva per controllare che non ci siano righe vendita legate alla riga dell’ordine programmato che stai cancellando. Direi che invece del TESTFIELD ci sarebbe stato meglio un ERROR che fosse maggiormente esplicativo …
Dovresti prima cancellare le righe ordine derivate da quella riga dell’ordine programmato.
The purpose of a Blanket order is to log into the system an order that indicates that the cleint will take a certain qty of goods, but as yet they don’t know exactly when. You don’t want them as a standard order, for two reasons, one that the quantities become a part of statistics, and thus the items could get ordered or manufactured, and also because of the chance that the items will ship.
There are a lot of reasons for Blanket orders, but two tpical ones, are Pricing and Planning. In the pricing scenario, you tell the customer that they get a special price if they agree to order 1000 items over a year, and at the end of the year you can easily track what they did and did not order. Secndly its a usefull place to store planning numbers for the production and sales department where they can see global plans.
So in the case that the Blanket order for 1,000 items had had 200 items converted to orders, and then the order line was deleted, the customer would apear to have ordered (rememeber Ordered, not Received or invoiced or paid for) more than they actually did.
Thus the code.
I would suggest if this code is not needed in your clients scenarios then maybe Blanket orders is not the right thing for them.
I think its more important to address why the Sales Order is not being deleted. You can run the periodic activity to delete them. Either way you really don’t want to be leaving closed sales order in the system, since that will start to affect performance. If the case is just that there are some line non yet fully invoiced on the order, and so the order can not yet be deleted, isn’t it best to wait till the oder is fully posted before deleting the blanket order.
In my experience, many customers ask to have the functionality which automatically deletes fully invoiced orders, both sales and purchase orders, removed. They do prefer to choose themselves when their orders have to be deleted. This was the case with this particular customer.
They wanted to keep the orders and get rid of the oldest blanket orders. I wrote a function that, on demand, erases the links between a given blanket order and its derived sales orders.
They seem to be happy with it. [:)]
Do be careful with this, especially if running on SQL. The Sales Line Table is designed to be a temporary table, and should never get “too” big. There are many flow fields based on this table, that are included even if the Outstanding Qty is zero.
Also as you get a lot of unused lines, you can increase problems with Dimension lockings.
I have also done this mod, but only with careful contemplation and understanding of the issues that can arise.