Documented resourceCriterionRequired
Has official documentation covering purpose, syntax, parameters, return and conditions of use; it is the preferred choice for customizations.
BEST PRACTICEPublished
Internal and undocumented resources in Protheus
Documented API → public contract; internal resource → implementation with no compatibility guaranteeLearn why internal Protheus functions, classes and variables should not underpin customizations and how to replace these dependencies.
Overview
Not every identifier found in source code, old examples or the product repository is a public API. According to TOTVS, restricted or undocumented functions, classes and variables are outside standard support and may change behavior or be discontinued without notice. Confirm official documentation before adopting a resource; when it is internal, replace it with a documented API or your own implementation.
Syntax
Documented API → public contract; internal resource → implementation with no compatibility guaranteeParameters
Internal or restricted resourceCriterionRequired
Was created for product use, may depend on implicit assumptions and provides no public compatibility contract.
Resource found only in source codeCriterionRequired
Technical existence does not prove that the identifier is public, supported or stable; confirm it in official documentation.
Return value
The classification guides the architectural decision: use the public API, replace the internal dependency or submit the requirement through official TOTVS channels.
Prefer a documented alternative
#Include "TOTVS.ch"
User Function ExDocumentedResource()
Local cMessage := "Processing completed"
// Prefer a public, documented function for the requirement.
MsgInfo(cMessage, "Result")
ReturnExpected result
The example uses a documented public function. In a real migration, replace the internal call with the official API for the requirement and test it on the approved release.
Internal-dependency remediation path
Expected result
1. Find every call. 2. Record inputs, outputs and context. 3. Check official documentation. 4. Choose a public API or your own implementation. 5. Add regression tests. 6. Remove the dependency and validate the target release.
- Search TDN and the TOTVS Support Center before using an identifier.
- Confirm that documentation matches the target release and environment.
- Wrap public integrations in your own functions when this improves testing and replacement.
- Record where an existing internal dependency is used, its purpose and the chosen replacement.
- If no public API exists, build your own routine or submit the requirement to TOTVS for evaluation.
- Include internal-resource checks in the release-upgrade checklist.
- TOTVS identifies StaticCall() and PTInternal() as internal resources blocked from compilation as of release 12.1.33.
- Other listed resources may still compile but remain unsupported and may change or disappear.
- Standard source code may rely on state, scope, execution order or context unavailable to a customization.
- Jobs, web services and headless routines may expose assumptions from a different execution context.
- A wrapper limits dependency spread but does not make an internal resource supported.
- A copied static list may become outdated; consult the official source.