Active Business & Technology

UPGRADES DATOS A BC19

ÍNDICE
1. Preparación versión BC14
2. Creación EmptyApps (Task 4)
3. Creación Extension AllTables (Task 5)
4. Creación Master Data (Task 3)
5. Preparación BBDD (Task 6)
6. Conversión a BC19 (Task 7)
7. Configuración BC19 (Task 8 – Task 9)
8. Publicar App Migración(Task 10)
9. Sincroniza App Migración (Task 11)
10. Upgrade aplicación e Instalación (Task 12)
11. Publicar extensiones finales (Task 13)
12. Sincronizar extensiones finales (Task 14a)
13. Sincronizar extensión migración (Task 14b)
14. Proceso migración versión 2 (Task 15)
15. Limpiar app migración (Task 16)
16. Instalar o migrar la app finales (Task 17)
17. Finalizar upgrade
1. Preparación versión BC14
ASPECTOS IMPORTANTES:

- Este paso es el más IMPORTANTE del proceso de upgrade de datos.

- El objetivo principal es tener la estructura espejo al destino que tendremos en BC19.

- Si se consigue la estructura adecuada el proceso de upgrade se minimiza el riesgo de errores y

tener que repetir dichos procesos.

- Se tiene que saber los productos que se tendrán que tener instalados en BC19.

- Tenemos que tener claro el origen si es una BC14, o la BC14 es resultado de alguna o varias
upgrades anteriores.

- Se recomienda dejar la empresa más pequeña para realizar todo el procesos de forma inicial
para poder ver de una forma más ágil los problemas de estructura. Luego se deberá ejecutar
con la base de datos completa por si existe algún problema de datos.
1. Preparación versión BC14
COMPROBACIONES SOBRE CAMBIOS EN TABLAS ESTANDAR:

- Si venimos de una versión BC14:

- Comprobar si ha habido cambios en los tamaños de los campos estándar respecto a la
versión BC19.
- Comprobar si ha habido cambios en la propiedad de DataPerCompany respecto a la
versión BC19.
- Comprobar si existen campos que se llaman igual entre BC19 y una personalización del
cliente BC14.

- Si venimos de una versión anterior a BC14:

- Comprobar si ha habido cambios en los tamaños de los campos estándar respecto a la
versión BC19.
- Comprobar si ha habido cambios en la propiedad de DataPerCompany respecto a la
versión BC19.
- Comprobar si existen campos que han desaparecido en la versión BC19.
- Comprobar si existen tablas que han desaparecido en la versión BC19.
- Comprobar si existen campos que se llaman igual entre BC19 y una personalización del
cliente BC14.
1. Preparación versión BC14
SOLUCIÓN SOBRE CAMBIOS EN TABLAS ESTANDAR:

- Cambios en tamaños de campos:

- Si se ha ampliado el campo en BC14 y es mayor a lo que hay en BC19 se deber revisar los datos, guardar la
información en otro campo personalizado (si hay datos más grande que el tamaño de BC19) y reducir el campo
estándar al mismo tamaño de BC19. Si no hay datos más grandes se puede reducir directamente la BC14.
- Si el campo en BC19 es mayor al actual en BC14 se debe ampliar el campo en BC14.

- Cambios en propiedad DataPerCompany:

- Se debe dejar como esté en BC19, lo más frecuente es encontrarnos el DataPerCompany a SI en BC19 y a NO BC14,
en estos casos se deber hacer el cambio en BC14, comprobar que la información este en todas la empresas y avisar al
analista del proyecto para ver que solución se le da a nivel de sincronización entre empresas esto no forma parte del
proceso de upgrade de datos.
1. Preparación versión BC14
SOLUCIÓN SOBRE CAMBIOS EN TABLAS ESTANDAR:

- Campos con mismo nombre:

- Primero comprobar que son exactamente iguales en nombre (mayúsculas y minúsculas), y tipo.
- Si hay algún cambio en el nombre dejarlo en BC14 tal y como este en BC19.
- Avisar al analista del proyecto para que lo tenga en cuenta cuando se traspase la funcionalidad.
- Si hay cambio de tipo hay que cambiar el nombre en BC14 y luego tenerlo en cuenta en la Master Data (como
cualquier campo personalizado)

- Campos desaparecidos en BC19:

- Si no tienen información eliminar en BC14
- Si tiene información crear TableExtension en una extensión old* para poder guardar la información que tienen.

- Tablas desaparecidas en BC19:

- Si no tienen información eliminar en BC14.
- Si tiene información crear una extensión old para poder guardar la información que tienen.

*Con extensión OLD nos referimos a una extensión específica donde estén localizados
los campos que ya no existen para poder decidir si son necesarios o no para luego poder quitarlos.
1. Preparación versión BC14
COMPROBACIONES SOBRE CAMBIOS EN TABLAS PRODUCTOS PROPIOS:

