Cómo planificar los permisos de una integración con Service Layer en SAP Business One 10

Si una integración necesita acceder al Service Layer, el punto de partida no es concederle permisos amplios: primero hay que identificar qué datos y operaciones requiere. La referencia de la API de SAP describe operaciones sobre entidades y acciones que van más allá de las operaciones habituales de creación, lectura, actualización y eliminación. Por eso, «acceder a pedidos» no define por sí solo el alcance de un permiso.

Este artículo ofrece una pauta para preparar la revisión de una cuenta dedicada a una integración. No presenta una lista universal de autorizaciones ni sustituye la comprobación de los permisos correspondientes a cada operación en el paquete instalado. Para el inicio de sesión y las sesiones, consulta el artículo relacionado sobre autenticación del Service Layer.

Requisitos antes de asignar accesos

Identifica la empresa, el motor, el paquete exacto de SAP Business One 10, las funciones del Service Layer utilizadas y los datos que tratará la integración. Confirma también quién autoriza el acceso y quién administra sus credenciales. Esta separación es una pauta de diseño de mínimo privilegio, no una denominación oficial de cuenta ni una indicación sobre licencias.

Prepara una matriz como esta antes de solicitar cambios de autorización:

Necesidad de la integración	Operación que debe identificarse	Revisión pendiente
Consultar un objeto de negocio	Entidad y operación de lectura concretas	Datos visibles y autorización aplicable
Crear o modificar un objeto	Entidad y operación de escritura concretas	Alcance del cambio y autorización aplicable
Ejecutar una acción de negocio	Acción concreta; no asumir que equivale a actualizar la entidad	Autorización aplicable a esa acción
Utilizar consultas SQL expuestas por Service Layer	Función y consulta concretas, si están disponibles en el paquete	Control de permisos y datos que podría devolver cada consulta

La referencia de SAP distingue las acciones de las operaciones habituales sobre entidades; por ejemplo, explica que cancelar un pedido requiere una acción definida para ese servicio. La matriz es una herramienta de planificación, no una relación de permisos ya verificada.

Procedimiento de revisión

1. Documenta cada operación requerida. Anota la entidad o acción, el tipo de operación, su finalidad y los datos necesarios. Contrasta los nombres y las operaciones disponibles con la referencia de la API; no deduzcas que el permiso para una lectura cubre una escritura o una acción.
2. Separa necesidades de ejecución y administración. Propón una identidad identificable para la integración y solicita únicamente los accesos justificados por la matriz. Antes de configurar usuarios, licencias o autorizaciones en SAP Business One, confirma esas decisiones con el administrador y con la documentación aplicable al paquete instalado: las fuentes recuperadas para este artículo no permiten indicar una ruta de menús ni un tipo de licencia universal.
3. Si se utilizarán consultas SQL del Service Layer, haz una revisión aparte. La guía Working with SAP Business One Service Layer, versión documental 1.29, incluye apartados específicos sobre control de permisos de consultas (§4.11), consideraciones de seguridad (§4.12) y limitaciones (§4.13). Consulta esos apartados y la documentación de tu paquete antes de autorizar una consulta; revisa especialmente los datos sensibles que podría exponer. La existencia de esos controles no permite extrapolar sus reglas a todas las entidades OData.
4. Define la comprobación antes de ponerla en producción. Para cada operación de la matriz, especifica qué acceso debe permitirse y cuál debe permanecer denegado. Registra el resultado por operación sin incluir credenciales ni secretos en las evidencias. Esta es una recomendación de verificación; aquí no se proporcionan códigos de error como diagnóstico universal.

Resultado esperado y advertencias

El resultado de esta revisión es una solicitud de acceso trazable: cada capacidad pedida tiene una finalidad, un responsable y una comprobación prevista. Si una operación falla, revísala junto con su contexto de autenticación y con el permiso que corresponda a esa función; no amplíes privilegios de forma indiscriminada para resolverla.

