Addressing Over-Allocations
Overallocation 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, because 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.
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 overallocations. 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 overallocation could mean that a Ship Date given to a customer on a Sales Order is inaccurate because there is not any inventory to fulfill the order. Perhaps a Backorder should have been created rather than an Invoice. The Stock Count also cannot automatically figure out how to handle these items.
CompleteCount 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 overallocations.
The transactions allocating the inventory must be unallocated and a decision made about how to handle the shortage for that document. Altering the count to “leave enough” inventory for the allocation is incorrect as is overriding the allocation of driving Available Inventory even more negative.
There are a couple of options for addressing overallocations:
- Find the transactions allocating inventory (i.e. Sales Transactions or Manufacturing Picklists), and unallocate enough inventory to allow the count to post.
- Find the items in the Build Stock Count window or Post Stock Count window and remove them from the Stock Count. Deleting items from either window will remove them from the Count and VOID any Tags containing the Item-Site/Bin combination.
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 added 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.