i_bison,

такая схема вполне рабочая...
для её фунциклирования необходимы несколько условий:
1. по железу:
- для мамки подобрать процессор по максимуму
- должно быть по два гига оперативки на каждого юзера (то есть если одновременно четверо - то восемь)
- на каждого юзера два гига на HDD, то есть если в остатке сейчас гиг-два на диске С, то это не хорошо
- операционка и база должны лежать на очень шустром SSD
2. По базе данных:
Акцесс такая хрень, что не зависимо от железа при определенном размере файла БД начинаются тормоза
и этот размер коррелируется со схемой БД, чем проще БД (с десяток таблиц и парой связей) тем при большем
размере БД начинаются тормоза, база может устойчиво работать и при размере в гиг и более...
Чем сложнее БД (50 таблиц и более и все они жутко связаны между собой паутиной) - тем быстрее могут
проявляться тормоза - обычно это становится заметным при размере файла более 100 мб и как раз в таких
интерфейсах которые вы привели выше (когда в форму тащится неимоверное количество источников данных
с наложением фильтров, условий и т.д.)

Я так думаю нужно смотреть в сторону очистки БД... ну например копию действующей сохранить отдельно для
историков, а действующую почистить (оставить только продажи за этот год и реальные остатки)

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

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