Оптимизация работы подсистемы "Версионирование объектов" в БСП

Публикация № 237921

Администрирование - Производительность и оптимизация (HighLoad)

подсистема Версионирование объектов БСП библиотека стандартных подсистем оптимизация версия размер базы данных

Многие знают, что подсистема версионирования объектов в БСП (библиотеке стандартных подсистем) довольно прожорливая, базы начинает "пухнуть" от размера, поэтому многие её не включают. Я же столкнулся ещё с одной проблемой-перепроведение документов стало занимать гораздо больше времени.  Попытался со всем этим что-то сделать и всё-таки использовать этот функционал в реальной работе, не переделывая всё кардинально.

 

    В данный момент уже очень многие конфигурация содержат БСП (библиотеку стандартных подсистем), в составе которой есть подсистема "Версионирование объектов". Эту подсистему можно использовать как в в режиме "Управляемого приложения", так и в принципе и в режиме "Обычного приложения" без появления автоматической команды для просмотра истории в форме объекта.

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

         Включается эта подсистема в интерфейсу управляемого приложения в пункте "Администрирование-настройка системы - Использовать версионирование объектов". Далее настраивается виды объектов, т.к. какие документы и справочники, по которым будет идти версионирование.

 Настройки версионирования в БСП

 Кстати говоря, о вариантах версионирования, то вариант "Версионировать  при проведении" означает, что сохраняется версия документа после первого проведения, а затем уже всё время, чтобы с документом не делали версия сохраняется при записи. Поэтому правильнее было бы его назвать "Начать версионировать после первого проведения документа".

     

     Но как уже упоминалось выше проблема в том, подсистема слишком напрягает базу, а именно возникают проблемы:

  1. Тратится время на сохранение версии объекта. Это влияет на то, что например перепроведение документов заметно замедляется .
  2. Заметно увеличивается размер базы данных, что требует беспокоится о свободном месте, где находится база данных. Да и раздражает немного, что выгрузка базы (dt) занимает гораздо больше времени.

      Проанализируем эти проблемы и попробуем найти пути оптимизации.

 

      1. Тратится время на сохранение версии объекта

  •               Механизм сохранения построен на подписке события для СправочникОбъект и ДокументОбъект событи ПриЗаписи. Последовательность такова:
  • определяется нужно ли этот объект версионировать , определяется это из настроек в регистре сведений НастройкиВерсионированияОбъектов
  • версия объект сериализуется в XML, помещается в ХранилищеЗначений и записывается в регистр сведений ВерсииОбъектов, при этом каждой версии присвается следующий порядковый номер в записи в реквизте НомерВерсии

          Основное время уходит как на сериализацию объект (преобразования в XML) и собственно на запись этого серилизованной версии в регистр.

      2. Заметно увеличивается размер базы данных

                Размер увеличивается за счет количество сохраненных версий в регистре. Ведь каждая версия это по сути копия объекта и получается копий будет столько, сколько раз записывали документ (т.е. редактировали, проводили и отменяли проведения, помечали на удаление и т.п.). Так на один документ может приходиться и 10 версий и тогда у вас реально документов в базе "как бы" в 10 раз больше.

          

         Решение этих проблем это смена подхода как к сохранению изменений, так и и количества сохраненных изменений. Есть много уже готовых решений, которые отлично работают(их много и на Infostart). Подходы у эти разработок сводится  к тому, чтобы проанализировать , что именно изменилось и сохранить только изменения. А затем , когда есть текущая  версия, то через динамику изменений можно восстановиться до любой версии. Некоторые решения ещё предлагают сохранять все эти изменения в другой специальной базе или время от время переносить накопленные изменения в другю специальную базу.    Эти решения отлично работают, но ими нужно специально заниматься. Приобретать, устанавливать, настраивать. Но если требуется действительно серьезный и даже критический подход к хранению изменениям, то на это стоит потратить и время и деньги.

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

          Итак делаем

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

          2.) Проверив, что объект версионируется, начинаем анализировать , а изменился ли объект? Как ?  Тут я решли поступить просто раз объект сериализуется в XML,а XML это строка, а строки можно сравнивать. Берем XML текущего объекта и XML версии в базе данных и сравниваем, если ещё точнее сравнивать будет строки XML помещенные в ХранилищеДанных сжатые. Выглядет примерно это так:

 Сравнение версий

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

           4.) Есть ещё один момент. Не будем сохранять текущую версия объекта сразу при записи, а только если появляется новая действительно измененная версия. А зачем сохранять текущую версию сразу, если она и так в базе сидит в виде документа. Это позволит, если документ один раз ввели и потом практически не меняли, то количество версий сохраненных будет минимально.

           5.) Таким образом в регистре сведений ВерсииОбъектов будут  записи , в которых действительно хранятся версии объекта (базовые версии), а остальные  записи ссылаются только на базовые версии, т.к. при записи объектов они не менялись.

           6.) Так как на сравнение версий  все равно уходит время, нужно предусмотреть, чтобы в ситациях когда это не нужно делать, можно было обойтись без этой проверки. Например, делаем перепроведение документов , сами документы при этом не меняются, зачем что-то сравнивать. Поэтому добавим в ДополнительныеСвойства объекта флаг ПроверятьНаИзменениеСПредыдущимиВерсиями. Но чтобы этого флаг добавить придётся делать собственную обработку по групповому перепроведению документов, я их обычно делаю или беру где-нибудь для работы в программах, пользователи пользуются только этим перепроведением.

            7.) Чтобы теперь сравнивать версии нужно учитывать, что в каждой записи сохраненной версии может и не быть, а также то, что текущие базовые версии не содержат в себе данные о версии ,т.к. эта версия сейчас и есть объект в базе . Поэтому нужно эти нюансы учесть в отчете о сравнении версий ОтчетПоИзменениямВерсийОбъектов

        8.)  Для анализа сколько и чего уже хранится в регистре сведений ВерсииОбъектов сделан новый отчет СтастикаПоХраненимымВерсиямОбъектов, в котором можно посмотреть данные о количестве объектов, версиях , базовых версиях, размерах храненимых версиях в мегабайтах (да это тоже сохраняется при записи версии в регистр)

     В итоге изменений не так уж и много нужно внести 2-3 процедуры в общий модуль Версионирования, в модуль объекта отчета о сравнении, в регистр сведений добавить новые реквизиты. Результат будет существенное экономия места в базе и скорость перепроведения (своей обработкой) возрастет.

   Все что получилось выкладываю в своей базе небольшой демо базе с одним документом и справочником, там же есть простая своя обработка перепроведения документов. Всё это можно использовать как доработку БСП  , так и как отдельное решение сравнив и объединив. При встраивании в свои конфигурации нужно понмнить о том, что список объектов нужно задать в общей команде ИсторияИзменений в типе параметров команды, а также тип измерения Объект в регистре сведений ВерсииОбъектов, основная измененная процедура - это ВерсионированиеОбъект. ЗаписатьВерсиюОбъекта. В качестве основы бралась старая версия БСП 1.1.2.3, но текущая версия по этой подсистеме принципиально не отличается.

 

 
   

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

