Addressing Over-Allocations
An over-allocation occurs when the quantity allocated exceeds the actual, physical quantity on hand. This may occur because your Dynamics GP setup allows shortage overrides, so that prior to starting the count the allocated quantity already exceeds the quantity available, or, as a result of the physical count being lower than the quantity of inventory reported in GP the adjusted quantity would be lower than the quantity of inventory allocated.
Dynamics GP does not allow posting a Stock Count if the variance quantity would result in an over allocation. Since CompleteCount interfaces with the GP Inventory Stock Count functionality, CompleteCount must also adhere to this control.
When using the Stock Count Entry window (without CompleteCount), GP will adjust the variance quantity, regardless of the counted quantity, so that posting the Stock Count does not create an over-allocation. For example, you could start with GP reporting that you have 220 units of CAP100 On Hand, with 200 units of CAP100 are allocated. If the physical count is 150 (a variance quantity of -70), GP will change the variance quantity to -20. In other words, it makes sure that posting the count will result in 200 units On Hand so that it matches the quantity allocated.
A Stock Count cannot be posted below the allocated quantities because there is no way for the software to figure-out how to handle the over-allocations. For serial/lot-controlled items SPECIFIC transactions need to be unallocated to free-up allocations on the serial or lot numbers were not counted (they physically do not exist). Since allocations could come from Sales, Manufacturing, Inventory Transactions, or many other 3rd Party Products, the Stock Count has no way to unallocate the inventory.
For non-serial/lot tracked items, the over-allocation could mean that a Ship Date given to a customer on a Sales Order is inaccurate because there is not any inventory to actually fulfill the order. Perhaps a Back-Order should have been created rather than an Invoice. The Stock Count also cannot automatically figure-out how to handle these items.
To retain the integrity of the Stock Count module, CompleteCount also will not allow submission of a count where the counted quantity is less than the Quantity Allocated. This will result in Tag Submission Warnings, which will identify the part(s) with over-allocations.
The transactions allocating the inventory must be unallocated and a decision made about how to handle the shortage for that document. Simply allowing the Stock Count to change the variance so that posting the Stock Count leaves enough inventory to cover the allocations is not any better than not counting the items at all—the count is still wrong.
There are a couple of options for addressing over-allocations:
- Find the transactions allocating the inventory (i.e. Sales Transactions or Manufacturing Picklists), and unallocate enough inventory to allow the count to post.
- Find the items on the Stock Count Entry window and remove them from the Stock Count (see Deleting Stock Count Items). Then VOID the tags containing those items. See Tag Reporting for information on identifying the tags that need to be voided.
NOTE: See CompleteCount Setup for special circumstances under which CompleteCount will allow overriding allocations.
Serial Numbers
Counting Serial Numbers raises several unique issues particular to serialized inventory. Since there can only ever be just one of a given Serial Number in GP:
- A Serial Number cannot be on a Stock Count and a Sales Return at the same time. Since both transactions would add the serial number to GP, one of the two must be incorrect.
- A Serial Number cannot be in two warehouses at the same time. If GP shows the serial number residing in SOUTH, but it is counted in NORTH, it must be in NORTH.
- A Serial Number cannot be in two bins at the same time. If GP shows the serial number residing in SOUTH in Bin G, but it is counted in Bin X, it must be in Bin X.
- If a Serial Number is recorded on two different Stock Count Tags, one of the Tags must be incorrect.
CompleteCount takes steps to automatically resolve some of these issues. In all cases where a Serial Number is found someplace other than where GP thinks it should be, CompleteCount will automatically transfer the serial number to the correct location.
With non-serialized inventory, GP can simply increase the quantity of an Item in one Site (or Bin), and decrease the quantity of the Item in a different Site (or Bin). With Serial Numbers this is not possible because doing so would either (1) temporarily result in a Serial Number being in two locations at the same time, or (2) completely remove the Serial Number from the system and then re-add it in a different location which would change the FIFO layer of the Serial Number.
The following pages provide examples of when CompleteCount can automatically perform Inventory Transfers to resolve Serial Number issues, and when Error Conditions exist which must be manually resolved.
Serial Number Transfer Scenarios
| Scenario | Result |
| Item: 100XLG
SN: A123 Tag records A123 in NORTH GP Location: SOUTH |
An Inventory Transfer is created and posted to move A123 from SOUTH to NORTH. |
| Item: 100XLG
SN: A123 Tag records A123 in NORTH Bin: A GP Location: SOUTH Bin: G |
An Inventory Transfer is created and posted to move A123 from SOUTH-G to NORTH-A. |
| Count: NORTH
Item: 100XLG SN: A123 Tag records A123 in NORTH Count: SOUTH Item: 100XLG SN: A123 captured in SOUTH A123 was not counted in SOUTH (it is not on a Tag for the SOUTH count). |
An Inventory Transfer is created and posted to move A123 from SOUTH to NORTH.
Count SOUTH is adjusted. The Captured Quantity is reduced by 1, and A123 is removed from the Captured Serials list. |
| Count: NORTH
Item: 100XLG SN: A123 Tag records A123 in NORTH Bin: A Count: SOUTH Item: 100XLG SN: A123 captured in SOUTH Bin:G A123 was not counted in SOUTH (it is not on a Tag for the SOUTH count). |
An Inventory Transfer is created and posted to move A123 from SOUTH-G to NORTH-A.
Count SOUTH is adjusted. The Captured Quantity is reduced by 1, and A123 is removed from the Captured Serials list. |
| Count: NORTH
Item: 100XLG SN: A123 Tag records A123 in NORTH Bin: A The Count captured A123 in NORTH Bin: M |
An Inventory Transfer is created and posted to move A123 from Bin-M to Bin-A in NORTH. |
Serial Number Error Conditions
| Condition | Resolution |
| Count finds a new SN. It does not exist in the SN Master, but the SN is on an unposted transaction (such as a SOP Return, or a positive Inventory Adjustment). | You will need to either remove the SN from the Tag, or find the other transaction and remove the SN.
Report: Serials: New on Open Transactions It is not possible for CompleteCount to find which transaction is adding the SN because 3rd Party Products integrate into the GP routine which detects if unposted transactions are adding a SN, and that GP routine only returns yes/no. |
| Count finds a SN which was not captured on the Count because GP has it in a Site (Site-Bin) which was not on the Count.
The SN is allocated in the GP Site (Site-Bin). |
Find the allocating transaction and unallocated the inventory.
Report: Serials: Transfer Needed but Allocated |
| SN on another started Count, and is on a Tag. | One of the Counts will need to be manually fixed to resolve the problem. The SN cannot be on Tags for two different counts.
Report: Serials: Duplicated on Tags |
| SN occurs on two different Tags in the same Count. | The SN needs to be removed from one of the Tags.
Report: Serials: Duplicated on Tags |
For all Error Conditions, the Stock Tag Submission Wizard will identify the errors and an Error Report can be printed with the error information.
In the Resolution section above, the Report mentioned in each section can be run before using the Submission Wizard to identify problems.