TpvFox - Gestion de Empresa
Aplicación web para gestionar pequeñas y medianas empresas
Nuestro pequeño bebe
Puede ver mas información en esta categoria ( Presentacion proyecto Tpvfox) e incluso ver y descargar el código en GITHUB
Introducción sobre Recalculo de Precios en Tpvfox
El acción de recalculo de precios permite revisar y actualizar los precios de venta de los artículos cuando se detectan cambios en el precio de compra registrado en los albaranes de proveedor.
Cuando un artículo cambia de precio de compra, el sistema registra automáticamente el cambio en la tabla historicos_precios para que el usuario pueda revisar si es necesario modificar el PVP.
Este sistema evita que los precios de venta cambien automáticamente sin revisión. Aunque se podría automatizar, de momento tiene una revisión humana y así permite mantener un control adecuado sobre los márgenes comerciales.
Funcionamiento del sistema
El proceso se inicia cuando se registra un albarán de proveedor.
Si el sistema detecta que el precio de compra de un artículo ha cambiado respecto al anterior, se genera un registro en la tabla historicos_precios.
Flujo del proceso:
Albarán de proveedor
↓
Cambio en precio de compra
↓
Registro en historicos_precios
↓
Estado inicial: Pendiente
↓
Revisión por parte del usuario
↓
Aplicación o no del nuevo PVP
La Tabla historicos_prercios
Esta tabla registra todos los cambios de precios, tanto costo como ppv. Los registros en historicos_precios pueden tener diferentes estados según su situación dentro del proceso de revisión.
Pendiente
Estado inicial del registro.
Indica que se ha detectado un cambio en el precio de compra del artículo y que el precio de venta todavía no ha sido revisado.
Recomendado
El sistema calcula automáticamente un precio de venta recomendado según los márgenes configurados en el artículo.
Este valor es una sugerencia que el usuario puede aceptar o modificar.
A mano
El precio de venta ha sido modificado manualmente por el usuario.
Este estado indica que el precio aplicado no corresponde al recomendado automáticamente por el sistema.
Sin cambios
El usuario ha decidido mantener el precio de venta actual.
Esto suele ocurrir cuando el cambio en el precio de compra no afecta significativamente al margen o cuando se desea mantener un precio comercial concreto.
Revisado
El registro ha sido revisado por el usuario.
Indica que el cambio detectado ya ha sido evaluado y que el precio de venta ha sido confirmado o actualizado.
Sin revisar
Este estado indica que el artículo ha sufrido modificaciones posteriores al registro inicial.
Cuando un registro se encuentra en este estado, el sistema no permite modificar el PVP desde el módulo de recalculo, para evitar sobrescribir cambios realizados posteriormente.
Objetivo del sistema
- Detectar cambios en los precios de compra de los proveedores.
- Permitir revisar antes de aplicar cambios en el precio de venta.
- Mantener un histórico de modificaciones de precios.
- Evitar cambios automáticos que puedan afectar a los márgenes comerciales.
Recomendaciones de uso
Se recomienda revisar periódicamente los registros en el módulo de recalculo para:
- Comprobar cambios en los precios de compra.
- Ajustar precios de venta cuando sea necesario.
- Mantener márgenes adecuados en los artículos.
Funciones y objetivo de TPVFOX
Es una aplicación para gestionar medianas y pequeñas empresas. En la que puedes:
- Gestionar productos: Altas, modificaciones, gestión stock y control de precios.
- Gestionar Proveedores: Altas y modificaciones.
- Gestionar Clientes: Altas y modificaciones.
- Gestión de compras: Pedidos a proveedores, albaranes de entrada , Facturas de proveedores.
- Gestión de ventas: Tickets-POS, pedidos de clientes, albaranes y facturación-
También se puede conectar con una tienda e-comerce (Joomla + Virtuemart ), tiene la posibilidad conectarse otros e-comerce como :
- Prestashop
- woocommerce
- ...
Estas aun no esta creada la API, te apetece hacerla.
Licencia y código
Esta publico en GITHUB y con licencia GNU General Public License v2.0
Puede utilizarlo, modificarlo y incluso venderlo, lo que no puedes cambiar la licencia, el código debe ser abierto siempre.( leer licencia )
Aunque el proyecto aun esta su fase beta , ya hay varias empresas que la utilizan, si estas interesado en utilizarlo para ti o tu empresa, estaríamos encantados en ayudar.
Tabla: historico_precios
Descripción
La tabla historico_precios registra los cambios de precio de costes y ventas ( siempre con iva) realizados a los artículos del sistema. Permite llevar un control histórico de las modificaciones, incluyendo datos como el precio anterior, el nuevo, la fecha del cambio, el usuario que lo realizó, y el contexto desde el cual se hizo.
Hoja de Ruta para Implementar Factura Electrónica y VeriFactu en TPVFOX (PHP)
Punto a seguir.
Aquí intentaremos explicar los posibles estado que pueda tener el campo estado en las distintas tablas del proyecto TPVFOX.
Este campo hasta ahora era varchar, sabemos que no es lo correcto, crearemos una tabla de estados para relacionarlas con un id :-)
Ahora definimos los posibles estados que vamos utilizando en las distintas tablas.
De momento la unica forma eliminar varios productos de una familia, lo puedes hacer desde la familia en la opcion de productos, ahí tiene que seleccionar el producto y luego pulsar el boton de eliminar
Hay en creada una advertencia en albaranes de compras, que puede generar un error, que me imagino que puede suceder en pedidos en el modulo compras e incluso en pedido y albaranes en modulo de ventas..
La advertencia es está:
Esto realmente controla que el estado del albarán sea "Sin Guardar" igual que el de temporal. Si aparece es que hay un error, fijo.
Esto aparece cuando , pulsamos lapiz (2) para editar un albarán y este tiene un albarán temporal, pero el estado del albarán no es Sin Guardar.
Al aparecer, la advertencia lo que hace es cárganos el albarán, pero no nos permite editarlo, nos aparecería algo asi:
En este caso , al ser un albarán Guardado, tiene fácil solución , pulsando en el albarán temporal, ya nos deja editarlo y guardarlo.
La cuestión es cuando el albarán en vez de estar Guardado, está facturado o procesado, entonces el albarán temporal, ya nos permite guardarlo, nuevamente.
Algo que es correcto.
Esto sucede porque el albarán seguramente lo añadimos a una factura , pero lo dejamos abierta, pero la tenemos eliminada.
En tpvfox se puede relacionar productos entre tiendas, es decir tenemos una tabla que nos indica la relación entre ids de la tienda principal con las tiendas secundarías.
Esta relación se crea automáticamente al crear un producto en la tienda web ,por ejemplo.
El problema surge cuando un producto en la tienda principal, queremos que este relacionado con un producto que ya existe en la tienda web, pues no tenemos ninguna forma a nivel usuario para hacerlo.
Si podemos hacerlo desde la propia base de datos :
- Si ya existe una relación al id de la tienda web, simplemente debemos cambiar idArticulo por el nuevo, queremos.
- Si no existes ninguna relación, pero existe el producto en la web, entonces tenemos que obtener el id de la tienda web y crear un nuevo registro en la tabla articulosTiendas
Ejemplos consulta:
Modificar un indice relacion de un producto:
UPDATE `articulosTiendas` SET `idArticulo`=100 WHERE `idVirtuemart=XXXX and idTienda=2
Con esa instruccion en MariadB , cambiamos la relacion idVirtuemart (XXXX) y del registro de la tienda 2, que normalmente es la tienda web, y lo relacionamos con el producto 100
El mejor lugar para poner un formulario ( pop-up ) para que nos permita poner el id queremos relacionar, es la ficha del producto en el apartado de
En nuestro proyecto TPVFOX versionamos X.Y.Z
Método de crear versiones (tag)
Esto quiere decir que:
X: Fin de una etapa, ya se terminó de implantar de nuevas funcionalidades.
Y: Añadimos alguna funcionalidad o cambios bastante grandes.
Z: Pequeños cambios y pequeñas mejoras. Este número indicar cuantos commit esta por encima de la última versión (pequeños parches), si eres desarrollador y quieres saber que numero de version ver la respuesta a el punto siguiente , donde te explica como obtener cuando commits esta por encima.
¿Cómo sabemos en versión estamos?
De momento saber cuál es la única forma de saber cuál es la versión en la que estamos es a través de un repositorio de Git y desde la terminal poniendo la siguiente instrucción:
git describe
La respuesta es algo así
▶ git describe
v0.3.0-29-g3266211c
v0.3.0 es el tag, la versión que estamos. 29 indica que la rama actual esta 29 commit por encima de ese tag.
En la rama STABLE no debería indicar ningun numero, ya que no es habitual que estemos encima sin tener versionado. En otras ramas, como MASTER si puede estar por encima, ya que son ramas que estan en constante desarrollo.
Versiones de nuestra Base de Datos
Todos sabemos que los cambios en la estructura de la Base datos implica siempre posibles problemas con el código
Como versionamos nuestra Base de datos
En nuestro proyecto TPVFOX cuando realizamos un cambio en la estructura de la base de datos, lo que hacemos es un fichero con los cambios indicando la versión, este fichero se guarda en el directorio BD/Update con el nombre y sufijo de la versión, como indicamos a continuación:
install_update_vX.Y.[Z]
[Z] Estos al igual que al anterior, nos indica cuantos commits estamos por encima de la rama actual. No tiene por qué existir esa versión con esa terminación, pero sí son correlativas.
En estos ficheros puede encontrar las instrucciones SQL para ejecutar y así actualizar tu Base de Datos.
Siempre que hagamos un cambio en la base datos, generamos un fichero install_update_vX.Y.Z que es realmente el commit que vamos a hacer justo después de crearlo.
Cuando vayamos a actualizar un repositorio, simplemente debemos saber en versión estamos y luego actualizar el repositorio, luego solo tenemos que ejecutar los ficheros superiores a la versión que estábamos.
Por ejemplo, si estamos en la versión v0.2.22 del código, si actualizamos hasta la versión v.0.3.30, debemos ejecutar todos los ficheros que hay con las versiones superiores v0.2.22 en el directorio BD/Update, hasta la versión que vamos a actualizar.
Posibles problemas con Base Datos de backup
Nos podemos encontrar con el problema que cuando tenemos un backup de base de datos, ya que no sabemos en qué versión está esa copia. Y tampoco podemos comprobarlo con el código, puesto que realmente no está en funcionamiento y no tenemos repositorio instalado para ese backup.
Por este motivo, creamos este issue en el proyecto, para poder registrar el número de versión en una tabla de configuración, así de esa forma podemos guardar en esa tabla el número versión de la base de datos y luego simplemente tendríamos que actualizar desde esa versión.