собственно, сабж

А какой смысл менять?

(1) Не менять. а открывать.
а с месяца перевел на 5 дней - ибо надо

в недрах храни.
программно сравнивай сохраненное в недрах с тек.датой.

(я бы на твоем месте пачками периоды открывал, кстати - если, конечно, не испортит "надобность"))

Констану, по типу номера листа кассовой книги... При открытии очередного периода, прописывать в нее дату. Криво конечно, но, какая задача...

фу, какие бяковые варианты, такую хрень я и сам знаю...

ДатаТА = ПолучитьДатуТА();
Если (РабочаяДата()>ДатаТА) И ((ДатаМесяц(ДатаТА)<>ДатаМесяц(РабочаяДата())) ИЛИ (ДатаГод(ДатаТА)<>ДатаГод(РабочаяДата()))) Тогда
                Если МонопольныйРежим()=0 Тогда
                    Предупреждение("Не открыт период!
                    |Для открытия периода запустите программу в монопольном режиме!
                    |Работа программы будет завершена!");
                    СтатусВозврата(0);
                    Возврат;
                Иначе// монопольный режим
                    Сообщить("Открытие нового периода.");
                    УстановитьТАНа(КонМесяца(РабочаяДата()));
                    Сообщить("Новый период открыт.");
                КонецЕсли;
            КонецЕсли;

Даты нужно будет откорректировать.

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

А компоненты "расчет" в составе конфы нет случаем - ? А то можно было-бы спец. календарь под это дело замутить...

(9) так я тоже умею, неинтересно.

(8) А в чем проблема переделать условие на:
Если (РабочаяДата()>ДатаТА+5) Тогда
//Открываем итоги;
КонецЕсли;

датаТА - это не дата начала или окончания периода итогов

датаТА = сегодня. Рабочаядата=Сегодня.
Вопрос - сегодняшняя дата - последняя ? надо открывать период?

КонецТекущегоПериодаТА=?(ДатаЧисло(ПолучитьДатуТА())>25,КонМесяца(ПолучитьДатуТА()),Дата(ДатаГод(ПолучитьДатуТА()),ДатаМесяц(ПолучитьДатуТА()),Цел((ДатаЧисло(ПолучитьДатуТА())-1)/5)*5+5)));
    Если РабочаяДата()>КонецТекущегоПериодаТА Тогда
        Если МонопольныйРежим()=1 Тогда
            УстановитьТАНа(Макс(РабочаяДата(),КонецТекущегоПериодаТА+1));
        Иначе
            //спросить и перевойти монопольно
        КонецЕсли;
    КонецЕсли;

в твоём случае
Если РабочаяДата()>=КонецТекущегоПериодаТА Тогда

(2) ВОт итересно зачем это надо и где?

(12) Освоить прямые запросы и дату итогов почерпнуть напрямую из любого регистра.

(16) Это нужно понимать как семерка хранит итоги. И рассчитывает на произвольную дату.
Когда период "месяц" - итоги хранятся на началомесяца и ТА. Все, что в промежутке, рассчитывается от "остаток на началомесяца" плюс приход за период с началамесяца минус расход за период с началамесяца. И когда вам нужно иметь промежуточные итоги скажем на 23-е число семерка будет просчитывать период 23 дня.
Если у вас период 5 дней тогда и максимальный период для расчета 5 дней.
Короче все от работы "задним числом".

(18) Что опять возвращает нас к вопросы. Это какой же бизнес-процесс в компании принуждает постоянно работать задним числом или постоянно получать остатки на дробный период (не кратный месяцу).

(19) Работа задним числом - это отдельный вопрос.
Эт-т-то я вам скажу тот еще вопрос.
У меня есть клиент на территории которого я уже года два веду войну за исключение работы задним числом. Пока я в пролете.

(20) Ну просто зная ТС как человека все таки способный навести в этом вопросе порядок, мне стало любопытно

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

хоспаде, делов то! берешь прямой запрос к таблице итогов - смотришь последнюю запись которая не ТА и сравниваешь с текущей датой. Это самый верный способ - всегда так делаю

(17) это неинтересно, хочется штатно

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

(14) Криво.
(+лишняя закрывающая скобка в конце?)
.
тест: сейчас 31.07.18 - последний день периода итогов. Завтра (01.08.17 - первый день очередной пятидневки)
.
ТекДата = РабочаяДата();
Пока ТекДата < '01.10.2018' Цикл
    КонецПериодаТА = ?(ДатаЧисло(ТекДата)>25,КонМесяца(ТекДата),Дата(ДатаГод(ТекДата),ДатаМесяц(ТекДата),Цел((ДатаЧисло(ТекДата)-1)/5)*5+5));
    Сообщить(""+ТекДата+ " - "+КонецПериодаТА);
    ТекДата = ТекДата + 1;
