Доброго времени суток!
ТиС 7.70.932 правленная не одним поколением (и не 2-мя) программистов.

1. У начальства появилось желание отгружать товар с одного склада 2-мя фирмами.
Поступление товара планируется делать только на одну из них.

2. Так же был необходим экспорт (стандартной обработкой) различных (для каждой фирмы) проводок во внешние базы.

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

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

Пока 2 наиболее очевидных варианта:
1) настройка параметров учета -> режим работы -> контроль остатков тмц = по компании
Отчеты удобоваримы и логичны (почти всегда) в разрезе по фирмам, видны долги по каждой из фирм и т.п.
Но: регистры не закрываются по измерению фирмы, а база распухает и без того достаточно быстро.
2) создать отдельный документ реализции (или отдельный код операции, который пользователи будут проставлять для второй фирмы)и отдельные проводки прикрутить именно к нему, а отчеты смотреть в разрезе договоров. Либо значительно править отчеты, т.к., н-р, ведомость по группе контрагентов будет выглядеть не особо удобоваримо.
"Но" здесь являются множественные правки конфы с возможностью что-то не учесть и сделать большой ай-яй-яй...
---
Jill,
vcv, как доберусь вообще решил класс регистров с методами на прямых запилить и т.о. избавиться от РассчитатьРегистрыНа...
Не с той стороны берёшься. Сначала бы подумал о базе данных и её индексах, потом уже о прямых запросах. Не оптимальный прямой запрос будет работать медленнее оптимального черного.
Почему выгрузка итогов с (76) отрабатывает более чем в 1000 раз быстрее чем
ВремЗаявки.УстановитьЗначениеФильтра("Фирма",ФирмаДляОстатковТМЦ, 2);
Ну смотри. Предположим, измерения регистра такие (порядок важен):
Фирма, Номенклатура, ДоговорПокупателя, ...
1С по ним стоит комплексный индекс Фирма+Номенклатура+ДоговорПокупателя
Теперь спрашивается, если у тебя фирма указана списком значений, будет ли 1С использовать индекс? Ведь для быстрого поиска по индексу, а не тупого скана всей таблицы данных, необходимо точно знать все компоненты индекса, посчитать индексное выражение и только тогда быстро выбирать данные по индексу.
А у тебя, скорее всего, при выборе данных по списку фирм, индекс не может использоваться даже частично, что бы хотя бы данные по фирме отобрать. Получаешь скан всей таблицы и своё замедление в 1000 раз.
Если просто тупо переделаешь на прямой запрос, ну будет он, предположим, работать в 10 раз быстрее. Получишь замедление не в 1000 раз, а всего лишь в 100.
Если тебе так уж надо выборку итогов по нескольким фирмам, попробуй, на копии базы, поиграть с порядком измерений. Например, поставить первым ДоговорПокупателя. Можно еще пробовать использовать галочки на измерении "Отбор итогов" и "Отбор движений". Это создаёт дополнительные индексы, которые могут ускорить выборку. Только не переусердствуй, индексы, ускоряют выборку данных (если условия выборки попадают в индекс), но замедляют запись данных в таблицу.
---
И снова вопрос: заявки очистил, стало чуть быстрее, но гораздо менее, чем ожидалось.
Полез в отладчик и увидел: если провожу реализацию не в ТА - делается:

```1c
    Если ИтогиАктуальны()=0 Тогда
    ВремРегистры.Актуальность(1);
    ВремРегистры.РассчитатьРегистрыНа(ТекущийДокумент());
    КонецЕсли;
```

После чего

```1c
    ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1);
```

считается НАМНОГО быстрее (естественно - фильтры в ФильтрЗаявок(...) отработали), но если проводить на ТА то ВыгрузитьИтоги размышляет ну очень ощутимо...

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

ЗЫ: напоминаю ТиС 7.70.932 сильно правленная (но в данной ситации, я думаю, можно ориентироваться на типовую).
Вознаграждение за лучший ответ на данный вопрос добавил.
---
Jill, Предполагаю, что в первом случае ВыгрузитьИтоги выгружает их из кэша, куда их загрузил РассчитатьРегистрыНа. Во втором случае ВыгрузитьИтоги читает их из базы. Поэтому и долго.
Попробуй поставить две строки подряд ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1)
Скорее всего первая при проведении на ТА будет выполняться медленно, а вторая - быстро.
---
vcv,

Документ.Реализация.Модуль Документа 302 ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1); 614 84.008754 49.45
Документ.Реализация.Модуль Документа 304 ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1); //Втор 614 83.970272 49.43

Вот масштабы катастрофы:
На ТА:

Документ.Реализация.Модуль Документа 302 ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1); 614 83.726007 97.78

До ТА:

Документ.Реализация.Модуль Документа 542 ВремРегистры.РассчитатьРегистрыНа(ТекущийДокумент()); 1 2.918570 45.39
Документ.Реализация.Модуль Документа 302 ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1); 614 1.548476 24.08

(Время с 6-ю символами за запятой)
Это все при включенном контроле остатков "По компании" и реализацией с 614 строчками...
---
vcv, сговнокодил вот это:

```1c
    Если ТипЗначенияСтр(ФирмаДляОстатковТМЦ)="СписокЗначений" Тогда
    ТекФирма=ФирмаДляОстатковТМЦ.ПолучитьЗначение(1);
    ВремЗаявки.УстановитьЗначениеФильтра("Фирма",ТекФирма,1);
    ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1);

    КолФирм=ФирмаДляОстатковТМЦ.РазмерСписка();
    Если КолФирм>0 Тогда
    Для ТекНомФирмы=2 По КолФирм Цикл
    ТекФирма=ФирмаДляОстатковТМЦ.ПолучитьЗначение(ТекНомФирмы);
    ВремЗаявки.УстановитьЗначениеФильтра("Фирма",ТекФирма,1);
    ВремЗаявки.ВыгрузитьИтоги(ВремТИЗаявки,1,1);

    Для Стр=1 По ВремТИЗаявки.КоличествоСтрок() Цикл
    ТИЗаявки.НоваяСтрока();
    Для Кол=1 По ВремТИЗаявки.КоличествоКолонок() Цикл
    ТИЗаявки.УстановитьЗначение(ТИЗаявки.КоличествоСтрок(),Кол,ВремТИЗаявки.ПолучитьЗначение(Стр,Кол));
    КонецЦикла;
    КонецЦикла;

    КонецЦикла;
    КонецЕсли;
    Иначе
    ВремЗаявки.УстановитьЗначениеФильтра("Фирма",ФирмаДляОстатковТМЦ,1);
    ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1);
    КонецЕсли;
```

В ПогаситьЗаявки и получил:

До ТА

Документ.Реализация.Модуль Документа 569 ВремРегистры.РассчитатьРегистрыНа(ТекущийДокумент()); 1 2.398985 55.34
...
бла-бла-бла
...
Документ.Реализация.Модуль Документа 314 ВремЗаявки.ВыгрузитьИтоги(ВремТИЗаявки,1,1); 1228 0.034018 0.79

На ТА

Документ.Реализация.Модуль Документа 314 ВремЗаявки.ВыгрузитьИтоги(ВремТИЗаявки,1,1); 1228 0.058813 2.97

