¿Cómo migro los datos de Powergest?

La pantalla Migrar de Powergest recibe un ZIP con las tablas del programa antiguo y las importa todas de una vez, en el orden correcto, sin tener que preparar ninguna plantilla. Es el camino recomendado para pasar un cliente de Powergest al ERP.

¿Qué necesito antes de empezar?

Un fichero ZIP con las tablas .dbf de la empresa de Powergest que quieres pasar. Sirve el ZIP de la carpeta de datos completa: el programa coge las tablas que reconoce e ignora el resto. El límite es 200 MB.

En Powergest cada empresa contiene un solo ejercicio; aquí eliges a qué ejercicio de la empresa actual entran los datos. Puedes crear ese ejercicio desde la propia pantalla.

Los datos entran en la empresa en la que estás trabajando. Si vas a migrar varias empresas de Powergest, cambia de empresa entre una migración y otra.

Si además quieres las fotos de los artículos, necesitas una cosa más: la carpeta BMP de la instalación de Powergest. Las fotos no van dentro del ZIP. Está explicado en el apartado siguiente, y conviene leerlo antes de migrar.

Entra por Gestión → Migrar de Powergest.

¿Cómo se hace?

1. En 1 · Ejercicio destino (empresa actual), elige el ejercicio al que van los datos. Si no
2. En 2 · Fichero ZIP de Powergest, selecciona el ZIP. Al cargarlo se **inspecciona sin escribir
3. En Carpeta de imágenes del programa antiguo, escribe la carpeta BMP de Powergest si quieres
4. Lee los avisos, si aparecen. El de Tablas del ZIP aún no soportadas dice qué se ignora. El de
5. En 3 · Migrar, deja marcada Actualizar lo ya importado si vas a repetir una migración, y

La previsualización del paso 2 no toca la base de datos. Puedes cargar el ZIP para ver qué trae y no migrar.

¿Cómo traigo las fotos de los artículos?

Las fotos no viajan dentro del ZIP. En Powergest son ficheros sueltos guardados en una carpeta aparte, así que hay que decirle a la migración dónde está esa carpeta.

Se hace en el campo Carpeta de imágenes del programa antiguo, en el paso 2. Ahí va la carpeta BMP de la instalación de Powergest. Es una ruta como D:\Powergest\011\BMP.

Es una ruta vista desde el servidor del ERP, no desde tu ordenador. Si Powergest está en otra máquina, copia la carpeta BMP a un sitio que el servidor alcance, o usa una ruta de red completa (\\SERVIDOR\Powergest\011\BMP). Si no sabes dónde está esa carpeta, pregunta a quien te lleva el programa antiguo: la respuesta está en el apartado siguiente.

Las fotos se guardan en la galería del artículo, la misma que ves al abrir su ficha. Por esa misma carpeta entran las imágenes de las categorías del catálogo, que van a la ficha de cada categoría.

¿Qué pasa si no indico la carpeta de imágenes?

Todo lo demás se migra igual, y las fotos no entran. El campo es opcional a propósito: no bloquea la migración ni la deja a medias.

En el Resultado de la migración aparece una fila de imágenes diciendo que no se importaron, y por qué. Nunca se quedan fuera en silencio.

Si te das cuenta después, no hay que rehacer nada: vuelve a migrar indicando esta vez la carpeta. Migrar otra vez no duplica las fotos que ya estén, ni las fichas ya migradas.

¿Por qué no aparecen todas las fotos?

Porque el programa antiguo guarda, junto a cada artículo, la ruta desde la que se arrastró la foto el día que se dio de alta. Esas rutas suelen apuntar a discos de otros ordenadores que hoy ya no existen: C:\ifswin, D:\FOTOS CATALOGO, G:\....

Esas rutas no sirven. Lo que sí sirve es que Powergest copió cada foto a su carpeta BMP con el mismo nombre de fichero. Por eso la migración se queda solo con el nombre y lo busca dentro de la carpeta que le has indicado.

Medido en una instalación real: se encuentran 248 de 286 fotos, un 87 %. Las que faltan son fotos que el cliente ya no tiene en esa carpeta —se borraron, o nunca llegaron a copiarse—. No hay forma de recuperarlas desde la migración: se vuelven a subir a mano en la ficha del artículo.

En esa misma instalación entraron 232 imágenes: 201 de artículos y 31 de categorías del catálogo.

Las de categoría se guardan en la ficha de su categoría, igual que las de artículo se guardan en la galería del artículo.

