Tecnico Cuentas Por Cobrar V2

DOCUMENTO REQUERIMIENTO TECNICO
Unidad de Desarrollo de Tecnologías Informáticas
Tipo Documento: Formulario F. Emisión:

Código: SDGI-HD-DRT F. Publicación y Vigencia Página 1 de 30
Versión:01 F. Actualización:
DOCUMENTElaborado por: Revisado por: Aprobado por:
Nombre
O
REQUERIMI
Cargo
Modificación
a la ENTO
creación
en SAP de
TECNICO
cuentas por
Firma
cobrar
Fecha
Índice
1. Introducción.....................................................................................................................3
1.1. Propósito de la Iniciativa..........................................................................................3
1.2. Antecedentes Generales de Negocio........................................................................3
2. Flujo actual del proceso...................................................................................................4
3. Descripción de la Iniciativa.............................................................................................8
4. Flujo del Proceso Propuesto............................................................................................9
4.1. Caso ejemplo cuenta paciente sugerido..................................................................10


4.2. Ejemplo de proceso de asociación de pagaré de Urgencia a cuenta de

Hospitalización..................................................................................................................12
4.3. Asociación de pagaré a cuentas de Hospitalización...............................................12
5. Descripción de Impacto para el Cliente.........................................................................13
6. Detalle de Funcionalidades............................................................................................13
6.1. Funciones / eventos / casos de uso.........................................................................13
6.2. Funciones / eventos / casos de uso.........................................................................14
6.2.1. Sistema SAP.......................................................................................................14
7. Respaldos y Mantención de Información Histórica.......................................................16
7.1. Impacto en Sistemas...............................................................................................16
7.2. Interfaces Externas.................................................................................................16
7.3. Seguridad y Auditoria............................................................................................16
1. Introducció n
1.1. Propó sito de la Iniciativa
Las cuentas por cobrar en cuenta paciente que acá se trabajaran, son SOLO
las generadas luego de un ingreso por Urgencia y el paciente quede
Hospitalizado, estas cuentas hoy son respaldadas con una boleta de ventas y
servicio, generando problemas en los indicadores EAR por el hecho de solo
incrementar solo las cuentas de venta.


Se necesita usar la contabilización del pagaré en SAP ya que es una cuenta

de orden que refleja lo que está en la cuenta por cobrar, que proviene desde la
cuenta paciente, esto ayuda transparentar la deuda por cobra sin emitir una
boleta de ventas y servicios, además permite devengar y percibir en momento
del pago de la deuda y emitir la boleta.
Para esto se requiere:
 Reestablecer el asociar un pagaré de urgencia a episodios de
Hospitalización del mismo paciente.
 Modificar el botón de “Reconocimiento de Ingreso” para las cajas no
recaudadoras, con el fin de eliminar la opción de generación de boleta
interna SAP, cambiando la fecha a un nuevo campo que se usará para
indicar la fecha de la deuda.
 Gestionar el pagaré según el estado de la cuenta paciente.
 Gestionar la cuenta por cobrar por medio de trx. F150.
1.2. Antecedentes Generales de Negocio
Hoy en día se tiene una cuenta de Hospitalización (cuenta por cobrar) que el
departamento de comercialización debe gestionar y valorizar, una vez
valorizada, deben cambiar el estado a cerrado, grabar, generar los pedidos y
reconocimiento de ingreso. Es aquí que el proceso no sigue un flujo correcto,
en el siguiente ejemplo se mostrará el problema que esto implica.
2. Flujo actual del proceso
Hoy al presionar este botón Reconocimiento de Ingreso, una de las rutinas del
proceso ingresa la fecha del día cómo fechas de la contabilización, luego esta
fecha llena un tag de los DTE (boletas o facturas), si la emisión del DTE se
genera más de 72 horas que el proceso de reconocimiento, este DTE será
rechazado ya que SII, asume esa fecha como la contabilización y generación


del DTE, pero para cuentas por cobrar, estos procesos pueden generarse
hasta con 4 días de diferencia.
También, el solo hecho de que una caja comercializadora genere una Boleta a
una deuda está incorrecto, ya que la deuda se debe respaldar en este caso
con un documento Pagaré.
El otro problema que existe es en la gestión del pagaré, tal como se verá más
adelante, este proceso también debe modificarse para solucionar algunos
problemas presentes.
1.
2.
2.1 Caso de ejemplo actual en cuenta paciente
El problema que presenta esta forma de trabajar (reconocimiento de ingreso

desde caja comercialización)
Cuenta Paciente n° 3219237 (PRE)
Fecha creación: 25-02-2020
Fecha cierre de cuenta: 09-06-2021
Fecha generación de boleta: 18-08-2021
Esta boleta se generó el reconocimiento de ingreso el 09-06-2021