Какой-то страшный прирост. Может я где-то сурово ошибся (вроде все норм., но я 3-и сутки бодрствую)?
---
проведи дефрагментацию диска - ускоряет.
используй удаление нулевых итогов http://infostart.ru/public/180018/ - ускоряет (например, для открытия периода ускорение весьма существенное!!!)
---
CheBurator, дефрагментация делается по планировщику. С этим все ок.
Удаление нулевых итогов - так я вчера ночью, после общения с Вами, всю таблицу регистров и грохнул.
Обработку видел - просто побоялся ее сразу пользовать ("на свой страх и риск", вроде, по понятным причинам, но как-то страшно все-равно делается :))) а код посмотреть - руки не дошли)...

Проблема, как будто, решена (если я где не перехимичил), но как-то сильно удивляет...

Почему выгрузка итогов с (76) отрабатывает более чем в 1000 раз быстрее чем

```1c
    ВремЗаявки.УстановитьЗначениеФильтра("Фирма",ФирмаДляОстатковТМЦ, 2);
```

хотя функционал подразумевает сильно сходный...

Странно.
---
Подниму тему.
При работе на реальной базе возникли некоторые трудности.
При формировании перепродаж анализируются (к слову достаточно продолжительный период времени) отрезки существования партий и в точках наибольшего их пересечения генерируются документы.
Но, к сожалению, при работе с пробной базой согласно варианту 1 из (1) я не учел резервы...

(9) CheBurator, у Вас интеллектуальные перепродажи учитывали резервы, или компания работала без резервирования товара?
---
Jill, При реализации со второй фирмы, делать автоматом: 1. реализацию с первой на вторую и 2. поступление с первой на вторую.
Естественно при перепроведении эти документы должны изменяться, и они документы созданные автоматически не могут изменяться вручную.
---
Помнится, встречалась обработка как раз для таких случаев, которая по итогам дня на все отгруженное с "чужого" склада создавала документ реализации между фирмами.

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

Но вообще наличие таких документов (продажа/покупка), естественно, предполагалось, но за пределами ТиС...
Т.е. пока предлагается рассматривать для ТиС именно схему (мнимого) дарения...
---
В свое время лет 7 назад делал обработку, которая собирала в кучу реализацию за период в минус по фирме ХХХ и формировала Поступление товара на ХХХ в паре с продажей от фирмы УУУ, бухгалтер выполняла обработку в ТиС каждую неделю. ЗАтем выгружала в 1С Бухг. Почему в ТиС перед выгрузкой а не в Бухг после? как раз для того чтобы регистры закрывались.

Сейчас в 1С УТ 10.3 подобная обработка существует сразу с коробки.
---
ssega, спасибо.

Но, именно это уже обсуждалось в (2) и (3).
---
> обработку, которая собирала в кучу реализацию за период в минус по фирме ХХХ
- осталось понять - эти минуса - это просто незакрытые плюсом с соседней фирмы или же нарушение учета и среди легальных минусов затесались и голимые "продажи в минус" - а такое запросто.. любят в таких конторах то контроль остатокв отключить, то криво внутрях дописать... ;-)
.
Будь пердельно бздителен!
.
Кстати, организация таких автоперепродаж для закрытия минусов - скорее всего (давно было, могу лажать) приведет к невозможнсоти получить повторную распечатку счф с тем же набором гтд что и первая распечатка... а с 2015 г. обещаются усилит контроль по ГТД...
---
CheBurator, понятно, что "обработка формирующая в кучу перепродажу" - это только парнокопытное, округлой формы, в межзвездном безвоздушном пространстве. Идея, бишь.

Формирование перепродажи за какой-то период мне вообще видится предприятием в реальности слабо применимым. А если нечего было фирме, получающей товар, перепродавать на начало периода? Т.е. формировать перепродажу нужно будет именно перед документом реализации и именно с теми партиями, которые попали в реализацию. Плюс рассчитывать суммы перепродажи, мне кажется, следует именно исходя из стоимости тех самых партий. Т.о. ГТД - это далеко не первое о чем следует волноваться. Они (ГТДы), выдернутые из необходимых партий, вряд ли будут отличаться.

Основными проблемами/неудобствами мне видятся еще и следующие моменты:
1. док-т перепродажи размазанный ровным слоем по всему месяцу (именно с такой периодичностью "закрываются" возможности поковыряться сзади), особенно при хорошем документообороте (1500 док-тов в день) и нештатной ситуации (а они 100% поначалу будут)
2. сам процесс формирования требует слишком много телодвижений и времязатрат:
 а) восстановление последовательности с корректировкой всех (реальных) минусов
 б) формирование перепродаж
 в) еще одно перепроведение всех реализаций второй фирмы

И это все еще без учета таких ситуаций, как, первое, что на ум приходит: реализация на фирма2, возврат от покупателя, реализация данного товара от фирма1. Делать обратную перепродажу? Или плевать на минуса - регистр-то, как будто, закрывается (если не делать перепродажу)? А если возврат на фирма2 спустя месяц случился? Таки делаем? Вручную? А как это пользователям объяснить? Они складскую заявку два-три раза распечатать и отдать на сборку иногда умудряются и товар уезжает (и это при том, что им предупреждение выводится, что данная накладная уже была распечатана N раз)...

Вообщем, если остановлюсь, таки, на сей схеме (а пока все идет именно к этому), то не знаю как там дела с бздительностью будут обстоять, но дефицита бздения, точно, не предвидится... Как бы не поседеть.
---
Наверное, да. Все-таки следует этой самой обработкой анализировать еще и возвраты и делать в т.ч. и обратную перепродажу.
Чтобы никаких "лишних ручек" в документе...

Жонглирование товаром, все же, меньшее зло, чем ассенизаторские работы детским совочком (которые сделаются неотвратимыми, сразу после того, как "лишние ручки" те документы потрогают).
---
в свое время делал "интеллектуальные" перепродажи.
то есть в отчетном периоде работаем от 2 фирм.
в конце периода запускаем обработку. быдлопрограммисты генерят под каждую реализацию в минус - отдельную перепродажу. что вообщем сильномного получается, и для более-менее нечерной фирмы неприемлимо. Чуть более умные программисты генерять перепродажи за день. за неделю. Уже получше, но впринципе - та же самая хрень... я делал так: анализировал и находил "ключевые точки" в которых обязательно должна быть перепродажа. все необходимые "перепродажи" под каждую реализацию в минусовой фирме консолидировались в эти ключевые точки. Хорошо прокатывало когда большие опотзакупы и мелкие продажи. Потом добавил к этому перестройку в течении дня документов приходов-расходов (грубо говоря - все приходы в начало дня, все расходы в конец) - это позволило еще лучше консолидировать ключевые точки. но бОшку пришлось поломать... да, были и мы когда-то рысками... ;-)
---
CheBurator, медитирую на тему ключевых точек.
Поступления товаров всегда в начало дня проводятся. Пользователи сами, на уровне рефлексов, сие организуют.