¿Cómo leo los motivos de las imágenes que no entran?

En el Resultado de la migración, la fila de imágenes trae debajo su tabla de detalle, con la misma forma que las demás: Fila, Clave y Motivo. Cada foto que no entró dice por qué.

Se listan hasta 20, como en el resto de tablas. Si hay más, debajo pone cuántas quedaron sin listar.

¿Se migra mi catálogo?

Sí. Entra el catálogo entero del programa antiguo: las categorías, los productos colocados dentro de cada una, los textos de cada ficha con sus traducciones y las imágenes de las categorías.

Se conserva el orden: las categorías quedan como estaban y los productos ocupan dentro de cada categoría el sitio que tenían.

Medido en una instalación real: 38 categorías —35 en el primer nivel y 3 colgando de otra— y 487 productos colocados.

Las categorías se crean primero con un nombre provisional y el paso siguiente, el de los textos, les pone su nombre de verdad. Si el ZIP no trajera los textos, el catálogo queda con la estructura correcta y con nombres poco legibles: se corrige volviendo a migrar con el fichero completo.

¿Se conservan los textos y las traducciones del catálogo?

Sí. De cada ficha del catálogo entran el título, la descripción —con su formato— y los datos para buscadores: meta título, meta descripción y palabras clave.

Las traducciones no se pierden. Se guarda una ficha por objeto y por idioma, así que un artículo con texto en castellano y en euskera llega con los dos. Medido en una instalación real: 392 textos importados de 507, repartidos en 293 en castellano y 95 en euskera.

Es la parte de la migración que más trabajo ahorra, porque un texto de escaparate traducido es lo más caro de rehacer a mano.

¿Por qué hay textos que no entran?

Porque pertenecen a fichas que ya no existen en el programa antiguo. Con el tiempo se borran categorías y artículos, pero sus textos se quedan en el fichero sin nadie a quien pertenecer.

No hay nada que arreglar: son restos, no datos perdidos. En la instalación medida fueron 115 de 507.

Aun así no se descartan en silencio. Cada uno aparece en el Resultado de la migración, en la tabla de detalle de los textos, con su Fila, su Clave y el motivo: dice que ese texto no corresponde a ninguna categoría ni artículo importados.

Si al leer el detalle reconoces una categoría que sí debería existir, la causa suele ser otra: que el ZIP no traía la tabla del árbol del catálogo, o que se migró antes que los artículos. Vuelve a migrar entero y se resuelve.

¿Qué hago si me avisa de que el ZIP trae otro juego de tablas?

Ese aviso sale antes de migrar, en la previsualización, y dice algo así: «El ZIP trae otro juego de tablas que NO se va a importar: ALMA27 (junto a ALMA)».

Significa que dentro del ZIP hay dos tablas del mismo tipo: la normal y otra con el mismo nombre más un sufijo. Pasa con cualquiera de ellas: ALMA y ALMA27, FAMILIA y FAMILIA27, PROV y PROV_2, IMAGEN e IMAGEN2. Solo se importa la primera, la que no lleva sufijo.

Ese sufijo puede ser otra empresa, otro ejercicio o una copia de seguridad. El programa no lo decide por ti, porque no hay forma de saberlo desde fuera: te lo enseña para que lo compruebes.

Qué hacer:

1. Abre el programa antiguo y mira cuál de las dos tiene los datos buenos. Si tienes dudas,
2. Si los datos buenos son los de la tabla sin sufijo, sigue con la migración: es la que entra.
3. Si los datos buenos son los de la tabla con sufijo, no migres todavía. Prepara un ZIP en el

Merece la pena pararse aquí. En un caso real, ALMA tenía 960 artículos y ALMA27 nueve mil: migrar sin mirar habría dejado fuera casi todo el catálogo, y el resultado de la migración habría salido correcto, porque las 960 fichas que entraron entraron bien.

¿Qué tablas se migran hoy?

La migración de un clic pasa los maestros y el catálogo, en este orden, que es el de sus dependencias:

De los artículos se conserva también la marca de publicar en la tienda, y la familia mantiene el código que tenía en el programa antiguo.

Las tres tablas del catálogo van después de los artículos y en ese orden entre ellas. Primero el árbol, que crea las categorías y coloca dentro los productos. Después los textos, que ponen a cada categoría su nombre de verdad. Y al final las imágenes, que necesitan que existan ya el artículo o la categoría de los que cuelgan.

