entry-point-designer

Name: entry-point-designer
Author: totvs

108stars50forks

How to install entry-point-designer?

totvs/engpro-advpl-tlpp-skills/entry-point-designer

$npx -y skills add totvs/engpro-advpl-tlpp-skills --skill entry-point-designer

Installs into the current project.

Summary

Design and document Protheus Entry Points (Pontos de Entrada). Always generates TLPP by default; only generates AdvPL (.prw) when the user explicitly requests AdvPL. Covers User Function signatures, PARAMIXB parameter layouts, return value specifications, and ProtheusDOC document

Files · 1

View on GitHub

SKILL.md

1	# Protheus Entry Point Designer
2
3	## Overview
4
5	Design, implement, and document Protheus Entry Points (Pontos de Entrada). Entry Points are the standard extensibility mechanism in TOTVS Protheus, allowing customization of standard ERP routines without modifying the original source code.
6
7	## Language Priority — TLPP First
8
9	TLPP is the default and mandatory output language for every new Entry Point. Only generate AdvPL (`.prw`) when the user explicitly requests it (e.g., "em AdvPL", "como .prw", "legacy AdvPL", "sem TLPP").
10
11	- Default: generate `.tlpp` with `#include "tlpp-core.th"`, type annotations, `Try-Catch`, and namespaced helpers when applicable
12	- Opt-in AdvPL: only when the user is explicit. If the request is ambiguous (e.g., the project still has many `.prw` files), confirm before falling back to AdvPL
13	- Migrating an existing `.prw` Entry Point: prefer rewriting in TLPP unless the user requires keeping the original extension
14
15	## When to Use
16
17	- Creating a new Entry Point to customize standard Protheus behavior
18	- Documenting existing Entry Points
19	- Designing the PARAMIXB interface for custom Entry Points
20	- Migrating legacy Entry Points to TLPP
21
22	---
23
24	## How Entry Points Work
25
26	1. A standard TOTVS routine (e.g., MATA010, FINA010) calls `ExistBlock("PE_NAME")` at predefined extension points
27	2. If a `User Function` with the matching name exists in the RPO, it is executed
28	3. The standard routine passes parameters via the `PARAMIXB` array (Private variable)
29	4. The Entry Point returns a value that influences the standard routine's behavior
30
31	---
32
33	## MANDATORY Rules
34
35	### Function Naming — NEVER use the `U_` prefix
36
37	The compiler resolves `U_` automatically at runtime. Adding it manually causes the Entry Point to never be triggered.
38
39	\| ✅ Correct \| ❌ Wrong \|
40	\|---\|---\|
41	\| `User Function MT410INC()` \| `User Function U_MT410INC()` \|
42	\| `User Function A010TOK()` \| `User Function U_A010TOK()` \|
43
44	### File Naming — match the Entry Point name exactly
45
46	File name must be the Entry Point name in uppercase + language extension. No namespaces, no prefixes, no suffixes.
47
48	\| Entry Point \| AdvPL \| TLPP \|
49	\|---\|---\|---\|
50	\| MT410INC \| `MT410INC.prw` \| `MT410INC.tlpp` \|
51	\| FA080BUT \| `FA080BUT.prw` \| `FA080BUT.tlpp` \|
52
53	---
54
55	## Workflow
56
57	### Step 1 — Identify the Entry Point
58
59	1. Confirm the Entry Point name (e.g., `MT410INC`, `A010TOK`)
60	2. Identify the standard routine and module (e.g., MATA410, SIGAFAT)
61	3. Determine the trigger moment (before validation, after save, grid processing, etc.)
62	4. Consult TDN to confirm PARAMIXB layout and return type
63
64	### Step 2 — Design the PARAMIXB Interface
65
66	Document each parameter using the standard table format in [PARAMIXB & Return Types](./references/paramixb-and-returns.md).
67
68	### Step 3 — Implement the Entry Point
69
70	Default: use the [TLPP Template](./references/templates.md#tlpp-template).
71
72	Only use the [AdvPL Template](./references/templates.md#advpl-template) when the user explicitly requested AdvPL.
73
74	Key implementation rules:
75	- Document the Entry Point with a `/*/{Protheus.doc}` block (`@type user function`, `@param`, `@return`, `@obs`)
76	- Always validate PARAMIXB existence (`Type("PARAMIXB") == "A"`) and length defensively
77	- Extract business logic to `Static Function` helpers
78	- Use `Try-Catch` for error handling — never `ErrorBlock`
79	- Default return value must be fail-safe (must not block the standard routine)
80
81	### Step 4 — Validate
82
83	Apply the [Entry Point Design Checklist](./references/design-checklist.md) before delivering.
84
85	---
86
87	## Quick Reference
88
89	\| Resource \| Contents \|
90	\|---\|---\|
91	\| [Templates](./references/templates.md) \| AdvPL and TLPP code templates \|
92	\| [PARAMIXB & Return Types](./references/paramixb-and-returns.md) \| PARAMIXB layout format, return types, common EP categories \|
93	\| [Design Checklist](./references/design-checklist.md) \| Interface, defensive programming, code quality, SonarQube compliance \|
94	\| [Troubleshooting](./references/troubleshooting.md) \| Common issues and fixes \|

People who liked this also viewed

6 picks

Type

entry-point-designer

108stars50forks

View on GitHub

How to install entry-point-designer?

totvs/engpro-advpl-tlpp-skills/entry-point-designer

$npx -y skills add totvs/engpro-advpl-tlpp-skills --skill entry-point-designer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Protheus Entry Point Designer
2
3	## Overview
4
5	Design, implement, and document Protheus Entry Points (Pontos de Entrada). Entry Points are the standard extensibility mechanism in TOTVS Protheus, allowing customization of standard ERP routines without modifying the original source code.
6
7	## Language Priority — TLPP First
8
9	TLPP is the default and mandatory output language for every new Entry Point. Only generate AdvPL (`.prw`) when the user explicitly requests it (e.g., "em AdvPL", "como .prw", "legacy AdvPL", "sem TLPP").
10
11	- Default: generate `.tlpp` with `#include "tlpp-core.th"`, type annotations, `Try-Catch`, and namespaced helpers when applicable
12	- Opt-in AdvPL: only when the user is explicit. If the request is ambiguous (e.g., the project still has many `.prw` files), confirm before falling back to AdvPL
13	- Migrating an existing `.prw` Entry Point: prefer rewriting in TLPP unless the user requires keeping the original extension
14
15	## When to Use
16
17	- Creating a new Entry Point to customize standard Protheus behavior
18	- Documenting existing Entry Points
19	- Designing the PARAMIXB interface for custom Entry Points
20	- Migrating legacy Entry Points to TLPP
21
22	---
23
24	## How Entry Points Work
25
26	1. A standard TOTVS routine (e.g., MATA010, FINA010) calls `ExistBlock("PE_NAME")` at predefined extension points
27	2. If a `User Function` with the matching name exists in the RPO, it is executed
28	3. The standard routine passes parameters via the `PARAMIXB` array (Private variable)
29	4. The Entry Point returns a value that influences the standard routine's behavior
30
31	---
32
33	## MANDATORY Rules
34
35	### Function Naming — NEVER use the `U_` prefix
36
37	The compiler resolves `U_` automatically at runtime. Adding it manually causes the Entry Point to never be triggered.
38
39	\| ✅ Correct \| ❌ Wrong \|
40	\|---\|---\|
41	\| `User Function MT410INC()` \| `User Function U_MT410INC()` \|
42	\| `User Function A010TOK()` \| `User Function U_A010TOK()` \|
43
44	### File Naming — match the Entry Point name exactly
45
46	File name must be the Entry Point name in uppercase + language extension. No namespaces, no prefixes, no suffixes.
47
48	\| Entry Point \| AdvPL \| TLPP \|
49	\|---\|---\|---\|
50	\| MT410INC \| `MT410INC.prw` \| `MT410INC.tlpp` \|
51	\| FA080BUT \| `FA080BUT.prw` \| `FA080BUT.tlpp` \|
52
53	---
54
55	## Workflow
56
57	### Step 1 — Identify the Entry Point
58
59	1. Confirm the Entry Point name (e.g., `MT410INC`, `A010TOK`)
60	2. Identify the standard routine and module (e.g., MATA410, SIGAFAT)
61	3. Determine the trigger moment (before validation, after save, grid processing, etc.)
62	4. Consult TDN to confirm PARAMIXB layout and return type
63
64	### Step 2 — Design the PARAMIXB Interface
65
66	Document each parameter using the standard table format in [PARAMIXB & Return Types](./references/paramixb-and-returns.md).
67
68	### Step 3 — Implement the Entry Point
69
70	Default: use the [TLPP Template](./references/templates.md#tlpp-template).
71
72	Only use the [AdvPL Template](./references/templates.md#advpl-template) when the user explicitly requested AdvPL.
73
74	Key implementation rules:
75	- Document the Entry Point with a `/*/{Protheus.doc}` block (`@type user function`, `@param`, `@return`, `@obs`)
76	- Always validate PARAMIXB existence (`Type("PARAMIXB") == "A"`) and length defensively
77	- Extract business logic to `Static Function` helpers
78	- Use `Try-Catch` for error handling — never `ErrorBlock`
79	- Default return value must be fail-safe (must not block the standard routine)
80
81	### Step 4 — Validate
82
83	Apply the [Entry Point Design Checklist](./references/design-checklist.md) before delivering.
84
85	---
86
87	## Quick Reference
88
89	\| Resource \| Contents \|
90	\|---\|---\|
91	\| [Templates](./references/templates.md) \| AdvPL and TLPP code templates \|
92	\| [PARAMIXB & Return Types](./references/paramixb-and-returns.md) \| PARAMIXB layout format, return types, common EP categories \|
93	\| [Design Checklist](./references/design-checklist.md) \| Interface, defensive programming, code quality, SonarQube compliance \|
94	\| [Troubleshooting](./references/troubleshooting.md) \| Common issues and fixes \|

People who liked this also viewed

6 picks

Type