Основная проблема в том, что товарный запас держится на складе минимальный (1-3 дня). И интервал заказа тоже небольшой (с недели начинается и поставщиков с таким интервалом заказа масса). Ну и, понятно, все заказы никак не в один день делаются, а ровненькой нагрузкой на отдел закупок, в соответствии с графиком...

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

Пути назад, увы, нет. Остановились на этой схеме. Показалась наиболее логичной.
---
Один хрен в одной базе должны быть как минимум 2 документа - продажа от фирмы1 на фирму2 + поступление на фирму 2 от фирмы 1.
+Продавать нужно, как минимум по себестоимости + минимальная наценка (хоть в копейку)... Итого, на фирма 2 товар будет уже по другой себестоимости.
Ну.. короче, кучу моментов надо учитывать.
---
, (13) Тсрпё, ну да...
Я так в (7) и сказал:

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

Не обязательно 2: можно и одну "перепродажу" слепить... Если захотят иные проводки по данным движениям видеть, то, вероятно, так и придется поступить.
А пока да: 1 перепродажа = 1 реализация от фирма1 + 1 поступление ТМЦ на фирма2.

По-поводу "итого, на фирма 2 товар будет уже по другой себестоимости": пока, честно говоря, не улавливаю почему это проблема и чем это чревато... :(
---
в течении месяца продажники видят один профит (прибыль свою), при закрытии (когда накладные слепишь) - себестоимость выше - прибыль ниже.
Если их зарплата зависит от профита - будут "вопросы".
---
Тсрпё, понятно.

Ну, тут картина такая: разница будет не особо серьезная, ибо наценка должна быть, действительно, минимальной.
Да и трудоработы по выяснению величины профита, на данный момент, и так всецело лежат на плечах начальства (вердикт выдвигается исходя из цифр базы начальства, а не торговой).
Т.е. либо они пойдут навстречу продажникам и будут считать з/п "из первоначальной себестоимости" (маловероятно), либо это дело одного разговора с объяснением того, что подсчет делается по итогам закрытия месяца (бунт, вряд ли, должен подняться).

На самом деле текущие формулы расчета з/п мне не доступны, но, в любом случае, мне кажется, что это момент, скорее, организационный, чем проблема, которую следует решать программно...
---
не факт. профит может сильно упасть. бо перепродажа может делать по существенно высокой цене, чтобы минимизировать уплату НДС за счет высокого входного НДС.. особенно когда продаванская фирма -серомутночерная...
---
Тсрпё, да, один документ будет. В одну из баз перепродажа грузится не должна...
Хотят отдельной суммой перепродажи видеть...
---
+12 у нас "закрытие дня" по таким фирмам, делается в конце месяца(квартала) обработками - лепятся и приходы и расходы.
В течении отчетного периода можно продавать "чужой товар".
---
Ситуация есть следующая:
Есть две фирмы по два склада у каждой, торговля идет от двух ППешников по остаткам "четырех" складов
Дописан документ "Продажа" и "Возврат", в которых доступны все остатки, документы контролируют отрицательные остатки и делают движения ТОЛЬКО
по списанию соответствующих остатков с соответствующей фирмы и склада
Ночью запускается обработка, которая по каждой отдельной фирме и складу, откуда продавался товар делает расходные накладные и соответствующие приходные накладные на конкретного ПП + автоматически переносит все приходные документы в начало дня + перепроводятся документы "Продажа"/"Возврат", которые делают уже правильные движения, т.к. приход на ПП у нас есть
Отдельно было написано отчет по "Продажа/наценка", чтобы правильно видеть реальную ситуацию по продажам, с которых считаются бонусы продавцам
---
Еще одну тему создавать не стал...

Вообщем защит от дурака в документы подобалял, документ перепродажи слепил, алгоритм формирования перепродаж, вроде, тоже понятен...
Но столкнулся с проблемой: классом прямого запроса давно не пользовался (все как-то sqlite обходился), а тут, раз нужно "еще позавчера" решил не мудрить (с регистрами поудобней), но увы...

Второе условие никак не хочет отрабатывать...
Буду благодарен за толчок в верном направлении.

Кусок запроса:
---
Jill, это зачем? а средствами 7.7 религия не позволяет пользоваться?

```1c
    ТекстЗапроса =
    "//{{ЗАПРОС(Сформировать)
    |Период с ДатаНачала по ДатаКонца;
    |Фирма = Регистр.ПартииНаличие.Фирма;
    |УпрАналитика = Регистр.ПартииНаличие.Фирма.УпрАналитика;
    |ЮрЛицо = Регистр.ПартииНаличие.Фирма.ЮрЛицо;
    |СтатусПартии = Регистр.ПартииНаличие.СтатусПартии;
    |Номенклатура = Регистр.ПартииНаличие.Номенклатура;
    |МОЛ = Регистр.ПартииНаличие.МОЛ;
    |Партия = Регистр.ПартииНаличие.Партия;
    |СвойствоПартии = Регистр.ПартииНаличие.Партия.Свойство;
    |Поставщик = Регистр.ПартииНаличие.Партия.Поставщик;
    |Док = Регистр.ПартииНаличие.ТекущийДокумент;
    |КодОперации = Регистр.ПартииНаличие.КодОперации;
    |Количество = Регистр.ПартииНаличие.Количество;
    |Сумма = Регистр.ПартииНаличие.СуммаРуб;
    |Функция НачОстС = НачОст(Сумма);
    |Функция ПриходС = Приход(Сумма);
    |Функция РасходС = Расход(Сумма);
    |Функция КонОстС = КонОст(Сумма);";
```
---
monkbest, именно.
---
Jill, как говорил Немец в фильме Брат "Бывает"
---
monkbest, На более-менее больших базах пользоваться штатными запросами 1С может только тот, кто понял жизнь и никуда не торопится. Как я ему завидую!!! :)
---
vcv, угу. Черный запрос=первый шаг к дзэн буддизму.
А на "более-менее больших", да на "менее-более новом" железе можно знатно преуспеть в его постижении.
---
vcv, боле менее большая - это сколько в Гб?
---
monkbest, запрос свой править не стал. Но суть, я думаю, будет ясна.

Ваш:

```1c
    ТекстЗапроса =
    "//{{ЗАПРОС(Сформировать)
    |Период с ДатаНачала по ДатаКонца;
    |Фирма = Регистр.ПартииНаличие.Фирма;
    |УпрАналитика = Регистр.ПартииНаличие.Фирма.УпрАналитика;
    |ЮрЛицо = Регистр.ПартииНаличие.Фирма.ЮрЛицо;
    |СтатусПартии = Регистр.ПартииНаличие.СтатусПартии;
    |Номенклатура = Регистр.ПартииНаличие.Номенклатура;
    |МОЛ = Регистр.ПартииНаличие.МОЛ;
    |Партия = Регистр.ПартииНаличие.Партия;
    |СвойствоПартии = Регистр.ПартииНаличие.Партия.Свойство;
    |Поставщик = Регистр.ПартииНаличие.Партия.Поставщик;
    |Док = Регистр.ПартииНаличие.ТекущийДокумент;
    |КодОперации = Регистр.ПартииНаличие.КодОперации;
    |Количество = Регистр.ПартииНаличие.Количество;
    |Сумма = Регистр.ПартииНаличие.СуммаРуб;
    |Функция НачОстС = НачОст(Сумма);
    |Функция ПриходС = Приход(Сумма);
    |Функция РасходС = Расход(Сумма);
    |Функция КонОстС = КонОст(Сумма);";
```