Las familias van antes que los artículos a propósito. En el programa antiguo el artículo solo guarda el código de su familia; el nombre está en otra tabla. Al pasar primero esa tabla, la familia queda creada con su nombre de verdad —BIZ se llama BIZCOCHO, no «BIZ»— y el artículo la encuentra ya hecha. Si el ZIP no trae la tabla de familias, las familias se siguen creando a partir del código del artículo, pero entonces se quedan llamándose como su código.

Las divisas van las primeras, porque las fichas de cliente y de proveedor y los documentos guardan el código de su moneda y conviene que la ficha de esa moneda ya exista.

Hay una particularidad con ellas: en Powergest la tabla de monedas no está en la carpeta de la empresa, sino en la carpeta raíz de la instalación, así que muchas veces no viene dentro del ZIP. Cuando falta, aparece en la lista de tablas que no llegaron y no pasa nada más: el resto de la migración sigue igual y el programa funciona con las monedas que trae de fábrica —euro como moneda de la casa, más las habituales—. Si necesitas las tuyas, copia el fichero MONEDA.DBF de la carpeta raíz de Powergest dentro del ZIP, o pásalo aparte con el asistente de importación.

Y otra, que conviene saber antes: la moneda de la casa no cambia al migrar. Si en el programa antiguo llevabas la contabilidad en otra moneda, esa moneda entra como una divisa más y verás un aviso diciéndolo. Cambiar cuál es la moneda de la casa se hace a mano en la ficha de divisas, porque afecta a todos los importes ya grabados.

De clientes y proveedores entra la ficha casi entera: identidad y dirección, contacto (móvil, fax, web, persona de contacto), observaciones, condiciones económicas (días de pago, descuento, riesgo, retención de IRPF, cuenta contable, divisa, régimen) y datos bancarios. El detalle campo a campo está en qué se puede importar.

De un tercero entran también su forma de pago y su agente, ya enlazados con las fichas que la propia migración crea. Lo que no entra es su tarifa y sus direcciones adicionales.

¿Entran las facturas y los albaranes?

Sí, y con su número y su serie de siempre. Es la parte que más importa al reconocer el histórico: la factura que tienes impresa, declarada y cobrada se llama igual en el programa nuevo, así que la encuentras buscando por donde la buscabas antes.

Entran los siete tipos: presupuestos, pedidos, albaranes y facturas de venta, y pedidos, albaranes y facturas de compra. Cada documento llega con su cliente o proveedor, sus líneas en el mismo orden, sus precios, descuentos e impuestos, y además con lo que el programa antiguo guardaba y hasta ahora se perdía: la forma de pago, el agente, el almacén, la cuenta contable, el importe aplazado, el coste, la fecha de servicio, los bultos y la comisión. De cada línea se conserva su coste, su comisión, la referencia con la que ese artículo aparece en los papeles del proveedor o del cliente, y las cajas.

Los documentos migrados son histórico: quedan fuera del envío a Hacienda, porque su declaración la hizo en su día el programa antiguo y volver a enviarla sería declararla dos veces.

Si un documento trae un código de forma de pago, de agente o de almacén que no existe en el programa nuevo, el documento entra igual y ese dato queda sin rellenar. Es preferible a perder la factura entera por un código suelto.

¿Y lo que los clientes me deben?

Entra, y enlazado con su factura. Cada vencimiento llega con su fecha, su forma de pago, su agente, su número de recibo y su base, así que la cartera se puede remesar desde el primer día.

Lo que ya estaba cobrado entra como cobrado. Un recibo que el cliente pagó en su día no vuelve a aparecer como pendiente, y uno que pagó a medias entra por lo que falta, que es lo que sigue debiendo. Es la diferencia entre una cartera que cuadra con los extractos del banco y una lista de deuda inventada.

Por eso una factura importada no se inventa sus vencimientos: los suyos son los que traía el programa antiguo. Si el ERP los recalculara a partir de la forma de pago saldrían plazos teóricos —sin número de recibo, sin lo ya cobrado y sin los aplazamientos que se negociaron por teléfono—, y el cliente vería su deuda por duplicado.

Los vencimientos cuya factura no esté en el ZIP entran igual, como saldo arrastrado del tercero.

¿Y las existencias del almacén?

Entran, con el stock de cada artículo en cada almacén y su mínimo de aviso. Lo que se trae es la foto del almacén tal como está el día de la migración, no el historial de entradas y salidas: los documentos que se importan no mueven stock, así que las existencias son las que traiga el programa antiguo y nada las descuadra por el camino.

