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.