One-Time Orders of Multi-Volume Sets are problematic in FOLIO currently [Orchid]. Multi-Vol sets come in various flavors and with different scenarios:
(1) It is known at the outset that it is a multi-volume set. There is a single price, but 2+ items that are sold as a single (1) unit. In this case one can choose to either (a) use the Receiving Workflow option of Independent Order and Receipt Quantity and keep the Cost Quantity physical & Location Quantity physical as 1, OR, (b) divide the vendor's unit price by the number of expected items and enter it as the Physical Unit Price and set the Cost Quantity physical & Location Quantity physical to the expected items number so that the total for the Estimated price = the vendor's unit price. And then Open the Order. If one goes with option (a) then after receiving all pieces, one has to remember to return to the POL and change the Receipt Status to Fully Received otherwise the Order will not Close after also being Paid. In the case of option (b), the Order will Close automatically on its own after the last piece is received and the invoice paid, and all the items are created at the time of opening the order [so if needed one can place holds on all of them at that time] BUT the single unit cost is divided across them.
(2) It is NOT known at the outset that it is a multi-volume set, there is a single price, the vendor indicates a single unit for sale, but in fact there are 2+ items. Assuming it is undesirable to UNopen the Order again--otherwise one could could open it again & handle like described in (1)--but if unopening again is not desirable then one can either (a) use the Receiving App to receive one of the volumes so that it is linked up with the POL and Inventory–adding info in the Piece Comment field to show on the Holdings record and Notes variously–besides then in Inventory creating the additional Items directly, on the same Holdings record with the Comment, and adding Notes to the Item etc. ... OR (b) edit the POLs Physical Unit Price to X# so that when one then creates additional Expected Pieces in the Receiving App on the Receiving record, which then triggers the Cost Quantity physical & Location Quantity physical to increase one ends up with the orginal Estimated price = the vendor's unit price again. Basically implementing (1b) above after opening with the same +/- (- = the single unit cost is divided across the items). As to (2a) the issues are: additional Items are not linked to the POL via Receiving App Pieces and do not show in the Receiving Record, etc. & the Receiving Note may be missed, which may indicate that the Items are Requested, so that only the one initial Item has a hold and not the whole set.
(3) It is NOT known at the outset that it is a multi-volume set (there is a single price, the vendor indicates a single unit for sale, but in fact there are 2+ items) AND the POL has already been Fully Paid (as a single unit re: cost & quantity). At this point--as far as I can tell--while one is still able to edit the POLs Physical Unit Price, one is NO longer able to create additional Expected Pieces in the Receiving App on the Receiving record. So at this point then the options become (a) to handle like (2a), OR, (b) to Cancel the Invoice, then proceed according to (2b), and then re-entering etc the Invoice. Now however is not only the single unit cost divided across the items, but also (a) one has to tweak the invoice number to make it unique from its first-now cancelled version AND the manual entry of the invoice pulls in the now Cost Quantity physical which is greater than 1 [this may also happen for (1) and (2) depending on when the invoice is entered or EDIed into FOLIO and linked up to the POL].
What would be great [and I think take care of all of the above outlined scenarios] is re: One-Time Orders set to Receiving Workflow: Synchronized Order and Receipt Quantity [and actually generally too] if (a) the Cost Quantity physical and Location Quantity physical were not tied to each other. That is, that they did not have to match. And (b) for the Receiving Expected Piece quantity not to be tied back to the Cost Quantity physical but only tied to the Location Quantity physical. And (c) for POL Receiving Workflow: Synchronized Order and Receipt Quantity, it NOT be the creation/adding of Expected Pieces in Receiving that changes the quantity of the POL Location Quantity physical, but rather the other way around. That is, one would have to be able to edit the number of the POL Location Quantity physical and that then would change/add how many Expected Pieces there would be in Receiving. & The POL Receipt Status would have to be tied to the Location Quantity physical and not to the Cost Quantity physical.