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).
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)
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
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.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.
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 | 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) |
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 |
Situación | Procedimiento |
|---|---|
Documentaciones con informaciones incorrectas. 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. | 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. |
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. | Presentación en la Review Alineación con el soporte |
