gifts2017

Периодические реквизиты для 8-ки "по быстрому"

Опубликовал Гарик Багосьян (garik80) в раздел Программирование - Практика программирования

Данная разработка предназначена для сохранения истории любого реквизита справочника стандартной конфигурации с минимумом изменений. Имитирует работу с периодическими реквизитами как в 7.7. Можно получить значение реквизита справочника на любую дату. Для работы с реквизитами справочников в стандартных конфигурациях необходимо добавить слово "периодический" в комментарий реквизита, и внести небольшие изменения в в модуль формы элемента справочника.

Как это сделать

1. Добавляем в конфигурацию необходимые для работы объекты

2. Добавляем слово "периодический" в комментарий. 

3. Дополняем модуль формы элемента справочника (см. первый скриншот)

Все сведения храняться в регистре ПериодическиеРеквизитыСправочников. В случае обновления конфигурации история никуда не исчезает, а востановить функционал не займет много времени.

 

При открытии формы элемента справочника, проверяется наличие реквизитов с признаком "периодический". Если такие имеются то на форме появляется кнопка "История" и у периодических реквизитов появляется кнопка списка для показа истории значения.

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

Для получения значений реквизита в общем модуле РаботаСПериодическимиРеквизитами есть функции 

//Функция возврачает значение реквизита справочника на указанную дату
Функция ПолучитьЗначениеРеквизитаНаДату(Ссылка,Реквизит,Дата) Экспорт

//Функция возвращает последнее значение реквизита на указанную дату
//и дату этого последнего значения
Функция ПолучитьЗначениеРеквизитаИПоследнююДатуНаДату(Ссылка,Реквизит,Дата) Экспорт


Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Периодические реквизиты справочников база для ознакомления
.dt 44,04Kb
27.03.13
34
.dt 44,04Kb 34 Скачать
Периодические реквизиты справочников конфигурация
.cf 41,32Kb
27.03.13
22
.cf 41,32Kb 22 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Misha ⁠ (Magister) 28.03.13 03:20
Простите, не сдержался )))
WhiteOwl; GoVas; VasMart; Den_D; andrewks; Alex_E; KonstB; Serj1C; +8 Ответить 1
3. Александр Капустин (kapustinag) 28.03.13 12:53
Картинка убивающая, спору нет.
Думаю, в публикации неудачно выбран пример применения "периодических" реквизитов.
Для кадровых данных в типовых конфигурациях (например - ЗУП, УПП) и так есть место для хранения - периодический регистр сведений.
Но вот Вам пример вполне нормальный, где это можно было бы использовать:

В одном из последних обновлений УПП в документ "Счет-фактура выданный" добавили реквизит "КПП покупателя".
Таким образом попытались решить проблему, когда у контрагента сначала был один КПП, а потом стал другой КПП.
То есть, вместо того чтобы применить периодический регистр сведений, или применить описанный в данной публикации механизм "периодических" реквизитов справочников, засунули этот реквизит в КАЖДУЮ счет-фактуру выданную. А счетов-фактур этих на данного контрагента может быть несколько сотен в месяц.
Абсурд, не правда ли?

Но я все-таки согласен с (1). Можно было бы - с некоторой потерей функциональности - обойтись просто использованием периодического регистра сведений и внешних печатных форм. Незачем описания реквизитов и модули форм элементов справочников менять.
4. Александр Капустин (kapustinag) 28.03.13 12:58
Либо, как вариант, включить версионирование для данного справочника. Правда, придется из версий данные самостоятельно выкапывать. Но пример использования есть - в типовой УПП отчет "История изменений объектов".
5. Гарик Багосьян (garik80) 28.03.13 13:37
(1)
1. Работаете только на стандартных конфигурациях, фантазия дальше не работает?
2. Любите все делать как в 1С, - На ваяем новый регистр, ни к чему нам универсальные механизмы.
3. Если пример приведен на сотруднике это не значит что его следует именно так и использовать.
4. При написании своей конфигурации, решающей не только учетные задачи, вопрос необходимости отслеживать историю того или иного реквизита приходит порой только в процессе работы, а поступать как в пункте 2 не вижу смысла.
5. Даже если не видите целесообразности, то вполне пригодится для начинающих, так как затрагивает много аспектов работы с формами и данными.
6. Ваша "Универсальная настраиваемая печать документов" отнюдь не блещет оригинальностью и сложностью реализации.
7. Вы взялись судить о работе даже не удосужившись её скачать это ваш ник способствует такой мании величия, или это супер интеллект такой- Нихрена не смотрел, но уверен что херня ?
6. Гарик Багосьян (garik80) 28.03.13 14:52
(4) kapustinag,
Разработка позволяет в одном регистре сведений хранить значения любого количества справочников, минимум изменений в процедурах, причем стандартных изменений, и всего лишь добавить слово "периодический" в комментарий реквизита.
7. Misha ⁠ (Magister) 28.03.13 22:02
(5) Если я вас задел - извините, картинку запостил на эмоциях. Заметьте, что минуса я не ставил - т.к. примерно представляю объем работы, нужный для реализации такого механизма. Плюс тоже не ставил, т.к. лично для меня такой механизм не нужен. Впрочем, не исключаю, что нужен для других.
Теперь по пунктам.
1. Нет, сейчас вот, например, активно дорабатывается написанная мной "с нуля" конфигурация для торгового предприятия, с очень приличным товарооборотом. Типовая (была раньше) - просто загнулась на таких объемах
2. Люблю делать так, как оптимальнее с точки зрения производительности. Предполагаю, что ваша реализация использует для всех периодических реквизитов одну таблицу (регистр сведений, скорее всего) - соответственно при активной записи документов на этом регистре будут возникать блокировки (если механизм применить для документов). Также будет замедляться чтение при увеличении объема сохраненных данных. Если же сделать отдельные регистры - таких проблем не возникает.
3. Вот как раз на сотруднике он оправдан. Правда, в типовых механизм, решающий данную задачу для сотрудников, уже есть.
4. Уже ответили. Версионирование, создание новых регистров, ...
5. Не спорю. Как уже написал - потому и не ставил минуса.
6,7. А это уже начинается переход на личности. Впрочем, отвечу. Я и не претендовал на оригинальности и сложность реализации. Сделал полезную для людей вещь и выложил. Все. Есть у меня и другие разработки, поинтереснее - но в основном узко специализированные.
А про ник... убойный аргумент, ничего не скажешь. Впрочем, тут всё достаточно просто. У меня есть диплом магистра, полученный по окончании ВУЗа. Вот и всё, собственно.