Наименование Файл Версия Размер
Демо база "Оптимизация версионирования объектов БСП"
.dt 133,23Kb
03.12.13
24
.dt 1.0 133,23Kb 24 Скачать

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Armando 1392 24.11.13 02:54 Сейчас в теме
Мне кажется, что это какое-то вредительство.
Что происходит в БСП:
1. Проверка настроек версионирования
2. Считывание номера последней версии из базы
3. Сериализация объекта
4. Запись в регистр

Что я увидел у Вас:
Представим, что пользователь просто нажал ОК ничего не изменяя.
Первые 2 пункта не отличаются
1. Проверка настроек версионирования
2. Считывание номера последней версии из базы
дальше самое интересное
3. Получение пометки на удаление по ссылке через точку: Источник.Ссылка.ПометкаУдаления
4. Сериализация объекта
5. Считывание из регистра предыдущей версии элемента справочника
6. Какая-то проверка и еще раз считывание уже какой-то другой (исходной) версии этого элемента
7. Сериализация объекта полученного по ссылке. Т.е. полное чтение объекта из базы. Ссылка.ПолучитьОбъект()
8. Запись в регистр без сериализованной версии объекта.

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

И ради чего это? Ради экономии пары гигов дискового пространства? Вам жалко что ли?
Может проще в часы простоя регламентным заданием чистить этот регистр от старых записей?
alexeyvs77; mnemchinov; roman8115; ojiojiowka; +4 Ответить
2. maxx 840 24.11.13 10:24 Сейчас в теме
(1)
3. Получение пометки на удаление по ссылке через точку: Источник.Ссылка.ПометкаУдаления

Согласен, что функционал по определению, пометили ли на удаление объект, нужно сделать опциональным. Мне он был нужен, подумаю.

Вместо 1 раза сериализация выполняется 2 раза. Плюс к этому еще 4 раза зачем-то обращаемся к базе. И все равно выполняем запись в регистр. Тут уже не сильно важно есть там сериализованый объект или нет (если только он не очень большой)

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

И ради чего это? Ради экономии пары гигов дискового пространства? Вам жалко что ли?
Может проще в часы простоя регламентным заданием чистить этот регистр от старых записей?

Действительно жалко место, только на 2 гига, а гигов 20 и администраторы серверов начинают беспокоится о месте на сервере (500 Гб), особенно если надо развернуть копию и что-то проверить.
А обработка, которая удаляет лишние версии, у меня есть. Эта обработка переводит хранение из структуры хранения версий в БСП в мою структуру, удаляя лишние (одинаковые) версии.

Ну и главное, перепроведение. У меня на база перепроведение ДО занимало часов 8, ПОСЛЕ 1 час, т.к в этом случае не происходит ни сравнения версий , ни записи этих версий, а только информация о том, что документ проводился.


33. maxx 840 28.11.13 09:43 Сейчас в теме
мы об этом узнали только в (2), причем в конце немаленького комментария, зато с припиской "и главное - перепроведение". А из (0) мы то подумали, что вопрос о том, что "тратится лишнее время при записи" и "пухнет база".

Согласен, что наверное нужно было начать описание с того, из-за чего всё начиналось, а не сразу описывать БСП.
3. Armando 1392 24.11.13 12:09 Сейчас в теме
Согласен, что функционал по определению, пометили ли на удаление объект, нужно сделать опциональным. Мне он был нужен, подумаю.

Если очень надо, то лучше пометку получать запросом, а не через точку по ссылке. Тем более, если у Вас документы с большим количеством записей в ТЧ. Сейчас чтоб получить пометку, тянется вообще весь объект.
Разница есть при записи документом с большой ТЧ, быстрее сравнить версии, чем записать эту большую версию в регистр. Запись практически пустой записи отличается по времени от записи с ХранилищеЗначения большого размера (несколько килобайт)

Для больших объектов актуально. Согласен. Но для маленьких это того не стоит. Проще его записать, чем выполнить кучу накладных манипуляций.
Действительно жалко место, только на 2 гига, а гигов 20 и администраторы серверов начинают беспокоится о месте на сервере (500 Гб), особенно если надо развернуть копию и что-то проверить.

Если у Вас MS SQL, то как вариант можно этот тяжелый регистр хранить в отдельной файловой группе и не бекапить ее. Только скорее всего при каждой реструктуризации придется заново переносить таблицу. Возможно на инфостарте кто-то этим уже заморачивался, надо поискать.
Ну и главное, перепроведение. У меня на база перепроведение ДО занимало часов 8, ПОСЛЕ 1 час, т.к в этом случае не происходит ни сравнения версий , ни записи этих версий, а только информация о том, что документ проводился.

Здесь полностью согласен. Чтоб облегчить групповое перепроведение, надо костыль прикручивать. Либо на этот период вообще отключать версионирование этих документов.


В общем что хочу сказать. Я так понимаю, что выигрыш достигается только на тяжелых объектах и только когда текущая версия объекта не отличается от предыдущей. Но для этого я бы сначала собрал статистику. А то у меня есть сомнения на этот счет. Для начала надо посчитать, при каком весе объекта его запись становится дороже расходов на сравнение и пр. Потом оценить вес имеющихся версий. Если есть такие объекты и их много, то надо бы собрать статистику, часто ли происходит перезапись неизмененного объекта. Если из 10 версий 1 неизмененная по отношению к предыдущей, то наверное не стоит заморачиваться. В любом случае надо замеры делать.
Ну и спасибо за попытку сделать что-то полезное.
6. maxx 840 25.11.13 09:12 Сейчас в теме
(3)
Если очень надо, то лучше пометку получать запросом, а не через точку по ссылке. Тем более, если у Вас документы с большим количеством записей в ТЧ. Сейчас чтоб получить пометку, тянется вообще весь объект.


