Hello, I am have been doing some research and I am not finding anything on the following topic.
I have a form that our shop can request rework to our nesting department. We have a simple form that collects information such as date, name, department, job number and the parts that need to be nested again and the quantity of the part needed. We are wondering if there is a way to add a plus sign button to add multiple part entries to the form as each job could need multiple different parts. Please see the attached image under the parts number section, we would like to be able to click the plus sign, and be able to enter in a different part number and the quantity for that part.
IMHO, the problem you are encountering is a result of the structure of your app. In database first principles, what you are describing is a classical Many-to-Many relationship. In your case, Orders and Parts. In other words one order can have many parts and one part can have many orders. The proper construction of the database should include two separate tables (Orders and Parts) connected by a junction table. Unless your app is constructed properly, you will have problems developing it further. Please review @Meneghino 's blog post at https://baizini-it.com/blog/index.php/2017/10/10/powerapps-101-many-to-many-relationships-between-ta... Hopefully, this will give you a start on how to structure your app. Once the underlying structure is correct, the forms needed to obtain the data will be much easier to create.
I figured that I would need to restructure the backend, a SP List for Jobs, and a SP List for Parts. The parts would be linked to the job based off a unique id. I guess I was looking more for how to add or decrement the text inputs for part number and quantity when the + or - sign was pressed. I would also assume that i'd have to collect each part that was entered in to a collection, which would contain the Job number, the part number and the quantity. Foreach item in the collection, i would have to patch each line to the Parts SP list and then the remaining data (user, job number, urgency, department, notes, etc) would be patched to the Jobs SP List. Am I in the ball park?
What I am saying is that before you design your app, step back and consider the relationships between the entites in your business from this standpoint: One-to-one, One-to-many or Many-to-many. Your app is a database and a databases have tables, (in sharepoint they are called lists), that are related to each other and are defined by their uniqueness and should have a unique ID or Primary key. Sharepoint automatically assigns one when you create a list. From your description, The entities appear to be as follows: Users, Jobs, Departments and Parts, possibly Customers as well. If I were designing your database, I would have a separate table (list) for each of these. The columns in each list would be attributes of the entity. For example, Users would have a name, email address, possibly a company ID number. Parts would have a unique part number, description and possibly category. Customers would have a name, address, phone number, etc. Jobs would have a job number, Urgency, deadline date, description, etc. In a theoretical database you would have the following relationships between your lists.
One customer could have many jobs
One User could have many jobs
One Department could have many Users (employees?)
One job could have many Parts
One part could be used in many jobs.
If the database were designed in this fashion, it would be easy to create a gallery and edit form for each list so that you could add or modify the items in it should there be changes. For the connecting fields you would use dropdown or combobox controls in the Edit form for the lists.