Несколько табличных частей в одном документе в 7.7 #380143

Вот придумал концепцию организации нескольких табличных частей в одном документе. Так чтобы не пострадал контроль ссылочной целостности и чтобы не лепить на форму ТЗ. Вот хочу поделиться, удачна ли вообще моя реализация этой идеи?

Вот придумал концепцию организации нескольких табличных частей в одном документе. Так чтобы не пострадал контроль ссылочной целостности и чтобы не лепить на форму ТЗ. Вот хочу поделиться, удачна ли вообще моя реализация этой идеи?

Вот придумал концепцию организации нескольких табличных частей в одном документе. Так чтобы не пострадал контроль ссылочной целостности и чтобы не лепить на форму ТЗ. Вот хочу поделиться, удачна ли вообще моя реализация этой идеи?

Ну давай выкладывай. В свое время сделал это на 1С++, через Табличное поле(ТР)

не лепить на форму ТЗ? а во что выводить данные? ссылочная целостность прекрасно работает на подчинённых документах, данными из которых заполняются ТЗ на форме. у меня есть разработки (конфигурация) в документах по 5-6 табличных частей

Трехколесный велосипед с вращающимися в разные стороны взаимноперпендикулярными коресами с разным числом углов?

без всяких плюсов. Во-первых, продумываем колонки наших табличных частей. Выявляем одинаковые колонки всех табличных частей. Одинаковые по типу, но не по названию колонки. Если в разных таб. частях используются справочники разных типов. То колонкам присваиваем тип Справочник.НеопределенногоВида и считаем колонки одинаковыми. Во-вторых, на уровне метаданных в таб. часть нашего документа добавляем реквизиты: НомерТабличнойЧасти, Колонки все наших таб. частей без рабора (при этом не повторяем одинаковые колонки с т.зр. п.1) В-третьих, в документ добавляем количество закладок по количесту виртуальных таб. частей. Многострочная часть документа находится на общем слое. В-четвертых, при открытии документа. Считываем в ТЗ табличную часть документа. Таб. часть документа очищаем. При выборе закладке натсраиваем видимость колонок многострочной части документа, по фильтру НомерТабличнойЧасти заполняем многострочную часть документа нужно виртуальной таб. частью. При выборе закладке сохраняем изменения мнгостр. части в ТЗ, "заливаем" по фильтру другие строки. В-пятых, при закрытии и сохранении документа, ТЗ со всеми вирт. ТЧ загруажем в многостр. часть документа

Минусы: 1) храним избыточное количество пустых ячеек (пустые колонки, не исполозуемые в других ТЧ) 2) максиальная емкость ТЧ документа уменьшается в n раз, где n - кол-во ТЧ (помним, что в 1С макс. номер строки 99999)

Все остальное плюсы

жесть. мне не нравится. есть проще варианты с ТЗ

И попереключавшись между закладками получаем измекненный документ? КГ/АМ

"помним, что в 1С макс. номер строки 99999" - ошибся в 10 раз

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

Научи как проще Гасим признак модифицированности таким кодом: "Попытка Записать Исключение КонецПопытки" Это я опечатался, но для моих целей хватит диалоговое изменение ширины колонок теряется и в типовых решениях от 1С (напр. Документ БухСправка, закладки: БУ и НУ). Почему криво работает переключение закладки в процессе ввода новой строки? я просто не в курсе, объясни.

главное - скорость теряется в разы. перезаполнять ТЧ при переключении закладки? мне не нравится. и ещё - юзер начал вводить новую строку - не ввёл что то определяющее номер закладки или данные - закрыл документ с сохранением - на какой закладке выведется инфа по этой строке юзер начал вводить строку (она в режиме редактирования) и решил переключить раскладку. что будет?

Скорость не сильно и упадет. Вообще, зачем такие извраты, если есть 1с++

1. Я проверил, глазу не заметно перезаполнение ТЧ 2. ПриНачалеВводеСтроки присваиваем НомерТабличнойЧасти 3. ПриНачалеВводеСтроки ставим флаг. При окончании редактирвании строки убираем флаг. Запрещаем переключение закладки пока включен флаг или завершаем ввод строки.

Как сделать на 1с++, я не в курсе?

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

В поиск.

Во-первых, "гружу в ТЗ" не хочу на форме эмуляторов таб. частей, хочу чтобы пользователь работал нормальным интерфейсом, пользовался кнопками Insert, Del или их командными кнопками, вводил значения непосредственно в ячейке. Т.е. чтобы все было "красиво" Во-вторых, не хочу плодить сущностей без надобности - доп. подч. документы.