Pero se emitió y envió el 18-08-2021
Traza de Acepta para este DTE
Boleta fue rechazada por tener más de 72 horas entre que se reconoce
el ingreso, hasta que se emite el documento

XML generado en Acepta con datos enviados desde SAP
1
2

2.2 Caso de ejemplo actual en gestión de pagaré
El problema que acá se presenta, como se ve en la siguiente imagen, es que

mientras la primera cuenta puede estar pagada, sigue apareciendo pendiente
en el reporte FBL5N, en conclusión, no debería mostrar el gestor de pagaré, las
cuentas que estén pagadas o en su defecto, informar la cuenta en su estado y
no pendiente.


3. Descripció n de la Iniciativa
Lo que se solicita es poder quitar uno de los procesos que efectúa el botón de
reconocimiento de ingreso, SOLO para las cajas comercializadoras (no
recaudadoras), se debe eliminar la generación del documento factura interna y la
fecha que se llena al presionar dicho botón, que no sea el campo que hoy se usa,
sino otro campo de fecha que debe ser el reconocimiento de la deuda.
El reconocimiento de ingreso se debe usar solo en las cajas recaudadoras al

momento de emitir la boleta.
Si el proceso de las cajas de comercialización, llenara un nuevo campo con un
nuevo botón que reconozca le fecha con la que la deuda está completa y no la de
ingreso, este problema no se generará, se debe asociar esta cuenta al pagaré
generado en el episodio de Urgencia para respaldar esa deuda, luego al momento
de que el paciente pague ese pagaré, se generará la boleta correspondiente.
La desasociación de cuenta paciente con la obligación de generar un DTE para

cuentas por cobrar en cajas comercializadoras es un hito importante, ya que con
esto se mejorarán los indicadores EAR por una parte y se tendrá un mejor control
de este tipo de cuentas. Cambiando la forma de cómo se lleva hoy en día,
pasando de respaldar la deuda con una boleta en muchos casos a relacionar el
pagaré generado en episodio de urgencia


4. Flujo del Proceso Propuesto
El proceso de cuenta por cobrar, debe trabajar igual que hoy, solo quitando la
generación de la factura interna, pudiendo este documento, generarse al
momento de pagar la cuenta en la caja recaudadora.
En el departamento de cuenta paciente, se toman las cuentas por cobrar, se
gestionan, se valorizan y luego comienza la gestión de cobranza, para estos
procesos se requiere usar la trx. ZSD001, donde el pagaré debe tener
asociadas las cuentas que sean generadas en el mismo ejercicio de ingreso del
paciente a urgencia y posterior hospitalización.
La cuenta quedará cerrada y con reconocimiento de deuda, esta fecha es la
que genera la cuenta por cobrar contra ingresos operacionales y se contabiliza
como lo instruye las (PCGA). (principios contables generalmente aceptados). Es
decir, se debe reflejar el hecho económico de manera oportuna, fidedigna y
homogénea. Este proceso se denomina devengamiento o compromiso. Para
luego diferenciar la fecha del pago o percibido y esta forma contabilizarlo como
indica los (PCGA). De esta forma tiene un impacto en los reportes de los
indicadores EAR.


El proceso de gestión de pagaré debe gestionar solo las cuentas impagas de

los episodios de Urgencia y Hospitalización.
Para esto es necesario asignar el pagaré del episodio de Urgencia al episodio
de Hospitalización, teniendo en cuenta algunas consideraciones, estas deberían
ser:
• No se puede asociar otra cuenta de Urgencia.

• No se puede asociar una cuenta de Hospitalización anterior a la fecha de
creación del pagaré.
• Solo debe mostrar cuentas de hospitalización del mismo paciente que
cumplan con punto anterior.
• Entre la fecha de creación de la cuenta de Urgencia y pagaré asociado y
la de Hospitalización a asignar, No puede existir otra cuenta de Urgencia.
4.1. Caso ejemplo cuenta paciente sugerido




4.2. Ejemplo de proceso de asociació n de pagaré de Urgencia a cuenta de

Hospitalizació n
4.3. Asociació n de pagaré a cuentas de Hospitalizació n


5. Descripció n de Impacto para el Cliente

El impacto será en la forma de gestionar las cuentas por cobrar, cambiando de la
forma actual, con respaldo de una boleta de ventas y servicios, a un pagaré.
6. Detalle de Funcionalidades
6.1. Funciones / eventos / casos de uso
1. Asociar la cuenta de Hospitalización con pagaré de episodio de

