4 Replies Latest reply on Mar 28, 2017 8:54 PM by dale_allyn

    Check-in/Check-out, Acknowledge Receipt


      This is a bit longwinded, but I hope to provide enough info.


      (FM Server 15 and all users will have FMP 15)


      I’m seeking input on a check-in/check-out process that provides for transferring items from one technician to another, without passing through a central “librarian” or repository.


      I’ve built a solution element based on the Assets starter solution method. I used some of the methods and scripts to save time, but it’s integrated into my solution, not implemented as a minor tweak or a stand-alone.


      For checking in and out it works great; indicates location and history, timestamps, etc., and I include a “Move” option (similar to the Assets starter) where one can assign it to a new location or person without checking it out or first returning it to the central repository. Once testing and report are complete, record is locked and indicated as such.


      This is a laboratory setting; specimens are taken in by customer service window/counter and passed to the lab repository (and “librarian”). Each specimen is checked-out to be processed by various test methods, e.g. weights and measures, FTIR, UV-VIS, Ramen Spec, etc. Sometimes they will be checked-in again (especially end of day), sometimes they’ll be moved from tech to tech.


      I need to provide for a specimen to be moved from Ted, in Weights and Measures, to Alice, in Ramen Spec, without Ted having to check the specimen back in first (not return it to central repository).


      Problem: I need to design an elegant way to allow a recipient to acknowledge receipt of a specimen once someone “Moves” (assigns) it to someone else.


      So… Ted finishes his work and wants to pass the item to Alice. He clicks “Move” and assigns it to Alice and it (currently) shows as “Assigned To: Alice”. I will change this to indicate “Assigned To: Alice [Pending]” until Alice acknowledges receipt (and responsibility).


      An ItemLocationHistory table tracks all movements, with the exception of a "received" acknowledgement. I’m thinking of adding a receiptStatus field and a button that the recipient clicks to acknowledge receipt. (Stack this button on top of the Check-in/Check-out buttons and "hide when..." as the others are.) The associated script would compare the current user to the assignee and once clicked, the “Alice [Pending]” would be replaced with just “Alice”. I’ll also add an icon to indicate status is pending until she accepts as a visual helper.


      There will be times when several specimens are moved from Ted to Alice at a time. A barcode is scanned for each item and the user is taken to the appropriate record for transfer (Move or Accept, i.e. outbound or inbound).


      Can the community provide input or suggestions on other/better/cleaner methods for this?

        • 1. Re: Check-in/Check-out, Acknowledge Receipt

          I have a system in place where one group of users send an "inquiry" to users in another department. It looks and works like email, but is all in FileMaker and they get buttons to click that track inquiry status and that pop up data relevant to the specific inquiry.


          Most of this process is what you already have in place--creating a record in a table with data that "assigns" it to another user (or department) in your system. The added piece of the puzzle is that you need some system that checks for the appearance of new records (that need attention on the part of the recipient). There are several approaches that can be used. In the above case, an "OnFirstWindowOpen" script does a find for records and pops up a message notifying the recipient that they have new messages if any are found. Another button lets them check for messages at any time.


          In another system, I set up a looping script with a pause that displays a list of such records in a list view in a window where the users can click to select one. With today's version, I'd use a window set up with Install OnTimerScript to make such periodic checks. This can be done in a window hidden off the monitor edge that only pops the window into view when a new record is routed to the recipient or the recipient's department.

          1 of 1 people found this helpful
          • 2. Re: Check-in/Check-out, Acknowledge Receipt

            Hi, Phil, Thank you for your reply. (Sorry for the slow response. I'm 14 times zones away at present [Thailand]). Your systems sound interesting.


            Your mention of the notification method for records which need attention is helpful. I had been thinking about that and not fully resolved the best UX for it in this case. Most of the time Ted literally hands Alice a specimen package with a barcode label, or tray of such packages. That Alice physically accepts the items suggests that she's prepared to scan them in right then and there. Otherwise, Ted wouldn't be bothering her. Still, I'll provide for it in case Alice goes to lunch and wants to accept when she returns, or needs to finish some current tests before changing work mode.


            In most cases, the onFirstWindowOpen won't work because the window will be opened once and left open for hours and these transfers occur randomly throughout the day. I'm thinking I'll add a header element that shows when items are pending; click that element (button) and be shown a list of records which need to be accepted. This would be needed only if Alice can't or won't scan the item immediately as it's handed to her (or very soon). And this will catch any that she may have missed (scanned three of four, thinking she got them all). Some of this must be controlled by lab business rules.


            In a straight-up web app (LAMP stack, etc.) we can run a script periodically (or on some other event) that is very low overhead and scans for any items needing acceptance; then throw an alert, send an SMS, turn on a siren , or highlight a header element, etc. This is similar to your looping script suggestion.


            This is all very helpful. And it brings up something else that I've not yet addressed. The check-out/check-in process works technically, but in practice it may get less use than the "librarian" moving a requested specimen to Ted who then must accept it. Rather than Ted walking up and checking it out himself, then later checking it back. However, this latter scenario is more likely with the research department of the lab where there is more freedom to interact with specimens as research is done for various studies.

            • 3. Re: Check-in/Check-out, Acknowledge Receipt

              "In a straight-up web app (LAMP stack, etc.) we can run a script periodically (or on some other event) that is very low overhead and scans for any items needing acceptance; then throw an alert,"


              This is what Install OnTimer Script can do.


              You might research barcode scanning scripts re in this forum. There are ways to do this where simply scanning the barcode triggers a script that puts the scanned data into a field and processes it. Finding and updating records in a table to show that the item has changed hands.

              • 4. Re: Check-in/Check-out, Acknowledge Receipt

                I've used the Install OnTimer Script step occasionally, but wasn't sure if it was efficient vis-a-vis performance (just my ignorance). I'll consider its use as I refine the UX.


                I believe I've read every modern (and some not-so-modern) posts on barcode scanning in the forum. This project relies a lot on 1D and 2D codes and I've been boning up a bit to find the best paths (hopefully).


                Turning some of my focus back to this element (check-out/check-in) has reminded me that I've not provided an "authorization to move" layer yet. I.e. Alice has possession of an item, therefore only Alice (or appropriate management) should be able to check it in to the repository or move it back to Ted.


                The Location History is abundantly clear and easy to see in a  portal, so any movements would be shown as by whom and when, etc. But I think it makes sense to limit movements to the one responsible and any appropriate supervisor. This is more of a business rule, but it also protects application integrity a bit.


                Thanks for sharing your ideas and experience, Phil.