Как хранить ТЗ в конфигурации ? или нужен толковый совет... #294941

Даже не знаю как спросить то толком. Сам уже думаю думаю, есть какие-то варианты, но пока не очень они мне нравятся. Вообщем так: Имеется 5 зон, в каждой зоне может быть до 25 рядов, в каждом ряду до 50 мест. Нужно все это как-то хранить в конфигурации... Для упрощения задачи можно принять, что заранее нам известно и кол-во зон, и кол-во рядов в каждой зоне и кол-во мест в каждом ряде (хотя практически эти данные переменны). Т.е. данную задачу можно сравнить, например, с развлекательным центром, где есть 5 кинотеатров(зоны). Вот как это сохранить в конфигурации для дальнейшего использования? Дальше оператор быдет указывать, какое место занято, чем занято и т.д. 1С в свою очередь должен предоставлять отчет о занятых/свободных местах в каждой зоне. Пока наиболее подходящим решением вижу использованием ТЗ, где колонки - ряды, строки - места. Значения - занято/свободно/нет. Но ТЗ тоже как-то надо хранить... не очень то хочется зранить его отдельно от базы, т.к. при архивировании базы, ТЗ пропадет...( Есть какие-нибудь идеи?

справочник

Я бы создал справочник, и заполнил его программно... Значения Занято/Свободно/Нет - периодический реквизит справочника, тип перечисление

Это самая первая мысль и у меня была. Но не нравится она мне чего-то.... Почему? Ну а если будет 10 зон, по 20 рядов по 50 мест в каждом месте... получим 20*50*10 = 10 тыщ элементов справочника.... и каждый раз программно заполнять значениями? блин как-то не нравится...   И это, самое главное, неудобно очень будет... поскольку в справочнике будут группы и подгруппы, т.е. 3 уровня.... Зона-Ряд-Место.... Муторно. А таблица вот она - квадратная как на ладони, 1 таблица - одна зона.... И заполнять очень удобно... Думаем дальше. Вариант 1: Справочник. (вариант не очень) Вариант 2: ....?

вот пришла мысля - а что если ТЗ хранить во внешнем DBF-файле? я когда так делал: в одной конфе была куча изменяемых настроек, так вот чтоб не плодить справочники с периодич.реквизитами, записывал в DBF-файл

Храни в справочнике заполняй в таблице. Не надо придумывать велосипеды.

А если в документе? Количество (хотя бы максимальное) рядов заранее известно?

+ Собственно, табличная часть документа и есть ТЗ.

(6,7) и чем это сильно отличается от справочника?

С ДБФ сложновато будет делать архивы, да и вообще использовать внешнее хранилище - не самая хорошая идея

+ Из справочника легко можно сделать ТЗ, используя самый обычный Запрос

Регистр сделай, измерения зона, ряд, место, ресурс занято. Когда занимаешь - движение приход 1, когда освобождаешь - расход. Берешь итог с фльтром зона, выгружаешь в ТЗ, да и все...

Вся таблица в одном объекте. Таки да, но движения регистров ведь к документам привязывать надо.

опа... че-то в голову сразу не дало...) А ведь вариант хороший + врхивирование будет происходить. Надо обкумекать... Спасибо за идею. лучше действительно во внешнем dbf, чем в справочнике...наверное. не совсем понял.... думаю не покатит. Да кол-во рядов известно, но теоретически с течением времени может меняться. почему? дбф будет автоматически архивироваться даже штатным архиватором 1С. Конфа на основе компоненты бух. Самописная. Делаю с нуля. В принципе мне ничего не стоит добавить регистр. Но вот пользователю придется уже покупать 2 компоненты(накладно). А так, спасибо! Идея заслуживает внимания... разве? там же разные регистры есть...

Я за связку документ + регистр

не выгодно материально...

Сделай на счетах, если регистры не нравятся

Можно количество колонок в документе взять с запасом, а в реквизитах шапки текущее количество рядов указывать, и по нему видимостью колонок управлять.

Вообщем, пока 2 наиболее подходящих варианта. Справочник и ТЗ(внешний dbf). Итак Справочник vs dbf: 1. Справочник 3 уровня. Зона-Ряд-Место. Допустим есть 10 зон, по 10 рядов, по 10 мест. Итого в зоне 1000 мест, соответственно в справочнике 1000+10+1 = 1011 элементов. Итого в справочнике 10110 элементов. Реквизиты - Наименование,Код,Состояние.   Внешние дбф: 10 файлов(таблиц) по 10 столбцов и 10 строк, тип число 1,0. 1)Чтобы занести в базу, например, 3 зона, 5 ряд, 7 место - "Занято" или "Свободно" нужно: Найти "Зона 3", в ней найти "ряд №5", там уже найти "место №7" и только потом записать. В то время для дбф нужно открыть нужный дбф по номеру, перейти на нужную строку и столбец... Тут понятно, лучше дбф. 2)Но, мне еще нужно знать для чего место предназначено. Т.е. в справочник добавится реквизит "НазначениеМеста", а вот как поступить с ДБФ??? Тут у меня такая мысля: создаю справочник "НазначениеМеста", в нем указываются возможные значения(например, "Запчасти" с кодом "01"). Теперь в ДБФ я буду хранить такие значения: "0"- места нет вообще "001" - свободное место для хранения запчастей. "101" - занятое место для хранения запчастей. и т.д. Взлетит? ) Думаю должно....)

глупа брать 100 колонок для запаса. Если будет использоваться всего 5, например....

