Saco la transición entre "Pendiente" y "Vencida"... Sólo pueden vencer las autorizaciones aprobadas, porque la fecha de vencimiento se setea cuando se aprueba/rechaza una autorización.
Sebastian Lavena [Tue, 26 Apr 2005 17:28:11 +0000 (17:28 +0000)]
Cambie la fechaResolucion de lugar.
Ahora esta en Autorizacion Manual (hijo de autorizacion) y no esta mas en el padre. Pues en las autorizaciones automaticas esta fecha es identica a fechaSolicitud.
Diagrama de estados de una autorización automática. Al igual que con la manual, con éste diagrama la idea es que queden perfectamente claros los estados, transiciones y eventos que disparan las transiciones de una autorización manual.
También se colocan las notas que explican como se define cada estado a nivel clase.
Se aplican cambios mencionados en el RFC 1 =)
- Afiliado.nroAfiliado pasa a ser Afiliado.codigo
- Zona.codigo pasa a ser Zona.nombre
- Se borra Prestador.codigo
- Se borra Prestacion.codigo
(faltaría actualizar los CU para que usen los nuevos nombres)
Diego Marcet [Tue, 26 Apr 2005 04:11:15 +0000 (04:11 +0000)]
- Agregue la especificacion mantener planes
- Agregue tipo de atributo a clase plan
- Saque atributo precio del plan (asumo q igual q para las prestaciones, nosotros no tocamos costos de planes) y agregue categoría
Se agrega relación entre Afiliado y Solicitante, porque el Solicitante podría
decir a la hora de pedir una solicitud que se quiere agregar al Plan familiar
del Afiliado titular X.
Versión inicial del diagrama de estados de una autorización manual.
La idea es que quien tenga dudas de como es la vida de una autorizacion manual, simplemente abra este diagrama.
Cada estado tiene asociado un comentario con las condiciones (una por renglón) para que se pueda decir que la autorización está en ese estado específico. No debería haber ambigüedad de estados.
1) Reordenacón de atributos de Autorización
2) Saqué los underscores de todos los nombres de atributos para unificar notación. Esto después nos va a facilitar la lectura de clases->tablas y el mapeo.
* Hay que ponerle titular (que es un afiliado) al solicitante en caso de que
quiera depender de uno. Representarlo en el diagrama de clases.
* Si el solicitente existe como inactivo y se quiere volver a afiliar, hace
falta llamar a "consultar estado de cuenta"? o podemos verificar el atributo
"Afiliado::moroso" directamente?
* Si un ex afiliado, conserva la antigüedad si quiere reafiliarse? (nosotros
pensamos que no, que es un nuevo afiliado) Esto es por las PK en las tablas.
Se actualiza con lo hablado en la reunión del 24/04. También se pule bastante
para que deje de ser una mezcla entre DER y DC y empiece a ser un DC de verdad
=) El principal cambio es que se sacan atributos pertenecientes a relaciones.
Paso el diccionario de datos adentro del diagrama. Saque un par de atributos que estaban mal (en general de relaciones entre clases que estaban al revés). Igual falta MUCHO por hacer, puse muchas preguntas...
Sebastian Lavena [Thu, 21 Apr 2005 04:25:55 +0000 (04:25 +0000)]
Bueno, aca esta el hermano del anterior... Este actualiza la autorizacion manual. En realidad es la nueva version del "Revisar autorizaciones manuales", al rtf anterior le di "delete", pero no estoy seguro si lo borro localmente o tambien en el servidor. Asi que si el otro todavia existe, no sirve mas, borrenlo al carajo.
Sebastian Lavena [Thu, 21 Apr 2005 04:22:47 +0000 (04:22 +0000)]
Actualice el cuso agregando el diccionario de datos y le saque la parte de “criterios minimos de aceptación”. Antes funcionaba de manera que si un afiliado no tenia cobertura o era moroso se rechazaba automáticamente antes que lo vea un auditor. Por todo lo que hablamos hasta ahora, asumo que esa decisión le corresponde al grone con corbata.
no me gusta mucho como quedo, pero no se me ocurre una manera mejor de escribir lo que quiero decir, espero que se me ocurra y cuando eso suceda lo cambio
Mando los dos reportes q especifiqué y al de clases le agregué el atributo tipo a la prestación (aparentemente hay tipos porque así lo pide el reporte) y al de clases le saqué dos errores de ortografía :P
Agrego script para generar, a partir del diagrama UML, la especificación de las
clases. Lo que hace es tomar todos los datos de la clase, incluído los
comentarios, así sólo hay que mantener actualizado el diagrama y a partir de
ahí podemos generar la especificación en texto.
Diagrama actualizado con cardinalidades y relaciones. Saco estado_cuenta de Afiliado porque supongo que vamos a necesitar muchos mas datos que ese para mostrar al Auditor Médico en las autorizaciones manuales.
Voy subiendo lo que tengo porque no doy mas y no se me ocurre nada...
en realidad tengo un par de dudas..
por ahi meti una opcion de "Consulta de prestador" porque alguien lo menciono
en la reunion, y yo como buen esclavo lo anote, pero no se que carajo es una
consulta de prestador.. si alguien sabe que aclare..
tampoco se muy bien como manejar o dividir las consultas, si por cliente, por
solicitante, por planes, por prestaciones.. o como ¿?¿?¿
espero obtener alguna ayuda, si no intentare hacer lo que me parezca mejor.
demasiado comentario para un solo commit!!!
Es cualquiera. Como no definimos bien que mierda hace 'Consultar Estado de Cuenta' (hay que preguntar si puede ser online), quedan varias cosas en el aire
Se agregan los atributos estado (bool) y estado_cuenta(int) en afiliado. Representa si un Afiliado se encuentra activo o no en el sistema (estado) y en caso de adeudar meses, cuantos son (estado_cuenta).
Diego Marcet [Mon, 18 Apr 2005 19:57:17 +0000 (19:57 +0000)]
- Agregue casos de uso Recuperar Historial y Emitir Hoja de Ruta
- Agregue actor CAP
- Agregue especificaciones de Ingresar Solicitud, Recuperar Historial y Emitir Hoja de Ruta
- Se relaciona prestador con zona.
- Se desgloso el domicilio de la persona en calle, numero, dto.
- En cobertura se puso tiempo_de_permanencia en vez de tiempo_de_conveniencia