Once you receive an incoming transfer in METRC first, you will have the ability to generate a Purchase Order from it. Also any, incoming licensed transfers that were made before a certain time may not show up in the notifications feed. If this is the case, please contact us so that we can manually correct this for you.
To import an incoming transfer:
Click on the METRC notifications badge on the top right in Distru (or select an incoming transfer from the section in your dashboard if you have that setup)
You should see that you have Transfer(s) that you need to import.
Click on that and then Select Facility, Select Transfer, and then Import as a Purchase Order (as the image shows above)
Select a Supplier (make sure its the supplier and that they are marked as the 'vendor' of the product for which you are importing these packages)
The order line items you will see will have the METRC item in it; all you will have to do is select the Distru Product that that METRC item is connected to (as the image below shows)
If you do not see the product to match but you know you've created it, it could be because those products belong to a different vendor than the one you've selected. Please double check and fix the vendor on the products prior to doing this instead of creating a new product for the wrong vendor.
IF during this process your METRC transfer gets accepted (or something changes) then it may give you an error so you will have to re-create the order.
To match an existing PO, goto the purchase section and then click the 3 dots to match a PO to a transfer as the image shows below:
At some point you may find yourself with a long list un-imported packages. Learn how do deal with them in our knowledge base article: Skipping Metrc Package Imports
Since this release we've added some new functionality to Purchase Orders! Dive deeper in our next article.
Broken Incoming Transfers
What is a ‘broken’ incoming transfer?
When we fetch an incoming transfer from the Metrc API for a particular license, we don’t get any information about the quantity of the packages on that transfer. In order to know these details, we need access to the sender’s license. In this case, since we only have access to the recipient’s license, we are unable to determine the quantity of the packages. This kind of transfer is something we internally call a 'broken incoming transfer.'
The only time we reliably get quantity information (and thus the transfer is not broken) is when the package was sent by your own ‘other’ license (for example you have a Distribution & Manufacturing license which are both connected to Distru). This way, we have access to the sender license and are able to get this information from the Metrc API.
What are we doing about this?
We have to make an ‘educated guess’ and infer this information.
We pull data from Metrc every 2-3 minutes and store all Metrc related information we receive (transfers, manifests, packages, etc.) in our cache
Using the manifest number of the transfer, we are able to track down the quantity of the package in our cache at the time of import and use that value
Where this fails
The problem is that this is not a bulletproof strategy. There are many cases where this doesn’t work. For example:
Say that you have an incoming transfer that you received months ago which had 1 package in it
You accept the package, and the next day transfer it out
2 weeks later, you sign up with Distru
We pull all your historical data from Metrc so that you can import all of those old transfers
We will not be able to tell (via the Metrc API) what the quantity of the package on the incoming transfer was because:There is no quantity information available from the incoming transfer itselfThe package has been transferred out so is no longer available for us to readThere is no Metrc cache record of that package being received since the user was not a Distru customer back then
What we’re doing about it
We have implemented an enhancement to the way we infer the package’s quantity to make it smarter.
For every broken incoming transfer, we have a timestamp of when the customer accepted the packages in Metrc.
For every package we pull from Metrc into our cache, we have a timestamp called Last Modified.
If there is too big of a gap between those two timestamps, we will assume that we cannot infer the quantity and the user will be asked to manually enter the quantity.
If the timestamps are almost equal (just a few seconds apart), then we can assume that this was the quantity you received.
Conclusion
While this is not perfect due to the limitation we face with the Metrc API, it hopefully is a good enough workaround where we can unblock customers and give them enough options to manually correct the record.
Please reach out to us with any questions :)