Subversion Repositories SmartDukaan

Last modification

• Rev 37603 – 28 d 5 h
• Author: amit

• Log message:

  Price internal warehouse movements from the stock's original vendor
  
  Stock moving between our own warehouses was priced from the sending internal supplier's
  own vendor catalog, which only ever holds prices copied from elsewhere - so every hop let
  the price drift further from what the group actually paid, and a movement was blocked
  outright whenever that supplier happened to have no row for the item.
  
  It is now derived from the stock being moved: the original EXTERNAL vendor is established
  per unit and that vendor's current catalog price is used. Origin is looked for in
  descending order of certainty - the serial traced back to the external purchase that first
  brought the unit in, then the unit's own inbound PO when that was external, both of which
  are facts that survive any number of internal hops. Non-serialised stock that has already
  moved internally has no recoverable origin at all, since fungible units carry no identity
  and the movement records nothing linking the receiving row to its source, so those fall
  back to the most recent externally approved price for the catalog and are never recorded
  as though their vendor were known.
  
  A purchase order carries one price per item, so an item can only move from one original
  vendor at a time. Where a requested quantity would run past the oldest vendor's stock into
  another's, this refuses and reports how many can move now and at what price, leaving the
  second order to whoever is moving the stock, rather than averaging the two or silently
  splitting the order. Each order therefore stays attributable to one vendor.
  
  Receiving no longer validates price for these movements: both sides of the comparison come
  from the same derivation, so a mismatch cannot mean anything. That also removes a null
  dereference in GrnRequestServiceImpl, which assumed every supplier has a circular.
  
  Removes addVendorPricingIfMissing, which wrote permanent approved pricing rows onto internal
  suppliers sourced from hardcoded vendor 334 for Samsung or an arbitrary findFirst() vendor
  otherwise, stamped with hardcoded auth ids. Those rows are now not just unnecessary but
  harmful: they would pin a stale price that wins over the derived one.
  
  Verified against live data: covers every unit in every warehouse with none unresolved,
  agrees exactly with the origin join the FOCO/ImeiSupplierPricing report already runs in
  production, and prices 12,305 of 13,589 units within 2% of what was actually paid.
  Resolution takes 0.7ms for one item and 1.1ms for ten.