Los privilegios de conexión del servicio a la base de datos y los permisos funcionales de la integración no deben tratarse como una única configuración. Tampoco debe darse por supuesta la disponibilidad de una función solo porque la instalación pertenece a la serie 10.x: confirma el motor y el paquete antes de seguir documentación específica de consultas SQL o de otra capacidad.

Alcance y referencias

Aplicable como pauta de revisión a proyectos de SAP Business One 10 con SAP HANA o Microsoft SQL Server; la compatibilidad de funciones concretas queda sujeta al paquete instalado. Fecha de revisión: 5 de noviembre de 2026. Referencias técnicas: Service Layer API Reference y Working with SAP Business One Service Layer (versión documental 1.29, 27 de julio de 2026).

Nivel de validación: revisión documental.

Fecha de revision documental: 2026-11-05.

Inventario por almacén en SAP Business One 10: consulta SELECT para SQL Server

Si necesitas ver la existencia actual de cada artículo por almacén, puedes partir de OITW y añadir el nombre del artículo desde OITM y el del almacén desde OWHS. Esta consulta de solo lectura está planteada para SAP Business One 10.x sobre Microsoft SQL Server.

Consulta de inventario por artículo y almacén

SELECT
    w.ItemCode,
    i.ItemName,
    w.WhsCode,
    h.WhsName,
    w.OnHand AS EnStock,
    w.IsCommited AS Comprometido,
    w.OnOrder AS Pedido,
    w.OnHand + w.OnOrder - w.IsCommited AS Disponible
FROM OITW AS w
INNER JOIN OITM AS i
    ON i.ItemCode = w.ItemCode
INNER JOIN OWHS AS h
    ON h.WhsCode = w.WhsCode
ORDER BY w.ItemCode, w.WhsCode;

La referencia del SDK de SAP Business One 10.0 documenta OITW como tabla de artículos por almacén, con los códigos y cantidades usados aquí. También documenta OITM.ItemName y OWHS.WhsName. Las uniones relacionan cada código de artículo y almacén con su nombre correspondiente. Consulta las referencias de OITW, OITM y OWHS.

Cómo interpretar el resultado

• EnStock muestra OITW.OnHand: la cantidad en stock del artículo en ese almacén.
• Comprometido y Pedido muestran, respectivamente, OITW.IsCommited y OITW.OnOrder.
• Disponible es un cálculo añadido en esta consulta: OnHand + OnOrder - IsCommited. No es sinónimo de EnStock ni se presenta aquí como una fórmula oficial de un informe estándar.

Como ejemplo orientativo, si una fila tuviera 10 unidades en stock, 2 comprometidas y 3 pedidas, las columnas mostrarían EnStock = 10 y Disponible = 11. Son cifras ilustrativas, no resultados de una compañía.

Filtros opcionales y límites

Para consultar un único almacén, añade antes de ORDER BY una condición como WHERE w.WhsCode = N'CODIGO_REAL', sustituyendo el texto por un código comprobado en tu compañía. Si solo interesan existencias positivas, puedes usar WHERE w.OnHand > 0; ese criterio excluye tanto los ceros como los saldos negativos. Si necesitas ambos filtros, combínalos con AND. En compañías con muchos artículos y almacenes, acotar la consulta puede reducir el volumen de filas devueltas; no se dispone de un plan de ejecución para estimar su rendimiento.

El resultado esperado es una fila por combinación artículo–almacén presente en OITW que encuentre sus registros relacionados en OITM y OWHS. La consulta sin filtros no elimina las filas cuya existencia sea cero, pero tampoco genera combinaciones que no estén en OITW. No reconstruye inventario a una fecha anterior ni ofrece valoración, lotes, números de serie o existencias por ubicación dentro del almacén.

Esta versión usa sintaxis de SQL Server; no debe trasladarse sin adaptación a SAP HANA. Si tu instalación utiliza ese motor, consulta el artículo independiente sobre inventario por almacén para HANA.