Да запросов можно это сделать. Но тут у меня пока так получается, что сначала я получаю пометку удаления, а потом все равно для сравнения делаю ПолучитьОбъект, по идее когда я считываю пометку уже ПолучитьОбъект считает из кэша, т.е. не будет двойного чтения из базы. Но повторюсь, что , считаю что для пометки лучше сделать запросом.

В общем что хочу сказать. Я так понимаю, что выигрыш достигается только на тяжелых объектах и только когда текущая версия объекта не отличается от предыдущей. Но для этого я бы сначала собрал статистику.

Со статистике я и начал думать обо всем этом.
4. Silenser 512 24.11.13 19:30 Сейчас в теме
ИМХО.
Серилизация сама по себе занимает крайне мало времени, а вот сравнение - да. При записи документа нужно делать минимум телодвижений, ИМХО в БСП как раз все правильно - получили номер версии, сериализовали и записали, а анализ весь потом. Если уж так заботит размер базы - создайте регламентное задание, которое будет версии шерстить и удалять лишние или удалять больше определенного числа версий на объект. Я бы даже не искал последний номер версии, а писал GUID, потом можно отсортировать по дате записи версии (только не помню, если ли дата записи в стандартной БСП).
В идеале, посмотреть бы нагрузку на проц сервера приложений и на диск на SQL базе в момент перепроведения документов.
5. maxx 840 25.11.13 09:08 Сейчас в теме
(4)
При записи документа нужно делать минимум телодвижений

Это не аксиома, всё зависит от ситуации. Большинство решений по накоплению изменений объектов делают анализ именно перед записью.

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

Послушайте, но какая разница делать это сразу или регламентным заданием с точки зрения времени, все равно суммарное время будет одинакова при любом способе. Тут опять же зависит от условие эксплуатации конкретной базы. Если сидят до 10 операторов работают в файловых обычно базах, и к ним иногда забегает администратор(-программист), то наверное лучше всё сразу делать при записи. Если это админ в компании, который действительно всем занимается, может контролировать запуски регламентных заданий , результат этих запусков, то наверное тогда лучше делать регламентным заданием.
Поэтому опять же вижу, что это можно сделать настройкой типа "Сравнивать версии при записи" или "Сравнивать и удалять одинаковые версии регламентным заданием".
9. Silenser 512 25.11.13 09:40 Сейчас в теме
(5) Попробую навести вас на мысль: допустим регламентное задание потратило суммарно 30 мин на анализ и удаление лишних версий (при этом 28 мин ушло на анализ, а 2 мин на запись, при этом продолжительность каждой отдельной транзакции была минимальна, т.к. анализ выполнялся вне ее), а суммарно анализ внутри процедуры ПередЗаписью потратил 20 мин (при этом и анализ и запись вся суммарно заняла 20 мин, т.к. все выполняется внутри транзакции записи документа).
10. maxx 840 25.11.13 09:48 Сейчас в теме
(9)Ничего не понял, сформулируйте по-другому, что хотите сказать
11. Silenser 512 25.11.13 10:18 Сейчас в теме
(10) Увеличение числа телодвижений внутри транзакции ведет к увеличению ее продолжительности. Увеличение продолжительности транзакции ведет к увеличению числа одновременно активных транзакций. Увеличение числа одновременно активных транзакций ведет к риску эскалации транзакций, таймауту или деадлоку.
12. maxx 840 25.11.13 12:20 Сейчас в теме
(11) Да, теперь понял. Конечно время транзакции увеличится, тогда вариант с регламентным заданием может быть будет и лучше. Но думаю все равно надо анализировать ситуации каждый документ и его поведение в каждой базе, как эксплуатируется база. Например, Справочник "Организации" редко редактирует, я думаю можно и при записи всё сделать, а расходный документ уже может быть и блокировки. Просто не нужно забывать о "бедных" бухгалтерах, кладовщиках, которые работают одни в базах и нет у них помощи со стороны администраторов, я думаю там само всё должно работать.

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



13. Silenser 512 25.11.13 13:54 Сейчас в теме
(12) Опять же ИМХО, если у бухгалтеров или кладовщиков нет помощи от админов или разработчиков, то организация скорее всего маленькая и документооборот небольшой. Так что можно даже немного вольностей себе позволить при разработке, все равно они особо разницы не почувствуют, пока их в базе одновременно человек 30-50 не окажется.
7. ShantinTD 87 25.11.13 09:12 Сейчас в теме
(0) ну ведь глаза сломаешь, пока дочитаешь твою статью. В ворде хотя бы проверил, что ли...

Мысли вижу правильные, но реализация - пока что костыльная. Конечно, хранить полную сериализацию объекта в каждой записи, тем более не измененной, это жирно будет. Но 4 раза читать из базы, 2 раза сериализовывать - перебор, ИМХО. Тут скорее как Silenser в (4) написал нужно подчищать регистр периодически.

И еще вопрос: в том случае, когда для группового перепроведения используется не специализированная обработка, а динамический список, например, что прикажете? Отказаться от типового удобного механизма, за которым никуда лезть не нужно, в пользу отдельной обработки?
alexeyvs77; u_n_k_n_o_w_n; +2 Ответить
8. maxx 840 25.11.13 09:20 Сейчас в теме
(7)Но 4 раза читать из базы, 2 раза сериализовывать

С чего это решили, происходит все лишь дополнительное чтение объекта сохраненного в базе 1 раз.
2 раза сериализовать - 1 раз и так сериализуется в стандартном БСП , а 2-ой раз нужно для сравнения. Что не так?
14. ShantinTD 87 26.11.13 10:14 Сейчас в теме
(8) я хотел сказать, что производить достаточно громоздкие проверки при каждой мало-мальской записи - не есть гуд. Вижу, что понимание этого тут уже родилось.
Однако, могу и в пользу Вашего решения высказаться (и не буду стесняться в этом!): Ваш вариант вполне пригоден к применению, если использование регламентов по тем или иным причинам невозможно или затруднено. Причинами могут быть небольшая контора без толкового администратора базы, использование файлового варианта (опять же малопригодно для большой конторы), или еще что-то. С удовольствием продолжу конструктивный диалог, послушаю какие еще причины могут способствовать применению Вашего варианта.

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

