2010-07-07 8 views
7

Así que estoy atascado. Estoy trabajando en un sistema de crédito con vencimientos. Similar a las millas de tarjetas de crédito, pero no exactamente. Por cierto, lo siento por el libro que tengo por delante, pero necesitaba agregar detalles suficientes para ayudar a obtener una imagen completa.Necesita ayuda con el algoritmo de caducidad del crédito

Lo que necesito es un sistema donde un usuario acumula créditos para realizar actividades. Pero también pueden gastar estos créditos en actividades. Los créditos deben vencer después de 30 días si no se utilizan. Parece que estoy atascado en cómo calcular esto con precisión en un lote que se ejecutará todas las noches. Cualquier idea en cualquier idioma sería muy apreciada ya que parezco estar atascado en un pequeño detalle que no puedo resolver. Este es un ejemplo de los datos:

7/1: 5 - usuario se registra
7/2: 5 - usuario interactúa con el sistema de
7/2: -3 - user actividad compras
7/3: +5 - el usuario interactúa con el sistema

En este punto, el usuario ha recibido 15 créditos y ha gastado 3. Dejándolo con un total de 12 créditos. (Al menos obtuve las matemáticas básicas: P)

Debo añadir que actualmente estamos jugando con la idea de tener dos campos: el último procesado, el próximo procesado. Por lo tanto estos valores en este momento suponiendo que era una nueva muestra encima son:

Última fecha Procesado: 7/1
próximo proceso Fecha: 8/1

Así que ahora 8/1, vuelve. El lote comienza y mira todos los créditos que tienen más de 30 días. Que en este punto es 5.

Aquí es donde comienza a ser borroso.

Luego, el sistema debe considerar todos los créditos que se han gastado en los últimos 30 días para ver si están utilizando algún crédito. Porque solo deben caducar si no se han usado. Entonces, hay 3. Entonces deduzco al usuario 2 créditos porque esa es la diferencia de los créditos obtenidos con más de 30 días y lo que se gastó. Así que termino el lote y establezco las fechas correspondientes para el día siguiente. Ahora, suponiendo que no hayan pasado más, empiezo el cálculo de los créditos obtenidos con más de 30 años, que son 5 y los créditos gastados, que de nuevo es 3. Pero obviamente no quiero considerar los 3 créditos que consideré ayer. ¿Cuál es un buen enfoque para no incluir esos 3 créditos nuevamente para su consideración?

Ahí es donde estoy atascado.

Estamos pensando en escribir un registro de débito para los créditos vencidos, de modo que podamos rastrearlos, pero nos cuesta trabajo ver cómo puedo usarlo en este cálculo.

Si ha leído hasta aquí, gracias. Si incluso hace algún esfuerzo en la respuesta, como mínimo, le daré un voto por el esfuerzo.

EDITAR:
Ok @Greg mencionó algo que olvidé de abordar. La idea de poner una bandera en los créditos considerados. Un punto válido pero no uno que puede funcionar debido a la siguiente situación:

Digamos que en un día en particular, un usuario gasta 10 créditos. Pero los créditos vencidos que el lote está considerando solo se acumularon a 5. Bueno, aún debería tener 5 créditos restantes para que no hayan expirado porque pasó más de un solo vencimiento. Entonces, la bandera no funcionaría porque nos habríamos salteado esos 5 créditos adicionales. Espero que tenga sentido?

Respuesta

2

Suponiendo ejecutar este lote sobre una base diaria, usted puede tener una tabla que mantiene un registro de todos los créditos que ganaban, y los créditos se utilizan (créditos negativos).

Al comienzo del mes siguiente, su trabajo consiste simplemente en averiguar cuál de los créditos ganados el primer día no se gastó durante el mes.

Número de créditos obtenidos en el primer día: los créditos que han gastado durante todo el mes pasado. Si el número es positivo, tienen algunos créditos que deben expirar. Tan simple agregar un registro en la tabla con un crédito negativo.Esto pondrá a cero los créditos no utilizados.

Al día siguiente, repita el proceso viendo cuántos créditos obtuvieron en el segundo día menos la suma de todos los créditos que obtuvieron en el último mes, teniendo en cuenta el registro con los créditos negativos que creó el día anterior .

+0

Siento que este es el enfoque con el que he estado tratando de trabajar y parece que no funciona. ¿Puedes encontrar un ejemplo para demostrar esto? – spinon

1

¿Qué le parece agregar una bandera a los gastos? Si la bandera no está configurada, puede incluir ese gasto en el lote, si es necesario. Si usa los gastos para compensar una caducidad, entonces establece la bandera. La próxima vez, ignorará ese gasto porque la bandera está configurada.

+0

gracias por mencionar que creo que dejé un poco de detalle fuera de mi publicación. Déjame agregar eso ahora. – spinon

3

No consideraría tratar de procesar los datos mientras los presenta. En cambio, debe realizar un seguimiento de cuántos créditos tiene el usuario y cuándo caducan. De esta forma, puede hacer un seguimiento de los créditos que se usaron cuando se realizó la compra, en lugar de tratar de solucionarlo más adelante.

Así, cuando el usuario se registra, tienen:

5 credits expiring on 8/1 

Después de interactuar con el sistema al día siguiente:

5 credits expiring on 8/1 
5 credits expiring on 8/2 

Después de comprar algo:

2 credits expiring on 8/1 
5 credits expiring on 8/2 

Y así en.

+2

Una gran idea de UI, pero esta es una mala forma de almacenar los datos; desea una pista de auditoría en caso de que haya un error para corregir –

+1

