Гордеев Алексей

90
Рейтинг

allert73
Алексей Гордеев



  •   Регистрация: 13.10.2009 (14 лет назад)

  •   Был(а) на сайте: 12.03.2024

Подписчики 7

Группы

Профессиональный разработчик

Рейтинг 90

Подсистема: История изменений реквизитов объекта, в том числе табличных частей. 1С 8.2

Инструменты и обработки Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Windows Абонемент ($m) Конфигурация (md, cf) Журнал регистрации

Данная подсистема предназначена для хранения истории изменений реквизитов шапок и табличных частей документов и справочников. Подсистема основана на записях изменений реквизитов в регистр сведений с указанием автора и времени изменения.

1 стартмани

12.11.2012    48158    301    allert73    19       

34

Использование Web-сервисов для синхронизации баз данных в режиме online 1С8.2 (8.1) .

Статья Программист Платформа 1С v8.3 Конфигурации 1cv8 Windows Бесплатно (free) Нет файла WEB-интеграция

Часто при ведении учета в различных конфигурациях 1С возникает необходимость выполнения обмена данных. Для решения этой задачи принято использовать Универсальный обмен данными XML или другие внешние обработки, общим у которых является использование текстовых файлов посредников. Я предлагаю использовать Web-сервисы 1С.

08.11.2012    36509    allert73    10       

53

Комментарии

ОбменСохранение xml сведений о застрахованных лицах в ФСС без ЭДО#0 04.03.24 7:00
Расширение позволяет сохранить в xml файл ответов на запросы ФСС о физических лицах без подключенного ЭДО.
ПубликацииАнализ вычетов НДС по полученным авансам#0 17.08.22 6:00
Отчет позволяет проводить анализ вычетов НДС по полученным авансам, в разрезе реализаций.
AdminПодсистема: История изменений реквизитов объекта, в том числе табличных частей. 1С 8.2#11 17.01.14 9:51
Тем что в моей подсистеме не полная сохраняется верися объета в виде XML файла переведенного в двоичные данные. А сохраняются только значения и только измененных реквизитов. А это в свою очередь облегчает анализ внесенных изменений и не приводит к неоправданному(из за обилия не нужной информации) разрастанию базы.
AdminПодсистема: История изменений реквизитов объекта, в том числе табличных частей. 1С 8.2#6 19.05.13 18:36
(5)подозреваю что ни чем. к сожалению не могу провести полного анализа так как для этого мне придется купить их решение.
AdminПодсистема: История изменений реквизитов объекта, в том числе табличных частей. 1С 8.2#4 05.04.13 11:25
(3) qvvert, Извиняюсь что ввел в заблуждение заголовком статьи(заголовок я исправил). к сожалению подсистемы написанной под 8.1 нет. Но вы можете создать у себя аналогичные подписки на события и скопировать туда тексты модулей Важно!!!(копирование объектов копи псейтом целиком из дерева конфигурации, может привести к повреждению конфигурации, поэтому копируйте только текст модулей).
Также рекомендую вам перейти на 8.2. конвертация данных не займет много времени и в большенстве случаев проходит безболезненно. Кроме того(если ваш случай окажется болезненным), после конвертации можно включить режим совмещенности с кодом работающим только на 8.1, до того как куски будут скорректированы, что позволит не прерывать работу системы. А возможность проводить динамические обновления вас приятно обрадует
AdminПодсистема: История изменений реквизитов объекта, в том числе табличных частей. 1С 8.2#2 12.01.13 23:16
нет не покажет т.к. номер строки это поле табличной части.
Насчет 60 ГБ для того чтобы регистр достиг подобных размеров записывать изменения придется очень долго.

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

В данной выложенной подсистеме подход совершенно другой. Здесь при внесение изменений в объект в регистр сведений записывается только информация о том у какого документа, коркой именно реквизит был изменен, ну и естественно автора(виновника) изменения и время когда данной действие было произведено. Создается одна запись в регистре с неопределенными типами измерений, которая хранит в себе ссылки на объекты базы, т.е. 5 текстовых полей не более 50 ти символов. Это занимает очень мало места и легко обрабатывается в дальнейшем.
AdminПодсистема: История изменений реквизитов объекта, в том числе табличных частей. 1С 8.2#0 12.01.13 22:53
Данная подсистема предназначена для хранения истории изменений реквизитов шапок и табличных частей документов и справочников. Подсистема основана на записях изменений реквизитов в регистр сведений с указанием автора и времени изменения.
DevИспользование Web-сервисов для синхронизации баз данных в режиме online 1С8.2 (8.1) .#7 09.11.12 16:39
(5) DitriX, Извиняюсь, забыл указать получателя в комментарии. текст ответа в комментарии 6.
DevИспользование Web-сервисов для синхронизации баз данных в режиме online 1С8.2 (8.1) .#6 09.11.12 16:35
все реквизиты которые необходимо синхронизировать я передаю в структуре значений преобразованной в строку. Согласен что перебор реквизитов объекта через его метаданные(что позволило бы использовать общий обработчик для различных типов объектов) был бы эффективным, но только для случая когда реквизиты объекта во всех базах совпадают, например в практике процедуры синхронизации происходят между Базами CRM(от раруса), УПП(от 1с), самодельные база "регистрации Продаж и Остатков" и база "регистрации Потребности, себестоимости и закупок" и набор реквизитов справочников и документов довольно таки сильно отличается.

Единицы измерения у меня подчиненный справочник. их я передаю как таблицу значений опять же преобразованную в строку, то же самое делаю и с табличными частями объектов(преобразую таблицы в строку), также имеется реквизит базовая единица измерения который передается в качестве GUIDа нужной единицы, и обрабатывается уже после того как обработана переданная таблица единиц. Код по передачи данных большинства реквизитов в статье заменен на многоточия. (т.к. статья писалась лишь с целью показать альтернативную возможность синхронизации данных)
но вот кстати процедура передачи Единицы измерения в примере есть.
Что касается прочих реквизитов которые имеют не примитивные типы (например реквизит "Поставщик"), то в зависимости от пожелания: элементы принадлежащие набору данных с типом данных реквизитов, можно также синхронизировать. Очевидно что вызов процедур синхронизации для значений которые присваиваются реквизитам элемента, происходит раньше синхронизации самого элемента.

Почему ГУИД а не код, дело в том, что по определенным причинам, код и номер(для объекта документа) являются величинами переменными, в то время как УникальныйИдентифкатор() величина постоянная.

О том что делать в случае если базы к которым мы стучим не доступны, например можно сделать так, как указоно в предыдущем комментарии.
Процедура ПриЗаписи(Отказ)
Если РежимЗаписиДок<>РежимЗаписиДокумента.Проведение тогда
отказ = не Синхронизировать();
КонецЕсли;
КонецПроцедуры

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

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

Насчет Сотни Раз. Фиговое решение согласен. Однажды на практике как то вышло так что запрос к веб-серверу обрабатывался с третьей попытки. Вообще давно пора от этого куска избавиться.