Un artículo con existencias negativas entra en negativo. No es un error de la migración: es lo que había en el programa antiguo, y casi siempre significa que se vendió algo cuya compra no llegó a registrarse. Ponerlo a cero taparía el problema y además dejaría el inventario sin cuadrar con el programa viejo. Se regulariza con un inventario, que es lo que tocaba hacer igualmente.

Si vuelves a migrar, las existencias se ponen al valor del ZIP, no se suman. Repetir la migración no infla el almacén.

Lo que todavía no entra con esta pantalla son las tarifas por cliente, los lotes y la contabilidad. Aparece en el aviso de tablas no soportadas para que quede constancia de que se ha ignorado, nunca se descarta en silencio. Esos datos se pueden pasar uno a uno con el asistente de importación, preparando una plantilla por tabla.

¿Qué pasa con un artículo que está en varios almacenes?

Entra una sola vez, con todas sus fichas leídas. En el programa antiguo, un artículo que existe en dos almacenes se guarda dos veces, una por almacén. Aquí eso no crea dos artículos: la segunda ficha del mismo código actualiza al artículo que ya está.

Por eso el resultado puede enseñar más filas leídas que artículos creados, y es correcto. En un caso real, el fichero traía 1.011 fichas y salieron 960 artículos: las 51 restantes eran repeticiones del segundo almacén.

Un matiz importante: esto no suma las existencias de los dos almacenes. Cada ficha lleva el stock de su almacén, y así entra: separado por almacén, no acumulado en el artículo.

¿Y si el programa antiguo usa un almacén que no tiene dado de alta?

Se crea, con el mismo código que usa.

Pasa más de lo que parece: el fichero de almacenes del programa antiguo declara solo el 001, pero luego hay artículos con stock en el 002. El almacén existe de verdad —tiene mercancía dentro—, lo que falta es su ficha.

Antes esas existencias se quedaban fuera con un aviso. Ahora entran, porque perder inventario real es peor que tener una ficha de almacén de más. Lo mismo vale para las líneas de un documento: una línea siempre acaba en un almacén, y si el que cita no está dado de alta, se crea en vez de mandarla a otro — que era la forma silenciosa de acabar con el stock repartido donde no es.

Después de migrar, revisa el maestro de almacenes y ponles el nombre que corresponda: entran con el código como nombre, porque es lo único que el programa antiguo dice de ellos.

¿Qué pasa cuando pulso Migrar ahora?

Las tablas se importan una detrás de otra, en el orden de la lista. Cada tabla es independiente: si una falla entera, se registra el fallo y la migración sigue con las siguientes.

Al terminar sale el Resultado de la migración, con una fila por tabla: creadas, actualizadas, incompletas, con error, omitidas y estado. Debajo, las tablas soportadas que no venían en el ZIP y las que se han ignorado.

Las tres columnas del final dicen cosas distintas, y conviene no confundirlas:

Las fichas se crean de verdad y no hay deshacer. Por eso la primera pasada conviene hacerla sobre un ejercicio marcado como de pruebas.

Una tabla vacía no es un error: se informa con 0 filas y se pasa a la siguiente.

¿Por qué falla una fila? ¿Dónde lo veo?

En el Resultado de la migración, cada tabla que haya tenido problemas trae debajo una tabla de detalle con tres columnas: Fila, Clave y Motivo. Ahí está la fila exacta del fichero antiguo, el código de la ficha que no entró y la razón, con las mismas palabras con las que el programa la habría rechazado si la escribieras a mano.

Se listan hasta 20 filas. Si hubo más, debajo pone cuántas quedaron sin listar. Veinte ejemplos bastan casi siempre, porque los fallos suelen repetirse: si las veinte dicen lo mismo, las cuatrocientas restantes dicen lo mismo.

Qué hacer con eso:

• Si el motivo apunta a un dato de la ficha —un código vacío, un importe que no es un número—,
• Si el motivo apunta a otra ficha que no existe («no se encontró el artículo…»), migra otra vez
• Si es un caso suelto, sale más a cuenta crear esas fichas a mano después de migrar.

Cuando lo que falla es la tabla entera, el aviso lo dice con todas las letras: no se importó ninguna fila de esa tabla, y debajo aparece qué columna esperaba y no encontró en el fichero. Ahí no hay filas fallidas que listar, porque no llegó a intentarse ninguna.

¿Qué son las fichas «incompletas»?