Итого время запроса: 29108 миллисекунд

Мой:

```1c
    ТекстПрямЗапр="
    |SEL ECT
    | julianday(Substr(Рег.ДатаКонцаПер,1,4)||'-'||Substr(Рег.ДатаКонцаПер,5,2)||'-'||Substr(Рег.ДатаКонцаПер,7,2))-julianday(Substr(Рег.ДатаНачалаПер,1,4)||'-'||Substr(Рег.ДатаНачалаПер,5,2)||'-'||Substr(Рег.ДатаНачалаПер,7,2)) as РазмерОтрезка,
    | Рег.ДатаНачалаПер as [НачалоПериода $Дата],
    | Рег.ВремяНачалаПер as ВремяНачалаПерМил,
    | (julianday(Substr(Рег.ДатаНачалаПер,1,4)||'-'||Substr(Рег.ДатаНачалаПер,5,2)||'-'||Substr(Рег.ДатаНачалаПер,7,2))-julianday('1800-01-01'))*864000000+Рег.ВремяНачалаПер as ДатаВремяНачПерВМил,
    | Рег.ДатаКонцаПер as [КонецПериода $Дата],
    | Рег.ВремяКонцаПер as ВремяКонцаПерМил,
    | (julianday(Substr(Рег.ДатаКонцаПер,1,4)||'-'||Substr(Рег.ДатаКонцаПер,5,2)||'-'||Substr(Рег.ДатаКонцаПер,7,2))-julianday('1800-01-01'))*864000000+Рег.ВремяКонцаПер as ДатаВремяКонПерВМил,
    | Рег.Номенклатура as [Номенклатура $Справочник.Номенклатура],
    | Рег.Партия as [Партия $Справочник.Партии],
    | Рег.Количество as Количество
    |
    |FROM
    | (
    | SELECT
    | CASE WHEN ЖурПриход.Date<:ДатаС THEN :ДатаС ELSE ЖурПриход.Date END as ДатаНачалаПер,
    | CASE WHEN ЖурПриход.Date<:ДатаС THEN 0 ELSE str2id(replace(ЖурПриход.Time,' ','')) END as ВремяНачалаПер,
    | Жур.Date as ДатаКонцаПер,
    | str2id(replace(Жур.Time,' ','')) as ВремяКонцаПер,
    | РегПарт.Номенклатура as Номенклатура,
    | РегПарт.Партия as Партия,
    | РегПарт.Количество as Количество,
    | РегПарт2.Фирма as ФирмаПродавец
    | FR OM
    | [Журнал] as Жур
    | INNER JOIN [Регистр.ПартииНаличие] as РегПарт on
    | (
    | (РегПарт.IdDoc = Жур.IdDoc)
    | and (РегПарт.Debkred=1)
    | and (РегПарт.Фирма=:ФирмаПолучатель)
    | and (Жур.date between :ДатаС and :ДатаПо)
    | )
    | INNER JOIN [Справочник.Партии] as СпрПарт on РегПарт.Партия=СпрПарт.Id
    | INNER JOIN [Журнал] as ЖурПриход on ЖурПриход.IdDoc=Substr(СпрПарт.ПриходныйДокумент,5,9)
    | INNER JOIN [Регистр.ПартииНаличие] as РегПарт2 on
    | (
    | (РегПарт2.IdDoc = ЖурПриход.IdDoc)
    | and (РегПарт2.Debkred=0)
    | and (РегПарт2.Фирма=:ФирмаПродавец)
    | )
    | ) as Рег
    |
    |GROUP BY
    | ДатаВремяНачПерВМил,
    | ДатаВремяКонПерВМил,
    | Номенклатура,
    | Партия,
    | Количество
    |
    |";
```

Итого время запроса: 587 миллисекунд

Просто второе "итого" мне чуть больше нравится.
---
Jill, Приведи "чёрный" и "прямой" запросы к одинаковому функционалу и разница будет не столь трагична. Например, в чёрном запросе есть соединение со справочником фирм для получения ЮрЛица и УпрАналитики, а в прямом это не делал. В штатном запросе есть переменная "Док = Регистр.ПартииНаличие.ТекущийДокумент", которая вполне может вызывать соединение с таблицей движений регистра, а в прямом что-то не вижу обращения к движениям (может просто не увидел).
(45) monkbest, vcv, боле менее большая - это сколько в Гб?
Зависит от документооборота, количества пользователей и тому прочее. У меня уже за сотню перевалила. Считаю её большой для 7.7.
---
vcv, будет достаточно трагична. Да и реализовать весь функционал sqlite в черном запросе весьма проблемно.

Вот версия черного делающая малую часть прямого, но ничего особо лишнего (тут я конечно ручаться не могу, ибо оптимизатором черных запросов не являюсь):

```1c
    ТекстЗапроса =
    "
    |Период с ДатаС по ДатаПо;
    |Без итогов;
    |
    |ДатаНачалаПер=Регистр.ПартииНаличие.ТекущийДокумент.ДатаДок;
    |ДатаКонцаПер=Регистр.ПартииНаличие.ДатаПартии;
    |
    |Номенклатура = Регистр.ПартииНаличие.Номенклатура;
    |Партия = Регистр.ПартииНаличие.Партия;
    |Количество=Регистр.ПартииНаличие.Количество;
    |
    |Функция КоличествоРасход = Расход(Количество);
    |
    |Группировка Номенклатура;
    |Условие ((Регистр.ПартииНаличие.Фирма=Фирма) и (Регистр.ПартииНаличие.ТекущийДокумент.Фирма=ФирмаПолучатель));
    |";
```

Итого время запроса: 33415 миллисекунд

Против все тех же: 868 миллисекунд (железо сейчас более загружено)
---
Jill, Ну что прямой запрос, обычно, работает гораздо быстрее "чёрного", я возражать не буду.
Но что вы запросом хотели получить? Судя по фильтру Фирма - ФирмаПолучатель, это выборка перемещений.
Предлагаю такой вариант:

```1c
    Функция ОтборДокументов(ТекущийДокумент)
    Если ТекущийДокумент.Фирма <> ФирмаОтправитель Тогда
    Возврат 0;
    ИначеЕсли ТекущийДокумент.ФирмаПолучатель <> ФирмаПолучатель Тогда
    Возврат 0;
    Иначе
    Возврат 1;
    КонецЕсли;
    КонецФункции // ОтборДокументов

    ТекстЗапроса =
    "
    |Период с ДатаС по ДатаПо;
    |Без итогов;
    |
    |ДатаНачалаПер=Регистр.ПартииНаличие.ТекущийДокумент.ДатаДок;
    |ДатаКонцаПер=Регистр.ПартииНаличие.ДатаПартии;
    |
    |Фирма = Регистр.ПартииНаличие.Фирма;
    |Номенклатура = Регистр.ПартииНаличие.Номенклатура;
    |КодОперации = Регистр.ПартииНаличие.КодОперации;
    |Количество=Регистр.ПартииНаличие.Количество;
    |ТекущийДокумент=Регистр.ПартииНаличие.ТекущийДокумент;
    |
    |Функция КоличествоРасход = Расход(Количество);
    |Функция КоличествоПриход = Приход(Количество);
    |
    |Группировка Номенклатура Без групп;
    |Условие(КодОперации = Перечисление.КодыОпераций.Перемещение);
    |Условие ((Фирма=ФирмаОтправитель) или (Фирма=ФирмаПолучатель));
    |Условие (ОтборДокументов(ТекущийДокумент)=1);
    |";
```
---
vcv, да, тут я, конечно, пургу сморозил...