(13) Silenser, если их окажется "человек 30-50", то это уже не маленькая контора. Да и в файловом варианте работать такой оравой негуманно. Опять приходим к регламентному заданию.
15. maxx 840 26.11.13 11:23 Сейчас в теме
(14)
я хотел сказать, что производить достаточно громоздкие проверки при каждой мало-мальской записи - не есть гуд. Вижу, что понимание этого тут уже родилось

Тут вы сразу крест поставили на кучу решений (http://infostart.ru/public/18588/, http://infostart.ru/public/172052/
http://infostart.ru/public/71458/
http://infostart.ru/public/19364/ и прочее и прочее)

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

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

Честно говоря мне эта тема не так интересно. Потому что в любой мало-мальски хорошей конфигурация, логика оптимального проведения не подразумевает, что нужно всё перепроводить и все движения переделывать, поэтому появляется в конфигурации свои обработки перепроведения (возьмите Бухгалтерию хотя бы), свои кнопки перепровести у пользователя, последовательности (по партиям_ и т.п.)
16. Silenser 512 26.11.13 11:52 Сейчас в теме
(15)
Как я знаю перед записью документа в момент перепроведения нельзя понять, менялся ли документ или нет, чтобы ничего не сравнивать объект с текущей версией в базе. В момент перепроведения он считается измененным, поэтому передать признак, что не нужно делать дополнительные действия нельзя.

Можно предположить, что если функция Модифицированность() дает истину в процедуре ПередЗаписью, то объект скорее всего изменен. Тогда можно в допсвойства закинуть некий признак и в ПриЗаписи выполнить некие действия по записи версии. Для документа еще нужно будет сравнить флаг проведения, если не ошибаюсь, его изменение на модифицированность не влияет.
17. maxx 840 26.11.13 12:15 Сейчас в теме
(16)
Для документа еще нужно будет сравнить флаг проведения, если не ошибаюсь, его изменение на модифицированность не влияет.

Надо это проверить. Вроде раньше влиял.
18. ShantinTD 87 26.11.13 13:54 Сейчас в теме
(15) я не сказал, что категорически нельзя проводить проверки перед записью. Я лишь поставил под сомнение правильность и оптимальность проверок. Это как раз то, о чем уже говорил Silenser: стОит ли овчинка выделки?
Честно говоря мне эта тема не так интересно. Потому что в любой мало-мальски хорошей конфигурация, логика оптимального проведения не подразумевает, что нужно всё перепроводить и все движения переделывать, поэтому появляется в конфигурации свои обработки перепроведения (возьмите Бухгалтерию хотя бы), свои кнопки перепровести у пользователя, последовательности (по партиям_ и т.п.)

Еще раз обрисую ситуацию: любая типовая на управляемых формах, форма списка - скорее всего является "Динамическим списком", можно выделить несколько документов (в том числе все) (а предварительно настроить отбор и сортировку) и нажать "провести". Специальная обработка - не требуется, перепроведение - групповое, конфигурация - типовая, "хорошая?" - "не плохая". А если говорить о перепроведении вообще, то в "хорошей" конфигурации его быть не должно, ИМХО. Нужно изначально не дать пользователю сделать неправильно.
19. maxx 840 26.11.13 14:12 Сейчас в теме
(18)
Еще раз обрисую ситуацию: любая типовая на управляемых формах, форма списка - скорее всего является "Динамическим списком", можно выделить несколько документов (в том числе все) (а предварительно настроить отбор и сортировку) и нажать "провести".


Проверил Модифицированность() даёт Истину, если перепроводишь документ.

Поэтому, я не знаю пока стандартного решения, как отличить "простое перепроведение" от "изменения проведенного документа (как программно, так и интерактивно) и его последующем проведением"
21. ShantinTD 87 27.11.13 09:53 Сейчас в теме
(19) еще раз повторю вопрос из (7): как поведет себя Ваша подсистема при использовании группового перепроведения из динамического списка?
По логике вещей запись о том, что документ перепровели должна остаться, а вот сериализация объекта в регистре сохраняться не должна. Правильно? Как дело обстоит на самом деле? Нужно ли мне подтягивать отдельную обработку, чтобы перепровести несколько документов? (при том, что в динамическом списке выбрать какие именно нужно перепровести - реально дело нескольких секунд).

Конечно, если перепроводятся документы разных типов, восстанавливаются последовательности, используется хитрый алгоритм и прочее - тут не отвертишься от специализированной перепроводилки.
22. maxx 840 27.11.13 11:20 Сейчас в теме
(21)
По логике вещей запись о том, что документ перепровели должна остаться, а вот сериализация объекта в регистре сохраняться не должна. Правильно?

Да всё правильно.

Просто я понял мы обсуждали, как при перепроведении динамических списков избавиться от сравнения версий и пока решения нет. Сравнение производиться будет, но одинаковые версии в регистр записывать не будут, будут только записи о проведении (пустышки), которые ссылаются на записи базовых версий.
20. ShantinTD 87 26.11.13 14:13 Сейчас в теме
Есть встречное предложение: называть это не "оптимизация", а "надстройка" над подсистемой версионирования объектов. То есть не заменять типовой механизм, а дополнять его. Опционально.
Может быть смазано высказываю свою мысль: система выборочного хранения записей в регистре - это хорошо, а вот как складывать записи в регистр или чистить его ("оперативно" или "регламентно") - сделать настраиваемым. И, например, при первом запуске, или периодически при запуске, проверить число пользователей в базе (при большом количестве рекомендовать регламент). Или проверить режим базы (для файлового варианта рекомендовать (жестко так рекомендовать) оперативный механизм). "Пусть лошадь думает - у нее голова большая". Пусть база сама определяет большая она или нет...
23. eeeio 111 27.11.13 13:53 Сейчас в теме
На мой взгляд оптимизация должна подразумевать вынос наиболее затратных действий в регламентную обработку. Например так:
1. ПриЗаписи в отдельный регистр фиксируется признак ВозможноНадоСохранитьВерсию = Истина и ссылка на объект, а также автор и дата записи (для нового объекта этот пункт не нужен);
2. Потом регламентное задание по этому регистру перебирает объекты и сравнивает их с хранящимися версиями - при нахождении различий сохраняет новую версию и удаляет обработанную строку из регистра (удаляет в любом случае)
3. На случай повторной записи объекта до регламентной обработки ПередЗаписью объекта происходит проверка на наличие флага ВозможноНадоСохранитьВерсию, и при его наличии сохраняет версию объекта ИЗ ССЫЛКИ
alexeyvs77; +1 Ответить
24. maxx 840 27.11.13 15:47 Сейчас в теме
(23) В целом, как уже обсуждали выше, согласен, что операцию сравнения и удаления можно вынести в регламентную обработку. Но я выступаю за то, чтобы работали оба варианта: сразу при записи документа или отложено регламентной обработкой(тут как раз придётся добавлять новое поле в записи "ВерсияПрошлаПроверкаНаИдентичностьСПредыдущими")
27. eeeio 111 27.11.13 18:43 Сейчас в теме
(24) мой вариант помимо сокращения объема хранимых версий (как и в статье) хорош тем, что:
- при записи неизмененного объекта не будет никаких затрат на проверку версий, если не считать быстрого запроса флага ВозможноНадоСохранитьВерсию
- при записи измененного объекта в случае отсутствия флага ВозможноНадоСохранитьВерсию тоже не будет затрат на сравнение версий
- и только при повторной записи объекта будет 1 раз вызвана процедура сравнения и записи версии
29. maxx 840 27.11.13 20:59 Сейчас в теме
(27)Не пойму что вы принципиально нового придумали.

В моем варианте для новых объектов никаких сравнений и записи версий нет.

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

Также напомню, что разработка родилась,когда документы проводились за месяц около 8 часов,после запуска моей настройки 1час, т.е. Большая часть времени уходило на сериализацию версий и запись этих версий в регистр
30. eeeio 111 28.11.13 08:54 Сейчас в теме
(29) Да, я не очень понятно выразился (хотя ничего принципиально нового я не придумал, конечно):
1. Запись нового объекта- нет затрат на контроль и запись версий (как и у вас)
2. При перезаписи объекта, после регламентной обработки "ОтложеннаяЗаписьВерсий" - нет затрат на контроль и запись версий (у вас есть)
3. При перезаписи объекта, необработанного регламентной обработкой "ОтложеннаяЗаписьВерсий" - есть сравнение и запись новой версии (из ссылки до изменения!), если найдены отличия (у вас тоже есть)
4. Нет необходимости в заполнении ДополнительныхСвойств объекта
То есть, судя по пунктам 2 и 4 можно получить плюсы из статьи, не заплатив (почти) за них минусами - лишним контролем при записи и замедленной скоростью типовой групповой перезаписи объектов из журнала
ojiojiowka; +1 Ответить
31. ShantinTD 87 28.11.13 09:22 Сейчас в теме
(29)
Также напомню, что разработка родилась,когда документы проводились за месяц около 8 часов...
мы об этом узнали только в (2), причем в конце немаленького комментария, зато с припиской "и главное - перепроведение". А из (0) мы то подумали, что вопрос о том, что "тратится лишнее время при записи" и "пухнет база". Вероятно, следовало начать с того, что оказалось "главным". По крайней мере акцентировать на этом внимание в (0). И акцентировать внимание на том, что обработка перепроведения тоже должна быть "оптимизированная", то есть заточенная под использование Вашей схемы версионирования.
Вероятно, если бы с (0) не осталось сомнений, что основной выигрыш именно на групповом перепроведении, то и вопросов и споров было бы меньше.
В свете того, что все затевалось ради перепроведения - предложение такое: комбинировать оба метода - ускоренный режим именно при перепроведении (специальной обработкой), и обычный режим + регламентная подчистка регистра при "плановом" проведении документа/записи объекта.
25. Danil.Potapov 27.11.13 17:27 Сейчас в теме
Есть еще более оптимальное решение. в 8.3 средствами платформы можно получать хеши. В хеш данных подаются двоичные данные от ЗаписьFastInfoset, получается хеш. В самом регистре версий добавляется ресурс с хешом версии. При записи из регистра считывается последняя версия и ее хэш и сравнивается с новых хешом. Такая доработка позволяет уменьшить объемы чтения данных из базы.
Кузьмич; +1 Ответить
26. maxx 840 27.11.13 17:53 Сейчас в теме
(25)
Есть еще более оптимальное решение. в 8.3 средствами платформы можно получать хеши.

Дайте ссылку почитать про хэши. Тут главное учесть, что проводят и меняют документы разные пользователи, в разные дни.
28. Danil.Potapov 27.11.13 18:52 Сейчас в теме
(26) в справке конфигуратора 8.3 ХешированиеДанных метод добавить, туда подается результат работы ЗаписьFastInfoset.Записать()

итого

ДвоичныеДанные = ЗаписьFastInfoset.Закрыть()
ХешированиеДанных = Новый ХешированиеДанных(ХешФункция.SHA256);
ХешированиеДанных.Добавить(ДвоичныеДанные);
ХешВерсии = ХешированиеДанных.ХешСумма

второй вариант подавать на хеширование не Двоичные данные и строку (если работа версионирования идет через ЗаписьXML).



ojiojiowka; +1 Ответить
32. ShantinTD 87 28.11.13 09:28 Сейчас в теме
(28) Dpotapov, а с 8.3 тоже нужно осторожно - далеко не все перешли на новую платформу. Бывают и те, кто еще какой-нибудь 8.2.13 пользуются.
34. Danil.Potapov 28.11.13 09:54 Сейчас в теме
(32) ShantinTD, В 8.2 делаю тоже самое через регламентное задание, ночью система ищет версии без хеша, добавляет его, удаляет одинаковые версии. Скорость записи измененного документа не меняется, но хоть места становится меньше.
35. ShantinTD 87 28.11.13 10:17 Сейчас в теме
(34) Dpotapov, я сказал о том, что "использовать хеш" на 8.3 можно, но нужно иметь ввиду, что на 8.2 встроенного хеша нет - нужно приколхозивать его. У меня, например, была самописная процедура MD5(СтрокаДляХеширования). Естесственно, поменять во всех местах ее вызов на вызов встроенного объекта хеширование - хлопотно, и неправильно. В саму процедуру внесены изменения: если версия 8.3 или выше - то встроенный объект, иначе самописный алгоритм.
А "отсталые" пользователи, к сожалению, бывают: умер комп, поставили заново 1С с диска. Только вот диск 2010 года (или 2011 - не позднее), там тебе и счет-фактура "неправильная", и платформа старая, и прочее и прочее.
36. maxx 840 28.11.13 11:30 Сейчас в теме
(25)
Есть еще более оптимальное решение. в 8.3 средствами платформы можно получать хеши.

А можете тыкнуть меня на материалы по хешированию, незнакомая для меня тема.
Поэтому пока не понимаю, что именно оптимальнее получается: размер версии или скорость сравнения?
38. maxx 840 28.11.13 21:44 Сейчас в теме
(37)Правильно я понял, что вы утверждаете, что хеширование использовать оптимальнее, т.к.:
- сжатый ЗаписьFastInfoset в ХешФункцию занимает меньше в размере, чем сжатие просто типа ХранилищеЗначения?
- сравнивать ХешФункции будет быстрее чем сериализованные ХранилищеЗначения с ЗаписьFastInfoset внутри?
39. Danil.Potapov 29.11.13 10:34 Сейчас в теме
(38) нет. Смысл в том, чтобы сравнивать хэш версий, а не тащить из базы хранилище предыдущей версии.
40. maxx 840 29.11.13 10:48 Сейчас в теме
(39)
Смысл в том, чтобы сравнивать хэш версий, а не тащить из базы хранилище предыдущей версии

Смысла не понял (сравнивать потому что можно сравнивать хеш версии а не версии объектов так?).
41. Danil.Potapov 29.11.13 11:04 Сейчас в теме
(40) сравниваются хэш версий объектов, так как при вытягинваии из базы будет меньше тянуться данных.
42. maxx 840 29.11.13 17:50 Сейчас в теме
(41)
сравниваются хэш версий объектов, так как при вытягинваии из базы будет меньше тянуться данных

Не понял за счет чего меньше.
43. Bad_Developer 19.09.14 13:50 Сейчас в теме
Что мешает серриализованные объекты сохранять в файл, и по периодам архивировать данные. Их можно складывать в дальний угол. И в случае форсмажора восстанавливать всю цепочку событий.
44. maxx 840 19.09.14 23:12 Сейчас в теме
Да ничего не мешает мне лично и думаю 1с, главное если есть желание.
Минусы только чтобы проанализировать изменения в данных на копии базы данных нужно дудеть тащить весь архив.
Оставьте свое сообщение

См. также

Универсальные инструменты 1С

Инструменты и обработки Программист Расширение (cfe) v8 1cv8.cf Абонемент ($m) Универсальные обработки Прочие инструменты разработчика

Свободно распространяемый набор универсальных обработок и отчетов в виде расширения для разработки и поддержки, которое работает во ВСЕХ видах клиентских приложений и во всех операционных системах, которые поддерживает платформа 1С:Предприятие, кроме мобильных. Консоль запросов - консоль отчетов - консоль кода - редактор объектов базы данных - удаление помеченных объектов - поиск и удаление дублей - редактор констант - консоль заданий - групповая обработка справочников и документов - динамический список - поиск ссылок на объект - регистрация изменений для обмена данными - структура хранения базы - консоль HTTP запросов.

1 стартмани

21.01.2020    4695    76    cprit    50       

Базовый курс для начинающих 1С-программистов. Пятый поток. Онлайн-курс с 12 февраля по 15 апреля 2020 г. Промо

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

4500/9500 рублей

Тест серверного оборудования на допустимое количество пользователей: как это использовать?

Статья Системный администратор Программист Архив с данными v8 1cv8.cf Абонемент ($m) Администрирование СУБД Нагрузочное тестирование Сервера

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

3 стартмани

17.12.2019    5949    7    sapervodichka    3       

Базовый курс по управлению ИТ-проектами. Курс проходит с 26 февраля по 22 апреля 2020 года. Промо

Отличительная черта курса - органичное сочетание трех вещей: 1.Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С); 2. Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days); 3. Разбор реальных проблем и рекомендации экспертов по проектам слушателей. Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике руководителей проектов внедрения. Ведущая курса - Мария Темчина.

