Todas las nuevas 贸rdenes de trabajo se introducen por primera vez dentro del sistema en estado de planificaci贸n, a menos que se informe expl铆citamente de que ya est谩n produci茅ndose en una c茅lula. (v4.2.0)
En el momento de importar datos es importante hacerlo de forma parcial, para un optimo rendimiento y obtener una respuesta en un periodo razonable. El sistema por cada of realiza una serie de comprobaciones y c谩lculos antes la inserci贸n en base de datos.
v7.14.0 : Comprobaci贸n por hash de cada orden de trabajo y su hoja de ruta para prevenir importar 贸rdenes de trabajo sin cambios y mejorar la velocidad del proceso.
Por ello se recomienda no realizar env铆os con bloques demasiado grandes de datos.
As铆 mismo se recomienda no enviar todos los registros cada vez, intentar importar 煤nicamente los registros que hayan tenido cambios durante la jornada, para evitar sobrecargar el sistema con informaci贸n redundante que ya existe.
Tambi茅n hay que evitar importar los registros finalizados desde hace tiempo. Las ofs terminadas hay que enviarlas en algun momento para que epolca las marque como finalizadas, por lo tanto se recomienda limitar la importaci贸n de ofs terminadas en las 煤ltimas 24/48h. Pero una vez pasado ese tiempo, no hace enviarlas m谩s.
Hay que intentar que no se solapen las importaciones con las simulaciones autom谩ticas. Ya que los dos procesos trabajan sobre los mismos registros y proboca bloqueos e incoherencia de datos, no tiene sentido modificar los datos del sistema mientras se est谩 intentando simularlos.
Por ejemplo, si las simulaciones se han configurado para hacerlas cada hora, hay que evitar realizar las importaciones a la hora en punto.
Para evitar este bloqueo si en el momento de enviar datos en sincronizaci贸n el sistema detecta que hay una simulaci贸n en curso, cancelar谩 la simulaci贸n para poder hacer correctamente la importaci贸n. Al terminar la importaci贸n, si el sistema detecta que ha tenido que cancelar una simulaci贸n, volver谩 a ejecutar otra simulaci贸n. En cambio si se han sincronizado sin tener que cancelar nada, al terminar la sincronizaci贸n no realizar谩 simulaci贸n.
La api de importaci贸n define varios atributos de definici贸n de ofs, entre ellos existe el erp_item_code en la definici贸n de pasos de la hoja de ruta. Este campo es el identificador 煤nico de paso en la hoja de ruta, no es un campo obligatorio, pero si altamente recomendable.
脡ste campo est谩 destinado a identificar cada paso para permitir a帽adir o eliminar pasos en sincronizaciones posteriores a la creaci贸n inicial de la of. Si no se define, o no se utiliza este campo, en el momento que el erp elimine o cree un nuevo paso y lo quiera actualizar en epolca a trav茅s de la sincronizaci贸n, el sistema no podr谩 identificar correctamente la fase y dejar谩 una hoja de ruta inocherente.
Si el ERP en la siguiente actualizaci贸n dice que la misma OF est谩 en otro estado:
Casos en que la of contin煤e en planificaci贸n, que el usuario no la haya pasado a producci贸n desde ePolca:
Casos en que la of haya sido pasada a producci贸n desde ePolca
Por defecto ePolca no calcula el tiempo restante en las ofs que se informan como que estan en proceso. Por ello se espera que cada vez que se sincronizan datos desde el ERP en el campo time_left se informe del valor correcto del tiempo que queda de fabricaci贸n. Inicialmente ese tiempo debe ser la suma del tiempo de preparaci贸n m谩s el tiempo de fabricaci贸n, pero una vez el paso se pone en marcha (estado 5) el campo time_left deber铆a ir reduciendo su tiempo en cada sincronizaci贸n que se haga.
Siendo el funcionamiento descrito el establecido por defecto, ePolca ofrece dos funcionamientos alternativos
Si se desea que ePolca calcule el tiempo restante en un paso en fabricaci贸n, para ello se debe informar en el paso del campo working_at con el valor de la marca de tiempo del momento en que ese paso se ha puesto a fabricar. El formato debe de ser fecha y hora (YYYY-MM-DD HH:mm:ss)
Si en el momento de sincronizaci贸n el sistema detecta en una c茅lula en proceso que el campo working_at est谩 informado, autom谩ticamente ignorar谩 el campo time_left informado por el ERP y calcular谩 el tiempo transcurrido entre la marca de tiempo y el momento de la sincronizaci贸n, y restar谩 ese tiempo al time_left almacenado en la base de datos, asignando as铆 un nuevo time_left al paso en curso.
Referencia: M贸dulo de tiempo restante
ePolca ofrece a partir de su versi贸n 7.7.0 un nuevo funcionamiento activable desde la configuraci贸n el cual permite configurar ePolca para que reste el tiempo restante a todas las ofs que hay en producci贸n cada periodo de tiempo.
As铆 pues de forma independiente a las sincronizaciones, mientras se detecte que que una of est谩 en estado de producci贸n (estado 5) este proceso ir谩 descontando tiempo periodicamente.
Esta configuraci贸n invalida los tiempos informados por el ERP. Una vez se introduzcan por primera vez en el sistema ePolca, ya no se podr谩n volver a actualizar, ya que los ir谩 actualizando el propio ePolca
ePolca permite sincronizar datos existentes de un sistema ERP del cliente. Para ello ofrece una API desarrollada bajo el est谩ndar API Rest.
La documentaci贸n de la api se ha desarrollado bajo el estandar OpenAPI 3. Puede encontrar dicha Documentaci贸n en el siguiente enlace:
https://epolca.innovait.cat/api/redoc
ePolca permite sincronizar peri贸dicamente las ofs desde el ERP del cliente a trav茅s de consultas a una API del propio cliente.
La respuesta a esa petici贸n debe ser con estructura id茅ntica a la definida en la documentaci贸n de la API, de igual forma como si el cliente enviara los datos a ePolca, pero con la diferencia de que en vez de mandarlo su ERP, ePolca se lo consulta cada x tiempo configurable en la secci贸n de Admin/Configurci贸n
Para realizar la integraci贸n desde ePolca, el cliente debe suministrar al equipo t茅cnico de ePolca los siguientes datos:
En caso de autenticaci贸n, segun sea necesario tambi茅n deberan de informar de los siguientes campos:
Toda of entrante en el sistema o actualizada que se informe que est谩 en un paso en producci贸n, debe tener obligatoriamente una m谩quina asignada. Si el ERP del cliente no puede facilitar esa informaci贸n se podr谩 configurar epolca a trav茅s de las opciones del configurador de m贸dulos la posibilidad de que sea ePolca el que asigne una m谩quina de manera aleatoria a la of en producci贸n.
Esta asignaci贸n autom谩tica a帽ade una capa de control que valida que no se puedan definir m谩s ofs en producci贸n que m谩quinas hay disponibles en una misma c茅lula. As铆 pues en el momento que se detecte que una of est谩 informando de un paso en producci贸n en una fase que ya tiene todas sus m谩quinas asignadas, el sistema devolver谩 error y cancelar谩 toda la importaci贸n.
Cuando se hace una importaci贸n a medida, esta se lanza cada vez que se solicita una simulaci贸n nueva. Si durante el proceso de importaci贸n y actualizaci贸n de ofs alguna de ellas no cumple con las comprobaciones de integridad del sistema, es proceso se interrumpe y no se contin煤an sincronizando ni se realizar谩 la simulaci贸n.
Se ha a帽adido a partir de la versi贸n v7.9.2 un check de sincornizaci贸n en la administraci贸n de la aplicaci贸n que permite saltarse esta restricci贸n, de manera que aunque se detecte que una of tiene un fallo de integridad, esta of se omitir谩 y continuar谩 con las siguientes y el proceso de simulaci贸n.
Aclarar que en el caso de tener esta configuraci贸n la estimaci贸n de simulaci贸n no ser谩 real, ya que no tendr谩 todos los datos actualizados debido al fallo que ha omitido.
El sistema devuelve error 503 en algunos casos cuando se intenta hacer una petici贸n por API pero el servidor la rechaza por estar ocupado en otros procesos.
Este error se produce en las siguientes peticiones:
En cada una de estas peticiones el sistema comprueba:
A excepci贸n de la petici贸n 2 y de la petici贸n 3 que no comprueban si hay simulaci贸n en marcha, ya que esas peticiones gestionan ese estado de otra manera. Todas las dem谩s peticiones hacen todas las comprobaciones y si alguna da positivo es en ese momento que devuelve la respuesta 503 de sistema ocupado.
Para el caso de la simulaci贸n y sincronizaci贸n, ePolca muestra en la barra inferior de la pantalla 3 puntitos que indican que hay un proceso en marcha y que no se admiten nuevas peticiones.
Para el caso de trabajos pendientes de procesarse, en integridad del sistema hay un check que indica si hay algo pendiente, y en caso de que est茅 atascado se puede forzar su ejecuci贸n desde la secci贸n de Admin > Acciones > Procesa modificaciones pendientes bloqueadas por simulaci贸n