Для управления регистрацией документа в последовательности документов служит набор записей регистрации в последовательности документов.
У документа есть свойство ПринадлежностьПоследовательностям. Значением свойства является коллекция наборов записей регистрации в последовательности документов. Для каждой последовательности, в которой участвует документ, существует свой собственный экземпляр набора записей. Если у документа стоит режим автоматического заполнения последовательностей, то перед записью документа наборы записей регистрации будут автоматически заполнены. Для последовательностей без измерений набор записей будет содержать только одну запись. Для последовательностей с измерениями число записей зависит от содержания документа и настройки соответствия измерений последовательности реквизитам документа.
Набор записей автоматически заполняется до записи документа и записывается после записи документа в одной транзакции с ним. Это позволяет в обработчиках событий документа ПередЗаписью() и ПриЗаписи() переопределить набор записей регистрации. Так, например, если документ входит в последовательность Последовательность1 и у документа стоит признак автоматического заполнения последовательности, то для того что бы отменить его регистрацию в последовательности в зависимости от значения реквизита документа достаточно в модуль документа вставить обработчик события ПередЗаписью() следующего содержания:
В этом случае если реквизит Регистрировать имеет значение "Ложь", то документ не будет зарегистрирован в последовательности Последовательность1. Кроме отмены регистрации документа в последовательности, доступна возможность написания собственного алгоритма регистрации документа в последовательности. Для этого надо очистить набор записей регистрации и заполнить его новыми записями.
Формат JSON в 1С до версии 8.3.6 не реализован, но нижет я приведу примеры функций которые можно использовать для полноценной работы JSON в 1С предыдущий версий.
JSON (JavaScript Object Notation) это текстовый формат обмена данными, широко используемый в веб-приложениях. По сравнению с XML он является более лаконичным и занимает меньше места. Кроме этого все браузеры имеют встроенные средства для работы с JSON.
Необходимость работы с этим форматом на уровне платформы обусловлена не только тем, что это «модный современный» формат, который прикладные решения 1С:Предприятия сами по себе могут использовать для интеграции со сторонними приложениями. Другая причина заключается ещё и в том, что JSON активно используется в HTTP интерфейсах. А в 1С:Предприятии как раз есть такие механизмы, в которых хочется использовать этот формат. Это REST интерфейс приложения, автоматически генерируемый платформой, и HTTP-сервисы, которые вы можете создавать самостоятельно.
В платформе с версии 8.3.6:
Потоковое чтение и запись JSON:
Объекты потоковой работы - это общие объекты ЧтениеJSON и ЗаписьJSON. Они последовательно читают JSON из файла или строки, или последовательно записывают JSON в файл или строку. Таким образом, чтение и запись JSON происходят без формирования всего документа в памяти.
В качестве иллюстрации потокового чтения JSON можно привести следующий пример:
Результат такой записи:
Сериализация примитивных типов и коллекций в JSON
Вторая группа средств работы с JSON хороша тем, что избавляет вас от рутинной работы по чтению/записи каждого отдельного значения или свойства. При чтении документы JSON отображаются в фиксированный набор типов платформы: Строка, Число, Булево, Неопределено, Массив, ФиксированныйМассив, Структура, ФиксированнаяСтруктура, Соответствие, Дата. Соответственно, в обратную сторону, композиция объектов этих типов позволяет сформировать в памяти и быстро записать в файл структуру JSON. Таким образом, чтение и запись небольшого объема JSON заранее известной структуры можно производить немногими строчками кода.
Основное назначение этих средств мы видим в обмене информацией с внешними системами, чтении конфигурационных файлов в формате JSON.
Сериализацию вы можете выполнять с помощью методов глобального контекста ПрочитатьJSON() и ЗаписатьJSON(). Они работают в связке с объектами ЧтениеJSON и ЗаписьJSON.
В качестве примера десериализации JSON можно рассмотреть чтение массива из двух объектов:
Полностью автоматизировали работу с JSON и реализовали в платформе третью группу средств. Они позволяют сериализовать в JSON прикладные типы 1С:Предприятия: ссылки, объекты, наборы записей и вообще любые типы, для которых поддерживается XDTO сериализация. Конечно же, мы обеспечили и обратную операцию - десериализацию. Зачем это нужно!?
Прежде всего, и в основном, XDTO сериализацию в JSON мы рекомендуем использовать при обмене данными между двумя прикладными решениями 1С:Предприятия. По сравнению с XML формат JSON более компактный, сериализация/десериализация в/из JSON выполняется быстрее. Кроме этого мы предприняли дополнительные меры для того, чтобы сократить объём передаваемых данных.
Кроме обмена между приложениями 1С:Предприятия этот механизм можно использовать и для обмена с внешними системами, готовыми принимать типы данных 1С:Предприятия. Например, XDTO сериализацию в JSON можно использовать для организации собственного HTTP интерфейса прикладного решения. Сервис на платформе 1С:Предприятия будет формировать ответ в памяти в виде строки JSON. А затем передавать её при помощи объекта HTTPСервисОтвет. Реализованный нами механизм сериализации полностью соответствует стандарту JSON. Поэтому внешняя система не должна испытывать каких-либо трудностей с десериализацией.
Использование XDTO сериализации в JSON для других задач видится нам маловероятным. Потому что если внешняя система не готова работать с прикладными типами 1С:Предприятия, то зачем их ей передавать? А если предполагается обмениваться только примитивными типами и коллекциями, то для этой задачи хорошо подходят методы ПрочитатьJSON() и ЗаписатьJSON(). Подробнее здесь
Программисту, имеющего немного опыта на платформе 1С 8.2, бывает сложно разобраться: ПередЗаписью, ПриЗаписи, ПослеЗаписи, на сервере, на клиенте, в модуле формы, в модуле объекта, а-а-а-а-аааа!!.....
Именно такое сложное чувство непонимания было поначалу и у меня. В процессе обучения и реального опыта была создана эта шпаргалка, целью которой было "разложить всё по полочкам", чтобы было четкое понимание в каком случае какой обработчик нужно использовать и в какой последовательности они запускаются при записи объектов.
Для чего нам вообще нужны эти обработчики?
Очень часто программисту требуется переопределить стандартное поведение системы во время записи объектов, а именно: отменить запись, в случае каких-то условий; запросить дополнительную информацию у пользователя; дозаполнить реквизиты; что-то ещё записать в базу данных на основании этой записи; что-то изменить на форме после записи и т.д. и т.п. Каждый программист рано или поздно сталкивается с подобными задачами, потому знать назначение и последовательность запуска этих событий программисту, работающему на платформе 1С 8.2, необходимо.
В модуле формы или в модуле объекта?
Сначала надо определиться нужны ли нам данные формы? Будет ли запись записываться программным способом или только интерактивно? Будем ли вести диалог с пользователем?
Дело в том, что часть событий выполняется на уровне модуля формы и это значит, что они выполняются только при интерактивной записи, а также в этих событиях мы можем обращаться к данным формы, вести диалог с пользователем.
Другая часть событий выполняется на уровне модуля объекта, как при интерактивной, так и при программной записи.
Потому можно сразу определиться с обработчиком модуля формы или модуля объекта будем работать.
Модуль формы: на клиенте или на сервере?
Далее, если выбран модуль формы, то надо определиться какой обработчик потребуется: исполняемый на клиенте, или исполняемый на сервере. Если потребуется диалог с пользователем, то на клиенте, в противном случае на сервере. Их можно отличить по имени директивы компиляции или по имени обработчика (когда на сервере, это пишется в имени, например ПередЗаписьюНаСервере()).
Как выбрать конкретный обработчик?
Выбор зависит от поставленной задачи. Что конкретно можно делать в каждом обработчике опишу ниже, а пока пример.
Пример выбора обработчиков событий записи объекта:
Бывают задачи, когда потребуется использовать несколько обработчиков для решения одной задачи. Например, надо запросить информацию у пользователя во время записи: «Будем создавать новый документ на основании этой записи?» и, если пользователь ответит утвердительно, то надо создать новый документ с ссылкой на записываемый объект. Причем запись нового документа надо выполнять в транзакции, т.к. если текущая запись по каким то причинам будет отменена, то и уже созданный и записанный документ не должен остаться в базе данных.
Для решения этой задачи потребуется использовать обработчики события модуля формы по двум причинам:
1) Диалог с пользователем возможен только на клиенте, а клиентеские обработчики есть только в модуле формы. Для диалога будем использовать клиентскую процедуру модуля формы ПередЗаписью(), и сохраним ответ пользователя в параметре этой процедуры «ПараметрыЗаписи».
2) А в процедуре ПриЗаписиНаСервере() модуля формы примем этот параметр и в зависимости от него будем создавать документ или нет. Почему именно эта процедура? Ссылка будет получена только после записи, но поскольку нам нужно записывать в транзакции, то нужно использовать процедуры ДО завершения транзакции, но уже имеющие ссылку на записываемый объект. ПередЗаписью() не подходит , так как ещё нет ссылки, а ПослеЗаписи() не подходит, так как транзакция уже завершена. Остаётся ПриЗаписи(), но перед нами встаёт выбор: модуля формы или модуля объекта? Поскольку обработчик события ПриЗаписи() модуля объекта не содержит параметр, содержащий ответ пользователя, а событие ПриЗаписиНаСервере() модуля формы содержит, то ответ очевиден-используем это событие ПриЗаписиНаСервере() модуля формы потому что:
1) Это событие выполняется в транзакции 2) Содержит параметр «ПараметрыЗаписи», в котором уже содержится ответ пользователя, который передался из процедуры ПередЗаписью() 3) Ссылка уже создана и можно создавать новый документ, используя эту ссылку.
Ну и теперь последовательность запуска событий (в том порядке, в каком они перечислены) и небольшие подробности :
Во многих обработчиках есть параметр «Отказ». Там, где этот параметр присутствует означает, что в этом обработчике ещё можно отказаться от записи, присвоив параметру «Отказ» значение Истина, и тогда запись произведена не будет. 1) Модуль формы ПередЗаписью(Отказ, ПараметрыЗаписи)
Выполняется на клиенте!
Этот обработчик следует использовать, если необходимо организовать диалог с пользователем перед тем, как записать объект. Запросить дополнительную информацию, предупредить о чём-либо, дать возможность отказаться и т.п.
Второй параметр этого обработчика «ПараметрыЗаписи» имеет тип «Структура». У документов эти параметры заполняются системой предопределенными параметрами РежимЗаписи, РежимПроведения. Можно добавить свои.
Эти параметры передаются между событиями формы ПередЗаписьюНаСервере, ПриЗаписиНаСервере, ПослеЗаписиНаСервере, где их можно благополучно использовать. Например, при записи регистра сведений, надо сделать запись в другой регистр сведений старое значение ресурса. Можно передать старое значение в эти самые параметры и уже в ПриЗаписиНаСервере сделать запись в другой регистр. 2) Модуль формы ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)
3) Модуль объекта ОбработкаПроверкиЗаполнения (Отказ, ПроверяемыеРеквизиты)
Эти два обработчика проверки заполнения реализуются через параметр «ПроверяемыеРеквизиты» типа Массив, содержащий реквизиты, которые надо проверять (т.е. которым установлено свойство проверки заполнения «Выдавать ошибку»)
И если из этого массива убрать реквизит, то проверяться он не будет, если добавить, то будет выполняться проверка заполнения.
Таким образом, можно сказать, что эти два обработчика событий предназначены :
Для включения в проверку заполнения тех реквизитов, у которых в свойствах «ПроверкаЗаполнения» указано «Не проверять». Для этого надо добавить этот реквизит в массив параметр «ПроверяемыеРеквизиты»
Для того, чтобы исключить из автоматической проверки реквизиты, у которых установлено свойство проверки заполнения «Выдавать ошибку» в зависимости от каких-то условий. Для этого надо удалить этот реквизит из массива параметра «ПроверяемыеРеквизиты»
Имеется несколько особенностей, которые необходимо учитывать:
Если у формы из которой записывается объект в свойствах не установлено «ПроверятьЗаполнениеАвтоматически», то тогда эти обработчики проверки заполнения не вызываются и проверки не происходят!
Вызываются только при интерактивной записи! При программной записи не вызываются. Для проверки нужно использовать метод объекта ПроверитьЗаполнение(), который инициирует запуск этих событий.
Для документов, имеющих возможность проведения , эти события проверки заполнения вызываются только при проведении!
Оба эти события выполняются на сервере, отличие в том, что ОбработкаПроверкиЗаполненияНаСервере() это событие модуля формы и, следовательно, есть доступ к данным формы. А ОбработкаПроверкиЗаполнения() - событие модуля объекта. 4) Модуль формы ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
В этом обработчике можно дозаполнять реквизиты объекта или провести дополнительные проверки. Есть доступ к данным формы. Есть параметр ТекущийОбъект.
Параметр ТекущийОбъект имеет тип класса «объект» в зависимости от типа записываемого объекта (СправочникОбъект,ДокументОбъект и т.д). Т.е. экземпляр класса объект создан, и можно обратиться к его свойствам и методам, но в базу данных ещё не записан. Начало транзакции 5) Модуль объекта ПередЗаписью(Отказ)
В этом обработчике можно дозаполнять реквизиты объекта или провести дополнительные проверки.
Для документов в параметры данного обработчика добавляются ещё два параметра:РежимЗаписи, РежимПроведения. Запись 6) Модуль объекта ПриУстановкеНовогоНомера(СтандартнаяОбработка, Префикс)
Возникает в момент, когда выполняется установка номера нового документа, задачи или бизнес-процесса.
Или ПриУстановкеНовогоКода(СтандартнаяОбработка,Префикс)
Возникает в момент, когда выполняется установка нового кода элемента справочника, узла плана обмена или кода плана видов характеристик.
Эти событии вызываются для объектов у которых указано свойство «Автонумерация» и только для новых объектов.
Если установить параметру СтандартнаяОбработка значение Ложь, то новый номер генерироваться не будет и можно программно задать код объекта в данном обработчике. 7) Модуль объекта ПриЗаписи(Отказ)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи.
Ссылка уже есть и можно записать в базу данных дополнительные данные на основании текущего объекта, используя эту ссылку.
Например, при записи создавать другой документ, содержащий реквизит ссылку на записываемый. 8) Модуль формы ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
Вызывается после записи объекта в базу данных, но до окончания транзакции записи. Есть доступ к данным формы. Есть последний шанс отказаться от записи.
Параметр ТекущийОбъект имеет тип класса «объект» в зависимости от типа записываемого объекта (СправочникОбъект,ДокументОбъект и т.д). Можно обратиться к его свойствам и методам. Завершение транзакции 9) Модуль формы ПослеЗаписиНаСервере(ТекущийОбъект, ПараметрыЗаписи)
Выполняется на сервере.
Можно использовать для того, чтобы визуально что-то отобразить на форме. 10) Модуль формы ПослеЗаписи(ПараметрыЗаписи)
Выполняется на клиенте!
Можно использовать для того, чтобы визуально что-то отобразить на форме или выдать предупреждение пользователю.
Событие При записи объекта вызывается всегда, когда объект записывается (интерактивно и программно). Обработчик этого события необходимо использовать для решения задач, которые связаны именно с записью объекта и не имеют отношения к интерфейсу.
Событие При записи формы объекта вызывается всегда, когда объект записывается в этой конкретной форме и вызывается оно расширением формы только при выполнении записи интерактивными командами или методом ЗаписатьВФорме(). Это событие необходимо использовать для решения задач, которые связаны с записью в конкретной форме.
ЗаписатьВФорме()
Возвращаемое значение:
Тип: Булево. Истина - объект записан; Ложь - в противном случае.
Описание:
Записывает объект, редактируемый в данный момент в форме.
Доступность:
Толстый клиент.
Для понимания особенностей записи и проведения документа в форме следует, прежде всего, разделять особенности записи самого объекта (ДокументОбъект) и особенности работы расширения формы. Расширение формы документа действует, если основной реквизит формы имеет тип ДокументОбъект. Оно обеспечивает специфическую функциональность формы при редактировании и записи документа. Задача расширения заключается в реализации удобного для пользователя поведения формы. Но собственно запись и проведение документа выполняет, разумеется, объект, являющийся реквизитом формы. Расширение документа обрабатывает различные команды пользователя, выполняет предварительные проверки и другие сервисные действия, а затем вызывает запись объекта. Запись объекта выполняется так же, как и если бы она вызывалась средствами встроенного языка. То есть с точки зрения объекта запись в форме и запись средствами языка ничем не различаются. Таким образом, расширение обеспечивает некоторую сервисную функциональность, обращаясь в конечном итоге к функциональности объекта. Следует учитывать, что расширение формы действует, только если используются механизмы формы и не действует, если выполняется обращение непосредственно к объекту. Например, если вызвать метод Записать() у объекта ДокументОбъект, то никакие действия расширения формы не будут выполняться. Чтобы они выполнялись нужно вызывать метод ЗаписатьВФорме().
Далее мы рассмотрим те сервисные действия, которые обеспечивает расширение формы документа. В данном разделе, мы опишем только те действия, которые специфичны именно для расширения формы документа и не будем касаться общих действий, которые поддерживаются расширениями всех объектов.
Установка даты документа
При открытии формы нового документа, если дата документа не установлена (равна значению типа Дата по умолчанию), то документу устанавливается рабочая дата. Следует заметить, что используется именно рабочая дата, а не текущая (если не установлено использование текущей даты в качестве рабочей). Это дает возможность пользователю настроить рабочую дату так, чтобы новые документы вводились определенной датой. При этом в качестве даты устанавливается начало дня (дата без времени), даже если в качестве рабочей даты выступает текущая дата. Но если свойство АвтоВремя имеет значение НеИспользовать, и рабочая дата равна текущей, то устанавливается текущая дата, вместе со временем. Таким образом, для варианта АвтоВремя = НеИспользовать при открытии берется рабочая дата (если она отличается от текущей) или текущая дата вместе со временем, а для остальных вариантов установка времени откладывается на момент записи документа.
При записи нового документа в форме если свойство АвтоВремя имеет значение отличное от НеИспользовать, и не используется оперативное проведение, и время документа пустое (0:00:00), то выполняется автоматическая установка времени на основании значения свойства АвтоВремя. Действие расширения формы в этом случае аналогично вызову метода УстановитьВремя() с вариантом выбранном в свойстве АвтоВремя и с использованием журналов документа.
Расширение формы так же предоставляет команды для установки времени документа в начало дня, конец дня, перед предыдущим и за последующим документом.
Установка режима записи
При нажатии кнопки "ОК", если для документа в метаданных разрешено проведение, документ записывается в режиме проведения.
Кроме того, расширение формы предоставляет две отдельные команды для записи с проведением и записи с отменой проведения.
При любой записи документа в форме, если установлено свойство расширения формы ПриЗаписиПерепроводить и документ проведен, то выполняется запись в режиме проведения. Это позволяет исключить ситуацию, когда пользователь изменит документ, а движения документа не будут обновлены.
Установка режима оперативного проведения
При записи документа в форме, расширение формы выполняет установку режима проведения (оперативное или неоперативное проведение). Установка выполняется по следующему алгоритму.
Вначале если свойство ИспользоватьРежимПроведения имеет значение Авто выполняется первичный подбор режима проведения из вариантов Оперативный, Неоперативный и Запрашивать.
Если у пользователя нет права на неоперативное проведение – используется оперативное проведение.
Если документ не проведен – используется оперативное проведение.
Если дата документа равна текущей, а время меньше или равно текущему, то используется режим Запрашивать. Здесь и далее в этой статье сравнение даты имеется в виду без учета времени, а сравнение времени описывается отдельно.
Если дата документа меньше текущей, то используется неоперативное проведение.
Если дата документа равна текущей и время больше текущего – используется оперативное проведение.
Дальнейшие действия системы определяются уже исходя из трех вариантов (Оперативный, Неоперативный и Запрашивать) установленных непосредственно в свойстве ИспользоватьРежимПроведения или на основании описанного алгоритма для варианта Авто.
Если дата документа меньше текущей, используется оперативный режим и у пользователя есть права на неоперативное проведение, то пользователю предлагается использовать неоперативный режим. Если пользователь отказывается, то запись документа отменяется.
Если дата документа меньше текущей, используется оперативный режим и у пользователя нет права на неоперативное проведение, то запись документа отменяется.
Если дата документа меньше текущей и используется режим Запрашивать, то в зависимости от наличия прав на неоперативное проведение или выбирается неоперативный режим (без запроса пользователя), или запись документа отменяется.
Если дата документа больше текущей и используется оперативный режим, то запись документа отменяется. Штатное поведение расширения формы не разрешает проведение документа завтрашней датой, даже если у пользователя есть права на неоперативное проведение. Это объясняется тем, что после появления документов проведенных завтрашней датой текущие остатки регистров используемых проводимыми оперативно документами перестают соответствовать реальным остаткам и механизм оперативного проведения для всех пользователей перестает работать адекватно.
Далее если используется режим Запрашивать, то пользователю выдается диалог с выбором режима проведения.
Полученный таким образом режим проведения (Оперативный или Неоперативный) используется при выполнении записи документа.
Проверка прав
При открытии формы документа, если документ проведен, а у пользователя нет права "Интерактивное изменение проведенных", то расширение переводит форму в режим ТолькоПросмотр.
При записи документа в форме выполняется проверка прав на интерактивное проведение и интерактивную отмену проведения в соответствии с текущим режимом записи.
Считывание движений
При открытии формы документа, если есть табличные поля, связанные с движениями (наборами записей) объекта редактируемого в форме, то эти движения считываются из базы данных и соответственно отображаются в табличных полях.
Слово "Микроскоп" кодируется в URL как: "%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D1%81%D0%BA%D0%BE%D0%BF"
Суть метода заключается в следующем:
Преобразование происходит в два этапа: сначала каждый символ кириллицы кодируется в Юникоде (UTF-8) в последовательность из двух байтов, а затем каждый байт этой последовательности записывается в шестнадцатеричном представлении:
М → D0 и 9C → %D0%9C
и → D0 и B8 → %D0%B8
к → D0 и BA → %D0%BA
р → D1 и 80 → %D1%80, и т. д.
Для пользователя:
Последовательность документов есть в УПП, УТ (8), ТиС, ПУБ (7). Операции – Проведение документов, на закладке «Восстановление последовательностей» приведены все имеющиеся в программе последовательности и указана дата актуальности каждой из них. То есть если в июне 2010 года мы видим такое:
то это плохо. Партионный учет давно неактуален, значит – все значения себестоимости, которые появляются в отчетах, врут. (Учет кадров и налоговый учет УСН в данной базе не ведется).
Что значит последовательность? Строго говоря, одним из правил учета является его оперативность, т.е. отражение хозяйственных операций по мере их возникновения. 1 июня на склад поступило 10 штук товара А, потом 10 июня продано 8 штук. Если проводить эти документы (Поступление товаров и услуг, Реализация товаров и услуг) строго в хронологическом порядке, то последовательность установится сначала на 1 июня, потом на 10 июня. Т.е. ее граница будет сдвигаться вперед каждым документом, и итоги (количество, сумма, себестоимость) будут актуальными на каждый момент времени. Если же потом, задним числом, провести еще один документ (Реализация товаров и услуг) от 8 июня, которым будет оформлена реализация 7 штук товара А, программа дает это сделать беспрепятственно. Граница последовательности при этом установится на 8 июня, на этот документ. То есть информация ДО ввода этого документа верна, а ПОСЛЕ – уже нет. При восстановлении последовательности (перепроведении документов, входящих в последовательность), документ от 10 июня проведен не будет, потому что нет необходимого количества товара А. Далее пользователь должен искать причину этой ошибки, устранять и восстанавливать последовательность заново.
Как часто восстанавливать последовательность? Как минимум – перед выполнением регламентных операций, формированием значимых отчетов и т.п. Поскольку любое перепроведение документа (относящегося к последовательности) сдвигает ее границу, имеет смысл закрывать для редактирования прошлые периоды (Сервис – Установка даты запрета изменения данных).
В Бухгалтерии последовательности нет (за исключением кадровых приказов – в 8.1), но есть возможность автоматического перепроведения документов за период. Перед закрытием месяца это делать необходимо (Операции – Проведение документов). Для программиста: Последовательность – объект метаданных 1С – предназначена для упорядоченного хранения множества документов согласно дате и времени.
Граница последовательности (ГП) – позиция, последнего введённого документа в последовательность. Если после ГП есть другие документы в последовательности, то последовательность считается нарушенной и её необходимо восстановить.
Логически - последовательность можно условно представить как «Общий» журнал документов входящих в эту последовательность. Условно, потому, что на последовательностях строится логика учета.
У некоторых последовательностей, для дополнительного контроля автоматически при движении регистров, отслеживается связь: регистр – последовательность. Если изменился регистр, должна измениться и последовательность.
Физически – последовательность состоит из двух таблиц:
1. Таблица регистрации;
2. Таблица границ.
Таблица регистрации (ТР) – коллекция зарегистрированных в последовательности документов в разрезе измерений. В случае повторной записи документа сначала удаляется старая запись, затем записывается новая.
Таблица границ (ТГ) – хранит границу последовательности в разрезе измерений, одно измерение – одна запись если измерений нет, то у ТГ одна запись. Запись ТГ показывает, какой документ в ТР является последним правильно проведённым, т.е. не нарушившим правильное ведение учёта.
Обе таблицы идентичны по составу колонок: «Период», «Регистратор», «Измерение».
Восстановить последовательность возможно путём простого программного переноса ГП (если вы уверены, что итоги не нарушены) на последний документ в последовательности или повторным, последовательным проведением всех документов от ГП до последнего по времени документа в последовательности. Для исправления последовательности существует штатная обработка «Проведение документов».
Механизм «последовательность» имеет подчинённые объекты, свойство – измерения.
Измерения – это разрезы последовательности. Измерения, условно разбивают последовательность на несколько логически целых частей.
Измерение позволяет, в случае необходимости, перепроводить не все документы, входящие в последовательность, а только те которые содержат данное измерение, что ускоряет скорость работы при восстановлении последовательности.
Измерения повышают производительность системы в целом, так как при записи и проведении захватывается не вся таблица целиком, а только те её строки, которые соответствуют данному измерению.
Регистрация документа в последовательности, т.е. в ТР, производится в момент его записи.
Регистрация документа в последовательности может осуществляться автоматически, под руководством системы, если свойство «Заполнение последовательностей» документа будет установлено в «Заполнять автоматически» если иначе, то сам разработчик описывает правила регистрации.
Запись в ТГ происходит при проведении документа.
При проведении документа, его движения учитываются в:
· «Оперативном учёте» - записывает движения документа в регистрах;
· «Бухгалтерском учёте» - запись проводок.
ПоследовательностьМенеджер.< ИмяПоследовательности > - Данный менеджер предназначен для управления последовательностью:
Последовательность.«ИмяПоследовательности».Восстановить
Последовательность.«ИмяПоследовательности».ПолучитьГраницу
Последовательность.«ИмяПоследовательности».ПолучитьГраницы
Последовательность.«ИмяПоследовательности».Принадлежит
Последовательность.«ИмяПоследовательности».Проверить
Последовательность.«ИмяПоследовательности».СоздатьНаборЗаписей
Последовательность.«ИмяПоследовательности».УстановитьГраницу
Вся работа «ПоследовательностьМенеджер» складывается из анализа и работы с ТР и ТГ. Например, метод «Проверить» - если документ в ТГ, есть последний в ТР, значит, последовательность не нарушена и наоборот и т.д. Что такое Последовательности Документов
Для набора данных «Объект» используется для передачи в СКД внешних данных, таких как таблица значений, результат запроса. Для этого набора данных доступны описания полей, а также название объекта, которые будет передан в СКД:
Описание полей набора данных
После определения, какого вида мы набор данных используем, следует внести описание полей для данных, выводимых в отчет:
В таблице «Поля» заполняются свойства:
1. «Поле» - имя поля, в случае запроса заполняется автоматически, в случае набора данных «Объект» определяется вручную.
2. «Путь» - указывается путь к данным из набора. Именно это название, указанное в этом поле будет фигурировать во всех дальнейших настройках СКД.
3. «Заголовок» - строка с заголовком поля, которые выводится в отчет или в настройках
4. «Ограничение доступности поля» - ряд галочек – настроек, служит для указания того, как данное поле не может быть использовано в настройках. Возможно, указать такие ограни-чения
a. «Поле» - поле нельзя использовать в выборках СКД
b. «Условие» - поле нельзя использовать как условие
c. «Группа» - запрет на использование поля в группировках
d. «Упорядочивание» - запрет использовать поле в сортировках
5. «Ограничение доступности полей-реквизитов» - ряд галочек ниже, указывает на ограничения для реквизитов поля, смысл установки данных ограничений такой же что и в для поля
6. «Роль» - обозначает дополнительные свойства поля и его взаимоотношения с другими полями. Для редактирования ролей открывается специальный диалог:
a. «Без роли» - никаких особых «нагрузок» на поле не накладывается, режим по умолчанию для большинства полей
b. «Период» - содержит номер периода, если поле имеет тип периода. Самый младший период должен иметь тип 1. Например, в запросе рассчитываем итоги по различным периодам: ПериодСекунда = 1, ПериодДень=2, ПериодНеделя=3 и т.д. Данный номер будет указывать, как в СКД рассчитывается итоги по полям остатка.
c. «Дополнительный» – указывает на то, что поле–период не является обязательным
d. «Счет» - указывает на то, что поля является бухгалтерским счетом, используется для рас-чета бухгалтерских итогов.
e. «Вид» - строка выражение, с помощью которого рассчитывается вид счета. Результатом выражения должно быть значение перечисления ВидСчета (Активный, Пассивный, Активно/Пассивный), либо число. Значение числа 0 соответствует активному счету, 1 – пассивному, 2 – активно-пассивному. Выражение записывается на языке выражений системы компоновки данных. Данная информация используется при расчете по полям бухгалтерских остатков;
f. «Остатки» – признак того, что поле является полем остатка;
g. «Имя» – строка, содержащая имя группы полей остатка. Например: "Сумма", "Количест-во";
h. «Тип» – тип остатка (НачальныйОстаток, КонечныйОстаток, Нет (поле не является остат-ком));
i. «Бух. Тип» – тип бухгалтерского остатка (Дебет, Кредит, Нет (поле не является бухгалтерским остатком));
j. «Поле счета» – имя поля-счета, для которого рассчитываются остатки;
k. Игнорировать значения NULL – если установлено, то в результат не нужно включать групповые записи по данному полю в случае, если поле содержит значение NULL.
l. «Обязательное» - при выполнении запроса поле с указанным флажком будут присутствовать всегда, даже если не были выбраны в выборке.
7. «Выражение представления» - содержит выражение, которое используется при выводе зна-чений поля в отчет.
Например нужно преобразовать дату в особый формат для этого указываем такое выражение «Формат(ПериодПолугодие,"ДФ = '""Полугодие с"" дд.ММ.гггг""'")» или ссылку на документ преобразовать к произвольному виду: ««Дата: »+Ссылка.Дата+«Номер: »+Ссылка.Номер».
8. «Выражение упорядочивания» - как упорядочивать это поле. При редактировании открывается диалог:
В диалоге можно указать, как данное поле упорядочивать. «Выражение» - как упорядочива-ется это поле, «Тип упорядочивания» - «по возрастанию» или «по убыванию», «Необходи-мость автоупорядочивания» – автоматическое определение полей, по которым необходимо упорядочивать результат компоновки данных.
9. «Проверка иерархии» - используется, в случае если нужно формировать нестандартные отборы.
a. «Набор данных» – набор данных для проверки иерархии;
b. «Параметр» – параметр, в который будет подставляться значение, для которого нужно получить дочерние элементы;
10. «Тип значения» - уточнение типа значения поля набора данных, полезно использховать для уточнения полей составного типа
11. «Оформление» - параметры оформления поля набора данных. При редактировании открывается диалог:
Можно задавать следующие параметры:
Цвет фона - Определяет цвет фона в ячеках
Цвет текста - Определяет цвет текст в ячейках
Цвет в диаграмме - Определяет цвет линий в диа-грамме
Цвет границы - Цвет линий границы
Стиль границы - Типы линий границы
Стиль границы слева - слева
Стиль границы сверху - сверху
Стиль границы справа - справа
Стиль границы снизу - снизу
Шрифт - Вид шрифта, толщина, наклон и т.д.
Отступ - Количество знаков отступа
Авто отступ - Количество знаков отступа, применяется в группировках
Горизонтальное положение - Положение текста в ячейке по горизонтали
Вертикальное положение - Положение текста в ячейке по вертикале
Размещение - Размещение текста который не помещается в ячейку
Ориентация текста - Ориентация текст в градусах (90-поворот перпендикулярно)
Формат - Форматная строка значения
Выделять отрицательные - Признак того чтобы выделять отрицательные значения
Минимальная ширина - Минимальная ширина ячейки в пунктах
Минимальная высота - Минимальная высота ячеки
Максимальная высота - Максимальная высота
Текст - Текст который выводится вместо значения
Для проверки наличия подчиненных записей элемента справочника можно пользоваться запросом, аналогичным представленному:
В данном примере ссылка элемента, для которого необходимо проверить наличие дочерних элементов, записывается в параметр запроса "Родитель". После выполнения такого запроса необходимо проверить результат на пустоту. Если результат не пустой, то подчиненные записи есть. Иначе - нет :
Если такое происходит, обратите внимание на следующее:
Посмотрите, какой режим восстановления (Recovery) стоит на закладке Options в свойствах базы данных. Он бывает Simple (простой, который требует наименьшего администрирования) или Full (полный, который обеспечивает наилучшую возможность восстановления данных после сбоя). В режиме Full возможен рост журнала транзакций (LDF), поскольку изменения базы данных накапливаются в этом журнале.
Уменьшение журнала транзакций зависит от операции резервного копирования (backup): если не делать резервное копирование, то лог транзакций в режиме Full будет расти.
Обратите внимание на пункт контекстного меню "Shrink Database" (shrink - англ. усадка, усушка, уменьшение). Эта операция уменьшает размер базы данных путем "удаления неиспользуемых страниц" ("remove unused pages").
В свойствах базы данных есть опция "Auto Shrink", которая активизирует автоматическое уменьшение базы, во время периодических проверок неиспользуемого места ("during periodic checks for unused space").
Для базы данных предприятия в свойствах базы я установил опцию Full Recovery. На этой же закладке я установил флажок Auto Shrink. Базу надо периодически архивировать, для чего я настроил автоматическое архивирование базы данных (каждое утро) и журнала транзакций (каждые 10 минут).
Режим восстановления базы данных:
Режимы восстановления базы данных (recovery models) баз данных SQL Server 2005, полное протоколирование (full), неполное протоколирование (bulk-logged), простая модель восстановления (simple)
Одно из важных решений, которые нужно принять при создании базы данных — в каком режиме восстановления будет работать база. Этот параметр выбирается на вкладке Options свойств базы данных в строке Recovery Model (Режим восстановления) (над списком остальных параметров). Изменить режим восстановления базы данных можно также при помощи команды A_lter DATABASE.
Всего предусмотрено три режима восстановления базы данных: Full (режим полного протоколирования) — в этом режиме максимальное количество операций записывается в журнал транзакций. Журнал транзакций автоматически не обрезается. Этот режим обеспечивает максимальные возможности восстановления (за счет снижения производительности). Только в этом режиме вы можете использовать зеркальное отображение баз данных и автоматическую доставку журналов (log shipping). Именно этот режим выбирается по умолчанию для пользовательских баз данных, поскольку он настроен для базы данных model. Если изменить режим восстановления для базы данных model, то для создаваемых баз данных по умолчанию будет выбираться новый режим.
Bulk-logged (режим неполного протоколирования) — это компромисс между требованиями производительности и возможностями восстановления. При использовании этого режима запись в журнал практически отключается (в терминологии Microsoft — проводится минимальное протоколирование) для операций следующих типов:
- массовой вставки (команды BULK I_nsert, S_elect INTO, загрузка средствами bcp и т. п.);
- вставка/изменение больших двоичных данных (text, ntext, image);
- операции по созданию, перестроению и удалению индексов.
Автоматическая перезапись журналов транзакций при этом не производится, работа с транзакциями, не включающими в себя перечисленные операции, производится как обычно.
При работе в этом режиме вы лишаетесь возможности использовать журнал транзакций для восстановления (при утрате файлов данных, на момент времени или на метку транзакции), если в нем была хотя бы одна запись о перечисленных ранее операциях. Microsoft рекомендует не использовать этот режим восстановления на постоянной основе, а переключаться в него из режима Full на время выполнения больших операций массовой вставки, а потом возвращаться обратно.
Simple (простая модель восстановления) — максимальный выигрыш в производительности и удобстве работы за счет возможностей восстановления. Минимально протоколируются те же операции, что и в режиме восстановления Bulk-logged, а кроме этого, журнал транзакций автоматически очищается (блоками, размер которых изначально равен 256 Кбайт, но при необходимости он может быть автоматически увеличен). В результате вы получаете максимальную производительность и возможность не думать о потенциальной нехватке места в журнале транзакций. Но в этом режиме использовать журнал транзакций для восстановления уже не удасться. Вы не сможем даже выполнить резервное копирование журнала транзакций: команда BACKUP LOG в этом режиме сразу вернет ошибку.
Какой же режим восстановления выбрать?
Microsoft (в своих учебных курсах) рекомендует для рабочих баз данных выбирать только режим Full. Однако из опыта проведения автором этих самых учебных курсов и общения со слушателями можно сказать, что очень многие опытные администраторы сознательно настраивают для своих баз данных режим восстановления Simple. Значительное повышение производительности при операциях массовой вставки и при работе с большими двоичными данными вполне оправдывает некоторое снижение возможностей резервного копирования и восстановления. Что важнее для вашей задачи — дополнительные возможности восстановления или максимальная производительность, решать вам. Рост журнала транзакций в 1С MS SQL Server
Для работы с текстовыми документами существуют три типа данных – ТекстовыйДокумент, ЗаписьТекста и ЧтениеТекста. Разница двух подходов состоит в способе загрузки документа: ТекстовыйДокумент загружает файл целиком и далее построчно обрабатывает его; ЗаписьТекста и ЧтениеТекста загружают файл построчно.
ПРИМЕР 1: Запись данных справочника в текстовый файл:
С помощью типа ЗаписьТекста этот код будет таким:
Чтение данных из текстового файла в справочник:
С помощью типа ЗаписьТекста этот код будет таким:
ПРИМЕР 2:
В строке текста значения реквизитов справочника разделяются символом кавычка. Его можно получить, например, используя функцию Символ(34).
В случае если символ разделителя (в данном случае – кавычка) может встречаться в выгружаемых данных,
перед помещением в строку меняем этот символ на заранее определенную комбинацию символов.
В нашем случае это %квч%.
Управление регистрацией документа в последовательности документов 
Необходимость работы с этим форматом на уровне платформы обусловлена не только тем, что это «модный современный» формат, который прикладные решения 1С:Предприятия сами по себе могут использовать для интеграции со сторонними приложениями. Другая причина заключается ещё и в том, что JSON активно используется в HTTP интерфейсах. А в 1С:Предприятии как раз есть такие механизмы, в которых хочется использовать этот формат. Это REST интерфейс приложения, автоматически генерируемый платформой, и HTTP-сервисы, которые вы можете создавать самостоятельно..gif)