от 11000 рублей

Шаблон разработки печатных форм и подключения к конфигурациям на БСП 2.х и БСП 3.0

Инструменты и обработки Программист Расширение (cfe) v8 1cv8.cf Абонемент ($m) Печатные формы документов БСП (Библиотека стандартных подсистем) Расширения

«Вместо поставки внешних печатных форм в виде внешних обработок рекомендуется вести их разработку с помощью расширений конфигурации.» [ИТС, БСП гл. 3.38 Печать] У меня задачи типа «Требуется разработать печатную форму …» появляются регулярно, но с временными интервалами. Что бы вести разработку единообразно, для конфигураций на БСП, я заготовил шаблон для таких задачек, который позволяет мне сразу приступить к разработке макета и алгоритма формирования печатной формы, а «обертка» из БСП уже готова.

1 стартмани

04.10.2019    15126    30    tolX5    16       

Перенос данных УПП 1.3 => ERP 2 (ЕРП) / УТ 11 / КА 2.х (обработка переноса документов, остатков и справочников из "1С:Управление производственным предприятием, ред. 1.3" в ERP / УТ 11 / КА 2). Обновлен до УПП 1.3.130.х, КА 2.4.11.х и ERP 2.4.11.х! Промо

Обработка позволяет переносить из УПП 1.3 в ERP 2 документы за выбранный период и остатки. Типовая обработка от фирмы 1С документы не переносит. Также исправлены ошибки типовой обработки. При выходе новых релизов обновление высылается бесплатно в течение года. Разработка будет полезна фирмам-франчайзи, которые периодически выполняют такой перенос данных для заказчиков. Вы можете один раз приобрести обработку переноса, и потом бесплатно получать обновления при выходе новых релизов конфигураций 1С.

