En los siguientes tópicos se muestran los estándares utilizados en todos los módulos estándar, personalizados y de asociados para la denominación de varios artefactos comunes que componen los productos de la línea de producto Microsiga Protheus.

Denominación de los módulos

En el Microsiga Protheus, los nombres de los módulos siempre vendrán precedidos de la palabra "SIGA" (debido a los orígenes del sistema), más la contracción del nombre real del módulo. Por ejemplo, en el caso del módulo Facturación, se optó por el nombre SIGAFAT. La misma regla vale para todos los otros módulos creados por el equipo del producto Microsiga Protheus, como SIGAEST (Stock), SIGAFIN (Financiero), SIGALOJA (Automatización comercial), etc. Por convención, el nombre del módulo no excede los ocho caracteres.
SIGAXXX.PRJ
SIGA - Obligatorio
XXX - Sufijo del nombre real del módulo.

Proyecto

Para nombres de Proyectos, utilizamos una sintaxis para estandarizar, de acuerdo con lo que se explica a continuación.
SIGWXXX.PRJ
SIGW - Es el fijo del sistema y es obligatorio.
XXX - Sufijo del nombre real del módulo.
Ejemplo:

• SIGWTMK
• SIGWCRM

Denominación de los archivos fuente

La línea Microsiga Protheus tiene un estándar de construcción para el nombre de los programas.
Los programas de la línea Microsiga Protheus deben tener 7 (siete) dígitos y dos extensiones posibles, de acuerdo con lo que se explica a continuación:
XXXYNNN[III][S].PRW
XXX - Prefijo del módulo de la línea Microsiga Protheus, por ejemplo: GPE para el módulo de Gestión de personal, PON para el módulo Reloj registrador electrónico, FAT para el módulo de Facturación, etc.
Y - Código que identifica la operación del programa. Se tienen:

NNN - Código secuencial del programa. Mantenga el estándar de numeración de 10 en 10 y vincule las operaciones de programa similares. Ejemplos:

• GPEA010 - Archivo de empleados.
• GPEA020 – Archivo de personas.
• GPEA030 – Archivo de fórmulas.
• GPER010 – Informe de empleados.
• GPER020 – Informe de personas.
• GPER030 – Informe de fórmulas.

III - Las tres últimas letras identifican la localización de origen del programa. Deben utilizarse con base en la tabla de la norma ISO 3166 (Referencia que vendrá posteriormente).
Atención: La sigla se torna obligatoria únicamente para los programas de productos localizados. En caso contrario la sigla deja de ser obligatoria.
S - Secuenciador de la rutina. Algunas rutinas complejas necesitan más de lo que simplemente un código fuente. En estos casos debe utilizarse un secuenciador alfanumérico. Por ejemplo, la rutina de televentas utiliza cuatro programas:

• TMKA273A.PRW
• TMKA273B.PRW
• TMKA273C.PRW
• TMKA273D.PRW

PRW - Extensión PRW. Los archivos de rutinas antiguas aún mantienen el uso de la extensión prx. En los cambios de versión del Microsiga Protheus estas rutinas deben redenominarse con la extensión prw.
Importante:
Siempre que sea posible, debe evitarse la creación de códigos fuente de bibliotecas o rutinas secuenciadas. En muchos casos, pocos códigos fuente agrupan y acumulan grandes cantidades de funciones genéricas iniciando situaciones donde hay un aumento continuo de concurrencia para la reserva del código fuente para modificación. Este tipo de concurrencia deja el proceso de desarrollo rígido y burocrático.
Tabla ISO 3166:

Funciones

Las funciones pertenecientes a un código fuente deben denominarse de acuerdo con su aplicabilidad y su alcance de actuación.
Los posibles alcances de actuación son:

1. Funciones principales y auxiliares de una rutina, informe o consulta.

La actuación exclusiva y limitada a la rutina, informe o consulta, siempre se declara con alcance estático cuando se trata de una función auxiliar y con alcance público cuando la función es la entrada principal.