Fecha de referencia editorial: 4 de noviembre de 2026, 07:00:30 −05:00. Validación técnica: revisión documental y estática. Se recomienda comprobar la consulta y sus resultados en un entorno de pruebas antes de utilizarla operativamente; el build concreto y el rendimiento no están verificados.

Fecha de revision documental: 2026-11-04.

Documentos de compras en SAP Business One 10.0 SP 2505: revisión previa a aprobaciones en Web Client

Antes de configurar una aprobación de compras conviene responder una pregunta más concreta: ¿qué documento se quiere revisar y en qué momento? Una solicitud de compra, una oferta de proveedor y un pedido no representan necesariamente la misma decisión. Tampoco debe darse por hecho que una aprobación aplicada a un documento se extenderá a los que se creen después a partir de él.

Esta es una lista de preparación, no un procedimiento de configuración probado. La evidencia recuperada para este artículo es el índice de la guía oficial de SAP Business One, Web Client, 10.0 SP 2505. Ese índice identifica apartados de compras, entre ellos solicitudes de compra y ofertas de proveedor, y apartados denominados «Managing Drafts», «Managing Documents in Approval Process» y «Approval Decisions». El índice no acredita por sí solo qué documentos de compras admiten aprobaciones, cómo se activan ni cuál es el comportamiento de cada pantalla.

El problema: una regla demasiado amplia

«Aprobar las compras superiores a cierto importe» parece una especificación suficiente, pero deja preguntas abiertas. ¿Se revisará la solicitud interna o el documento dirigido al proveedor? ¿Qué sucederá si alguien cambia los datos tras la decisión? ¿Quién comprobará que el siguiente documento del circuito refleja lo acordado? Son preguntas de diseño del control, no afirmaciones sobre el funcionamiento automático de SAP Business One.

Requisitos para preparar la revisión

• Conocer el FP/SP/build instalado y distinguir los procesos realizados en Web Client de los realizados por otros canales.
• Disponer de un ejemplo real, sin datos sensibles, de cada tipo de documento que la empresa desea controlar.
• Identificar al responsable funcional del circuito y a quien administra las autorizaciones. No cambiar permisos ni plantillas como parte de esta revisión preliminar.
• Contar, si se decide validar el diseño, con un entorno de pruebas apropiado. Este artículo no aporta resultados de esa validación.

Pasos de análisis documental

1. Delimitar los nombres de los documentos. El índice de la guía citada separa «Purchase Requests» y «Purchase Quotations» dentro de compras. Úselo como punto de partida para redactar una lista de los tipos que intervienen en su circuito; no interprete la presencia de un apartado en el índice como prueba de que admite una aprobación concreta.
2. Dibujar el recorrido previsto. Para cada documento de la lista, anote quién lo prepara, qué decisión se pretende controlar y cuál sería el documento siguiente. Este cuadro es una propuesta propia de levantamiento de requisitos: no describe una secuencia configurada ni un resultado observado en SAP.
3. Separar borrador, decisión y documento final en la especificación. La guía contiene apartados con los títulos «Managing Drafts», «Managing Documents in Approval Process» y «Approval Decisions». Precisamente porque son conceptos diferenciados en la documentación, pida que el equipo indique qué estado espera observar en cada caso. La evidencia disponible no permite afirmar aquí qué transición se produce ni para qué documento de compras.
4. Registrar los casos que requieren comprobación. Prepare ejemplos de documento que debería entrar en revisión y otro que no; añada un rechazo, un cambio posterior y la continuación del circuito. Anote resultado esperado y responsable de comprobarlo. No presente esos resultados como comportamiento confirmado hasta contrastarlos en la instalación correspondiente.

Resultado esperado y límites

El entregable esperado es una matriz breve con documento, canal, responsable, momento de control y casos pendientes de prueba. Servirá para plantear una configuración específica sin confundir una decisión sobre un documento con el control completo de las compras.

