I’m curious if anyone has some advice on this. I have some users that have a need to record data about a number of machines for every shift, every day. I had already created them an entry program (storing the data in UD10) but the idea of having to select the machine from a dropdown, enter data, and update each individual machine was evidently too slow for them.What they are used to is something along these lines:
Ideally when this grid loaded it would already have the Machines and Date populated and allow the user to fill in the rest of the grid and save it. I will also need to do some coding to automate some data like part from job and other calculations but that’s later. This is what I’d like to accomplish if possible to keep them in the system instead of in separate spreadsheets.
Now, if this is not possible I can create a Service Connect workflow that will allow them to use the same spreadsheet they use now but, as I said, I’d really like to get them away from that and into the actual system.
This looks like an obvious use-case for an updateable dashboard.
You’d probably still get complaints that it wasn’t what they’re used to, but the actual process would be barely any different to a spreadsheet in reality, and you can keep your UD10 workings.
Thanks for the reply. A UBAQ was my initial thought though I’m having some trouble wrapping my head around how to populate the machine column based on the equipment in the system. I thought about manually entering the first record for each machine (Key1), date (Key2), and shift (Key3) but that means that if any machines were added or removed I would have to manually edit the table instead of it pulling from Equipment. Any thoughts?
The keys for UD tables can be what you like, so it only matters where the data that goes into them comes from.
Our usual approach is to make the column entry a combo control from the source data - so for your machines that would be Equipment, and you might want to list your shifts in UserCodes so they’re a drop-down as well. If you were thinking of pre-populating the table then it would be a good idea not to get too far ahead because you can’t change the key fields of existing rows, but otherwise I don’t see why it wouldn’t work.
