Manual de Proceso de Devengamiento de Ingresos. Deferred Revenue Recognition. Vicerrectoría Económica. Centro de Costos CHL

Transcripción

1 Manual de Proceso de Devengamiento de Ingresos EL PRESENTE DOCUMENTO HA SIDO DESARROLLADO PARA USO EXCLUSIVO DE EMPLEADOS DE LA UNIVERSIDAD ANDRÉS BELLO QUIENES DEBERÁN MANTENER ESTRICTA RESERVA FRENTE A TERCEROS RESPECTO DEL CONTENIDO DEL DOCUMENTO, EN CONSECUENCIA, UNIVERSIDAD ANDRÉS BELLO NO ASUME RESPONSABILIDADES RESPECTO DE SU USO INADECUADO y/o POR PERSONAS NO AUTORIZADAS.

2 ÍNDICE 1. INTRODUCCION EXTRACCIÓN DE LAS GURFEED DIARIAS Y CUADRATURA EN PLEOPLESOFT Extracción de las Gurfeed diarias Agregar Gurfeed al modelo SQL PROCESO DE AGREGAR LA GURFEED DEL MES A LAS BASES HISTORICAS Bases Históricas Gurfeed Complementada con Información TIBCO y de Actividad Procesamiento Gurfeed del Mes Bases Históricas Actualizadas Antes de Devengar Bases Históricas Gurfeed Complementada con Información TIBCO y de Actividad Bases Históricas Actualizadas Antes de Devengar Base Rut Activos Devengo Lineal Devengo Cash PROTOCOLIZACIÓN... 21

3 1. INTRODUCCION El presente documento describe las principales etapas e inputs considerados en el proceso de cálculo del devengo mensual de ingresos percibidos por la Universidad como retribución a los servicios educacionales prestados por ella. La primera sección describe la tabla Gurfeed, que corresponde al consolidado de transacciones mensuales que afectan la cuenta corriente del alumno, y el proceso de reflejo de estas transacciones en PeopleSoft. A continuación se detalla la consolidación de las transacciones del mes con las bases históricas, así como los controles considerados. Posteriormente se detalla las reglas consideradas para la definición de alumnos activos, los cuales son la base para el cálculo de devengo de ingresos. Finalmente, se describe la generación de las bases de devengamiento.

4 2. EXTRACCIÓN DE LAS GURFEED DIARIAS Y CUADRATURA EN PLEOPLESOFT 2.1 Extracción de las Gurfeed diarias. Para extraer la Gurfeed del día se debe ingresar al servidor de Servicios Andinos y obtener la archivo que se encuentra dentro de la cuadratura que realiza Servicios Andinos. El link del servidor es el siguiente: ftp:// /contabilidad/grupo%20unab/ Dentro de esta Carpeta se encuentran detallada por año / mes / día, todas las Gurfeed que son necesarias para la extracción de la información de los Ingresos. Dentro de cada carpeta, se encuentran 4 archivos, que corresponden a: - Cuadratura diaria. - Gurfeed_ empresa_día. - Tyrcarps_empresa_día. - Tyrerps_ empresa_día. Diariamente, se generan 3 archivos, una es la Gurfeed con toda la Información que debe ser levantada y traspasada a PleopleSoft. Cuando este proceso se ejecuta, se genera el archivo Tyrcaps, que es el archivo_base que se ha traspasado a Pleoplesoft.

5 Normalmente este proceso no se genera con total éxito, es decir, de todas las transacciones generadas en la Gurfeed, no todas logran ser traspasadas a Peoplesoft, por lo cual, cuando ocurre esto, se genera un Archivo de Errores Tyrerps, el cual debe ser analizado por Servicios Andinos y traspasado en forma manual. Sólo posteriormente a esto, se puede decir que el traspaso diario de la Gurfeed ha quedado finalizado y cuadrado en PeopleSoft. 2.2 Agregar Gurfeed al modelo SQL. Para realizar este proceso, se debe abrir el archivo (Cuadratura) y previa validación de los saldos se debe tomar la pestaña GURFEED y subirla al modelo de SQL asignándole el día que corresponde a la cuadratura. Para subir el archivo Gurfeed al modelo SQL, se debe guardar la base en un archivo.csv. Luego se debe cargar este archivo en el servidor de Finanzas UNAPRDFIN01 en la base de Datos BTCG. En esta sección se carga diariamente las Gurfeed y se van consolidando a nivel mes.