Ну хотя бы мне, лентяю, дай строку для поиска, а?

Проблема. при сохранении ТЗ выгружается в ТЧ. И юзеров это немного пугает.

И что мешает?

есть методы работы с ТЗ через ВК - от ТЧ не отличишь подчинённые докукенты - умножение сущностей? да ладно

А нафига? Восьмерка же есть...

Восьмерка будет не раньше через два года, а жить надо сейчас

Мешает нежелание юзать внешние компонетны

Сделаю так, чтобы не видели

На сегодняшний день семерка без плюсов вобще не живет...

Чесать нос, засунув руку через задницу  - желательно, а вот юзать ВК - нежелательно... ну-ну... Зато "с плюсами" по крайней мере, на равных по возможностям, но менее требовательна.

накидай пожалуйста структуру ТЧ окумента по моему документы у 6 ТЧ на подчинённых документах 1 - основная ТЧ документа 1. работа (справочник "Услуги") 3. стоимость нормочаса (число) 4. сумма на услугу без скидки (число) 5. сумма на услугу со скидкой (число) 6. скидка на услугу (число) 2 - ТЗ № 1 "материалы в заказе" 3. стомисть (число) 4. сумма материала без скидки (число) 5. сумма материала со скидкой (число) 6. сумма скидки на материал (число) 3 - ТЗ № 2 "запчасти в заказе" 3. стомисть (число) 4. сумма запчасти без скидки (число) 5. сумма запчасти со скидкой (число) 6. сумма запчасти на материал (число) 4. ТЗ № 3 - "выполненные работы по каждой услуге" 1. Услуга (справочник "Услуги") 2. Работа (справочник "Работы по услугам" подчинённый справочнику "Услуги")

Ладно, буду юзать плюсы поиском. Но один вопрос: где реализуется хранение доп. ТЧ при юзаньи ? В подч. доках?

3. количество нормочасов (число)... 4. стоимость нормочаса (число)... 5. сумма на услугу без скидки (число) ... 6. сумма на услугу со скидкой (число) ... 7. скидка на услугу (число) ... 8. Работа (справочник "Работы по услугам" подчинённый справочнику "Услуги") 9. Сотрудник (справочник "Сотрудники") 10. замечание (строка)

угу и ПриначалеВыбораЗначения для всех случаев жизни так? прикольно. особенно усли учесть что точность и длина поля у всех практически ТЗ разная. т.е. количество нормочасов и коичество материалов и количество запчастей - разные по размерности числа

Да, ПриначалеВыбораЗначения. Количество нормочасов и коичество материалов и количество запчастей я не разбил, потому что ты не указал точность. Указал бы, разбил бы.

особенно прикольно проведение строить по такой ТЧ этож каждый раз надо флаг закладки проверять. эта работа типа "сдела и забыл". что то подправить в таком документе (добавить ещё одну колонку в определённую закладку) - можно застрелиться. хотя как вариант мести заказчикам при желании свалить от них - почему нет ;)

я не сказал что идея - полная кака. можно и на справочниках построит доп ТЧ. просто проще гораздо работать с ТЗ на форме и не морочить голову

Я создал универсальный механизм - массив номеров ТЧ и список колонок, по ним он строит отображение на форме и формируте ТЗ для проведения. Сопровождать просто: добавил новый реквизит в ТЧ, добавил в массив новое описание - всё!

Если отрбосить в сторону 1с++, то имеет ли право на жизнь моя идея, или есть более удачные идеи, не использующие 1с++?

Имеет. Только чрезжопица это.

Я знаю про жопицу, просто в 77 без плюсов иногда никак

Тогда посчитай,  стоит ли необходимость двух ТЧ перехода на восьмерку, и переходи. зы. если есть удобный инструмент - такой, как 1с++ - грех его не использовать. Тем более не нарушающий прав и бесплатный.

У меня в итоге не 2 ТЧ, а 5. Но восьмерку перейти не могу, т.к. надо конфу дорабатывать быстро, а на 8-ке я программирую в 1000 раз медленнее, а надо быстро, да и парк компов не потянет 8-ку. На освоение 1с++ тоже время надо, оного у меня нет, вот и спрашиваю альтернативы.

"Думать некогда, трясти надо?"© :-)

Если кому интересно, то пытаюсь на типовой бух 77 наладить производственный учет. Пока что моя реализация очень походит на реализацию производственного учета в УПП. А ПУБ я на дух не беру.

Сам я прог в глубинке с большим стажем программирования в 77 (вот только 1с++ как-то пока миновал), знаком более чем с бухучетом. Наняли меня за 20 т.р. в месяц в производственную фирму наладить порядок в производстве. Если смогу наладить нормальный производственный учет (похожий на УПП) в типовой бух, поделюсь с сообществом

