Hi Cetin,
Yes, a single check is fine. The user on the POS app will be informed if the TOTAL sale amount
is > current balance. The Account would then be unlocked while the POS user can modify the
sale reducing the total sale amount. Once they have reduced the total sale amount, they could
again submit the sale for posting.

Yes, it is true this could go back and forth if users of the ITF app were constantly reducing
the Account balances. That is NOT what really happens business wise, and never will.

Your response:

sum sales_amt to lnSalesTot for SalesID = m.luCurSaleID && luCurSaleID is current sales' id
select Customer && From ITF
if !seek(m.luCustomer, 'customer', 'CustomerID') ;
  or customer.Balance < m.lnSalesTot
  * Customer unknown or Balance is not suitable
  return .F.
endif

No problem with that part. I understand and perfectly OK.

Your response:

set reprocess to 1
declare Sleep in win32API integer
ltStart=datetime()
lnTimeOut = 30
do while !rlock('Customer') and datetime()-ltStart < lnTimeOut
 Sleep(200)
enddo
* set reprocess to old setting
* Either locked or timed-out
if !IsRlocked(recno('Customer'),'customer')
  * Sorry timed out connecting to backend
  return .f.
endif

Sounds like the above is so that VFP tries for a little while without even telling the
user. If so, that's OK and I understand.

I believe it would be better if we just forget (for this conversation), about the
local stuff. I understand what needs to happen locally. It just gets too complex
for me to discuss.

Cetin, I believe I understand what you and possibly Hilmar are trying to tell me.
Are you saying, Yes, you could do that in an error handler but you could also just
handle the RETURN .F. in the above code where this save stuff is occurring.

Is that correct?