Комментарии 37
Как то мне
Как то мне нужно было настроить обмен с базой 1с с самописной конфой, так там все реквизиты справочников были сделаны таким образом. Жесть была еще та
Каким методом? доп реквизитами или как? Не совсем понимаю как в «самописной конфе» можно что то страшное натворить…
Один программист создал конфу, в которой во всех справочниках вместо нескольких реквизитов добавил один строковой реквизит с названием «ХМЛ» и в него сохранял в формате XML то, что нужно по сохранять в отдельных реквизитах (ИНН, КПП, р/с — у контрагента, ставку НДС и цены у товара и прочее). Особенно было весело, когда один и тот же по смыслу тег различался по названию от записи к записи. И еще там была куча проблем с ссылочной целостностью.
Добавляется объект с таблицей значений и реквизитом содержащий объект родитель
Ого, а как же ссылочная целостность?
Вообще это конечно прелесно, что 1С за почти 20 лет разработки своей платформы так и не осилила упростить процесс поддержки доработанных конфигураций, введя хоть какое то подобие ООП. Хотя бы в виде «пользовательских» файлов, автоматически сливамых с основной конфигурацией + перезагрузка функций. Это же элементарно сделать
Такое впечатление, что 1С специально усложняет поддержку, чтобы обеспечивать работой своих многочисленных франчайзи
Ого, а как же ссылочная целостность?
Я имел ввиду «реквизит с ссылкой на объект родитель», изменил в статье.
Может картинками дополню для наглядности…
Таблица значений (ТЗ) содержит ссылку на контактное лицо. Вместе с этой ссылкой ТЗ помещается в строковом виде в дополнительный реквизит. Затем по какой-либо причине контактное лицо удаляется. Вуаля — строковый реквизит содержит ссылку на несуществующий объект. Это и называется отсутствие ссылочной целостности.
А, что предусмотреть то это очень трудно и очистить строку в доп реквизите перед удалением?
И вообще вы часто из конфигурации наглушняк удаляете?
Да я конечно не делал в примере различные проверки, да и цели такой небыло. Была цель просто продемонстрировать механизм вывода, а уж ряшечки навесить можно любые.
К примеру вообще заточить данный механизм под то чтобы ТЗ формировала колонки в зависимости от структуры массива. Но это как говорится уже тянет на платные разработки…
И вообще вы часто из конфигурации наглушняк удаляете?
Да я конечно не делал в примере различные проверки, да и цели такой небыло. Была цель просто продемонстрировать механизм вывода, а уж ряшечки навесить можно любые.
К примеру вообще заточить данный механизм под то чтобы ТЗ формировала колонки в зависимости от структуры массива. Но это как говорится уже тянет на платные разработки…
Предусмотреть, конечно, можно. Попробуем прикинуть пути решения такой задачи:
Или махнуть рукой на отсутствие ссылочной целостности.
- Можно отловить событие пометки на удаление контактного лица в модуле объекта
- Можно сделать подписку на событие удаления объекта
Или махнуть рукой на отсутствие ссылочной целостности.
Ну а к примеру обработка для удаления чем плохой вариант. Выбрали из списка контактное лицо и нажали удалить. Это на вскидку… Чаще всего элементы не простой пользователь в базе удаляет а грамотный специалист отличающийся умом и сообразительностью ;)
А вообще в документообороте удалять контактное лицо это ересь честно говоря. С ним договора заключали и история хранится в независимости от того уволился он из сторонней конторы.
А вообще в документообороте удалять контактное лицо это ересь честно говоря. С ним договора заключали и история хранится в независимости от того уволился он из сторонней конторы.
А вообще, если серьезно о какой целостности идет речь если ТЗ хранится строкой в формате JSON и в ПриСозданииНаСервере можно поставить проверку на это мероприятие?
Неправда, в 1с все сущности — объекты. Создавать свои классы не имеет смысла, вы просто расширяете готовые, например, прописываете код нажатия кнопки.
Что не правда? Я не понял претензии…
Я кратко заикнулся про часто используемые методы. Один из них добавить в конфигурацию новый документ\справочник с таблицей и в реквизите документ основание указать ссылку на документ\справочник типовой конфигурации. По этим двум кратко описанным пунктам добавлю картинки для ясности но попозже, я на них не акцентировал внимания.
Далее я подробно расписал как использовать дополнительный реквизит для хранения Таблицы Значения в виде JSON. И как через «Расширения конфигурации» работать с этим реквизитом словно с таблицей.
Я кратко заикнулся про часто используемые методы. Один из них добавить в конфигурацию новый документ\справочник с таблицей и в реквизите документ основание указать ссылку на документ\справочник типовой конфигурации. По этим двум кратко описанным пунктам добавлю картинки для ясности но попозже, я на них не акцентировал внимания.
Далее я подробно расписал как использовать дополнительный реквизит для хранения Таблицы Значения в виде JSON. И как через «Расширения конфигурации» работать с этим реквизитом словно с таблицей.
Добавил скриншоты по двум кратко описанным методам.
Стесняюсь спросить: чем же хорош данный способ? Он что, не требует вмешательства в конфу (первому варианту это было поставлено в минус)? Можно ли использовать эту таблицу, хранимую в строке, в дальнейшем для анализа данных в запросах (а иначе зачем нам все эти данные)? Нет и нет. Как по-мне, так сплошные минусы.
А за хардкод типа «НайтиПоНаименованию(»ТЗ_АдекватностьКонтактныхЛиц");" вообще надо бить по рукам, уж извините.
А за хардкод типа «НайтиПоНаименованию(»ТЗ_АдекватностьКонтактныхЛиц");" вообще надо бить по рукам, уж извините.
Судя по комментариям с Документооборотом не работали, ну по порядочку отвечу.
Тем и хорош что не требует вмешательства в конфу, в самом низу на скриншоте это наглядно видно.
Также используя этот метод можно сварганить универсальный способ вывода разных таблиц значений в зависимости от вида документа.
Из двух кратко описанных способов 1 по мне это самый плохой, я лично предпочитаю 2-й способ.
По моему я в статье написал, что это один из минусов способа.
Тем кто работает с конфигурацией Документооборот известны хотелки руководства.
Например создать вид документа «Служебка на командировку» и чтобы в ней присутствовала ТЗ с затратами.
Вы работали с конфигурацией документооборот?
Если под каждый вид добавлять ТЗ в конфигурации это будет жомопа как говориться. Справочник то один, а видов документа много и под каждые могут быть хотелки.
Или к примеру в ERP под номенклатуры с видами похожая история.
В данных ситуациях 1 способ вообще не катит.
Конкретно тут под данный пример этот хардкор очень даже подходит.
В других случаях запросом можно получить.
Хотелось бы услышать ваш вариант…
Стесняюсь спросить: чем же хорош данный способ? Он что, не требует вмешательства в конфу (первому варианту это было поставлено в минус)?
Тем и хорош что не требует вмешательства в конфу, в самом низу на скриншоте это наглядно видно.
Также используя этот метод можно сварганить универсальный способ вывода разных таблиц значений в зависимости от вида документа.
Из двух кратко описанных способов 1 по мне это самый плохой, я лично предпочитаю 2-й способ.
Можно ли использовать эту таблицу, хранимую в строке, в дальнейшем для анализа данных в запросах (а иначе зачем нам все эти данные)? Нет и нет. Как по-мне, так сплошные минусы.
По моему я в статье написал, что это один из минусов способа.
Тем кто работает с конфигурацией Документооборот известны хотелки руководства.
Например создать вид документа «Служебка на командировку» и чтобы в ней присутствовала ТЗ с затратами.
Вы работали с конфигурацией документооборот?
Если под каждый вид добавлять ТЗ в конфигурации это будет жомопа как говориться. Справочник то один, а видов документа много и под каждые могут быть хотелки.
Или к примеру в ERP под номенклатуры с видами похожая история.
В данных ситуациях 1 способ вообще не катит.
А за хардкод типа «НайтиПоНаименованию(»ТЗ_АдекватностьКонтактныхЛиц");" вообще надо бить по рукам, уж извините.
Конкретно тут под данный пример этот хардкор очень даже подходит.
В других случаях запросом можно получить.
Хотелось бы услышать ваш вариант…
А если надо будет, развивать механизм, реализовать, например, отчет по контактным лицам с отбором по адекватности? вам придется сначала пройти весь справочник, подготовить таблицу, поместить ее в запрос и только потом работать как обычно. Все это будет работать до определенного момента (объема данных). Практичности от такого подхода на мой взгляд мало.
Я и писал что этот вариант подходит не для всех задач. Для вашей задачи лучше 2 вариант или регистр сведений.
Но повторюсь конкретно для документооборота этот способ очень даже подходит. Зачастую по Внутренним документам разного вида разные пожелания.
Но повторюсь конкретно для документооборота этот способ очень даже подходит. Зачастую по Внутренним документам разного вида разные пожелания.
А при чем здесь документооборот? Видимо, просто, тот, кому вы решали таким образом задачу, хотел просто указывать данные в справочниках или документах и не использовать их в совокупном анализе. Таким образом, этот подход ограничевается областью конкретного элемента, например, печатные формы.
В том то и дело что данный вопрос очень часто задают по документообороту.
И чаще всего по справочнику внутренние документы или исходящие документы.
Данные справочники в зависимости от вида документов имеют разные наборы доп реквизитов.
Я именно поэтому продемонстрировал данный пример на Документообороте, хотя конечно не на том справочнике по которому спрашивают.
Я данную задачку ни для кого не делал, я просто решил описать данный метод и за минуту придумал «Шуточное задание». Просто чтобы было на чем продемонстрировать.
И чаще всего по справочнику внутренние документы или исходящие документы.
Данные справочники в зависимости от вида документов имеют разные наборы доп реквизитов.
Я именно поэтому продемонстрировал данный пример на Документообороте, хотя конечно не на том справочнике по которому спрашивают.
Я данную задачку ни для кого не делал, я просто решил описать данный метод и за минуту придумал «Шуточное задание». Просто чтобы было на чем продемонстрировать.
Данная статья весьма хороша как яркий пример того, как не надо дорабатывать конфигурации.
Неужели обновление доработанной конфигурации на поддержке сложнее обновления расширения конфигурации?
Да и задача слияния дважды измененных объектов не является сколько-нибудь сложной. Ведь третьичное сравнение поставки, обновляемой и доработанной конфигураций выполняется системой автоматически ;)
Неужели обновление доработанной конфигурации на поддержке сложнее обновления расширения конфигурации?
Да и задача слияния дважды измененных объектов не является сколько-нибудь сложной. Ведь третьичное сравнение поставки, обновляемой и доработанной конфигураций выполняется системой автоматически ;)
Данная статья весьма хороша как яркий пример того, как не надо дорабатывать конфигурации.
Неужели обновление доработанной конфигурации на поддержке сложнее обновления расширения конфигурации?
От чего же? Я описал часто встречаемые и используемые методы и описал метод который позволит хранить ТЗ которое выводится «информативно». Что часто кстати просили именно в Документообороте.
Да и задача слияния дважды измененных объектов не является сколько-нибудь сложной. Ведь третьичное сравнение поставки, обновляемой и доработанной конфигураций выполняется системой автоматически ;)
Мне тут вспомнилось. Примерно с год назад столкнулся с базой которую правил беспощадно программист приклонного возраста работающий до этого только с семеркой. Его услугами пользовались потому, что «дешево». Программист умер, что и для чего там наверчено не сохранилось инфы, так как в конторе тякучка адская. Мало того версия конфигурации и конфигурации поставщика каким то волшебным образом оказались различны.
К чему я? Да вроде все просто и легко, но как такое получается?
Была тривиальная задача доработки конфигурации, при котором последующее обновление полуавтоматически накатывалось. Скажем так, это задача на которой юниоров знакомят с системой.
Стало: доработанная конфигурация, решающая проблемы бизнеса и заказчика, но!
1. При изменении в БСП методов хранения или отображения доп. свойств все захардкоденные условия типа: сериализации и десериалихации ровно как и скрытие вывода типовым отображением и вывод своим способом, все это просто перестает быть актуальным и нуждается в полной проработке заново.
2. Теряется ссылочная целостность базы.
3. Теряется возможность обращаться к данным на уровне субд, соответственно и возможность использовать индексы для поиска данных, что на больших системах критично.
4. Фактически задача сравнения и объединения остается, только не для конфигураций, а для расширений.
5. С этой доработкой любому программисту будет необходимо сначала разбираться как это все работает, в итоге время обновление релиза не вами будет выше для заказчика, чем если это сделать нормальным способом (кажется вы сами только что на это ругались).
6. Использование расширения конфигурации не по назначению. Было бы условие того, то ваша конфигурация в сервисе, то решение было бы нежелательным, но приемлимым.
7. Заказчик же наверное попросит не только хранить табличную часть, но и обрабатывать ее, искать данные по сведениям в ней или выводить эти данные в отчете. Потому еще и слишком ограниченное применение и усложнение всех последующих доработок по подобным документам.
P.S. Версия конфигурации поставщика спокойно может отличаться от версии из конфы, читайте правила нумерации форков и технологию разветвленной разработки, если хотите работать с нумерацией версий правильно. Тот же простой пример, вы разрабатываете свою конфигурацию на базе БСП со своей нумерацией, но при этом БСП время от времени обновляете до последнего релиза.
P.P.S Финты ушами при разработке надо делать ориентируясь не на плохие примеры до этого в вашей практике, а на хорошие.
Стало: доработанная конфигурация, решающая проблемы бизнеса и заказчика, но!
1. При изменении в БСП методов хранения или отображения доп. свойств все захардкоденные условия типа: сериализации и десериалихации ровно как и скрытие вывода типовым отображением и вывод своим способом, все это просто перестает быть актуальным и нуждается в полной проработке заново.
2. Теряется ссылочная целостность базы.
3. Теряется возможность обращаться к данным на уровне субд, соответственно и возможность использовать индексы для поиска данных, что на больших системах критично.
4. Фактически задача сравнения и объединения остается, только не для конфигураций, а для расширений.
5. С этой доработкой любому программисту будет необходимо сначала разбираться как это все работает, в итоге время обновление релиза не вами будет выше для заказчика, чем если это сделать нормальным способом (кажется вы сами только что на это ругались).
6. Использование расширения конфигурации не по назначению. Было бы условие того, то ваша конфигурация в сервисе, то решение было бы нежелательным, но приемлимым.
7. Заказчик же наверное попросит не только хранить табличную часть, но и обрабатывать ее, искать данные по сведениям в ней или выводить эти данные в отчете. Потому еще и слишком ограниченное применение и усложнение всех последующих доработок по подобным документам.
P.S. Версия конфигурации поставщика спокойно может отличаться от версии из конфы, читайте правила нумерации форков и технологию разветвленной разработки, если хотите работать с нумерацией версий правильно. Тот же простой пример, вы разрабатываете свою конфигурацию на базе БСП со своей нумерацией, но при этом БСП время от времени обновляете до последнего релиза.
P.P.S Финты ушами при разработке надо делать ориентируясь не на плохие примеры до этого в вашей практике, а на хорошие.
Надеюсь пишу в последний раз.
Если читать статью там есть такие фразы:
1 «Заранее скажу, вариант не идеален, и сгодится только под определенные задачи.»
2 «Самый главный минус это то, что будет использоваться строка неограниченной длины а, следовательно, с поиском в ней будут определенные сложности.»
3 «Сразу говорю задачка больше шуточная для демонстрации метода.»
Но так как никто не прочитал из тех то комментирует, а просто посмотрел картинки, началось обсуждение…
Я мог сделать пример с двумя колонками «КолонкаСтрока», «КолонкаЧисло» — по крайней мере так любят делать на большинстве ресурсов, но я решил чуть расширить пример.
Кстати о какой целостной речи идет речь если данные хранятся в виде строки, в формате JSON и в ПриСозданииНаСервере можно поставить проверку на это мероприятие?
Вы не допускаете, что по внутренним документам по разным видам нужна просто информативная таблица? При этом для каждого вида различная…
Еще раз повторюсь, я просто привел пример как можно хранить ТЗ в допе с помощью строки.
Если читать статью там есть такие фразы:
1 «Заранее скажу, вариант не идеален, и сгодится только под определенные задачи.»
2 «Самый главный минус это то, что будет использоваться строка неограниченной длины а, следовательно, с поиском в ней будут определенные сложности.»
3 «Сразу говорю задачка больше шуточная для демонстрации метода.»
Но так как никто не прочитал из тех то комментирует, а просто посмотрел картинки, началось обсуждение…
Я мог сделать пример с двумя колонками «КолонкаСтрока», «КолонкаЧисло» — по крайней мере так любят делать на большинстве ресурсов, но я решил чуть расширить пример.
Кстати о какой целостной речи идет речь если данные хранятся в виде строки, в формате JSON и в ПриСозданииНаСервере можно поставить проверку на это мероприятие?
Вы не допускаете, что по внутренним документам по разным видам нужна просто информативная таблица? При этом для каждого вида различная…
Еще раз повторюсь, я просто привел пример как можно хранить ТЗ в допе с помощью строки.
Конечно. Но лучше не давать таких примеров :)
С архитектурной точки зрения такую задачу правильно решить было бы:
Создать свою подсистему дополнительных табличных частей (не пересекающуюся. БСП) состоящую из плана вида характристик определяющих двумерную адресацию значений (имя таблицы и имя реквизита/ресурса) с указанием типа хранения значения. Для документа создать таблицу значений для хранения этих дополнительных табличных частей. Разворачивать такую двумерную адресацию на скд можно в несколько строк кода в режиме обработки таблицы значений. Отредактировать форму документа или создать связанную форму для отображения табличных частей. Данное решение будет не привязано к последующим обновлениям и система будет легко обновляться, помимо этого решение прозрачно для понимания, контроль целостности выполняется платформой, результаты можно использовать как во встроенном языке так и в запросах, сама база данных остается в третьей нормальной форме.
С архитектурной точки зрения такую задачу правильно решить было бы:
Создать свою подсистему дополнительных табличных частей (не пересекающуюся. БСП) состоящую из плана вида характристик определяющих двумерную адресацию значений (имя таблицы и имя реквизита/ресурса) с указанием типа хранения значения. Для документа создать таблицу значений для хранения этих дополнительных табличных частей. Разворачивать такую двумерную адресацию на скд можно в несколько строк кода в режиме обработки таблицы значений. Отредактировать форму документа или создать связанную форму для отображения табличных частей. Данное решение будет не привязано к последующим обновлениям и система будет легко обновляться, помимо этого решение прозрачно для понимания, контроль целостности выполняется платформой, результаты можно использовать как во встроенном языке так и в запросах, сама база данных остается в третьей нормальной форме.
вы серьезно?
вы серьезно?
В статье же написано «Сразу говорю задачка больше шуточная для демонстрации метода.»
Мне больше нравится конечно, что даже при этом к примеру относятся так будто он куда то внедрен…
Можно прикрутить костыль немного попроще: в конфигурациях на БСП есть регистр сведений «ПользовательскиеМакетыПечати» с ресурсом «Макет», который имеет тип «ХранилищеЗначения», соответственно, туда можно запихнуть целиком ТЗ.
Полезность статьи конечно минимальна, но чего все накинулись то, про эту минимальность автор и написал:«Заранее скажу, вариант не идеален, и сгодится только под определенные задачи», то есть вариант одноразовый.
Потому что, кто-то прочитает и подумает что так и нужно делать и это есть правильно.
Из-за болота вредных советов (просто устаревших советов, мифов, велосипедов и т.п.) по 1С и другим языкам, очень тяжело новичкам двигаться в правильном направлении. Такие статьи и полезны только наличием комментариев, чем такие подходы плохи и чреваты в последующем.
Автору + за решительность публиковать свои достижения и продолжать расти, за битого двух небитых дают.
Из-за болота вредных советов (просто устаревших советов, мифов, велосипедов и т.п.) по 1С и другим языкам, очень тяжело новичкам двигаться в правильном направлении. Такие статьи и полезны только наличием комментариев, чем такие подходы плохи и чреваты в последующем.
Автору + за решительность публиковать свои достижения и продолжать расти, за битого двух небитых дают.
Самое страшное в статье даже не сама идея, она в принципе имеет право на жизнь, но тогда я не вижу существенных отличий от простого форматированого документа с табличкой.
А самое страшное — код. Раз уж вы приводите реальные куски кода из серии копи/паст — то хотя бы оптимизируйте его :)
Вы тут делаете все так, как делать не надо, ваш код можно ужать в несколько раз, и работать он будет на порядок быстрее. Некоторые вещи вообще меня заставляют задуматься над смыслом бытия! Зачем вы ГУИ превращаете в строку, а потом в цикле клиента дергаете сервер каждый раз? Что вам мешает сериализовать само значение справочника?
Зачем вы вообще массив создаете? Возьмите вашу таблицу формы конвертните в ТЗ, а ТЗ сериализуйте — 4 строки кода, и тоже самое при десериализации, всю вашу идею можно уместить в 10 строк полезного кода :)
А самое страшное — код. Раз уж вы приводите реальные куски кода из серии копи/паст — то хотя бы оптимизируйте его :)
Вы тут делаете все так, как делать не надо, ваш код можно ужать в несколько раз, и работать он будет на порядок быстрее. Некоторые вещи вообще меня заставляют задуматься над смыслом бытия! Зачем вы ГУИ превращаете в строку, а потом в цикле клиента дергаете сервер каждый раз? Что вам мешает сериализовать само значение справочника?
Зачем вы вообще массив создаете? Возьмите вашу таблицу формы конвертните в ТЗ, а ТЗ сериализуйте — 4 строки кода, и тоже самое при десериализации, всю вашу идею можно уместить в 10 строк полезного кода :)
Зачем вы ГУИ превращаете в строку, а потом в цикле клиента дергаете сервер каждый раз? Что вам мешает сериализовать само значение справочника?
Пресловутая ссылочная целостность…
Зачем вы вообще массив создаете? Возьмите вашу таблицу формы конвертните в ТЗ, а ТЗ сериализуйте — 4 строки кода, и тоже самое при десериализации, всю вашу идею можно уместить в 10 строк полезного кода :)
Серелизуйте ТЗ с 2 строками и скажите сколько там в JSON осталось полезных значений, а сколько мусора в виде описания типов?
Смущает объем? Ну так помещайте в хранилище :)
Смущает.
С хранилищем думаешь меньше весить будет? там тоже будут хранится типы…
Да и не интересно это, всегда хочется поэксперементировать, что то новенькое попробовать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Размещение таблицы значений с помощью доп реквизита и расширения конфигурации 1С