1. 07 Dec, 2019 2 commits
  2. 01 Dec, 2019 5 commits
  3. 30 Nov, 2019 1 commit
  4. 26 Nov, 2019 2 commits
    • Andrew Danger Lyon's avatar
      adding stupid comment · 0eb09836
      Andrew Danger Lyon authored
    • Andrew Danger Lyon's avatar
      More initial order cost updates · 8fb10a06
      Andrew Danger Lyon authored
      regarding tracker#37 ...making the first order "free" as in the company
      initiating the order will not see those costs added to their books
      (because the cost is effectively 0). this seeds the data with an initial
      order and keeps the costs from being polluted in cases where they might
      be astronomically high with an initial order with a high volume (like
      with electricity)
  5. 25 Nov, 2019 3 commits
    • Andrew Danger Lyon's avatar
      fixing count, removing print · e8804c73
      Andrew Danger Lyon authored
    • Andrew Danger Lyon's avatar
      now including all orders int he rolling index · 7bf19531
      Andrew Danger Lyon authored
      changing the rolling index for orders to INCLUDE non-finalized orders,
      and index them by create date. i am realizing using only the
      update+finalized orders is too rigid (an order cannot be marked as
      anything other than finalized after or it would corrupt the index and
      double-dount the order once it was finalized again). using create date
      or non-finalized orders is not ideal, but it's more "resilient" and
      also doesn't prevent us from doing filtering when pulling the orders
      out. the only real problem would be orders that take longer than a year
      to fill, but we can cross that bridge when we get there (likely by
      increasing the time window on a per-company basis).
      this has one side effect, which is actually what spurred the change in
      the first place: if we're trying to come up with costs for a product, we
      can include the current non-finalized orders in our calculations. what
      we do is say if we have less than 10 finalized orders, include
      non-finalized orders in the calculations as well. this helps alleviate
      bloated costs for the first few orders.
      in other words, if i make electricity and it's sold by the watthour and
      someone makes an order of 10000 watthours, even if i've only worked one
      day, the cost previously would be 8 * 10000, or 80000 labor hours for
      the order (because the outgoing costs of the order are not included
      because the order isn't finalized yet!) by including the order itself as
      a cost divider (remember, the basic algorithm is inputs/outputs) then
      the cost of a watthour of electricity becomes (8 / 10000) instead (and
      at 10000wh, the total cost for the order is 8 labor hours, which is
      pretty much exactly what we want).
      this is a good change.
    • Andrew Danger Lyon's avatar
      adding some test stuff to costs crate. the idea is we can generate a set of... · 8075ac13
      Andrew Danger Lyon authored
      adding some test stuff to costs crate. the idea is we can generate a set of test data given a company id such that we can pump the data into the costs algorithm and get the output. this allows us to pick apart WHY a thing costs what it does in an order-by-order way.
  6. 19 Nov, 2019 2 commits
  7. 18 Nov, 2019 2 commits
  8. 19 Oct, 2019 2 commits
  9. 06 Oct, 2019 4 commits
  10. 04 Oct, 2019 1 commit
  11. 28 Sep, 2019 5 commits
  12. 25 Sep, 2019 2 commits
  13. 24 Sep, 2019 6 commits
  14. 21 Sep, 2019 1 commit
  15. 18 Sep, 2019 2 commits