6 Cuadratura que realiza Servicios Andinos: Para cargar y consolidar las Gurfeed se debe usar el primer script construido para este fin: - 001_AGREGA_GURFEED_DIA.servidor.sql

7 Todos los scripts se encuentran en el servidor de Finanzas como una manera de seguridad y transparencia de los procesos. El link donde se encuentran alojados los script del modelo de reconocimiento de ingresos en SQL es: \\ \cobranzas\CONTROL GESTION\SCRIPT SQL\ING_DIF\Version 2\SCRIPT V6 Código SQL: con esta instrucción se puede comprobar que la Gurfeed que se esta subiendo al modelo cuadra con el archivo Excel de origen. A modo de ejemplo, en la cuadratura de Servicios Andinos sobre el día da un saldo en ingresos diferido de $ , y al levantar el archivo y llevarlo al modelo SQL, el monto es exactamente el mismo. De acuerdo a este criterio se realiza la comprobación de integridad de los datos por día.

8 2.3 Evidencia del código SQL y los datos que arroja el modelo de reconocimiento de Ingresos: Select GURFEED_ACCOUNT,MTO_DEBITO= SUM(CASE WHEN GURFEED_DR_CR_IND='D' THEN CAST(GURFEED_TRANS_AMT AS FLOAT) ELSE 0 END),MTO_CARGO = SUM(CASE WHEN GURFEED_DR_CR_IND='C' THEN CAST(GURFEED_TRANS_AMT AS FLOAT) ELSE 0 END),SDO_ACUM = SUM(CASE WHEN GURFEED_DR_CR_IND='D' THEN CAST(GURFEED_TRANS_AMT AS FLOAT) ELSE 0 END)- SUM(CASE WHEN GURFEED_DR_CR_IND='C' THEN CAST(GURFEED_TRANS_AMT AS FLOAT) ELSE 0 END) from BTCG.dbo.Gurfeed_Mes Where GURFEED_SYSTEM_ID='UNAB' group by GURFEED_ACCOUNT ORDER BY GURFEED_ACCOUNT ASC

9 2.4 Cuadratura de Gurfeed v/s PeopleSoft Con la agrupación de las Gurfeed diarias en un solo archivo, se debe validar si ellas diariamente han sido traspasadas correctamente a PeopleSoft. Para lo anterior, se debe generar desde PeopleSoft el Mayor de gestión para corroborar la cuadratura indicada. Este proceso consiste en generar el mayor del mes, detallado por transacción. El pantallazo siguiente muestra el mayor de PeopleSoft con el cual debe cuadrarse la información. Este mayor entrega la información para verificación, se exporta a Excel y es guardad en la carpeta donde se encuentran las Gurfeed diarias. Una vez exportado a Excel, se debe validar haciendo dos tablas dinámicas, una de la Gurfeed\empresa\Cuenta\día y otra del mayor de gestión, también por día. Esta validación permite verificar y validar que todos los traspasos diarios se han ejecutados correctamente.

10 En esta cuadratura al día , se logra visualizar que de las 06 Gurfeed, 03 hay sido traspasadas correctamente, pero aun resta que servicios andinos realice el traspaso de las demás Gurfeed. En lo que concierne al reconocimiento de ingresos, este proceso no se lleva a cabo hasta que tengamos el 100% de confirmación de que todas las Gurfeed han sido traspasadas a PeopleSoft.