La guía recuperada corresponde a Web Client 10.0 SP 2505; este texto no demuestra que las mismas opciones existan en otros FP/SP, en el cliente de escritorio o para todos los documentos. No se propone SQL o SAP HANA. Las autorizaciones son un asunto de seguridad de riesgo alto: cualquier cambio de permisos o aprobación requiere revisión separada por personal autorizado.

Fecha de revisión: 28 de octubre de 2026. Nivel de validación: revisión documental. Fuente técnica: SAP, User Guide for SAP Business One, Web Client, 10.0 SP 2505.

SAP Business One Service Layer 10.0: cómo evaluar la autenticación y las sesiones de forma segura

Fecha de corte documental: 28 de octubre de 2026. Alcance: SAP Business One Service Layer 10.0; los builds y las diferencias entre SAP HANA y Microsoft SQL Server no se han comprobado.

El problema: una conexión no equivale a una sesión válida

Al diseñar una integración conviene distinguir tres cuestiones: cómo se identifica el cliente, cómo se mantiene su sesión y cómo termina. Confundirlas puede llevar a repetir intentos de acceso o a cambiar parámetros sin haber identificado el fallo. La guía oficial Working with SAP Business One Service Layer, versión documental 1.29 del 27 de julio de 2026, separa expresamente «Login and Logout» y «Session» en su índice. Sin embargo, los pasajes recuperados para esta revisión no incluyen el desarrollo de esas secciones. Por ello, aquí no se presenta una receta de inicio de sesión ni se atribuye a SAP un formato concreto de cookies, credenciales o tiempos de caducidad.

Qué se puede establecer con la documentación disponible

La referencia oficial de la API indica que Service Layer expone OData v3 y v4. Desde SAP Business One FP 2405, OData v3 está deprecado, aunque sigue disponible por compatibilidad; SAP señala v4 como protocolo principal. La referencia consultada corresponde a v4 y muestra ejemplos bajo /b1s/v2/, incluido un GET con URL HTTPS. Esos ejemplos acreditan la ruta y el tipo de operación mostrados, no una secuencia de autenticación ni el comportamiento de una instalación particular.

El índice de la guía también identifica apartados de metadatos, documento de servicio y recuperación de entidades. Son puntos de consulta pertinentes para delimitar qué ofrece el servicio antes de desarrollar una integración; el extracto disponible no permite convertirlos en instrucciones de ejecución detalladas.

Revisión previa a una prueba autorizada

1. Delimitar el entorno. Registrar el FP/SP y build que se pretende evaluar, el motor, el cliente de integración y la URL facilitada por el administrador. La documentación recuperada no acredita que todos los builds 10.x ni ambos motores tengan una configuración idéntica.
2. Elegir la documentación del protocolo. Para una integración nueva, revisar primero la referencia OData v4 y sus ejemplos /b1s/v2/. Si existe una integración v3, considerar expresamente la deprecación indicada desde FP 2405, sin presuponer que deja de funcionar.
3. Consultar el procedimiento completo de SAP. Antes de implementar el acceso, leer en la guía oficial las secciones «Login and Logout» y «Session» correspondientes al entorno. Los extractos disponibles aquí solo permiten localizar esas secciones, no reproducir sus pasos.
4. Definir controles de seguridad para la prueba. Como criterio preventivo del proyecto —no como resultado verificado en Service Layer—, evitar que contraseñas o datos de sesión aparezcan en registros y exigir una validación adecuada del certificado del destino HTTPS. La revisión de permisos y de la configuración de red corresponde a los responsables del sistema.

Resultado esperado y límites

El resultado esperado de esta revisión es un plan de prueba que identifique protocolo, documentación aplicable y controles antes de manejar credenciales reales.

Si aparece un fallo de autenticación en una prueba posterior, conservar evidencia técnica sin secretos y contrastarla con la guía completa y la configuración efectiva antes de modificar parámetros. Una URL o una referencia comunitaria sin texto recuperado no basta para declarar una solución compatible con SAP Business One 10.x.