```1c
    ТекстЗапроса =
    "
    |Период с ДатаС по ДатаПо;
    |Без итогов;
    |
    |ФирмаПокуп=Регистр.ПартииНаличие.Фирма;
    |ФирмаПродав=Регистр.ПартииНаличие.Партия.ПриходныйДокумент.Фирма;
    |ДатаНачалаПер=Регистр.ПартииНаличие.Партия.ПриходныйДокумент.ДатаДок;
    |ДатаКонцаПер=Регистр.ПартииНаличие.ДатаПартии;
    |
    |Номенклатура = Регистр.ПартииНаличие.Номенклатура;
    |Партия = Регистр.ПартииНаличие.Партия;
    |Количество=Регистр.ПартииНаличие.Количество;
    |
    |Функция КоличествоРасход = Расход(Количество);
    |
    |Группировка ДатаНачалаПер;
    |Группировка ДатаКонцаПер;
    |Группировка Номенклатура без Групп;
    |Группировка Партия;
    |Группировка Количество;
    |Условие ((ФирмаПокуп=ФирмаПолучатель)и (ФирмаПродав=Фирма));
    |";
```

Итого время запроса: 8101 миллисекунд против 365 миллисекунд

Сначала просто то что предложили запустил, а после "откорректировал" без вывода куда-либо...

Тем не менее: быстрее в 20 с лишним раз и функционала только часть, т.е. дальше еще таблицы "крутить"...
---
Jill, Тут есть как еще ускорить. Раза этак в два, а то и больше. Но это не важно - прямой запрос всё равно лучше. :)
---
Для получения расхода ОстанкиИОбороты - это ..ид..изм.
Пользуй или РегистрОбороты или реальную табличку движения регистра
---
Тсрпё, кхм...
Ок.

  ТекстПрямЗапроса="
  |SELECT
  | Рег.Номенклатура as [Номенклатура $Справочник.Номенклатура],
  | Рег.Партия as [Партия $Справочник.Партии],
  | Рег.КоличествоРасход as Количество,
  | Substr(Рег.ПозицияДокумента,1,8) as [ДатаКонцаПер $Дата]
  |FROM
  | $РегистрОбороты.ПартииНаличие(:ДатаС, :ДатаПо, Документ, ((Фирма=:Фирма1) and (ВидДокумента=$ВидДокумента.Реализация)), (Фирма,Номенклатура,Партия,ДатаПартии), (Количество)) as Рег
  |";

А как с условием быть?
---
Не знаю как именно в этом классе (ибо не пользую его) а в обычном запросе всё можно (по виду дока нужно ? )
---
Тсрпё, да. Именно так.
---
смотреть надо доку по классу, или примеры на 1cpp..
я хз, есть ли там ВидДокумента в параметрах ВТ и есть ли параметры типа $ВидДокумента.Реализация
---
Ну и синтаксис смотреть,, где там $ надо ставить, а где нет.
я знаю только как это на 1cpp написать в sql, как это переделать без вт в oledb для дбф и как это будет выглядеть в 1sqlite/

А вот как там оно в Классе.ПрямойЗапрос - хз, смотреть доку по нему надо
---
Тсрпё, спасибо!!!
Вот оно как:
---
Тсрпё, еще один вопрос: в 1sqlite никак не удается время из 36-ричной в 10-ричную перегнать...
Это:

