Recurso documentadoCriterioObligatorio
Cuenta con documentación oficial sobre finalidad, sintaxis, parámetros, retorno y condiciones de uso; es la opción preferente.
BUENA PRáCTICAPublicado
Recursos internos y no documentados en Protheus
API documentada → contrato público; recurso interno → implementación sin garantía de compatibilidadComprende por qué las funciones, clases y variables internas de Protheus no deben sustentar personalizaciones y cómo reemplazarlas.
Descripción general
No todo identificador encontrado en fuentes, ejemplos antiguos o en el repositorio del producto es una API pública. Según TOTVS, las funciones, clases y variables restringidas o no documentadas están fuera del soporte estándar y pueden cambiar o desaparecer sin aviso. Confirma la documentación oficial antes de adoptar un recurso; si es interno, sustitúyelo por una API documentada o una implementación propia.
Sintaxis
API documentada → contrato público; recurso interno → implementación sin garantía de compatibilidadParámetros
Recurso interno o restringidoCriterioObligatorio
Fue creado para uso del producto, puede depender de premisas implícitas y no ofrece un contrato público de compatibilidad.
Recurso encontrado solo en el fuenteCriterioObligatorio
La existencia técnica no demuestra que el identificador sea público, soportado o estable; confírmalo en la documentación oficial.
Retorno
La clasificación orienta la decisión: utilizar la API pública, reemplazar la dependencia interna o registrar la necesidad en los canales oficiales de TOTVS.
Preferir una alternativa documentada
#Include "TOTVS.ch"
User Function ExRecursoDocumentado()
Local cMensaje := "Procesamiento finalizado"
// Prefiere una función pública y documentada para la necesidad.
MsgInfo(cMensaje, "Resultado")
ReturnResultado esperado
El ejemplo utiliza una función pública documentada. En una migración real, sustituye la llamada interna por la API oficial y pruébala en la release homologada.
Ruta para sanear una dependencia interna
Resultado esperado
1. Localiza todas las llamadas. 2. Registra entradas, salidas y contexto. 3. Consulta la documentación oficial. 4. Elige API pública o implementación propia. 5. Crea pruebas de regresión. 6. Elimina la dependencia y valida la release de destino.
- Busca el identificador en TDN y en la Central de Atención antes de usarlo.
- Confirma que la documentación corresponda a la release y al entorno.
- Encapsula integraciones públicas en funciones propias cuando facilite pruebas y sustituciones.
- Registra dónde se usa una dependencia interna, qué necesidad atiende y cuál será su reemplazo.
- Si no hay una API pública, desarrolla una rutina propia o registra la necesidad ante TOTVS.
- Incluye esta verificación en el checklist de actualización de release.
- TOTVS identifica StaticCall() y PTInternal() como recursos internos bloqueados para compilación desde la release 12.1.33.
- Otros elementos de la lista pueden compilar, pero siguen sin soporte y pueden cambiar o desaparecer.
- El fuente estándar puede depender de estado, alcance, orden o contexto inexistentes en una personalización.
- Jobs, servicios web y rutinas sin interfaz pueden revelar premisas de otro contexto de ejecución.
- Un wrapper limita la dispersión, pero no convierte un recurso interno en API soportada.
- Una lista copiada puede quedar desactualizada; consulta siempre la fuente oficial.