Zmeelov2vitkhvДа это доработка. И 1С считает это доработкой.То есть получается, что все, что нельзя сделать из коробки, есть результат доработок. Тогда я не понимаю тезиса "Продавайте настройки, а не доработки". К кому он со стороны фирмы 1С обращен? К франчам? Есть доступная инфа в открытом доступе? Чтобы не в перепеве?
Естественно к франчам обращен этот тезис. Что касается инфы - вэлком на партнерский форум.

Nitro_Junkie
Там дело не в том, что есть такой тезис или нет, а что выбора все равно нет. Вот вы пробовали что то в УТ11 дорабатывать? И как впечатления?

У меня на перенос подсистемы товарного планирования, без фин. части из ERP в УПП ушел месяц.

Кратко как это реализовано в ERP:

1.) Есть Настраиваемая СКД. Которая в том числе м.б. настроена или перенастроена пользователем из "предприятия".
2.) Есть интерфейс тоже на СКД для преобразования данных из Настраиваемой СКД, в строки документа планирования.
Т.е. первая схема берет данные из источников данных и через ТЗ передает это во вторую СКД, в свою очередь 2 я схема преобразует уже данные в строки документа планирования.
3) Настраиваемых схем СКД из пункта 1 может быть множество и они по цепочке могут передавать данные друг другу, но в конце цепочки всегда будет СКД из пункта 2.
4) Вся это может быть гибко настроено пользователем без всякого вмешательства программиста, кроме СКД из пункта 2.

-какие задачи пришлось решить:
-Обновление очень старой БСП в УПП.
-собственно сам перенос с допиливанием документов планирования.
-Разработка собственной реализации к источникам данных (т.к. та что была в ERP естественно не подходила к УПП):
Соответственно разработал две 1х "СКД" для плана закупок и плана продаж. Причем для плана закупок, чтобы данные не передавались по цепочке из нескольких СКД ~ 80 тыс строк(см. пункт 3 )(12 на год), а планируемые складские остатки м.б. рассчитаны помесячно на основании расчетов в предыдущем месяце, динамически генерировался 1 СКД запрос, кстати да, реализовал именно через Выполнить(<Кусок кода>), почему так не помню, но так мне показалось предпочтительней, чем генерация просто SQL запроса. SQL запрос там тоже генерился, но и динамически генерился код который генерил еще и этот SQL запрос.
-Разработка зубодробильного отчета, который тоже на СКД но табличный документ был нарисован отдельно, соответственно осуществлялась трансформация из СКД через несколько взаимодействующих ТЗ в нарисованный табличный документ.

-Заодно оптимизировал 1С алгоритм там при огромном количестве строк и уже не нужный контекст передавался на клиент, со всеми этими 80 тыс строк. Я думаю сейчас это 1С ники уже поправили. Ну а так как задач на оптимизацию у меня уже тогда была нескончаемая очередь, то такая оптимизация заняла у меня пару часов и заключалась в комментировании одной строчки кода.


Соответственно раз за месяц я справился с этой задачей, то все не так сложно в 1С конфах как вы пишите?

Да кстати, а что у вас с планированнием? Есть что-то подобное описанному мною? С формулами самостоятельно описавыемыми пользователем, настраиваемыми источниками данных, возможностью их сложения вычитания умножения и т.д. и т.п.

vitkhvпо цепочке из нескольких СКД ~ 80 тыс строк(12 на год), а планируемые складские остатки м.б. рассчитаны помесячно на основании расчетов в предыдущем месяце
Точнее т.к. планирования начинали делать ближе сентябрю, то получалось необходмо было бы в стандарте гонять данные между 12 + 6 месяцев и соответственно стольким же количеством СКД. Т.е. считаем складской остаток на основании текущих остатков-план продаж+План закупок. Соответственно если текущая точка удалена на 18 мес от последнего месяца года расчета, то пришлось бы использовать 18 СКД, т.к. каждый следующий месяц использует рассчитанный планируемый складской остаток предыдущего, который в свою очередь сам же использует расчетные данные предыдущего месяца. И так точка начала расчета смещается ближе к концу года при корректировке планов. Т.е. если начинаем перепланирование уже в текущем году на остававшиеся месяцы то если считаем в мае, то используем 7 СКД, по колтчеству месяцев оставшихся до конца года.