11 A modo de ejemplo se detalla la cuadratura del mes de Octubre: En esta cuadratura se logra ver que de todas las Gurfeed informadas por Servicios Andinos, ninguna arroja alguna diferencia, es decir, todas han sido traspasadas a PeopleSoft, y por tanto, se puede tener la seguridad de que la información está ingresada correctamente.

12 3. PROCESO DE AGREGAR LA GURFEED DEL MES A LAS BASES HISTORICAS. El proceso de consolidar las Gurfeed del mes a las bases históricas se ejecuta a través de scripts en SQL. En términos generales, esta actividad consiste en consolidar las Gurfeed del mes con las bases históricas de ingresos al mes anterior al actual, eliminando filas que se anulan mutuamente, rebajando anulaciones e insertando nuevas transacciones, todo lo cual permite obtener la base histórica actualizada con las novedades del mes. El proceso general está descrito en la figura siguiente. Como se ve, a las bases históricas por tipo de alumno (Pregrado, Postgrado y Advance) se agregan las transacciones del mes más data adicional, para generar el nuevo saldo contable.

13 A continuación se describe más en detalle el procedimiento considerado. 1. Bases Históricas: 2. Gurfeed Complementada con Información TIBCO y de Actividad: 3. Procesamiento Gurfeed del Mes: 4. Bases Históricas Actualizadas Antes de Devengar: 1. Bases Históricas: En la actualidad existen 3 bases históricas acumuladas: Post-grados, Advance y Pre-Grado. Estas bases contienen todos los ingresos históricos y su formato está compuesto por la siguiente estructura: SELECT [GRADO],[TIPO_OPE],[COD_DET],[ANNO],[Sem],[PERIODO_PS],[Fecha],[Rut_Alum],[Dv_Alum],[Rut_BNN],[Nombre_Alu],[Codigo_Carrera],[Nombre_Carrera],[CAMPUS_BNN],[SEDE],[Ccosto],[Charfield2],[Degree],[ACTIVITY_CODE],[CAMPUS_PS],[SDO_INI10],[Anulaciones_Acumuladas],[Devengo_Acumulado],[Cash_Acumulado],[SDO_ACT],[SDO_CONT] FROM [BTCG].[dbo].[HISTORICO_PREGRADO_201410_SQL] Descripción: a) GRADO: se refiere al nivel que cursa el alumno (Pregrado, Advance, postgrados, Factura). b) TIPO_OPE: se refiere al tipo de Operación que se genera en la transacción; es decir, Ingresos, Becas o Descuentos Varios.

14 c) COD_DET: es el código de detalle (ARA1 es el Arancel, MAT1 es la matricula, etc. d) ANNO: año en relación al periodo de transacción. e) Sem: Semestre en relación al periodo de transacción. f) PERIODO_PS:Periodo en que se carga la transacción. g) Fecha: Es la fecha en que se carga la transacción. h) Rut_Alum: Rut del alumno si dv. i) Dv_Alum: Dígito verificador del rut del alumno. j) Rut_BNN: Rut del alumno incluyendo el dv. k) Nombre_Alu: Nombre del alumno. l) Codigo_Carrera: Código del programa del alumno en el mes que se cargo la transacción. m) Nombre_Carrera: Nombre del programa del alumno en la fecha que se cargó la transacción. n) CAMPUS_BNN: campus donde se encuentra el alumno estudiando. o) SEDE: Sede de acuerdo al campus. p) Ccosto: Centro de Costo de acuerdo al programa/campus. q) Charfield2: Disciplina academica de acuerdo al programa/campus. r) Degree: Degree de acuerdo al programa/campus. s) ACTIVITY_CODE: Activity code de acuerdo al programa/campus. t) CAMPUS_PS: código del campus del alumno. u) SDO_INI10: Saldo correspondiente al Saldo inicial con el cual el alumno se matricula o se genera con la nueva transacción. v) Anulaciones_Acumuladas: anulaciones acumuladas y la del mes asociados al alumno. w) Devengo_Acumulado: devengo lineal acumulado al mes anterior al mes en curso. x) Cash_Acumulado: devengo cash acumulado al mes anterior al mes en curso y) SDO_ACT: saldo actual real (Saldo inicial anulaciones devengos) z) SDO_CONT: Saldo contable real Neto. La finalidad de estas bases es mantener el saldo contable real al mes anterior al presente mes. Por ejemplo, para el mes de noviembre 2014, se mantienen 3 bases históricas al cierre de octubre, que son las bases con las cuales se cerró el mes y disponen del saldo contable por Rut, es decir, todo lo que queda pendiente por reconocer de estos alumnos. SELECT DISTINCT GRADO, SUM(SDO_CONT)'SALDO CONTABLE' FROM dbo.historico_postgrados_201410_sql GROUP BY GRADO (código de ejemplo base histórica de Postgrados) (Imágenes de las 3 bases)

