[Javier Ader]

Buenas. Mirando MBPartner.setTotalOpenBalance() parece que los pedidos pueden afectar el credito usado (esta medio complicada la sentencia sql … pero algo de eso se puede llegar “a inferir”) y no se si esto tiene sentido, o al menos no se lo veo en todos los escenarios. Esto tambien lleva a que desde MOrder se chequee el estado de credito de la EC.
Bueno, mas alla de esto, no deberia ser esto configurable?
Me imagino que habria que agregar , en MBPartner, digamos, algo como :

Code:

public static booelan orderAffectsCredit()
{
//mira en alguna lado de en la base de datos y determina
//si los pedidos deben afectar el crédito usado;
//cachea el resultado para no acceder en el futuro
}

Este método puede ser usado por ej desde MOrder para saltear el recalculo de credito de una EC, y desde MBpartner.setTotalOpenBalance(), para que la sentencia sql sea distinta (esto es, si orderAffectsCredit es false, la ulitmo exprsion sql seria algo como “0::numeric(20,2) as TotalOrder” ). Todo los demas quedaria igual.

Mi pregunta es si hacer esto es “seguro” o se rompe alguna otra cosa…

[Cognitiva Consultores]

Muy buen punto… Pienso que un pedido por consumar una obligación comercial entre el cliente y su proveedor debe afectar el balance. (Es dinero que el cliente nos debe o que debemos al proveedor.) Es cierto que contablemente el hecho ‘se realiza’ al retirar la mercadería, pero me parece que desde un punto de vista financiero la generación de pedidos puede correctamente configurar un pasivo o un activo.

Esto sin perjuicio de la configurabilidad del comportamiento a capricho del contador, como menciona Javier.

[Javier Ader]

Ok, igual me sigue sin cerrar la idea de que un pedido genere “una deuda”; estas se deberian generar al momento de facturar si es que no se esta pagando en el momento (e.d hay alguna forma de pago a credito en el pago de la factura). Fijate que ademas el pedido afecta el balance solo si el “termino de pago” en el pedido es “A Crédito”; si no, no hace nada….
El termino de pago en un pedido, a mi entender es solo informativo: “cual es el termino de pago que se tiene que usar al facturar este pedido”, pero no en ningún sentido tiene que representar alguna forma de “contrato” entre el la EC y nosotros.

El tema viene por el TPV… (bueno, muchas de las cosas que estoy posteando últimamente vienen por código relacionado al TPV). Ahí se crea un pedido de forma automática que tiene un termino de pago sobre el cual el operador no tiene control (creo que lo toma del termino de pago seteado en la EC… otro valor que es solo informativo, o si se quiere, “indicativo”; pero para nada “obligatorio”). Entonces, lo que termina gobernando si se afecta o no el balance de una EC, son valores “informativos” (esto por ej, te obliga a que muchas veces tengas que configurar “En efectivo” como termino de pagos en TODAS las EC; asi no falla en el TPV cuando se esta el total en efectivo…. este lleva a que simplemente no tenga sentido este campo en la EC, ya que te vez obligado a ponerlo siempre en el mismo valor….). Ahora bien, como se supone que el pedido esta relacionado con el estado de credito de la EC, codigo en MOrder chequea si la EC tiene credito; y ademas le actualiza el balance… algo que 1) ya lo chequea el TPV (y de mejor manera, porque chequea solo por la cantidad que sabe que se va a pagar a credito; NO por el total) 2) lo va a hacer de todas maneras la futura factura generada desde el pedido (si es que el tpv esta configurado para hacerlo automaticamente; si no, cuando se facture el pedido). Esto no solo, se repiten chequeos y actualizaciones, si no que ademas, el chequeo que hace el pedido es por un importe mayor al necesario….

Por todas estas cosas (y principalmente porque semánticamente pienso que un pedido, sin importar el termino de pago, NO debería afectar el balance de la EC) pienso o que se debería sacar esto, o por lo menos que sea configurable.

Yo actualmetne opte por esta ultima forma, poniendo este codigo en MBParnter

Code:

/**
* Determina dependiendo de la configuración del sistema si los pedidos afectan
* el estado de crédito de los clientes.
*
* @return
*/
public static boolean ordersAffectCredit()
{
//TODO: simplemente se retorna false; deberia
//tomarlo y cachearlo desde la configuracion del sistema
return false;
}