Urgencia
Hoy en día se tiene una cuenta de Hospitalización (cuenta por cobrar) que el
departamento de comercialización debe gestionar y valorizar, una vez valorizada,
deben dejar la cuenta en estado cerrado, grabar, generar los pedidos y
reconocimiento de deuda. Con esto la cuenta queda cerrada y lista para asociar a
un pagaré ya existente.
Criterio de Satisfacción
La cuenta del episodio de Hospitalización debe poder asociar al pagaré del
episodio de Urgencia del cuál nació la hospitalización
Premisas para que se cumpla la satisfacción
Debe considerarse que se pueda asociar solo una cuenta de hospitalización del
mismo paciente
2. Gestión de Pagaré, Trx. Zsd001

Gestionar el pagare, valorizar el mismo con valores de las cuentas asociadas que
tenga el pagaré.
Se debe gestionar el pagaré, valorizar y contabilizar respecto de las cuentas
asociadas a este.
Gestionar y valorizar el pagaré en relación a las cuentas asociadas
Debe tener la información, valorización de ambas cuentas, debe totalizar el total
de ambas cuentas


6.2. Funciones / eventos / casos de uso
6.2.1. Sistema SAP

Nombre del Caso Generación episodio de Urgencia
de Uso
Número del Caso 1
de Uso
Descripción SAP debe recibir desde Thalamus el episodio de Urgencia
Actores Thalamus - SAP
Pre-Condiciones Sistema Thalamus, genera episodio de Urgencia.
Flujo Principal 1. Thalamus genera episodio de Urgencia.
2. Thalamus da de alta a paciente y gestiona la hospitalización.
3. SAP recepciona información y crea cuenta de Urgencia en
cuenta paciente.
Se debe validar información recepcionada
Post Condiciones Generación de episodio de Hospitalización
Flujos Alternativos
Control de Versión
Nombre del Caso Generación episodio Hospitalización
de Uso
Número del Caso 2
de Uso
Descripción Thalamus debe crear su episodio de Hospitalización.
Actores Thalamus - SAP

Pre-Condiciones Sistema Thalamus, genera episodio de Hospitalización.
Flujo Principal 1. Thalamus genera episodio de Urgencia.
2. Thalamus gestiona episodio de hospitalización hasta su alta.
3. SAP crea la cuenta de Hospitalización del paciente que pasa
de urgencia a hospitalizado
Post Condiciones Las cuentas de Urgencia y Hospitalización, debe ser
consecutivas en temporalidad, siendo primero la de urgencia
luego la de hospitalización
Flujos Alternativos
Control de Versión


Nombre del Caso Generación cuentas por cobrar desde caja de Urgencia
de Uso
Número del Caso 3
de Uso
Descripción Paciente pasa a Urgencia e indica que pagará la cuenta, pero
luego se va del lugar sin pagar la cuenta, cajero no alcanza a
emitir boleta, pero si genera reconocimiento de ingreso.
Actores SAP
Pre-Condiciones Paciente indicó que pagará total de atención.
Flujo Principal 1. SAP gestiona la cuenta de Urgencia
2. En caso de que paciente indique que pagará cuenta, no
generar reconocimiento de ingreso hasta que se recaude el
dinero
3. Si se generó el reconocimiento de ingreso y paciente se fue,
anular el reconocimiento de ingreso.
No se debe generar reconocimiento de ingreso si no se ha
recaudado el dinero.
Post Condiciones Cuenta quedará como por cobrar, pero sin reconocimiento de
ingreso, ni tampoco DTE generado.
Flujos Alternativos
Control de Versión
Nombre del Caso Generación cuentas por cobrar episodio Dental

de Uso
Número del Caso 4
de Uso
Descripción Paciente viene en varias cesiones por episodio Dental.
Actores SAP
Pre-Condiciones Paciente tiene episodio dental abierto.
Flujo Principal 1. SAP gestiona la cuenta de Dental
2. No se asociarán pagaré a estos episodios
Post Condiciones 3. Cuenta se llevarán tal cual se llevan hoy.
Flujos Alternativos 4. Departamento de Recaudaciones lleva su flujo
Control de Versión


7. Respaldos y Mantenció n de Informació n Histó rica

No se asociarán cuentas ya contabilizadas y cerradas por comercialización con
fecha posterior a la puesta en producción de esta funcionalidad.
7.1. Impacto en Sistemas
Descripción
Esto es un cambio en SAP, afectará la forma de respaldar las cuentas por cobrar
Las cuentas por cobrar siempre deben tener un pagaré asociado
1. generación de cuentas de Urgencia y Hospitalización consecutivas
2. asociar cuenta de Hospitalización con pagaré de Urgencia
3. la cuenta a asociar no puede ser otra de urgencia
4. la cuenta a asociar, debe ser solo de hospitalización y del mismo paciente
5. la cuenta a asociar debe ser consecutivas en temporalidad a la de Urgencia
6. la cuenta a asociar, no puede ser anterior al episodio de Urgencia
7.2. Interfaces Externas
Descripción
7.3. Seguridad y Auditoria
Descripción
Estas deudas deben ser mostradas en cuentas por cobrar cuando el pagaré sea
valorizado y contabilizado, mostrando solo lo que está impago
En reportes de cuentas por cobrar solo se muestre las cuentas impagas que
estén asociadas a un pagaré
Validación por parte de comercialización y finanzas de las cuentas por cobrar




