Política de campos del pedido
Este artículo tiene como objetivo explicar la Política de campos del pedido de Demander.
Sobre la Política de campos del pedido
Sección titulada «Sobre la Política de campos del pedido»La Política de campos del pedido permite controlar el comportamiento de los campos del pedido según el contexto comercial (por ejemplo: vendedor, cliente, tipo de pedido, etc.).
Para cada campo compatible, es posible definir:
- Visibilidad (mostrar/ocultar).
- Obligatoriedad (exigir llenado).
- Bloqueo (mostrar sin permitir modificación).
- Filtro de opciones (permitir/bloquear valores).
- Selección automática de valor (cuando corresponda).
Alcance y objetivo
Sección titulada «Alcance y objetivo»El objetivo es atender escenarios donde la empresa necesita limitar el uso y/o las opciones de campos del pedido por contexto (por ejemplo: un contexto puede ver un campo con lista filtrada, otro puede exigir llenado, otro puede ocultar el campo).
La solución fue diseñada de forma extensible: se pueden agregar nuevos campos manteniendo el mismo contrato del jsonRegras y sin remodelación de base de datos. Para consultar qué campos están disponibles actualmente, consulte la sección Campos compatibles y ejemplos.
Campos de configuración
Sección titulada «Campos de configuración»La configuración de la política involucra campos de identificación, filtros de contexto y el JSON de reglas. Esta sección se basa en los campos previstos en la integración de la tabla 280 - PoliticaCamposPedido.
Identificación y estado
Sección titulada «Identificación y estado»- codigo: identifica la política en el contexto del cliente.
- descricao: descripción de la política.
- ativo: define si la política se puede aplicar (0 = inactivo, 1 = activo).
- prioridade: criterio de desempate entre políticas aplicables (menor valor indica mayor prioridad).
Filtros de contexto
Sección titulada «Filtros de contexto»Los filtros siguientes son opcionales. Cuando se completan, restringen el uso de la política al contexto correspondiente (y aumentan la especificidad).
- codVendedor: filtro por vendedor.
- codCliente: filtro por cliente.
- codListaPreco: filtro por lista de precios.
- codTipoPedido: filtro por tipo de pedido.
- codFormaPagamento: filtro por forma de pago.
- codCondicaoPagamento: filtro por condición de pago.
- codTipoFrete: filtro por tipo de flete.
- codTipoDesconto: filtro por tipo de descuento.
- codSegmento: filtro por segmento.
- codFilial: filtro por sucursal.
- codTransportadora: filtro por transportista.
- codRedespacho: filtro por reenvío.
- codDivisaoVendas: filtro por división de ventas.
Ejemplos de filtros
Ejemplo 1: política aplicable únicamente cuando coinciden codVendedor, codCliente y codDivisaoVendas.
- prioridade = 1
- codVendedor = 45
- codCliente = 1001
- codDivisaoVendas = DV01
En este caso, la política solo se considera aplicable cuando el pedido se encuentra en el contexto del vendedor 45, del cliente 1001 y de la división DV01 al mismo tiempo. Si cualquiera de estos valores difiere, la política no se aplica.
Ejemplo 2: política aplicable cuando coinciden codVendedor y codDivisaoVendas, independientemente del cliente.
- prioridade = 5
- codVendedor = 45
- codDivisaoVendas = DV01
En este caso, la política se aplica a cualquier cliente, siempre que el pedido se encuentre en el contexto del vendedor 45 y de la división DV01.
En una situación donde existan ambas políticas (Ejemplo 1 y Ejemplo 2) aplicables, el sistema preferirá la más específica (Ejemplo 1) porque su prioridad es menor (1), lo que indica que debe aplicarse primero.
Reglas (jsonRegras)
Sección titulada «Reglas (jsonRegras)»- jsonRegras: JSON con las reglas dinámicas de los campos del pedido. El contrato se describe en la sección Contrato del JSON de reglas.
Contrato del JSON de reglas
Sección titulada «Contrato del JSON de reglas»Estructura general
Sección titulada «Estructura general»El campo jsonRegras almacena un JSON con el comportamiento de los campos:
{ "campos": { "nomeCampo": { "obrigatoriedade": ("VISIVEL","OBRIGATORIO","BLOQUEADO","OCULTO"), -> comportamiento del campo en los datos del pedido "filtro": { "tipo": ("PERMITIR","BLOQUEAR") "valores": ["1", "2", "3"] -> Valores que estarán disponibles/bloqueados según "tipo" }, "selecionado": "2" -> Valor que se seleccionará automáticamente o enviar null para no seleccionar automáticamente. } } }Comportamiento
- VISIVEL: mantiene el campo disponible para uso.
- OBRIGATORIO: exige el llenado del campo.
- BLOQUEADO: no permite modificar el campo.
- OCULTO: oculta el campo.
- PERMITIR: muestra para selección únicamente las opciones listadas en valores.
- BLOQUEAR: oculta de la selección las opciones listadas en valores.
- selecionado: el valor se seleccionará automáticamente cuando se aplique la regla.
Campos compatibles y ejemplos
Sección titulada «Campos compatibles y ejemplos»Esta sección concentra los campos interpretados en la aplicación y ejemplos de uso. Al agregar nuevos campos, el mantenimiento de la documentación suele quedar restringido a esta sección.
Campo: División de ventas (divisaoVendas)
- Permite controlar visibilidad, obligatoriedad, bloqueo, filtro de opciones y selección automática del valor.
Ejemplo de jsonRegras para divisaoVendas:
{ "campos": { "divisaoVendas": { "obrigatoriedade": "VISIVEL", "filtro": { "tipo": "PERMITIR", "valores": ["1", "2", "3"] }, "selecionado": "2" } }}Cómo el sistema elige la política (prioridad y especificidad)
Sección titulada «Cómo el sistema elige la política (prioridad y especificidad)»Cuando exista más de una política aplicable, debe prevalecer la regla más adecuada al contexto. La lógica esperada de selección es:
- Considerar únicamente políticas activas.
- Una política es aplicable cuando todos los filtros completados en ella coinciden con los valores del escenario del pedido.
- Los campos de filtro no completados en la política se consideran “indiferentes” (política más genérica).
- Ordenación recomendada para desempate: prioridade ASC (menor valor indica mayor prioridad), luego especificidad (mayor cantidad de filtros aplicados), luego id DESC.
- Devolver/aplicar únicamente la mejor política (la primera tras la ordenación).
Escenarios de ejemplo
Sección titulada «Escenarios de ejemplo»- Escenario 1: Campo visible y con lista permitida (únicamente 1, 2 y 3).
- Cuando la política aplique al contexto del pedido, el usuario verá solo esas opciones en el campo.
- Escenario 2: Selección automática.
- Si selecionado está presente en la lista final tras el filtro, el sistema completará automáticamente el campo con dicho código.
- Escenario 3: Campo oculto para un contexto específico.
- Cuando la política defina OCULTO, el campo dejará de mostrarse y el valor actual se removerá del pedido.
Preguntas frecuentes
Sección titulada «Preguntas frecuentes»¿Qué campos se pueden controlar?
Sección titulada «¿Qué campos se pueden controlar?»- Los campos interpretados en la aplicación están listados en Campos compatibles y ejemplos.
¿Cómo realizar la integración de esta política?
Sección titulada «¿Cómo realizar la integración de esta política?»- Integración de la tabla 280 - PoliticaCamposPedido.
¿Cómo configurar en Demander Web?
Sección titulada «¿Cómo configurar en Demander Web?»-
- Acceda al registro Política de campos del pedido.
-
- Complete Código, Descripción, Empresa (idClienteRetta), Activo y Prioridad.
-
- Configure los filtros de contexto (por ejemplo: vendedor, cliente, tipo de pedido, etc.). Cuantos más filtros se completen, más específica es la política.
-
- En el campo JSON de reglas, ingrese el jsonRegras siguiendo el contrato oficial.
- Para detalles sobre el significado de cada campo, consulte la sección Campos de configuración.
-
- Guarde la política y sincronice los datos para que las aplicaciones e integraciones reciban la configuración.