Fecha de revision documental: 2026-10-28.

Inventario por almacén en SAP Business One 10 para HANA: consulta SELECT

Motor: SAP HANA. Versión documental: SAP Business One 10.0; compatibilidad con el build instalado no comprobada. Fecha de referencia del informe preliminar: 27 de octubre de 2026, 17:08:52 −03:00. Este artículo presenta una revisión estática: la consulta no se ha ejecutado en una sociedad.

¿Qué problema resuelve?

Si necesitas revisar cantidades por artículo y almacén, la tabla OITW ofrece campos para las existencias, las cantidades comprometidas y las pedidas. La referencia de tablas del SDK 10.0 documenta ItemCode, WhsCode, OnHand, IsCommited y OnOrder en Items - Warehouse (OITW). Las descripciones del artículo y del almacén proceden, respectivamente, de Items (OITM) y Warehouses (OWHS).

Consulta candidata para SAP HANA

La siguiente sentencia es exclusivamente de lectura. Usa comillas dobles en los nombres de columnas y parte de los pares artículo-almacén presentes en OITW:

SELECT
    W."WhsCode"    AS "CodigoAlmacen",
    H."WhsName"    AS "NombreAlmacen",
    W."ItemCode"   AS "CodigoArticulo",
    I."ItemName"   AS "NombreArticulo",
    W."OnHand"     AS "EnStock",
    W."IsCommited" AS "Comprometido",
    W."OnOrder"    AS "Pedido",
    W."OnHand" + W."OnOrder" - W."IsCommited" AS "DisponibleCalculado"
FROM "OITW" W
INNER JOIN "OITM" I ON I."ItemCode" = W."ItemCode"
INNER JOIN "OWHS" H ON H."WhsCode" = W."WhsCode"
ORDER BY W."WhsCode", W."ItemCode"

Importante: DisponibleCalculado es un cálculo aritmético propuesto a partir de tres campos documentados; no se ha acreditado aquí que reproduzca la definición ni los criterios de un informe estándar de SAP. EnStock corresponde a OnHand; no debe confundirse con la cifra calculada, que también incorpora OnOrder e IsCommited.

Requisitos y comprobación recomendada

1. Confirma que la sociedad de destino utiliza SAP Business One para SAP HANA y registra su versión, build y localización. La referencia SDK 10.0 no demuestra compatibilidad con todos los parches 10.x.
2. Revisa que el contexto de consulta apunta al esquema de la sociedad correcta y que el usuario dispone únicamente del acceso de lectura necesario. Antes de compartir la consulta o exportar resultados, comprueba quién podrá verlos.
3. Prueba primero una lectura limitada y controlada de los campos de OITW en el entorno de destino. Incorpora después las uniones con OITM y OWHS y, por último, el cálculo. Si aparece un error, verifica los nombres exactos de los campos y el contexto de ejecución.
4. Contrasta unos pocos artículos y almacenes con los datos mostrados por la sociedad. Si comparas con un informe estándar, documenta sus filtros y criterios: la equivalencia funcional no está comprobada.

Resultado esperado y límites

Resultado esperado: una fila por cada par artículo-almacén de OITW que también encuentre las filas relacionadas en OITM y OWHS, con códigos, nombres y las cuatro cifras seleccionadas o calculadas. Las uniones internas pueden excluir filas sin correspondencia; la consulta no crea combinaciones ausentes en OITW.

No hay filtros de almacén, artículo ni stock positivo, por lo que el volumen de salida dependerá de la sociedad. Tampoco se obtiene un saldo a una fecha histórica, valoración, detalle de lotes, números de serie o ubicaciones. Antes de usar la cifra calculada para una decisión operativa, verifica qué significado necesita tu proceso y coteja los valores en el sistema real.

Fecha de revision documental: 2026-10-27.