Anexo 1: 12-01-2022
Estados de cuenta paciente:
Para la activación del procedimiento solo se debe tener en cuenta cuando el estado sea:
 1400 cerrado
 3400 pagado
La diferencia es que ahora el cajero, según su perfil.
Si cajero recaudador->debe tener activo botón “reconocimiento de ingreso”
Si cajero NO recaudador-> debe tener activo botón “reconocimiento de deuda” y dejar
oculto botón “reconocimiento de ingreso”.
Botón nuevo: “reconocimiento de deuda” significa que se debe crear un nuevo botón y que
debe registrar la fecha (campo nuevo) como se hace tal cual, con el botón de
reconocimiento de ingreso, pero la diferencia es que se debe intervenir el flujo de la
generación de la factura actual.


Figura actual:
Botón: reconocimiento de ingreso

a) Factura interna (SAP)
b) Contabilización
c) Emisión DTE (xml).
Botón: reconocimiento de deuda.

a) “pre-boleta”
b) Contabilización.


Perfiles de utilización
a) Caja Recaudadora (Cuenta Paciente).

Ejemplo:
b) Caja Comercializadora (ADM. Recaudación).


Ejercicio paso a paso asociar un pagare :
Cuenta 1 de Urgencia y su flujo

actual con reconocimiento de
ingreso y pagaré generado


Segunda cuenta de Urgencia y su

flujo actual con reconocimiento
de ingreso


Cuenta de Hospitalización y su
de ingreso, pero no muestra flujo,
por qué?


Segunda cuenta de Urgencia y su

de ingreso


Al tratar de asociar la tercera

cuenta al pagaré, muestra este
mensaje, pero igual permite
asociar


Las 3 cuentas asociadas al mismo
pagaré 158810, no muestra el
estado de todas las cuentas, pero
el proceso deja continuar hasta la
contabilización del pagaré
No aparece estado de las cuentas asociadas a pagaré, solo aparece estado de la primera
cuenta
Búsqueda de partidas abiertas por deudor




Asientos contables del pagaré
por cuenta




No aparece flujo para Episodio de HOSP 3230818 y pedido 3277285, pero si existen
documentos contables y documentos para generar DTE

Tecnico Cuentas Por Cobrar V2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tecnico Cuentas Por Cobrar V2

Cargado por

Copyright:

Formatos disponibles

DOCUMENTO REQUERIMIENTO TECNICO

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

DOCUMENTElaborado por: Revisado por: Aprobado por:

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

4.2. Ejemplo de proceso de asociación de pagaré de Urgencia a cuenta de

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

Se necesita usar la contabilización del pagaré en SAP ya que es una cuenta

1.2. Antecedentes Generales de Negocio

2. Flujo actual del proceso

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

El problema que presenta esta forma de trabajar (reconocimiento de ingreso

Fecha generación de boleta: 18-08-2021

Esta boleta se generó el reconocimiento de ingreso el 09-06-2021

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

Pero se emitió y envió el 18-08-2021

Traza de Acepta para este DTE

Tipo Documento: Formulario F. Emisión:

XML generado en Acepta con datos enviados desde SAP

Tipo Documento: Formulario F. Emisión:

2.2 Caso de ejemplo actual en gestión de pagaré

El problema que acá se presenta, como se ve en la siguiente imagen, es que

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

El reconocimiento de ingreso se debe usar solo en las cajas recaudadoras al

La desasociación de cuenta paciente con la obligación de generar un DTE para

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

4. Flujo del Proceso Propuesto

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

El proceso de gestión de pagaré debe gestionar solo las cuentas impagas de

• No se puede asociar otra cuenta de Urgencia.

4.1. Caso ejemplo cuenta paciente sugerido

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

4.2. Ejemplo de proceso de asociació n de pagaré de Urgencia a cuenta de

4.3. Asociació n de pagaré a cuentas de Hospitalizació n

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

5. Descripció n de Impacto para el Cliente

1. Asociar la cuenta de Hospitalización con pagaré de episodio de

2. Gestión de Pagaré, Trx. Zsd001

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

6.2. Funciones / eventos / casos de uso

6.2.1. Sistema SAP

Actores Thalamus - SAP

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

Nombre del Caso Generación cuentas por cobrar episodio Dental

Unidad de Desarrollo de Tecnologías Informáticas

Tipo Documento: Formulario F. Emisión:

7. Respaldos y Mantenció n de Informació n Histó rica

7.1. Impacto en Sistemas

7.2. Interfaces Externas

7.3. Seguridad y Auditoria