15 2. Gurfeed Complementada con Información TIBCO y de Actividad: La extracción de la Gurfeed se realiza diariamente y finalmente se consolida todo el mes. El problema de estas bases que no aportan mucha información relacionada al alumno, por ejemplo, no especifica el nombre del alumno, su carrera, sede, etc. De acuerdo a este problema es que la base gurfeed se complementa con 2 bases extraídas desde banner; una es la base de Actividad y la otra es la base TIBCO o base de Centro de costos. - Actividad: Esta base provee información relacionada al alumno, como lo es nombre, código programa, nombre programa, sede, nivel. Además muestra su último estatus académico, periodo de matrícula y toma de ramos. Lo último es de vital importancia para determinar si un alumno se encuentra activo o no para su reconocimiento de ingresos. - TIBCO: La base TIBCO nos entrega la información de los diferentes centros de Costos que deben llevar los distintos alumnos. Lo anterior es de vital importancia para saber a qué centros de costos se deben reconocer los ingresos. SELECT [SYVFPCC_UNIDAD_NEGOCIO],[SYVFPCC_UNIDAD_CODE],[SYVFPCC_CAMP_CODE],[SYVFPCC_LEVL_CODE],[SYVFPCC_CCOSTO_CODE],[SYVFPCC_CAMP_CODE_PS],[SYVFPCC_DEGC_CODE_PS],[SYVFPCC_ACAD_DISC_PC] FROM [BTCG].[dbo].[TIBCO]

16 3. Procesamiento Gurfeed del Mes: Ya con la Gurfeed del mes completada con la toda la data adicional requerida se procede a identificar y caracterizar las distintas transacciones que la conforman. A modo de ejemplo, se debe identificar los siguientes tipos de operaciones: o A1 = Anulación de Ingresos. o A2 = Anulación de Descuentos. o I = Ingresos. o D = Descuentos. El procesamiento y caracterización de las transacciones de una Gurfeed entrega la siguiente información, separada por grado y tipo: GRADO0 (Todas) Rótulos de fila Valores Suma de DESCUENTOS Suma INGRESOS de Suma SALDO A D I A Total general de GRADO0 POSTGRADO Valores Suma de Suma de Suma de Rótulos de fila DESCUENTOS INGRESOS SALDO A D I A Total general GRADO0 (Varios elementos) Valores Suma de Suma de Suma de Rótulos de fila DESCUENTOS INGRESOS SALDO A D I

17 A Total general Una vez procesada la Gurfeed del mes, ella se distribuye según las transacciones correspondan a alguno de los segmentos considerados, como: Post-Grados, Advance y Pre-Grado, insertándose éstas en la base histórica que corresponda. 4. Bases Históricas Actualizadas Antes de Devengar: Una vez insertada la Gurfeed del mes ya procesada en cada una de las bases históricas, se obtiene el nuevo saldo contable, antes de devengo. Este corresponde al saldo inicial, mas las novedades contenidas en la Gurfeed, donde alguna transacciones reducen el saldo inicial (tales como las anulaciones o descuentos) mientras que otras lo aumentan (como los ingresos). 3.1 CALIFICACION DE ALUMNOS ACTIVOS 1. Base Rut Activos: Como se señaló anteriormente, esta tabla es obtenida desde TI. La regla de negocio que aplica para evaluar a un alumno como activo, toma como input los siguientes 3 atributos: - Último Estado Académico. - Última Matrícula. - Última Toma de Ramos. Para que un alumno esté activo debera estar ACTIVO en estos 3 criterios. En otro caso el alumno es calificado como INACTIVO, por lo cual esta inhabilitado para su devengamiento mensual. Un alumno con Estatuto Académico AS es considerado activo.

