Se definieron como estándar los Criterios de DoR y DoD - Soporte y Desarrollo para el RRHH Protheus, con la finalidad de estandarizar las entregas de Soporte para el Desarrollo (creación de las issue) y del Desarrollo para el Soporte (resolución, dudas o rechazo de las issue).


El modelo anterior se puede acceder en detalles en el archivo Criterios_DoR_DoD_Soporte_Desarrollo.xmind

(Importante: este modelo se desarrolló en el software XMind, por lo tanto es necesario instalarla para su visualización).

1. Soporte > Desarrollo - Apertura de Issue

Al crear una nueva issue, el equipo de soporte debe seguir los Criterios de DoR y DoD - Soporte y Desarrollo definidos y utilizar el Checklist Modelo de generación de Issue para desarrollo (ejemplo de cumplimentación en http://tdn.totvs.com/x/h25YGw), completándolo con todas las informaciones que fueron necesarias y adjuntándolo al ticket y la issue, para que el desarrollo pueda realizar el análisis y actuar en su resolución.

NOTA: Las evidencias se deben hacer por medio de Prints de pantallas y no por videos. (En caso de excepciones, donde solamente se puede evidenciar el error por video, se alineará con los P.O. Y Proxys la apertura por video)


(estrela vermelha) Para las issue de Documentación, seguir el modelo indicado> Modelo de Issue de documentación


En cualquier pantalla del Protheus se pueden pulsar las teclas SHIFT + F6 del teclado, simultáneamente, para mostrar informaciones de la rutina indicando que usted está en el sistema, informaciones del entorno y herramientas útiles.

Si existe alguna situación, en que no se puede reproducir en entorno local, el Maestro y/o Líder del soporte deben ponerse de acuerdo con el Product Owner, y este puede aceptar o no la apertura de la issue, frente a las evidencias.

Plazo estándar para respuesta del soporte al desarrollo:

En la situación en que el Desarrollo, después de analizar la issue verifique que se debe rechazar la issue y realizar el acuerdo con el analista de atención y el Maestro y/o Líder de Atención. Queda establecido el plazo de 2 días hábiles para la respuesta del Soporte, si no hubiera respuesta, el desarrollo hará el rechazo.


2. Desarrollo > Soporte - Rechazo y apoyo

El equipo de Desarrollo, al iniciar el análisis de una nueva issue, debe verificar si los Criterios de DoR y DoD - Soporte y Desarrollo definidos, fueron seguidos por el soporte para crear la issue y debe seguir también los Criterios de DoR y DoD definidos en la actuación de la resolución de las demandas. El proceso de priorización debe estar alineado con el Product Owner de la Squad.

Verificar los procedimientos para los casos donde sea necesaria la Devolución / Rechazo de la issue, en: Instrucción de Trabajo - Procedimiento antes de rechazar o no rechazar una Issue


3. Procesos para Issues sin posicionamiento

Se definieron procesos de formalización de plazos y planificación de issues a través de los campos "PRIORIZADO" en el ticket en el Zendesk y "FECHA DE ACUERDO" en la issue en el JIRA. Los flujos que se definieron y deben ser seguidos por elSoporte y Desarrollo (Product Owners) son:

Posicionamento del plazo para el cliente.

Rechazo del plazo por el cliente.

Fecha Acuerdo entrega vencida.

Los detalles de cada uno de estos procesos están documentados en la space de la Guild Protheus en: Desarrollo Protheus - Issues sin posicionamiento

4. Proceso de estandarización para subir fuentes

4.1. Documento con el paso a paso de todas las características necesarias para crear la base congelada, de acuerdo con el siguiente ejemplo:


Nombre del caso de prueba: Factura de entrada - Devolución de mercadería remitida para industrialización por pedido en operación interna con el ICMS e IPI suspendidos, PIS y COFINS que no inciden en el régimen no acumulativo

Condiciones previas:

Acceder a la configuración (SIGACFG) ->Registros →Parámetros:

MV_ESTADO = SP

MV_ICMPAD = 18

MV_ESPECIE = 633=SPED

MV_IPINOBS = SS

Registro de naturaleza - Industria - Venta de material

Código (ED_CODIGO) = IND001

Descripción (ED_DESCRIC) = VENTA DE MATERIAL

Cond. Naturaleza (ED_COND) = INGRESO

Registro de naturaleza - Industria - Compra de material

Código (ED_CODIGO) = IND002

Descripción (ED_DESCRIC) = COMPRA DE MATERIAL

Cond. Naturaleza (ED_COND) = GASTO

Registro de proveedor - Industria - SP0002 - tipo contribuyente persona jurídica

Datos de registro:

Código (A2_COD) = SP0002

Tienda (A2_LOJA) = 01

Razón social (A2_NOME) = FORN SP PJ

N Fantasía (A2_NREDUZ) = FORN SP PJ

Dirección (A2_End) = Av. Braz Leme, 100

Barrio (A2_BAIRRO) = Santana

Estado (A2_EST) = SP

Cd. Municipio (A2_COD_MUN) = 50308

Municipio (A2_MUN) = SAO PAULO

CP (A2_CEP) = 05124-000

Tipo (A2_TIPO) = Jurídico

CNPJ/CPF (A2_CGC) = 36.528.684/0001-46

Insc. Estatal (A2_INSCR)= 178.899.484.930

País (A2_PAIS) = 1055

Adm/Financiero:

Naturaleza (A2_NATUREZ) = IND002

Fiscales:

País Bacen (A2_CODPAIS) = 01058

Registro de cuenta contable - Industria - Entrada de documentos

Cód. Cuenta (CT1_CONTA) = ENT000001

Desc Moneda 1 (CT1_DESC01)= CUENTA PARA REGIS ENTRADA

Clase Cuenta (CT1_CLASSE) = 2 - Analítica

Cond. Normal (CT1_NORMAL) = 2 - Acreedora

Fch Ini Exist (CT1_DTEXIS) = 01/01/2017

Nat Cta SPED (CT1_NTSPED) = 09 - Otras

Registro de cuenta contable - Industria - Salida de documentos

Cód. Cuenta (CT1_CONTA) = SAI000001

Desc Moneda 1 (CT1_DESC01)= CUENTA PARA REGIS SALIDA

Clase Cuenta (CT1_CLASSE) = 2 - Analítica

Cond. Normal (CT1_NORMAL) = 1 - Deudora

Fch Ini Exist (CT1_DTEXIS) = 01/01/2017

Nat Cta SPED (CT1_NTSPED) = 09 - Otras

Registro de cliente - Industria - SP0002 - tipo contribuyente persona jurídica

Datos de registro:

Código (A1_COD) = SP0002

Tienda (A1_LOJA) = 01

Física/Juríd (A1_PESSOA) = Jurídica

Nombre (A1_NOME) = CLIENTE SP REV PJ

N Fantasía (A1_NREDUZ) = SP REV PJ

Dirección (A1_End) = Av. Braz Leme, 100

Tipo (A1_TIPO) = R- Revendedor

Estado (A1_EST) = SP

Cd. Municipio (A1_COD_MUN) = 50308

Municipio (A1_MUN) = SAO PAULO

Barrio (A1_BAIRRO) = Santana

CP (A1_CEP) = 10025-100

País (A1_PAIS) = 105

CNPJ/CPF (A1_CGC) = 07.079.511/0002-70

Ins. Estat. (A1_INSCR) = 148.538.048.119

Adm/Financiero:

Naturaleza (A1_NATUREZ) = IND001

Fiscales:

País Bacen (A1_CODPAIS) = 01058

Ventas:

Riesgo (A1_RISCO) = A - Riesgo A

Lím. Crédito (A1_LC) = 999.999.999,99

Venc Lím Cré (A1_VENCLC) = 31/12/2049

Registro de condición de pago - Industria - 001 - al contado

Código (E4_CODIGO): 001

Tipo (E4_TIPO): 1

Cond. Pago (E4_COND): 0

Descripción (E4_DESCRI): AL CONTADO

Registro de TES - Salida - Industria Sucursal SP - 514 - Remesa P/ Industrialización por pedido - ICMS suspendido (CST 50), IPI suspendido (CST 55), PIS y COFINS que no inciden (CST 08)

Código (F4_CODIGO) = 514

Créd. ICMS (F4_CREDICM) = N-No

Acredita IPI (F4_CREDIPI) = N-No

Genera Dupl. (F4_DUPLIC) = N-No

Actu.Stock (F4_ESTOQUE) = S-Sí

Poder Terc (F4_PODER3) = R-Remesa

Finalidad (F4_FINALID) = REMESA PARA INDUSTRIALIZACIÓN POR PEDIDO - ICMS

SUSPENDIDO, IPI SUSPENDIDO, PIS COFINS QUE NO INCIDEN

Calcula ICMS (F4_ICM) = S-SÍ

Calcula IPI (F4_IPI) = N-NO

Cód Fiscal (F4_CF) = 5901

Txt estándar (F4_TEXTO) = REM. IND. PEDIDO

Fisc ICMS (F4_LFICM) = O-OTROS

Fisc IPI (F4_LFIPI) = O-OTROS

Resalta IPI (F4_DESTACA) = N-NO

IPI en la base (F4_INCIDE) = N-NO

Cálc.Dif.Icm (F4_COMPL) = N-NO

Agrega valor (F4_AGREG) = S-SÍ

SIT. TRIB ICM (F4_SITTRIB) = 50

Pis/Cofins (F4_PISCOF) = 3 - AMBOS

Créd. Pis/Cofins (F4_PISCRED) = 4 - CALCULA

CÓD. TRIB IPI (F4_CTIPI)= 55

Tp Reg (F4_TPREG) = 1 - NO ACUMULATIVO

SIT. TRIB. PIS (F4_CSTPIS) = 08

SIT. TRIB. COF (F4_CSTCOF) = 08

Tab. Nat. Re (F4_TNATREC) = 4315

Cód. Nat. Rece(F4_CNATREC) = 999

Registro de TES - Entrada - Industria Sucursal SP - 011 - Devolución de mercadería remitida para industrialización por pedido - ICMS suspendido (CST 50), IPI suspendido (CST 05), PIS y COFINS que no inciden (CST 74)

Código (F4_CODIGO) = 011

Créd. ICMS (F4_CREDICM) = N-No

Acredita IPI (F4_CREDIPI) = N-No

Genera Dupl. (F4_DUPLIC) = N-No

Actu.Stock (F4_ESTOQUE) = S-Sí

Poder Terc (F4_PODER3) = D-Devolución

Finalidad (F4_FINALID) = DEVOLUCIÓN DE MERCADERÍA REMITIDA PARA INDUSTRIALIZACIÓN

POR PEDIDO - ICMS SUSPENDIDO, IPI SUSPENDIDO, PIS COFINS QUE NO INCIDEN

Calcula ICMS (F4_ICM) = S-SÍ

Calcula IPI (F4_IPI) = S-SÍ

Cód Fiscal (F4_CF) = 1902

Txt estándar (F4_TEXTO) = RET. REM. IND. PEDIDO

Fisc ICMS (F4_LFICM) = O-OTROS

Fisc IPI (F4_LFIPI) = O-OTROS

Resalta IPI (F4_DESTACA) = N-NO

IPI en la base (F4_INCIDE) = N-NO

Cálc.Dif.Icm (F4_COMPL) = N-NO

Agrega valor (F4_AGREG) = S-SÍ

SIT. TRIB ICM (F4_SITTRIB) = 50

Pis/Cofins (F4_PISCOF) = 3 - AMBOS

Créd. Pis/Cofins (F4_PISCRED) = 4 - CALCULA

CÓD. TRIB IPI (F4_CTIPI)= 05

Tp Reg (F4_TPREG) = 1 - NO ACUMULATIVO

SIT. TRIB. PIS (F4_CSTPIS) = 74

SIT. TRIB. COF (F4_CSTCOF) = 74

Pedido de venta

Encabezado del pedido:

Número (C5_NUM)= 000009

Tipo de pedido: (C5_TIPO) = B - Utiliza proveedor

Cliente (C5_CLIENTE) = SP0002

Tienda (C5_LOJACLI) = 01

Cli. Entrega (C5_CLIENT) = SP0002

Tienda Entrega (C5_LOJAENT) = 01

Tipo Cliente (C5_TIPOCLI) = R - Revendedor

Cond. Pago (C5_CONDPAG) = 001

Ítem del pedido:

Ítem (C6_ITEM): 01

Producto (C6_PRODUTO): PA0000000000000000000000000002

Cantidad (C6_QTDVEN): 1

Prc Unitario (C6_PRCVEN): 2.000,00

Val. Total (C6_VALOR): 2.000,00

C6_CONTA: SAI000001

Tipo Salida (C6_TES) 514

Para generar la clave del documento fiscal (prueba automatizada)::

Código de la UF emisora del documento fiscal = 35

CNPJ del emisor =

Modelo del documento fiscal = 55

Script de prueba

Factura de salida

Encabezado de la factura:

Tipo de Factura (F1_TIPO) = Normal

Form. Prop (F1_FORMUL)= NO

Número (F1_DOC) = XXXXXXXXX

Serie (F1_SERIE) = 199

Proveedor (F1_FORNECE) = SP0002

Tienda (F1_LOJA) = 01

Clase Doc (F1_ESPECIE) = SPED

Ítem de la factura:

Ítem Fact (D1_ITEM) = 0001

Producto (D1_COD) = PA0000000000000000000000000002

Cantidad (D1_QUANT) = 1

Val. Unitario (D1_VUNIT) = 2.000,00

Val. Total (D1_TOTAL)= 2.000,00

Tipo Entrada (D1_TES) = 011

C. Contable (D1_CONTA) = ENT000001

<Obtener número de la factura generada por el pedido mencionado anteriormente>

Docum Orig (D1_NFORI) = XXXXXXXXX

Serie Orig (D1_SERIORI) = 633

It. Doc Orig (D1_ITEMORI) = 01

Solapa Facturas de Crédito:

Cond. Pago (F1_COND) = 001

Naturaleza (E2_NATUREZ) = IND002

Para generar la clave del documento fiscal (prueba automatizada):

Código de la UF emisora del documento fiscal = 35

CNPJ del emisor = 36528684000146

Modelo del documento fiscal = 55

Resultado esperado:

SF3

Fecha de entrada (F3_ENTRADA)= Mes anterior a la fechabase

Fecha de emisión (F3_EMISSAO)= Mes anterior a la fechabase

Número de la factura (F3_NFISCAL)= xxxxxx

Serie (F3_SERIE)= 199

Cliente/Proveedor (F3_CLIEFOR)= SP0002

CFOP (F3_CFO)= 1902

Estado (F3_ESTADO)= SP

Valor contable (F3_VALCONT) = 2.200,00

Base ICMS (F3_BASEICM) = 0,00

Valor ICMS (F3_VALICM) = 0,00

ICMS exento (F3_ISENICM) = 0,00

ICMS Otros (F3_OUTRICM) = 2.000,00

Base IPI (F3_BASEIPI) = 0,00

Valor IPI (F3_VALIPI) = 0,00

IPI Otros (F3_OUTRIPI) = 2.000,00

IPI exento (F3_ISENIPI) = 0,00

SFT

Número de la factura (FT_NFISCAL) = xxxxxx

Serie (FT_SERIE) = 199

Fecha de emisión (FT_EMISSAO) = Mes anterior a la fechabase

Cliente/Proveedor (FT_CLIEFOR) = SP0002

Fecha (FT_LOJA) = 01

CFOP (FT_CFOP) = 1902

Ítem (FT_ITEM) = 0001

Alíc ICMS (FT_ALIQICM) = 0

Valor contable (FT_VALCONT) = 2.200,00

Base ICMS (FT_BASEICM) = 0,00

Valor ICMS (FT_VALICM) = 0,00

ICMS exento (FT_ISENICM) = 0,00

ICMS Otros (FT_OUTRICM) = 2.000,00

Base IPI (FT_BASEIPI) = 0,00

Valor IPI (FT_VALIPI) = 0,00

IPI Otros (FT_OUTRIPI) = 2.000,00

IPI exento (FT_ISENIPI) = 0,00

Tipo (FT_TIPO) = EN BLANCO

IPI en la Observación (FT_IPIOBS) = 200,00

Base PIS cálculo (FT_BASEPIS) = 2.000,00

Valor PIS cálculo (FT_VALPIS) = 33,00

CST PIS (FT_CSTPIS) = 74

Base COFINS Cálculo (FT_BASECOF) = 2.000,00

Valor COFINS Cálculo (FT_VALCOF) = 152,00

CST COFINS (FT_CSTCOF) = 74

Fecha de anulación (FT_DTCANC) = EN BLANCO

Observación(FT_OBSERV) = Dev. terc. N.F.ORIG.: ​Número de la Fact generada por el pedidoo

4.2. Si el programa está automatizado, evidencie la ejecución de todos los casos de pruebas en el AdvPR y/o TIR, mostrando que a pesar de la modificación propuesta, ningún caso de prueba antiguo volvió a fallar.

La evidencia de ejecución local o Smart Test son válidas para este proceso.

4.3. Fuente modificado con versión y changeset utilizado como base (envíe el fuente compatibilizado con la última modificación en la fecha del envío).

4.4. Texto con descriptivo del ajuste para Check In.

4.5. Sub-task de codificación de la issue (Squad que solicita la modificación) donde se realizará el check-in.

4.6. En el caso de crear la CH, tablas, índices, campos, disparadores, consultas estándar y parámetros, envíe también en este documento TODOS LOS DETALLES que se refieren a la creación/modificación de los mismos.

También es válido el informe del paquete de la base de datos ATUSX con las informaciones de los ajustes realizados.

4.7. Importante: La creación de funciones específicas para módulos que no son los "dueños" de los fuentes, se debe realizar en fuentes propios. Es decir, en el fuente (motivo de apoyo de subir) solamente debe constar las protecciones del módulo/existencia de la nueva función, y el ticket de esta nueva función.

Esta observación también tiene validez cuando la situación es específica para una localización, como por ejemplo, Localización Brasil o Localización Argentina.

4.8. Si aparecen fallas futuras en los Script de pruebas creados por los equipos solicitantes, el equipo "Dueño del programa" evaluará y tratándose de un problema del equipo solicitante, se pedirá su corrección.




5. Procesos específicos para central colaborativa 

5.1. Punto de entrada: 

Punto de entrada no se considerará como mejora en la central colaborativa y debe seguir el siguiente proceso:

5.1.1. Solicitud del cliente: 

Hacer la alineación con los P.O. antes de la apertura.

El Product Owner evalúa si el punto de entrada hace sentido y si se debe realizar

El Product Owner realiza el presupuesto en horas de desarrollo para los puntos de entrada aprobados

El Product Owner devuelve la respuesta al suporte con el presupuesto en horas, macro objetivo y objetivo detallado para el desarrollo

Después de responder al P.O. el soporte abre la issue de punto de entrada al producto

El Product Owner prioriza la creación del punto de entrada y lo devuelve al cliente.

5.1.2. Solicitud del equipo de servicios:

CEl consultor envía un e-mail al Produt Owner y realiza la apertura del ticket con la solicitud del presupuesto

PEl Product Owner evalúa si el punto de entrada hace sentido y si se debe realizar

PrEl Product Owner realiza el presupuesto en horas de desarrollo para los puntos de entrada aprobados

PElProduct Owner estable el precio del costo de desarrollo según la regla de determinación de precio de la Tribe involucrada y envía el presupuesto al área de servicios por e-mail, solicitando la respuesta con la aceptación del presupuesto y el suministro de los datos financieros (Centro de costo / Ítem y clase contable) para cobrar el costo mediante el workflow de Transferencia de Gestión en el Fluig, y pone en copia en el e-mail al PMO de Ingeniería Protheus ([email protected]);

El Product Owner abre una issue para crear el punto de entrada

El Product Owner prioriza la creación del punto de entrada y lo devuelve al consultor.

Importante: Si el Product Owner no ve sentido en crear el punto de entrada, el mismo Product Owner debe responder al consultor.

5.2. Definición de mejora / Error de concepción

Si la funcionalidad puesta a disposición con la documentación está realizando el resultado documentado, el entendimiento es de mejora.

Si la funcionalidad no está haciendo lo que está documentado, entonces es Error (sea en la documentación o en el producto).

Si el entendimiento final no es error de concepción o mejora, se debe alinear con el P.O. y si es necesario documente el concepto de la funcionalidad.


5.3. Definición del límite para la primera interacción en la Central Colaborativa

90 dias.

5.4. Definición de quien puede/debe realizar la interacción en la Central Colaborativa

Product Owner, Proxy PO y sustitutos en la ausencia del Product Owner.

5.5. Uso de funciones estándares disponibles para personalizaciones / Documentación de la función

No debe entrar como Central Colaborativa

Se debe realizar la alineación con el P.O. y después de esto la apertura de la issue del tipo Documentación.

Importante: Funciones que no están a disposición ni documentadas en el TDN, no se deben utilizar para personalizaciones, porque en cualquier momento puede sufrir cambios y el equipo no se responsabilizará por posibles reflejos. Si el Product Owner define que la función no se puede utilizar para personalización, el mismo Product Owner debe responder al soporte, que oficializará para el cliente.

6. Soporte > Desarrollo - Procedimiento para Issues de apoyo

Situación

Procedimiento

El apoyo solamente se abrirá si está alineado con el Product Owner o Maestro.

Alineación entre PO / Maestro o Líder

Evidencias de prueba (paso a paso, fecha de fuentes, etc.)

Issues de apoyo recientes
Actuar en el apoyo, sin necesariamente activar al soporte, en caso de duda en la demanda, entre en contacto con el analista y formalice por e-mail con copia para el líder.
Si hay divergencia de parecer entre el desarrollador y el analista de soporte, involucre al Maestro o Líder.

Realizar apoyo.

Seguimiento semanal del plazo de respuesta de apoyo al soporte y Aging.

Incluir la issue de apoyo, cuando esté abierta, en las sprint, de esta manera se programará la entrega. Pero si algo más urgente aparece, y si es necesario programar nuevamente, debemos incluir al soporte en nuestras reuniones semanales.

Dashboard Seguimiento de apoyos

Apoyos relacionados a la legislación

Adjuntar la issue al parecer de la consultoría tributaria

Apoyos relacionados al desempeño

Adjuntar el LogProfile, generado con MV_LOGPROC habilitado, sin personalizaciones o punto de entrada (no se aceptará si tiene personalizaciones)

LogProfiler - Como ejecutar

Apoyo relacionados a cálculos 

Adjunte la issue a la memoria de cálculo

Apoyo con necesidad de debug

Verifique si el cliente tiene entorno de homologación idéntico al de la producción y suministre los datos de acceso 


7. Soporte > Desarrollo - Procedimiento para Issues de documentación

Situación

Procedimiento

Documentaciones con informaciones incorrectas.
Documentaciones con errores de ortografía.
Documentaciones faltantes - Nuevos procesos y rutinas

Entrega de diccionario de datos (Preguntas, Disparadores, Tablas y Campos)

Apertura de Issue de documentación. 

De acuerdo con el modelo Modelo de Issue de Documentación

Nuevas funcionalidades - Soporte analiza la documentación de la funcionalidad e indica puntos de mejoras.
La aceptación de la documentación para expedir el producto es del Product Owner.

Apertura de Issue de documentación.

De acuerdo con el modelo Modelo de Issue de Documentación

Issue abierta como “Mantenimiento”, pero el Product Owner entiende que se trata de concepto, pero no existe documentación.

Rechazar la ISSUE de mantenimiento y solicitar la apertura de una issue de documentación - Modificar el tipo de la Issue para documentación, solamente en casos excepcionales, que serán evaluados por el PO (por ejemplo, creación de un nuevo control en el que no existe documentación técnica)

Issue abierta como “Mantenimiento”, pero el Product Owner entiende que se trata de concepto, el concepto ya está documentado

Rechazar para la atención, informando el enlace y con alineación previa

Product Owner es el responsable en evaluar si la documentación está efectiva o no y cumple con las reglas de apertura de issue, según la Resolución de Trabajo | Procedimiento antes de rechazar o no rechazar una Issue

Si hubiera el entendimiento de la efectividad de la documentación, la issue se recusará, con la explicación del motivo de rechazo.

Rechazar, con alineación previa

Si se identifica la necesidad de ajuste en el fuente (por ejemplo inclusión de enlace), el Product Owner convierte la issue en Story/Mantenimiento

Conversión a Story/Mantenimiento

Cuando sea necesario actualizar en el fuente, no habrá paquete puntual, solamente se actualizará por medio del paquete acumulado. (retirar)

Expedición continua.

En el caso de los help en el diccionario, dependerá de que cada módulo tenga o no un paquete vinculado a la expedición continua. Si no existe, este help se actualizará solamente en el siguiente release (ejemplo Fact, Sto, etc).

Expedición Continua / Release.

7.1. Notas sobre Issues de documentación

  • Cuestiones técnicas, como las citadas a continuación, se atenderán puntualmente como apoyo:
    • Utilización de tablas
    • Utilización de campos
    • Detalles de funcionamiento de rutinas 


  • Execauto y punto de entrada.

Si no existe, vamos a crear el enlace y colocar los ejemplos más utilizados 



8. Soporte > Desarrollo - Procedimiento para repase de funcionalidades

Situación

Procedimiento

Nuevas funcionalidades - La documentación de la funcionalidad debe servir como guía (paso a paso) para el cliente. (retirar)

PO: Aceptación de la documentación en el modelo paso a paso. 

Nuevas funcionalidades - Pequeñas mejoras: 

La documentación de la funcionalidad debe servir como guía (paso a paso) para el cliente.

Repase por medio de las Reviews.

Presentación en la Review

Nuevas funcionalidades - Medianas y grandes: 

Alinear con el Líder/Maestro la necesidad de que realicemos o no las capacitaciones presencial/On Line.
Documentación debe seguir los modelos reportados en la última reunión (paso a paso).
Repase por medio de las Reviews.

Presentación en la Review

Alineación con el soporte


<style>
div.theme-default .ia-splitter #main {
    margin-left: 0px;
}
.ia-fixed-sidebar, .ia-splitter-left {
    display: none;
}
#main {
    padding-left: 10px;
    padding-right: 10px;
    overflow-x: hidden;
}

.expand-control-text {
    color: #000000;
	font-size: 13px !important;
	font-weight:bold !important;
}

.expand-icon, .aui-icon, .aui-icon-small, .aui-iconfont-chevron-right {
    color: #FF8000;
}

.aui-header-primary .aui-nav,  .aui-page-panel {
    margin-left: 0px !important;
}
.aui-header-primary .aui-nav {
    margin-left: 0px !important;
}
</style>