Despues modifique el codigo en setTotalOpenBalance() para que dependiendo de setTotalOpenBalance() genere una string sql distinta (en ralidad, simplemten el select que calcula el total en ordernes simplemente lo saque).
Tamien estoy modificando codigo en MOrder para que saltee codigiciones y acutalizaciones del balance dependiendo de lo que retorne este metodo….Me da la sensación que por comentarios en el codigo voy a tener que tocar algo en “AllocationLine.processIt”, porque se lee en MOrder el comentario:

Code:

// Update total revenue and balance / credit limit (reversed on
// AllocationLine.processIt)

No creo que los cambios necesarios vayan mucho mas alla de esto.

De cualquier manera, me da la sensación de que esta configuración es fácilmente reversible; a lo sumo hay que hacer un proceso que cada vez que se cambie esta configuración, recorrer cada una de la EC y le invoque el setTotalOpenBalance(), el cual va a tomar la nueva configuración y por lo tanto tener o no en cuenta a los pedidos y finalmente salvarla (es mas creo que ya hay un proceso que hace esto, aunque me parece que lo hace para una sola EC)

[Cognitiva Consultores]

javAd escribió:

Quote:

Ok, igual me sigue sin cerrar la idea de que un pedido genere “una deuda”; estas se deberian generar al momento de facturar si es que no se esta pagando en el momento (e.d hay alguna forma de pago a credito en el pago de la factura). Fijate que ademas el pedido afecta el balance solo si el “termino de pago” en el pedido es “A Crédito”; si no, no hace nada….
El termino de pago en un pedido, a mi entender es solo informativo: “cual es el termino de pago que se tiene que usar al facturar este pedido”, pero no en ningún sentido tiene que representar alguna forma de “contrato” entre el la EC y nosotros.

A mi me parece perfecto que se pueda parametrizar. Sin embargo, el comportamiento por defecto creo que debería ser el actual. Sino, como harias en los muchos casos donde una empresa entrega mercadería o reserva pedidos sin facturar en el momento? Cuando vendemos a crédito, puedemos hacer la facturación a fin de mes, basandose en los pedidos o remitos. Si el pedido a crédito no genera una deuda, me parece que nos quedaríamos sin control financiero.

[Javier Ader]

(bueno, ahí edite; me había faltadp un NO… si no afirmaba lo contrario que quería).

Si… tiene sentido tu escenario; pero no se si es el más común. Yo creo que lo mas normal es que una empresa desee saber exactamente cuanto le debe un cliente, y ahí si no tenes que contar los pedidos. Imagínate una cobranza…. también, tene en cuenta que podes tener pedidos desde hace 3 meses que simplemente quedaron ahi; no se facturaron ni se remitieron ni nada… Es pedido te cuenta en el balance; uno tiene que andar buceando entre pedidos “no facturados” (algo que no es tan simple de encontrar, salvo que ejecutes una query sql…) para cancelarlos (y en ese caso probablemente tengas un problema de periodo cerrado…).
Otro problema aparejado (aunque no se si tan importante) es que los pedidos no se contabilizan (con todo sentido a mi entender) y por ej, una balance contable te va a diferir de lo que dice el “balance libertya”.

De todas maneras, aún en tu caso, si uno quisiese llevar el total de “pedidos a credito” simplemente habría que agregar una columna a MBParnter; TotalOrders (que ya va de la mano con el nombre que usa el código), y ahi almacenas el valor que esta calculando ahora el código en el 4to campo de la query; ahora, ese TotalOrders no se debería sumar en ningún momento a cosas como “crédito usado” (en donde ahí si entran pagos de facturas o factura sin saldar parcial o totalmente, por ej); es mezclar peras con manzanas. Incluso mas, si queres tener un control de valor máximo sobre este campo, se agrega TotalOrdersLimit, y este si se chequea en de manera similar al credito al momento de completar pedidos a crédito (sería algo como “podes realizar pedidos a crédito sin facturar hasta cierto monto”; no se igual si tendría mucho sentido de control…).

Bueno…. ahora, si me preguntas, entre que sea parametrizable y agregar 2 columna (mas!) a C_BPartner, no se… me parece que que prefiero lo primero (ando medio reticente a agregar columnas o incluso tablas… es mas, si me preguntan, no se si entraría a eliminar muchos campos sin uso…); pero bueno, esto es solo porque muchas tablas , con muchos campos, me complica la vida a mi… no porque sea lo correcto.

[Autor]

Entradas