Добрый день. Посмотрел решение своей проблемы в https://forum.infostart.ru/forum9/topic185344/ Если не считать метода, которым воспользовался (или сам придумал) автор, о котором ничего неизвестно, то...
Предложенные схемы отдельной ТЗ с ключом и НайтиСтроки, а также присвоение колонке значения вновь сформированной ТЗ, как-то попахивают дурно.
Почему дурно? Да потому что при наличии формы этой проблемы не возникает - в дизайнере нащелкал кнопок и всего делов...
У меня нет формы, она в обработке не нужна. Реквизиты модуля создал в дизайнтайме, в том числе и нужные ТЗ. В реалтайме добавляю колонки в ТЗ. Да вот незадача... нужна колонка типа ТЗ. Поступил вот так:
ТипТЗ = Новый ОписаниеТипов("ТаблицаЗначений");
ЗаказыИМ.Колонки.Добавить("ПримечаниеЗаказа",ТипСтрока1024,,);
ПозицииЗаказа = ЗаказыИМ.Колонки.Добавить("ПозицииЗаказа",ТипТЗ,,);
начиная отсюда идет ошибка "нет поля "Колонки"
ПозицииЗаказа.Колонки.Добавить("ИдентификаторИМ",ТипЧислоИден,,);
ПозицииЗаказа.Колонки.Добавить("Товар1С",ТипТовар1С,,);
Показать
Ошибка понятна. Тупой интерпретатор решил, что ПозицииЗаказа - есть сущность "Колонка", а вот как ему подсказать, что последняя добавленная колонка - есть ТЗ? Читал-читал про приведение типов... но там, как всегда дальше строка-число и обратно ничего нет.
(2)Не нашлось специалиста для синхронизации с интернет-магазином - есть там заморочки очень существенные. Вернее, максимум поисков привели к "сумма в тучу нулей и без гарантий". Но это лирика...
Проблема решена, но внешней обработкой с формой. Все нужные процедуры выполняются кнопками/менюшками и пр., визуализируются и т.д. и т.п. НО...
На базе этого кода нужно сделать регламентное задание. Есс-но, что у меня желание не рожать дважды и по-разному... Для этого нужно, чтобы необходимые реквизиты модуля задания были идентичны реквизитам формы обработки, а все бизнес-процессные процедуры не правились . Только и всего. Поскольку в дизайнтайме и на форме проблем нет, то зачем мне изгаляться?
(6)Подобное уже не раз слышал... Только кто-то из "великих", называющих себя "программистами 1С", как-то брякнул типа "1С - это язык будущего, он декларативный". Вот вам и результат. Абсолютная тупоголовость, мания величия, а на самом деле слюни и сопли вместо одной строчки кода или ссылки.
Абсолютная тупоголовость, мания величия, а на самом деле слюни и сопли вместо одной строчки кода или ссылки.
Угу, по вашим комментариям это отлично видно.
Начал человек, слабо разбирающийся в 1С что-то делать, у него что-то не получается.
Все вокруг сразу тупые =)
Предложенные схемы отдельной ТЗ с ключом и НайтиСтроки, а также присвоение колонке значения вновь сформированной ТЗ, как-то попахивают дурно.
Что мешает использовать другие инструменты?
На вскидку:
1 - вместо таблицы использовать дерево значений
2 - использовать соответствие, в котором в качестве ключа будет строка первой ТЗ, а значением - таблица детализации этой строки
3 - ...
Но все еще не понятно, в чем проблема индексировать таблицу детализации по ключам и все-таки использовать Найти или НайтиСтроки?
(8)Да это все понятно и примеры даются... Вопрос же в "Почему дурно? Да потому что при наличии формы этой проблемы не возникает - в дизайнере нащелкал кнопок и всего делов." Или Вы думаете, что дизайнер пользуется недокументированным API?
(12) Это я уже понял. Не верь глазам своим, когда видишь в дизайнере тип "ТаблицаЗначений". Но, извините, ТЗ.Колонки.Добавить возвращает... Понятно, что возвращает... Блин...ство... там только объект с четырьмя свойствами. Ну что можно сказать... Декларативное программирование - что хочу, то и пишу. А то, что принципиально НЕЛЬЗЯ добавить в ТЗ колонку типа полноценная ТЗ. Нет, добавить можно, только потом можно только присвоить значение типа ТЗ. И где же тут ООП... Лирика. Можно вопрос закрыть и больше не поднимать.
(13) Ты не задумывался, почему за столько лет у колоссального сообщества разрабов не возникало подобной проблемы? Тебе там задавали вопрос про задачу, ты так и не ответил. Так вот, 100 пудов даю на отсечение, ты бьёшься в это решение, потому что только его и видишь. Но при этом существует другое, подходящее без кучи кода. Тебе даже озвучивали несколько вариантов как сделать.
Тупой интерпретатор решил, что ПозицииЗаказа - есть сущность "Колонка", а вот как ему подсказать, что последняя добавленная колонка - есть ТЗ?
Как же так, у колонки сущность "колонка"? Это же вообще беспредел! Давайте в ТЗ вместо колонок будут другие ТЗ, а тип ТЗ пусть будет не "ТЗ" а "Строка". И с чего ж оно не работает? Может, потому что тип нужно назначить ЗНАЧЕНИЮ, хранимому в ТЗ, а не менять тип существующих объектов.
(14)Я почему-то решил, что 1С сродни интерфейсам, а поля(свойства) что-то типа Variant. Хотя на самом деле, моя ошибка в том, что "поверил" глазам своим... решил, реквизит формы типа ТЗ - это Таблица значений и с ней можно проделывать то же самое, что и в дизайн-тайме... А это совершенно не так.
во многих типовых сейчас используют в табличных частях поле "ИдСтроки", это поле используют когда для некоторого поля строки одной ТЧ необходимо задать в качестве значения множество строк другой ТЧ. Этот механизм вполне логичен и успешен.
Каша мысле-образов автора говорит о том, что он хочет изобрести что-то корявое и кривое.
Пример(идентификаторы по памяти): УТ-11.4 Документ "ВводОстатков", ТЧ "Товары", поле "РасчетныйДокумент", связанная ТЧ "Партии"
(3)Я разве сказал, что предложенные методы "неуспешны"? Я буквально удивился, что приемы работы в дизайн-тайме почему-то непрозрачны для "специалистов"/программистов 1С - им по душе "всякие "придумки"... Это не их вина. Я бы мысле-образы 1С-ников поддверг бы экспертизе в Серсбского. Экспертиза на ООП 1С-у уже давно дана.
А колонки нужно добавлять в формируемую для каждой строки ТЗ, а ее уже пихать в ячейку. Метод Колонки.Добавить() возвращает колонку ТЗ, а не тот тип, который в ней будет храниться, что естественно.
На базе этого кода нужно сделать регламентное задание. Есс-но, что у меня желание не рожать дважды и по-разному... Для этого нужно, чтобы необходимые реквизиты модуля задания были идентичны реквизитам формы обработки, а все бизнес-процессные процедуры не правились . Только и всего. Поскольку в дизайнтайме и на форме проблем нет, то зачем мне изгаляться?
(20)Потому что данные по заказам приходят из интернет-магазина по http в виде xml. Предлагаете на лету (на парсинге) сразу заносить в 1С? Кто сказал, что порядок тегов в xml стабилен? Главбух сказала, что заказ "проводится" и отпускается ТОЛЬКО с одного склада. Менеджер "перекинет" недостающий товар на один склад, и только после этого "проведет" и оформит реализацию. Хотите с главбухом поспорить? Короче, есть куча заморочек, главная из которых - вы не контролируете ресурс-источник, а значит без промежуточного хранилища входящей инфы не обойтись. Вернее, можно обойтись, но с риском обзавестись модной болезнью, обозначаемой в рекламе в виде канцелярской скрепки на сидении стула.
(24) Ты про XDTO слышал вообще? Определяешь св-во объекта XTDO Упорядоченный = Ложь и вперёд.
Зачем контролировать какие-то источники? Вариантов решения полно. Хоть делай непроведённый заказ, хоть записывай пришедшие пакеты в РС, а потом обрабатывай по какому-нибудь событию.
С главбухом надо разговаривать квалифицированному специалисту, который хорошо знает возможности платформы. Он сможет сгенерить решение, которое не будет отдавать говнокодом. Иначе хреновый программист "подстилается" под хотелки главбуха и конфигурация превращается в колхоз. А потом главбух увольняется и возникают вопросы "а зафига мы так делали" и "кому это надо вообще".
Хочешь получить оптимальное предложение реализации - чётко опиши свою задачу. А то какие-то контроли источников, порядки полей XML и прочие несуразицы.
(27)Для начала хорошим манерам обучитесь, а потом все остальное. Хорошо быть программистом и не видеть дальше собственного носа. Особенно умиляет "с главбухом нужно разговаривать..." Пипец. Нормальный главбух пошлет такого умника, и будет прав. Знаете почему? Читайте законы про главбухов, и радуйтесь, что про программеров (особенно 1С) законов еще не пишут. Останьтесь при своем мнении, или поверьте опыту работы интегратора интернет-ресурсов, волею судеб вынужденного программить на 1С.
(29) Ох, малыш... Мне верить твоему опыту работы в сторонней среде разработки? Ты смешной. Можешь сотрясать ресурс своими открытиями вроде "1с говно", но на жизни это никак не скажется. Умерь гонор и послушай советы выше, если тебе нужна эта платформа и ты хочешь стать хорошим специалистом. Сейчас тебя пытаются уберечь от говнокода.
(33)Сынок, не тебе меня учить. Ты еще под стол ползал, когда я на пенсию вышел. Особенно, про говнокод. К большому сожалению, не все говно, всплывшее в начале 90-х, утонуло.
Хотя да, тз все же понадобится, но можно плоской обойтись, добавить колонку типа «КлючЗаказа», а если данные получаете в json или xml - 1с их прекрасно читает и превращает в объект xdto или массив структур. Тз хороша для интерфейса, да, но в регламенте и без неё обойтись.