- Comprobar si ha habido cambios en los tamaños de los campos de producto en BC14

respecto a la versión del producto BC19.
- Comprobar si ha habido cambios en la tablas de producto en BC14 en la propiedad de
DataPerCompany respecto a la versión del producto BC19.
- Comprobar si se ha cambiado la clave principal de alguna tabla en BC19.
- Comprobar si existen campos que se llaman igual entre BC19 y una personalización del
cliente BC14.
- Comprobar si existen campos con el mismo número pero con nombre diferente.
- Comprobar si existen campos que han desaparecido en la versión BC19.
- Comprobar si existen tablas que han desaparecido en la versión BC19.
- Comprobar si existen campos que han se han creado en la versión BC19 en tablas que no
existían en BC14 (ya sean estándar Microsoft o del producto). P.ej. en la BC19 de Abaco
Base se han creado dos campos:
- Tabla 841 "Cash Flow Account“ campo "Bank Account filter“
- Tabla "Posted Cartera Doc.“ campo "Transfer Type“
1. Preparación versión BC14
SOLUCIÓN SOBRE CAMBIOS EN PRODUCTOS PROPIOS:

- Cambios en tamaños de campos:

- Si se ha ampliado el campo en BC14 y es mayor a lo que hay en BC19 se deber revisar los datos, guardar la
información en otro campo personalizado (si hay datos más grande que el tamaño de BC19) y reducir el campo
estándar al mismo tamaño de BC19. Si no hay datos más grandes se puede reducir directamente la BC14.
- Si el campo en BC19 es mayor al actual en BC14 se debe ampliar el campo en BC14.

- Cambios en propiedad DataPerCompany:

- Se debe dejar como esté en BC19, lo más frecuente es encontrarnos el DataPerCompany a SI en BC19 y a NO BC14,
en estos casos se deber hacer el cambio en BC14, comprobar que la información este en todas la empresas y avisar al
analista del proyecto para ver que solución se le da a nivel de sincronización entre empresas esto no forma parte del
proceso de upgrade de datos.

- Cambios en la clave principal:

- Se debe dejar como esté en BC19, para ello se debe comprobar que los datos permiten este cambio.
1. Preparación versión BC14
SOLUCIÓN SOBRE CAMBIOS EN PRODUCTOS PROPIOS:

- Campos con mismo nombre:

- Primero comprobar que son exactamente iguales en nombre (mayúsculas y minúsculas), y tipo.
- Si hay algún cambio en el nombre dejarlo en BC19 tal y como este en BC14.
- Avisar al analista del proyecto para que lo tenga en cuenta cuando se traspase la funcionalidad.
- Si hay cambio de tipo hay que cambiar el nombre en BC14 y luego tenerlo en cuenta en la Master Data (como
cualquier campo personalizado)
- Si el campo que cambia el tipo es del producto propio, se debe renombrar y renumerar el campo actual en BC14 a
uno personalizado en una numeración no ocupada en cualquier producto o estándar. Y crear el campo con el
nombre, tipo y número definitivo del producto propio. Si hiciese falta se debería pasar un proceso (nos lo deberá dar
el responsable del producto) para hacer esta conversión de datos en BC14.

- Campos con mismo número:

- Este caso no debería darse ya que deberíamos tener todos los campos de productos propios en numeraciones propias
del producto.
- Si sucede cambiar número en BC14 a una numeración no ocupada en cualquier producto o estándar.
1. Preparación versión BC14
SOLUCIÓN SOBRE CAMBIOS EN PRODUCTOS PROPIOS:

- Campos desaparecidos en BC19:

- Si no tienen información eliminar en BC14
- Si tiene información crear TableExtension en una extensión old para poder guardar la información que tienen.

- Tablas desaparecidas en BC19:

- Si no tienen información eliminar en BC14.
- Si tiene información crear una extensión old para poder guardar la información que tienen.

- Campos nuevos en B19:

- Se han de crear en BC14 para que los SQL que realiza la sincronización de los datos no falle.
- Si se ha creado una tabla nueva en BC19 no es necesario crearla en BC14.
Cuando se realiza la sincronización de la app de migración versión 2, realiza la siguiente consulta para mover los datos sino se crea el campo no localiza el campo en la estructura actual y da error:
INSERT INTO "dbo"."CRONUS España S_A_$Posted Cartera Doc_$c0a8bc6a-acb8-465c-a3c1-d11cc33f4486" ("Type","Entry No_","Transfer Type")
SELECT "Type","Entry No_",0 FROM "dbo"."TEMP$CRONUS España S_A_$Posted Cartera Doc_$2451e58e-0fb0-4de1-981a-d860a3d46aed
2. Creación EmptyApps (Task 4)
ASPECTOS IMPORTANTES:

