INFOSTART EVENT 2018 EDUCATION

Второй тур голосования за доклады.
Окончание 5 сентября.

Князьков Алексей | Ведущий программист | BIA-Teсhnologies, LLC

«Про ТабДок или TabDoc Pro»

- киллерфича или нет? - оптимизация формирования отчетов (с примерами и табличками) - оптимизация сохранения (тоже с примерами и замерами) - варианты применения (хранение настроек, построение интерфейсов, экспорт/импорт и т.д.) - проблемы: чего не хватает, ошибки платформы

Несколько табличных частей в 1С:7.7 - это просто

Программирование - Практика программирования

2
При программировании на платформе V7 достаточно часто возникает задача создать несколько табличных частей документа (или справочника). Традиционно эта задача имеет несколько решений..

При программировании на платформе V7 достаточно часто возникает задача создать несколько табличных частей документа (или справочника). Традиционно эта задача имеет несколько решений:

1. Хранение нескольких табличных частей в одной. Данный метод имеет только один плюс, "1С-совместимо". Основной недостаток – часто разные табличные части сильно отличаются форматом и составом полей;

2. Хранение дополнительной информации путем "сворачивания" данных в строку. Никаких плюсов метод не имеет. Минусы очевидны: возможное нарушение ссылочной целостности;

3. Хранение табличных частей вне информационной базы. Как и в предыдущем способе гарантировать, что восстановленная ссылка будет корректной, нельзя;

4. Наконец есть правильный способ – хранение табличных частей в служебных документах.

Этот последний способ позволяет:
* делать практически неограниченное число табличных частей,
* избавиться от задач отображения таблицы значений,
* конфигурации остаться 1С-совместимой,
* трудозатраты на создание табличной части в типовом случае составляют около 5 минут,
* ссылочная целостность отрабатывается системой.

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

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

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

Далее, в табличной части этого документа создаем необходимые реквизиты. Даже те, которые не должны отображаться. В поле "Синоним" указываем то название, которое должно отображаться в колонке. На рисунке 1 имеется реквизит табличной части "ОбъемПриДаннойТемп", который в колонке таблицы будет отображаться как "V при tc".

В поле "Комментарий" можно указывать команды форматирования таблицы (необычная фича, да? ;-). В данном случае задается ширина колонки таблицы, 11 единиц. Сейчас у меня поддерживается несколько таких команд:

- "Ширина=ХХХ;" – установить ширину в ХХХ,
- "Скрыть;" – скрыть колонку,
- "Иконка;" – отображать иконки в колонке.

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

Рисунок 1. Реквизит служебного документа.

После этих операций можно смело утверждать, что с форматированием отображаемой таблицы мы справились.

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


Рисунок 2. Связь главного и служебного документов.

В форму "главного" документа добавляем таблицу значений, при помощи которой будем отображать дополнительную табличную часть, и три кнопки – стандартные "добавить-редактировать-удалить". При желании можно определить и другие операции со строками дополнительной табличной части – копировать строку, и т.д.


Рисунок 3. Будущая табличная часть.

Теперь нужно вставить необходимый код в глобальный модуль (см. конфигурацию-пример).

Для манипуляций с табличной частью в родительский документ необходимо добавить всго лишь три строки:

Процедура ПриОткрытии()
   глХранилищеОткрыть(Контекст,ХранилищеПотери,ТаблицаПотерь);
КонецПроцедуры

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

При открытии происходит форматирование таблицы и заполнение её данными.

При закрытии происходит попытка удаления служебного документа (при необходимости). Второй параметр такой же, как и в первой функции:

Процедура ПриЗакрытии()
   глХранилищеУдалить(Контекст,ХранилищеПотери);
КонецПроцедуры

Ну и собственно сохранение табличной части. Параметры такие же как и в первой процедуре:

Процедура ПриЗаписи()
   глХранилищеСохранить(Контекст,ХранилищеПотери,ТаблицаПотерь);
КонецПроцедуры

Готово. Ну, за исключением ввода данных в таблицу. Для этого я позаимствовал из типовой конфигурации ИТРП универсальную процедуру ввода в таблицу значений (см. пример). Можно взять какую-нибудь другую универсальную процедуру ввода данных в ТЗ, или написать свою собственную – кому как больше нравится.

Вот и все… Восьмерка лишается одного из своих основных козырей?

Источники:
* Владимир Камышников aka Tazoth // icq: 261515707 // тел: 518-32-16
* hare.ru // vladimir__@e-mail.ru
* tazoth.ru // tazoth@tazoth.ru // tazoth@e-mail.ru // январь 2003 г.
* mista.ru/articles1c/hare/article.74.html

Смежная публикация:
* infostart.ru/public/15672

2

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

Наименование Файл Версия Размер
multitable-sample.zip
.zip 16,48Kb
30.04.18
6
.zip 16,48Kb 6 Скачать

См. также

Комментарии
Сортировка: Древо
1. M_W_W 8 01.05.18 11:42 Сейчас в теме
Ну, да... Этим способом давно уже пользуюсь, только еще, служебные документы записываю датой основного документа минус 50 лет назад, что-бы в общем журнале "под ногами не путались" и не вызывали у пользователей лишних вопросов. Потому, что "не должен принадлежать никакому журналу" это хорошо, но из общего журнала то его не уберешь. Ну и при установке/отмене пометки удаления, не забывать про служебный документ, доработать соответствующие процедуры.
2. bulpi 131 01.05.18 11:52 Сейчас в теме
"2. Хранение дополнительной информации путем "сворачивания" данных в строку. Никаких плюсов метод не имеет. "

Имеет. Минимализм. "Не плоди сущностей сверх необходимого"
3. Gkmy 27 02.05.18 08:10 Сейчас в теме
(2)
Имеет. Минимализм. "Не плоди сущностей сверх необходимого"
имеет/не имеет - суждение спорное, к тому же не моё; в зависимости от задачи имеет как плюсы, так и минусы,.. обсуждать которые здесь нет смысла.. если желаете, то создайте на форуме отдельную тему.
4. Gkmy 27 02.05.18 08:42 Сейчас в теме
5. puh 18.05.18 22:23 Сейчас в теме
Восьмерка не лишается своего козыря. Недостаток данного способа в 7.7 - отсутствие единой транзакции в случае проведения документа. Если проведение завершается неудачей, то не забудьте откатить данные во вспомогательной табличной части, т.к. запись основных данных документа уже откатилась и пользователь может выйти без сохранения. И это можно решить, но не без заморочек.
6. фокусник 24 30.05.18 11:14 Сейчас в теме
Хорошая доработка примера из Методической конфигурации с диска ИТС. Только я согласен с Михаилом (5). Те же процедуры перенастрой для сохранения табличных частей в одном родительском документе. Работы на полтора два часа. Лучше эти процедуры сделать универсальными под текущую схему и под новую. Один доп. реквизит о наименовании ТЗ и всё. Конечно придется отказаться от стандартного выведения табличной части. И с конвертацией проще потом, и с удалением документов, и с транзакциями, и с изменением даты. У нас основная проблема была с переносом документов из филиальных баз в центральную, и с префиксами воевали, и с изменениями дат. А у нас в подчиненных документах распределение зар. платы по узбекам на строительных объектах было. У меня из программиста чуть плов не сделали.
Оставьте свое сообщение