Pequeño detalle en MPayment

Inicio Foros Foro principal Desarrolladores Pequeño detalle en MPayment

  • Este debate está vacío.
Viendo 2 entradas - de la 1 a la 2 (de un total de 2)
  • Autor
    Entradas
  • #31401
    Javier Ader
    Participante

    Buenas. Emitiendo una orden de pago usando Trans. Bancaria como medio me aparecieron un par de errores severos (el pago se realiza igual correctamente). Posiblemente ya lo hayan visto, pero bueno, por las dudas lo pongo:

    Code:
    ===========> MPayment.set_Value: CreditCardExpMM=0 – MinValue=1(1) – compared with Numeric Value=0(0) – results in 1 [11]
    ===========> MPayment.set_Value: CreditCardExpYY=0 – MinValue=3(3) – compared with Numeric Value=0(0) – results in 1 [11]
    ===========> MPayment.set_Value: CreditCardExpMM=0 – MinValue=1(1) – compared with Numeric Value=0(0) – results in 1 [11]
    ===========> MPayment.set_Value: CreditCardExpYY=0 – MinValue=3(3) – compared with Numeric Value=0(0) – results in 1 [11]
    ===========> MPayment.set_Value: CreditCardExpMM=0 – MinValue=1(1) – compared with Numeric Value=0(0) – results in 1 [11]
    ===========> MPayment.set_Value: CreditCardExpYY=0 – MinValue=3(3) – compared with Numeric Value=0(0) – results in 1 [11]

    Basicamante es un error de validación de minimo/máximo que esta tirando PO.set_value (se esta queriendo setear por ej, el mes, MM, con cero). Mirando un poco el codigo de MPayment se ve que tiene redefinido setCreditCardExpMM (y YY), y si el valor que se esta queriendo setear no esta entre 1..12, simplemente no hace nada; el el valor esta en ese rango se llama a a super.setCredidCardExpMM (es va a llevar a la validación en set_value de PO, pero en este caso no debería tirar error. Entonces segui mirando un poco mas y vi que en el unico lugar en que se llama sin a super.setCreditCardExpMM (y YY), es en MPayment.clearTenderTypeFields(), que a su vez es solo llamado desde MPayment.beforeSave().
    Las columnas en la base de datos permiten NULL (tiene sentido, no siempre se usan) pero seguro que a nivel de metadatos estas estan definidas como no solo requeridas ni no también con un restricción de limites (no lo chequie pero casi seguro). No se cual sería la modificación para que clearTenderTypeFields no genere estos errores “severos” pero me imagino: o no se llama a super.setCreditCardExp, o se permiten null sobre esta columns a nivel de metadatos, se se llama directamente al “setValue” especial que “saltea” las restricciones.

    También encontré otro pequeño detalle (lo pongo aca para que para no hacer otro thread y que seguramente también ya lo han visto) que esta asociada a la lógica de plugins cuando se intenta buscar un proceso asociada a un boton que “tome” el control en lugar de la clase asociada al proceso en los metadados (la idea si no me equivoco es permitirle a los plugins afectar el comportamiento incluso sin tener que modificar los metadatos; interesante). El tema es que por ej, los botones asociados a la logica de documentos no tiene una clase asociada en los metadatos (tiene asociado un “proceso” pero este proceso, no tiene asociada una clase); y en el campo de classname tiene null (o la string vacía). El tema es que cuando se aplica la logica de documentos en algún punto se ejecuta un getClassForName(null); esto obviamente tira una excepción que finaliza logueada, creo que como “severo” (la solución que veo es que antes de intentar buscar la clase en el paquete del pluging se cheuquee si se esta solictando un nombre de clase “null”; si es asi, se retorna simplemente null). Ahora, exactamente en donde esta esto… se los debo… lo escribí en un txt en algún lado cuando lo vi, pero el txt no lo tengo a la mano en este momento; después lo busco.

    Repito, son detalles y no afectan en nada al comportamiento, solo se terminan logueando cosas “sereras” que no lo son y que se pueden evitar.

    #34509
    Juan Godoy
    Espectador

    CreditCardExpYY=0 – MinValue=3(3) – compared with Numeric Value=0(0) – results in 1

    Buenas, en mi caso se reprodujo este error cuando intente emitir un pago para un periodo (mes+año) que no se encontraba previamente configurado en el sistema.
    Tenia configurados todos los periodos del Año 2012 e intentaba emitir un pago para el periodo 01-2013, sin tener creado el AÑO-PERIODO-CONTROL DE PERIODO.
    Saludos.
    JUAN

Viendo 2 entradas - de la 1 a la 2 (de un total de 2)
  • Debes estar registrado para responder a este debate.