Skip to content
Snippets Groups Projects
  1. Nov 04, 2014
  2. Nov 03, 2014
  3. Oct 31, 2014
    • Denis Ledoux's avatar
      [FIX] web: on editable list save, valid all records · df845940
      Denis Ledoux authored
      opw-617036:
      In my current timesheet, if you add a a required field on the timesheet ids lines, and add data in the summary tab, it was possible to validate the timesheet lines while requried fields were missing.
      df845940
    • Mohammad Alhashash's avatar
      [FIX] stock: more tolerant copy method · 8af9fdfa
      Mohammad Alhashash authored
      Allow setting origin/backorder when copying new stock.picking
      Fixes #379, lp:1098557
      8af9fdfa
    • Martin Trigaux's avatar
      [IMP] stock: avoid errors with picking without quantity · aed71f39
      Martin Trigaux authored
      When a line is not present in the partial delivery wizard, computation variables are initialized with generic values (zero quantity, zero price,...). Instead of setting the uom to False, keep the quantity of the move.
      This makes a difference only when the quantity of the move is 0. That means that the move will be marked as complete and can be processed.
      This avoids trying to update the stock.move with a uom at False. opw 616844
      aed71f39
  4. Oct 30, 2014
  5. Oct 29, 2014
    • Christophe Simonis's avatar
      2b2ec074
    • Mohammad Alhashash's avatar
      [FIX] stock: UoS quantity in stock.picking · 43db7267
      Mohammad Alhashash authored
      Implements the UoS TODO items on stock.picking.do_partial() to fix #1432.
      Add a new method _compute_uos_qty() on product.product to computes
      product's invoicing quantity in UoS from quantity in UoM.
      
      The created invoice will use the product_uos of the stock.move, meaning keeping
      the quantity specified on the partial picking and the unit of measure of the
      original stock.move (e.g. recieving 1 dozen from a 12 unit picking should either
      get uos=dozen, uos_qty=1 or uos=unit, uos_qty=12, not a mix of both)
      
      Fixes #1432, opw 611479
      43db7267
  6. Oct 28, 2014
  7. Oct 27, 2014
  8. Oct 24, 2014
  9. Oct 23, 2014
  10. Oct 22, 2014
    • Denis Ledoux's avatar
    • Martin Trigaux's avatar
      [FIX] product.uom: safer handling of factor/factor_inv in UI · 3a0af6af
      Martin Trigaux authored
      Add readonly attribute to avoid sending both factor and factor_inv value to the backend when saving.
      This was possible if the user switched between uom_type to fill the two fields.
      3a0af6af
    • Cédric Snauwaert's avatar
      [FIX] product: remove digits_precision from uom factor fields · fa2f7b86
      Cédric Snauwaert authored
      Remove the hardcoded precision of 12 on factor and factor_inv,
      to use the complete natural precision of NUMERIC types,
      preserving all significant digits.
      
      e.g. a UoM with a factor_inv of 6.0 used to be computed as:
      factor_inv: 6.0 -> factor: 0.166666666667 (1.0/6.0, rounded to 12 digits) -> factor_inv: 5.999999999988 (1.0/factor)
      which could lead to errors such 12*0.166666666667 = 2.000000000004 instead of 2.0
      
      Slightly changed the way the ORM handles float fields to allow setting `digits=0`
      as a way to explicitly require a NUMERIC value but without enforcing/rounding
      the values at the ORM level, i.e. a truly full-precision field.
      
      NUMERIC type has unlimited precision but is less efficient so should not be
      used as the default behaviour, which is why we keep float8 as an alternative.
      
      Modified the view to display the product UOM factor with a 5 digits value by default.
      This value is for usability purpose only, the field still accepts bigger precision, by
      setting the `digits` option on the field in the form view.
      
      This change is safe in a stable series, the `digits=0` alternative is
      treated the same as the default `digits=None` everywhere in the framework,
      except when creating the database field.
      fa2f7b86
    • Martin Trigaux's avatar
      [FIX] base: support float rounding with rounding_method=UP (ceiling) · 7705f883
      Martin Trigaux authored
      Add rounding_method parameter on float_round method to offer
      HALF-UP (default, usual round) or UP (ceiling) rounding method.
      Use the second method instead of math.ceil() for product
      reservations.
      
      For UP, the python math.ceil() method uses "torwards infinity"
      rounding method while we want "away from zero".
      Therefore we use the absolute value of normalized_value to make
      sure than -1.8 is rounded to -2.0 and not -1.
      
      Fixes #1125 #2793
      
      This is a cherry-pick of d4972ffd which was reverted at 333852e1 due
      to remaining issue with negative values.
      7705f883
  11. Oct 21, 2014
    • Martin Trigaux's avatar
      [FIX] report: page numbering rml reports · 354b82be
      Martin Trigaux authored
      Save the NumberedCanvas state before doing a page reset.
      The order of execution when rendering an rml report is the following:
      1. init canevas (_pageNumber = 1)
      2. render the page element
      3. if still pages to render, afterPage method
      4. if still pages to render, showPage method (_pageNumber += 1)
      5. back to step 2 for each page
      6. draw the ResetPage element (setting flag _doPageReset=True)
      7. end the document build with afterPage & showPage method
      
      The PageReset element should be executed at the end of the rendering of a story (subdocument) to reinitialize the page numbers to 0 (for new story) and insert the pageCount element for that story with the total number of pages (needed if want to use tag <pageCount/> in rml).
      
      In case of NumberedCanvas (e.g. used in Trial Balance report), the numbering is generated at the end of the build using the _saved_page_states dict in the canevas.
      To have an accurate _saved_page_states content, it needs to be saved before the pageReset.
      
      Fixes #2225
      354b82be
    • Denis Ledoux's avatar
      [FIX] point_of_sale: no need to specify numeric digits · 78a29b37
      Denis Ledoux authored
      In the report pos order, average_price was set as a numeric(16,2), therefore, if the amount was too big, it led to a psql crash:
      A field with precision 16, scale 2 must round to an absolute value less than 10^14.
      78a29b37
  12. Oct 20, 2014
Loading