| | | |
|---|
:01 | Housekeeping | Dung-Lan | Bindery support UAT will run starting August 7 (Wednesday) thru August 13 (Tuesday) - we appreciate your participation and any feedback you might have! Reminder - prioritizing acq-sig-topics voting (details here) Next meetinig - Tuesday, August 13th, at 1 pm Eastern
|
:05
| Duplicating Invoices
| Dennis Bridges | When duplicating an invoice, would also be duplicating the vendor invoice number In some cases when you clone/duplicate a record, FOLIO adds hyphen copy (-copy). Might not want that in this case? Might be best to actually clone the number? Duplicate would have exact same invoice number Won’t know what number you want it to have in the end If it is exactly the same will get duplicate invoice warning
Pamplin, Kimberly B 12:08 PM
Keeping it the same makes sense to me Scott Perry 12:08 PM
Keeping it the same. Okay - gave example of approved invoice with error - return to invoicing person to duplicate invoice to correct Duplicate message appears if vendor, invoice date and vendor invoice number are all exactly the same ~:11 Acquisition unit assignment - when you duplicate an order record, we currently will also duplicate the acq unit assignment. Assumption is that for invoices should have the same behavior. Trouble with this will be - if user does not have permission to create invoices, then will fail to duplicate the invoice. e.g.: “You don’t have permission to create invoices for that acq unit” Can you think of a use case where it might be important not to duplicate the acq unit assignment? If acq unit is duplicated from the original invoice can we change it if needed?
|
:15 | Receipt and Payment Status Not Required | Dennis Bridges | ~:15 - Going back to Poppy - If an order has one order line, and as you are creating the order line set receipt and payment status to not required. E.g. Gifts. Something you do not need to receive or pay for. In previous versions of FOLIO when you opened the order it would immediately be closed. In newer versions of FOLIO not automatically happening - has to be an update post-opening the order record. Are there any libraries relying on this status that could describe their use case in a bit more detail? ~:19 - Lisa - generally don’t create orders for gift records. Have done some ebook packages where input receipt not required and payment not required. Create separate order and order line? Separate so each title can be searched separately. Use link package to link all to original package POL If use package POL and add titles can’t search for that purchase order based on linked title Not putting in inventory, so want to have visible in orders. Would make it faster for them to close. Add note that they are paid on the package.
Could set up as ongoing order if you want it to stay open until closed May expect system to operate this way - system automatically opens and closes? ~ :27 - One of the cleanup things done at fiscal year end. Would be confusing if the order was still open.
|
:30 | Implementer’s Topic #125 | Dennis Bridges | Order something as a single unit for a single cost for the unit, may or may not know ahead of time that it will actually have multiple pieces/items. If you want to have everything linked back to POL have to do it via mechanism of receiving. Creating items via pieces. Workaround of not caring that they are not linked back to their order. Create items in inventory. E.g. Costs $200 – 5 items. Paid invoice for 1 unit at $200. On POL side can either divide the $200 by $5. $40 per unit – but that’s kind of fake. Change POL unit cost for $40. Add unexpected pieces to increase the unit quantity so that back on POL side have 5 instead of 1. $40 multiplied by 5 to end up with $200 again. ~:35 current example from Sara Read toast that it wouldn’t create extra piece. Had created an item. Cost on POL is completely wrong and cannot be edited anymore. If we don’t collect the data, don’t have the data to create reports and do analysis of holdings.
Lisa Smith, Mich State 12:45 PM
We would pull expenditures from the invoice app. Discussion on different approaches to solve the problem. Dennis: It would be reasonable to have a cost quantity and receive quantity separate from each other and still have a synchronized workflow. Increasing quantity is easier, decreasing is more problematic since the system wouldn’t know which one to remove. Dennis: There is enough here to create a feature, but will need to come back to discuss the approach. There are at least two ways that might be logical and need to refine the story and discuss the pros and cons.
|