Son fichas que sí están en el programa nuevo, pero a las que les falta un dato porque ese dato chocaba con una regla del ERP. No son un error: entrar sin un campo es mucho mejor que perder la ficha entera con su nombre, su dirección, su banca y todo su histórico.

El resultado las cuenta en su propia columna, Incompletas, y debajo lista cuáles son y qué les falta. Es la lista que hay que revisar después de migrar; con el resto no hay nada que hacer.

Hoy pasa en dos casos, y los dos vienen de lo mismo: una empresa con varias tiendas tiene en el programa antiguo una ficha por punto de venta, todas con el mismo CIF y a menudo con la misma cuenta contable.

• Ficha sin su NIF. El ERP no admite dos fichas con el mismo documento, porque el 347 y el 349
• Ficha sin su cuenta contable. Dos fichas en la misma subcuenta mezclarían sus saldos en el

¿La migración cambia algo de la configuración de mi empresa?

Puede, y te lo dice arriba del todo del resultado, en un aviso aparte, porque es lo único que sigue puesto cuando la migración termina.

Hay dos casos.

El primero: si el plan contable del programa antiguo usa códigos de cuenta con letras (4300135E, 4300FS00), la migración activa en tu empresa la opción de admitir códigos de cuenta con letras. Sin ella, esas cuentas se rechazan una a una y con cada una se pierde la ficha del cliente que la usa.

Solo se activa si el fichero trae de verdad códigos así; con un plan normal no se toca nada. Queda activada después de migrar y se puede volver a apagar en la configuración de Contabilidad.

El segundo es el ancho de los códigos, y ese lo autorizas tú. Está explicado abajo.

¿Por qué no me deja migrar si los códigos «no coinciden»?

Porque migrar así te dejaría los datos inservibles, y no se vería hasta mucho después.

En el programa antiguo un cliente puede ser 0001, con cuatro cifras. Si tu empresa del ERP está puesta en seis, ese mismo cliente entra como 000001. La migración termina bien, están todas las fichas y los totales cuadran, pero el código ha cambiado: deja de casar con las etiquetas, con los listados impresos y con lo que el cliente teclea para buscarse. No hay arreglo a medias — habría que vaciar y volver a migrar.

Por eso, cuando cargas el ZIP, el programa compara la forma de los códigos del programa antiguo con la de tu empresa y no te deja migrar si no coinciden. Tienes dos salidas:

• Ajustar el ancho a mano en Configuración → Campos y volver a esta pantalla.
• Marcar la casilla que aparece en el aviso, para que la migración lo iguale al del programa

Si tu empresa ya tiene fichas, el aviso te lo dice: al cambiar el ancho, los códigos que ya existían dejan de casar con el nuevo. Piénsalo antes de marcarlo.

¿Y si el aviso dice que los códigos «no están rellenos»?

Entonces no hay nada que ajustar y se migra tal cual.

Algunos programas antiguos rellenan los códigos con ceros hasta una longitud fija, y otros no. Cuando no lo hacen, el número que declara la configuración es un máximo, no una forma: los códigos de artículo pueden medir tres caracteres o diez, y haberlos como GES o 1011A. Rellenar eso con ceros convertiría GES en 0000000GES, que no es lo que el cliente tiene.

El programa lo distingue mirando los códigos de verdad que trae el ZIP, no solo lo que dice la configuración, porque las dos cosas conviven en la misma instalación: es normal que los clientes sí estén rellenos a un ancho fijo y los artículos no.

¿Puedo repetir la migración sin duplicar nada?

Sí, y es el uso previsto: se migra una primera vez para que el cliente ensaye, se sigue trabajando en Powergest unos días y se vuelve a migrar antes del arranque real.

El programa recuerda qué ficha del ERP corresponde a cada código de Powergest, así que al repetir:

• Con Actualizar lo ya importado marcado (por defecto), las fichas ya migradas se actualizan
• Con la casilla desmarcada, las ya migradas se saltan y solo entran las nuevas.

En ninguno de los dos casos se duplica una ficha. Lo que hayas creado a mano en el ERP entre una migración y otra se respeta: la migración no borra nada.

Con el catálogo pasa lo mismo, y conviene decirlo porque es donde más se nota: no se duplican ni las categorías, ni los productos colocados, ni los textos, ni las imágenes. Migrar otra vez actualiza lo que ya está y añade lo que falta.

Si algo va mal

Ver también: Qué se puede importar · Importar clientes desde un Excel · Abrir un ejercicio nuevo