18 3.2 DEVENGAMIENTOS LINEAL Y CASH. El concepto general para reconocer ingresos a un alumno, es que se haya prestado el servicio educacional por parte de la universidad. Lógicamente, los alumnos con estatus académico, fecha de matrícula y fecha de toma de ramos activo, son los alumnos para los cuales se tiene certeza se ha prestado el servicio educacional. Si este es el caso, el reconocimiento de ingresos para estos alumnos está dado por la expresión siguiente: (INGRESO INICIAL / TOTAL DE SEMANAS ANUAL ) * SEMANA DEL MES. 1. Devengo Lineal: La fórmula general anterior, corresponde a una forma de reconocimiento lineal (Devengamiento Lineal). Por lo tanto, si un alumno está activo devengará ingresos de esta forma. Esta fórmula general se funciona de diferentes maneras según el segmento de alumnos considerados. En efecto, los alumnos de pregrado reciben servicio en semandas académicas distribuidas de marzo a diciembre, los alumnos advance por su parte, tienen una distribución en base a trimestres y ciclos comprados. En cuanto a los alumnos de Post Para todos los alumnos sin embargo, el procedimiento de cálculo general considera el cálculo de los siguientes factores: Saldo Inicial: Saldo inicial todas las anulaciones a la fecha. Devengo Teorico: (Saldo inicial / total semanas anual) * suma(semanas mensual al corte)

19 Devengo del mes: Devengo Teorico devengo acumulado. Con este método lo que se busca es que si un alumno no ha sido devengado en los meses anteriores por estar inactivo, y tampoco por el metodo cash, sea regularizado o nivelado. Para los alumnos de pregrado, se utiliza el calendario academico y el sistema semestral. Para los alumnos de advance, su sistema es trimestral y de acuerdo a los ciclos que compra se les devenga su ingreso. Para los alumnos de Postgrados, su sistema es en base a su fecha de inicio y término del programa. 2. Devengo Cash: Existe un segundo mecanismo para devengar ingresos de los alumnos que no estén activos. Este método considera que si un alumno está inactivo, pero sigue pagando o rebajando su deuda con la Universidad, es un claro indicio de que si esta utilizando el servicio entregado por la Universidad, en cuyo caso se le aplica un devengamiento de acuerdo al Cash cancelado, en donde el devengamiento Teorico acumulado no puede ser inferior a la deuda vigente. La fórmula aplicada corresponde a la que se indica mas abajo, la cual tiene a igualar la deuda efectiva con el saldo contable del alumno. FORMULA CÁLCULO CASH MI SDO_CONTABLE - ; SDO_CONTABLE - 0 N TEORICO DEUDA Una vez que ya se tiene el Devengamiento lineal y cash, lo que se debe realizar es rebajar la base histórica actualizada al mes en curso, para obtener la nueva base final que servirá como input en la calculo EDI. Esta base EDI es la que se ocupa para el cálculo de reservas.

20 3.3 GENERACION DE LAS BASES DE DEVENGAMIENTOS. Con los cálculos realizados, y la rebaja en las bases Históricas, se procede a extraer las bases de Devengamientos que el depto. de Contabilidad de Servicios Andinos debe subir. Se separan las bases por tipo para tener un mejor control al momento de visualizar los traspasos en el mayor contable. Con este proceso se da por finalizado el proceso de Devengamiento de los Ingresos.

21 4. PROTOCOLIZACIÓN