КонецЦикла;    
.
    ТекДата = РабочаяДата();
    Пока ТекДата < '01.10.2018' Цикл
        КонецПериодаТА = ?(ДатаЧисло(ТекДата)>25,КонМесяца(ТекДата),Дата(ДатаГод(ТекДата),ДатаМесяц(ТекДата),Цел((ДатаЧисло(ТекДата)-1)/5)*5+5));
        Сообщить(""+ТекДата+ " - "+КонецПериодаТА);
        ТекДата = ТекДата + 1;
    КонецЦикла;    

31.07.18 - 31.07.18 5
01.08.18 - 05.08.18 1
02.08.18 - 05.08.18 2
03.08.18 - 05.08.18 3
04.08.18 - 05.08.18 4
05.08.18 - 05.08.18 5
06.08.18 - 10.08.18
07.08.18 - 10.08.18
08.08.18 - 10.08.18
09.08.18 - 10.08.18
10.08.18 - 10.08.18
11.08.18 - 15.08.18
12.08.18 - 15.08.18
13.08.18 - 15.08.18
14.08.18 - 15.08.18
15.08.18 - 15.08.18
16.08.18 - 20.08.18
17.08.18 - 20.08.18
18.08.18 - 20.08.18
19.08.18 - 20.08.18
20.08.18 - 20.08.18
21.08.18 - 25.08.18
22.08.18 - 25.08.18
23.08.18 - 25.08.18
24.08.18 - 25.08.18
25.08.18 - 25.08.18
26.08.18 - 31.08.18 1
27.08.18 - 31.08.18 2
28.08.18 - 31.08.18 3
29.08.18 - 31.08.18 4
30.08.18 - 31.08.18 5
31.08.18 - 31.08.18 КРИВО. Период должен заканчиваться 30.08.18
01.09.18 - 05.09.18
02.09.18 - 05.09.18
03.09.18 - 05.09.18
04.09.18 - 05.09.18
05.09.18 - 05.09.18
06.09.18 - 10.09.18
07.09.18 - 10.09.18
08.09.18 - 10.09.18
09.09.18 - 10.09.18
10.09.18 - 10.09.18
11.09.18 - 15.09.18
12.09.18 - 15.09.18
13.09.18 - 15.09.18
14.09.18 - 15.09.18
15.09.18 - 15.09.18
16.09.18 - 20.09.18
17.09.18 - 20.09.18
18.09.18 - 20.09.18
19.09.18 - 20.09.18
20.09.18 - 20.09.18
21.09.18 - 25.09.18
22.09.18 - 25.09.18
23.09.18 - 25.09.18
24.09.18 - 25.09.18
25.09.18 - 25.09.18
26.09.18 - 30.09.18
27.09.18 - 30.09.18
28.09.18 - 30.09.18
29.09.18 - 30.09.18
30.09.18 - 30.09.18

здесь явно кривовато
?(ДатаЧисло(ТекДата)>25,КонМесяца(ТекДата)
в т.ч. и в феврале 28/29...?

Оборотный регистр по 5 дней.
Что-то тебя несет не в ту степь

(26) Нет, всё правильно. Если периодичность 5 дней, то период будет 26.08.18 - 31.08.18, то есть 6 дней. Такая вот арифметика в 1С. Также как и в феврале - последний период будет 3 или 4 дня.

Да не оскудеют клюшки фантазиями программистов!

И ещё. Конечно хозяин-барин, но мне тут досталась в наследство складская самописка. SQL, с 2003г., 200 тыс. номенклатуры, регистр на 7 измерений, 2 последних измерения не закрываются (надо было делать "реквизитами"), период итогов - 5 дней, выгрузка базы - 30 (тридцать) мегабайт. Ставил загрузку на отдельный мощный комп, интересно было - через 2 недели выключил. Не судьба.
Это я к чему - всё-таки оптимально "месяц". "5 дней" чревато разбуханием. Итогов в 6 раз больше, а если есть проблемы с закрытием регистров, то кирдык. DBF вообще не стОит, имхо. Таблица итогов на 200 метров легко превратится в 1.5 гига.

(24) Штатно? Можно и штатно...
Пустой документ ТестПериода с флагом ОперативныйУчет


Функция ПериодОткрыт(ДатаПроверки)
    НачатьТранзакцию();
        Док=СоздатьОбъект("Документ.ТестПериода");
        Док.Новый();
        Док.ДатаДок = ДатаПроверки;
        Док.Записать();
        Проведен = Док.Провести();
    ОтменитьТранзакцию();
    Возврат Проведен;    
КонецФункции


(27) Сделай пустую базу, период "5 дней" и начинай открывать периоды - увидишь как 1С будет шагать.

(33) хочешь сказать, что в приведенном мной "тесте" будут и периоды и по 6 и по 4 дня в зпвисимости от попадания на границу месяца?

(29) а, увидел! спсб!

(31) согласен, тут надо смотреть частности.
но все-таки большой файл итогов - это статичная трудность, используемая редко. получение итогов - повседневная операционная деятельность. так что тут выбираем в зависимости от конкретной ситуации.
За советы спасибо.
база небольшая, файл движений растет на 2 Мб в день (4-5 ТСД работают), так что нормально. такими темпами хватит НАДОЛГО.

(31) " 2 последних измерения не закрываются (надо было делать "реквизитами"),"
- если не секрет - то за что отвечали измерения?

(32) блин! но с учетом (29) вариант Харлампия - норм!

А база то скульная?

(39) ни, файловая

(37) Не секрет:
Регистр "Назначения" (учет выданного в аренду)
1) Номенклатура;
2) Склад;
3) Размер;
4) Уникальность - уникальная ссылка на конкретную одежду;
5) Признак - новая/подержанная;
6) Вид движения - поступило/передано/списано etc.