Спасибо

Блин, ну не нравится мне идея - заводить доп. служебный документ, хоть убейте! Хочется, чтобы вся необходимая информация хранилась в одном документе, даже если возрастут трудозатраты по его программной обработке. Даже не знаю, что сделать, что победить свою убежденность.

Блин, посмотрел я демо-пример по ссылке в . Ну неудобно до ужаса. ТЗ на форме - это ацтой! Пока что у моего методы есть преимущества, от которых меня никому не удалось отказаться: 1) никаких ВК (даже таких полезных как 1с++) 2) никаких ТЗ - все таб. части редактируются удобной и привычной многострочной частью документа 3) никаких доп. сущностей без надобности - ни подч. документов, ни служебных справочников.

Это старая дилемма - "код/данные". Денормализация (отдельный документ) в данном случае дает простоту обработки и (опять же ИМХО) вполне оправдан...

Вот чем тебе ВК не угодили - понять не могу... v7plus.dll тоже похерил ?

v7plus.dll имеет статус "1С: совместимо", 1с++ - нет. С 1с++ я уже натолкнулся на баг, что она может затирать значения переменных глоб. модуля. Очень устойчивый баг словил, при использовании метода ИсполняемыйМодуль случилось что глоб. переменная Да, потеряла свое значение, поменяв его на значение одной из переменной ИсполняемогоМодуля. Представляешь, как я огребся? Ведь переменная Да до хрена где используется в типовых конфах. Причем баг устойчивый, хоть в багзиллу добавляй. А если серьезно, вопрос из разряда почему бы не юзать 8-ку вместо 77.

Ты уверен, что это баг? кинь на форум 1с++ описание с тестом...

Уверен! Поменял имена перменных в Исполняемом модуле, баг пропал, вернул на место, тут же появился. Весь мудешник кидать? Простого примера сделать не получается. Так что, боюсь я 1с++ повсеместно юзать, попала она у меня в разряд недоверяемых

то, гдн менял, и нидай... Имхо, дело не в 1с++, а в широко известном драйвере....

не понял

руки.sys

После выполнения такого ВМ: значение переменной глобального модуля Да, имеющей значение Перечисление.Булево.Да менялось на значение ТаблицаТовара. Причем здесь "широко известный драйвер"?

Чтобы было понятнее откуда взялось Конт, сообщу, что вначале ВМ был еще такой код:

В форме модуля документа Чек такой код: В глоб. модуле такая ф-я:

это с "чистым" 1с++ или с FormEx?.. (просто в свое время нарвался на то, что при использовании FormEx в отладчике после простого присвоения в коде внешней обработки управление перескакивало в глобальный модуль, причем на прямо на строку внутри процедуры.. я офигел..)

Чистый 1с++ без формекса

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

то что придумал гений из , народ уже лет 8 пользует...

Хотелось бы услышать от тебя конкретики, а также поделись опытом.

вопрос в неизвестность....

Ты слишком много смотришь передачь с Бахметьевым "Очумелые ручки".

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

1. Мне не требуется 2. Как раз это я реализую, в том числе 3. Нет, учитывая, что я таб части внутри распихиваю по ТЗ

1 - был бы смысл... это ты 8-кой избалован 2 - что мешает? дописать зависимость - проблем-то... тяжко отслеживать изменения, но можно, если постараться 3 - в чем хлопоты? в коде ТЗ ведь никто не отменял!

иногда есть... мне вот надо было показать в табчасти Лот и две ТЗ: "состав лота" и "заявки по лоту"....  вот и представь сколько избыточной инфы висело бы в документе....

тогда с помощью ТЗ реализуешь всё от задачи зависит

п. 1,2 Мне в 7.7 чаще требовалось, чем в 8 :) И в п.2. я имел в виду показ/редактирование одной таб. части по тек. строке другой таб.части. Без одновременного показа 2х частей это невозможно или неудобно. Простой пример. + Табчасть "Серийные номера" (подчиненная к материалам) + Табчасть "Детализация" (подчиненная к услугам) -  показывает основания выставленных услуг (типа заказ-нарядов). Серийные номера и детализацию удобнее видеть/вводить по текущей строке материалов/работ. На вопрос "почему не объединить, например, работы и детализации" отвечу "потому что цена одна за услугу". 3. Поддерживать еще и тз по каждой псевдотабчасти во время постоянных выгрузок/загрузок - дополнительный расход ресурсов и кода :) Неразрешимая проблема при данном способе - только одновременный показ и все, что из него вытекает.

