IdentificadorContrato documentadoObligatorio
Nombre exacto del punto de entrada indicado en la documentación de la rutina.
FUNDAMENTOEn revisión
Puntos de entrada en Protheus
Conceptos, contrato y buenas prácticasComprenda puntos de entrada convencionales y MVC para ampliar rutinas estándar de Protheus sin cambiar el fuente original.
Descripción general
Un punto de entrada es una extensión prevista por TOTVS en un momento determinado de una rutina. En el modelo convencional, la User Function se ejecuta en el evento documentado. En MVC, una sola User Function asociada al identificador del modelo puede ejecutarse en varios hooks del ciclo de vida. En ambos casos, el objetivo es adaptar un proceso de negocio sin modificar el fuente estándar.
Sintaxis
Conceptos, contrato y buenas prácticasParámetros
PARAMIXBArray o contextoOpcional
Disponible solo cuando el punto documentado lo proporciona; su estructura varía según la rutina y la versión.
RetornoContrato documentadoOpcional
Algunos puntos exigen retorno y otros devuelven Nil. Confirma el tipo y el efecto en la documentación específica.
Retorno
Una extensión segura: respeta el contrato de parámetros y retorno definido para el punto de entrada elegido.
Estructura orientativa de una extensión
#Include "TOTVS.ch"
/*
Reemplace EJEMPLOPE por el identificador documentado en el TDN.
Consulte los parámetros y el retorno antes de implementar.
*/
User Function EJEMPLOPE()
Local lContinua := .T.
// Aplique solo la regla de negocio prevista para este evento.
Return lContinuaResultado esperado
Modelo didáctico. El retorno .T. es solo ilustrativo y no debe copiarse sin consultar el contrato real.
Punto de entrada MVC: selección de hooks
#Include "TOTVS.ch"
#Include "FWMVCDEF.ch"
/* El nombre debe coincidir con el ID documentado del Model. */
User Function MIMODELO()
Local aParam := PARAMIXB
Local xRet := .T.
Local cIdHook := ""
If aParam <> Nil
cIdHook := aParam[2]
Do Case
Case cIdHook == "MODELPOS"
// Validación global del modelo.
Case cIdHook == "MODELCOMMITTTS"
// Acción dentro de la transacción: mantenla segura y breve.
EndCase
EndIf
Return xRetResultado esperado
Ejemplo didáctico. Confirma el ID del Model, la estructura de PARAMIXB, los hooks aceptados y el retorno en el TDN de la rutina.
- Usa puntos de entrada para adaptar procesos; no modifiques el fuente estándar ni los uses para corregir defectos del producto.
- La documentación específica define rutina, evento, fuente, función, parámetros y retorno. Confirma ese contrato en el TDN de la versión homologada (TOTVS, s.f.).
- Un punto puede cambiar, sustituirse o descontinuarse entre versiones. Reevalúa las personalizaciones en actualizaciones relevantes.
- Mantén la User Function pequeña, rastreable y cubierta por pruebas de escenarios de negocio.
- En MVC, el punto de entrada es una sola User Function cuyo nombre coincide con el ID del Model. El identificador del Model no puede ser igual al nombre del fuente cuando ese fuente también es una User Function (TOTVS, 2026).
- El array PARAMIXB de MVC entrega el objeto/contexto y el identificador del hook. Ejemplos habituales incluyen MODELPOS, FORMPOS, FORMLINEPRE, MODELCOMMITTTS y MODELCOMMITNTTS; trata solo los hooks documentados para la rutina.
- Los hooks dentro de TTS requieren cuidado adicional: evita operaciones externas o grabaciones que puedan comprometer la transacción. Alinea validaciones, posprocesamientos e integraciones con el momento documentado.
- Inventar PARAMIXB, retorno o momento de ejecución basándose en otro punto de entrada.
- Grabar datos, abrir transacciones o cambiar el flujo estándar sin comprender el efecto del retorno.
- Sustituir una corrección de producto por personalización; los defectos deben evaluarse con el soporte TOTVS.
- Usar el mismo nombre de User Function para finalidades distintas o sin control de versiones.
- En MVC, usar el mismo nombre para el fuente y el ID del Model, en contra de la regla de identificación de TOTVS.
- Ejecutar integraciones externas en un hook transaccional sin evaluar rollback, tiempo de respuesta e idempotencia.