Отдаем одежду в аренду - новая/передано, возвращают - подержанная/возвращено.

А ещё 4 ресурса:
1) Количество;
2) Сумма;
3) Цена - должна быть реквизитом;
4) Сбор - должен быть реквизитом.

При этом, Размер - это Уникальность.Размер, Номенклатура - это Уникальность.Владелец, а по последним двум измерениям даже по названию понятно, что они должны были быть реквизитами регистра. То есть, в теории вместо 6 измерений и 4 ресурсов можно было иметь 2 измерения, 2 ресурса и 4 реквизита.

По всем измерениям стоит "отбор движений" и "отбор итогов" - при том, что в SQL они не используются. И 5 дней итогов, при том что они в 5 и 6 измерении не закрываются.

Регистр "Остатки" почти такой же.

Представь как у меня руки чесались.
На практике же - 100! ГИГА!байт в SQL и 30 МЕГА!байт выгрузка, которую никаких шансов загрузить штатно.
С учётом:
работы клиента 24/7;
удалённости;
дряхлого сервера;
принципа "работает - не трожь";
самописной нетленки от 2 предыдущих прогов с очень оригинальным складом ума;
нежелания клиента хоть сколько-то резать базу -
пока наблюдаю)
Но верю, что когда-нибудь, когда все свои долги закрою, - я ей таки займусь.

"Но верю, что когда-нибудь, когда все свои долги закрою, - я ей таки займусь."
это правильно1 у меня в групваре тоже висятзадчаи 3-4 летней давности и больше... тоже займусь...

Да ты трудоголик! Моей уж восемь...

(43) так, подожди, пойду проверю...

самый старый тикет - 2393 дня....

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

(41) Все просто:
1) делаешь копию базы средствами SQL, удаляешь напрямую данные проблемных регистров, добавляешь нужные реквизиты (и их заполнеие). сохраняешься.
2)смотришь имена реквизитов, добавляешь в рабочей базе, 3)подменяешь md и dd (можно даже не выгонять юзверей)
4)копируешь данные из глупых измерений в новые реквизиты (это же касается и ресурсов)
5) в копии удаляешь глупые измерения и ресурсы
6) делаешь п.3
7) делаешь п.2
8) пересчитываешь итоги по периодам по этому регистру. во время пересчета последнего периода просишь пользователей временно (обычно это минута-две) не проводить документы, влияющие на этот регистр.
profit!

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

(48) "лучше день потерять, а потом за час долететь"©
ладно, есличо - стучись в скайп. я сюда вообще случайно зашел...

ох уж эта 7.7, со слезами вспоминаю:
1. Просыпаться 1 числа каждого месяца в 12 ночи, чтоб период открыть ночным кладовщикам
2. Каждый год делать обрезание базы нештатными средствами
3. Документы, которые порой проводились датой больше ТА, в итоге выгон всех пользователей и откатывание ТА на конец прошлого месяца и назад  (чтоб текущие итоги поправились).
ну и прочие интересности

(48) А зря, надо освоить...
Кстати, на 1sqlite недавно стало такое работать


DELETE
FROM РегистрИтоги_Покупатели AS Итоги
WHERE Итоги.СуммаРуб=0


и никаких хвостов в итогах, причем в отличии от фокса индексы не ломаются.

(50)
1)SQL+хранимка - и необходимости открывать период больше не нужна.
2)один раз настраиваешь, и подрезка производится автоматически каждый месяц в часы наименьшей нагрузки.
3)пересчет ТА без выгона пользователей реализован был DmitrO уще ,емнип, в 2006-м...

