fix: double future qty updates

[ankush]

This is an edge case, where if you have transactions like these then canceling the middle transaction results in double processing of future quantity.

The incorrect data resolves itself in some time once the backdated entry is processed.

This is because:

1. Future qty for those SLE with same posting time are updated in update_entries_after

Here all SLE that match posting date time (after removing milliseconds) are processed.

erpnext/erpnext/stock/stock_ledger.py

Lines 440 to 461 in c4d20ce

	def get_sle_against_current_voucher(self):
	self.args["time_format"] = "%H:%i:%s"
	return frappe.db.sql(
	"""
	select
	*, timestamp(posting_date, posting_time) as "timestamp"
	from
	`tabStock Ledger Entry`
	where
	item_code = %(item_code)s
	and warehouse = %(warehouse)s
	and is_cancelled = 0
	and timestamp(posting_date, time_format(posting_time, %(time_format)s)) = timestamp(%(posting_date)s, time_format(%(posting_time)s, %(time_format)s))
	order by
	creation ASC
	for update
	""",
	self.args,
	as_dict=1,
	)

2. Same are again updated when doing update future qty.

erpnext/erpnext/stock/stock_ledger.py

Lines 1301 to 1314 in c4d20ce

	frappe.db.sql(
	"""
	update `tabStock Ledger Entry`
	set qty_after_transaction = qty_after_transaction + {qty_shift}
	where
	item_code = %(item_code)s
	and warehouse = %(warehouse)s
	and voucher_no != %(voucher_no)s
	and is_cancelled = 0
	and (timestamp(posting_date, posting_time) > timestamp(%(posting_date)s, %(posting_time)s)
	or (
	timestamp(posting_date, posting_time) = timestamp(%(posting_date)s, %(posting_time)s)
	and creation > %(creation)s
	)

Since step 1 updates all current posting time SLEs, only strictly newer SLEs should be updated while updating qty.

Both these function calls in this order (i.e. this exact code execution path) ONLY occurs when you are making backdated entry.

TODO:

• check impact on similar query part for stock reco
  

  erpnext/erpnext/stock/stock_ledger.py

  Lines 1377 to 1385 in c4d20ce

  	def get_datetime_limit_condition(detail):
  	return f"""
  	and
  	(timestamp(posting_date, posting_time) < timestamp('{detail.posting_date}', '{detail.posting_time}')
  	or (
  	timestamp(posting_date, posting_time) = timestamp('{detail.posting_date}', '{detail.posting_time}')
  	and creation < '{detail.creation}'
  	)
  	)"""

Unrelated fix:

Sort SLEs while picking the next stock reco entry:
0fb6062#diff-7a6f48ad1157b2728d67c44c2bdb26439c7eec44a4241b915070f63fef695f95R1382

[ankush]

unrelated test_tax_rule failing (on like 80-90% PRs now, its time has come 🥲 #30934 )