Glop TPVEtiquetas Manual para soporte — Julio 2026
En pocas palabras: Glop incluye una plantilla de etiqueta ya preparada para imprimir la tabla nutricional del artículo (grasas, hidratos, proteínas, calorías…). Solo hay que seleccionarla al imprimir etiquetas. Y, como cualquier etiqueta de Glop, se puede modificar en el diseñador para adaptarla al formato que ya use el cliente.
Es una etiqueta de artículo normal (con su descripción, precio, código de barras…) a la que se le ha añadido el bloque de la tabla nutricional por 100 g: valor energético (kJ y kcal), grasas y de las cuales saturadas, hidratos y de los cuales azúcares, fibra, proteínas y sal.
Idea clave: la impresión de etiquetas funciona igual que siempre. Lo único nuevo es que existe una plantilla que ya trae el bloque nutricional montado, lista para usar.
2. Antes de imprimir: el artículo debe tener la información nutricional
La etiqueta imprime lo que el artículo tenga guardado en su pestaña Información nutricional. Si ese artículo no tiene los valores calculados o rellenados, el bloque saldrá vacío o a cero.
Al ir a imprimir etiquetas de artículos, en el selector de plantilla / diseño de etiqueta elige la plantilla nutricional de Glop:
1 Entra en la impresión de etiquetas por artículo como siempre y selecciona los artículos.
2 En la lista de plantillas, elige la etiqueta con información nutricional que suministra Glop.
3Vista previa para comprobar que la tabla se ve bien y Imprimir.
[Captura pendiente: pantalla de impresión de etiquetas con el selector de plantilla y la plantilla nutricional marcada]
4. Adaptarla al estilo del cliente
La plantilla de Glop es un punto de partida. Si el cliente ya tiene un formato de etiqueta propio (su logotipo, su tamaño, su distribución), no hace falta empezar de cero: se abre el diseñador de etiquetas y se coloca el bloque nutricional donde encaje, con el tamaño y la fuente que quiera.
En el diseñador están disponibles estos campos nutricionales del artículo para colocarlos donde se necesite:
Campo
Qué imprime
ENERGIA_KJ / ENERGIA_KCAL
Valor energético en kJ y en kcal
GRASAS / GRASAS_SATURADAS
Grasas y de las cuales saturadas
HIDRATOS / AZUCARES
Hidratos de carbono y de los cuales azúcares
FIBRA
Fibra alimentaria
PROTEINAS
Proteínas
SAL
Sal
Recomendación: parte siempre de una copia de la plantilla de Glop y modifícala, así conservas el original por si quieres volver a él. Todos los valores van por 100 g.
[Captura pendiente: diseñador de etiquetas con el bloque nutricional seleccionado y la lista de campos disponibles]
5. Comprobaciones rápidas
Síntoma
Qué comprobar
La tabla nutricional sale vacía o a cero
El artículo no tiene su información nutricional. Rellénala o recalcúlala en su ficha y vuelve a imprimir.
No aparece la plantilla nutricional en la lista
Asegúrate de estar en la impresión de etiquetas por artículo y de tener cargada la plantilla que suministra Glop.
El bloque no cabe o se corta
Ajusta el tamaño de la etiqueta o del bloque en el diseñador; para etiquetas pequeñas, reduce fuente o deja solo los valores obligatorios.
Glop — Etiquetas: imprimir la información nutricional — Manual para soporte — Julio 2026
Claude CodeTodos los ecosistemas Manual para desarrollo — Julio 2026
Trabajo autónomo con /goal en Claude Code
En pocas palabras:/goal fija una condición de finalización y Claude sigue trabajando solo, turno tras turno, hasta cumplirla — sin que tengas que ir dándole a «continúa». Es ideal para llevar una tarea feature/<KEY> desde el plan hasta dejarla verificada de una sentada. Y como en muchos de nuestros proyectos las pruebas se hacen a mano, este manual explica cómo usarlo sin necesidad de una suite de tests (compilación, grep, diff y checklist), con plantillas listas para copiar por cada ecosistema.
Normalmente, cuando Claude termina un turno te devuelve el control y esperas a que le des la siguiente instrucción. Con /goal cambias eso: defines una condición de finalización y, al acabar cada turno, un modelo pequeño y rápido comprueba si ya se cumple. Si no, Claude arranca otro turno por su cuenta. Cuando la condición se cumple, el objetivo se borra automáticamente.
Idea clave:/goal sirve para trabajo sustancial con un final verificable. Tú describes dónde está la meta, no cada paso para llegar. Claude itera hasta llegar.
Casos típicos en nuestro día a día:
Implementar una tarea hasta que compile y cada criterio de aceptación quede demostrado.
Migrar o refactorizar un módulo hasta que compile y el diff no toque nada fuera de su sitio.
Dividir un fichero gigante (por ejemplo un .pas de miles de líneas) en units enfocadas dentro de un presupuesto de tamaño.
Vaciar un backlog de tickets de una versión, trabajándolos uno a uno hasta que la cola quede vacía.
Requisito:/goal necesita Claude Code v2.1.139 o posterior y un espacio de trabajo de confianza (el evaluador forma parte del sistema de hooks). Si tu versión es anterior, actualiza antes de usarlo.
2. Cómo funciona: la regla de oro del evaluador
Después de cada turno, la condición y la conversación hasta ese momento se envían al modelo pequeño y rápido de tu sesión (por defecto Haiku). Ese evaluador responde sí o no, y añade una breve razón que verás en pantalla y que orienta el siguiente turno de Claude.
Fijas /goal ─► Turno de Claude (trabaja) ─► Evaluador (Haiku) lee el chat
▲ │
│ ¿condición cumplida? │
└────────────── NO ◄─────────────────┤
│ SÍ
▼
Objetivo cumplido ► se borra solo
La regla de oro: el evaluador solo juzga lo que Claude ha escrito en la conversación. No ejecuta comandos ni abre ficheros por su cuenta. Por eso la condición tiene que apoyarse en algo que la propia salida de Claude pueda demostrar: un log de compilación limpio, la salida de un grep, un git status, un curl. Una condición como «el código queda elegante» no es verificable y el objetivo no se cerrará nunca.
Dicho de otro modo: si quieres que el objetivo se cierre cuando «el endpoint exige autenticación», la condición correcta es «php artisan route:list muestra el middleware auth en /auth/users«, porque Claude ejecutará ese comando y su salida quedará en la transcripción para que el evaluador la lea. Fíjate en que ahí no hace falta ningún test automatizado — y eso es justo lo que desarrolla la sección 4.
3. Anatomía de una condición efectiva
Una condición que aguanta muchos turnos sin desviarse suele tener estos cuatro ingredientes:
Ingrediente
Qué es
Ejemplo
Estado final medible
El resultado observable que marca «hecho».
un build sin errores, un grep con 0 coincidencias, una cola vacía, un recuento de líneas
Verificación establecida
Cómo debe probarlo Claude, con un comando concreto.
«el proyecto compila (log pegado)»; «git status solo muestra el módulo X»
Restricciones
Lo que NO debe cambiar por el camino.
«no se tocan otras rutas», «ninguna firma pública cambia»
Límite
Un tope de turnos o tiempo para que no se enganche.
«o detente tras 20 turnos»
La condición puede tener hasta 4.000 caracteres, así que hay sitio de sobra para ser específico.
Condición débil (evítala):«Arregla el módulo de cobros y déjalo bien.»
No hay estado final medible ni verificación: el evaluador no puede saber cuándo parar.
Condición sólida:«GLOP-1170 implementada; el proyecto compila sin warnings nuevos (log pegado), cada criterio de aceptación de JIRA queda mapeado a su fichero:procedimiento, y git status solo muestra units de cobro. Detente tras 20 turnos.»
Estado final + verificación + restricción + límite. El evaluador sabe exactamente qué mirar — y no ha hecho falta un solo test.
4. Cómo verificar sin tests automatizados
En muchos de nuestros proyectos las pruebas se hacen a mano y no hay una suite automatizada. No es un problema para /goal: el comando no necesita «tests», necesita evidencia objetiva escrita en el chat. Un test es solo una forma de generarla; estas son las anclas que puedes usar sin una sola línea de test.
Ancla
Qué demuestra
Cómo pedirla en la condición
Fuerza
Compilación / build
Que el cambio integra y no rompe la construcción.
«compila sin errores ni warnings nuevos, con el log pegado en el chat»
Objetiva
Búsqueda (grep)
Que algo existe, ya no existe o es consistente.
«0 coincidencias de get(url) sin slug, con el grep pegado»
Objetiva
Diff / git status
Que solo se tocó lo previsto.
«git status muestra solo ficheros de app/Cobros«
Objetiva
Comprobación funcional puntual
Que un endpoint o servicio responde como debe.
«curl a /auth/users devuelve 401 sin token, salida pegada»
Objetiva (si se ejecuta)
Checklist contra JIRA
Que cada criterio de aceptación está cubierto.
«lista cada criterio y el fichero:procedimiento que lo resuelve»
Depende del mapeo de Claude
La receta que mejor funciona sin tests:compilación limpia + una segunda ancla objetiva (grep o git status) + checklist de criterios de JIRA. Con las tres, el evaluador tiene señal de sobra para decidir.
No te fíes de la autoevaluación a secas. Si la única «prueba» es que Claude afirme «lo he revisado y está bien», el evaluador se cree esa afirmación optimista. Combina siempre el checklist con una ancla objetiva (compilación o grep); nunca dejes el checklist solo.
El límite honesto: la prueba manual de verdad — abrir el TPV y hacer un cobro con el datáfono — no la puede hacer el evaluador, que solo lee texto. En esas tareas, /goal deja el trabajo hasta «compila + criterios cubiertos + auto-revisado» y la validación final la haces tú antes del PR. Te ahorra el camino, no la prueba final.
5. El flujo recomendado: del ticket al PR
Las tareas os llegan ya definidas (las generamos con la revisión previa y quedan en JIRA). A partir de ahí, el flujo natural con /goal mantiene un punto de control humano entre planificar y ejecutar:
1Explora y planifica. Lanza /explore-plan (o un /goal de planificación) para que produzca un plan que cubra ficheros a tocar, riesgos y criterios de aceptación. Lo revisas tú.
2Implementa con objetivo. Ya con el plan validado, lanzas el /goal de implementación anclado a la verificación de tu proyecto (compilación, grep, checklist). Claude itera hasta dejarlo demostrado.
3Revisa, prueba y entrega. El objetivo se cierra solo; tú revisas el diff, haces la prueba manual que corresponda y de ahí al PR. La responsabilidad del código sigue siendo del dev.
Plantilla — Fase Explorar & Planificar
Aquí la meta no es un test ni un build, sino un plan completo:
/goal Existe un plan de implementación para <KEY> en .claude/sessions/ que cubre: ficheros a tocar, cambios por fichero, riesgos y cada criterio de aceptación de JIRA mapeado a un cambio concreto. Ningún criterio queda sin abordar. Detente tras 10 turnos.
Plantilla — Implementar hasta verificación en verde
/goal <KEY> implementada según su descripción en JIRA. Demuéstralo: (1) <VERIFICACIÓN> (compila / grep / curl, según el proyecto) con la salida pegada; (2) lista cada criterio de aceptación con su fichero:procedimiento; (3) git status solo muestra ficheros de <RUTA>. Detente cuando los tres estén demostrados o tras 20 turnos.
Plantilla — Refactor / dividir un fichero grande
/goal He dividido <FICHERO> en módulos de <800 líneas cada uno. Demuéstralo: pega el conteo de líneas por módulo (todos <800) y el log de compilación limpio. Ninguna firma pública cambia y el comportamiento se mantiene. Detente tras 25 turnos.
Plantilla — Vaciar un backlog de versión
/goal Cada tarea asignada a mí en la versión <X.Y.Z> con estado «To Do» tiene su rama feature/<KEY> con la implementación, compila y sus criterios de aceptación quedan demostrados en el chat. Trabaja una a una y ve reportando cuáles quedan. Detente cuando la cola esté vacía o tras 40 turnos.
Sustituye los placeholders:<KEY> (p. ej. GLOP-1170, APIREST-62, APPGLOP-45), <VERIFICACIÓN> por el ancla de tu ecosistema (tabla de la sección 6), <RUTA> por el directorio del módulo, <FICHERO> por el archivo real.
6. Plantillas por ecosistema (copiar y pegar)
Cada ecosistema tiene sus anclas de verificación. Estas son las que puedes usar sin una suite de tests — ajústalas si tu proyecto tiene otras:
Antes de copiar: confirma los comandos reales de tu proyecto (los de arranque, compilación o lint están en el CLAUDE.md del ecosistema). Los de aquí son los típicos, pero cada proyecto puede tener su propio script.
Central Glop — Delphi / Firebird (Glop TPV)
La verificación fuerte es la compilación limpia, reforzada con el checklist de criterios y git status. Ancla la condición al log de compilación que Claude pegue en el chat.
/goal GLOP-1170 implementada. Demuéstralo en el chat: (1) lista cada criterio de aceptación de la tarea en JIRA con el fichero:procedimiento que lo resuelve; (2) el proyecto compila sin errores ni warnings nuevos (log de compilación pegado); (3) git status muestra solo units de cobro modificadas. Detente cuando los tres estén demostrados o tras 25 turnos.
Dividir una unit enorme (caso muy nuestro, p. ej. ficheros de datos táctil de miles de líneas), verificado por conteo + compilación:
/goal He dividido UdatosTactil.pas en units temáticas de <800 líneas. Demuéstralo: pega el conteo de líneas por unit nueva (todas <800) y el log de compilación limpio. Ninguna firma pública cambia y ninguna funcionalidad cambia de comportamiento. Detente tras 30 turnos.
Web Glop — glop-api-rest / backend (Laravel)
Ejemplo con una tarea real de API sin autenticación, verificado por route:list + curl (sin test automatizado):
/goal APIREST-62 implementada: el endpoint /auth/users exige autenticación. Demuéstralo: pega `php artisan route:list –path=auth/users` mostrando el middleware auth aplicado, y una llamada curl que devuelva 401 sin token y 200 con token válido. No se tocan otras rutas. Detente tras 20 turnos.
Comprobar que una validación queda en su sitio, sin levantar tests:
/goal El FormRequest de la ruta de cobro valida los campos indicados en APIREST-XXX. Demuéstralo: pega el grep del FormRequest con las reglas y `php artisan route:list` mostrando que la ruta lo usa. `php -l` sin errores en los ficheros tocados. Detente tras 20 turnos.
Web Glop — frontend / dashboard (Vue)
/goal GLOP-XXXX implementada; `npm run build` compila y `npm run lint` sale limpio. Lista cada criterio de aceptación de JIRA con el componente que lo resuelve. Ningún fichero fuera de src/views/cobros se modifica. Detente tras 20 turnos.
Migración de convención verificada por grep (recuerda: ApiService nunca hace get(url) sin slug):
/goal No queda ninguna llamada ApiService.get(url) sin slug en src/: ejecuta el grep y pega el resultado (0 coincidencias). `npm run build` compila y `npm run lint` limpio. Ningún otro directorio cambia. Detente tras 25 turnos.
Android Glop — Kotlin
/goal APPGLOP-XXX implementada según su descripción en JIRA; `./gradlew assembleDebug` compila y `./gradlew ktlintCheck` pasa. Lista cada criterio de aceptación de JIRA con la clase/función que lo resuelve. No se modifican módulos fuera de :feature:comandas. Detente tras 20 turnos.
Central Servicios — servicios Windows
Como en Central Glop, la verificación fuerte es la compilación, reforzada con el arranque del servicio en local (que Claude pegue la salida de arranque).
/goal El cambio en servicio-post está implementado; el proyecto compila sin errores (log en el chat) y el servicio arranca correctamente en local (salida de arranque pegada). git status muestra solo ficheros del servicio y no se toca la lógica de conexión con la nube. Detente tras 25 turnos.
WordPress — wooglop y addons (PHP)
/goal La tarea en wooglop está implementada; `php -l` no da errores de sintaxis en los ficheros tocados y `phpcs –standard=WordPress` pasa sin errores. Lista cada criterio de aceptación con el fichero:función que lo resuelve. No se modifican otros plugins del ecosistema. Detente tras 20 turnos.
7. Buenas prácticas y precauciones
Combínalo con el modo automático. Sin él, /goal te seguirá pidiendo permiso en cada edición y no correrá solo. El modo automático aprueba las herramientas dentro del turno; /goal decide si hay otro turno. Juntos es cuando se vuelve realmente autónomo.
Nunca sobre main. Un objetivo autónomo puede tocar muchos ficheros. Trabaja siempre en la rama feature/<KEY> de la tarea, para poder descartar todo con un git reset si el resultado no convence.
Pon siempre un límite. Añade «o detente tras N turnos» a la condición. Sin tope, un objetivo mal medido puede iterar más de la cuenta. Claude reporta el progreso contra ese límite en cada turno.
Ancla a algo objetivo, no a una opinión. «Compila y el grep da 0 coincidencias» es verificable; «el código es correcto» no. Si tu proyecto no tiene tests, apóyate en compilación + grep + git status (sección 4).
Acota el alcance. Las cláusulas «no se toca nada fuera de <RUTA>» y «ninguna firma pública cambia» evitan que el objetivo se expanda y modifique cosas que no tocaba.
Vigila la razón del evaluador. En cada turno se muestra por qué la condición aún no se cumple. Si ves que da vueltas sobre lo mismo, corta con /goal clear y reformula la condición.
8. Referencia rápida de comandos
Comando
Qué hace
/goal <condición>
Fija el objetivo y arranca un turno de inmediato (la condición es la propia directiva). Si ya había uno, lo reemplaza.
/goal
Sin argumentos: muestra el estado — condición, tiempo, turnos evaluados, tokens gastados y la última razón del evaluador.
/goal clear
Cancela el objetivo activo antes de cumplirse. Alias válidos: stop, off, reset, none, cancel.
claude -p "/goal ..."
Modo no interactivo: ejecuta el bucle hasta completarse en una sola invocación. Se corta con Ctrl+C.
--resume / --continue
Restaura un objetivo que seguía activo al cerrar la sesión (se reinician contador de turnos, temporizador y línea base de tokens).
Indicador en pantalla: mientras un objetivo está activo verás ◎ /goal active con el tiempo que lleva corriendo. Iniciar una conversación nueva con /clear también elimina el objetivo.
9. Preguntas frecuentes
No tenemos tests automatizados. ¿Tiene sentido usar /goal?
Sí. /goal no necesita tests, necesita evidencia objetiva en el chat. Ancla la condición a la compilación, a un grep, a git status o a un curl, y refuérzala con el checklist de criterios de JIRA. Lo tienes desarrollado en la sección 4.
¿Consume muchos tokens el evaluador?
No. El evaluador corre en el modelo pequeño y rápido (Haiku por defecto) y su gasto es normalmente insignificante frente al del turno principal. Lo caro es el trabajo, no la comprobación.
¿Va a escribir código sin mi permiso?
Solo si activas el modo automático. Con /goal a secas, cada herramienta que edite ficheros te seguirá pidiendo confirmación; lo que /goal elimina son los «continúa» por turno, no las aprobaciones por herramienta.
¿Cómo lo paro a mitad?
En sesión interactiva, /goal clear. En modo no interactivo (-p), Ctrl+C. Y /clear (nueva conversación) también lo borra.
¿Qué pasa si cierro la sesión con un objetivo a medias?
Si reanudas con --resume o --continue, la condición se restaura (se reinician contadores). Un objetivo ya cumplido o ya borrado no se restaura.
¿Por qué mi objetivo no se cierra nunca?
Casi siempre es una condición no verificable desde el chat: revisa que se apoye en algo cuyo resultado Claude pegue en la conversación (compilación, grep, git status, curl). Mira la razón del evaluador de cada turno para ver qué le falta.
¿En qué se diferencia de /loop o de un Stop hook?
/goal arranca el siguiente turno cuando acaba el anterior y para cuando un modelo confirma la condición. /loop arranca cada intervalo de tiempo. Un Stop hook vive en tu configuración y aplica a todas las sesiones de su ámbito; /goal es un atajo de una sola sesión (por dentro es justo un Stop hook basado en prompt).
Glop — Trabajo autónomo con /goal en Claude Code — Manual para desarrollo — Julio 2026
Partner Agnóstico: localizaciones y pedidos — Glop (Manual para partners)
Api de GlopGlop Cloud Manual para partners — Julio 2026
Partner Agnóstico: enviar tus localizaciones y tus pedidos
En pocas palabras: por cada sitio que gestionas, envías a Glop la lista de sus localizaciones (tus establecimientos, p. ej. «Cafetería María», «Bar Pepito 1») mediante dos llamadas sencillas a la API. El equipo de soporte de Glop conecta cada localización con su terminal, y a partir de ahí ya puedes enviar pedidos. Cuando tu catálogo cambie, vuelves a enviar la lista.
Lee la sección 8 antes de enviar tu primer pedido. El endpoint de pedidos responde 200 OK aunque el pedido no llegue a crearse, y acepta importes o campos mal formados sin protestar. Casi todas las incidencias de puesta en marcha salen de ahí: el formato del pedido no perdona y no avisa.
Dos conceptos clave:
Un sitio es la cuenta en la nube de Glop que soporte da de alta. Tiene una sola credencial (id + secret).
Dentro de un sitio hay una o varias localizaciones: tus establecimientos. Por ejemplo, «Bar Pepito 1» y «Bar Pepito 2» pueden ser dos localizaciones del mismo sitio.
Con la credencial de un sitio envías todas sus localizaciones de una vez.
Antes de empezar, el equipo de soporte de Glop da de alta tu sitio en la nube de Glop y te entrega su credencial. Por cada sitio que gestiones recibirás un único par de valores:
Dato
Para qué sirve
id
Identificador de la credencial de ese sitio.
secret
Clave secreta de ese sitio. Con id + secret obtienes el token para enviar las localizaciones del sitio.
Una credencial por sitio, no por localización: un sitio puede agrupar varias localizaciones (por ejemplo «Bar Pepito 1» y «Bar Pepito 2»), y todas se envían con la misma credencial del sitio. Solo tendrás id/secret distintos si gestionas varios sitios; en ese caso, repite esta guía con la credencial de cada sitio.
Seguridad: el secret es privado. No lo publiques en apps de cliente, webs ni repositorios. Guárdalo en tu servidor y haz las llamadas desde ahí.
2. Cómo funciona, en dos pasos
Todas las llamadas cuelgan de la dirección base https://api.glop.es/api/v1. Para cada sitio, la puesta en marcha se reduce a dos pasos:
1Obtener un token. Con el id y el secret del sitio pides un token de acceso. Es temporal y sirve para autenticar el envío del catálogo.
2Enviar tus localizaciones. Con ese token, mandas la lista de localizaciones del sitio a una URL fija.
Después de eso, soporte conecta cada localización con su terminal (sección 7) y ya puedes empezar a enviar pedidos (sección 8).
3. Paso 1: obtener el token
Haz una petición POST con la credencial del sitio:
Reutiliza el token: dura 15 días (expires_in, en segundos). Guárdalo y reutilizálo hasta que caduque; no pidas uno nuevo en cada envío. Cuando caduque (o recibas un 401), pide otro.
4. Paso 2: enviar tus localizaciones
Envía la lista completa de localizaciones del sitio con el token en la cabecera Authorization:
Glop te responde confirmando cuántas localizaciones ha guardado:
{ «status»: «ok», «count»: 2 }
Nota: puedes usar PUT o POST indistintamente sobre esta misma URL; el resultado es el mismo.
Si una sola localización va mal, no se guarda ninguna: a diferencia del envío de pedidos, este endpoint sí valida. Si a cualquier localización de la lista le falta el id, la respuesta es 422 y se rechaza el lote entero — el catálogo anterior se queda como estaba. Revisa el 422 y reenvía la lista completa corregida.
5. Contenido de cada localización
Campo
Obligatorio
Descripción
id(texto)
Sí
Identificador único de la localización. Debe ser estable (es lo que identifica cada localización entre un envío y el siguiente) y único a nivel global (ver el aviso de abajo). Si falta en alguna localización, se rechaza el lote entero con 422.
nombre(texto)
Recomendado
Nombre del establecimiento (p. ej. «Bar Pepito 1»). Es lo que verá soporte al conectarlo con un terminal, así que ponlo claro.
id_mesa(texto)
No
Solo para integraciones de pedidos en mesa: mesa asociada a la localización. Si tu integración es de pedidos en mesa, acuérdalo con soporte antes de usarlo. Para delivery, omítelo.
El id debe ser único en toda la nube de Glop, no solo en tu sistema. Cuando entra un pedido, Glop busca su location entre las localizaciones de todos los clientes e integradores para saber a qué terminal enviarlo. Un identificador genérico como BARRA, 1 o MADRID puede coincidir con el de otro cliente y tu pedido acabaría en el terminal de un tercero.
Haz esto: prefija todos tus id con algo tuyo e irrepetible — KYTS-CAF-MARIA, KYTS-PEPITO-1.
No hagas esto:1, BARRA, PEPITO-1, CENTRO.
6. Cuándo volver a enviar la lista
Repite el Paso 2 (con un token válido) cada vez que cambie el catálogo de localizaciones de un sitio: das de alta, das de baja o renombras una localización.
Envía siempre la lista completa del sitio: cada envío reemplaza por completo el catálogo anterior de ese sitio por la lista que mandas. Así altas, cambios y bajas quedan sincronizadas automáticamente: lo que dejes de incluir, se elimina. No mandes solo lo que ha cambiado.
Mantén el id estable al renombrar: cambia el nombre pero conserva el mismo id. Si cambias el id, Glop lo tratará como una localización nueva y habrá que volver a conectarla a un terminal.
Reenviar la lista no rompe las conexiones ya hechas: la conexión de cada localización con su terminal se guarda por separado y se conserva entre envíos. Mientras mantengas el mismo id de cada localización, puedes reenviar tu catálogo las veces que quieras sin perder lo que soporte ya haya configurado.
7. Qué hace soporte con lo que envías
Con la lista que has enviado, el equipo de soporte de Glop conecta cada localización con el terminal correspondiente del sitio, usando el id y el nombre que mandaste. Es un paso que hace soporte una vez; tú no tienes que intervenir.
Hasta que soporte no conecte una localización con su terminal, sus pedidos no entran. Y no recibirás ningún error al enviarlos (ver sección 8). Antes de dar por buena tu integración, confirma con soporte que el mapeo está hecho.
8. Enviar un pedido
Una vez soporte ha conectado tus localizaciones a los terminales, ya puedes enviar pedidos. Se envían a un endpoint fijo, y este envío no necesita token:
POST https://api.glop.es/api/v1/delivery/orders
8.1. Antes de nada: la respuesta no confirma nada
Este endpoint responde siempre 200 OK con un cuerpo vacío ([]), tanto si el pedido se ha creado como si se ha descartado. No hay código de error, ni mensaje, ni forma de distinguir el éxito del fallo desde la respuesta. Un 200 significa «te he oído», no «he creado el pedido».
Durante la integración, comprueba en el terminal (o con soporte) que cada pedido de prueba ha entrado de verdad. No te fíes de la respuesta.
Si un pedido no aparece, la causa casi siempre está en 8.2. Repásalas en orden.
8.2. Las cinco reglas que no perdonan
Estas son las causas reales de las incidencias que hemos visto en producción. Las dos primeras hacen que el pedido se pierda; las tres siguientes dejan que entre con datos erróneos, que suele ser peor porque nadie se da cuenta hasta que hay que cuadrar la caja.
1. Un pedido es un objeto, nunca un array — si no, se pierde. Envía { ... }, no [{ ... }]. La API espera un único pedido por llamada. Si lo envuelves en un array, no encuentra el location, descarta el pedido y te responde 200 igualmente. No se admiten lotes: un pedido, una llamada.
2. customer.email: o un email de verdad, o no lo envíes — si no, se pierde. Un valor de relleno sin @ ("-", "", "n/a") provoca un error interno y el pedido no entra.
Lo más seguro es omitir el campo: Glop genera uno solo a partir del teléfono.
Si lo envías, que sea un email real con @.
Da igual lo que mandes: Glop reescribe el email internamente para que cada pedido tenga uno distinto. No te sirve para identificar al cliente.
3. Todos los importes van en CÉNTIMOS, como número entero — si no, se cobra mal. 12,50 € se envía como 1250, no como 12.5. Afecta a payment.amount, al price de cada línea y a deliveryCost, serviceCharge, tip y discountTotal. Si envías decimales, el pedido entra igualmente y se cobra un importe incorrecto: nadie te avisa.
4. Cada línea necesita su plu — si no, entra sin artículo. El plu es el identificador del artículo en Glop. Si falta o va vacío, la línea entra en el terminal sin artículo asociado, sin ningún error.
5. _created y orderIsAlreadyPaid son fáciles de olvidar y salen caros:
Si omites _created, el pedido entra fechado el 01/01/1970.
Si omites orderIsAlreadyPaid, el pedido se marca como PAGADO. Si el cliente paga en el local, envía false explícitamente.
8.3. Ejemplo de referencia
Este es un pedido completo y correcto. Si tienes dudas, copia esta forma:
Fíjate en tres detalles del ejemplo:payment.amount y price valen 1250 (12,50 € en céntimos); no hay customer.email (se omite a propósito); y deliveryAddress es [] porque no hay reparto a domicilio.
8.4. Campos del pedido
Campo
Obligatorio
Descripción
location(texto)
Sí
El mismo id de la localización que enviaste en tu catálogo. Debe coincidir exactamente (mayúsculas y guiones incluidos). Es lo que Glop usa para saber a qué local y terminal entra el pedido.
orderId(texto)
Sí
Tu identificador del pedido. Si no lo envías, Glop genera uno aleatorio y pierdes la trazabilidad con tu sistema.
_created(fecha ISO 8601)
Sí
Fecha y hora del pedido. Si falta, el pedido entra fechado el 01/01/1970.
payment.amount(entero)
Sí
Importe total en céntimos. 12,50 € → 1250.
items(lista)
Sí
Líneas del pedido. Ver 8.5.
orderIsAlreadyPaid(booleano)
Muy recomendado
true si ya está pagado, false si se paga en el local. Si lo omites, se marca como pagado.
channel.slug(texto)
Recomendado
Nombre de tu canal (p. ej. nora). Es lo que se ve como plataforma de origen en el terminal. Si falta, el pedido aparece como deliverect.
customer.name(texto)
Recomendado
Nombre del cliente. Si falta, se usa el nombre del canal.
customer.phoneNumber(texto)
Recomendado
Teléfono del cliente. Si falta, se registra 000000000.
customer.email(texto)
No — mejor omitir
Omítelo, o envía un email real con @. Un valor de relleno sin @ hace que el pedido no entre.
id_mesa(texto)
Solo pedidos en mesa
Si lo envías, el pedido entra como pedido en mesa en esa mesa, no como delivery. Para delivery, omítelo.
deliveryAddress(objeto o [])
No
Dirección de entrega (street, streetNumber, postalCode, city, notes). Envía [] si no hay reparto.
deliveryTime(fecha ISO 8601)
No
Fecha sugerida de entrega. Si falta, se usa la hora actual.
note(texto)
No
Nota del pedido, llega a las observaciones del terminal. Se recorta a 150 caracteres y se le quitan los saltos de línea.
deliveryCost, serviceCharge, tip(enteros)
No
Gastos de envío, servicio y propina, en céntimos. Si suman más de cero, se añaden como una línea «Envío» al pedido.
discountTotal(entero)
No
Descuento total del pedido, en céntimos.
orderType(entero)
No
Tipo de pedido: 1 Pickup, 2 Delivery, 3 Eat in, 4 Curbside pickup.
account(texto)
No
No se usa en esta integración. Envíalo vacío ("") u omítelo.
8.5. Campos de cada línea (items)
Campo
Obligatorio
Descripción
plu(texto)
Sí
Identificador del artículo en Glop. Si falta o va vacío, la línea entra sin artículo.
name(texto)
Sí
Descripción del artículo, tal y como saldrá en el terminal.
quantity(entero)
Sí
Unidades. Si falta, se registra 0.
price(entero)
Sí
Precio de la línea en céntimos. Si falta, se registra 0.
remark(texto)
No
Nota de esa línea (p. ej. «sin cebolla»).
discount(entero)
No
Descuento de la línea, en céntimos.
subItems(lista)
No
Extras, modificadores o artículos de menú. Si vas a usarlos, acúerdalo antes con soporte: el formato del plu de un subitem tiene reglas propias.
8.6. Lista de comprobación antes de tu primer pedido real
1Soporte ha conectado la localización con su terminal. Confírmalo con ellos.
2El pedido es un objeto{ ... }, no un array.
3El location coincide carácter a carácter con un id de tu catálogo.
4Todos los importes son enteros en céntimos. Busca cualquier decimal en tu JSON: si hay un punto, algo va mal.
5No hay customer.email, o el que hay lleva @.
6Están _created y orderIsAlreadyPaid, y cada línea tiene plu.
7Has visto el pedido en el terminal. No des por bueno el 200.
9. Errores frecuentes
Síntoma
Qué comprobar
El token devuelve 401 / invalid_client
Revisa id y secret (que sean los del sitio correcto y sin espacios). Confirma con soporte que el sitio está dado de alta.
El envío de localizaciones devuelve 401
El token ha caducado o falta la cabecera Authorization: Bearer .... Pide un token nuevo (sección 3) y reintenta.
El envío de localizaciones devuelve 422
El cuerpo debe ser { "locations": [ ... ] } con al menos una localización, y todas con su id. Basta que a una le falte para que se rechace el lote entero. Envía Content-Type: application/json.
El pedido responde 200 y no aparece en el terminal
Es lo más habitual, y el 200 no te dice nada. Repásalo en este orden: (1) ¿va envuelto en un array [{...}]? (2) ¿lleva customer.email con un valor sin @? (3) ¿el location coincide exactamente con un id de tu catálogo? (4) ¿ha conectado soporte esa localización con un terminal?
El pedido entra pero con importes erróneos
Los importes van en céntimos como entero: 12,50 € es 1250, no 12.5. Revisa payment.amount y el price de cada línea.
La línea entra sin artículo
Falta el plu de esa línea, o va vacío.
El pedido aparece fechado el 01/01/1970
Falta _created.
El pedido aparece como pagado sin estarlo
Falta orderIsAlreadyPaid. Envía false explícitamente cuando el cliente pague en el local.
El pedido aparece como deliverect y no con tu nombre
Falta channel.slug.
El pedido entra en el terminal de otro cliente
Tu id de localización choca con el de otro integrador. Usa identificadores prefijados con algo tuyo (sección 5) y avisa a soporte.
Los pedidos no llegan al terminal correcto
La conexión localización→terminal la hace soporte. Avísales indicando el id/nombre de la localización afectada.
Soporte: ante cualquier duda sobre la credencial de un sitio, el envío de pedidos o la conexión de las localizaciones con los terminales, contacta con el equipo de soporte de Glop que dio de alta tus sitios. Si un pedido no entra, ten a mano el orderId, el location y el JSON exacto que enviaste: sin eso no se puede diagnosticar.
Glop — Partner Agnóstico: enviar tus localizaciones y tus pedidos — Manual para partners — Julio 2026
En pocas palabras: por cada sitio que gestionas, envías a Glop la lista de sus localizaciones (tus establecimientos, p. ej. «Cafetería María», «Bar Pepito 1», «Bar Pepito 2») mediante dos llamadas sencillas a la API. El equipo de soporte de Glop conecta cada localización con su terminal, y a partir de ahí los pedidos entran solos. Cuando tu catálogo cambie, vuelves a enviar la lista.
Dos conceptos clave:
Un sitio es la cuenta en la nube de Glop que soporte da de alta. Tiene una sola credencial (id + secret).
Dentro de un sitio hay una o varias localizaciones: tus establecimientos, cada uno con su dirección. Por ejemplo, «Bar Pepito 1» y «Bar Pepito 2» pueden ser dos localizaciones del mismo sitio.
Con la credencial de un sitio envías todas sus localizaciones de una vez.
1. Qué necesitas de soporte
Antes de empezar, el equipo de soporte de Glop da de alta tu sitio en la nube de Glop y te entrega su credencial. Por cada sitio que gestiones recibirás un único par de valores:
Dato
Para qué sirve
id
Identificador de la credencial de ese sitio.
secret
Clave secreta de ese sitio. Con id + secret obtienes el token para enviar las localizaciones del sitio.
Una credencial por sitio, no por localización: un sitio puede agrupar varias localizaciones (por ejemplo «Bar Pepito 1» y «Bar Pepito 2»), y todas se envían con la misma credencial del sitio. Solo tendrás id/secret distintos si gestionas varios sitios; en ese caso, repite esta guía con la credencial de cada sitio.
Seguridad: el secret es privado. No lo publiques en apps de cliente, webs ni repositorios. Guárdalo en tu servidor y haz las llamadas desde ahí.
2. Cómo funciona, en dos pasos
Todas las llamadas cuelgan de la dirección base https://api.glop.es/api/v1. Para cada sitio, tu integración se reduce a dos pasos:
1.Obtener un token. Con el id y el secret del sitio pides un token de acceso. Es temporal y sirve para autenticar el envío.
2.Enviar tus localizaciones. Con ese token, mandas la lista de localizaciones del sitio a una URL fija. Eso es todo lo que tienes que hacer.
3. Paso 1: obtener el token
Haz una petición POST con la credencial del sitio:
Reutiliza el token: tiene una caducidad (expires_in, en segundos). Guárdalo y reutilízalo hasta que caduque; no pidas uno nuevo en cada envío. Cuando caduque (o recibas un 401), pide otro.
4. Paso 2: enviar tus localizaciones
Envía la lista completa de localizaciones del sitio con el token en la cabecera Authorization:
Glop te responde confirmando cuántas localizaciones ha guardado:
{ "status": "ok", "count": 3 }
Nota: puedes usar PUT o POST indistintamente sobre esta misma URL; el resultado es el mismo.
5. Contenido de cada localización
Campo
Obligatorio
Descripción
id(texto)
Sí
Identificador único de la localización en tu sistema. Debe ser estable: es lo que identifica cada localización entre un envío y el siguiente. Las localizaciones sin id se descartan.
nombre(texto)
Recomendado
Nombre del establecimiento (p. ej. «Bar Pepito 1»). Es lo que verá soporte al conectarlo con un terminal, así que ponlo claro.
6. Cuándo volver a enviar la lista
Repite el Paso 2 (con un token válido) cada vez que cambie el catálogo de localizaciones de un sitio: das de alta, das de baja o renombras una localización.
Envía siempre la lista completa del sitio: cada envío reemplaza por completo el catálogo anterior de ese sitio por la lista que mandas. Así altas, cambios y bajas quedan sincronizadas automáticamente: lo que dejes de incluir, se elimina. No mandes solo lo que ha cambiado.
Mantén el id estable al renombrar: cambia el nombre pero conserva el mismo id. Si cambias el id, Glop lo tratará como una localización nueva y habrá que volver a conectarla a un terminal.
Reenviar la lista no rompe las conexiones ya hechas: la conexión de cada localización con su terminal se guarda por separado y se conserva entre envíos. Mientras mantengas el mismo id de cada localización, puedes reenviar tu catálogo las veces que quieras sin perder lo que soporte ya haya configurado.
7. Qué hace soporte con lo que envías
Con la lista que has enviado, el equipo de soporte de Glop conecta cada localización con el terminal correspondiente del sitio, usando el id y el nombre que mandaste. Es un paso que hace soporte una vez; tú no tienes que intervenir.
Tu parte es solo enviar las localizaciones. Una vez conectadas a sus terminales, los pedidos de cada localización entran automáticamente por el flujo normal. Para que soporte pueda identificarlas sin dudas, usa id estables y nombre descriptivos.
8. Errores frecuentes
Síntoma
Qué comprobar
El token devuelve 401 / invalid_client
Revisa id y secret (que sean los del sitio correcto y sin espacios). Confirma con soporte que el sitio está dado de alta.
El envío devuelve 401 Unauthorized
El token ha caducado o falta la cabecera Authorization: Bearer .... Pide un token nuevo (Paso 1) y reintenta.
El envío devuelve 422
El cuerpo debe ser { "locations": [ ... ] } con al menos una localización, y cada una con su id. Envía Content-Type: application/json.
El count es menor de lo esperado
Se descartaron localizaciones sin id. Revisa que todas lo lleven.
Los pedidos no llegan al terminal correcto
La conexión localización→terminal la hace soporte. Avísales indicando el id/nombre de la localización afectada.
Soporte: ante cualquier duda sobre la credencial de un sitio o sobre la conexión de las localizaciones con los terminales, contacta con el equipo de soporte de Glop que dio de alta tus sitios.
Este documento ayuda a Soporte Técnico de Glop a entender y explicar, de forma sencilla, cómo se ven las imágenes en el modo Kiosko, por qué a veces aparecen pixeladas y qué debe hacer el usuario para que se vean correctamente.
Mensaje clave (lo más importante)
Si una pantalla en modo Kiosko se carga con las imágenes de la BBDD demo, esas imágenes son de 100×100 px.
Como el Kiosko las muestra mucho más grandes, siempre se verán pixeladas.
Solución: el usuario debe cargar sus propias imágenes con un tamaño recomendado de 900×900 px para que se vean nítidas.
Regla rápida:
100×100 → OK para miniaturas, mal en Kiosko
900×900 → recomendado para Kiosko
¿Por qué se ven pixeladas?
Una imagen de 100×100 tiene muy pocos píxeles. Cuando el Kiosko necesita mostrarla en un recuadro grande, el sistema “estira” esos píxeles y el resultado es el típico efecto de cuadraditos (pixelado).
Lo importante es que:
Si la imagen que está guardada es pequeña, no se puede “mejorar” mágicamente al mostrarla.
Para que se vea bien, hace falta reemplazarla por otra de mayor tamaño.
Cuándo suele pasar
Caso 1: Kiosko con BBDD demo
El cliente está probando el Kiosko con datos demo.
Las imágenes demo son de 100×100.
Resultado: pixelado esperado.
✅ Respuesta de soporte: “Es normal con la demo. Para verlas bien, hay que cargar imágenes propias a 900×900.”
Caso 2: El cliente usaba TPV y añade Kiosko después
El cliente ya tenía artículos/grupos creados con imágenes antiguas.
Esas imágenes se guardaron en tamaño pequeño.
Al activar Kiosko, las imágenes antiguas se ven pixeladas.
✅ Respuesta de soporte: “Hay que volver a cargar las imágenes de esos artículos/grupos con tamaño 900×900.”
Solución (lo que debe hacer el usuario)
Solución rápida
Identificar qué artículos o familias se ven pixelados en el Kiosko.
Ir a su mantenimiento (Backoffice/gestión) y reemplazar la imagen.
Usar imágenes cuadradas (o casi) de 900×900 px.
Guardar cambios y comprobar en el Kiosko.
Si el cliente no tiene imágenes preparadas, puede empezar con cualquier imagen de buena calidad y luego ir mejorándolas. Lo importante es que no sean 100×100.
Recomendaciones de imagen (para que quede bien)
Tamaño recomendado:900×900 px
Formato recomendado: JPG
Orientación: preferible cuadrada
Calidad: que se vea nítida en el ordenador antes de subirla
Peso orientativo: cuanto más ligera mejor, pero sin perder calidad (por ejemplo, entre 100 KB y 500 KB suele ir bien)
Consejos prácticos:
Si la imagen tiene fondo blanco y el Kiosko también, puede “desaparecer”. En ese caso, mejor un fondo con algo de contraste.
Evitar capturas borrosas de WhatsApp o imágenes con zoom.
Checklist para Soporte (pasos de diagnóstico)
Cuando un cliente diga “se ven pixeladas”:
¿Está usando BBDD demo?
Sí → explicar que las demo son 100×100 y que es normal.
¿Cuándo cargó las imágenes?
“Hace tiempo, antes de usar Kiosko” → probablemente quedaron pequeñas y hay que recargarlas.
¿En qué se ve pixelado?
Artículos
Grupos de venta
Ambos
Confirmar la solución:
Pedir que suba imágenes propias a 900×900 y revisar de nuevo.
Preguntas frecuentes (FAQ)
“¿No se puede arreglar sin cambiar las imágenes?”
No. Si la imagen guardada es de 100×100, el Kiosko solo puede ampliarla, y eso siempre genera pixelado. Hay que reemplazarla por una imagen más grande.
“He activado el Kiosko, ¿se actualizan las imágenes antiguas?”
No automáticamente. Las imágenes que ya estaban guardadas siguen igual. Hay que recargarlas.
“¿Con qué tamaño se recomienda subirlas?”
900×900 px. Máximo. Si el la pantalla del usuario es suficiente con tamaños de 600×600 es mejora debido a que se mejora la carga de ellas en la pantalla.
“¿Qué pasa si subo una más grande que 900×900?”
El sistema lo redimensiona a 900×900
Mensaje tipo para enviar al cliente
Puedes copiar/pegar esto:
En modo Kiosko, las imágenes se muestran grandes. Si estás usando la BBDD demo, las imágenes son de 100×100 px y por eso se verán pixeladas. Para que se vean bien, te recomendamos subir tus propias imágenes en 900×900 px (JPG o PNG). Una vez reemplazadas, la visualización en Kiosko queda nítida.
Resumen final
Pixelado en demo: normal (imágenes 100×100).
Pixelado en un cliente real: suele deberse a imágenes antiguas pequeñas.
Solución: reemplazar por imágenes propias 900×900.
La aplicación está diseñada para gestionar el reparto de pedidos, por lo que cada usuario que la utilice será uno de los repartidores de la empresa. Esta aplicación ofrece varias vistas accesibles, entre ellas la vista principal, donde seleccionaremos qué repartidor somos, y la vista de pedidos, la más importante, que permite realizar diversas acciones como ver el detalle del pedido, llamar al cliente, y más.
La aplicación genera rutas óptimas utilizando Google Maps a partir de las direcciones asociadas a cada pedido. Los pedidos en la lista se organizan por la hora de creación, aunque el repartidor tiene la opción de reorganizarlos según sus necesidades, modificando así la ruta dependiendo de las paradas que deba realizar. De este modo, al abrir Google Maps desde la aplicación de repartidores, las paradas estarán organizadas de acuerdo con el orden establecido en la lista de pedidos.
Comprobaciones Previas
¿Requiere licencia de módulo?
Necesitaremos una licencia con Delivery para poder hacer uso
¿Qué tipo de licencia usa la integración?
Las posibles licencias son GL y GB.
Otros requisitos
Un teléfono Android y conexión a la misma red wifi que el TPV Glop
CONFIGURACIÓN DE LA APP
En Glop deberemos acceder a Menú > Configuración > Terminales, y en la ventanita que se nos abre, deberemos acceder al terminal que queremos usar en cuestión pulsando en el botón modificar y teniendo este seleccionado:
Una vez habiendo accedido, nos tendremos que situar en el apartado ficha, y acceder al subapartado módulos, en el cual veremos otro subapartado para esta sección, en este subapartado nos moveremos nuevamente hasta la opción Glop Delivery, en la cual veremos lo siguiente:
Aquí, como podemos ver hay una opción que dice “Activar servicio a domicilio para android”, pues bien, esta es la que tenemos que activar, pero para ello, antes deberemos pulsar en modificar para poder editar este apartado, y posteriormente pulsar en la casilla para marcar que sí queremos esta opción activa, por tanto deberemos pulsar al botón Modificar:
Posteriormente a haber hecho esto, el propìo programa de escritorio de Glop nos indicará que debemos reiniciarlo, por tanto, lo cerraremos y lo volveremos a abrir:
Video:
Ahora pasamos a la aplicación androd. Teniendo Glop de escritorio abierto en nuestro ordenador, abrimos la aplicación, y una vez abierta, en nuestro programa Glop de escritorio nos aparecerá la siguiente notificación:
Nos está indicando que un dispositivo, como el que vemos en el ejemplo, se quiere conectar a nuestro servicio, por lo tanto, aceptaremos indicando en el botón Sí, y de esta forma ya tendremos el dispositivo enlazado con Glop y podremos usarlo para los repartidores que tengamos.
Creación de Repartidores
Aunque el dispositivo ya esté enlazado con nuestro Glop de escritorio, todavía nos falta una parte fundamental, sin esta parte podemos acceder a la aplicación.
Es necesario crear repartidores dentro de la configuración de Glop de escritorio, ya que al ser una aplicación de repartidores, para poder acceder primero deberá estar dado de alta dentro de Glop.
Para realizar estos ajustes, lo que deberemos hacer será, dentro de la aplicación de escritorio de Glop, acceder al Menú > Ventas > Delivery > Repartidores, aquí veremos que, si no hemos creado aún ningún repartidor, estará vacío:
Ahora procederemos a crear un repartidor, para ello, lo que deberemos hacer será clicar en el botón que pone Nuevo y un símbolo de suma dentro de un círculo de color verde, como podemos ver en la barra inferior de la ventana, una vez habiendo pulsado aquí, se nos abrirá la pestaña Ficha automáticamente y veremos lo siguiente:
Aquí simplemente rellenaremos los campos para crear el Repartidor. Una vez rellenados los datos pulsaremos aceptar para que se guarde.
Al volver a la pestaña Lista, veremos que tenemos los repartidores ya creados:
Una vez hecho todo esto, ya solo nos faltaría acceder a la aplicación de repartidores desde el dispositivo en el que la hemos instalado, y enlazado a Glop, y ver que los repartidores nos aparecen tal y como los hemos creado. También veremos que nos aparecen los pedidos a repartir, asignados para cada uno de los repartidores.
Creación de Zonas de Reparto
Antes de poder asignar los pedidos a un repartidor ya creado, deberemos crear antes las zonas de reparto a las cuales se van a enviar los pedidos.
Para ello lo que haremos será acceder al Menú > Ventas > Delivery > Zonas de Reparto, y aquí veremos lo siguiente:
Para crear una zona nueva de reparto lo que haremos será de nuevo y como en el anterior caso clicar en el botón que pone Nuevo en la barra inferior, y se nos abrirá la siguiente pestaña:
Aquí indicaremos los parámetros que más nos interesen para la zona de reparto, principalmente lo que te deberemos hacer será indicar la Descripción, que será el nombre de la zona. El código no es necesario indicarlo puesto que es automático.
Configuración de la zona de reparto
Docuemento: tipo de documento que deseamos generar en esta zona, puede ser factura o factura simplificada
Tarifa: seleccionar tarifa por defecto de la zona de reparto
Forma de pago: seleccionar la forma de pago por defecto de la zona de reparto
Parámetros de la zona:
Solicitar fecha y hora al aparcar: al aparcar un pedido en esta zona nos solicitará la fecha y hora de entrega de este, podremos añadir comentarios, con que pagará y destacar el pedido.
Imprimir en zona de pedido en hora de preparacion: no imprimirá el pedido hasta que llegue la hora establecida
Zona para “Recoger”: establece esta zona como una zona de pedidos que son para recoger en el local y no para llevar a domicilio
Si tenemos una zona a domicilio y otra para recojer cuando creemos un pedido nos preguntará el tipo de pedido:
Una vez tengamos la zona completada con la información que nos interese, clicamos en el botón Aceptar de la barra inferior, y se guardará la zona de reparto.
En la siguiente imagen veremos las zonas de reparto de nuevo, pero con los cambios aplicados, y con la nueva zona que ya podremos usar para crear pedidos:
Creación de Clientes
Para crear clientes nuevos lo que haremos será acceder a Menú > Ventas > Clientes, y nos aparecerá la siguiente ventana:
Lo que haremos aquí será lo mismo que en los anteriores casos, le clicamos al botón Nuevo de la barra inferior, y nos aparece la siguiente pestaña:
La rellenaremos con la información que creamos conveniente dentro de todos los parámetros rellenables de esta ventana, por ejemplo:
Además, deberemos también entrar en el apartado direcciones que vemos arriba en la barra de secciones, esto lo deberemos hacer una vez tengamos ya todos los datos del cliente añadidos, ya que automáticamente si hemos especificado en los datos generales una dirección, ésta se almacenará en este apartado.
Aunque la dirección se guarde automáticamente por comodidad, tenemos que editarla para indicar la zona de reparto en la cual va a estar asignado este cliente, esta opción es la última que veremos en el apartado de direcciones. La razón por la cual tenemos que especificarla es porque podemos tener más de una zona de reparto, por lo tanto es el único parámetro que no se pone automáticamente por defecto en este apartado, y además hemos de saber que si el cliente no tiene una zona de reparto asignada, posteriormente al crear un pedido para llevar para el mismo, este pedido no nos aparecerá en ninguna zona de reparto de las que nosotros hayamos creado. La zona de reparto la asignaremos de la siguiente forma:
Una vez realizado esto, lo que haremos será clicar en Aceptar en la barra inferior de la ventana, y a éste cliente nuevo lo tendremos ya identificado en la lista de clientes, como podremos ver en la siguiente imagen:
Creación y Asignación de Pedidos a Repartidor
Una vez ya hemos conseguido realizar todos los pasos anteriores, lo último que queda es acceder al TPV (Punto de Venta), en este realizamos pedidos para la zona de reparto creada anteriormente, y para los clientes que tengamos, además de que asignaremos dichos pedidos a alguno de nuestros repartidores para indicar que ese pedido debe ser entregado por dicho repartidor.
Creación de pedido para una zona de reparto
Vayamos paso por paso, para hacer todo esto, lo primero que deberemos hacer es acceder al TPV, como se ha dicho antes, y esto lo haremos estando en la ventana principal de Glop para escritorio, clicando en el botón que está en la esquina inferior izquierda de color naranja en el cual pone <Acceso a TPV>
Vamos a elegir la zona de reparto, esto se encuentra en la barra lateral derecha de la ventana. Aquí veremos varias opciones, la que seleccionaremos será la que tiene el nombre de la zona de reparto que hemos creado:
Esta ventana se encuentra vacía por el momento (si no hay pedidos), ya que posteriormente, cuando creemos un pedido para esta zona de reparto veremos los pedidos en esta misma sección.
Por el momento, lo que a nosotros nos interesa son las opciones de la barra inferior, concretamente por el momento la primera de todas ellas empezando por la izquierda. Es un botón que contiene el nombre de <Nuevo Pedido>.
Clicamos en esta, y se nos volverá a enviar al TPV, donde se nos abrirá una pequeña ventana que nos indica que seleccionemos el cliente para el cual va asociado el pedido nuevo.
La ventana tiene este aspecto:
Nosotros en este caso seleccionaremos el cliente que hemos creado en el anterior caso de ejemplo, Hector. Para ello, lo que haremos será clicar sobre este, y podemos clicar y posteriormente clicar en el botón seleccionar cuando tengamos elegido el cliente que queremos, o doble clic sobre el cliente.
Posteriormente, seleccionaremos los productos que queremos enviar a dicho cliente mediante el clic sobre los mismos.
Como ejemplo, así se vería el resumen del ticket que estamos creando para el nuevo pedido:
Para tramitar este pedido, lo que haremos será pulsar el botón Aparcar que nos aparece al lado del resumen del ticket, es el botón más grande que hay en la pantalla:
Al hacer esto, el pedido estará ya disponible volviendo a entrar en nuestra zona de reparto.
Si lo deseamos, podemos volver a entrar en dicho pedido para editarlo realizando doble clic en el mismo.
Asignar Pedido a Repartidor y Repartir
Lo siguiente que toca hacer es indicar cual va a ser el repartidor que va a repartir dicho pedido.
Esto lo haremos mediante el acceso a la zona de reparto, y en la barra inferior de botones de esta sección, pulsando en Asignar Repartidor:
Una vez habiendo hecho esto, nos aparecerá una ventana pequeña para seleccionar el repartidor que se va a asignar al pedido:
De modo que elegiremos el repartidor que nos interese en el momento, y una vez hecho esto, en el ticket del pedido nos aparecerá el nombre del repartidor que hemos elegido (se puede cambiar repitiendo el proceso de selección de repartidor):
Finalmente, lo único que nos queda por hacer es repartir los pedidos, y esto es lo más sencillo que vamos a hacer, ya que solo tenemos que pulsar un clic en un botón y este proceso se realizará automáticamente.
Este botón del que estamos hablando recibe el nombre de Repartir Pedidos, y está en la barra inferior de botones de la sección de la zona de reparto, concretamente al lado del botón de Asignar Repartidor, como veremos en la siguiente imagen:
Una vez realizada esta acción, el pedido se repartirá para el repartidor asignado, el cual podrá acceder a este desde la aplicación de repartidores, como veremos en los siguientes apartados de esta documentación.
GUÍA DE USO DE LA APP
Vistas Principales de la App
Vista Repartidores
Esta vista es la que se carga nada más iniciar la aplicación.
En ella veremos que tenemos una lista con los repartidores dados de alta, cada uno de los repartidores que contiene la lista se puede seleccionar y poder ver los pedidos que se le han asignado para poder empezar a repartir.
Esta vista además, contiene un botón con un símbolo de flecha circular, el cual hace referencia al reinicio de la lista, por tanto, con este, una vez habiendo pulsado, refrescamos la información que contiene la lista, para así poder ver si hay nuevos repartidores, o si por el contrario se ha quitado alguno. Finalmente, al clicar en uno de los repartidores, accederemos a su lista de pedidos a repartir asociada.
COMPROBACIONES AL INICIAR LA APP
Comprobación de versión. Si la versión de la APP no coincide con la versión de Glop, nos avisará para descargar la versión de la APP acorde a la versión de Glop instalada.
Conexión con Glop. Al iniciar la app, comprueba la conexión con Glop, si es la primera vez que iniciamos, nos aparecerá que debemos aceptar la conexión con Glop. Si no la aceptamos, no nos volverá a preguntar y ese dispositivo no se podra conectar hasta que desde configuracioes -terminales – modulos – app repartidores eliminemos el registro.
Vista Pedidos
Esta vista contiene la información necesaria acerca de todos los pedidos que se le han asociado a un repartidor, en ella podemos apreciar una lista de pedidos, los cuales tienen una interfaz propia con distintas funcionalidades, que vamos a explicar posteriormente. A continuación, se puede apreciar una imagen de ejemplo para ver la pantalla tal y como es:
Barra Superior de la Ventana (AppBar)
Disponemos de un botón con el símbolo de encendido y apagado, nos servirá para cerrar sesión con el repartidor actual, y por tanto, volver a la vista de selección del repartidor.
El siguiente botón tiene forma de flecha en zigzag, con dos cabezas, y hace referencia a las rutas que se van a tener que tomar para llevar a cabo el reparto de todos los pedidos asociados al repartidor.
Este botón nos abre directamente el Google Maps con nuestra ubicación exacta actual, y las paradas necesarias que se tendrán que llevar a cabo por el repartidor para llegar a cada dirección siempre y cuando estemos en la sección de pedidos no entregados.
Hemos de saber que si no tenemos conexión a Internet, o la cobertura es muy baja y por ende no nos permite el acceso a la red, la aplicación no nos permitirá acceder a Google Maps, indicándonos esto con un diálogo de alerta, en el cual nos indica mediante un mensaje cual es el problema, como veremos a continuación:
Por otro lado, si alguna de las direcciones que hay en la lista de pedidos no entregados es incorrecta, o ilegible por Google Maps, se nos hará saber mediante dos diálogos, uno de alerta con un mensaje informativo que indica cual es el problema, y otro que nos mostrará solamente aquellas direcciones que sean erróneas, permitiéndonos con ello cambiarlas todas, estos mensajes de aviso se ven de esta forma:
Si pulsamos <ACEPTAR>, todas aquellas direcciones que hayamos cambiado serán editadas solamente hasta el momento que se acceda a Google Maps, después se establecerán las iniciales con el fin de no perder posibles datos importantes.
Si alguna dirección sigue siendo incorrecta, el diálogo no parará de aparecer hasta que todas sean correctas.
Si pulsamos <CANCELAR> se cerrará el diálogo sin realizar cambios en las direcciones editadas en el momento.
Vamos con el último botón de la barra superior de la aplicación, este contiene el símbolo de tres puntos. Este es un desplegable que contiene el filtrado de los pedidos según si han sido entregados, o no, al igual que podemos seleccionar la opción de que se vean todos los pedidos, sin importar si han sido entregados o no.
Menú Lateral de Opciones Seleccionables
Vamos a comenzar a explicar opciones que nos ofrece el menú lateral
Pulsaremos en la opción <Recibir Pedidos>, la cual nos permitirá recibir los pedidos que estén asociados a este repartidor para poder visualizarlos en pantalla, y así recibir la información necesaria para llevar a cabo su reparto.
Posteriormente, accediendo de nuevo al mismo menú lateral, nos encontraremos con la sección de pedidos <No Entregados>, en esta, encontraremos todos los pedidos los cuales todavía no se han entregado.
Otro de los apartados es la sección de pedidos <Entregados>, en esta, encontraremos todos los pedidos los cuales se han entregado.
Por otro lado, en el menú lateral tenemos la opción de <Información Pago>, en la cual encontraremos toda la información referente a los pagos de todos los pedidos realizados y ya entregados. Aquí podemos ver la forma de pago de cada pedido.
Finalmente, en este menú lateral podemos encontrar la opción <Ruta de todos los pedidos>, en la cual como su nombre indica, se nos mostrará mediante Google Maps la ubicación actual del repartidor, y las paradas que tiene que realizar para poder llegar a todas las direcciones de los pedidos y así repartirlos.
Lista de Pedidos
Ahora vamos a volver a situarnos en el punto de recepción de los pedidos. Después de haber recibido todos los pedidos pendientes de entregar, vamos a realizar algunos ajustes en nuestra lista de pedidos. Podemos arrastrar cada pedido hacia la posición en la lista que queramos dependiendo de cómo nos interese más el orden de reparto de los mismos.
En este caso, como solo hay dos pedidos, vamos a realizar el ejemplo de arrastrar el primer pedido debajo del segundo, esta acción la vamos a poder realizar mediante el uso de un botón el cual contiene un símbolo con 6 cuadrados en línea, este lo podremos encontrar en cada pedido de la lista.
Este botón lo encontraremos justamente al lado del nombre de la calle de destino para este pedido. Con él podemos arrastrar los pedidos a la posición que queramos, como hemos dicho antes.
Una vez habiendo dicho esto, es hora de arrastrar el pedido debajo del segundo, y como podremos ver, el orden de los pedidos habrá cambiado:
Ahora bien, si quisiéramos volver al orden inicial, no tendríamos la necesidad de volver a arrastrar todos los pedidos a la posición que estos tenían ya que hay un botón flotante en la parte superior derecha, este tiene fondo naranja por completo, y contiene 3 líneas, las cuales van menguando una detrás de otra.
Este botón nos permite filtrar de nuevo por la hora de realización del pedido, por lo tanto, si queremos volver al orden inicial (ordenado por hora por defecto) pulsaremos este, y los pedidos volverán a estar como estaban desde un principio:
Después de haber organizado la lista como a nosotros más nos interese, tenemos a parte algunas funcionalidades en cada pedido de la lista, como llamar al cliente, acceder a la dirección asociada del pedido concreto, y más.
Vamos a hablar de la primera, poder llamar al cliente. Esta función es muy simple, hay que pulsar al botón que tiene un símbolo en forma de teléfono con una flecha indicando hacia la derecha, y automáticamente se nos abrirá el marcador de números de teléfono de nuestro móvil con el número del cliente asociado al pedido concreto:
Ahora hablaremos de la opción dentro del pedido que nos permite acceder a Google Maps y ver cual es la dirección asociada a este, y la ruta que tendría que tomar el repartidor para llegar solamente a este destino.
Este botón tiene el típico símbolo de la lágrima del revés con un puntito blanco en el centro, este nos indica que nos permite ver la dirección del pedido, como he dicho antes. Para poder realizar esta acción, simplemente tendremos que pulsar en el botón del que estamos hablando, y directamente se nos redireccionará a Google Maps, el cual recogerá la dirección actual en la que el repartidor se encuentra (mediante la ubicación que marca su dispositivo móvil), y la dirección del pedido, para así poder calcular la ruta o rutas más óptimas para llegar hasta el destino:
Posteriormente, podemos ver que a la misma altura de estos dos últimos botones tenemos otro que es un poco más grande, que tiene un símbolo en forma de bolsa con un símbolo de correcto en su interior.
Este botón nos permite indicar si un pedido ha sido entregado o no, y al pulsarlo, nos aparecerá un diálogo, en el cual nos hacen la pregunta de cómo queremos pagar. En este diálogo podemos ver que hay varias opciones seleccionables, nosotros nos quedaremos con la que el cliente haya indicado que quiere pagar.
Posteriormente, en el mismo diálogo podemos ver que hay otros dos botones, uno que pone <CANCELAR> y otro que pone <ACEPTAR>, si le damos a cancelar no se realizará ninguna acción, y se nos devolverá a la lista de pedidos no entregados. Por otro lado, si pulsamos aceptar, este pedido se marcará como entregado, por lo tanto ya podremos acceder a la sección antes comentada (tanto desde el filtro de búsqueda, como en el menú lateral) en la cual podemos ver los pedidos entregados, y a la sección de información de los pagos de los pedidos, también antes comentada (desde el menú lateral antes explicado), puesto que al realizar esta acción ya hemos especificado la forma de pago para este pedido concreto:
Finalmente, para la lista de pedidos tenemos un último botón que se encuentra en la esquina superior derecha el cual tiene un símbolo en forma de ojo. Este botón nos servirá para poder acceder a la vista del detalle del pedido concreto, en la cual se detalla el pedido que se ha realizado, y qué contiene el mismo.
Para realizar esta acción simplemente se pulsará en el botón del que estamos hablando, y directamente la aplicación nos redireccionará a la vista del detalle, la cual vamos a explicar en el siguiente apartado de la guía.
Vista Detalle de Pedido
A esta vista se accede pulsando al botón de detalle dentro de cada pedido de la lista de pedidos, tanto en la sección de pedidos no entregados, como entregados.
Esta vista contiene básicamente la información del cliente, la forma de pago que se va a realizar, y una lista de los productos que ha añadido el cliente a su pedido, además de contener los botones de llamada y visualización de ruta (anteriormente explicados):
En el aspecto de los botones, como se ha dicho antes tenemos el de llamada, y el de ruta, los cuales hacen la misma función que los que se han explicado anteriormente; abrir el marcador de teléfono del móvil con el teléfono del cliente ya marcado, y abrir el Google Maps con la dirección actual del repartidor exacta, junto con la dirección asociada al pedido para calcular las posibles rutas hasta llegar a este.
Vista Entregados
A esta vista podremos acceder desde el menú lateral de la vista de pedidos, o desde el desplegable para filtrar entre entregados, no entregados o todos, de la misma vista.
Esta vista contiene exactamente lo mismo que la vista de pedidos principal, ya que es la misma, pero siendo filtrada solo por pedidos entregados concretamente, y por tanto, contiene también una lista de pedidos, los cuales tienen las mismas funcionalidades que en la vista de pedidos original (llamar, ruta, etc…).
Las dos únicas diferencias que podemos ver respecto a la otra vista son que el color de los botones ha cambiado a verde en vez de naranja, y que el botón de entregar pedido ya no tiene la funcionalidad de entregar pedido, ni tampoco el mismo símbolo como tal.
Esto se debe a que este botón ahora ha adquirido la funcionalidad de mover a no entregado, para poder hacer que el pedido en cuestión vuelva a la lista de no entregados y que el repartidor pueda visualizarlo para saber que este no ha sido entregado todavía.
Al pulsar este botón, nos aparecerá un diálogo en el cual nos preguntan si queremos realmente mover el pedido a no entregados, y nosotros tendremos que pulsar <ACEPTAR> si realmente queremos esto, o <CANCELAR> si no queremos realizar cambio alguno:
Vista Todos
A esta vista solo podremos acceder desde el desplegable que filtra por entregados, no entregados, y todos.
En esta vista tenemos las mismas funcionalidades que en la de pedidos original, aquí los datos se nos dan sin importar este estado de pedido:
Como podemos ver, tenemos tanto el pedido no entregado, como el entregado anteriormente. Cada uno tiene las mismas funcionalidades, excepto el botón de entregar, como se ha explicado antes.
Vista Información Pago
A la cual podremos acceder solamente desde el menú lateral de la vista de pedidos (en general).
En esta tenemos una lista de los pagos que se han realizado asociados todos y cada uno de ellos a su respectivo pedido, además de indicar la forma en la cual se ha pagado, como podremos ver a continuación:
En este caso, solo hay un ítem en la lista ya que solo hemos entregado un pedido.
Como podemos ver, está indicado el número del pedido, y el tipo de pago.
Por otro lado, si nos fijamos, en la barra superior de la vista tenemos un botón que contiene un símbolo en forma de avión de papel. Este botón nos va a permitir enviar la información de todos los pagos que se han realizado y que se ven reflejados en la lista de estos. Para hacer este envío es necesario estar en la misma red que Glop y con el TPV en funcionamiento, de lo contrario no permitirá realizar el envio.
Al pulsar el botón veremos que se nos abre un diálogo el cual nos hace la pregunta de si realmente queremos enviar toda la información de los pagos, si le damos a <ACEPTAR>, la lista se vaciará de información de pagos, en cambio, si le damos a <CANCELAR> todo se quedará como estaba y el diálogo desaparecerá:
ARQUEO DE PEDIDOS DESDE GLOP UNA VEZ SE HA ENVIADO LA INFORMACIÓN DE PAGO
Una vez enviada la información de pago, debemos acudir a Glop para realizar el arqueo de esos pedidos. Desde la zona de reparto accederemos a Arqueo Pedidos en la barra inferior.
Tras esto nos preguntará sobre que repartidor queremos realizar los arqueos, seleccionaremos el repartidor y nos aparecerá la siguiente pantalla:
Sobre esta pantalla podremos ver todos los pedidos pendientes de arquear (con la forma de pago recibida desde la aplicación), seleccionaremos los que deseamos arquear y pulsaremos en arquer pedidos. Con esto tendremos finalizado el ciclo del pedido.
En el caso de que no tenga forma de pago o se la queramos cambiar podemos pulsar sobre asignar forma de pago y si queremos imprimir el documento sobre imprimir doc.
VIDEO CICLO COMPLETO
ASPECTOS A TENER EN CUENTA
Para poder realizar ciertas acciones, tales como recibir los pedidos, o enviar la información de pago de los mismos, deberemos estar conectados a Internet, y estar exactamente en el mismo establecimiento en el que se encuentra el terminal con la aplicación de escritorio de Glop, de lo contrario nos saltará una advertencia indicando que no hay conexión a la red o con el servidor.
Es MUY importante tener en cuenta que al inicio de la aplicación en el caso de no tener la versión actualizada de la App y no haberse aceptado la conexión con el dispositivo desde Glop, los mensajes informativos nos aparecerán en un orden de prioridades, primero el mensaje de versión para descargar la última, y posteriormente, si tiene que aparecer, el que nos indica que la conexión a sido negada o rechazada.
En el caso de querer acceder a la opción ruta/rutas, debemos saber que si no hay conexión a Internet o tenemos una mala cobertura, no se nos permitirá acceder a Google Maps, indicándose con un mensaje de alerta el motivo.
Si las direcciones de los pedidos son erróneas o ilegibles por Google Maps, antes de acceder a este se nos indicará mediante un diálogo que hay direcciones incorrectas, y posteriormente se nos abrirá un diálogo alternativo que nos permite ver, y editar solo las direcciones incorrectas. Cabe destacar que si una vez habiendo pulsado <ACEPTAR> en este diálogo sigue habiendo alguna dirección incorrecta, se repetirá el mismo proceso, hasta que las direcciones sean correctas, entonces podremos acceder a Google Maps.
Las direcciones que se hayan editado, tanto individual, como grupalmente, desaparecerán una vez habiendo accedido a la función de Google Maps desde la aplicación repartidores o una vez habiendo recibido de nuevo los pedidos. Esto se ha realizado así para poder mantener las direcciones iniciales de los pedidos y de esta forma, si hay necesidad de volver a editar una dirección por cualquier tipo de fallo de escritura o equivocación, tengamos una guía o referencia pudiendo ver la dirección principal del pedido.
La aplicación de gestión de reparto permite a los usuarios ser repartidores, ofreciendo vistas como la de pedidos y la principal, donde se elige el repartidor y se organizan las rutas con Google Maps.
La configuración de la aplicación requiere una licencia con Delivery, un teléfono Android y conexión a la misma red wifi que el TPV Glop.
Es necesario crear repartidores en la configuración de Glop de escritorio para poder acceder a la aplicación de repartidores.
Antes de asignar pedidos a repartidores, es crucial crear zonas de reparto en la aplicación.
Para crear clientes, es necesario acceder a Menú > Ventas > Clientes y asignarles una zona de reparto para poder crear pedidos para ellos.
En la vista de pedidos, se pueden organizar, llamar a clientes, ver direcciones en Google Maps y marcar pedidos como entregados, con opciones de filtrado y funcionalidades detalladas.