(51) а индексы?

(51) надо! но мну учитель-тренер нужен, а за бесплатно кто будет...

(54) я тебе ишшо в 2015 предлагал, по осени.

(52) а какже лицензионное соглашение и всё такое? или в 7.7 можно напрямую в БД лазить руками?

1. робот, не вижу проблем
2. нафейхоа? не, конечно, если базы десяткигиговые то может и надо, я обрезаю примерно раз в три года файловую, тупо чищу регистры заказов - они самые объемные. тоже не напряжно. а уж если сделать полное обрезание нештатными средствами - оно вообще делается часа за два с перекурами на базе практически любого размера.
3. Это как так..? если можно провести документ датой больше ТА - то почему бы кому-то не провести? если запрет проведения документов будущей датой - то фиг там.

незачет короче

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

(56) в 7.7 его, говорят, не было.

(58) ну я с понедельника в отпуске, вечерком можно будет, благо на озере инет есть... стучись

(57) 1. для открытия роботом все равно надо выгонять пользователей (а там то блокировка, то вопрос о сохранении, то еще какая фигня).
2. базы могут быть и больше сотни гигов за 3 года. поддерживать 37 месяцев в базе - это своего рода элемент информационой безопасности.
3. ага

(60) это попозже уже, числа после 8-го...

(61) "1. для открытия роботом все равно надо выгонять пользователей (а там то блокировка, то вопрос о сохранении, то еще какая фигня)."

ССЗБ, бачилы очи шо купували

(53) С индексами все в порядке. 1sqlite работает изнутри 1С, фактически удаление идет методом Удалить(1).
Можно было бы и update с insert сделать, но это долго и муторно.

(64) "Можно было бы и update с insert сделать, но это долго и муторно."
- а это было бы быстрее штатных методов типа записать/провести? а то блин меня клинит общий журнал, а свой двтижок на разовый проект писать не хотелось изобретать всякое...

(65) я б не рекомендовал проводить прямыми. да и записывать.
в принципе, это все реально, но не быстрее. по крайней мере, на SQL

(65) Не думаю что сильно быстрее, для записи требуется создавать объекты 1С.
Т.е. в sql update будет быстрее, а в dbf нет.
Во всяком случае на нынешнем движке 1sqlite.
это скорее интересно тем что можно было бы движения документа на любую дату писать.

(67) не лучшая задумка - из-за структуры клюшек. т.е. если быстрая обработка включена - тогда еще можно (но придется самому итоги пересчитывать). но ну его нафик.

(68) Не уверен, возможно движок сам бы сделал пересчет.
Метод записи все таки был бы не прямой, а объектный.

(69) я делал в SQL - писал, потом вызывал хранимку. без блокировки журнала. теоретически можно, но мне не понравилось. больше к этому не возвращался - все и так работало достаточно неплохо. а потом ушел оттуда (но система практически без поддержки проработала еще 3 года)

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

" при чтении и записи " - при чтении и записи и проведении документов/регистров, в т.ч. и запросами

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

(73)
1.если не 24/4, то никаких проблем.
2. много - это сколько? и тормоза - они зависят не от общего объема базы, а от количества записей от начала периода хранения остатков
3.несинхронизировано время на компах. синхронизация решает эту проблему.

(74)
1. Да, 24. Но в принципе выгон пользователей делал их работу уже не совсем 24 )
2. Да сейчас  уже и не помню, это же было 10 лет назад. Что-то порядка 3000 документов по расходу по рабочим дням, в них хз сколько строк по товарам. каждая строка расхода фактически еще была в соответствующей заявке от клиента и наверно какие-то складские документы по перемещению данного товара из зоны склада в зону погрузки. Это было 10 лет назад, железо наверно не то, что сейчас. Часть пользователей (типа бухгалтера, диспетчеры) были посажены в отдельные базы, чтобы не блокироввать работу склада и операторского отдела.
3. Маловероятно. Пользователи работали через citrix, локальные машины не очень справлялись с нагрузкой. а терминальный сервер вроде был один.

(75)
1.ну, у меня последний месяц работы на старом месте - воемя простоя для обновлений было порядка 15 минут. достаточно немного. остальное "динамически"
2. пик был 7800 документов в день (всех), а железо - 2007 года. но все местные в одной базе (плюс распределенка с иногородними)
3) странно. у меня пользователи работали локально, такие проблемы наблюдались либо при уходе локального времени, либо при проблемах с сетью. Т.е. крайне редко, буквально единицы случаев в год. единственное - у меня был SQL

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

(77) там много запросов.
Так что если есть возможность - то лучше в привате.