--- title: "Tipos de datos especiales | Documentación de Ordering.co" description: "Conserva los nombres de campo y tipos de valor exactos mostrados por el esquema de la operación de destino." canonical: https://docs.ordering.co/es/api-reference/guides/special-data-types/ --- # Tipos de datos especiales Algunos campos de la API de Ordering usan JSON estructurado. Conserva los nombres de campo y tipos de valor exactos mostrados por el esquema de la operación de destino. ## Horarios Los horarios se usan en recursos como negocios, menús y zonas de entrega. Un horario no nulo contiene exactamente siete objetos de día. Cada día tiene un valor booleano `enabled` y un arreglo de `lapses`. ```json [ {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]}, {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]}, {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]}, {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]}, {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]}, {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]}, {"enabled": false, "lapses": []} ] ``` - `open` y `close` contienen campos enteros `hour` y `minute`. - Usa el formato de 24 horas. Las horas van de `0` a `23`, y los minutos de `0` a `59`. - Una hora de apertura no puede ser posterior a su hora de cierre dentro del mismo lapso. - La convención de origen ordena los días de domingo a sábado. El validador actual exige siete entradas y su forma, pero no las etiqueta; conserva el orden exigido por la operación consumidora. ## Productos de pedido La entrada de un producto de un pedido contiene un `id` de producto, `quantity`, `comment` opcional, identificadores de ingredientes y opciones seleccionadas. La forma numérica heredada sigue siendo compatible con el procesamiento actual de pedidos: ```json [ { "id": 1309, "quantity": 1, "comment": "No onions", "ingredients": [10], "options": [ { "id": 53, "suboptions": [174, 175] } ] } ] ``` La forma de objeto agrega `position` y `quantity` para cada subopción: ```json [ { "id": 1309, "quantity": 1, "comment": "No onions", "ingredients": [10], "options": [ { "id": 53, "suboptions": [ { "id": 174, "position": "left", "quantity": 1 } ] } ] } ] ``` Los valores convencionales de `position` para ubicar modificadores son `left`, `right` y `whole`; `whole` también es el valor predeterminado. Estos son valores de uso documentados, no una afirmación de que la API valide `position` mediante un enum. El procesamiento de pedidos conserva una posición distinta de `whole` cuando están habilitados tanto el ajuste de proyecto `advanced_product_options` como el ajuste de la opción superior `with_half_option`. Para una ubicación de mitad, se usa `half_price` de la subopción cuando no es nulo; si es nulo, el backend usa el `price` completo. El precio de mitad se configura, no se calcula como un porcentaje. La `quantity` de la subopción tiene un valor predeterminado de `1` y es independiente de la `quantity` del producto. El ajuste `allow_suboption_quantity` de la opción controla si se pueden usar cantidades de subopción, y los valores `max` configurados pueden limitarlas. La ubicación y la cantidad son distintas; esto no define cómo cuenta una ubicación de mitad para el número de selecciones del grupo. El backend distingue el valor numérico `0` de `null`, pero la interfaz de cliente revisada usa una comprobación de verdad para este precio. No des por hecho que todos los clientes muestran de forma consistente como gratis un precio de mitad en cero. Para el flujo de Website, consulta [Personalizar y agregar un producto](https://docs.ordering.co/es/docs/products/website/browse/customize-product/). Para la configuración, consulta [Configurar opciones de productos](https://docs.ordering.co/es/docs/products/dashboard/stores/create-edit-product/product-options/); para los campos de precio de la subopción, consulta el [modelo de subopción de opción de extra](https://docs.ordering.co/es/api-reference/guides/extra-option-suboption-model/). ## Ubicaciones Las ubicaciones usan latitud y longitud: ```json { "lat": 40.8065, "lng": -73.9536 } ``` ## Polígonos Un polígono es un arreglo de al menos tres ubicaciones distintas: ```json [ {"lat": 40.8065, "lng": -73.9536}, {"lat": 40.8083, "lng": -73.9436}, {"lat": 40.8013, "lng": -73.9375} ] ``` La validación de zona de entrega normaliza `lat` y `lng` a valores numéricos y rechaza polígonos malformados. ## Zonas de entrega basadas en radio El contrato heredado usa el nombre de campo `radio` para el radio. Conserva esa clave literal. ```json { "center": { "lat": 40.8065, "lng": -73.9536 }, "radio": 10 } ``` La documentación de origen describe `radio` en kilómetros. Confirma la unidad en la operación de destino antes de calcular o transformar datos de zona de entrega. ## Datos de cliente Los objetos de cliente pueden incluir campos de identidad, contacto, dirección y ubicación. Usa datos sintéticos en ejemplos y envía solo los campos aceptados por la operación de destino. ```json { "id": -1, "name": "Example", "lastname": "Customer", "email": "customer@example.com", "address": "100 Example Street", "address_notes": "Leave at reception", "zipcode": "10001", "cellphone": "5550100", "phone": "5550101", "location": { "lat": 40.7314, "lng": -73.997 }, "map_data": { "library": "google", "place_id": "example-place-id" } } ``` El contrato histórico usa `id: -1` para un cliente no registrado. Verifica ese comportamiento frente a la operación que acepta el objeto de cliente. ## Datos de mapa `map_data` puede ser `null` o un objeto que contiene el proveedor de mapas y el identificador de lugar: ```json { "library": "google", "place_id": "example-place-id" } ```