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 |