Галактика в вопросах и ответах

Нет никакого повышения быстродействия, т.к. при списании все равно идет проверка на сальдовые остатки. Интерфейс выбора из текущих остатков если в нем наложить фильтр по складу и мол вообще умирает
при большом количестве ТМЦ хотя по логике не должен.
Имхо не нужны таблицы текущих остатков, а есть плохая организация таблиц сальдовых и отсутствие в скл group by.
К примеру кому нужна сейчас saldofnd? В версии 550 например она была нужна т.к. saldomc хранила остатки на произвольную дату,
а saldofnd контрольные точки движения что позволяло быстро ограничить sporder и сосчитать сальдо на произвольную дату, а зачем она сейчас когда сальдо считается на все даты движения?

2Oiko
Ну а как же,например, интерфейс выбора из прайс-листа - думаю его загрузка была бы дольше,если бы там инфа подтягивалась из saldomc. Я не говорю об объеме данных, хранящихся в таблицах сальдовых остатков и в таблицах текущиъх остатков. А даже только потому,что оптимальную create view интер-са,исходя из структуры saldomc построить было бы трудно.

2 Den напишем свой фейс и проверим?

oiko писал(а):2 Den напишем свой фейс и проверим?

А что писать то..стандартный и так из текущих берет ...ты хочешь попробовать написать чтоб эти цифири брались из saldomc ? )

Угу - уверен особо медленней он не будет

Как ты построишь view,которая будет строиться при иннициализации фейса. Я имею ввиду вот этот момент:

((
...
prices.cthing==saldomc.cmc
...
))

Работать будет медленнее, однозначно.

Так как запись придется искать на определенную дату.
Можно и не пытаться даже.
Тем более что тут придется исчо и производственные сальдо отсекать, так как они не нужны в продажах например...

+
по SaldoMc резерв вы не определите ни как!

резерв конечно никак

Да и без резерва даже медленнее будет...
- запись придется искать на определенную дату (как заметил Seybukan правильно)
- размер таблицы saldomc бывает в десятки раз больше таблицы текущих остатков. Чисто физически выборка будет идти дольше по любому...

oiko писал(а):Интерфейс выбора из текущих остатков если в нем наложить фильтр по складу и мол вообще умирает
при большом количестве ТМЦ хотя по логике не должен.

Да, вот проблема серьезная. Решать так и не собираются, видимо.

Решил написать сюда.
Есть накладная на передачу ТМЦ в ремонты. При нажатии кнопки "перевод в ремонты" формируется 2 ордера, списание со склада и приход в ремонт.
Хочу чтобы при хозяйственном способе ремонта (своими силами) ордер в ремонт не формировался. Ничего лучше не нашел как повесить альтер на событие и после создания удалить ремонтный ордер.
Но наверное надо же пересчитать остатки (текущие или сальдовые или все вмесет) ? Каким объектным интерфейсом воспользоваться?

чтоб списать МЦ в ремонте служит акт на списание. почему не пользуетесь? разаработчики переделали разрезы хранения и в модуле ремонт расчета текущих вообще нет

потому и не пользуемся, что это лишний документ кладовщикам. кода они передают МЦ в ремонт подрядчикам, то переводим их в ремонт и учитываем в разрезе подрядчиков. при получении КС2,3 производим списание из ремонта по заявке.
А когда списываем на ремонт пару кг гвоздей, и ремонт собственными силами, нет смысла их переводить сначала в ремонт а потом тут же списывать из ремонта. Документов очень много, в результате куча ненужных операций, кладовщики и так стонут.