```1c
    str2id(Жур.Time) as ВремяКонцаПер
```
 что-то не вменяемое выдает... :(
---
Сообщение было скрыто модератором.
---
А разве нельзя сделать вторую фирму как аффилированное лицо? И продажа между фирмами будет по себестоимости с "выхлопом" в 0. Так некоторые и делают: например, скутер отгрузят за 10500, а вторую часть цены 11500 проведут через ИП, у которого есть договор с этой фирмой на сборку скутера. Вот фирма платит налог с 10500, а ИП только упрощенка.
---
Или это просто я торможу...
Но, хоть тресни, как из 624760000 17:21:16 получается не догоняю.
---
Jill, нет, таки головокипение виновато (не миллисекунды, а десятые миллисекунды и не str2id(Жур.Time), а str2id(replace(Жур.Time,' ',''))): отлично получается...
---
Возник еще один сопутствующий вопрос: кто как поступал с нумерацией?
По некоторым документам требуется не сквозная нумерация. Т.е. у каждой фирмы своя...

Пока на ум приходят только: переназначение номера при записи (если фирма при открытии и при записи не совпадают) и добавление дублирующих документов.
Может быть в ТиС есть какая-то логика на сие рассчитанная, о которой я не знаю?
---
Jill, префиксы есть в справочники фирмы, но они будут применяться ко всем документам, а не выборочно.
---
AlexInqMetal, есть, но при вводе нового документа фирма берется из умолчаний пользователя, при смене на фирма2 номер не переназначается и благополучно записывается с нумерацией фирма1...
---
Jill, Значит косяк в конфигурации. В типовой ТиС при изменении фирмы (точнее юр.лица, потому что префиксы принадлежат юрлицу) номер у документа меняется.
В документах есть код

```1c
    Процедура ПриИзмененииФирмы()

    Если СтараяФирма <> Фирма Тогда
    // только если изменили
    глПриИзмененииФирмы(Контекст);
    СтараяФирма = Фирма;
    КонецЕсли;

    КонецПроцедуры // ПриИзмененииФирмы()
```

В процедуре в глобальнике есть строки

```1c
    Если Конт.ЮрЛицо <> ЮрЛицоФирмы Тогда
    ПрефиксЮрЛицаФирмы = ?(СокрЛП(ЮрЛицоФирмы.ПрефиксНомеровДокументов)=","0",СокрЛП(ЮрЛицоФирмы.ПрефиксНомеровДокументов));
    Конт.УстановитьНовыйНомер(СокрЛП(Константа.ПрефиксИБ) + ПрефиксЮрЛицаФирмы);
    Конт.ЮрЛицо = ЮрЛицоФирмы;
    КонецЕсли;
```
---
vcv, спасибо.

Некто до меня сделал хорошо:

```1c
    //Конт.УстановитьНовыйНомер(СокрЛП(Константа.ПрефиксИБ) + ПрефиксЮрЛицаФирмы);
```

А я как-то недоглядел...
---
Мне одному не понятно зачем это нужно? Зачем видеть в управленческой базе виртуальные продажи?
---
Aleksey_3, что в данном контексте есть "управленческая база"?

(50) vcv, возник еще вопрос по нумерации: если у документа стоит нумератор, то новый документ с фирма1 (из умолчаний пользователя) про него благополучно забывает (префикса у фирма1 нет) и мы имеем не "рн-***", а "0***1"...

И, соответственно, если убрать ноль из префикса

```1c
    ПрефиксЮрЛицаФирмы = ?(СокрЛП(ЮрЛицоФирмы.ПрефиксНомеровДокументов)=","0",СокрЛП(ЮрЛицоФирмы.ПрефиксНомеровДокументов));
```

имеем проблему с документами без нумератора, если уже были док-ты по фирма2 (с префиксом)...

Т.е. проблема в том, чтобы каким-либо образом вернуть префикс нумератора для фирмы без префикса.
---
Jill, А что мешает указать префикс нумерации документов у юр.лица?
---
vcv, уже имеющаяся нумерация...
---
Вообщем пока только вот такая пурга (оно, правда, какой-то дискомфорт вызывает) на ум пришла:

```1c
    ПрефиксЮрЛицаФирмы = ?(СокрЛП(ЮрЛицоФирмы.ПрефиксНомеровДокументов)=",?(СокрЛП((Метаданные.Документ(ВидДок).Нумератор))="Метаданные","0","),СокрЛП(ЮрЛицоФирмы.ПрефиксНомеровДокументов));
```

Если нумератор есть, но префикса нет - тоже "увы" имеем...

Если у кого есть более вменяемое решение - буду благодарен.
---
Jill, Предлагаю сделать так, что бы пользователь мог в номер документа вписать префикс и 1С сформировала бы новый номер. Навесить во всех документах на реквизит НомерДок вызов глобальной процедуры. Примерно так:

```1c
    Процедура глПриИзмененииНомераДокумента(Конт) Экспорт
    НомерДок = СокрЛП(Конт.НомерДок);
    ПоследнийСимвол = Прав(НомерДок,1);
    Если (ПоследнийСимвол <= "0") ИЛИ (ПоследнийСимвол >= "9") Тогда
    Конт.УстановитьНовыйНомер(НомерДок+"0");
    КонецЕсли;
    КонецПроцедуры
```
---
vcv, вообщем сделал проще.
Для фирмы без префикса проверяю свежесформированный номер на наличие префикса фирмы с префиксом и, если есть делаю ПрефиксЮрЛицаФирмы="0" с переустановкой номера...
А с нового года запрефиксую обе фирмы...
---
Однако возможность написать желаемый префикс и получить новый номер может оказаться ценна.
(58) Вот с подходом "не использование регистров Заявки и ЗаказыЗаявки (но использование Резервы)" хорошо бы послать далеко-далеко в пешее эротическое путешествие. Потому как есть регламенты работы. Менять их без приличного понимания внутренностей функционирования конфигурации чревато проблемами.
Заявки штатно закрываются документом "Отмена заявок", который может заполниться автоматически кучей заявок. Если не удаётся вразумить пользователей, тупо раз в месяц закрывать старые заявки.
Теперь, собственно, сам вопрос: для очистки сделанных движений по соответствующим регистрам достаточно будет прихлопнуть таблицы регистров, или сие будет чревато и нужно подменять обработки проводки документов и перепроводить все накопившееся добро?
А базу не жалко? Мы шашкой машите аккуратней. Закройте древние заявки отменой заявок. Если есть желание, можно дополнить, например, документ закрытия месяца возможностью закрывания старых заявок. Это простенько делается.
И, подозреваю, при вашем бардаке заявками дело не ограничивается. Проверяйте закрытие всех регистров остатков.
---
vcv, я, видимо недопонял предложение.
По двум фирмам, с пустым префиксом для фирма1 и заполненным для фирма2 не отрабатывает корректно нумерация в ситациях когда номер документа уже имеет свой префикс...
Формирование нового номера при ручном редактировании поля документа, на мой взгляд, эту проблему не решает (либо решает не очевидным для меня (я не иронизирую я, правда, непонимаю) образом).
Ну да ладно. Этот вопрос уже не актуален.

Люди уже далеко не первый год таким образом работают. Аналитика заявок/заказов никем не просматривается, а объяснения что дополнительные новые телодвижения необходимы вызывают крайне негативную реакцию. Никаких очевидных профитов они с сего не имеют, а сложности есть.
Отмену заявок делать можно, но это движения по регистрам, без которых они прекрасно существуют. И даже в некоторых ситуациях "мешают": "а почему не вводится на основании? Что значит: "Все заказанные товары либо получены, либо их нет в наличии!" - они же есть"... (Ввод на основании = Копия ТЧ)
+ если раз в месяц закрывать - имеем полное лукошко известной коричневой субстанции в регистрах в течение месяца.

То не шашка. То скорее веревка в туалете - исчезновение движений по этим регистрам никто не заметит (а там действительно ТРЭШ)... А если появится когда-либо необходимость работать по-человечески дернут переключатель в константах и начнут.
+ отсутствие ненужной аналитики еще никому не вредило.

По остальным регистрам пока ничего криминального не нашел...
---
Jill,
По двум фирмам, с пустым префиксом для фирма1 и заполненным для фирма2 не отрабатывает корректно нумерация в ситациях когда номер документа уже имеет свой префикс...
Вариантов несколько:
1. По фирме во всех документах используется единый префикс. Прописываем его в юр.лицо;
2. Документы каждого вида каждой фирмы используют единый префикс. Можно сделать подчинённый фирмам/юр.лицам справочник из двух реквизитов и заполнять его видами документов и нужными префиксами. Установку номера документа при изменении фирмы переделать.
3. Используются разные префиксы для одних и тех же документов. Или система префиксов слишком сложна, что бы вписаться в первые два пункта. Тогда удобней всего будет дать пользователю указать нужный префикс руками и1С поставит правильный номер. Притом, этот пункт отлично сочитается с первыми двумя. Довольно часто бухгалтерия хочет отдельную нумерацию, например, счетов-фактур на аванс. Или отдельно нумеровать накладные по разным складам. Или еще что.
4. Можно сделать отдельную нумерацию по каждой фирме и каждому виду документов. Определять использованные префиксы и генерировать номер. У меня такое сделано прямым запросом на SQL базе.
Аналитика заявок/заказов никем не просматривается, а объяснения что дополнительные новые телодвижения необходимы вызывают крайне негативную реакцию.
Так может поставить вопрос перед руководством в такой форме: вот отчет по заявкам, в нем отражаются НАШИ ОБЯЗАТЕЛЬСТВА перед покупателями совершить отгрузку, что будем с ними делать. Или другой вопрос. С большой вероятностью бардак есть и в резервах. Значит вылавливаем в отчете древние заявки, которые держат какой-то товар в резерве и спрашиваем, а зачем менеджер Вася держит этот товар под себя, когда другим менеджерам этого товара не хватает и они ЗАКУПАЮТСЯ компанией.
И в общем: аргументированно показать руководству бардак в учете с объяснением, что они получат от наведения порядка, обычно вызывает только положительную реакцию руководства.
Аналитика заявок/заказов никем не просматривается, а объяснения что дополнительные новые телодвижения необходимы вызывают крайне негативную реакцию. Никаких очевидных профитов они с сего не имеют, а сложности есть.
Какие сложности-то? Непонятно.
Что значит: "Все заказанные товары либо получены, либо их нет в наличии!" - они же есть"...
Тупое и неинформативное сообщение в типовой конфе - это не повод пытаться корёжить учет. Сообщение должно быть отдельной, вменяемо оформленной, формой (обработкой) и содержать информацию список документов, которые двигали интересуюю заявку/заявки, таблицу номенклатуры с колонками Заявлено, Отгружено, Отменено, Осталось отгрузить, Наличие, Можно отгрузить. Тогда вопросы, обычно, отпадают.
Вот для примера смотри: http://1drv.ms/1xsltAG
А если появится когда-либо необходимость работать по-человечески дернут переключатель в константах и начнут
Вот это показывает пробелы в понимании функционировании конфигурации. Ну запретишь ты движения по заявкам, заказам, оставив только по резервам. Потом "дернут переключатель" и? У тебя же волшебным образом не появятся остатки по регистру заявов, соответствующие остаткам по регистру резервов. А должны. ТиС считает, что заявка без резерва может быть, а вот резерв без соответствующего остатка по заявкам - нет. Тупо получишь минуса по регистру заявок вместо нормального учета.
---
vcv, как только пользователь заведет привычку ручками ковыряться в нумерации, мне кажется, разного рода бяки с нумерацией станут появляться с завидной регулярностью чего очень не хочется.
После НГ праздников приведу к виду укладывающемуся в 1, 2 (типовая задумка). Если захотят большего - буду думать о 4.

Само руководство не считает это "наши обязательства". Это просто информация для продажника о том чего хочет покупатель*. Далее этот вопрос урегулируется продажником с покупателем и по результатам сразу делается реализация.
Т.е. пришла заявка (которая ничего не делает*), сделали либо резерв, либо реализацию (которая забирает товар с остатков и не дает продавать*) на то количество, которое успели.

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

Сложности в принятии лишней* и довольно абстактной (см. "*" выше) информации + телодвижения: снятие заявок и контроль за сим (что им неинтересно: заказали - сколько заказали, дали - сколько смогли).

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

"заявка без резерва может быть, а вот резерв без соответствующего остатка по заявкам - нет" - а вот тут, и правда, видимо, пробел.

Я считал, что схема следующая: неподтвержденная делает приход на Заявки, заявка на склад делает расход с Заявки и приход туда же, только с другим документом + приход на РезервыТМЦ, а реализация спишет и Заявки (которые есть на остатке в регистре) и РезервыТМЦ.

Если из этой схемы убрать Заявки, то имеем: приход на резервы заявкой на склад и расход с резервов реализацией. Если даже на Заявках пусто, а в реализации флаг движения уже стоит, то реализации с Заявок списывать нечего и она, так же, спишет только резервы.

При такой схеме пока не понимаю о каких минусах речь. Я в каком-то из моментов сильно ошибаюсь?

* - мнение пользователся
---
Теперь новый вопрос: при работе по двум фирмам начались серьезные тормоза. Нашел незакрывающиеся регистры, документами по которым пользуются исходя из собственной логики и хотят продолжать пользоваться "как привыкли".

Логика сия подразумевает не использование регистров Заявки и ЗаказыЗаявки (но использование Резервы) + Заказы, как выяснилось, тоже не пользуют. Статус проведенности документа служит просто флагом для удобства в работе.
Сделал константу и реквизит в необходимых документах. При вводе документа реквизит берется из константы. Если реквизит =0 - движения по данным регистрам не делаются. + пришлось поправить заполнение при вводе на основании (регулируется той же опцией).
Стало значительно быстрее.

Теперь, собственно, сам вопрос: для очистки сделанных движений по соответствующим регистрам достаточно будет прихлопнуть таблицы регистров, или сие будет чревато и нужно подменять обработки проводки документов и перепроводить все накопившееся добро?
---
Само руководство не считает это "наши обязательства". Это просто информация для продажника о том чего хочет покупатель*. ... С резервами бардака нет
Если с резервами бардака нет, значит он только в неподтверждёнными заявками и заявками на поставку. Заявки на поставку просто тупо запретить. Тогда и регистры Заказы, ЗаявкиЗаказы использовать не должны. В заявке будет только один вариант резервирования - из текущего остатка. С неподтрерждёнными заяками тоже просто. Обычно неподтверждённая заявка одначает "счет", а на счетах обычно присутствует фраза "действителен в течении ___ дней". Запускать ежедневно регламентную обработку, которая просто создаст и проведёт документ Отмена заявок с нужными заявками.
заказали - сколько заказали, дали - сколько смогли
В реализации настройку закрытия заявки. С вариантами "Не закрывать / Закрывать по реализуемой номенклатуре / Закрывать полностью". По умолчанию второй вариант. И может быть руководство дозреет до рассмотрения вопроса "покупатель хотел плюшки, а мы ему не продали, потому что не было". Это же упущенная прибыль. И, временами, упущенный покупатель, который уйдёт к конкуренту с более широким ассортиментом.
И желают они (пользователи) именно того, что привыкли считать правдой.
Про то, что пользователи считаю правдой лучше помолчать. Буквально в пятницу тыкал носом главбуха филиала в Консультант+, потому что то, что она считала правдой, устарело законодательно лет на пять. В торговле и управленческом учете, конечно, не так однозначно...
реализация спишет и Заявки (которые есть на остатке в регистре) и РезервыТМЦ.
На сколько помнится, реализация списывает начала резервы по остаткам резервов, попутно списывая в том же количестве заявки, считая что резерва без заявки не бывает. А потом уже, если резервов не хватило, списывает заявки по остаткам заявок.
---
vcv, по-моему, все-таки, не попутно списывает, а попутно пытается списать по той же заявке и потом по прочим остаткам Заявки. Если нечего списывать - минусов не будет. Просто никакого движения по заявкам реализация не сделает...

Да. Я это и имел ввиду: бардак с неподтвержденными заявками и заказами (которые (документ) тоже информация). Заявки на поставку вообще не используются.

Закрывать ежедневно - не вариант. Любителей поковыряться сзади масса. И запретить им пока никак (рассмотрение претензий поставщиками по некоторым договорам превышает месяц, да я покупатели очень не быстро на недовозы реагируют). Т.е. пока только раз в месяц. Позже, быть может, переосмыслят, но это уже организационный момент.

Провалы сейчас проверяют анализом движений по остаткам и точечно. М.б. когда захотят видеть упущенную прибыль в цифрах и надумают поставить какие-либо планы закупщикам, да товарные запасы пересматривать начнут и придут к использованию заявок. Ну да это уже не наше дело: нехотят - сильно настаивать не будем.

Согласен. Ваша схема требует меньших правок конфы и, вероятно, более безопасна.
Но и отсутствие "мусорного" движения регистров в учетном периоде имеет свои плюсы. И я, пока, ничего критичного (заявку на склад только с РезервыТМЦ и РеализациюТМЦ с возможностью двигать Заявки попробовал) в неиспользовании этих 3-х регистров не нашел (тут, думается, тест на боевой базе покажет все то что могло всплыть).
---
vcv, да. Первый день на боевой базе показал, что некоторые товарищи, таки, пользуется переносом только несписанного реализацией по заявке при вводе на основании, а не просто копией ТЧ. Потому "вертаем все взад"...
Будем пользоваться отменой заявок.

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

Вопрос по удалению таблиц регистра в силе: насколько критичным может быть удаление таблиц Заявки (с пресозданием таблиц при ТиИ и перепроведением необходимых)?
Так избавиться от накопившегося мусора куда проще...
---
у мну есть готовая обработка "снятие просроченных резервов". запускается раз в день автоматом при старте системы любым пользователем.
можно тривиально докуртить до закрятия просроченных неподтвержденных заявок - их надо обязательно закрывать, иначе слоучатся капцы.
---
Вопрос по удалению таблиц регистра в силе: насколько критичным может быть удаление таблиц Заявки (с пресозданием таблиц при ТиИ и перепроведением необходимых)?
.
вообщем ничего страшного нет.
главное чтобы
1. рассинхронизации не произошло тип Регистр.Заявки снес а Регистр.ЗаказыЗаявки - нет, Резервы - нет, в ЗаказахЗаявках - заявка висит, В Резервах висит, а в заявках - нет... Наскольо адекватно будет себя вести списание по этим регитсрам - навскидку не скажу (по идее даже так должно сработать все нормально - но бошку сломаешь когда начнешь разбираться почему так а не инчае разлеглось).
2. "перепроведением" необходимых - может быть затык, что перепроведешь не все "необходимое" и где-то хвосты повиснут
---
CheBurator, понятно.
Спасибо.
---
Еще вопрос (м.б. я, правда, плохо смотрел): никакого типового закрытия заказов нет, кроме корректировочного?
---
Да зпт делаешь корректировочный заказ с пустой тч
Делал у себя отмену заказов аналогично отмене заявок
---
CheBurator, понял. Спасибо.
---
Т.е. проблема здесь:

```1c
    Фирмы=СоздатьОбъект("Справочник.Фирмы");
    Если Фирмы.НайтиПоКоду("3")=1 Тогда
    ТолькоОднаФирма=Фирмы.ТекущийЭлемент();
    КонецЕсли;

    ВремЗаявки.УстановитьЗначениеФильтра("Фирма",ТолькоОднаФирма, 1);
    //ВремЗаявки.УстановитьЗначениеФильтра("Фирма",ФирмаДляОстатковТМЦ, 2);
```

Документ.Реализация.Модуль Документа 308 ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1); 614 0.035511 1.91
---
На сколько я вижу, при проведении на ТА строка
Документ.Реализация.Модуль Документа 314 ВремЗаявки.ВыгрузитьИтоги(ВремТИЗаявки,1,1);
выполняется 1228 раза (видимо столько строк в документе) за время 0.058813 секунды и это занимает 2.97% от всего времени замера.
И чего тут оптимизировать? Эта строка просто зачудительно быстро работает.

