ABANDONED(27/06/06)
This spec has been put on hold since we decided to make use of some existing options to solve this problem, although it still does not address the issue of double receipting.
See PoRequiredOption
Stop double receipting when doing stock receipts (using blind receipting or otherwise)
There are two possible ways of receipting a purchase order:
- Lines are generated from the acutal purchase order.
- Blind Receipting, where the user is forced to put in all the lines manually.
One of the major problems with the current approach is that the user can receipt the same line more than once, and will not be stopped. This is due to the fact that the current checks just ensure that the user receipts an item that exists on the purchase order. There are also some checks that are supposed to ensure that the user does not over receipt the item, however this at best, works in a small number of cases, and does not work at all if you are doing blind receipting.
To solve these problems we propose a new method of checking the receipt lines against the purchase order.
A temporary index will be built at the beginning of the transaction with all the lines that would have been generated normally if the user had selected the option not to use blind receipting. There will be exactly one entry for each stock item from a particular purchase order in the index. The index entry will consist of the following:
- Purchase Order Number
- Stockcode
- Total Quantity
For example, if a purchase order with reference number 11223 contains two lines for the stock item 1001 with the quantities of 1 and 2 respectively, the entry in the index would be:
- {11223,1001,3}
As the user enters lines for the transaction, they will be checked against this index. If the stock item cannot be found, or if there is insufficient quantity remaining, they will not be allowed to complete the line. The two possible places where these errors will be produced is when the user is selecting the stock item, or when the user is editing the quantity field.
If during the transaction line entry, the user hits F7 (New PO), the temporary index will have to be updated with all the lines that match the criteria selected.
(Implementation Note: Will have to catch the case where the user selects a purchase order with the same number again, to ensure we dont re add the lines ... can do this by just looking for any entry with that purchase order number in the temp index and then not continuing with the index update)
When editing a quantity, the corresponding entry in the temporary index will have to be updated. The quantity will need to be decreased or increased depending on the change. If the user was not doing blind receipting, all the quantities in the index should start off as 0 (since the lines would have already been generated)
Description |
Time required (Hrs) |
Building an index at the beginning of the transaction consisting of all possible lines |
4 |
Altering the index during transaction line entry and modification |
4 |
Checking against the index during transaction line entry and modification |
2 |
Testing |
2 |
Documentation |
1 |
Quote/Specification |
2 |
Back porting changes to rel 8 |
5 |
Total |
20 |
Aegis# 9762
