In some instances, you may notice old manifests or packages listed under Accepted (Unassigned) in your Incoming Inventory. These may be packages that you accepted but later returned to the vendor, or transferred to another facility. Or, they may be packages that someone from your facility created directly in Metrc (instead of through a split or merge performed in Green Bits, for example).
- Why does this happen?
- What do to with these manifests
- How will this affect Metrc?
- What's happening in the background?
- Why can't I just delete these manifests?
- Can I just leave old manifests in Accepted (Unassigned)?
Why does this happen?
Any time a new package appears in Metrc – regardless of whether it was received from a vendor, or a package you created yourself – Green Bits will automatically import it and list it as a new manifest in your Accepted (Unassigned) view under Incoming Inventory. If you created the package(s) yourself, this manifest will list your retail license as the Vendor.
Once this manifest is imported by Green Bits, it will remain in Accepted (Unassigned) until you assign each and every package to a Product in Green Bits, even if a package has been transferred or otherwise updated in Metrc.
Put another way, manifests listed Accepted (Unassigned) are "hanging in limbo", and until you assign all packages to a Product in Green Bits they will neither disappear nor update, no matter what.
What to do with these manifests
- Assign each package to a Product in Green Bits, just as you would with actual incoming inventory. This can be any Product, though for this purpose you may want to create a "dummy" product named "Transferred out", "Returned", or anything else that helps you keep these packages separate from active inventory.
- If the package has been transferred out or finished, Green Bits will automatically update the package to reflect zero quantity, and tag it as "Transferred out". Note, however, that this may take up to 24 hours to be reflected in Green Bits.
- Because of this potential 24-hour lag time, set the product and/or package to Not For Sale or Archived status to prevent accidental sales in the meantime.
How will this affect Metrc?
Many users are understandably reluctant to "accept" inventory into Green Bits if they no longer have it in Metrc and it is no longer in their physical possession. Fortunately, the act of assigning a package to a Product in Green Bits does not affect or report to Metrc in any way. As long as Metrc correctly reflects which packages are/are not in your possession, there's no cause for concern from a compliance standpoint.
What's happening in the background?
This procedure may seem counter-intuitive to many users. To understand the method behind this madness, it may help to understand some of the background processes at play.
Each night, the Green Bits API automatically scans Metrc to identify any packages that have changed status during the past 24 hours, in order to validate that all active packages in Green Bits are also active in Metrc. This is how Green Bits automatically recognizes packages that you've transferred out or finished in Metrc.
However, Green Bits only validates package IDs that have been fully accepted and assigned to Products. Packages that are left in Accepted (Unassigned) are not included this nightly scan, and so Green Bits will not be able to recognize if these packages still exist in Metrc. This is why it's necessary to assign all packages to a Product in Green Bits first. Otherwise, Green Bits will not query Metrc about that package's current status.
Why can't I just delete these manifests?
As a general rule, Green Bits does not allow you to delete or remove historical inventory data that came from Metrc, for any reason. Even if a package was only in your store's possession for a brief period before it was returned or transferred and there were no sales or adjustments associated with it, Green Bits will keep a record of this package indefinitely.
Can I just leave old manifests in Accepted (Unassigned)?
Yes! If you prefer not to assign these packages to a Product, you are by no means required to do so. Assigning these packages to a Product is merely an optional suggestion to help keep your Incoming Inventory better organized and less cluttered.