PCGerente y Runfood comparten la misma base de datos, por lo tanto al crear un artículo en PCGerente, se crea en la misma base de datos que Runfood lee.
No se necesitan volver a hacerlo en RUnfood, no se necesitan procesos de sincronización.
Es una sola fuente de información.
Algunas funciones de RUNFOOD no generan asientos contables y por lo tanto son incompatibles con PCGerente. Cuando se contrate PCGerente, estas funciones deben dejarse de utilizar inmediatamente, para evitar descuadres contables.
| Opción Runfood incompatible | Reemplazo en PCGerente |
|---|---|
| Declarar valores en cierre de caja | Ninguno |
| Gastos de caja | COMPRAS / OTRAS COMPRAS y COMPRAS / COMPRAS DE INVENTARIO (formales o informales) |
| Ingresos de caja | CAJA / INGRESOS |
| Ventas pendientes | Ninguno |
| Ingresos y Egresos de inventario (Ajustes) | INVENTARIO / AJUSTE DE INGRESO e INVENTARIO / AJUSTE EGRESO |
| Transferencias | INVENTARIO / TRANSFERENCIA |
| Producción | INVENTARIO / ARMAR RECETA |
| Transformación | INVENTARIO / CONVERSION |
En el caso de la producción, sí genera asientos, pero tiene bugs en cuanto al costo. Por eso hemos decidido que se hagan siempre por PCGerente.
RUNFOOD admite registrar facturas con valor cero. Esto es un error conocido, que no tiene solución permanente aún.
El usuario debe tener cuidado de no registrar facturas con valor cero ya que el SRI no las admite y genera error de envìo.
Si necesita registrar una venta en cero por concepto de cortesías (por ejemplo), debe usar el documento NOTA DE ENTREGA.
Hay restaurantes que quieren vender un mismo producto en diferentes precios dependiendo del local.
La tabla ARTICULO tiene 6 precios, y RF usa sólo el precio 1.
La solución que RF brinda es crear varias veces el artículo y luego habilitarlo (o deshabilitarlo) según el local donde quieres verlo.
Por ejemplo si tienes 3 locales y quieres lograr esto
| Producto | Local 1 | Local 2 | Local 3 |
|---|---|---|---|
| A | $ 1 | $ 1 | $ 2 |
| B | $ 3 | $ 4 | $ 4 |
Lo que haces es crear 2 veces cada artículo (total = 4 artículos)
| Código | Descripción | Precio |
|---|---|---|
| A1 | A | $ 1 |
| A2 | A | $ 2 |
| B1 | B | $ 3 |
| B2 | B | $ 4 |
Luego configuras para cada local (tabla EXISTENCIA) la visibilidad del producto.
La tabla EXISTENCIA es una unión de artículos y locales (4 artículos x 3 bodegas = 12 registros):
| Artículo (código) | Local | Habilitado |
|---|---|---|
| A1 | 1 | ✅ |
| A1 | 2 | ✅ |
| A1 | 3 | ❌ |
| A2 | 1 | ❌ |
| A2 | 2 | ❌ |
| A2 | 3 | ✅ |
| B1 | 1 | ✅ |
| B1 | 2 | ❌ |
| B1 | 3 | ❌ |
| B2 | 1 | ❌ |
| B2 | 2 | ✅ |
| B2 | 3 | ✅ |
Cuando una empresa lleva inventario por primera vez se comenten muchos errores. Al punto que no son compatibles con el control por recetas, ej. la descripción no dice la presentación (kg), existen artículos duplicados, hay artículos artículos descontinuados que ya no se pueden borrar porque tienen historial.
Antes de iniciar este proceso verificar que todos los documentos electrónicos esten autorizados.
Antes de realizar la migración se debe generar un respaldo de la base de producción (original)
Notificar siempre a Runfood del cambio realizado.
En ese caso el proceso es:
@El script está en
Dropbox/Recursos PCGerente/Querys y Scripts/Runfood/Migracion articulos y recetas.sql
En PCGerente el cierre de caja es por usuario.
En Runfood el cierre de caja es más flexible: puede ser por bodega o por usuarios.
Cuando los dos sistemas están en funcionamiento, el cierre se hace desde Runfood. En PCGerente se le puede consultar, reimprimir, anular, depositar, etc.
Si quieres hacer una factura que no aparezca en el cierre de caja de runfood (ej. porque el negocio también factura arrendamiento) entonces regístrala en PCGerente, pero en una bodega distinta a la que se usa en RUNFOOD.
En RUNFOOD existe una función de anticipos que es distinto al anticipo de PCGerente.
El anticipo de runfood es un registro de un dinero que se recibe, pero no se contabiliza inmediatamente. El anticipo se ata a un pedido. La contabilización ocurre cuando se guarda la factura de ese pedido.
Es decir, si el anticipo y la factura ocurren el mismo día no habrá ningún problema pero la forma de pago a usarse no seria anticipo sino efetivo o transferencia, etc. como haya sido recibido el dinero.
Si el anticipo y la factura ocurren en días distintos, es mejor no usar los anticipos de runfood, porque dichos anticipos sí salen en el cierre de caja, pero no constan contablemente en PCGerente.
Los anticipos de PCGerente son un control completo de un dinero que se recibe y se va a aprovechar en el futuro. El anticipo sí se contabiliza, y se lleva un registro de cómo se ha consumido. Cada uno de estos "consumos" se llaman cruces y generan su propio asiento.
RUNFOOD no tiene la posibilidad de manejar anticipos como lo hace PCGerente.
@Consecuencias:
Script:
--IMPORTANTE: RESPALDAR LA BASE DE DATOS ANTES DE EJECUTAR!
--1) Defina una fecha del arranque del sistema
declare @fechaArranque date='20220801'
--2) Ejecutar el proceso
UPDATE MD SET MD.ARTICULO=A.ID
FROM MOVIMIENTODETALLE MD INNER JOIN
MOVIMIENTOCABECERA MC ON MD.cabecera=MC.id CROSS JOIN
ARTICULO A
WHERE A.codigo='@' AND A.stockeable=0 and
CAST(MC.FECHAEMISION AS DATE)<=@fechaArranque
--3) Actualizar existencias
EXEC ActualizarExistenciasLote