Удобно сделать так:

1. Расчитываешь новые остатки во временную таблицу.
2. Открываешь транзакцию
3. Удаляешь старые остатки
4. Добавляешь новые из вр. таблицы.
5. Закрываешь транзакцию.

Таким образом, длительная операция (расчет остатков) не попадает в транзакцию обновления, и транзакция (и соотв. блокировка) получаются короткими. Все довольны.

Есть еще один приём. Расчитываешь остатки в новую таблицу, а потом в одной транзакции дропаешь старую и переименовываешь новую в старую. Транзакция и блокировка получаются ну очень короткими.

Если данные для расчета беруться один раз (одним запросом), то по барабану абсолютно, никакие изменения расчету не помешают. Если данные считываются несколько раз, то скинь их одноразовым чтением во временую табличку, а дальше колупай её сколько хочешь раз. Надо не бояться использовать временные таблички, ибо сервер их сам использует весьма интесивно. Естественно, если расчет могучий, то это скажется на работе пользователей тормозами. Но несколько замедлять работу пользователей при закрытии периода гораздо гуманнее, чем полностью блокировать им ввод данных и получение отчетов в течении существенного периода времени, что непременно произойдет, если залочить таблицы.

Перерасчитывать остатки при каждом телодвижении - порочный путь. Тормозами система будет отличаться. Все, что я говорил, касается случая, когда остатки перерасчитываются периодически (например, закрытие периода, дня, etc), а не при каждом вводе новых данных. Обычно делают так: берут остатки в расчитанной таблице остатков за закрытый период + расчитывают остатки на лету по операциям в открытом периоде. Так как в открытом периоде мало данных, то такой расчет происходит быстро.

Насчет вр. табличек: их прелесть как раз в том, что они позволяют избежать блокировок. Впрочем, я не настаиваю. Каждому - свое.

> Потом, представьте ситуацию - товар отгружен сегодня, в остатках это еще не проявилось и менеджер преспокойно выписывает счет на данный товар

Так в этой ситуации как раз помогает то, что я писал "+ расчитывают остатки на лету по операциям в открытом периоде", что означает: менеджер при запуске отчета получит самый свежий и самый правильный остаток, так как сальдо по открытому периоду быстро посчитается и добавиться к расчитанным остаткам прямо в этой же процедуре отчета.

Сложение расчитанных остатков в закрытом периоде и расчитываемых "на лету" остатков в открытом периоде можно упростить и упорядочить применение такого бутерброда, если все это завернуть в одну вьюху, и везде эту вьюху использовать. Работает достаточно производительно, уж поверьте.
Я так в одном проекте делал, может кому пригодится: процедура в фоновом режиме запускалась (раз в несколько минут шедулером) и дорасчитывала остатки по появившимся изменениям в товарно-денежных движениях, комплектуя таблицу остатков. Эта таблица входила во вьюху и туда же во вьюху входил расчет по нерасчитанным движениям. Все отчеты использовали только эту вьюху. Так как движений с нерасчитанными остатками было мало (всего за несколько минут всего несколько движений), то их расчет во вьюхе времени не занимал практически нисколько. Зато все имели корректные остатки на момент запуска отчета. Расчет остатков процедурой в фоновом режиме практически не тормозил никого, так как там применялись методы, о которых я уже писал (со вр. табличками). Кроме того, в этой процедуре дорасчитывались опять же только изменения с момента предыдущего запуска процедуры. Т.е. очень быстро.