29700 руб.

CF & SQL : конструктор прямых запросов к БД 1С

Инструменты и обработки Системный администратор Программист Архив с данными v8 1cv8.cf Россия MS SQL Абонемент ($m) Инструментарий разработчика Администрирование СУБД

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

1 стартмани

02.10.2019    8295    135    dmitrydemenew    35       

Еще один тест 1C: Postgres SQL 11 Pro Enterpise против MSSQL 14 под Windows 2012 Server R2

Статья Системный администратор Архив с данными v8 Windows Абонемент ($m) Производительность и оптимизация (HighLoad)

Проработав 15 лет с MSSQL в 2017 начал активно СУБД Postgres SQL. За два года успел поработать в 9 версии Postgres и в 10-ой. И пришел к выводу, что существуют реальное замедление работы баз после перехода на Postgres. Недавно вышла 11 версия Postgres Pro Enterpise, которая обещает почти 2-х кратное ускорение над 11 Pro Standart и 10-ой версией. Закупив лицензию Postgres 11 Pro Enterpise Это я и решил проверить на 1С.

1 стартмани

05.09.2019    7628    20    ogidni    88       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Конвейер проверки качества кода

Инструменты и обработки Программист Архив с данными v8 1cv8.cf Windows Абонемент ($m) Инструментарий разработчика Практика программирования Математика и алгоритмы Разработка

