1 Reply Latest reply on Apr 7, 2014 8:53 AM by philmodjunk

    Suggestions for FMP13 solution



      Suggestions for FMP13 solution


           Hello.  I've been tasked with getting FMP13 and FMS13 up and running for one of our departments.  They will be using the Filemaker Go app with iPads as well.  Since I'm relatively new to Filemaker, I decided to get myself more familiarized with the products.  The server product was relatively easy to get up and running.  I then downloaded the app to my iPhone and iPad and found it easy to connect to the server and view remote databases.  Now comes the hard part, trying to build a proof of concept database.  I thought it would be an interesting project to build a database that tracked equipment that is assigned to our employees and make it a paperless workflow by deploying the application via FM Go, including signature capture for both the employee and their direct supervisor acknowledging receipt of the items.  The completed form would then be emailed in PDF format to the employee, supervisor and HR department to be placed in their employee file.  Here are the tables I envision:





           Where I get a little lost is this: how do I go about handling details about the items being issued when they have different metadata sets?  For instance, for a laptop I would want to track make, model, and serial number.  These same attributes would apply to most other electronics.  However, if we are issuing safety equipment or uniforms, I might not be tracking those same attributes.  Does that make sense?  Can anyone point me in the right direction?

           Much appreciated!

        • 1. Re: Suggestions for FMP13 solution

               There is an Assets Starter solution that comes with FileMaker 13. Even if this solution does not meed the precise needs you have for a database, you may find that there are methods and ideas used in it that you can adapt to your own solution.

               There is a free tutorial on FileMaker 13 produced by FileMaker Inc.: https://itunes.apple.com/us/book/filemaker-training-series/id787527886?mt=11

               When it comes to tracking very dissimilar items there are two parts to the process:

               First, sit down with a piece of paper and list every type of item you might possibly need to track at this time. Don't stress out too much about forgetting an item or two or the fact that the items you need to track will change as your business changes, this is just to get a starting point and you can add in more details at a later date--even after you have your database up and working.

               Then, for each item that you listed, list every detail about that item that you might want/need to record in your database.

               Then compare the lists of details--which will become fields in your database tables and organize them into two groups: One group is all the details that are common to all items that you will track. That might not be more than an ID number of some sort and a text description or there may be additional details common to all. The second group will consist of all the other details that are not common to all assets such as your electronic equipment details that won't apply to uniforms or safety equipment.

               Then you come to step 2. There are two basic design approaches you can take for how you handle these two groups of asset details.

               Option 1 is to set up a single table with a field for every possible detail--whether that be a detail from group 1 or group 2. If you have a record for a uniform in this table, the fields specific to electronics would be left empty and vice versa.

               Option 2 is to set up a table with only the fields common to all types of assets. You then set up a series of related tables for groups of the asset specific details. You might have a Uniforms table with fields for size and type of uniform and an electronics table with fields specific to electronic equipment. A record for a uniform would have a matching record in the uniforms table, but no related record in the electronics table.

               With either approach, you have a single table where you have one record for each asset. Make sure that you define an auto-entered serial number or text field with Get (UUID) to uniquely identify each record and to link it to any other related records in your system. Don't use a serial number copied from the physical item in place of this field as this set's up issues such as incorrectly entering the value and later having to correct it that can really complicate your life if you used that field in place of the auto-entered identifier as your primary key.

               With either approach, you can set up different layouts for different types of assets customized to the needs of that type of asset (or group of similar assets) And with either approach a related table can track the person to whom the asset is currently issued and another table might track the physical location of assets that have a specific location that can be specified.

               The main difference between the two methods is that using multiple tables for the details is more complex to set up in Manage | Database | relationships, but breaks up what could be a very large list of fields into smaller, more easily managed groups of fields. It can also produce a smaller database file, but given the massive capacity of modern hard drives, that difference in file size may not be significant when it comes to actually using the database.