Ya lo he comentado en otras ocasiones. Creo que en general, explotamos poco la capacidad que nos brinda PHPRunner con AnyChart, más cuando la licencia de AnyChart que nos habilita la adquisición de PHPRunner es completa, incluyendo el soporte por el fabricante.

También, como he comentado, la integración que hace PHPRunner de AnyChart es muy fácil de usar, creo que está hecha para que los principiantes del producto sean capaces de explotar varias de sus características, pero que hay un “mundo que inspeccionar y mostrar” usando este producto.

Para ampliar la capacidad de usar AnyChart por parte de PHPRunner he realizado un plugin y definido un método de trabajo que hace, desde mi punto de vista, muy sencillo su utilización y sobre todo, poder utilizar de forma muy sencilla, toda la documentación que dispone AnyChart en su portal y aplicarlo directamente a nuestros proyectos.

Así pues, este proyecto que os muestro y os facilito, tiene por objetivo:

• Crear múltiples gráficos, todos ellos realizado con el nuevo plugin.
• Crear gráficos que hubiera sido imposible su realización con la integración estándar de PHPRunner.
• Combinar los gráficos en páginas “Dashboard”, para mostrar la potencialidad de PHPRunner para hacer “Cuadros de Mando”.
• Utilizar un mapa temático, producto AnyMap, que también nos ofrece la licencia del producto.

Para hacer el ejemplo he utilizado los datos que dispongo de las Elecciones de la Comunidad de Madrid. Para los no españoles. España se divide en 17 Comunidades autónomas y éstas tienen una o más provincias. Las provincias se dividen en unidades administrativas que son los Municipios. Estos Municipios se dividen a su vez en Distritos.

Toda la información y el ejemplo en el artículo

He recibido consultas de cómo resolver la gestión de reservas de habitaciones en un hotel o toldos en una playa.

En general, esta problemática de gestión de las reservas (diarias y no por horas) de un artículo (habitación, coche, moto, barco, vivienda, etc.) es muy habitual, por ello he desarrollado este ejemplo (y no aplicación) para que os pueda ayudar a desarrollar un sistema que tenga esta problemática.

Requisitos funcionales

He previsto que el ejemplo contemple los siguientes requisitos funcionales.

• Se dispone de un inventario de productos (en este caso habitaciones) para reservar. Dicho inventario integra las características de las habitaciones.
• En la Base de datos, se almacenan las fechas en las que las habitaciones están reservadas.
• Asociada a la reserva, se relaciona, además de la habitación y las fechas, los datos del Cliente.
• Se tiene que facilitar un calendario donde queden reflejadas todas las reservas.
• Para buscar la disponibilidad de una habitación o para realizar una nueva reserva, existirá un formulario donde se describa las características de la habitación que se busca y las fechas que se desean. El sistema indicará las habitaciones disponibles según los criterios y un calendario de las ocupaciones de estas habitaciones, con el fin de que se ajusten las reservas y no se dejen huecos sin  que las habitaciones queden reservadas (optimización de los recursos).
• El sistema se diseña para que se use por personal del Hotel, aunque disponga de posibilidades para extender el ejemplo y habilitarlo para el público en general.

Para obtener la información completa y los códigos, acceda al artículo.

En la situación actual de pandemia mundial, casi todas las empresas y servicios públicos han tenido que recurrir a una gestión de citas para mantener la distancia social entre las personas.

Este ejemplo es un posible sistema de gestión de Cita Previa o al menos, así lo he querido identificar yo.

El ejemplo más sencillo es pensar en las necesidades de los servicios médicos, aunque he intentado que pudiera ser válido para cualquier otra necesidad.

Requisitos funcionales

Cuando he estado pensando qué es lo que una empresa requiere para esta gestión, he definido:

• He creado un “Objeto de negocio”, que le he llamado “Reserva”, que es la unidad a la que vamos a asociar los huecos de la gestión de citas. Este “Objeto”, puede ser un Médico, un Servicio Médico, una Unidad de Registro, un Agente bancario, etc., cualquier Objeto que requiera una lista de personas a las que atender.
• Estas “Reservas” estarán asociadas a 2 niveles de agrupación. En el sistema he asociado “Compañía” y “Departamento”, pero podría ser cualquier otra estructura.
• El registro de “Reserva” tiene que tener los datos que se requieran para establecer los huecos del calendario de la Cita Previa.
• El análisis de huecos disponibles debe ser muy fácil de identificar y gestionar, con posibilidad de que se pueda facilitar en un sistema de autogestión (que el usuario solicite la fecha y hora de cita). Se debe ofrecer la posibilidad de solicitar fecha de cita para cualquier día y hora de las disponibles.
• También, el sistema debe ofrecer listas o conteos, de os huecos o citas que se han cerrado a la fecha que se requiera.

Todo el detalle  y código, en el siguiente artículo.