- Estás extensiones vacías son necesarias para pode ejecutar los procesos de upgrade propios de
cada una de las extensiones definitivas.

- Si alguna de las extensiones definitivas no llevan procesos propios de upgrade no es necesario

crear las extensiones vacías para ellas.

- Sino se crean las vacías en las tareas donde existe algún cambio en lo que se ha de ejecutar se
indicará en esta presentación.

- Las que son 100% necesarias son las "System Application“ y "Base Application"

Microsoft_System Application_14.0.0.0.app Microsoft_Base Application_14.0.0.0.app

3. Creación Extension AllTables (Task 5)
All Table Versión 1:

- El objetivo de este paso es tener una extensión con toda la estructura de tablas que tenemos en
la BC14 una vez revisados los puntos anteriormente comentados.

- Dentro de lo que indica los pasos de Microsoft tenemos que ser muy escrupulosos en dos
puntos:
- Ejecutar el Dynamics NAV Development Shell de BC14 en modo administrador para evitar
problemas.
- En el Txt2Al sobre todo NUNCA olvidar el parámetro --tableDataOnly.

All Table Versión 2:

- El objetivo de este paso es tener una extensión con el mapa de extensiones (migration.json)
definitivas al cual se tiene que llevar los datos al sincronizarlos.
- Tiene que tener siempre las aplicaciones "System Application“, "Base Application“, “Master Data”
- Opcionalmente podemos tener: Extensión Old y Productos propios.
- Los productos que actualmente no tienen campos en BC14 pero se deben instalar en BC19 no
deben estar en migration.json.
4. Creación Master Data (Task 3)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es tener la estructura de datos que luego se utilizará para poder realizar
el upgrade de funcionalidad sin necesidad de modificar la estructura de la BBDD.

- Sería una buena practica aprovechar la extensión de todas las tablas (AllTables – Task 5).

- Debe tener TOD@S las tablas y campos existentes en la BC14 que no estén en productos
propios o en la extensión old.

- Los nombre de tablas y los campos deben ser IGUALES, incluso mayúsculas y minúsculas. 

- Las propiedades de las tablas deben ser IGUALES (DataPerCompany, Claves, etc.).

- Si se han de crear campos nuevo en el Master Data, se deberían tener dos versiones de la
Master Data la primera con los campos de la BC14 y la segunda (definitiva) para instalar una vez
acabada la upgrade de datos.
5. Preparación BBDD (Task 6)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es dejar limpia de extensiones la bbdd actual en BC14.

- Si la BBDD origen es de una versión previa a BC14 este paso no es necesario.

- Si la BBDD origen es BC14 es NECESARIO, y hay que ser muy cuidadoso con:
- Ejecutar el Business Central Administration Shell de BC14 en modo administrador.
- Errores que nos pueden dar al despublicar o desinstalar las extensiones actuales por
dependencias, leerlos, entenderlos aunque normalmente con volver a ejecutar el proceso
se acaba limpiando correctamente.
- El script más importante (y se parece mucho al primero) es el que incluye la clausula “-
SymbolsOnly”, este se encarga de desinstalar la extensión “Application”.
- Se recomienda ejecutar “Get-NAVAppInfo -ServerInstance <server instance name>” al
inicio y al final para asegurarnos de que esa todo limpio.
6. Conversión a BC19 (Task 7)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es convertir la BBDD a versión BC19 para que se pueda arrancar la
instancia BC19.

- Importante ejecutar el Business Central Administration Shell de BC19 en modo administrador.

- A nivel de SQL no hay ningún cambio importante:

7. Configuración BC19 (Task 8 – Task 9)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es configurar la instancia de BC19 para que sepa que estamos en modo
upgrade. Con esta configuración establecemos cual es la app que va a llevar a cabo la
sincronización a la diferentes extensiones de los datos.

- Además, se para el Task Scheduler para que no entre en conflicto con los procesos de migración
y sincronización

- Adicionalmente, debemos importar la licencia actualizada a BC19 para poder ejecutar el resto
de pasos.
8. Publicar App Migración(Task 10)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es poder tener publicadas las App que luego nos permitirán ejecutar en
el (Task 17) los procesos de upgrade propios de las apps.

- Que apps se tiene que publicar:

- La app de migración AllTables versión 1 (Task 3)
- Las EmptysApp (Task 4) que se tendremos para esta migración.

- A nivel de SQL no hay ningún cambio importante:

9. Sincroniza App Migración (Task 11)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es sincronizar la instancia y las extensiones que hemos instalado en el
paso anterior.

- A nivel de SQL se cambian las tablas para añadir el ID de AllTables:

10. Upgrade aplicación e Instalación (Task 12)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es ejecutar la upgrade de datos de la parte estándar previa a realizar los
cambios de estructura de tablas para las extensiones definitivas. Además se instalan las
extensiones de sistema publicadas y sincronizadas.

