Hi everyone, First of all thank you for all your help!.
In this episode of me trying to learn appsheet,
I have a form that adds a new row to another table, for that, no problem.
The problem comes when I edit a row in the original table, I want that the information updates on the table where the row was added.
Trying with bots but no luck.
Suggestions?
thank you again!
Solved! Go to Solution.
I see thank you. In this case, to pass values between different actions you can use the INPUT() function.
Gracias por la explicaciรณn.
La app se vuelve complicada porque la estructura de datos no es la optima. Lo que veo es que tienes demasiadas tablas innecesariamente. Lo que yo harรญa serรก simplificar en primero la estructura de datos para que luego todo me saldrรญa mรกs fรกcil.
Por ejemplo: no necesitas tener una tabla para cada uno de los motivos de movimientos. En lugar de tener una tabla de Nacimiento, otra de Compras, otra de Muerte, otra de Venta, etc., lo que necesitarรกs รบnicamente es una tabla de Motivos, con dos columnas: ID Key, y nombreMotivo Label. Y en la tabla de Movimientos, tendrรกs una columna Ref apuntando a la tabla Motivos.
Veo que no estรกs identificado los animales de manera individual, si posible operacionalmente serรก mejor. Si no, continuamos con la organizaciรณn actual de tratar los animales en cantidades.
En la tabla de Rodeos, estรกs listando las categorรญas en columnas, lo que estรก desaconsejado en las bases de datos. Esta tabla debe tener solo tres columnas, Key, Label, y una columna de Total , pero nada mรกs. Tambiรฉn es el caso para la tabla Categorรญas.
Ahora, lo que vamos a hacer es reflejar el flujo natural del trabajo dentro de la app. Para eso, vamos a eliminar tambiรฉn las tablas: Cambio de Rodeo y Cambio de Categorรญa. El usuario va a empezar siempre en la tabla de Movimientos. Por lo tanto, adaptaremos un poquito esta tabla donde vamos a crear solo un registro por movimiento no dos.
Los motivos de un movimiento pueden ser:
Por lo tanto, la tabla Movimientos debe tener las columnas abajo. La columna Tipo no serรก necesario.
movID | Cantidad | Motivo | Fecha | De Rodeo | De Categorรญa | A Rodeo | A Categorรญa | ventaID | compraID |
Key | Number | Ref a Motivos | Date | Ref a Rodeos | Ref a Categorรญas | Ref a Rodeos | Ref a Categorรญas | Ref a Ventas | Ref a Compras |
Asรญ serรก el comportamiento del formulario Movimientos en cada caso:
Lo que falta ahora es actualizar el Total en las tablas Categorรญas y Rodeos. Eso se podrรญa hacer en diferentes maneras. La mรกs eficiente serรก:
Y por รบltimo, a partir de las tablas Movimientos y Motivos, puedes crear cualquier vista filtrada utilizando Slices o la funciรณn LINKTOFILTEREDVIEW().
One easy way to do it:
In this way, whenever a user saves a Source Table form, the "Refresh" column in the relevant row in the Target Table will be updated, causing all App Formulas in columns of the same row to be recalculated copying the updated values from the Source Table.
You can also use these actions in bots.
Hi Joseph, thank you for you answer
Already did that on other tables, however the target table takes info of several source tables, so no formula can be used in each column.
The app is for cattle stock, the target table registers INPUTS and OUTPUTS of cattle. An input could be for birth or buying (two tables), OUTPUTS could be for death, selling, or a change in the category of the animal. The target table has a bot that refreshes a summary tables with the stock
I see thank you. In this case, to pass values between different actions you can use the INPUT() function.
Great!, this was a solution!. However, now I am struggling whith edits and deletes of de source table on the target table!
Could you please explain this further? What exactly is giving you difficulties?
Thank you in advanced. Sorry if a wasn't clear enough.
I will try to explain in detail, very sorry for my english.
The structure of tables is the following
The movement table has the following structure
IdMovement, IdReferenced( here it goes the Id that generates this movement), date, Type (input/output), reason (Sell, Buy, etc), IdCategory, IdGroup, and quantity.
So whenever for example I change animals for one group to another two rows are generated in this table with two different IdMovements but the same info in the other columns except for Type and IdGroup, one row has de input for the group "A" and the other the output for the group "B". The edit of these is type of rows is where I have difficulties.
The only way I could use inputs is if I change de KeyColumn to the IdReferenced, but there I will hace repeted values.
Nothing to be sorry for my friend!
I believe your data structure can be simplified, so that things are made easier for you. Would you please post screen shots of your tables and column configurations? This will make it easier for me to correlate with your description.
Por cierto, Gonzalo, ยฟhablas espaรฑol? Si es el caso si quieres podemos continuar en espaรฑol mejor ๐ Gracias.
De haber sabido que hablabas espaรฑol! . Bueno ahรญ te hago un par de screenshots.
Ahora en espaรฑol,
Cada Tabla que genera una entrada y una salida se refleja en la tabla movimientos, para despuรฉs actualizar en las tablas de categorรญas los totales y la de rodeos el total por categorรญa.
Bรกsicamente, necesito una forma de seleccionar las filas que deben modificarse en la TABLA MOVIMIENTOS por su IDREFERENCIA (que puede estar repetido, en el caso de las tablas que generan una tabla por entrada y otra por salida) y no por su IDMOVIMIENTO.
El problema es que el IDREFERENCIA puede venir de un IDCOMPRA, un IDVENTA, un IDCAMBIOCATEGORIA, etc.
Gracias por la explicaciรณn.
La app se vuelve complicada porque la estructura de datos no es la optima. Lo que veo es que tienes demasiadas tablas innecesariamente. Lo que yo harรญa serรก simplificar en primero la estructura de datos para que luego todo me saldrรญa mรกs fรกcil.
Por ejemplo: no necesitas tener una tabla para cada uno de los motivos de movimientos. En lugar de tener una tabla de Nacimiento, otra de Compras, otra de Muerte, otra de Venta, etc., lo que necesitarรกs รบnicamente es una tabla de Motivos, con dos columnas: ID Key, y nombreMotivo Label. Y en la tabla de Movimientos, tendrรกs una columna Ref apuntando a la tabla Motivos.
Veo que no estรกs identificado los animales de manera individual, si posible operacionalmente serรก mejor. Si no, continuamos con la organizaciรณn actual de tratar los animales en cantidades.
En la tabla de Rodeos, estรกs listando las categorรญas en columnas, lo que estรก desaconsejado en las bases de datos. Esta tabla debe tener solo tres columnas, Key, Label, y una columna de Total , pero nada mรกs. Tambiรฉn es el caso para la tabla Categorรญas.
Ahora, lo que vamos a hacer es reflejar el flujo natural del trabajo dentro de la app. Para eso, vamos a eliminar tambiรฉn las tablas: Cambio de Rodeo y Cambio de Categorรญa. El usuario va a empezar siempre en la tabla de Movimientos. Por lo tanto, adaptaremos un poquito esta tabla donde vamos a crear solo un registro por movimiento no dos.
Los motivos de un movimiento pueden ser:
Por lo tanto, la tabla Movimientos debe tener las columnas abajo. La columna Tipo no serรก necesario.
movID | Cantidad | Motivo | Fecha | De Rodeo | De Categorรญa | A Rodeo | A Categorรญa | ventaID | compraID |
Key | Number | Ref a Motivos | Date | Ref a Rodeos | Ref a Categorรญas | Ref a Rodeos | Ref a Categorรญas | Ref a Ventas | Ref a Compras |
Asรญ serรก el comportamiento del formulario Movimientos en cada caso:
Lo que falta ahora es actualizar el Total en las tablas Categorรญas y Rodeos. Eso se podrรญa hacer en diferentes maneras. La mรกs eficiente serรก:
Y por รบltimo, a partir de las tablas Movimientos y Motivos, puedes crear cualquier vista filtrada utilizando Slices o la funciรณn LINKTOFILTEREDVIEW().
Tremenda explicaciรณn Joseph, te agradezco mucho. Voy a tener que mandarte un vino argentino! O invitarte con un asado si algรบn dรญa venรญs jaj!
Revisando un poco con detalle tu excelente explicaciรณn, encuentro algunos inconvenientes.
1-Por que me pides que tenga una columna IdVenta e IdCompra si has pedido que borre esas tablas.
2- En Motivo Cbo. Categorรญa y en Cbo. Rodeo, tengo el siguiente problema. Un Rodeo puede tener varias Categorรญas; y una Categorรญa puede estar en diferentes Rodeos. Por tanto, cuando yo hago un cambio de categorรญa, tengo que decir en que rodeo lo estoy haciendo.
DE NUEVO TE AGRADEZCO ENORMEMENTE TU AYUDA! HA SIDA MUCHรSIMA!
SALUDOS
Quรฉ chulo !! Ya tengo hambre ๐
Genial! Avancรฉ con tu propuesta y me di cuenta de esto รบltimo que me dices.
La identificaciรณn individual estรก, pero por ahora es un problema ya que hay errores de registros y pรฉrdidas del tag que las identifica. Serรก para otro paso.
Ha sido increรญble tu ayuda, nosรฉ como agradecerte!
Buenos dรญas Joseph, te hago un update de la situaciรณn
Seguรญ tus consejos y armรฉ las tablas como me dijiste.
Luego para los totales usรฉ en cada caso esta expression
SUM(SELECT(MOVIMIENTOS[Cantidad],[A Categorรญa]=[_THISROW].[IdCategorรญa]))-SUM(SELECT(MOVIMIENTOS[Cantidad],[de Categorรญa]=[_THISROW].[IdCategorรญa]))
y
SUM(SELECT(MOVIMIENTOS[Cantidad],[A Rodeo]=[_THISROW].[IdRodeo]))-SUM(SELECT(MOVIMIENTOS[Cantidad],[De Rodeo]=[_THISROW].[IdRodeo]))
Y una columna Refresh or Update que recalcula cada vez que el form de Movimientos se guarda. Algunos problemas que me encontrรฉ fue con los cambios de categorรญa y rodeo pero fueron solucionados.
Lo que no me ha quedado claro es como hacer para tener la informaciรณn de cuantos animales de cada categorรญa hay en un rodeo. Si tienes algรบn post que me pueda orientar un poco serรญa genial.
Has sido genial conmigo, y te agradezco mucho toda tu ayuda!
Saludos!!
Hola Gonzalo,
Eso dependerรญa de cรณmo quieres representar los datos en un view o en un template de informe. La relaciรณn existe, pero las expresiones a utilizar dependerรญa de la manera de representaciรณn.
User | Count |
---|---|
15 | |
14 | |
8 | |
7 | |
4 |