1. Funciones genéricas de utilización por el módulo (Facturación, Compras, Contabilidad).

Actuación exclusiva para el entorno del módulo, presente en un código fuente del tipo biblioteca y con alcance público.

1. Funciones genéricas de utilización por el equipo del producto (Materiales, Ventas y CRM, Framework, RR.HH).

Actuación exclusiva para un determinado equipo, presente en un código fuente del tipo biblioteca y con alcance público.
En la creación y desarrollo de una función, es imprescindible que el analista que diseñó y el analista de desarrollo, analicen con cuidado la responsabilidad y las funciones que tendrá la función. En muchas situaciones una determinada función que está diseñada para formar parte de una determinada rutina puede generalizarse para su utilización en el módulo, o en el equipo del producto, o incluso, hasta en el framework. Evite la creación de funciones genéricas dentro de códigos fuente biblioteca, siempre que sea posible consulte el framework para que esta función o clase pueda transferirse al equipo correcto, mejorando su desempeño.
Para la función principal de una rutina, informe o consulta, utilice el nombre del archivo.
Ejemplo: Función de inclusión de datos presente FINA050: FINA050().
Para funciones auxiliares de una rutina, informe o consulta, utilice el estándar:
XYNNNXXXXX()
X - Primera letra del nombre del código fuente.
Y - Tipo de operación indicado en el código fuente.
NNN - Identificador del código fuente.
XXXXX - Abreviación descriptiva del objetivo de la función.
Ejemplo: Función de inclusión de datos presente FINA050: FA050Inclu().
Para funciones genéricas de utilización por el módulo, utilice el estándar:
XXZZZZZZZZ()
XX - Prefijo del módulo de la línea Microsiga Protheus. Por ejemplo: GP para el módulo de Gestión de personal, PO para el módulo de Reloj registrador electrónicos, FT para el módulo de Facturación, etc.
ZZZZZZZZ - Abreviación descriptiva del objetivo de la función.
Ejemplo: Función genérica del módulo Facturación: FTFuncaoGenerica().
Para funciones genéricas de utilización por el equipo del producto, utilice el estándar:
XXZZZZZZZZ()
XX - Abreviación en el nombre del equipo, ejemplo: VC para Ventas y CRM, MT para Materiales, etc.
ZZZZZZZZ - Abreviación descriptiva del objetivo de la función.
Ejemplo: Función genérica del equipo de Recursos Humanos: RHFuncaoGenerica().

Clases y métodos

Para estandarización de nombre de Clases y Métodos, debemos utilizar la siguiente nomenclatura:
Las clases deben iniciarse con una abreviación o sufijo del módulo, paquete al que pertenece la clase (opcional), tipo de clase () y el nombre de la clase, sin límite de tamaño, entonces, recomendamos que el nombre sea lo más explicativo posible y sin abreviaciones. Vea:

• "FT" – Abreviación - Facturación.
• "BC" - Paquete - Business Component , que es un paquete que podemos identificar, cuya clase tiene la función Regla de negocios.
• "A" - Tipo de clase, "A" para Abstracta e "C" para Concreta.
• "GeraFaturantoSimple" - Nombre de la clase

Entonces: FTBCAGeraFaturamento
Los nombres del paquete que pertenece a una Clase no son obligatorios, sin embargo, es recomendable para que en una consulta sepamos rápidamente cuál es la función básica de esta clase. A continuación, algunos ejemplos:

• "BC" - Business Component - Clase con función orientada a la Regla de negocio.
• "DT" - Data - Clase con función orientada a los datos, consulta, modificación e inclusión.
• "BW" - Busines Work Flow - Clase responsable por el Flujo de llamadas de los componentes.

También es importante, para una mejor organización y localización de una Clase, tener siempre un archivo (fuente) por clase.
Los Métodos pueden componerse únicamente por el nombre, respetando el tamaño de 10 caracteres.

Parámetros

