Help

Re: Base design for group collaboration on manufactured parts

1076 0
cancel
Showing results for 
Search instead for 
Did you mean: 
Jed_Davidow
6 - Interface Innovator
6 - Interface Innovator

Hello all!

We are a small company setting up production. I don't need to use AT to track every single part, but we want to use it as an engineering tool to track prototype lots and parts pulled in for inspections, testing, experiments, etc.

I have used the API to automate the creation of parts and automated test logging, and have designed some forms for Real Live Humans to update and add comments, requests, etc.

The core of what I have built so far is a PARTS table, with one entry per individual part, and then an UPDATES table which has multiple entries for each part, referenced back to the key in the PARTS table.

So, for example, when part ABC is tested in the color testing machine, my API will first check for an existing entry in the parts table under it's SN (say, SN=101). If it doesn't exist it's created.

Then it will log the test by adding a record to the UPDATES table, with TYPE=TEST (selection) and DESC="COLOR" (text).

If we then move it on to the Stiffness test, it will add a record in UPDATES with TYPE=TEST, DESC="STIFFNESS".

At that point, a human could look at the info in those records and add an UPDATE, TYPE=COMMENT.

In this way ALL the updates are in one table, and I have been running roll ups on them for things like latest test result (Pass/Fail), glomming comments together, looking at a request field, last test date, etc.

the idea is that the humans can log in and view all the history, and then add comments and make requests, have discussions, upload files, etc. All attached to a part.

So what I am asking is...

1) Is this a reasonable method? I considered having separate tables for the different types of updates, but quickly realized this would require scripting or at least, some much deeper knowledge of AT ideas.

2) Are there any examples of this? I have seen a couple simple ones in the demos, but nothing with different types of commenting. I'd also like to make my interface seem more like JIRA's comments, if possible.

Any help is appreciated. What I have appears to be working with a couple hundred parts, not sure how well it will scale.

NOTE: I looked at using the built in comments, and these will work for some portions, but I need to attach comments to each of these individual updates too, plus the built-in comments aren't accessible through the formulas, only the API right now.

2 Replies 2
IliyanSlavov
5 - Automation Enthusiast
5 - Automation Enthusiast

Hi Jed! Regarding your first question, I don't think you need separate tables for the different types of updates, what if you just have a field in the table called Type and it's of type Single Select having the options TEST, COMMENT and etc?

IliyanSlavov
5 - Automation Enthusiast
5 - Automation Enthusiast

You can create a table that only contains Comments. That way, you could mimic the comments functionality more fully and in a more flexible format. I am not quite sure that I understood your requirements correctly. Let me know if this helps! If not I'll be happy to chat. 🙂

Cheers!