Jenkinsfile для выполнения проверки качества кода. Собирает информацию с АПК, EDT и BSL-LS. Сопоставляет ошибки с гит-репозиторием, выгруженным ГитКонвертором. Отправляет в Сонар.

3 стартмани

04.09.2019    9626    16    Stepa86    37       

1C:Предприятие для программистов: Запросы и отчеты. Второй поток. Онлайн-интенсив с 17 марта по 16 апреля 2020 г. Промо

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

6500 рублей

Просмотр и анализ структуры базы данных (отчет на СКД)

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 v8::СКД 1cv8.cf Windows Абонемент ($m) Инструментарий разработчика

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

5 стартмани

24.07.2019    10997    113    YPermitin    26       

Модель объекта

Инструменты и обработки Программист Конфигурация (md, cf) v8 Абонемент ($m) Инструментарий разработчика

Подсистема позволяет описать модель данных объекта, где описана зависимость между реквизитами, и затем использовать эту модель в разных сценариях работы с объектом. Версия платформы: 8.3.6 и выше. С небольшими доработками будет работать на 8.2.

1 стартмани

30.06.2019    5453    1    vadim1980    3       

Онлайн-курс «Практические аспекты внедрения регламентированного учета и расчета себестоимости в 1С:ERP на крупных промышленных предприятиях» с 17 февраля по 13 марта 2020 года. Промо

Курс рассчитан для подготовки экспертов по регламентированному учету и учету затрат для внедрения на крупных промышленных предприятиях с «исторически сложившимся» учетом

9000 рублей

Переводим рутину ручного тестирования 1C на рельсы Jenkins-а и ADD

Инструменты и обработки Системный администратор Программист Архив с данными v8 Windows Абонемент ($m) Инструментарий разработчика Jenkins

Вы все еще тестируете свои конфигурации 1С вручную? Да вы просто тратите жизнь впустую! В данном туториале попробуем скрестить ADD и jenkins для автоматического запуска тестов.

1 стартмани

03.06.2019    13559    1    ripreal1    86       

Универсальный HTTP-сервис на платформе 1С, аля HTTP-сервер с примером

Инструменты и обработки Программист Подсистема v8 1cv8.cf Абонемент ($m) Инструментарий разработчика

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

1 стартмани

13.05.2019    20166    100    Diversus    42       

Открыто голосование за доклады на INFOSTART MEETUP Krasnodar Промо

Выбирайте и голосуйте за самые интересные доклады, лучшие из них попадут в окончательную программу митапа. Голосование продлится до 30 января 2020 года.

Групповая проверка доработок

Инструменты и обработки Программист Внешняя обработка (ert,epf) v8 v8::УФ 1cv8.cf Абонемент ($m) Инструментарий разработчика

Обработка для массовой проверки доработок конфигурации: Открытие форм, Печать, Формирование отчетов, Проведение документов, Запись справочников, ПВХ, ПВР. Выдает список обнаруженных ошибок. Рекомендуется применять для тестирования обновленной конфигурации, перед установкой пользователям. В коде используются универсальные методы поэтому подходит для большинства конфигураций, построенных на базе библиотеки стандартных подсистем. Проверялась на Зарплата и управление персоналом КОРП 3.1.8.216, Управление торговлей 11, 1С:ERP Управление предприятием 2.4.7.141, Бухгалтерия предприятия КОРП 3.0.68.66.

2 стартмани

05.05.2019    9264    74    sapervodichka    23       

Расширение "Быстрая проверка кода" для конфигурации 1С:Автоматизированная проверка конфигураций

Инструменты и обработки Программист Расширение (cfe) v8 v8::УФ 1cv8.cf Абонемент ($m) Инструментарий разработчика

Расширение для конфигурации "1С:Автоматизированная проверка конфигураций", позволяющее проверять произвольный код.

1 стартмани

26.03.2019    12072    46    Bazil    25       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Настройка отладки на сервере 1С

Инструменты и обработки Программист Внешняя обработка (ert,epf) v8 1cv8.cf Windows Абонемент ($m) Инструментарий разработчика

Обработка для настройки отладки на сервере, включение отладки COM-соединений и отладки Web-сервисов.

1 стартмани

26.03.2019    14941    67    frkbvfnjh    32       

Редактор объектов информационной базы 8.3

Инструменты и обработки Программист Пользователь Внешняя обработка (ert,epf) v8 v8::УФ 1cv8.cf Россия Windows Абонемент ($m) Инструментарий разработчика Универсальные обработки

Универсальная внешняя обработка для редактирования реквизитов и табличных частей объектов информационной базы, редактирование движений документов. Доступ ко всем реквизитам объектов, есть возможность выгрузки и загрузки данных (объекты и движения документов) через XML. Платформа 8.3, управляемые формы. Версия 1.1.0.37 от 14.12.2019