хм.... интересное предложение. Счета в конфигурации не используются. Если сделать например 5 счетов... Счет "1" - 1-я Зона... Но все равно придется тогда два(или 1 если иеархический)справочника делать - "Ряд" и "Место", чтобы аналитика была... и заюзать бухитоги.... Чтобы посмотреть свободные места по зоне, надо смотреть СКД(СКК) по всем Субконто... муторно ИМХО. Но в принципе тоже вариант...

Кодируй справочник по схеме Зона_ряд_место на забалансовом счете Места. В наименование справочника добавить предназначение. Иерархию убрать.

Блин... я уже про дбф думаю:))) Вот еще и про кодирование мыслю подкинул...) Но если использовать "кодирование", зачем нужны тогда счета ? )))0 Можно создать 1-уровневый справочник с дополнительными реквизитами "Состояние" и "Назначение", наименование элементов кодируется по схеме "Зона/Ряд/Место"... Вот это уже интересней.... Может действительно так?

Наличие счета позволяет воспользоваться функциями контроля остатков на определенную дату, например. Хотя и справочника зачастую достаточно

какие остатки...? ) У меня либо свободно, либо занято... Короче, спасибо за идею с кодированием. Сейчас еще раз обдумаю и наверное все-таки выберу справочник.

"наименование элементов кодируется по схеме "Зона/Ряд/Место" " А просто реквизиты "Зона", "Ряд", "Место" не менее геморно будет?

а фиг знает... я уже запутался...) Ну а если реквизиты "Зона", "Ряд", "Место".... то какое наименование будет? А если просто ТЗ сохранять во внешнем файле с расширением *.DBF ?

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

2 субконто - место Место занято - плюсуешь 1 по этому счету с выбранными субконто, освободилось - вычитаешь. Всегда типовыми механизмами получишь

есть компонента binarydata. с помощью нее удобно ТЗ хранить в строке неограниченной длины. Сделай по 1 строке для каждой зоны. Как минус - не сможешь строить к ним запросы стандартными средствами, как в случае использования справочника

как плюс - у тебя может быть совершенно разная размерность массива в каждой зоне

Если уж на то пошло, есть типовая функция ЗначениеВСтроку, но неудобно совершенно.

Скорость работы надо тестировать, а не предпологать "взлетит" - "не взлетит" Я бы проверил такой вариант. 1)Спр. "Зона" с реквизитами "КоличествоРядов", "КоличествоМестВРяду" 2)Спр. "Ряд" подчиненный спр. "Зона" 3)Спр. "Место" подчиненный спр. "Ряд" с реквизитом "Назначение" и  уст. флагами "Сортировка", "Отбор По Реквизиту".

Забалансовый счет. Субконто: Зона, Ряд, Место. К-во.. сумма.. ну, вы поняли..

лажа... Документ и все в ажуре

Создаешь справочник для залов. Указываешь имя зала, структуру зала (сколько рядов, мест в ряду) создаешь документ. Реквизиты табличной части: ряд, место, статус (занято, не занято). Реквизит шапки: Зал На каждый сеанс делай один документ. Также создай отчет. который, на основании одного документа (считай сеанса) показывает какие места заняты, какие нет. тут же менял статус если надо ... я бы так сделал

to 32, это не прокатит, 1с не даст создать такую структуру

+1

А назначение места? что за компонента? не слышал о такой. Можно сцылочку... дело в том, что в каждом ряду в пределах одной зона кол-во мест различно...А на счет скорости ты прав... Поэтому, собственно и ищется наиболее подходящий вариант удобство/надежность/скорость.

To 36. Недооценка возможностей 1С. Позволяет. Пример рабочего кода заполняющего ряда и места для одной зоны: Пример кода заполнения справочника "Зона"

Не очень удобно заполнять оператору такой документ. Каждый раз указывать ряд 1, ряд 2... Вместо того чтобы один раз это указать. Т.е. я пока с сохранением не определился, а вот с вводом да. Ввод осуществляется следующим образом. На основании данных: кол-во рядов, макс. кол-во мест в ряде, выводится таблица для этой зоны. Обычная 2-мерная таблица, гдн по оси Х - ряды, по оси Y - места. Короче стандартная таблица, широко используемая... Теперь оператору достаточно два клика на ячейке (X,Y), что бы указать, что ряд X, место Y занято, и занято тем и тем. ИМХО самый оптимальный вариант занесения данных. Оператор видит перед собой сразу все ряды и места. Э эта таблица есть не что иное, как графическое представление ТЗ. Т.е. я буду работать с ТЗ. Остался один главный вопрос, как это ТЗ хранить в базе.... Варианты здесь уже описаны: 1) справочник, 2)внешний дбф, 3)счета, 4)ТЗ во внешнем файле. Хотелось бы услышать, чем вам не нравится внешний дбф(ТЗ)? плюсы и минусы...

Задачу можно реализовать средствами 1С, но ИМХО лучше использовать другое приложение.

Ход мысли правильный, только разгляди получше , - дело говорит. Справочник Структура залов: Регистр Сеанс - Зал - ряд - место - Статус места, Документ, прописывающий регистр. Обработка с объектом "Таблица" для оператора, отображающая свободные места и выписывающая и проводящая сама документы по "тычку" оператора в свободное место. Справочник "Места" (элементы-места со всеми характеристиками, вплоть до цены) : Регистр Сеанс - Справочник - Статус места все остальное то же. Еще совет, - посмотри, как сделаны конфы по гостиничному бизнесу.

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