@Heath: De hecho, esto no reemplaza el registro de transacciones correcto. Sin embargo, usar algo como esto principalmente, y tratar el registro de transacciones básicamente como anexar-a menos que algo no esté bien, es, IMO, la mejor manera de seguir adelante. –

+0

@Heath Tengo que estar de acuerdo. No quiero tocar los registros que indican cuántos créditos se obtuvieron. He considerado esta idea, pero creo que para los fines de lo que Heath mencionó con respecto a una pista de auditoría, simplemente no veo cómo podría implementar esto limpiamente en un sistema de almacenamiento. – spinon

1

Use un registro de débito para registrar los gastos normales. Cuando se ejecuta el trabajo por lotes mensual, puede calcular los débitos totales que son menores o iguales que los créditos vencidos. Si hay créditos para vencer, simplemente inserte un registro de débito apropiado (apropiado == para cancelar el exceso, en su aplicación). De esta forma, cualquier código de 'total acumulado' que examine solo los créditos y los débitos alcanzará el mismo saldo que el código de lote previsto.

+0

Estoy de acuerdo y lo mencioné un poco. Pero eso todavía no resuelve mi problema, al menos no veo cómo, ahora, cómo no considerar los 3 créditos que se gastaron en el lote al día siguiente. Aunque creo que hay algo con eso. También estamos escribiendo el registro de débito en la tabla y estamos actualizando la columna agregada con esta información también. – spinon

3

Por cada usuario del sistema a mantener una matriz, que almacena información sobre la cantidad de créditos disponibles para el usuario para los próximos 30 días consecutivos

Por ejemplo los datos de algunos usuarios podrían tener este aspecto

8 | 
7 | | 
6 | | | | 
5 | | | | | | | | | | | 
4 | | | | | | | | | | | | | | | | | 
3 | | | | | | | | | | | | | | | | | | | | | | | | 
2 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
    ------------------------------------------------------------- 
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
^^       ^   
    | \_       | 
    today tomorrow    in 15 days 

Cada vez que el usuario gana algunos créditos, aumenta los importes de todos los días por el número de créditos ganados. Por ejemplo, si el usuario gana 2 créditos, la tabla cambia de la siguiente manera. Es como subir todo el gráfico.

10 | 
9 | | 
8 | | | | 
7 | | | | | | | | | | | 
6 | | | | | | | | | | | | | | | | | 
5 | | | | | | | | | | | | | | | | | | | | | | | | 
4 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
3 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
2 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
    ------------------------------------------------------------- 
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
^^       ^   
    | \_       | 
    today tomorrow    in 15 days 

si el usuario tiene créditos x hoy y pasa créditos de y, a disminuir la cantidad de créditos a su disposición para x - y, por cada día que tiene una cantidad mayor que x - y. Durante días no tiene más que x - y, la cantidad permanece igual. Es como cortar la parte superior del gráfico. Por ejemplo, si el usuario pasa 3 créditos gráfico cambia a

7 | | | | | | | | | | | 
6 | | | | | | | | | | | | | | | | | 
5 | | | | | | | | | | | | | | | | | | | | | | | | 
4 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
3 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
2 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
    ------------------------------------------------------------- 
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
^^       ^   
    | \_       | 
    today tomorrow    in 15 days 

todos los días se cambia el gráfico de la izquierda para modelar los créditos que vencen. El usuario tendrá las siguientes cantidades mañana

7 | | | | | | | | | | 
6 | | | | | | | | | | | | | | | | 
5 | | | | | | | | | | | | | | | | | | | | | | | 
4 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
3 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
2 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
    ------------------------------------------------------------- 
    | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 
^^       ^   
    | \_       | 
    today tomorrow    in 15 days 
+0

Te daría +1 solo por la cantidad de esfuerzo que parece poner en esto. Déjame verlo por unos minutos para darle sentido a lo que dijiste. Pero rápidamente al leerlo, mencionaste tener una mesa para cada usuario. ¿Eso fue un error tipográfico o es eso lo que querías decir? Porque tenemos casi 100k usuarios y una tabla para cada uno estaría un poco fuera de control. Entonces quiero dar sentido a esa pieza de inmediato. – spinon

+0

@spinon Ok, gracias por el comentario. mesa es una mala palabra. Un artefacto de mi pobre inglés. No me refiero a una tabla de base de datos sino a una estructura que contiene cantidades y permite asociarlas con los días. Podría ser una matriz simple fuera de la base de datos. Trataré de reformularlo en una edición. En el caso de una base de datos, solo use 30 columnas durante 30 días y almacene los datos para un usuario en una fila. –

+0

Ok, entiendo eso. Permítanme continuar mis pruebas en contra de esto. – spinon

0

Un enfoque a este problema es almacenar solo las transacciones, no el saldo. Entonces siempre se calcula el saldo en tiempo real cuando sea necesario. Aquí están los datos:

Date : Amount : Expiries 
7/1 : +5 : 7/31 
7/2 : +5 : 8/1 
7/2 : -3 : never 
7/3 : +5 : 8/2 

El saldo en cualquier momento es simplemente el total de todas las transacciones que aún no han vencido. No es necesario ejecutar ningún proceso por lotes.

0

En cuanto a la respuesta de Julians (que no puedo comentar todavía), estoy lidiando con el mismo problema y el enfoque de Julians no funcionará porque eso daría como resultado que la cuenta sea negativa.

Si el usuario no usó el servicio por un mes, el 8/4 el saldo de la cuenta sería -3 y una actividad por valor de 5 llevaría el saldo a 2, no a 5 como debería.

Cuestiones relacionadas