Consultas al prestador

Una consulta es el ofrecimiento de un servicio antes de asignarlo. La compañía la publica por API REST, AsistManager la distribuye internamente a uno o varios prestadores, y el resultado se envía al callback configurado para esa compañía.

Un prestador no equivale a un vehículo: puede tener un solo móvil o cien. La compañía consulta a la organización, y la distribución hacia los móviles la resuelve AsistManager.

Existen cuatro formas de consultar, según qué se le pide al prestador que decida: cuánto va a tardar, si acepta una demora ya fijada, cuál de una lista acotada de demoras elige, o cuál de varios turnos con fecha y rango horario prefiere. A cualquiera de las cuatro se le puede sumar el pedido de una cotización.

Sobre esas cuatro está la consulta de cotización, que se marca con el campo kind y pide los tres datos en un mismo formulario: el monto, los kilómetros y la demora estimada.

Una consulta no es una asignación. Para enviar un servicio directamente a un prestador, sin fase de ofrecimiento, se usa el punto de acceso de alta de caso.

Cuando hay más de un prestador que podría tomar el servicio y se quiere que la asignación la resuelva la disponibilidad real, no una decisión previa del operador.

También cuando el dato que falta para asignar es del prestador: cuánto va a demorar, cuánto va a costar, o qué día y en qué franja puede ir. Los servicios de hogar y los programados usan la variante de turnos precisamente por eso.

La compañía no elige el móvil. Publica el ofrecimiento y AsistManager resuelve a quiénes llega, cuándo y en qué orden. Eso permite que la misma integración sirva para un prestador con un vehículo y para una flota de cien, sin que la compañía tenga que conocer esa diferencia.

La política de distribución se configura por compañía y por tipo de servicio. Va desde lo más simple hasta esquemas de varias etapas.

La decisión final admite dos caminos, y la compañía elige cuál usar.

Los ejemplos siguientes muestran el cuerpo de la petición en cada caso. Para no repetirlo, el objeto task se abrevia: va siempre completo, como en el ejemplo de arriba.

Es la forma predeterminada: no se envía ninguno de los campos opcionales. El prestador ve una grilla de demoras y elige una. Esa grilla la define la aplicación, no la compañía: no viaja en el mensaje y no puede configurarse desde el envío. Es la variante mayoritaria en producción.

Con delay distinto de cero, el prestador no elige: ve la demora requerida y solamente puede aceptarla o rechazarla. Se usa cuando el compromiso con el cliente final ya está tomado y no admite negociación.

El prestador elige entre las opciones enviadas y no entre la grilla completa. Los elementos son enteros que representan minutos; el valor especial "condicional" se presenta como una aceptación sujeta a condición y se registra como 300 minutos.

Esta es la variante de los servicios de hogar y de los programados. Tiene precedencia sobre las demás: si se envían turnos y además una lista de demoras, el prestador ve los turnos. Con allow_custom_slot se agrega la posibilidad de proponer una fecha distinta de las ofrecidas.

Se activa con allow_cost_estimate. Habilita en la aplicación un paso adicional donde el prestador carga un precio y, opcionalmente, kilómetros adicionales.

Los campos cost_min y cost_max definen una banda de referencia. El extremo inferior se presenta como valor inicial, de modo que el prestador puede aceptarlo tal cual o modificarlo dentro del rango. No existe una modalidad de precio fijo de solo lectura: la compañía propone una banda, no impone un importe.

Es la forma de consultar que pide los tres datos a la vez: el monto, los kilómetros y la demora estimada. Se marca con kind en "cotizacion", y el prestador los completa en un único formulario.

El monto se acota con cost_min y cost_max, que en esta variante viajan siempre junto con allow_cost_estimate. El prestador responde un valor, en el campo cost.

Los kilómetros se envían en kms como valor preasignado y el prestador puede cambiarlo. Si el campo no se envía, el valor de partida es cero. Admiten decimales, siempre con punto, nunca con coma: un valor con coma se descarta. Vuelven en kms, con lo que el prestador haya dejado.

La demora estimada se ofrece con delay_options, la misma lista de la variante 3. La diferencia es cómo se presenta: acá es un desplegable compacto dentro del formulario, con las etiquetas de siempre (00:15, 00:30, 01:30, Condicional) en lugar de la fila de botones. La opción elegida vuelve en delay.

delay_options es opcional también en una cotización. Si no viaja, el formulario no dibuja la fila de demora y la respuesta llega con delay en cero: la cotización queda reducida al monto y a los kilómetros.

El plazo de la consulta no se extiende por ser una cotización: los 90 segundos incluyen completar el formulario, y son tres campos. Conviene tenerlo en cuenta al elegir a quién se le manda una cotización.

Resuelta la adjudicación, la compañía recibe una petición HTTP en el callback que registró al solicitar el acceso, con el prestador adjudicado y las condiciones acordadas. En un esquema de propuesta múltiple, lo que llega es el resultado del proceso, no cada respuesta individual.

Describe el servicio y es el mismo en la consulta y en el alta de caso. **Se envían todos los campos**, vacíos los que no apliquen: no se omiten.

Las fechas sin valor llevan el centinela 1899-12-30T00:00:00+00:00. Tratarlo como una fecha real produce cálculos absurdos: significa no ocurrió.

AsistManager no valida la entrada de estos endpoints. Una petición mal formada responde con código 200 y un cuerpo breve, sin detalle del problema, de modo que los errores se manifiestan como ausencia de efecto.