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