А вот
Документ.Реализация.Модуль Документа 569 ВремРегистры.РассчитатьРегистрыНа(ТекущийДокумент());
выполняется всего один раз и на это тратится 2.398985 секунд (55.34% от общего времени замера)
Тут затраты времени серьёзные, но так просто от них не избавишься.
---
vcv, как доберусь вообще решил класс регистров с методами на прямых запилить и т.о. избавиться от РассчитатьРегистрыНа...
Но это как доберусь.

А вопрос был по (74) на ТА:

Документ.Реализация.Модуль Документа 302 ВремЗаявки.ВыгрузитьИтоги(ТИЗаявки,1,1); 614 83.726007 97.78

Что (76) и решило...

Просто странно что и до ТА стало работать быстрее: "0.034018 0.79" против "1.548476 24.08 ".
И перебор выгрузки итогов в цикле по каждой фирме быстрее чем однократная выгрузка по одной: "0.113589 2.03" против "0.059818 2.39" (перемерил).

Вот я и перепугался...
---
Jill,
vcv, как доберусь вообще решил класс регистров с методами на прямых запилить и т.о. избавиться от РассчитатьРегистрыНа...
Не с той стороны берёшься. Сначала бы подумал о базе данных и её индексах, потом уже о прямых запросах. Не оптимальный прямой запрос будет работать медленнее оптимального черного.
Почему выгрузка итогов с (76) отрабатывает более чем в 1000 раз быстрее чем
ВремЗаявки.УстановитьЗначениеФильтра("Фирма",ФирмаДляОстатковТМЦ, 2);
Ну смотри. Предположим, измерения регистра такие (порядок важен):
Фирма, Номенклатура, ДоговорПокупателя, ...
1С по ним стоит комплексный индекс Фирма+Номенклатура+ДоговорПокупателя
Теперь спрашивается, если у тебя фирма указана списком значений, будет ли 1С использовать индекс? Ведь для быстрого поиска по индексу, а не тупого скана всей таблицы данных, необходимо точно знать все компоненты индекса, посчитать индексное выражение и только тогда быстро выбирать данные по индексу.
А у тебя, скорее всего, при выборе данных по списку фирм, индекс не может использоваться даже частично, что бы хотя бы данные по фирме отобрать. Получаешь скан всей таблицы и своё замедление в 1000 раз.
Если просто тупо переделаешь на прямой запрос, ну будет он, предположим, работать в 10 раз быстрее. Получишь замедление не в 1000 раз, а всего лишь в 100.
Если тебе так уж надо выборку итогов по нескольким фирмам, попробуй, на копии базы, поиграть с порядком измерений. Например, поставить первым ДоговорПокупателя. Можно еще пробовать использовать галочки на измерении "Отбор итогов" и "Отбор движений". Это создаёт дополнительные индексы, которые могут ускорить выборку. Только не переусердствуй, индексы, ускоряют выборку данных (если условия выборки попадают в индекс), но замедляют запись данных в таблицу.
---
vcv, понятно. Спасибо.
---
vcv, добавлю. Единственное - проблема: безболезненно поиграться с порядком измерений регистров достаточно проблемно. Это надо во всей конфе в вызове методов (некоторых) регистра, так же, менять порядок измерений.
А как это сделать быстро, не поиском в конфе по вхождению (тут надо еще о внешних обработках помнить) наименований, критичных к этому делу процедур/функций, я, к сожалению, пока не знаю.

ЗЫ: это я, скорее, для тех кто в порыве погони за производительностью, наткнувшись на ветку начнет все регистры "улучшать". :)
---
Jill, Это да. По современным меркам за синтаксис УстановитьФильтр, СводныйИтог, СводныеИтоги, Остаток, СводныйОстаток, Остатки, СводныеОстатки нужно канделябром по пальцам. А для 90х годов прошлого тысячелетия нормально смотрелось.
В ТиС таких вызовов хватает. К сожалению.
---
Топик стартер - а у вас на 2 фирмах ( 1 склад ) полностью белый учет ? ( то бишь по официальным накладным )
Есть ли приход ( расход ) без накладных ( или как можно сказать черный учет ) ?
---
KontoraB, все с документами...
Но данные вопросы к теме не имеют отношения.