Конечно, в режиме 1С Предприятие нельзя создавать документы и справочники, зато можно обеспечить иллюзию этого. А ведь, как известно, если что-то выглядит как утка, плавает как утка, крякает как утка, то, должно быть, это и есть утка. Предлагается конфа с конструктором документов такого вида (сверху – как задается, внизу — результат, как это выглядит для пользователя).
Есть справочник, в котором описывается, из чего будет состоять документ и какие он будет делать движения. Создается новый вид операции – это и будет новый «документ». Описываются поля шапки и табличных частей. Для реквизитов задается виртуальный «тип реквизита» «номенклатура», «контрагенты» и т.д. На самом деле это виртуальные справочники, которые создает пользователь, но для пользователя разницы нет. Когда он щелкает по реквизиту «Контрагент», у него открываются контрагенты, по номенклатуре «Номенклатура» и т.д. Можно создать столько «справочников», сколько нужно – на самом деле это просто папки справочника «Ресурсы», но пользователь документа об этом не догадывается.
Также в документе надо прописать заполнение реквизитов при выборе и расчет зависимых реквизитов, например, сумма = цена*количество. У каждого элемента виртуального справочника могут быть произвольные реквизиты – аналогично типовым конфигурациям. В конструкторе можно задать заполнение этого произвольно реквизита в создаваемый документ. Например, я создал в «номенклатуре» реквизит «Цена» и сделал, чтобы он заполнялся при выборе номенклатуры.
И, собственно, для каждого документа нужно описать движения. Каждое движение – это одна строчка. Модуль проведения каждого вида документа намеренно прост. Я считаю, что проведение должно быть максимально простым, а все необходимые данные для движений должны быть подготовлены в табличной части. Например в реализации и перемещении в ТЧ присутствует партия и сразу себестоимость (скрыта в форме) – т.е пользователь выбрал партию, себестоимость зафиксировалась и, сколько документ ни проводи, ничего не поменяется. Движения можно делать по регистру остатков, оборотов и сведений – все как в обычных конфигурациях.
Отдельно стоит упомянуть режим подбора из остатков – его также можно конструировать. Я сделал подбор остатков партий, чтобы считать себестоимость. Его можно использовать для подбора, например, заявок на расходование ДС под платежи, кредитных документов и т.д.
Для примера я сделал в конструкторе несколько характерных документов для УТ – поступление, перемещение, реализация, ПКО. Это заняло меньше 5 минут. Документы двигаются по регистру остатков товаров по складам, в котором сразу себестоимость (кстати себестоимость получается сразу), по взаиморасчетам, вспомогательным для аналитики регисрам Продажи, Закупки, Остатки денежных средств.
Чего тут не хватает для полноценной системы?
Печатные формы, обработки заполнения табличных частей, подбора — пишутся внешние и прицепляются страндартными средствами. Отчеты тоже внешние. В 3х видах регистров (остатки, обороты и сведения) есть достаточно данных, чтобы написать любой отчет. Т.е. констуктор, собственно, создает «документы» и движения к ним, а получение данных в виде печ. форм или отчетов — это задача уже слишком специфическая, чтобы можно было сделать какой-то конструктор — на то есть СКД.
Для чего это нужно?
Как уже было сказано, на этом можно сделать небольшой в несколько документов модуль к имеющейся конфе, либо самостоятельную простенькую конфу. Также можно применить при моделировании техпроекта с заказчиком – быстро набросать документы и показать заказчику, как это будет выглядеть в реале, чтобы обсудить какие-то вопросы.
Продолжение темы :
Группа для вопросов-ответов, пожеланий, обмена опытом: //infostart.ru/community/groups/1183/
UPD 30.07.2024 Добавил базу с демо-примером и правила обмена для переноса настроек
UPD 12.08.2024 Выложил демо базу с новой конфигурацией (убрал отдельно CF т.к. его можно взять из базы):
-добавлена проверка обязательных полей
-обработчики заполнения табличных частей
-названия таб частей
-количество таб частей увеличено до 3-х
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Звучит отлично. И потом можно развивать этот костяк расширениями.
Спасибо. У меня такие же мысли по этому поводу. Если людям понравится и будет полезно то тут еще можно развивать и развивать. Идей куча.
(0) Еще можно прикрутить сюда же возможность прописывать произвольные алгоритмы на встроенном языке для различных событий, например, таких как «Перед записью», «Обработка проведения» и т.д.
Подобный аналог подсистемы, но более функциональный и гибкий, используется в конфигурации «БИТ:ФИНАНС КОРП», в ней есть практически все для этих целей — начиная от конструктора структуры документов и описания алгоритмов заполнения как самого документа, так и его движений по произвольным регистрам, заканчивая формированием отчетов по этой подсистеме.
Bassgood, (3)
Добавить CRM 2.0 идею построениеБизнесПроцессов.
Почту, КонструкторПечатныхФорм и на Продажу.
Но боюсь уйму времени уйдет на отлатку и оптимизацию.
Я думаю на рынке нужен такой проект.
Правильная ссылка на группу.
Идея отличная. меня интересует в плане моделирования справочников динамически, то есть в режиме 1с. Нечто подобное видел в Инталев: корпоративный менеджмент
Сколько видел «универсальных» решений, типа «Инталев…», «БиТ…» и пр. и пр.
Что бы в них что-то создать более менее серьёзное, «пользователь» должен:
1) обладать умениями и навыками «моделирования» бизнес процессов
2) отлично знать и разбираться в учетных механизмах (бухгалтерия, зарплата, складской учёт, производство, расчет путевых листов и куча других — по нужному профилю)
3) изучить «с нуля» новую для себя «среду разработки». Т.е. данное «универсальное решение». И не зная всех его идеологических и технологических нюансов (а они никогда не могут быть полностью описаны) набить некоторое количество «шишек» которые для остальных пользователей обернуться кучей «перепроведений» и «перезаполнений».
ИТОГО: для такого «универсального внедрения» требуется наличие нескольких «специалистов» (идеолог, методолог, «программист»…) которых как правили нет у конечного потребителя по определению, т.к. не нужны для его бизнеса. Эти специалисты должны выучит новый для себя продукт и «набить шишки» на его «нюансах».
ПОЭТОМУ — как правили «внедряют» и «настраивает» этот «универсальный продукт» сам его автор (или его дилеры которые могут получать методологическую поддержку у автора).
ЛИЧНО МОЁ МНЕНИЕ: Это только маркетинг. Так как купленное «универсальное решение» внедряется не силами покупателя или путем увеличение его штата нужными специалистами….
ЗЫ Не совсем к данной публикации — но накопилось 😉
(5) Steelvan, Спасибо!!!
(7) AnryMc, Еще к минусам вышеперечисленных конструкторов можно добавить закрытые участки кода. Делаешь делаешь внедрение, вдруг бац надо сделать проводку а конструктор это не умеет или глючит и ты такой лезешь в модуль поправить а его нет. И ты понимаешь что толку от того что ты до этого сделал на конструкторе — ноль и надо все писать самому, а время потеряно. Сам на эти грабли наступал с БИТфинансом.
(9)
Аналогичные «грабли»
Только для демонстрации «приблизительной схемы работы» +1
(7) AnryMc,
Не знаю по мне такое решение имеет смысл.
Да конечные пользователи не смогут и не будут в этом копаться и разбираться.
Но ситуация немного другая.
1. Многим пользователям 1с не нужен весь функционал Торговли 11, или даже розницы 2.0.
А тут набросал им то что они хотят и пользуйтесь, захотели ещё, что то добавил.
2. Идеальный вариантом для данной конфигурации хорошо бы создать Выгрузку загрузку шаблонов.
Что имеется ввиду — это создать набор документов, справочников движений для учета склада кладовщику,
после выгрузить в шаблон. Создал шаблон менеджеру, снабженцу. После клиенту составил нужную программу учета
из шаблонов.
(9) да даже открытый код не гарантия. бывает открываешь, копаешь, копаешь, копаешь и потом понимаешь, что проще было самому сделать, более простой вариант, но работающий. а все из-за сложности написанного или из-за качества сложности написанного.
(7) AnryMc, абсолютно согласен. имхо вариант таких вещей возможен и жизнеспособен для случаев кодогенерации более простого.
(12) serg1983,
У Инталева — есть/были шаблоны
(12) serg1983,
Вопрос зачем «конструктор» если всё равно нужен специалист но «заточенный» под это решение
Не проще ли сделать функционал более богатый — а программистов 1С «для рихтовки» под клиентов — достаточно
ВЫВОД: Кстати это ещё один метод защиты своей прибыли и отсев конкурентов — т.е. «покупатель» «универсального решения» найдет клиентов только у продавца!!!
(12) serg1983, Добавил для скачивания правила для переноса шаблонов — обычные правила для универсального обмена XML. Спасибо за подсказку.
(14) AnryMc,
Покупатель может и не покупать у продавца.
Он может нанять Специалиста, или купить себе другую конфигурацию, что то подобие УПП и тратить время как же его отработанный механизм работы организации приспособить или перестроить для работы программы.
ОООООООООООО, si! Est моё решение такое же было на 7.7! Всего 2 документа в торговой программе — движение товаров и движение денег. При их создании выбирается направление движения, которое и указывает что куда проводить.
Есть даже торговец финиками-орешками, который по сию пору работает на ней и даже слышать ничего не хочет о переходе на другую версию — настолько всё шустро у него летает.
все новое — это хорошо забытое старое 🙂
(7) AnryMc,
Автомобиль — то же универсальное решение и что бы научиться им управлять, а тем более — настраивать, необходимо либо потратить много времени, либо много средств.
Главное, в конечном счете, что это универсальное решение, после первоначальной настройки может быть легко доработано.
Причем, никого не надо выгонять из базы для обновления конфигурации. Ночью тоже работать ради этого не придется.
И не менее важно, это универсальное решение позволяет внедренцу решать свою задачу быстрее, что приводит к повышению эффективности.
Знаю по себе.
Я работаю внедренцем 8мь часов в день. Закрываю в среднем 170 часов.
Есть вопросы — спросите меня «как».
Делал такие ещё на 7.7, совершенно реальная вещь и идея отнюдь не нова. Проблема лишь одна — вы не автоматизируете предприятие, а даёте кому-то в руки просто более другой инструмент той же автоматизации; эдакая 1С в 1С. И тут нужны толковые методисты и просто спецы, чтобы таким супер-универсалом грамотно воспользоваться, иначе это мертворожденный мини-конфигуратор и всё. Опыт показывает, что при отсутствии грамотных товарищей, умеющих применить сей инструмент, он бесполезен.
Где то здесь уже было похожее решение…
Добавлю также к недостаткам:
1) производительность. Наверняка все справочники развернуты в плоскую таблицу, где 1 строка представляет 1 реквизит конкретного справочника. И уж в любом случае все справочники лежат в 1 таблице друг с другом. Какие там индексы, в какие из них попадет программа при соединении в запросе? очень туманно.
2) формы. При наличии элементов на форме больше 20 начнутся проблемы с тем, как же все это компактно показать — понадобятся вкладки и прочие возможности конфигуратора.
3) обмен данными. Конвертация данных увидит эту странную таблицу, где смешаны все справочники, но вот как превратить это все в нормальный объект? Это будет на порядок сложнее.
А что с синхронизацией по УИДам 1 элемента справочника? а скорее всего у нас нет УИДа элемента — у нас есть уид каждого реквизита 🙂
4) обязательные поля для заполнения. Видимо их никак не указать.
5) зависимые поля (вспоминаем Номенклатуру и Характеристику в типовых). Пользователю будет неудобно выбирать характеристику без отбора по владельцу.
6) расширяемость с точки зрения пользователя. Вот набросали вы решение на этом конструкторе, взяли с клиента 10 тыс руб. Затем клиент хочет добавить особое заполнение одного документа на основе 2х других — в его понимании это довольно простое действие и оно не будет стоить много, а у вас оно не вписывается в конструктор — и стоимость выйдет высокая, т.к. это либо грязный хак, либо переписывание в обычный конфигуратор всего решения.
(7) Абсолютно прав.
Трудно даже представить что будет, если после реализации какого-то документа и ввода данных по этой структуре Вы решите изменить эту структуру (чисто гипотетически). Настройка обменов между базами тоже весьма проблематична.
(22) mixsture,
Спасибо за конструктивную критику. Отвечу:
1) производительность.
Если речь идет о блокировках, то изоляция на уровне записей, снапшоты решают эту проблему, я не прав?
2) формы. При наличии элементов на форме больше 20 начнутся проблемы с тем, как же все это компактно показать
Давайте подумаем о том, зачем в типовых конфах овер20 реквизитов на форме? Может таким образом 1С реализует свой вариант универсальности в типовых конфах? Может 1С, выпуская ERP, УТ11 и т.д. хочет чтобы ее конфа из коробки подходила для большего количества предприятий и пихает кучу реквизитов из которых на данном конкретном внедрении не использутеся половина?
.
Согласен и не согласен. Я уже писал обмен под реальные условия. С одной стороны проще т.к. 1 в 1 , с другой надо помнить реквизиты. Это же касается разработки отчетов.
У справочника есть УИДы . Т.е. у каждого элемента будь то контрагент, номенклатра и т.д. есть свой УИД.
Я это не реализовывал, но наверно сделаю. Это просто.
это сейчас тестирую — попросили. В конфк это уже есть справочник «Агрегаты», подчиненный справочнику «Ресурсы» но не доведен до ума. Сейчас доделал.
конфа открытая, бесплатная и простая как хозяйственное мыло. Там реально мало программинга.Любой начинающий программист разберется. Фишка больше в архитектуре. Я сделал, применил и увидел что результат превзошел мои ожидания. Обрадовался. Решил поделиться на инфостарте.
А можно архивом все 3 файла выложить?
(26) Spec1c82, Конфу можно не скачивать, а выгрузить из базы (dt).
(27) Да то понятно. Хотел еще глянуть на правила обмена. Впрочем дт-шку уже скачал.
А печатные формы документов подключаются стандартно или также свой механизм?
(29) pro1c@inbox.ru, Я использовал БСП но не стал это выкладывать т.к. не уверен что это не нарушает лицензию, всё-таки БСП — продукт 1С…
Если сделать конвертер для перевода виртуальной конфигурации в обычную, то данную разработку можно было бы использовать как конструктор конфигураций.
(31) vasvl123, Хорошая идея. Если бы 1С ещё что то типа XAML использовала вместо своих управляемых форм… Может дойдёт до этого — было бы проще.
Реализовал у себя на предприятии похожую идею. Началось с того что понадобилось хранить в учетной системе разнородную информацию , с разными наборами реквизитов.
Сделал универсальный справочник, для примера внес некоторые реальные данные, записал что то типа видео урока и выложил на корп. сайт. Идея оказалась очень удачной. Туда стали вбивать чуть ли не все подряд.. Потом реализовал и универсальный документ и универсальный отчет, движения по регистрам. Элементы справочника могут быть периодическими.
В настоящее время в системе около 40 видов справочников и документов.
Ко мне как к разработчику и методисту общаются не часто, чаще просят добавить какой нибудь функционал. Сейчас в разработке механизм автозаполнения вычисляемых полей и создание документов по результатам расчетов.
(30) Это зря.. любой, кто купил 1С Платформу — имеет право и на скачивание БСП..
(30) В смысле — с точки зрения лицензирования..
А вообще — БСП это тупиковая ветвь, ИМХО.. смотрите, как они наплодили её версий — т.е. не могут обратной совместимости обеспечить. Потому, что язык 1С — слишком простой, говоря мягко..
Переиспользование кода и его расширяемость тут — где до в начале 80-х, увы..
Добавить бы ООП, да сделать функций — переменными первого порядка, вот бы зажили!! Эх…
Хм, а зачем стартмани для демоверсии? Вот я захотел посмотреть демо, прежде чем принять решение о закупке, а у меня не получается.
(36) Да это полноценная версия. «Демо» — в смысле что там пример есть а не чистая база. Как в типовых.
Вот, если бы ещё вновь созданные документы отображались во «Все функции», то эта разработка стала бы величайшим заговором против 1Сников)
В действительности данный подход заслуживает внимания и может покрыть потребности в создании Лёгких документов.
Ещё лет 9 назад в УПП 1.3 я добавил один единственный справочник, на базе которого был реализован (могучий) инструмент выполнения дополнительного кода, инициирующийся при срабатывании множества подписок на события. Например, при начале работы выполнялись интерфейсные настройки на панелях пользователей. При проведении документов формировались сообщения для выгрузки в WMS-систему и т. д. И всё это «на лету».
На момент разработки я думал, что этот промежуточный слой кода временный… но он прижился, и сейчас без него корпоративная логика перестала бы работать.
Конечно, в настоящее время многие активно пользуются расширениями конфигурации, но в случае с УПП подход с промежуточным слоем кода и по сей день остаётся актуальным.
Так что для каждого конкретного случая может быть применён свой подход, дающий максимум эффекта.
(25)
5) зависимые поля (вспоминаем Номенклатуру и Характеристику в типовых).
это сейчас тестирую — попросили. В конфк это уже есть справочник «Агрегаты», подчиненный справочнику «Ресурсы» но не доведен до ума. Сейчас доделал.
6) расширяемость с точки зрения пользователя. Вот набросали вы решение на этом конструкторе, взяли с клиента 10 тыс руб. Затем клиент хочет добавить особое заполнение одного документа на основе 2х других — в его понимании это довольно простое действие и оно не будет стоить много, а у вас оно не вписывается в конструктор — и стоимость выйдет высокая, т.к. это либо грязный хак, либо переписывание в обычный конфигуратор всего решения.
конфа открытая, бесплатная и простая как хозяйственное мыло. Там реально мало программинга.Любой начинающий программист разберется. Фишка больше
Снапшоты решают только часть проблем.
Сами по себе документы по сути это только точка на оси времени (так же есть рекомендация хранить срез зафиксированных данных в табличной части для обеспечения неизменности при последующем перепроведении, но от этой вехи все чаще отходят), по методологии Вендора жизнь на предприятии пишется в регистры и решения принимаются на основании данных из регистров.
Отсюда вывод, что есть какой то универсальный регистр, чудя по скриншоту с простой структурой, который будет иметь огромное количество записей.
К чему это приводит можно посмотреть на реальной таблице субконто РБ наполнив хоть более менее бухгалтерский регистр.
Для тех кому лень — при достижении определенного числа записей за период — ломаются планы и простейшие запросы выполняются десятки секунд.
Решение конечно интересное, но:
Для микро баз проще накидать то же самое в конфигураторе.
Для серьезных баз универсальное хранилище в регистре станет узким местом.