ну так об этом речь... ими и реализовывал :)) но реализвоть это через методику - больно геморно и бессмысленно, проще было использовать документы...

Может быть стоит немного упростить способ (хотя я конечно всетаки рекомендовал бы ТЗ на форме) 1. Колонки которые находятся на определенной закладке именуем по формату, к примеру: ТЧ01В1Сырье  ТЧ01В1Количество  ТЧ01В0Ерунда   ТЧ02В1Материал   ТЧ02В0Ещечегото.... При открытии, как хотел перегружаешь это все в ТЗ, удаляешь строки, и в зависимости от закладки начинаешь перебирать колонки, разбирая названия 4 знака признак к какой ТЧ относится, дальше 2 знака видимость, впринципе еще может добавить доступность, ну и последнее собственно заголовок.

+76 Когда уже отправил пришла идея! Не стоит поганить идентификаторы, лучше все это перекинуть в комментарии или на крайняк синонимы. Тобишь при выборе закладки пробегаешь через метаданные по таб.части выбираешь синонимы и уже по ним формируешь свою табличную часть.

Согласен, это модификация моего предложения в . (74.3) Тут я погорячился, поддреживать ТЗ для итого не нужно, итоги уже будут в мн. части при открытии закладки.

Плохо ешкин кот

По статье... Вообще-то целесообразнее не служ. документ а служ. справочник имхо

Почему плохо? Про справочник было ранее, я принял к сведению

для меня, плюсы документа: 1. можно открыть форму документа и сразу получим форму редактирования таб части.... с привычными для юзера ins и Del 2. непосредственное удаление строки из документа 3. быстрое формирование ТЗ по выбранному доку, через выгрузить/загрузить...

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

Возможно придется следить, чтобы не создавалось документов больше 1 для 1 элемента справочника, думаю все?

А ес нуна хранить историю изменений табличной части?

по кн из спр открывать с параметром: ВыбДата последний документ

Подчиненные доки - и ниипет!

Кстати, я реализовал сабж. Работает чУдно. При этом реализовал универсальный механизм, который: а) позволяет легко сопровождать конфигурацию в плане изменения состояния реквизитов табл. частей и кол-ва табличных частей для уже введенных в эксплуатацию документов б) без труда добавлять любое кол-во табличных частей в другие документы; в) не используются никакие ВК, все табличные части равнозначны в интерфейсе, пользователь управляет ими одинаково. . При этом оказалось, что являются мифом следующие утверждения: "И попереключавшись между закладками получаем измекненный документ? КГ/АМ" "криво работает переключение закладки в процессе ввода новой строки" "главное - скорость теряется в разы. перезаполнять ТЧ при переключении закладки? мне не нравится." - не теряется нисколько! "юзер начал вводить новую строку - не ввёл что то определяющее номер закладки или данные - закрыл документ с сохранением - на какой закладке выведется инфа по этой строке" - исключено! "юзер начал вводить строку (она в режиме редактирования) и решил переключить раскладку. что будет?" - строка автоматически завршит свой ввод! "Проблема. при сохранении ТЗ выгружается в ТЧ. И юзеров это немного пугает" - реализовал, чтобы пользователь это не видел "особенно прикольно проведение строить по такой ТЧ. это ж каждый раз надо флаг закладки проверять. эта работа типа "сдела и забыл". что то подправить в таком документе (добавить ещё одну колонку в определённую закладку) - можно застрелиться. хотя как вариант мести заказчикам при желании свалить от них - почему нет ;)" - см. п. а)

поздравляем. ты пробил дырку за 10 дней в стене. на подчинённых документах реализуется за 1 час

Спасибо! Ты на самом деле не знаешь сколько я потратил времени. Но скажу следующее. Если бы я делал на подч. документах, то: а) это было бы дольше б) я не получил бы такого результата в плане удобства интерфейса и последующего споровождения(!) в) возросли бы трудозатраты по последующей организации переноса данных между конфигурациями (различными)

ну да ну да...... конечно. все вокруг дятлы а ты один дертаньян.... ну сделал и молодец. а как это работает в реале - посмотришь при реальной работе. хорошо?

БСМЯЛН

переведи

"Бред Сивого Мерина в Ясную Лунную Ночь"©

в оригинале было Сивой кобылы и эта фраза моя ;)

Я не говорю, что я молодец. Я лишь отмечаю тот факт, что аналогичных решений я не встерчал. А вы? Мне что, демку выложить, чтобы были не одни голословные утверждения?

давай, посмотрим, вруг оно того стоит.

Я на ЦопыРыгхт не претендую :-)