Los parámetros creados por un módulo deben seguir la siguiente regla de identificación:
MV_YYZZZZZ
MV - Indica que es un parámetro del módulo.
YY - Indica de qué módulo es el parámetro.
ZZZZZ - Nombre dado al parámetro.
Ejemplos:

Tabla

Los nombres de las nuevas Tablas se ponen a disposición por la Torre de ingeniería, dentro de un rango para cada GDP. De esta manera, cada nueva tabla que una GDP tenga necesidad de crear, tiene que orientarse por este Rango.
Ejemplo:
GDP Ventas & CRM Rango de MD1 a MD9
Además del Rango de tablas, es obligatorio que inmediatamente después que se definan qué tablas, campos e índices se utilizarán, se registren en el AtuSx.
También se recomienda que cada GDP haga un control de estas tablas, para saber cuáles están utilizándose y cuál es la próxima a utilizarse.

Campos

El nombre de campos tiene una sintaxis obligatoria:
XX[X]_YYYYYY[Y]
XX[X] - Segunda y tercera letra de la tabla si la tabla comienza con S o las tres letras de la tabla si no comienza con S.
YYYYYY[Y] - El nombre representativo del campo con seis letras si la tabla no comienza con S o siete letras si la tabla comienza con S.
Ejemplo:
Tabla: MD1 - Procesos
Campo: Código
Nombre del campo: MD1_CODPRO
Tabla: SA1 - Clientes
Campo: Código de la transportadora
Nombre del campo: A1_TRANSP
Sucursal:
El campo que identifica la Sucursal del registro, siempre debe completarse con la palabra "SUCURSAL", ejemplo, MD1_SUCURSAL.
Otros campos:
Los nombres siempre tienen que formarse con más de un sufijo, para ayudar en la identificación de los campos.
MD1_CODIGO - ERRADO - PUES, DE ESTA MANERA NO CONSEGUIMOS IDENTIFICAR "QUÉ CÓDIGO ES".
MD1_CODPRO - CERTO - PUES, DE ESTA MANERA SABEMOS QUÉ ES UN CÓDIGO DE PROCESO.
Importante:
La información en la base de datos no puede duplicarse, aunque la tabla sea de responsabilidad de otra GDP. Lo mismo sucede para los campos, pues el usuario no debe digitar dos veces la misma información. Siempre que sea posible, consulte a los especialistas de otros módulos si es posible encontrar la misma información en otra parte del sistema.

Puntos de entrada

Los puntos de entrada tienen como objetivo dejar el sistema flexible, permitiendo una gran variedad de desarrollo por los analistas de soporte, de acuerdo con la necesidad de cada tipo de cliente/implantación.
XXYYYZZZZ
XX - Iniciales del módulo.
YYY - Código secuencial del programa. Mantenga el estándar de numeración de 10 en 10.
ZZZZ - Nombre dado al punto de entrada.
Ejemplos:

Para crear y utilizar los puntos de entrada, debemos tener en mente:

• Analizar el motivo de la creación del punto, porque es importante crearlo en un punto que sea útil, no redundante y que atienda a las condiciones del cliente.
• De ninguna manera debe utilizarse el punto de entrada para corregir eventuales fallas en el sistema.
• Tampoco deben incluirse puntos de entrada en un proceso crítico del sistema, porque ocasionará resultados imprevisibles.
• Es imprescindible la utilización de la función ExistBlock() que verifica la existencia en el punto de entrada del repositorio, además de condicionar su ejecución.
• No tratar el punto de entrada con find function y user function.
• No es necesario realizar el cache de la existencia de un determinado punto de entrada, la función ExistBlock realiza este trabajo.

Ejemplo:
// EntrancePointExample.prw
#INCLUDE "TOTVS.CH"
Function EntrancePointExample()
While SA1->(EOF())
If ExistBlock("SAVECLI")
ExecBlock("SAVECLI", .F., .F., aParam)
EndIf
SA1->(DbSkip())
EndDo
Return