Дальше прошу на личности не переходить, а общаться по существу.
8. Гарик Багосьян (garik80) 28.03.13 22:57
(7) Magister,
Я тоже за общение по существу, а не за посты которые делаются даже не глянув в разработку. Про ник, отмаз не прокатил, у меня два высших образования "полученных по окончании ВУЗов", я же не ставлю ник Гуру, вот и все, собственно.
9. Misha ⁠ (Magister) 28.03.13 23:23
(8) В данном случае смотреть на код не вижу смысла, из описания идея понятна - копирование функционала 1С 7.7. Подробности конкретной реализации могут быть интересны только если сама идея для меня покажется интересной.
А доказывать кому-то что-либо у меня нет ни времени, ни желания.
10. andrewks 29.03.13 09:05
(8) garik80,
я же не ставлю ник Гуру, вот и все, собственно

собственно, никто не запрещает. хоть МегаГуру

по сабжу - для маленьких баз, может, и сойдёт, но для больших - валить всё в одну кучу (один РС) - плохая идея, на мой взгляд
11. Гарик Багосьян (garik80) 29.03.13 09:39
(10) andrewks,
Согласен, валить всё в кучу не есть хорошо, и использовать предложенный вариант как основной даже не берусь рекомендовать, а как дополнительный для реквизитов где вдруг захотелось фиксировать историю, вполне годится.
12. Игорь Дайнеко (Dnki) 05.04.13 19:38
+1
Мне нравится сама идея: хранить реквизиты в одном регистре и использовать для работы единый механизм. Когда я смотрю некоторые конфигурации, меня тошнит от количества созданных регистров сведений: на каждый периодический реквизит по своему регистру.

Причины:
1) Свято уверен, что большое количество таблиц (даже если каждая размером в единицы записей) не способствует скорости работы и старта.
2) Главное: в начале рождения системы порой не предсказано реквизиту быть периодическим. Это требование может возникнуть через годы эксп-ции. И данное решение минимизирует усилия "модернизации".

Прозвучало выше опасение насчет "блокировки при интенсивной работе". Все что относится к вносимой руками информации - это мелочи. Т.е. если в регистр не будут писать доки при массовом проведении и обработках, а только записывать люди клавиатурой, то это редкие и быстрые записи - никаких конфликтов никогда не будет видно.
13. Галина Исхакова (Lina_Buh) 28.01.14 14:42
Переходим с 7-ки на 8-ку. Подскажите кто сможет как лучше, как правильней организовать хранение нескольких периодических реквизитов? Сотворили их аж 11 штук. Завела пока 1 регистр сведений, но изменяя один реквизит, приходится менять все. Но это пол беды. Хочется выводить значения периодических реквизитов в форме списка справочника. Написала произвольный запрос. Но это открывается жууутко долго. Подскажите кто сталкивался с подобной проблемой. как решили?
14. WWWolfy (WWWolfy) 21.04.16 00:52
Несколько косяков:

В РаботаСПериодическимиРеквизитами
Реквизит=СокрЛП(ТекущийРеквизит); -> Реквизит=СокрЛП(ТекущийРеквизит.Имя);

косяки при начале работы, когда пока ещё нет записанных в регистр значений - затирает текущее значение (при открытии)
15. Валерий (Dr.Mult) 24.05.16 16:18
Процедура в общем модуле ОбработкаФормыСправочника ,
ФормаСправочника.ЭлементыФормы[Строка(ТекущийРеквизит)].КнопкаСпискаВыбора=Истина;
Так обращаться к элементу формы нельзя... В переменной платформа вернет не имя реквизита , а его синоним... и получите ошибку..

Надо заменить на ФормаСправочника.ЭлементыФормы[Строка(ТекущийРеквизит.Имя)].КнопкаСпискаВыбора=Истина;
Ну соответственно и в др. строчках
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа