Gestión transporte, base de datos y facturación.

Buenos días,

Somos una empresa de transporte por carretera de contenedores llamada TRANSPASSAR, S.A. Hacemos viajes de exportación e importación a los puertos de Alicante, Cartagena y Valencia. Necesitamos un programa que nos pueda facilitar la organización del tráfico y a su vez, la generación de facturas y una base de datos.

Cabe decir que ya tenemos un programa con el cual generamos órdenes de una en una, que luego son enviadas a una base de datos. Desde ese mismo programa y con la información de la base de datos, podemos generar facturas para los autónomos y para los clientes. De todos modos, el programa que tenemos requiere de la introducción manual una a una de órdenes de transporte, cosa que en caso de tener muchos viajes nos consumiría mucho tiempo e induce a errores.
Es por eso que proponemos un nuevo programa que nos permita integrar la organización del tráfico con la asignación de órdenes, la generación de la base de datos y las facturas de la manera más automatizada posible. Así, reduciríamos los pasos ordenador-trabajador-ordenador que llevan a horas de trabajo mecánicas, errores y que en caso de crecer y tener más transportes acabaría colapsando.


funciones basicas aplicables:

consideraciones iniciales

-ya disponemos de un servidor web.

-Usar el lenguaje de programación que permita una mayor flexibilidad a la hora de modificar/añadir funcionalidades al programa, incluyendo su relación con la app que también queremos.


modulo facturación y base de datos.

-Página web (preferiblemente, para poder trabajar de forma remota o desde cualquier PC)/ programa, en el que podamos trabajar todos en la oficina simultáneamente. Por usuario. En esta plataforma  poder realizar partes de trabajo (Si está interesado, por favor, entrad en contacto para poder adjuntar ejemplo) (en forma de tabla tipo Excel) y que todo el mundo vea lo que hacen los otros (tipo google drive).


-Es ideal que sea una página web o programa que trabaje con datos en la nube o servidor/es para proteger lo máximo posible esta información de ser borrada o perdida por un corte en la luz, por ejemplo.

-Sería óptimo que ciertas casillas para rellenar información no fueran de formato libre. Sino que se requiriera de registrar una serie de opciones. Por ejemplo: los cargadores/fabricas estaría bien registrarlos con su dirección y distancia al puerto de vlc, alc y cartagena (vlc como puerto predeterminado, especificar para alc y cartagena).
Con opción a añadir y modificar cargadores fácilmente. La intención es que esta información escrita en el parte de trabajo, vaya directamente a la base de datos, con la que se generarán facturas. Por tanto en la factura tendrán que aparecer los KM realizados en el servicio.


-Otro ejemplo sería los números de contenedor: sólo puede haber 4 letras 6 números y un dígito. Como se registran los cargadores, registrar también suplementos de servicio: puntos de carga extra, pesaje VGM, mercancía peligrosa, etc... Según cada cliente habrá un precio. No hace falta asociar un suplemento de servicio con un cliente y un precio, ya que las tarifas varían. Con guardar un tipo de suplemento, e introducir nosotros manualmente el precio nos bastaría.


-De hecho, lo ideal sería que el parte de trabajo se autocompletara con la información que proviene del programa SintraPortV2. No sabemos si se podría hacer un nexo entre los programas, o si se podría hacer en base a exportar (formatos PDF, Excel, csv, html, etc..) La información del SintraportV2 y luego importarla a la web/programa. Lo ideal sería que los programas se comunicaran de alguna manera ya que en el SintraportV2 se va actualizando la información.

-Por tanto, si se pudiera rellenar el parte de trabajo con la información del SintraPortV2. Y de ahí nosotros, añadir lo que falte al parte de trabajo sería ideal (recalcamos esto como prioridad a la hora del desarrollo del programa/web). Transmitir los precintos y el número de contenedor directamente desde el SintraportV2 nos ahorraría de tiempo y errores, ya que lo que está puesto en el SintraportV2 ha de ser correcto.


-En el SintraportV2 hay órdenes que tendrán toda la información necesaria para rellenar el parte de trabajo. Pero también hay transitarios que no ponen toda la información. Por eso estaría bien poder rellenar información carente cuando sea necesario.


-Una herramienta, que cuando detecte que ya ha entrado al parte de trabajo el nº contenedor y precinto, permita un fácil envío por correo electrónico de esta información al cliente que nos ha dado esa orden. Una vez enviado el correo, que quede marcado como que ese contenedor y precinto ya los tiene (o han sido enviados) el cliente. Se nos ocurren futuras funcionalidades a la hora de relacionar el programa/web/parte de trabajo con el correo electrónico (que es por donde nos entran las órdenes de transporte.


-Que se pueda ver el registro de actividad reciente (último día/8horas) de cada usuario. Así, se puede saber quién ha escrito x precinto (por ejemplo), o mirar lo último que ha escrito/modificado/borrado el usuario PAU, por ejemplo.

-Una vez termina el día, y se marca que todos los Nº de contendor y precinto han sido enviados a los respectivos clientes, la información de cada fila (transporte) se guarda en la base de datos de manera automática (o pidiendo un mensaje de confirmación tipo: ¿Estás seguro de que quieres guardar los viajes del parte del dia/mes/año? guardar/modificar/salir(¿estás seguro de que quieres salir sin guardar?(si/no)).

-Programa asociado con la base de datos (o el mismo programa) para generar facturas a partir de la base de datos. Opciones para generar facturas por cliente, autónomo, semana y mes. En la factura (para el cliente) se muestra la/s fabrica/s donde se ha hecho el viaje, los KM de cada viaje y el importe.
Flexibilidad a la hora de generar un tipo de factura u otra según el cliente (algunos requieren de número de orden y referencia de carga). Por ahora en cuanto a los precios, preferimos introducirlos manualmente. (Que se presente la/s orden/es, rellenamos precios y se generen facturas).


-Opción a “tachar” o descartar (aunque se guarden en otro lugar) las facturas ya generadas.  Me refiero a algo que evite generar o enviar facturas dos veces al mismo cliente, por ejemplo, por error. Algo que nos indique que facturas ya hemos hecho y cuáles no.


-De hecho, desde el módulo de tráfico, en el parte de trabajo tenemos todos los datos del viaje, qué transportista/chófer lo está haciendo, y qué cliente nos lo ha pedido. Así a la hora de generar factura, si seleccionamos generar facturas para el chófer Alberto, podrían salir todos los viajes que ha hecho Alberto en esa semana/periodo de tiempo.  Lo mismo para los clientes.


modulo tráfico

lo que está escrito en cursiva, son funcionalidades que depende del coste de su desarrollo, podemos prescindir por el momento. Por eso pediríamos un presupuesto a parte para el programa con estas funcionalidades ‘extras’. no se puede observar la cursiva (estaba escrito en word) básicamente es todo lo de calcular el tiempo medio de carga y tiempo en tardar a llegar a un lugar, explicado a continuación.
lo mas básico que requerimos de este modulo es el mapa con la ubicación de la flota y la generación de órdenes en base a la información del parte de trabajo.

-Aplicación que acceda al GPS del móvil de los chóferes. Para poder tener un mapa donde se vea la localización de todos los camiones a tiempo real, con un identificador. Configurar google maps u otras aplicaciones en el móvil de todos los chófers va a ser complicado, por su conocimiento medio de tecnología (tendríamos que instalársela nosotros a la mayoría de los chófers cuando se pasaran por la oficina).
Es por eso que es importante que esta app sea fácilmente instalable.

-Se podría usar esta aplicación para transmitir las órdenes de transporte a los chófers. Generar, igualmente órdenes de transporte a partir del parte de trabajo. Toda la información necesaria para generar las órdenes de transporte se encuentra en el parte de trabajo: Documentos sic (generados por sintraport), fecha y hora, tipo de contenedor, naviera, dirección de carga/descarga y teléfono, referencia de carga, pesaje vgm (verified gross mass), y precinto (a quien pedirlo; tendríamos que escribirlo a la hora de enviar la orden).
Depende del coste de esto, podríamos simplemente generar las órdenes desde el parte de trabajo y enviarlas por email o whatsapp.

-A partir del movimiento del dispositivo que se calcule en qué dirección se mueve el camión. (Indicar con una flecha o algo así). 

-Opción de asignar a un chófer/camión/dispositivo un viaje (viaje como fila del parte de trabajo).
Así desde el mapa se podría saber qué transporte está haciendo ese camión/chófer. La idea es que la información del parte de trabajo se pueda integrar con la de los dispositivos/chófers lo máximo posible, tanto para enviar ordenes como saber que viaje está haciendo cada uno y otras posibles funcionalidades futuras.

-Una vez asignado, cuando el chófer tenga el contenedor cargado, nos pasará el número de contenedor y precinto, una vez apuntado (o transmitido desde el SintraPortV2) se puede decir que el camión está cargado dirección a la fábrica/cargador. Sabiendo el destino, ubicación y velocidad media se podría calcular el tiempo aproximado (como google maps) que tardará en llegar. El criterio por el cual considerar que un camión/chofer tiene un transporte asignado o cargado se tiene que discutir.


-Una vez el camión se encuentre a un rango más o menos cercano a la fábrica y que esté parado un tiempo X=10/15min, considerar que el camión ha llegado. Aquí se puede empezar a contar tiempo de carga (o descarga en caso de import) cuando el dispositivo se aleje de la fábrica un rango X, se considera que ya está cargado.  Se para de medir el tiempo de carga y se almacena en una base de datos (que nos servirá al cabo del tiempo para tener una información aproximada del tiempo de carga medio en cada fabrica).


        -Con estos tiempos de carga aproximados medios y la ubicación de la fábrica y del camión, se podrá calcular al cabo del tiempo,  el tiempo aproximado que le queda a un chofer desde que carga el contendor (que nos da nº contenedor y precinto), hasta que lo devuelve a la respectiva base/terminal. Para mejorar la aproximación, que el cálculo se rehaga a medida que va cambiando la ubicación del dispositivo.

-Así, cuando entre alguien en la oficina (después de comer, o cuando empiece su turno) podrá fácilmente explorar y saber dónde se encuentran los camiones/chófers. Además clickando sobre el camión/chofer se podrá saber qué transporte está haciendo y a que altura del mismo se encuentra.

CONCLUSIONES

Por tanto para la empresa habría dos pantallas principales en el módulo de tráfico: Una con el mapa y la localización de la flota (con opción a detalles pinchando X camión). Y otra pantalla con la lista de camiones, detalles de sus transportes asignados (explicado en el modulo de facturacion y base de datos) ubicación  y tiempo medio aproximado que tardará en llegar a la fábrica/ en llegar a descargar el contenedor(finalizar el viaje si ya ha cargado) y el tiempo total para acabar el transporte (depende de en qué punto del viaje se encuentre, si acaba de cargar, sería la suma de los dos tiempos anteriores más el tiempo medio de carga en la fábrica. Todo esto facilitará mucho la organización del tráfico, pese a cualquier inconveniente fuera del programa que pueda aparecer.
Incluso si hay una avería o cualquier otro inconveniente (no le dejan entrar al puerto, retención, horas extra a la hora de cargar, etc…) que se pudiera apuntar en forma de etiqueta sobre el camión afectado, para tenerlo en cuenta.

Por ahora, lo que requerimos principalmente es lo mencionado en el módulo de facturación, parte de trabajo y base de datos. En cuanto al módulo de tráfico lo que más necesitamos es el mapa con la ubicación de los chófers/dispositivos. Que se pueda saber que viaje está haciendo cada chófer y los cálculos de velocidad es más secundario.
Dependiendo del coste de esto último podríamos prescindir de esa funcionalidad, y añadirla en el futuro.
La idea sería integrar lo máximo posible el módulo de facturación con el módulo de tráfico a través del parte de trabajo. En base a los viajes que apuntemos en el parte de trabajo, que estos se asignen a los chófers. Que podamos tener un parte de trabajo para el dia=x+1 y x+2 (incluso más días de antelación) para ir apuntando las ordenes que recibimos.

Por tanto hay aún muchas cosas por concretar y hablar. Por eso digo que el programa sea lo máximo flexible posible. Por ejemplo, nos envían una orden para un día, que de repente unas horas antes de empezar el transporte nos la anulan o la cambian de fecha y hora, esa flexibilidad debería reflejarse en el programa.
Es por eso que con esta presentación solo buscamos una orientación inicial a la hora de ver qué tipo de programador necesitamos y el coste del desarrollo. Una vez iniciada la relación con el progamador nos gustaría tener un feedback constante, que se convierta en una buena relación programador-empresa. No queremos un servicio puntual que luego no nos permita añadir funcionalidades y relacionarnos con el/los desarrolladores.