vitkhv-какие задачи пришлось решить:
-Обновление очень старой БСП в УПП.


Кстати обновление БСП в УПП не зря стоит на первом месте, т.к. по трудоемкости она действительно на первом и является весьма нетривиальной задачей. Поэтому и сидят 99,9999 % УПП на старой БСП. Я переносил тоже не всю БСП, а только нужные модули.

МодальноеОкнону объектная модель в скд это "на любителя"...



Я вот любитель, т.к. использование СКД позволяет хоть как то эмулировать ООП в 1С.

Последняя моя обработка на заказ, содержит в себе один супер-класс Первую СКД или класс А от которой наследуются остальные классы (B1,В2,Bn), потомки этой СКД, которые тоже СКД, каждый из которых есть вариант поведения выбранного пользователем. Соответственно также существует класс С - ТЗ на форме, который наследуется от первого СКД, нашего супер класса. В случае если метод не перегружен в классе B, то поведение класса С полностью наследуется от первой СКД, класса А.

МодальноеОкноили объектный конструктор запроса... кстати где он? кто-нибудь видел чтобы его использовали?


Вы про схему запроса ? Используют ее люди и даже поют дифирамбы как в этой статье. Я же для себя применения пока не нашел. Но данный вариант написания запросов завоевывает все большую популярность.

Кстати автором статьи вообще не описана Схема запроса, поэтому утверждение, что запросы в 1С это текст, глубоко ошибочно, что снижает релевантность статьи.

vitkhv класса С полностью наследуется от первой СКД, класса А.




Точнее класс C все же не наследуется от класса А а взаимодействует с ним через интерфейс класса Б, который в свою очередь наследуется от класса А. Но при начальной инициализации, при загрузке формы обработки класс С взаимодействует с интерфейсом класса напрямую.

vitkhvvitkhv класса С полностью наследуется от первой СКД, класса А.




Точнее класс C все же не наследуется от класса А а взаимодействует с ним через интерфейс класса Б, который в свою очередь наследуется от класса А. Но при начальной инициализации, при загрузке формы обработки класс С взаимодействует с интерфейсом класса А напрямую.

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

Я же сделал одну закладку, один компоновщик настроек с отборами и настройкой порядка выведенный на форму от СКД (класс А) и ДЗ на форме с возможностью переключения в режим плоской таблицы. И на каждый пункт стал запиливать вторую СКД- класс B.

В начале мне пришлось очень хорошо так повозиться, с наследованием, реализацией методов, переопределением и т.д., но зато потом каждый следующий пункт это было просто копирование схемы СКД (т.к. у нас все же не настоящее ООП) и доработкой запроса в ряде, пунктов в СКД класса B менялась одна, две строчки в запросе и перенастраивался вариант настройки, далее все работало само.
Моему коллеге же, все также на каждый пункт приходилось все так же рисовать закладку, описывать все методы и т.д., поэтому моя скорость разработки в разы превосходила его.

МодальноеОкно
вот почему функционал "Инструменты разработчика" от Tormoz IT не включен в типовые?

какого банана они заставляют изобретать какие-то "обработочки" для заполнения разнообразной хероты?



ИС от Tormozit вообще бесподобен, чем то напоминает LINQpad. А консоль кода в ИС гениальна, я например в конфигураторе с ИС очень редко что то кодю. И если бы 1С выкупила его и запилила для него отладчик, и нормальный intellij service к нему (ну или самое простое, используем, что уже там есть, но чтобы открывалось все с**а автоматично, без ctrl+enter), то конфигуратор, вообще бы нафиг был бы не нужен для разработки. Но 1С пилит свой ИС, который на данный момент совершенно убогий. Как правильно сказал автор сабжа в статье, с бюджетами 1С они могут себе это позволить и им совершенно пофиг на мнение каких то там разработчиков. И видимо как и с Оферковым у них получиться полная лабуда, и ИС не купят, и свои ИС толком не наваяют, потому как на мнения разработчиков им уже давно и откровенно плевать.