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.