2 стартмани

23.01.2019    13736    169    ROL32    28       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Конструктор мобильного клиента Simple WMS Client: способ создать полноценный ТСД без мобильной разработки. Теперь новая версия - Simple UI (обновлено 14.11.2019)

Инструменты и обработки Программист Архив с данными v8 v8::Mobile БУ УУ Android Оптовая торговля Производство готовой продукции (работ, услуг) Розничная торговля Учет ОС и НМА Учет ТМЦ Абонемент ($m) Инструментарий разработчика Сканер штрих-кода Терминал сбора данных Мобильная разработка

Simple WMS Client – это визуальный конструктор мобильного клиента для терминала сбора данных(ТСД) или обычного телефона на Android. Приложение работает в онлайн режиме через интернет или WI-FI, постоянно общаясь с базой посредством http-запросов (вариант для 1С-клиента общается с 1С напрямую как обычный клиент). Можно создавать любые конфигурации мобильного клиента с помощью конструктора и обработчиков на языке 1С (НЕ мобильная платформа). Вся логика приложения и интеграции содержится в обработчиках на стороне 1С. Это очень простой способ создать и развернуть клиентскую часть для WMS системы или для любой другой конфигурации 1С (УТ, УПП, ERP, самописной) с минимумом программирования. Например, можно добавить в учетную систему адресное хранение, учет оборудования и любые другие задачи. Приложение умеет работать не только со штрих-кодами, но и с распознаванием голоса от Google. Это бесплатная и открытая система, не требующая обучения, с возможностью быстро получить результат.

5 стартмани

09.01.2019    28159    231    informa1555    198       

Управление задачами в 1С - готовая подсистема с открытым кодом и широким базовым функционалом. Версия 1.0.6

Инструменты и обработки no Архив с данными v8 Абонемент ($m) Инструментарий разработчика Управление бизнес-процессами (BPM) Управление проектом

Конфигурация-подсистема для управления задачами с базовым функционалом, который, однако, может удовлетворить довольно широкий спектр запросов. Есть статусы и приоритеты, учёт трудозатрат по исполнителям и даже базовые разграничения по правам. А открытый исходный код позволит на базе данной конфигурации развить систему до любого уровня сложности.

2 стартмани

17.12.2018    12659    84    for_sale    38       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

PostgreSQL для 1С 8.3: ускоряем резервное копирование и восстановление для отдельной базы очень большого размера

Статья Системный администратор Программист Архив с данными v8 1cv8.cf Россия PostgreSQL Абонемент ($m) Производительность и оптимизация (HighLoad) Тестирование и исправление

В этой статье разберем оптимизацию работы с моментальным снимком отдельной базы 1С в кластере PostgreSQL средствами pg_dump.exe, pg_restore.exe, psql.exe в среде Windows Server 2008,2012,2016. А также разберем проблемные ситуации и неожиданные ограничения при работе 1С в связке с PostgreSQL. Для Linux все аналогично.

1 стартмани

03.12.2018    19649    30    vsasav    68       

Использование подсистемы БСП "Заполнение объектов"

Статья Программист Расширение (cfe) v8 v8::УФ 1cv8.cf Россия Абонемент ($m) Практика программирования Универсальные функции БСП (Библиотека стандартных подсистем)

Применение механизмов БСП для добавления новых команд заполнения к формам различных объектов. Использование расширений конфигурации для доработки. Шаблоны для реализации собственных команд заполнения.

1 стартмани

23.11.2018    16719    10    ids79    23       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Многопоточная обработка данных

Инструменты и обработки Системный администратор Программист Конфигурация (md, cf) v8 v8::УФ 1cv8.cf Абонемент ($m) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Конфигурация "Универсальные механизмы: пакеты данных". Набор инструментов для быстрой организации отказоустойчивой многопоточной обработки данных.

1 стартмани

23.11.2018    13365    46    _ASZ_    15       

Навигатор по конфигурации базы 1С 8.3

Инструменты и обработки Программист Пользователь Внешняя обработка (ert,epf) v8 v8::УФ 1cv8.cf Россия Windows Абонемент ($m) Инструментарий разработчика Универсальные обработки

Универсальная внешняя обработка (СДРНавигаторУпр) для просмотра метаданных конфигураций баз 1С 8.3. Отображает свойства и реквизиты объектов конфигурации, их количество, основные права доступа и т.д. Отображаемые характеристики объектов: свойства, реквизиты, стандартные рекизиты, реквизиты табличных частей, предопределенные данные, регистраторы для регистров, движения для документов, команды, чужие команды, подписки на события, подсистемы. Отображает структуру хранения объектов базы данных, для регистров доступен сервис "Управление итогами". Небольшой набор сервисных функций для повседневной работы. Для программистов и пользователей. Платформа 8.3, управляемые формы. Версия 1.1.0.51 от 08.01.2020

3 стартмани

28.10.2018    19958    207    ROL32    62       

PgConf.Russia 2020. 3-5 февраля 2020 г. Москва. Промо

PGConf.Russia – международная техническая конференция по открытой СУБД PostgreSQL, ежегодно собирающая более 700 разработчиков, администраторов баз данных и IT-менеджеров для обмена опытом и профессионального общения. Для участников сообщества infostart.ru скидка 5% на участие в конференции.

от 12350 рублей

Мониторинг показателей систем 1С 8.3 с помощью Zabbix

Инструменты и обработки Системный администратор Внешняя обработка (ert,epf) v8 1cv8.cf Абонемент ($m) Внешние источники данных Zabbix

Опишу свой опыт мониторинга наших систем 1С с помощью Zabbix и ту пользу, которую можно извлечить из этого.

1 стартмани

05.10.2018    25750    39    akimych    48       

HTTP Сервисы: Путь к своему сервису. Часть 4

Статья Системный администратор Программист Расширение (cfe) v8 1cv8.cf Абонемент ($m) Инструментарий разработчика Практика программирования

Продолжение статьи «HTTP Сервисы: Путь к своему сервису. Часть 3». В предыдущих частях мы уже о многом поговорили. В этой части поговорим про размер сообщений, о файлах, о порциях и немножко, о регламентах.

1 стартмани

28.09.2018    15854    20    dsdred    13