CARTA CONSTITUTIVA

\
Profuturo MANTENTM rENTo Y AcruALtzAclórr¡

NOMBRE DEL MANTENIMIENTO: Mejoras al proceso de Aportaciones Voluntarias en PeopleSoft

NOMBRE DEL PROCESO / SISTEMA: Cuentas a cobrar / PeopleSoft

TIPO DE MANTENTMTENTO: ESTRATÉGICO (X ) i¡ORMAT|VO ( ) MEJORA ( )

FECHA EN QUE ENTRA EN VIGOR:

SOLICITANTE: oFrcrNA DE ADMrNrsrn¡clóu oe

PROYECTOS

MA DE LOSX§I(
GTE DE CONT
CHAVEZ NAVARRO
ILIDAD GENERAL .r'"fu¡
/ o*Lr
MARIA IRENE RUBIO GONZALEZ DANIEL IGNACIO PEREGRINO
DIR DE FINANZAS
Rodolfo Milla Vilchis

RESPONSABLE DEL PROYECTO: ,.yoÉ soucrruo : 2e-06-2017

4/crae coNTRoL DE PRoYECTos:

?e cioe- ?r.r1o R,i,P at -rr1 - t1

OBJETIVO GENERAL: I

Mejorar el proceso de Aportaciones voluntarias y comisión por saldo, reduciendo los cobros manuales para automatizarlos.

ALCANCE:

PeopleSoft Cuentas a Cobrar

BENEFICIOS ESPERADOS:

ldentificación de /as aporfaciones voluntarias de los clientes de manera más sencilla

Reducción de tiempos.

DESCRIPCION GENERAL DEL REQUERIMlENTO Y SU FUNCIONALIDAD:

Actualmente se procesan los depósitos de los clientes realizan por las aportaciones voluntarias por el módulo de cuentas a cobrar
con la información proveniente del sistema de Apovol central, y se valida dicha información con los extractos bancarios que se
cargan a Peoplesoft mediante el estado de cuenta.

Sin embargo un incremento en la operación de las aportaciones más cambios en los bancos han hecho que la identificación de esos
depósitos y su cobranza sea un proceso manual, lento y propenso a errores.

Por lo anterior se tienen contemplados atacar esta situación con tres meioras:

OFICINA DE ADMINISTRACIÓN DE PROYECTOS Página 1 de 17

 CARTA CONSTITUTIVA
Profuturcr' MANTE N IM IE NTo Y AcruALrzAclór.¡

. Mejoras a las referencias de la carga de estados de cuenta

. Mejoras a la interfaz de cobros
' Mejoras a la interfaz Contable

Mejoras a las referencias de los estados de cuenta

Para una mejor identificación de los depósitos que hacen los clientes se requielen modificar las referencias que hoy en día se cargan
a PeopleSoft vía carga de estado de cuenta (PFEDOCTA) ampliando las referencias en la mayoría de los casos de acuerdo a lo que
a continuación se especifica:

BANCOMER

Para la carga del estado de cuenta de Bancomer la referencia se va a ampliar para todas las transacciones marcadas como
depósitos, que no hayan sido identificadas como un deposito proveniente de un traspaso vÍa tesorería, dicho valor corresponderá al
valor del campo "referencia numérica ampliada" del LayOut de Bancomer considerando lo siguiente:

Cada transacción de Bancomer consta de dos líneas, los registros que inician es sus primeras dos posiciones con una línea 22
corresponden a los datos principales de la transacción y en la siguiente línea invariablemente aparece un registro marcado con inicio
23 en las primeras dos posiciones que corresponden a detalles e información adicional, el campo que se va a tomar corresponde a la
referencia ampliada que está en esta segunda línea, esto es de la posición 43 de la linea; el campo tiene una longitud de 38
posiciones hacia la derecha, sin embargo el campo RECON_REF_ID de la tabla PS_BANK_STMT_TBL solo tiene 15 posiciones por
lo que es necesario contar quince posiciones de izquierda a derecha del archivo de Bancomer, en caso de que la referencia
recuperada sea menor a las quince posiciones, no rellenar con espacios vacíos a la derecha en caso de que no existan valores que
no cumplan con la longitud. Ejemplo:

220074998 170405170405 Y01200000005000000 cE00000000089991989602

230 1 00000000000000000000000003009't 0582907 2221 395

La referencia corresponde al valor: '2221395'

Una vez obtenido este valor es el que se va a cargar al campo RECON_REF_ID de la tabla PS_BANK_STMT_TBL y será la
referencia del depósito.

BANAMEX

Para la carga del estado de cuenta de Banamex la referencia se va a ampliar para todas las transacciones marcadas como
depósitos, que no hayan sido identificadas como un deposito proveniente de un traspaso vía tesorería, dicho valor puede variar
dependiendo del Códigos y Subcódigos corresponderá al valor del campo Referencia numérica y Referencia alfanumérica del
LayOut de Banamex considerando lo siguiente:

Campos Código y Subcódigo

Estos campos nos van a permitir identificar el tipo de transacciones que tiene el archivo, en el caso de Banamex cada transacción
está definido por una línea, el campo Código consta de una longitud de dos caracteres contados a partir de la posición 2, de la misma
manera el campo subcódigo consta de una longitud de dos caracteres contados a partir de la posición 55.

Depósitos de Domiciliación

En caso de depósitos de Domiciliación Banamex (Se pueden identificar estaé transacciones por el Código 60 Sub código 58) se
requiere la referencia numérica del LayOut del archivo Banamex que inicia en la posición 8 y tiene una longitud de 10 caracteres de
izquierda a derecha. No rellenar con espacios vacios a la derecha en caso de que no existan valores que no cumplan con la longitud.
Ejemplo:

A600859000617 71 SABONO L tQ DOM r CHQ.O0000000000 1 44500058

Página 2 de 17
 -\r CARTA CONSTITUTIVA
Profuturo MANTENTM rENTo Y AcruALrzecró¡¡

La referencia a considerar es: 0006177148

Una vez obten¡do este valor es el que se va a cargar al campo RECON_REF_ID de la tabla PS_BANK_STMT_TBL y será la
referencia del depósito.

Depósitos restante

Corresponde a la referencia alfanumérica del Layout del archivo Banamex que inicia en la posición 18 y tiene una longitud de 20
posiciones. considerar las primeras qu¡nce posiciones de izquierda a derecha. No rellenar con espacios vacios a la derecha en caso
de que no existan valores que no cumplan con la longitud. Ejemplo:

A150519000003009103300455379 0000000000010000000

La referenc¡a a considerar es: 3300455379

SCOTIABANK

Para el caso de Scot¡aBank el campo referencia numérica que actualmente se carga es el correcto, mas sin embargo para el caso de
las transacciones marcadas como depós¡tos se sol¡c¡ta cargar el total de la referenc¡a de 10 posiciones ya que actualmente se cargan
solo 6 posiciones. Ejemplo:

001 ;00000000001579266:2017101126i9988003998;30000.00;ABONO;POR COBRANZA C/RECIBO FIRME;90391 .88

Donde la referencia va en el cuarto campo cons¡derando las "comas" como separadores, la referencia a considerar es: 9988003998,
actualmente solo carga: 003998

Una vez obtenido este valor es el que se va a cargar al campo RECON_REF_ID de la tabla PS_BANK_STN¡T_TBL y será la
referencia del depósito.

Mejoras a la interfaz de cobros

Para la interfaz de cobros (Aplication Engine) actualmente valida los depósitos d'e las cuent¿s del extracto bancario contra los ltem's
pendientes siguiendo el s¡gu¡ente proceso:

1.-Valida el número de cuenta bancaria y el impole del deposito

2,-En caso de que encuentre concordancia aplica el deposito al ltem seleccionado y crea un deposito exprés,
3.-En caso de que no exista una concordancia o haya más de un ltem pendiente por el importe del depós¡to, crea un depos¡to
Estándar

Con la modificación el proceso seria el siguiente:

1.-Valida el número de cuenta bancaria y el importe del deposito

2.-En caso de que encuentre concordancia aplica el depós¡to al ltem selecc¡onado y crea un depósito exprés.
3.-En caso de que no exista una concordanc¡a buscará el ltem con el siguiente formato:

Del depósito toma el valor de la tabla PAYMENT en el campo PAYI\4ENT lD, ese valor lo va a comparar contra el campo de ITEM-ID
de la tabla ITEM que vendrá con el s¡guiente formato:

CCC-DDMMAARRRRRRRRRRRRRRR

Dónde:

CCC.- Corresponde a un consecutivo para prevenir que en caso de que la referencia de la transacc¡ón se repita se genere un error,
rellenando ceros a la derecha. Ejemplo: 001,
DDMMAA.- Corresponde a la fecha del depós¡to en el formato Día, Mes y Año. Eiemplo 2806'17.
RRRRRRRRRRRRRRR.- Corresponde a la referencia ¡dent¡ficada por el área de Aportac¡ones Voluntarias a partir de la posición 10,
referencia puede ser variable en long¡tud teniendo como máximo 15
 CARTA CONSTITUTIVA
Profuturo" MANTENTMTENTo Y AcruALtzAclóru

La referencia RRRRRRRRRRRRRRR, recuperada compararla con el valor extraído del campo RECON_REF_lD de la tabla
PS_BANK_STMT_TBL que trae el depósito. En caso de ser iguales se valida que los importes entre depósito y ltem sean iguales
aplica el depósito al ltem seleccionado y crea un depósito exprés.

4.- En caso de el paso anterior devuelva más de un registro el criterio de selección se dará por la fecha del depósito (Campo
RECON_BANK_DT de la tabla PS_BANK_STMT_TBL) y la fecha que se extrajo del ld del ltem en el paso 3, en caso de existir una
concordancia aplica el depósito al ltem seleccionado y crea un depósito exprés.

S.-En caso de no exista una concordancia o haya más de un ltem pendiente por el ímporte del depósito, crea un deposito Estándar

Consideraciones

Las validaciones solicitada son adicionales a las validaciones ya hechas y no substituye ninguna regla, actualmente el programa hace
una validación de Grupos de ltems contra un depósito, es este caso la modificación aquí presentada no es aplicable ya que al ser un
grupo de ltems el programa no va a poder hacer los amarres de manera correcta.

lnterface de Cobros para días Anteriores

Se solicita Clonar el proceso (Pf*AR_COBROS proceso Aplication Engine) en los pasos para la creación de los depósitos Exprés,
con la finalidad de que recorra los depósitos sin aplicar ya creados, esto es depósitos de la tabla PS_DEPOSIT_CONTROL que
tengan en el campo DEP_POST_STATUS <> 'C'y el campo PAY_WS_TYPE = 'P'; en vez crear Depósitos con los extractos
bancarios.

Posteriormente y tal cual lo hace el programa actualmente busque el ltem con el siguiente formato:

CCC.DDMMAARRRRRRRRRRRRRRR

Solo en caso de que encuentre una concordancia de la referencia con la fecha del depósito e importe aplicara el depósito y generara
un depósito Exprés llenado los campos faltantes mediante el Component lntelace ya existente en el programa original.

Es importante aclarar que en este caso el modo de entrada del Component lnterface no es en modo de añadir un registro nuevo sino
de actualizar uno existente.

Los parámetros a actualizar son:

De la página PAYMENT_EXPRESS2

Tabla
PAYMENT-ID_ITEM

Campos

ITEM
ITEM_LINE

OFICINA DE ADMINISTRACIÓN DE PROYECTOS Página 4 de 17

 CARTA CONSTITUTIVA
P rofut uro MANTENT M r ENTo y AcruAr-¡zeclór.l

¡ ltbr¿r : asijfns r agilrns €¡ lrrÉ:r :

kií:nr.r fjalci: Er.ltsfii, ' ¡"', .-,

(¡nrl(¡fl. P.¡Fj' i,11-:t ' 1;'it

Cu9rilü 8¿na¿r[] 41.' hnDl¡ fot¿l (:ontr¡l' 1r:c ?;t :r:¡ ;,1 Rrio:

Oerñ$¡ic ír¡¡a,l¡ds S l!¡§la Fr)l¡l lf l #l¡aiilor I io tr:1 ::'i ij: RBltrenlo

lml?nr$ Orforelilal n. I RBrIc¡lo

' li:r P!l'

1¡:1 r-r,i r:: )a

lnrSrftq 't:i r )i:

Méloda pif¡o: fta'i:r:rúa.:é t il'tr Ffr t §eler:l 1l ii.

[s{0d0; 5ú !lÍi: Dlol il'la lL:l-:.ii.,,:f.f:
::rl.i:.::l :,1; :::.::.,t:.i:..::..-

Asrg$¿clol Cobro§ Rtsl¿nle: !!.r..'tf:;¡( .. :irl!i.!! -t._. ::::).i- i'::,:,::::!.::t.t.i;.::i

¡rS{ia §1M4, 11) }q..,qe:r'ñ f) tbl U{ Ikr¿uenla i¡rhp

r,r' Our6r r,¡ !t e . Eq*!r '. i h6w cn L* ¡ .Sfufrle rn t4l¡ .r,.:i xotitur Ü áchdw i i A¡túr Acra{Eü.]{ar

'_1:3lj-r --.':¡: :. t'

Y actualizar los botones de Crear y Bach Estándar de la pagina PAYMENT_EXPRESS3

ldtoñ)n L)ñlús: E::fflol ' I

PnFrlr ilep: ElifrmerDspó§foRápldo

lJniHeg: l{.1 §TiirlJ2!'}

C¡r¡dre Deno$itor i.Lr¡drr{lo

[:ech¿l,Itrodu,:t(l¿; U6:Agr:úli
E sta(i.,: l,! (.inl:

il;rl Güaci§ :i''Vdt€,aBa8car r:A¡ta¡€,flLilla + lsrquiürleenl¡ló :r l¡ct¡,ier ;llclual<ar +Añadir At!41/n3uátr6r

¡"a.: - ',' .:_ .'

Los parámetros de ejecución son los mismos que los del programa original.

orrcrñn DE ADMrNrsrnncróru DE pRoyEcros Página 5 de 17

 CARTA CONSTITUTIVA
Profuturo MANTEN ¡ M r ENTo Y AcruALlzActór.l

Mejoras a la interfaz contable

Actualmente se recibe un archivo de texto para generar pólizas contables, se quiere hacer una interface por inserción de datos que
permita eliminar la dependencia de los archivos de texto VOLUNTI.

Esta interface contable debe ser configurable a fin de soportar diversos orígenes de datos, para lo anterior es necesario una página
de configuración que nos permita mapear varias tablas con varios orÍgenes distintos

' ......:.

lJnirlJ{l i¡qg.rrrir' F;F i :

.S.tiiil:::it lt trrl
,l lt ?jj:s-i l tt)tlr.t.l.Ln...1..3 irl¡.¡
?r i, ¡1 l. r?i, r.
' -1 ::_ j;Er_. f ,.
. qF FL_ : L -i -:: ,i
I Fif:i: Fi.)l FF.ii | _jrñ i:' J.,::i ríl
3 F:DE:' : EDit: pF:_ilFiF,¿if'9ta; A:r:ro , ,.
.1 : ir l:: , !;i,,ir;:: ¡:f ¿:.r: i-ra 'i.:,i: ir,:i:tc, +
'

,\: Guudlr rl' Vp¡s ¡ Euss A¡lsis en Lrsl¡ ; ; SsuÉñiÉ s L€l¡ 'Íl fiol,taar + Añ¿dr Ad¿,1,riiualf,¡r

La tabla para construir es la PF_CIFGL_APV

La estructura de la tabla es la siguiente:

Nombre del
Campo
BUSINESS UNIT Por default PAF01 a APVOL
PF TRAN ID ld único para identificar la transacción
PF_IDPROCESO ld que va a identificar los registros en Se sugiere elsiguiente Catalogo:

ACCOUNTING DT Fecha Contable de la Transacción

CURRENCY-CD Moneda, Valor por Defecto MXN, en caso de que el importe sea en acciones se
especifica en este campo
Monto de la transacción,

Por default "N" que indica que PeopleSoft no ha tomado la transacción

oFrcrNA DE ADwrNtsrRlcróru DE pRoyEcros Página 6 de 17

 CARTA CONSTITUTIVA
Prufuturo MANTEN rM r ENTo y AcruAl-¡zeclór.l

Numero de Secuencia

El Flujo de la lnterfaz es el siguiente:

lnterfaz Contable PeopleSoft - MIT

Siefores Afore

(¡)
!
o
Status N

f
I rn."rt".n clp cr I
E;;-'.;;¡
>l con
y Cruza
Cambia

l'T"l
I
Status a R
o
U) [r."ror."rl
-9
o-
o
Lo [-t-,,r-"J
fltaure ]

Cabe mencionar que esta información es complementaria a la lngresada en los ciclos de pagos para lngresos y
egresos.

Para el caso de aportáciones voluntarias, se espera que los conceptos del archivo Volunti queden como a
continuación se muestra :

oFrcrNrA DE ADMiñrsrnncróru DE pRoyEcros Página 7 de 17

 CARTA CONSTITUTIVA
Profuturo MANTEN!M!ENTo Y AcruALtzActóru

PIANTILLA TIPO BCO NOMBRE

PECPBBVA COR-PLAZO PESOS CP BBVA Pesos Corto Plazo BBVA
PECPBNMX COR_PLAZO PESOS CP BNMX Pesos Corto Plazo BNMX
PECPSCOT COR-PLAZO PESOS CP SCOT Pesos Corto Plazo SCOT
PECPBNXC COR-PLAZO PESOS CP BNXC Pesos Corto Plazo BNXC
PELPBBVA COR_PLAZO PESOS LP BBVA Pesos largo Plazo BBVA
PELPBNMX COR_PLAZO PESOS LP BNMX Pesos largo Plazo BNMX
PELPSCOT COR-PLAZO PESOS LP SCOT Pesos largo Plazo SCOT
PELPBNXC COR_PLAZO PESOS LP BNXC Pesos largo Plazo BNXC
ACCPBBVA LAR_PLAZO ACCIONES CP BBVA Acciones Corto Plazo BBVA
ACCPBNMX LAR_PLAZO ACCIONES CP BNMX Acciones Corto Plazo BNMX
ACCPSCOT LAR_PLAZO ACCIONES CP SCOT Acciones Corto Plazo SCOT
ACCPBNXC LAR_PLAZO ACCIONES CP BNXC Acciones Corto Plazo BNXC
ACLPBBVA LAR-PLAZO ACCIONES LP BBVA Acciones Largo Plazo BBVA
ACLPBNMX LAR-PLAZO ACCIONES LP BNMX Acciones Largo Plazo BNMX
ACLPSCOT LAR_PLAZO ACCIONES LP SCOT Acciones Largo Plazo SCOT
ACLPBNXC LAR_PLAZO ACCIONES LP BNXC Acciones Largo Plazo BNXC

Ejemplo detabla con el llenado de la lnformación proveniente de MlTAfore:

iS UNIT PF TRAN ID PF IDPROCESO ACCOUNTING DT CURRENCY CD AMOUNT STATUS SEQNO VISI

PAFOl 3 104170001 PECPBBVA 37/0412011 MXN 4,38 N 0 1

PAFOl 3104170002 PECPBNMX 3Ll04/20L7 MXN 3,935.94 N 0 1

PAFOl 3104170003 PECPSCOT 3tl04/2017 MXN 3s,003.03 N 0 1

PAFOl 31041.70004 AECPBBVA 3u04/20t7 MXN 100 N 0 1

PAFOl 3 104170005 AECPBNMX 31.10412077 MXN 450000 N 0 t-

PAFOl 3104170005 AECPSCOT 31.10412017 MXN 3s00000 N 0 t

1.-Una vez insertados los registros por operaciones se corre el "Proceso de creación de Pólizas", el sistema
deberá considerar para la creación de las Pólizas un catálogo de mapeo como sigue:

Tabla de Cabecera delcatálogo para la generación de la Póliza:

BUSINESS UNIT Campo referente a la Unidad de Negocio

LEDGER_GROUP Campo referente al Grupo Contable
Origen de la Póliza
Campo referente a la Contabilidad

DE ADMrNrsrRRctóN DE pRoyEcros Página 8 de 17

-orrcrnÁ
 CARTA CONSTITUTIVA
\
Profuturo' MANTENTMrENTo Y AcruALtzAclóru

ID PLANTILLA Nombre de la plantilla

Descripción de la Póliza

Tabla de Detalle delcatálogo para la generación de la Póliza:

BUSINESS_UNIT Campo referente a la Unidad de Negocio

LEDGER GROUP Campo referente al Grupo Contable
Origen de la Póliza
Campo referente a la Contabilidad
ID PLANTILLA Nombre de la plantilla
Numero de Proceso de acuerdo al catálogo anterior

Valores posibles:

Cargo. Movimiento que se carga en la póliza

Abono. Movimiento que se Abona en la Póliza (-)
NA. No aplicable, Esta opción solo estará disponible
cuando el modo de cuenta-contra cuenta este
encendido, la naturaleza del cargo lo dará el
movimiento de cuenta y el de abono el movimiento de
contra cuenta.
SIGNO. Se cargara o abonara de acuerdo al signo que
traiga la tabla, es decir Positivos Cargos, Negativos
Abonos.

Número de Secuencia con la que aparecerán los

registros en la póliza
SIGNO.-

ALTACOUNT Cuenta Alternativa

Estará Apagado por default y cuando este encendido

indicara que con un solo importe hará un cargo y un
abono dados por los campos ACCOUNT y
CNTR-ACCOUNT

ffipnovrcros Página 9 de '17

 , ..
CARTA CONSTITUTIVA
Profuturo" MANTENTMTENTo Y AcruALtzAc¡óru

Estará Apagado por default y cuando este encendido

indicara que esta línea se calculara a partir de la suma
de al menos dos líneas
Líneas a Sumariar cuando el campo SUM_ON este
SUM REG encendido
CONTR ACCOUNT Contra Cuenta
CONTR ALTACOUNT Contra Cuenta Alternativa
Contra Departamento
Contra Producto

Acontinuación se muestra un ejemplo de cómo se llenara elcatalogo

PAFOI REAT APV OIARIA 2AVIIND ¡NDIVIDUALI2ACION APOVOL

PAFO1 REAI APV UANIA coR Puzo pEaPBEva NA 1 711@1@ 71 5N 7214mlm )21ffiñ
PAFO1 ¡EAL APV OIAiIA COR PUZO PTCPBNMI NA 2 7u@1@ 71l4m SN 721@1m 7?l@m
PAFO1 REAT APV O1A¡IA coR_Puzo PtcPscor NA 3 7ll@¡@ 7¡14@ 5N 7214m1m 721@&
PAÉ01 BEAI APV OIAf,IA co8_Puzo CARGO 4 7l14m1m 7114@ N S 1,2,3 7?14m1m 721@re
PAIO1 NEAT APV DIARIA ABONO 5 7ll4m1m 711m N s 1,2,3 721¿m1@ 721m&

2.-El cruce de los registros de la tabla PS_PF_CIFGL_SAD con el catalogo del punto anterior dará como
resultado las pólizas contables, el proceso de Generación de Pólizas deberá Cambiar el status de las
transacciones de Apovol MIT a "R" para considerar las transacciones como Leídas y no volver a generar una
póliza.

Comisión por Saldo

Actualmente el proceso de comisión por saldo funciona de manera adecuada, sin embargo para los inicios y
fines de mes se tiene un problema la forma en que se contakiilizan los registros en fines de mes y siempre y
cuando haya dÍas inhábiles de por medio.

Actualmente cuando las Siefores envían información el último día hábil del mes y los subsecuentes días son
inhábiles o festivos se des contabilizan dichos registros a fin de darles el correcto registro en el mes
correspondiente.

Por ejemplo, considere el 30 de Diciembre de 201.6, las Siefores envían el Viernes 30 de Diciembre la comisión
por Saldo que se va a pagar del día Lunes 2 de Enero, con un valor de 5600,000 pesos MXN, este cálculo está
considerando tres días, Viernes 30, Sábado 3L de Diciembre y Domingo 1 de enero de Enero, siendo esto
correcto de acuerdo a las reglas con las que operan las Siefores.

OFIC[.IA DE ADt\¡INIISTRÁEIÓN DE PNOYCCTOS Página 10 de 17

 _\rr CARTA GONSTITUTIVA
Profuturo MANTEN ¡ M r ENTo Y AcruALrzAcrórr¡

El registro que actualmente se da queda de la manera siguiente:

Diciembre Enero
Vie Sab Dom Lun Mar
30 31 1. 2 3
Cuenta por Cobrar Pago
s 600,000.00 MXN s 600,000.00 MXN

Bajo las reglas de las Siefores esto es correcto, sin embargo para la Afore la forma correcta de registrar es por
meses completos, es decir la parte proporcionar que corresponde al mes se registra al mes que pertenece,
quedando de la manera siguiente:

Diciembre Enero
Vie Sab Dom Lun Mar
30 31 1 2 3
Cuenta por Cobrar Cuenta por Cobrar
s400,000.00 s 200,000.00 MXN
Pago
s600,0Óo.oo MXN

Lo anterior debido a que la afore considera el monto de la comisión entre tres partes aritméticamente iguales;
el 30, 31, de diciembre y el 1. de Enero. El 30 y 31 de Diciembre se considera dentro del importe de diciembre y
hace un registro el último dÍa hábil del mes, es decir el 30 del mes mencionado. Las partes resaltantes al estar
en enero se consideran parte de ese mes y se registran con fecha 2 de Enero que es el próximo día hábil
siguiente,

Actualmente el programa no soporta dichas reglas de negocio, por lo que se solicita que en la página de
"Captura de prorrateos" que actualmente funciona se hagan las adecuaciones de la siguiente manera:

1.-Al ingresar a la página esta toma lo introducido por SADFI en la tabla PF_AR_CIF_SAF de acuerdo a lo
contenido en el campo fecha contable y genera un prorrateo, partiendo la línea original en varias líneas (Este
paso actualmente funciona correctamente) quedando como se muestra en la imagen siguiente:

Para el ejercicio se considera la comisión por saldo del día 3l/0312017 para la Siefore Básica 4 Trabajadores,
con los saldos que se muestran en la pantalla:

ffiepnovecros Página 'l 1 de 17

 CARTA CONST¡TUTIVA
Profuturo MANTENTM ¡ENTo Y AcruALtzAc¡ót¡
lli:ii i. ,r ,.,ir I :i?i
klr,nr¡ 1r.r.s ! rr,¡'i '

Captur¡ 'J€ prcrrnleo§

.tl
., . ...:..::r>."1\

I F:.r-1r :i:t ti::i.1n.ir fi¡_iir.i?if: arrl:ri :/_: rlalrl:r1a

r!b?drau..' - kbqÉnl,tl. , Sqqi..e.rl,sli

.4!.,(.r

Cabe mencionar que el ejercicio se tomó con estos parámetros, pero el cambio se hace por todas las siefores y
para los importes de Trabajadores y Afore.

2.-Adicionalmente una vez que termine los cálculos actuales y antes de desplegar la información en pantalla, la
página validará la fecha contable, le sumará un día; si el resultado de la suma es un día hábil muestra la
información como lo hace actualmente y termlna, en caso contrario entrara a la modificación y ejecuta el paso
tres.

En el ejemplo en pantalla la fecha contable es 3L/03/201.7 si se le suma un día la fecha es Ot/04/2017 que es
sábado, es un día inhábil por lo que entra en la modificación.

3.- El día siguiente a la fecha contable es inhábil o es un fin de semana, ahora sumara un día adicional hasta
encontrar un día hábil, y guarda el número de días que ha tenido que sumar para encontrar el día hábil
siguiente; así como cada una de las fechas que recorrió, una vez que ha encontrado el día hábil siguiente lo va a
comparar contra la fecha contable original, en caso de que haya habido un cambio de mes del día hábil
siguiente sea el próximo mes de la fecha contable, ejecutará el paso cuatro, en caso contrario muestra la
información como lo hace actualmente y termina.

Siguiendo con el ejemplo, a OL/Oal2O17 se le suma una día más y mi fecha es 02104/20L7 que es domingo,
sumo un día más y la fecha es un día hábil lunes 03/0412077, dicha fecha pertenece a Abril y mi fecha contable
pertenece a marzo por ingreso al nuevo procedimiento.

4.-Por cada registro prorrateado y original generará un registro adicional idéntico, que solo será variable en el
campo ACCOUNTING_DT y ORIG_ITEM_AMT, dividirá el importe (Valor del campo ORIG-ITEM-AMT) entre el
número de días sumados para dividir de manera proporcionar el importe redondeado a dos posiciones, la
suma de cada parte debe dar exactamente el importe original en caso de necesitar hacer un ajuste por
redondeo se hará en el segundo registro. El registro original conservara su ACCOUNTING-DT y solo se
actualizara el monto (Campo ORIG_ITEM_AMT) y se le sumaran tantas partes proporcionales como se tenga en
el mes del ACCOUNTING_DT, al registro nuevo se le modificara su ACCOUNTING-DT asignándole el valor del
"día hábil siguiente" y para el campo ORIG-ITEM-AIVI sumaran tantas partes proporcionales como ¡S_lg
Página 12 de 17
OFICINA DE ADMINIS
 CARTA CONSTITUTIVA
Profutur§' MANTENrM r ENTo Y AcruALrzAc¡ót¡

fechas que coincidan con el mes del "día hábil siguiente"

En el ejemplo:

Se hizo un recorrido de tres posiciones, por lo que los días a dividir son tres, el importe de la línea L es de
5116,313.24 entonces se divide el monto de la línea entre tres:

116,313.241 3 = 38,771.08

Que corresponde a la parta proporcional de días, ahora a marzo le corresponde un día (31,/03/2017), y a abril
se le corresponde 2 días (01./0a/2017 y 02104/2017), por lo tanto

lmporte para Marzo

38,771.08x L = 38,771.08
Se redondea el importe a dos decimales
Que se cargara a la línea originalcon fecha del3L/03/2017

lmporte para Abril

38,77L.09 * 2 = 77,542.tG

Se redondea el importe a dos decimales

Que se cargara a la línea nueva con fecha deldía hábilsiguienle:03/04/20L7

Se valida la suma aritmética de los nuevos importes redondeados

38,771.08+77,542.16, en caso de que haya alguna diferencia respecto al importe inicialse ajunta las cifras por
redondeo en la nueva cifra.

Se procede a hacer el mismo procedimiento con la línea 2

Quedando las líneas de la siguiente manera:

sa¡do s€sin D
fpo O¡5iribuc6 to ltem lmpt Ortl PRORRAEO lD Cll€nte PROCESO

ssTt r017040384 T00700002506 6,14¿,305 82 38,771 08 38,771 08 1,893,02 :tfo000025 03104/201 3r/031201 !03/20r lo07B4r
sSft 6,144,305 82 77.542.15 17,342.16 1,893,02 :Í0000025 03/o4/207 03la4/20r r/a3/)or f00784r
f,ri¡'.al MSS 6,144,105 82 2,009,330.86 2,009,330.86 98.106,97! :1f0000025 )3104/20t 31/O1l20r 1l03/20r f007B4T
M55 6,144,305 82 4,OtA ,661 _7 2 4,OtA,667 .1 2 98,106,97: :1T0000025 )3/04/20r 03/o4/201 r/03/20t T007847

Es importante observar el cambio en el en número de secuencia a fin de garantizar que los registros sean
ún icos.

5,-En caso de que la suma del importe sea 0 de alguno de los registros originales el registro será eliminado.

orrcrwn or eovrrutsrRRcróru DE pRoyEcros Página 13 de 17

 CARTA CONSTITUTIVA
Profuturo' MANTENTM IENTo Y AcruALrzAcrór,r

6.-Las líneas de Afore también se van a distribuir; estas líneas actualmente no se muestran en la página, para lo
anterior y dado que solo se harán prorrateos de las líneas de Afore en los casos de cambios de mes;
anteriormente descritos, se solicita crear una nueva pestaña para la distribución de las líneas de Afores.

Dicha pestaña permanecerá oculta y sin funcionamiento y solo cuando se ingrese al paso 3 de mostrará.

8.- Esta nueva pestaña se llamara "Prorrateo Afore" y tendrá un funcionamiento similar al de la página original,
tendrá un cuadro de reparto dónde estará albergado el registro original y un cuadro de prorrateo para la línea
original y la nueva lÍnea prorrateada.

Para llenar el cuadro de reparto se consideran los criterios Fecha contable y tipo de proceso, en fecha contable
será la misma que el de la página anterior y en tipo de proceso lo va a determinar en base a lo siguiente:

Del catálogo de procesos no prorrateables que actualmente existe, seleccionar los registros cuyo tipo de
distribución sea AFORE y tomar el valor del campo Tipo de proceso de la primera página en sus primeras 5
posiciones.

.ir o' :c9 l':enú F:lf:ar9,;i ,:uefiI¿5 i Cgbtv. , ?tes¡;s ?r¡iulttra í;ti :-:.) P"rirj j t : 3tÉ,': n

'tn Set: iiFi¡,lPü,.-' Set ai Clntro: 0ñ1-,?3

Pl;arFlI .'jÍ:.1 3r',i !Á C[ ,-\.].aFljR[

rr¡ srr il!*d

ilaq&lü lfiXllijT"
üLuryio
Pr({€Eo Pr6*60
?r6t al*arlle
1,,¡i,r-, -

1 GfiUF¡:J PAF3I PrOrrAieAr t lTi,itr733T ruü7t3r ls:rE

2 r-rfiuPü PAF01 ü -' iir:,-i;;'á;¿
i.Jrüarrt r,lf.iI?iA t i!.:¡r.;- +¡ .*:
3 0ñuPC R'iF31 Frqra:ear . :f¡r::e:f ¡¡n:t lr t:.'s i ti *:;

., CI!.JFÍJ PAF'1 Prtr.a:ear v'f,.107847 Tlt'r 7t¿l +, -:

5 GfiIJFC PAF}1 Prciralrar r TC¡7847 T|]8Te{f ::l l ir"lfl
-;; *;;i ",.|--
i ¡:Fl ltrf PiFil FrLrrt;{e¿r' I,lÜ7É f r:_.: L.

¡ CiUPTJ FAFÉ1 prúr.á:ear t't,jr-i:E:T t' ^:

i CRLIFT:) F¡\F"11 PtotG'Éil ' Tai-'r:BFl Ttü ilf: lr l3 )l: ir

ú a:Pr ¡tr,- P:C :1 _-

Ffl1r,¡:eir t .:
l;rj - YL
_ ._:- _.._
i" rr 4: :t.
'i CliL"jFC F¡\F?1 Fra,rüie.rr r I-iüi:E: iicrI *, --:

1l CRl.jP{, FAFüi Pr0riá'6.1r I r.i.:¡sr i:l ri.,ii +.1 ..:.1

'j r-iRUP{_' f"Ét.!11 FroÍalsar Y I,lt r'$fi I l',¡li-i r'L r!ir! +i *,

"3 C?IJFC PÁF,}1 Frc.'1¡¿19¡¡ r IiCiSFl Tür TSRT lr,'a i *; *

,,, '3u$¿¿r ¡ ¿ñadtr iclrvrgu;ltrar

Esto regresara elvalor en el ejemplo T007B4A, con estos valores de tipo de proceso (campo PF-lD-PROCESO), y
fecha contable (campo ACCOUNTING_DT) y Status igual a N, (Campo STATUS ) buscar en la tabla para que
regrese una línea, en caso de no encontrar valor, no desplegar nada y en caso de encontrar más de un valor
OFICIr\IA DE ADMIÑ.STNNCIÓru DE PROYECTOS Página 14 de 17
 -_qrr CARTA CONSTITUTIVA
Profuturo MANTENTM rENTo Y AcruAlrzAcróu

marcar un error en la página.

La información recuperada seria la siguiente:

Unidad Negocio lO hem lmporte ftem Orig¡nal lO Cliente Fecha Ref 'Fecha Contable Fecha lntroducida ID PROCESO Estado Número Secuenci¿
PAFOl 45,165.47 c1T000002s o3/o4/2017 3t/03 120t1 3Ll03/2077 r00784A 1

9.-El recuadro de prorrateo se llenaría de manera similar al prorrateo descrito en los pasos anteriores. Primero
se crearÍa una línea copia de la línea original , se divide el importe de la línea original entre el número de días

En el ejemplo:

Se hizo un recorrido de tres posiciones, por lo que los días a dividir son tres, el importe de la línea 1es de
45,t65.47 entonces se divide el monto de la línea entre tres:

45,165.47 /3= 15,055.15

Que corresponde a la parte proporcional de días, ahora a marzo le corresponde un día (31,/03l2lt7), y a abril le
corresponde 2 días (01/04/2017 y 02/0a12017\, por lo tanto

lmporte para Marzo

15,055.16* I = 15,055.15
Se redondea el importe a dos decimales
Que se cargara a la línea original con fecha del31,/03/2017

lmporte para Abril

15,055.16* 2 = 30,110.32

Se redondea el importe a dos decimales

Que se cargara a la línea nueva con fecha deldía hábilsiguiente:03/04/20L7

Se valida la suma aritmética de los nuevos importes redondeados

15,055.16 + 30,110.32 = 45,165.48 en caso de que haya una diferencia respecto al importe inicial, se requiere
hacer un ajuste siempre en la línea nueva,

Ajustando 0.01e| valor para Abril es de:

30,110.31

15,055.16+ 30,110.31 = 45,L65,47

OFICINA DE ADMINISTRACION DE PROYECTOS Página 15 de 17

 __-.arr CARTA CONSTITUTIVA
Profuturcl MANTENrMrENTo Y AcruALrzAcróru

Quedando de la manera siguiente:

¡o hem lmpt Orsl Sáldo reBin Coñtabfidad D PROC60

,ar01 \loRt 2017040384 T00700002506 45,165 A1 15,055 16 :1T0000025 J3/04/201 3r/o3/2Ot 1t/o3/201 '007Bla l
'at0l \toRt 45,165 47 30.1 l0 32 tf0000025 3/04/201 03/o4/2Ot l/o1/20t 1

Donde se hace notar el cambio en el número de secuencia

10.-Al final de guardar el componente validara que prorrateos en ambas páginas se hayan realizado y los
importes sumen la cantidad original a repartir.

11.- A continuación se corre el proceso de lnterfaz contable (Aplication Engine PF_AR_CIF)tomara esos valores
para crear el ltem en el módulo de cuentas por cobrar, se debe validar que elvalor del ACCOUNTING_DT viaje
al ltem de tal manera que se creen grupos de ltem con con diversas fechas contables.

A continuación se muestra un ejemplo del ltem esperado:

i::.f I . tl) ijlri a, .

,ir: -i--
.t f::ali.lii'1)1. :, -" ]r- i, ,,rr 1

_i r ",r_i.:. i_4.-_il ,
'Crnl?do
t...tl. -_ -

!!r1rali1 7

i 5-',::ü lrloned¡:

t,(it.tis h'lo¿ivo; nistr,qRr ccH-:Fij3 t Evento Entr¿[l¿ j

Re?ai

Con(,ic: 1t) D ürdc,a VtD: lnrplr Iltrsi

üest uenlü: Graü8 Plu: lñrF){)r:l» lVAl

0qsruento li peilnrl¡r Dlo srenlpre .....i.r,,.'ii:.?:..tit.::

R(f Pfflido: txx.:

N" Pe(lidoi Lirr fier¡:

c r(o Xi Cil5o)

.' \'olvs ¿ 8us¿¡ ',, ttdlúsr ..: Frc¡a Áns,s , FEhr SE

:r ;i r ;:i .''.' "''i:-'r-r,''a: :. .:':,"t,

OFICINA DE ADMINISTRACIÓN DE PROYECTOS Página 16 de'1 7

 CARTA CONSTITUTIVA
Profuturo MANTENTMTENTo Y AcruALtzAclóx

tiN ()¡!Pri.
1rñ ürrpa: p¡,F;1-
i'.ii
., 6p:
ln \:P.
.l-r f 2r-: ;I
f;¿t.)

. ".
^áw;r-."*.. .o *;+*ity-á*,s: .iffih#il,
,"". i*::nni*ljáb,yi¿fue-iq-v.{1*#":*tlsrs*tá+iiá*-i.: $l'..* .}i.. .¡,";+--:*::kE.:.-.-e
f Cüñlrblr) :i¡ íli;,la'7 [9(ha Het] ?.ilii:t't ,(e{uBrciar ;:

lO llcñ) :11r0;/"¡.'§-T'f-"r0-
:11r0;,"¡.r§-T'f-"r0- t.in?ai : Contzdo

uN: Friil cliente: ti,TnJ:ri?¡ Filtjta FRi-1F

§[bclñ{ ,: Su§clnt lr

lm$orlei i 'i11 irl MonPdr: I.!iN

T0 Entrsdr: c:Llrs Molrvo:
Morvo: ¡i:!)P" nistr aFi l.l Éi(.F-
ari.l.l-Éi(1F-
ari I Fvenlo
Evenlo F-otradal

Reval

.-ondlc:
.-ondlc: 1l
1l Fechavercrm:
Fechavercrm: DGraciavto:
DGraciavto: lo¡rieTrn§:
lo¡rieTrn$i 1"'rf;
1"'tf;
Desc[ento:
Desc[ento: Dlú:
F Dlú: Oloi
Gracrü Oloi fmpone IVA:

t)Éscuento 1 r Lle§r:itenio 1 I perrnltir oto §reln§re il il f itgl f'líl"l'-\:/i

Rel Padrdai Lin Ped: BOl.:

§'Pedarlú:
§'Pedarlú: Doaume¡fo:
Doaume¡fo: Lin ltetrrl
¡-:trfr)l
l-ltrf,)l ,Ll
,L) Cefia; N' t üs(r
N'Caso:

¡ Eus¡r :; ¡ldiicr
\Jols a ; Fich¡ Antlris .. Fidi¡ Siq
:.!-: :il .t::.i;,:tt.,t.:: 1'. rr§':,1 rl iir 1 irt:iirrllilr.,ii
-.- ::,1|:-.1:1.at.l1.:i .i

Donde se puede ver que para un solo grupo, las fechas contables son diferentes.

Es posible que este entregable de comisión por saldo se haga en una liberación posterior para empatar la salida a producción
con el equipo de MIT Afore, al momento de la elaboración del presente documento no se tiene una fecha de liberación.

Los días inhábiles se deben considerar del calendario de días festivos de PeopleSoft con el valor: MEXO1
t:riir1f, l.:i\rt_rj.:!¡l i,$:irflnf Crprr¡:rraii,o'j ¡¡,rx,Íi,¡fr,rLin* ¡,tir'.ti..¡,,,t1c'iat1" . {!ari¡':.t.r.o i
d,?r, il

Calencinrio Lah,oral
i !: f.ar vñr

, -\ . - ... ;-b'¡ü&ia .rn''l.@ '... .

" rj
' .e,. 'iieiGÉ
, Ldrj a V\... , MrÁr.NEi r .h,,ét , !rnié! $&lo Odn'noo
,fficúrs,!¡ , ) L.l;t:.:i:i .., n. j;.:;.:a:l:;::::.a)rtt rt ):!t

I urr)r B¡(É! i1:f'anlrr q¡b¡(o o,mflo

'{rrn!t

..*. . *;* ;;*;¡¡*#Sáh+'miiw" s+*'¡*¡&l#Í"* -.. +.;d-"; - . *.".+lzu.. q..

Nrnrnr att:1 8Úsa
^ñ¡
.---4^qffi,\^t ' (i. " _.'t§: .iI.r.r:74"
¿!i4 a:q\M"^: lI 1l*& ;: #
t" tJ. » l."r triiúitA§rl

t, - n ^
"..
l¡::1' ¡ : ' '{'r.f,',
'r':..r'l ¡ r' r'!.)l.!i!.¡'

), a :¡ : i; t,;r ! rr{r,i. :.r^.!.