Respuestas de foro creadas
-
Entradas
-
Te faltaron crear objetos de datos tales la vista rv_payment. Deberías tener 126 vistas como mínimo en el esquema Libertya.
Bueno, me equivoqué sobre el origen del problema. Pinchaba porque el tpv estaba configurado para generar Presupuestos. Hay un problema con eso…
Saludos.
Sigo con problemas. Lo que observé es que en realidad, el problema son los pagos con cheque. Tome una instalación en blanco y configuré varios medios de cobro, y pincha para el de cheque. No veo nada raro en la C_POSPaymentMedium_ID.
Por lo que veo, no funciona el cobro con cheques en el TPV 10.9
O me equivoco y alguien le funciona???
fcristina escribió:
Quote:El algoritmo requiere su tiempo dado que el mismo es genérico, logrando generar las combinaciones también para casos en los que la cantidad de atributos sea más que dos.Saludos,
FedericoFede, eso esta funcional? si armo un conjunto de atributos de mas de 2 atributos, no va a tener representación matricial lo cual no me importa, pero va a funcionar correctamente el resto??? Yo pensaba que no.
Dario, las organizaciones comparten el mismo plan de cuentas. De manera que separar en calendarios puede no ser del todo consistente.
Por otro lado, el calendario se define a nivel compañia en LY, y no a nivel Organización. Con perfil de administrador de compañia en Compañia, Informacion de Compañia seteas el calendario a ese nivel.
Saludos
Hola Franco. Una consulta referido a los cierres de almacén.
Por lo que vi, la funcionalidad a la que te referis solo es aplicable a remitos de salida pero no de entrada…
Eso es así intencionalmente? No deberían controlarse también los ingresos de stock en un almacen cerrado?
Javier, una consulta.
Las info que programaron, son compatibles con la vista matricial que agregó el plugin de curva DetalleColor? o se puede aplicar estos cambios sobre dicho avance??
Gracias!
No se si me quedo del todo claro tu consulta… pero por las dudas te comento que en LY las percepciones no se calculan sobre bases imponibles. Simplemente cargas el monto percibido que te indica la factura de compra y listo.
Otra opción es simplemente revertir las facturas en cuestión. Eso va a anular las asignaciones en efectivo. Luego habria que volver a cargar las facturas correctamente.
Bueno, habilitamos varios que estan deshabilitados pero ninguno era lo que queríamos, de manera que hicimos una vista para reportearla desde LY. El resultado de utilizar proyectos a nivel línea de documento es interesante porque las campañas/proyectos puede verse como un Caso de Negocio en términos de utilidad o rentabilidad, agrupando en positivo las ventas y en negativos las compras se obtiene la ganancia o pérdida en pesos por proyecto, que es lo que el cliente nos estaba solicitando.
El resultado es algo como:
Campaña | Proyecto | ClienteDelProyecto | Utilidad($)
…
…
…
Total de utilidad: xxx$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.
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.