- Entre la upgrade de datos y la instalación debemos comprobar que el upgrade a finalizado:

Get-NAVDataUpgrade -ServerInstance $serverInstanceUpg
Progress : 100.00 %
State : Completed

- A nivel de SQL no hay ningún cambio importante:

11. Publicar extensiones finales (Task 13)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es publicar la AllTables (versión 2), todas las extensiones que estén
incluidas en el migration.json y la extensión Application de BC19.

- Si aquí da algún error publicando el Application es que en el Task 6 no se ha realizado la

despublicación SymbolsOnly.

- Si aquí da algún error de publicación de la extensiones de cliente es que los ficheros no son los
correcto o sus dependencias no son las adecuadas.

- A nivel de SQL no hay ningún cambio importante:

12. Sincronizar extensiones finales (Task
14a)
ASPECTOS IMPORTANTES:

- Este paso lo dividimos en dos, en este primero el objetivo de este paso sincronizar las
extensiones publicadas en el paso anterior, sincronizamos todas menos la AllTables versión 2.

- A nivel de SQL creará la estructura de tablas de las extensiones pero sin datos.
- Antes:

- Después:

Los datos siguen en la tabla de extensión AllTables versión1:

13. Sincronizar extensión migración (Task
14b)
ASPECTOS IMPORTANTES:

- En este segundo el objetivo de este paso sincronizar la migración en el paso anterior AllTables
versión 2, esto realizará la comprobación de que la estructura de datos es correcta y una vez
realizada la comprobación moverá los datos a las tablas de la extensiones.

- Si la preparación inicial no es correcta donde fallará será en este paso, y deberemos volver a
empezar.

- Se traspasan los datos y se borran las tablas de AllTables versión 1:

14. Proceso migración versión 2 (Task 15)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es ejecutar el proceso si existiese en la app AllTables versión 2, en

nuestros casos entiendo que no habrá.

- Por seguridad yo lo haría igualmente.

- A nivel de SQL no existe ningún cambio importante.

15. Limpiar app migración (Task 16)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es limpiar la base de datos de la app AllTables versión 2 y despublicarla.

- Se puede añadir un –force a la sincronización modo Clean para que no pregunte:

Sync-NAVApp -ServerInstance $serverInstanceUpg -Name $migrationAppName - Version
'2.0.0.0' -Mode Clean -Force

- El orden correcto es:

- Desinstalar la app
- Sincronizar modo clean
- Despublicar las dos versiones
16. Instalar o migrar la app finales (Task 17)
ASPECTOS IMPORTANTES:

- El objetivo de este paso es ejecutar los procesos de migración propios de cada extensión o
instalar aquellas que no tengan.

- Sobre las estándar se ha de ejecutar:

- Start-NAVAppDataUpgrade -ServerInstance $serverInstanceUpg -Name 'System
Application' -Version $newSystemAppVersion
- Start-NAVAppDataUpgrade -ServerInstance $serverInstanceUpg -Name 'Base Application'
-Version $newSystemAppVersion
- Install-NAVApp -ServerInstance $serverInstanceUpg -Name 'Application'

- Sobre la master data, extension old y/o productos propios, para cada una de ellas:
- Si se ha creado la EmptyApp se debe hacer Start-NAVAppDataUpgrade
- Sino se ha creado la EmptyApp se debe hacer Install-NAVApp.
17. Finalizar upgrade
ASPECTOS IMPORTANTES:

- Los pasos más importantes de la upgrade ya está finalizados los 3 últimos dan menos errores o
son menos importantes:
- Task 18: Actualiza los Add-Ins que son estándares, si existiesen nuestro deberíamos
hacerlos aquí.

- Task 19: Aquí trabaja con los conjuntos de permisos, yo recomiendo hacer esto una vez
finalizada la upgrade y el cliente ya este probando.

- Task 20: Cambiar la versión de la aplicación para de la base application, cambiar la versión
de la aplicación que se muestra en la página de ayuda y soporte en el cliente

- Tareas post upgrade: aquí lo mínimo que hay que hacer es despublicar las versiones
EmptyApp de las extensiones finales.
BARCELONA MADRID SEVILLA VALENCIA ZARAGOZA
Avda. Francesc Macià, 60 Calle Sevilla, 6 C/Gonzalo Jimenez de Quesada 2, Ronda Narciso de Monturiol, 17 B Calle Eduardo Ibarra, 6
Torre Millenium - Planta 19 Planta 3 Torre Sevilla, Planta 4. Oficina 24 Planta 2
28014 Madrid 41092 Sevilla 46980 Paterna (Valencia) 50009 Zaragoza
08208 Sabadell (Barcelona)
91 705 48 80 95 526 00 75 961 10 00 23 976 08 04 65
93 193 75 25