Respuestas de foro creadas
-
Entradas
-
El “valido desde” tiene que ser menor a la “fecha del la linea pedido” (guarda que hay varias fechas… cual no se… a nivel de codigo usa DateOrdered; al parecer se almacena a nivel de linea, ademas de cabecera del pedido; casi seguro algun callout, o algun beforeSave setean este valor; al parecer no se puede especificar desde la ventana porque ese campo no se muestra a nivel de linea), el campo valido hasta no existe (me equivoque yo); y los productos tienen que tener los dos precios especificados (en realidad tiene que tener el Precio de Lista para los pedidos; el precios standard para todo lo demas).
Ok, por lo que veo estas factura una suerte de servicio…. casi seguro que ni siquiera lo tenes especificado en la lista de precios; casi seguro que viene por ahi. Intenta poniendole un “precio” al servicio.
Fijate algo raro: si por el contrario, NO especificas el producto, pero si la descripción, casi seguro que lo permite (el código en general asume que si no esta especifica el producto, se usa la descripción como una suerte de “producto al vuelo”; lo mismo pasa por ej en las facturas y creo que no trae ningún problema usarlo de esa manera, aunque creo que esta deshabilitado).
PD: pienso que algo tiene que haber mal en el código mas allá de que el producto/servicio no tenga precio… Para mi debería ser distinto; si el producto/servicio no tiene precio, bueno, que se deje el que puso el usuario; es mas veo medio dudoso la forma en que “pisa” el valor puesto.
Ni idea… pero me parece que tiene que andar por las listas de precios. Verifica las fechas de validez de las misma (esto explicaría lo de “hasta el 03-11”) y tal vez (no estoy seguro) que las listas tengan “precio de lista” (es no se si asi, pero me parece que al hacer los pedidos se mira en un precio; mientra que al hacer todos los demas documentos se mira en otro; al menos en 10.03).
en 10.03 podes modificar el método createOxpCashPayment(CashPayment p) de la clase PoSOnline, poniendo algo justo despues de la llamada al constructor de MCashLine. Algo por ej como
Code:private void createOxpCashPayment(CashPayment p) throws PosException {
// MCashBook cashBook = new MCashBook(ctx, posConfig.getC_CashBook_ID(), trxName);
MCash cash = MCash.get(ctx, getPoSCOnfig().getCashBookID(), invoiceDate, getTrxName());throwIfFalse(cash.getC_Cash_ID() > 0);
MCashLine cashLine = new MCashLine(cash);
//estas son las lineas nuevas
String desc = “TPV”; //aca le podrias poner “TPV” seguido de la fecha actual
cashLine.addDescription(desc);
//lo que sigue igual….Creo que debe andar; en 10.03 casi seguro, en 10.09 me da la sensación que también debería, pero no lo chequie. Lo de agregarle la fecha actual (busca pro ej en System.getTime(), o algo por el estilo; eso ya es tema de manejar las librerias de Java), te puede servir para matar dos pajaros de un tiro.
Fijate que llamo a addDescription y no a setDescription (esto es por si la linea de caja es usada para pagar mas de una factura…. me da la sensación que eso en 10.03 no es posible pero en 10.09 por unos comentarios que leí puede que se de….); de esta manera, si la misma linea es usada mas de una vez, la descripción anterior no se pierde.
En cuanto a que no respeta los cambios manuales…. Asi parece, al menos en la 10.03 pasaba eso (lo descubrí hace poco y no lo reporte porque no había verifique en la 10.09 siga el problema). El tema en la 10.03 es que cuando apretas F5 para pasar a cobrar, se aplican descuentos mediante el esquema de descuento asociado a la EC. Ahora bien, eso PISA todos los descuentos agregados manualmente y en general te los deja 0 (e.d, al tener un descuento 0, el precio final va a ser el mismo que el dado en la lista de precios).
El hack que halle fue deshabilitar completamente ese calculo automático de descuentos; simplemente comente el cuero del metodo updateOrderProductsDiscounts() en la clase org.openXpertya.pos.model.Order.updateOrderProductsDiscounts().
Al parecer anda…
De cualquier manera eso lo hice para la versión 10.03; en la 10.09 no mire.Las tabla que almacenan las lienas de caja, como todas las tablas, tienen columnas Created y Updated; te tipo timeStamp. Esas columnas por defecto no se muestra en ninguna ventana (y yo no la mostraria tampoco); se pueden ver haciendo doble click en el “cuadradito de numero de filas” (parte inferior, derecha). Si queres que esos datos se visualicen directamente, de solo lectura, podes agregar una columna virtual a la tabla de de las lineas (de tipo fecha, creo) y despues las agregas a la ventana. Algo como
Nombre de columan: UpdatedView
Sql = Updated
Nombre de columan : Creadted
Sql = CreatedEn cuanto a la descripcion desde el tpv no entiendo muy bien… vos al facturar desde el tpv, creas a lo sumo una linea por tipo de pago efectivo (bueno, en realidad creo que se pueden crear mas, pero no es lo comun); a esa linea de caja, para que queres agregarle un descripcion en particular? para saber que lineas se generaron desde el tpv? La descripción creo que ya esta siendo usada por el TPV.
de que forma? porque se se podia solucionar de 3 maneras: o modificando la forma en trabaja “Verificar arbol” o en que la instalación por defecto no traiga ese “nodo 0” o que la el cvs de importación haya sido modificado para que “reparentee” las originales (esto último no se si es posible….).
Ya no recuerdo bien a que conclusión habia llegado… pero creo que lo correcto es que el nodo “cero” (que no apuntaba a ninguna cuenta, y por eso era eliminado por el “verificar arbol”) directamente no debía existir; y que las cuentas preinstaladas vengan con un nodo asociado y que este nodo sea “nodo padre”. Esto es, como quedaría la base de datos después de ejecutar en “Verficar Arbol”, sin haber hecho antes un importación.
Ok, todo esto dependiendo de que se entiende por “nodo padre”; por lo que había inferido del código, un nodo padre es aquel que no tiene padre, no aquel que tiene un id = 0 (esto es, no existe un nodo especial que representa a la raíz del arbol); y como cualquier otro nodo debe referenciar a “algo válido” (si no, “verficar arbol” lo va eliminar).y entonces (agregando a lo que dijo Federico), si no cambiaron tambien esto (me parece que no….), deberia acceder a ese perfil con usuario System, password System.
Y si….. puede ser alguna forma de bug. Ahora, deberian dejar de existir la entradas de las importaciones anteriores independientemente de si la importación que estas haciendo tiene exito o no; la razón es que la eliminación de entradas anteriores (si mal no recuerdo) se realiza antes de la importación en curso. Por otra parte…. la eliminación de entradas anteriores filtra por fecha (e.d elimina entradas creadas hace cierto tiempo), asi que puede ser que ocurra lo que decís. Tal vez, haciendo una pequeña trampa, te las elimine: te logueas eligiendo un fecha en el futuro. Igual, no te lo recomiendo, ya que la importación actual puede que tome esa fecha… El delete desde el pgAmdmin lo veo definitivamente mas simple….
Entiendo, pero lo que veo medio mal es porque estas generando una lista de precios de venta por cada proveedor…
Ahora bien, por tu descripción “intuyo” que cada producto es proveeido por solo un proveedor; es así? Si es así, podes generar una sola lista de venta con todos los productos y listo.
Ok, me parece que se de cualquier manera se te va a complicar un poco como generar esta lista a partir de multiples listas de costos…. lo mas simple seria, nuevamente tener una sola lista de costos con todos los productos y a partir de esta generar la lista de ventas.De cualquier manera, yo tambien pienso que es demasiado estricto eso de “usar una sola lista de precios por factura” (tiene cierto sentido, por cuestiones de “seguridad”; e.d que el no permitir al usario vender a cualquier precios… pero esto a la vez es un poco contradictorio con el hecho de que se puede darle permisos al usuario a modificar el precio…..); esto creo que deberia ser configurable, y por defecto, permitir a usar cualquier de las versiones de listas de precios.
Siguiendo esta idea, pienso que habría que hacer un par de modificaciones de núcleo; no se si serán tan grandes o no…. El problema es que la factura referencia a una lista de precios (ni siquiera a una versión); pero no hacen lo mismo las lineas de las facturas. En términos prácticos, cuando un genera una factura desde la ventana (no desde el TPV), la lista de precios en la cabecera se usa solo para saber si los precios incluyen o no IVA (creo que también la moneda y la precisión… pero esto esto no se si es muy usado). A mi entender, la lista de precios de la cabecera se debería usar solo como “la lista default para las lineas” (la inclusión o no de IVA en los precios se debería especificar a parte…), pero que cada linea referencia a la versión de lista en particular usada en esa linea (una configuración de perfil determinaría si el usuario puede o no mezclar mas de una lista en una factura).La lista de precios que usa el TPV se fija en la configuracion de TPV. Porque no te permite elegir otra… no lo se, esta hecho asi. La idea, supongo, es que el usuario que se encarga de realizar las ventas no tiene que poder elegir la lista de precios; es una manera a obligarlo a usar siempre los mismos precios (de cualquier manera tengo entendido que apretnado F6 o F7 no recuerdo, te permite cambiar la lista de ventas a usar).
Lo que yo te decia, es que en cualuqier caso (o en la configuración del tpv o via F6) era que vos podes especificar cuales la lista de precios a usar, no cual es la version en particular. Por eso te digo, si queres estar seguro de que precios van a usarse (salvo que hagas cosas como las que dice cognitiva), no te compliques teniendo mas de una version de lista por cada lista de precios; usa siempre una sola version por lista. El InfoProduct que usa el TPV tampoco te permite seleccionar tampoco la versión (y aunque lo hiciese no cambia nada las cosas, porque el precio lo toma de la lista especifica en la configuración o cambiada via F7).Me parece que es un tema general: yo en general no usaría mas de una versión por lista (en realidad a mi resulta bastante innecesario el concepto de “versión” de lista…). El problema de usar mas de una versión por lista es que no es tan claro que versión va a usar en determinado momento. Fijate que casi todas las entidades referencian a listas, no a versiones (por ej, en la factura queda registrada la lista y no la versión; lo mismo la ECs), pero los precios reales estan en las versiones, no en las listas.
En conclusión: puede que la idea de tener mas de una versión por lista tenga sentido en ciertas circunstancias, pero en general, a mi enteder, no es necesario y trae mas problemas. Te diria “pases” la versión 2 a otra lista de precios (no creo que lo vayas a poder hacer desde libertya mismo, pero si desde pgAdmin: crea otra lista de libertya y referenciala desde M_PriceList_Version.M_PriceList_ID ).Buenas Franco. Más allá de lo que decís, sigo pensando que es incorrecto. Los TotalTenders (emisiones de pagos), son para registrar pagos reales, y típicamente van precedidos de un leyenda “Recibos:” (y si uno una factura por 100$ lee “recibimos: efectivo 100”, se entiende que esta saldada, cuando esto no es necesariamente el caso con el código actual incluso cuando no se generaran automáticamente lineas de cajas). La PaymentRule pienso que se deberia usar para registrar solo la forma de pagos requeridas para pagar lo que falta saldar, no se deberia tomar nunca como un pago por el simple hecho de que tal pago no se realizo. Esto es, la PaymentRule es solo para especificar como el cliente deberia pagar lo que falta (“pagame lo que resta en efectivo; pagame lo que resta a 30 dias, etc”).
Ahora bien, si no se quiere perder esta información (que en realidad solo tendria sentido para aquellas facturas no saldadas completamente) se podria imprimir como texto fiscal antes de los items (las strings de observaciones en Document; yo actualmente estoy usando estas lineas, pero para otros datos).
Ahora bien, en las facturas no-TPV, seteadas para “generar un linea caja”, no lo probe pero deberían ser impresas y tratadas exactamente igual que facturas generadas desde el TPV y totalmente saldadas en efectivo. Si esto no ocurre (creo que no, ya que las tablas que son afectadas desde el TPV y desde la “completacion” de facturas, son distintas; en particular, creo que la ultima NO genera una AllocationLine y por lo tanto FiscalDocumentPrint no va “a ver” ningún pago), se deberia tratar como un caso especial (o modificar el codigo de MInovice.completeIt para que sea consistente con la lógica del TPV). Las facturas no-TPV, con reglas de pago “efetivo” pero sin generación automatica de la linea de caja, se deberian tratar como una factura sin ningun pago real (y como dije, si no se quiere perder la información del “acuerdo de pago”, se envia como un texto fiscal antes de los items).En conclusión, la forma en que pienso que deberia tratarse todos estos casos serian:
1) si FiscalDocumentPrint, encuentra la menos un pago real, actua tal como hasta ahora junto con la modificación del codigo del driver para tratar correctamente “el último pago” (esto igual debería darse solo en casos bastante raros).
2) si FiscalDocumentPrint no encuentra ningun pago
2.1) si “descubre” que fue creada con “generar linea de caja”, genera un solo pago por el total utilzando la misma leyenda que usaria en 1) para pagos en efectivo (esto de paso, logra una consistencia que ahora no existe).
2.2) si no, no emite ningún pago real; a lo sumo setea la regla de pago como una observación fiscal.En el caso 1 entran todas las facturas generadas desde el TPV con al menos un pago “real” (cualquiera de los medios de pagos que no sean “A crédito”). En el caso 2.1 entrarían solo aquellas facturas no-TPV que fueron creadas con “generar linea de caja”; en el caso 2.2 entrarían aquellas facturas TPV cuyo único medio de pago es “A Crédito”, las facturas no-TPV cuya regla de pago no era efectivo y las facturas no-TPV cuyo medio de pago sí era efectivo, pero no generaron una linea de caja por el total. En todos los casos, la regla de pago nunca va a parar a un TotalTender.
En cuanto a cuando imprimir la regla de pago en las observaciones, supongo que se podría simplificar e imprimirse siempre (el único problema potencial acá es que estas lineas son escasas; existen solo 4 en la mayoría de los documentos; de cualquier manera el código actual no esta haciendo uso de ninguna de ellas; en un versión propia se están imprimiendo por ej los números de pedidos y código del vendedor, en estos caso ya jode un poco mas darle un “linea” para imprimir este dato).
PD : tal vez, no haya que imprimir la regla de pagos como observación, si no, los términos de pagos…
Bueno, aporto unas modificaciones que hice para manejar el tema del último TotalTender permitido; básicamente agregue tres métodos (yo los agregue a un driver que aún no termino completamte; despues lo subo; en el código de 10.09 o 10.03 debería ir en HasarFiscalPrinter.printInvoice, posiblemente modificando la forma en que se llama a cmdTotaTender):
Code://SOPORTE PARA PrintPayments. Ader 20 oct 2010
/**
* Detemina si el CF soporta la cancelación de documentos despues de la emisión
* de un TotalTender; todas las tiqueadoras no soportan la cancelación leugos
* de la emisión de un TotalTender “excepto en los modelos SMH/P-PR5F (versión 2.01),
* SMH/P-715F (versiones 3.02 y posteriores), y SMH/P-441F.” (Sic. 3.4.10 TotalTender, Doc Hasar
* PubTick.pdf); todas las facturadoras parecen no permitir esto (Sic. 3.7.1. Cancel , Doc Hasar
* PubFact). Implemtanción default retonra false.
* @return
*/
protected boolean allowCancelAfterTotalTender()
{
return false;
}/**
* Dada una respuesta a un TotalTender retorna el valor del campo que representa
* el faltante para saldar el total de la factura según el CF. Un valor
* positivo supone un faltante; cero saldado exactamente; y un némero negativo
* reqpresenta “cambio”.
* NOTA: este metodo retorna null si encuentra algún problema (por ej, el rspTotalTender
* no tiene el formado requerido); esto es asi porque propagar una excepcion en este
* punto puede llegar a dejar a varios CF en un estado de bloqueo (los documetnos abiertos
* no se pueden cancelar luego de emitido un TotalTender en mucho modelos/versiones).
* NOTA2: esta implementación siempre retorna un BigDeciaml redondeado a dos decimales
* con redondeo DOWN (hacia cero); esto no deberia afectar ya que todos CF Hasar retorna 2 decimales
* en esta respueta.
* @param rspTotalTender
* @return
*/
protected BigDecimal getRemainingAmount(FiscalPacket rspTotalTender)
{
BigDecimal remAmount = null;
if (rspTotalTender == null)
return null;
try{
//el monto esta en 3er campo
String remAmoutString = rspTotalTender.getString(3);
//se asume que que el CF no retorna cosas raras como “+.00” o “-0.”
remAmount = new BigDecimal(remAmoutString);
remAmount = remAmount.setScale(2, RoundingMode.DOWN);
}catch(Exception ex){}return remAmount;
}
//FIN de soporte para printPayments/**
* Ref C++ Hasar: ver ImpresorFiscal::ImprimirPago
* NOTA Maxima cantidad de pagos permitidos: Este metodo emite a los sumo
* getAllowedPaymentQty() de TotalTenders
* NOTA Tiqueadoras: Para los modelos SMH/P-715F -versiones 3.02 y posteriores-,
* SMH/P-PR5F -versión 2.01- y SMH/P-441F puede emitirse 5 veces; 4 en el resto.
*
* NOTA Cancelacion luego de pagos: esta implementación invoca a setCancellowed(false) luego
* de la emisión de un TotalTender solo si allowCancelAfterTotalTender() retonra false. Esto último
* es el comportamiento por defecto, ya que todas los CF Hasar no permiten la cancelación
* de docuemtnos luego de la emisión de un TotalTender, salvo las tiqueadoras
* SMH/P-715F -versiones 3.02 y posteriores-, SMH/P-PR5F -versión 2.01- y SMH/P-441F en
* las cuales la cancelación SIEMPRE es posible; los drivers de estos modelos deberían redefinir
* allowCancelAfterTotalTender() para que retorne true.
*
*
* Comentario acerda del último pago: El Comando TotalTender asociado puede
* fallar (es rechazado) si el pago adeudado es 0, o, mas importante, si se esta emitiendo
* el ultimo TotalTender permitido (el quinto o el cuarto, dep. del modelo/version) y este no
* alcanza a saldar totalmente el monto a saldar. Aca hay dos posibles soluciones: siempre emitir
* una cantidad menor de TotalTenders (4 o 3 maximo, dep. del modeolo/version) o en usar el valor
* de la respuesta Monto Faltante del anterior TotalTender usar este monto como el
* monto del ulimto TotalTender en caso de que Payment.getAmount sea menor.
* NOTA modificación 20 oct 2010 :
* MODIFICACION DE MANJEJO DE ULITMO TOTAL TENDER:
* 1) Por cada Payment
* -SI, monto faltante según el CF es menor o igual que cero; finaliza la impresión de pagos
* -SI no, si estamos estamos en el ultimo pago y este es menor al faltante, CAMBIAR MONTO de pago
* al faltante y posiblemente su descripción
* 2) ejecución normal de un TotalTender, chequear si se deben prohibir cancelaciones,
* actualización del total faltante a partir de la respueta del TotalTender.
*
* @param payments
*/
protected void printPayments(Listpayments) throws FiscalPrinterIOException, FiscalPrinterStatusError
{
if (payments == null || payments.size()<=0) return; int maxTotalTenders = getAllowedPaymentQty(); BigDecimal remAmount = null; for (int i = 0; i < payments.size(); i++) { Payment pay = payments.get(i); BigDecimal payAmount = pay.getAmount(); String payDesc = pay.getDescription(); int numPayment = i + 1; //1,2,3.... if (numPayment > maxTotalTenders)
{
//NO debeira pasar, significa que se agregar mas payments que los
//permitidos a por getAllowedPaymentQty
break;
}
//assert(numPayment<= maxTotalTenders) if (remAmount != null) { if (remAmount.compareTo(BigDecimal.ZERO)<=0) { //se saldo completamente y aún quedan pagos! aca podria ir //un warning o mensaje, ya que no deberia pasar en general break; } //assert(remAmount != null && remAmount > 0)-> esto es, hay faltante//estamos por emitir el ulitmo TotalTender permitido, hay que chequear
//redondeos o modifaciones de la descripción del pago y del monto
//a pagar eviando remAmount para que no genere error (obligadamente se debe saldar
//completamente el documento con este TotalTender).
//Estas modificaiones solo son necesarias cuando el monto del pago es menor a
//el faltante; si es mayor o igual no se genera error nunca.
if (numPayment == maxTotalTenders && payAmount.compareTo(remAmount)< 0) { //el monto que le falta a payAmount para saldar completamente el documento BigDecimal difCredito = remAmount.subtract(payAmount); //modificación de la descripción original: //por simplicidad SIEMPRE se agrega a la descipción //"CC: difCredito, Resto:
//esto es, se supone que no hay error de redondeo; otra forma
//seria simplemente poner “Otro Pagos” y no usar el prefijo.
payDesc = “CC:” + difCredito.toPlainString()
+”, Resto:” + payDesc;
//finalmente, el monto a pagar realmente se pone a remAmount, asi
//el TotalTender salda exactametne el total de la factura. Este
//es el unico punto en que se cambia el monto a enviar.
payAmount = remAmount;}
}//se ejecuta el TotalTender
FiscalPacket rspTotalTender = execute(
cmdTotalTender( payDesc,payAmount,””));//solo setea cancelAllowed a false, si el CF NO permite la cancelación de documentos
//luego de un TotalTender.
if (!allowCancelAfterTotalTender())
setCancelAllowed(false);//se atualiza el totalFaltante o cambio
remAmount = getRemainingAmount(rspTotalTender);
//assert(remAmount != null) si no seria un error de formato en la respuesta}
}
Esta bastante comentado, supongo que se entiende; básicamente opte por implementar la solución mas complicada (esto es permite la emisión de pagos máxima, pero si se llega al último pago permitido y se ve que no va saldar completamente la factura, se cambiar el valor a emitir en el pago, pero cambiándole la descripción).
OBS: mi versión de printDocument(Invoice) no llama directamente cmdTotalTender si no que lo delega a printPayments; es decir las lineasCode://////////////////////////////////////////////////////////////
// Se ingresan los pagos realizados por el comprador.
// Comando: @TotalTender
for (Payment payment : invoice.getPayments()) {
execute(cmdTotalTender(
payment.getDescription(),
payment.getAmount(),
false,
null)
);
setCancelAllowed(false);
}se cambian por
Code://////////////////////////////////////////////////////////////
// Se ingresan los pagos realizados por el comprador.
// varios @TotalTender
printPayments(invoice.getPayments());Testeo:
lo testie forzando a llegar al limite te pagos y no saldar:
Total a pagar:
A PAGAR: 363,00
-50 efectivo
-100 tarjeta 1234, cupon 1
-100 tarjeta 1234, cupon 2
-100 tarteta 1234, cupon 3
-Resto a Credito desde el TPV: 13.00
Esto genera 4 TotalTenders (y por el efectivo y 3 por los pagos con tarjeta), pero el ulimto que emite de las tarjeta los hace por 113.00 , con la descripcion de la forma “CC:13.00, Resto:Visa 1”. Esto es, salda completamte la factura con el ultimo pago, pero le cambia la descripción reflejando este hecho.
EL otro teste que hice fue por el mismo monto y cantidad de pagos reales, pero de tal manera que no sea necesario una parte a crédito:
A PAGAR: 363,00
-50 efectivo
-110 tarjeta 1234, cupon 1001
-90 tarjeta 1234, cupon 1002
-113 tarteta 1234, cupon 1003
El último pago salda exactamente la factura, asi que al emitir el úttimo TotalTender, no le cambia la descripción.la opción de borrar los ya importados en realidad se refieren a las entradas importadas en (valga la redundancia) importaciones anteriores (esa opción lo que hace básicamente es borrar un tabla temporal antes de ingresar las nuevas).
No hay opción desde libertya de borrar importaciones anteriores sin importar nada (es decir te obliga a hacer un importación para poder borrar registros anteriores); es un limitación, pero no creo que sea muy grave; repitiendo la importación por segunda vez tal como hiciste todos los entradas ya importadas no van a volver a importarse, pero si van a borrarse.
Otra opción es borrar la tabla temporal que tiene las entradas a importar manaulmente desde pgadmin (DELETE FROM NombreTablaTemporal ); en donde el nombre de la tabla la podes obtener haciendo doble click en la parte de la ventana en que te muestra el numero de registros (parte inferior derecha de todas las ventanas); las tablas temporales comienzan, creo que todas, por convención con el prefijo “T_”.El precio asociado al proveedor, tengo entendido no se usa (en realidad toda esa pestaña me parece que no tiene una lógica detrás que le un uso importante más allá de dejarte registrar que proveedores te venden determinados artículos).
Los precios que realmente vas a usar son las precios asociados en la pestaña Precios (el que realmente importa es el Precio de Referencia, no el de Lista; el Precio limite es para no permitir vender un producto mas allá de un monto; 0 significa sin limite); en la venta vas a usar los asociados alguna de las listas de ventas; en la compra los asociados a algunas de las listas de compra.