0. skv_79 168 24.07.19 17:38 Сейчас в теме

Как проводятся документы в типовых конфигурациях от 1С

В свое время, когда только начинал шаги в 1С и изучал, как проводятся документы в конфигурациях на платформе 1С по книге "Разработка управляемого интерфейса" (Хрусталева Е.Ю.), и там были представлены примеры совсем далекие от того, как сейчас проводятся документы в современных конфигурациях от 1С.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. GROOVY 2499 24.07.19 23:58 Сейчас в теме
Там как бы много авторов https://its.1c.ru/db/pubmanagedui
А так выглядят материалы для типографии:
https://drive.google.com/drive/folders/0B2f7eow3JbLZcVhZOWtNN2ZUOHFydjVRM2s5MmxLZ­w?usp=sharing
:)
user774630; VooDOOPRo; creatermc; pbabincev; EMelihoff; sm.artem; +6 1 Ответить
5. skv_79 168 25.07.19 09:13 Сейчас в теме
(1) Да, авторов много, но Хрусталева шла первой в моей редацкии, поэтому запомнилось :). Да, согласен, это моя первая статья и наверно она очень далека от типографских стандартов.
2. bulpi 158 25.07.19 08:43 Сейчас в теме
Автор,
англоязычные люди не зря придумали аббревиатуру ИМХО.
конечно намного лучше и правильнее использовать типовой подход "Проведения документов" при выполнении процедуры проведения.

Вот тут вместо "конечно" напрашивается "ИМХО". Я бы плюс поставил, полезная статья. Но безапелляционно утверждать, что этот БРЕД БРЕДЯЦКИЙ (ИМХО, конечно) - это образец для подражания - .... слов нет.
rovenko.n; philya; +2 1 Ответить
6. skv_79 168 25.07.19 09:16 Сейчас в теме
(2) Вся эта статься - ИМХО, мое видение как это работает в типовых.
Трактор; +1 Ответить
3. DoctorRoza 25.07.19 08:50 Сейчас в теме
Ну такое нужно знать, как Отче Наш.
4. Aftee 25.07.19 09:09 Сейчас в теме
Увидев заголовок статьи, радостно подумал, что наконец-то смогу приблизится к пониманию алгоритмов проведения документов в ЗУП 3.1. Увы... Схема проведения - возможно, но остальное... Либо разбираемый пример в статье слишком простой (как большинство разбираемых примеров, так уж завелось), и в других документах дела обстоят "немного иначе", либо зависит от конфигурации (хотелось бы думать, что второе).
Summer_13; philya; begemot; acanta; +4 Ответить
7. skv_79 168 25.07.19 09:18 Сейчас в теме
(4) С ЗУП дела не имел, поэтому не могу сказать как там проводятся, эта статья для ЕРП и УТ. И для нее взяты самые простые документы в конфигурации, т.к. статья написана для ознакомления (читать начинающего работать с типовыми конфигурациями) со схемой проведения.
24. philya 77 31.07.19 10:11 Сейчас в теме
(7) как-как... ЗУП прекрасна. Глубина стека вызовов уровней в 10-15. Множественные вызовы функций из одной строки, которые просто вызывают следующую функцию. Запросы в 100 килобайт текста. Несколько почти одинаковых запросов по списку сотрудников.

И вишенкой на торте где-то в конце списка настроек галочка "оптимизированный расчет зарплаты" с комментарием "выключите, если зарплата считается неправильно", которая после обновления оказывается установленной.

Вспоминаем ЗУП 7.7, которая с меньшим числом свистелок, но фантастической скоростью считала ту же самую зарплату и плачем. )
28. CMK0001 02.08.19 12:53 Сейчас в теме
8. PLAstic 219 25.07.19 10:03 Сейчас в теме
(4) Пример вполне классический для УТ11. Поверхностно рассмотрен механизм контролей, в остальном достаточно для понимания.
20. Бубузяка 62 28.07.19 13:21 Сейчас в теме
(4)
либо зависит от конфигурации

В БП несколько по другому, но, в целом, подход такой же. Через МВТ набираются таблицы значений.
9. PLAstic 219 25.07.19 10:05 Сейчас в теме
Я бы рекомендовал:
1) Вернуть шрифт в стандартный для статей. Мне показалось, он мелкий и пришлось увеличивать до 120% масштаб.
2) В картинках убрать чёрный курсив и выделить имена процедур красной рамкой. Очень плохо читается.
3) Загрузить текст в ворд и исправить орфографию и пунктуацию.

В остальном нормальная статья. Добавил себе, буду новичкам скидывать.
AlbinaAAA; Summer_13; Darklight; cleaner_it; +4 Ответить
10. DBOdin_Lab 25.07.19 10:07 Сейчас в теме
Знать это все хорошо и правильно.
Но давайте взглянем на эту технику проведения под иным углом.
Мы все хотим быстрого проведения. Самые большие задержки возникают от обращений к базе данных. А теперь давайте посчитаем, сколько запросов к базе данных выполняется в процессе проведения (не считая записи результирующих движений):
1. Чтение реквизитов шапки документов;
2. Чтение табличных частей;
3. Запись временных таблиц (не зря же используется МенеджерВременныхТаблиц);
4. Чтение из временных таблиц;

Но если подумать, то все (или почти все) нужные нам данные уже есть в объекте. Можно заполнить движения без дополнительных обращений к базе.

1С, как я думаю, хочет обезопасить проведение от данных, измененных по сравнению с записанными в базу. Но этого можно избежать просто проверив модифицированность объекта в обработке проведения.

А вы что думаете?
11. dhurricane 25.07.19 10:21 Сейчас в теме
(10)
или почти все
Мне кажется, что как раз из-за того, что очень часто обращения к БД не избежать, получение реквизитов выполняется всегда запросом.

можно избежать просто проверив модифицированность объекта
Продолжите, пожалуйста, свою мысль. Как именно избежать? Что предполагается делать после проверки?
12. DBOdin_Lab 25.07.19 11:05 Сейчас в теме
(11)
Продолжите, пожалуйста, свою мысль. Как именно избежать? Что предполагается делать после проверки?


В обработке проведения нужно проверить модифицированность объекта, и если она Истина, то вызвать исключение с описанием ошибки.
Дальше программисту нужно устранить в ПриЗаписи и в подписках изменение объекта.
13. dhurricane 25.07.19 12:03 Сейчас в теме
(12) Думаю, что ситуация, когда объект модифицируется в обработчиках "ПриЗаписи" или "ОбработкаПроведения", является нештатной, и скорее всего это осознанный шаг, на который пошел разработчик. Следовательно и исключение бросать бессмысленно - разработчик его просто "отключит".

Полагаю, тут удобство именно в том, что далеко не все есть в табличных частях и реквизитах, и часто требуется запросом получить дополнительную информацию. Плюс есть возможность используя один и тот же программный интерфейс отразить движения документа без его перезаписи, т.е. без получения объекта, используя одну ссылку.
15. DBOdin_Lab 25.07.19 13:10 Сейчас в теме
(13)
Плюс есть возможность используя один и тот же программный интерфейс отразить движения документа без его перезаписи, т.е. без получения объекта, используя одну ссылку.


Соглашусь, что это может быть востребовано в групповом перепроведении документов.
Но к сожалению, в типовой Бухгалтерии такого решения нет, там всегда выполняется запись документа.
А запись документа - это самый тяжелый запрос к базе.

Как бы мне хотелось увидеть когда-нибудь групповое перепроведение без записи!
21. Бубузяка 62 28.07.19 13:27 Сейчас в теме
(15) Если перепроведение подразумевает только "толкание" регистров, то документ записывать не надо. Вызываем в модуле менеджера "ПодготовитьПараметрыПроведения" и получаем набор таблиц необходимых для подготовки вспомогательных данных и формирования движений. Далее вызываем методы модуля менеджера документа или программный интерфейс общих модулей. Таким образом можно "двинуть" только те регистры, что требуются.
14. baracuda 2 25.07.19 12:46 Сейчас в теме
годно, только много букв. надеюсь осилю этот текст
16. triviumfan 10 25.07.19 20:55 Сейчас в теме
Была похожая тема: https://infostart.ru/public/1026226/
И ещё одна, не могу найти.
17. json 2504 26.07.19 07:59 Сейчас в теме
18. pasha_2001 26.07.19 16:42 Сейчас в теме
Вопрос в тему: В процедурах ТекстОтраженияВРеглУчете() где идет выборка для проводок часто можно видеть в запросе ЗНАЧЕНИЕ(Справочник.Валюты.ПустаяСсылка) КАК ВалютаДт, ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.ПустаяСсылка) КАК СчетДт,
Каким образом и где подбираются корректные значения в данные строки?
19. Rashid80 26 28.07.19 09:51 Сейчас в теме
А потом 1с поменяет эти правила (разумеется в типовых документах она все исправит)... И ваши корректные проведения вдруг окажутся некорректными. Пока это не объявлено как интерфейс или api - это риск.
Периодически натыкаюсь что экспортные процедуры общих модулей поменяли перечень параметров или стали не экспортными
Summer_13; philya; Darklight; +3 Ответить
25. philya 77 31.07.19 10:15 Сейчас в теме
(19) Еще бывает, что их просто удаляют. Поэтому стараюсь не ленится и вытаскивать код из общих модулей во внешние обработки целиком - потом возвращать работоспособность проще.
Rashid80; +1 Ответить
29. Summer_13 07.08.19 15:03 Сейчас в теме
22. Бубузяка 62 28.07.19 13:39 Сейчас в теме
Считаю, что это полезная статья.
Она для тех, кто только начинает поддержку и сопровождение типовых конфигураций или решил закончить со свободным творчеством.
1. Если писать в стиле, принятом в типовом решении, тогда ваши последователи легко освоят ваше творчество.
2. У 1С есть ресурсы на исследование и оптимизацию процессов, связанных с изменением данных в транзакции, у меня таких ресурсов нет. Поэтому я следую стандартам разработки и повторяю приемы поставщика.

Про риски. После обновления должно выполняться минимальное тестирование. Хотя бы на открытие форм и проведение документов. Этот процесс снизит риск лишиться работы.
23. Darklight 20 30.07.19 13:44 Сейчас в теме
За статью спасибо. Но, сам механизм, конечной. бредовый. Нет, идея правильная - разделять настройки, требования, сбор данных, действия и контроль на отдельные блоки это здравая идея. Но то, как архитектурно это построено и как реализован - это кошмар. Куча лишнего кода, нерациональное использование памяти, куча циклов, повторяющиеся условия, разбросанные по куче модулей алгоритмы - это бред. И даже унификация это бреда внутри одного документа страдает. И что-то я не увидел секции наложения управляемых блокировок (ну там где остатки не контроллируются постфактум)

На мой взгляд - описание проведения должно быть более декларативным, по чётко-выделенным секциям, желательно в особой текстовой (XML?) схеме, cодержащей:

1. Требования к получению настроек (общих (обычно функциональные опции), организации (учетная политика), документа (внутренние опции и режимы))
2. Требования к получению источников данных (таблицы и поля),и их блокировки
3. Описание алгоритмов преобразования источников в движения (обычно построчные - т.е. принимающие строку к обработке)
4. Требования к источникам данных (дополнительные фильтры, настроенные исходя из текущий настроек п.1)
5. Описание ожидаемых выходных данных - наборов движений
6. Описание схемы обработки данных: ветвления условий (если таковы есть для конкретных данных) и связанные с ними алгоритмы обработки
7. Описание текстов шаблонов возможных ошибок (если общие не годятся)
8. Требования контроля данных
9. Описание алгоритмов постобработки (если требуются)

Так вот, эти секции схемы должны заполняться операциями, зарегистрированными по документу, т.е. документ может совершать целый набор разных операций (как совершенно отличных, зависящих от режима), так и связанных (выполняемых вместе/последовательно).
Каждая операция должна должна иметь своё заполнение каждой вышеназванной секции - повторяющиеся требования - сворачиваются, требования с разными условиями - объединяются (а условия будут наложены уже при обработке), источники данных объединяются (я имею в виду, в первую очередь, объединение полей, но таблицы тоже могут объединяться через "ОБЪЕДЕНИТЬ ВСЕ" при наличии сложных условий "ИЛИ" - это уже задача внутреннего оптимизатора генератора финальной схемы, который, правда, должен операться на возможные хинты, оставленные архитектором схемы)

Ну и в итоге - на основе финальной схемы (кстати, учитывающей и операции и модификации, расположенные в расширениях) должна произойти кодогенерация алгоритма выполнения проведения документа, по заданному шаблону (для разных событий модуля документа - свои блоки кодогенерации, с расстановкой управляемых блокировок).
Правда, финальных схем может быть и несколько - если у документа есть несколько различных режимов поведения или схемы сильно отличаются в зависимости от учетной политики - тогда у документа должна быть небольшая доп секция условий ветвления - для выбора нужной схемы (вернее сгенерированного алгоритма, ей соотествующего) в начале проведения.
Так же, по хорошему, при кодогенерации должны быть получены все значения функциональных опций - должны быть проверены все ветки условий, на них основанные - всё что "ЛОЖЬ" - должно быть выброшено из кодогенерации, и соответственно - выброшено из обработки алгоритмами (например, не используемые поля таблиц). Если знаения опций различны для разных организаций - то генерируются раздельные схемы для каждой организации (ну, либо опция должна иметь пометку проверки только в рантайм).

В идеале должна получиться единая секция инициализации - сбора источников данных; единая схема построчной обработки источников данных (число циклов прямо пропорционально независимым источникам данных); единая схема записи наборов движений (число циклов прямо пропорционально числу выходных наборов); единая схема контря (число циклов прямо пропорционально числу выходных наборов); и единая секция постобработки.

Вот такое моё виденье того, как должно выглядеть современное проведение документов. Основаное на предварительно выполненных этапах:
1. Регистрация операций
2. Декларирование схемы (для каждой операции, и получение финальной схемы)
3. Кодогегенерация алгоритмов проведения (но основе финальной схемы или набора финальных схем)
4. Выполнение оптимизированного алгоритма, с минимальным числом циклов и обращений к базе данных

То есть - что-то типа ещё более продвинутой компоновки данных, но для проведения! Где исхначально есть несколько схем, которые перед кодогенерацией (не только запросов, но и алгоритмов обрабтки) ещё и объединяются в единую схему, с оптимизацией и выкидыванием лишнего.

P.S.
Кстати, операции, при декларировании своих схем - могли бы ещё ссылаться на другие схемы и шаблоны, установленные в конфигурации, например на различные шаблоны отражения регл проводок.

P.P.S.
И само собой, должен быть какой-то автоматизированный мастер-конструктор, позволяющий визуально (хотя поддержка макро-скрипта тоже не помешала бы) настраивать секции схемы для каждой операции (независимо, хотя сама опрация может имеить прописанные зависимости от другой операции, и элементы, наследуемые из неё, при этом может их расширять)
26. skv_79 168 31.07.19 18:16 Сейчас в теме
(23)Интересная мысль про новую "Схему СКД" для проведения документов. Но вот мне кажется 1С сейчас сконцентрированы на другом: расширения, EDT. Про движения, наверно, вспомнят еще не скоро... Скажем так, сейчас в 1С развиваются те технологии, монетизация который достаточно высока. А обычном программисте, который пишет там свои движения, никто особо и не думает :)
27. Darklight 20 01.08.19 10:30 Сейчас в теме
(26)Не согласен с тем, что компания 1С сейчас не думает о программистах. Как раз со времён выхода 1С: Предприятие 8.3 очень даже думает. Не так много, как хотелось бы (вот, язык - вообще не развивается), но тут во много всё ограничивается консервативным настроем руководства (а может и ведущих архитекторов) компании, на то как должна развиваться платформа, в т.ч. в части конфигурирования, и внешнего вида для пользователей (и тут переход на УФ и управляемое приложение уже был гигантским скачком, надо заметить - что фактически этот скачок пока так и не завершён - и его можно смело считать не особо успешным).

А то, о чём я написал в (23) возможно только во одном из сценариев (или одном, плавно перетекающим в другой):

1. Представление совершенно нового продукта с иной архитектурой - а-ка 1С: Предприятие 9 - крайне маловероятный сценарий на ближайшие десятилетия

2. Создание расширения (плагина) для IDE EDT (хм... кстати, не только для EDT - такой плагин можно было бы создать для многих редакторов, поддерживающих редактирование 1С, например для Visual Studio Code - но в них в таком плагине нет большого смысла, без других плагинов, которые есть в составе EDT) – которое (расширение IDE) могло бы управлять новыми видами элементов проекта - генерируя классические выходные метаданные для загрузки в платформу (и в конфигуратор; без поддержки оных самим конфигуратором) - сценарий интересный, но трудно представить что кто-то за него возьмётся в ближайшие лет десять, по крайней мере, пока EDT не станет популярнее, чем конфигуратор (и не будет ему ни в чём ступать, по крайней мере при разработке управляемых приложений, ну разве что в скорости EDT наверняка всегда будет медленнее, классического конфигуратора)

3. Создание внешнего препроцессора для конфигурации (для классического конфигуратора, или для EDT - это не важно), который на основе, скажем, XML схем будет их объединять, совершать кодогенерацию и встраивать результат в целевую конфигурацию (через загрузку файлов) - этот сценарий проще 2-го, такой препроцессор сделать не очень сложно, но, хорошо бы ещё иметь визуальный редактор для XML схем - в принципе это всё можно налабать на 1С, а для препроцессора хорошо подойдёт OneScript движок). Другое дело, что таким решением пользоваться будет менее удобно (чем встроенным в IDE) - как минимум возникает две конфигурации (хотя можно и одной обойтись - тут много вариантов как это всё организовать), одна из которых будет являться исходником, а вторая - целевой после генерирования – либо рабочей, либо тестовой, либо посредником между ними. Но вряд ли это будет популярное решение из-за его извращённости

4. Ограничится только библиотечным фреймворком внутри конфигурации. Этот вариант сильно урезан по возможностям, в первую очередь по оптимизации, но основные принципы ( по крайней мере для алгоритмов проведения) предложенного мной решения вполне реализуемы просто ручным разнесением алгоритмов по заданным секциям модулей, и соблюдением определённых правил (API) такого фреймворка. Это сценарий, близкий к тому, что сейчас делается в типовых конфигурация 1С, просто подразумевает более продвинутую структуру чётких правил и требований по их соблюдению. И главное - ориентированность на модульность исходных данных и то, что их "фабричное" состояние не является финальным, и конченый потребитель может их расширять и модифицировать в широком диапазоне, не изменяя напрямую код поставщика. Тут очень хорошо подойдёт парадигма аспектно-ориентированного программирования (ну или хотя бы применение стратегии DI - Внедрение зависимостей) - чего так не хватает конфигурациям 1С (ну а если бы стратегию АОО поддерживал язык платформы 1С, как, например, нативно поддерживает язык Eiffel или AspectJ (многие другие языки поддерживают хотя бы DI через библиотеки), было бы вообще очень круто).
Тут так же хорошо бы иметь какой-то визуальный генератор хотя бы начального шаблона - правил - который проще было бы уже потом соблюдать.
Эта стратегия не сложна - и вполне реализуем уже в этом десятилетии

5. Комбинированный вариант 3. и 4. Здесь препроцессор встроен в рантайм. То есть - настройка схемы осуществляется в XML (ну или ином формате, это не важно, в виде макетов), которые сохраняются в конфигурации (алгоритмы так же сохраняются в конфигурации но в общих модулях, в схеме - только ссылки на них), а при проведении документа - схема XML "интерпретируется" на лету так же на лету происходит некоторая кодогенерация (в основном запросов, ну и некоторых коллекций) и через оператор "Выполнить" осуществляется запуск нужных алгоритмов в нужной последовательности в универсальном алгоритме обработки проведения, с применением стратегии DI - Внедрение зависимостей, с помощью которой в алгоритмы передаются некоторые сгенерированные части кода и данных.
Этот вариант очень хорош для тестирования, и несильно требовательного к производительности "продакшена" - а ну а для релизов в рабочие базу - лучше автоматически конвертировать-таки конфигурации, например, через вариант 3.
Это тоже не шибко сложный вариант, но он один из самых ограниченных по возможностям. Его можно сделать где-то за год, а базовые рабочие реализации получить за пару тройку месяцев

Но, всё это здорово - но не так интересно для широкого применения. Ибо, пока типовые конфигурации не будут применять данную стратегию - то и на практике у программистов, поддерживающих типовые решения, не будет большого стимула делать то же самое. Но для разработки новых документов, или вообще независимых конфигураций или сложных расширений для типовых конфигураций - данные стратегии вполне себе могли бы применяться - но на их массовую популяризацию тоже уйдут десятилетия, если, конечно, эти стратегии, не загнуться раньше, уступив место чему-то более продвинутому.

Кстати говоря, данные варианты стратегий тоже могли бы быть прибыльными - т.е. можно разработать варианты, когда их внедрение могло бы принести доп доходы разработчикам - хоть это всё будет "от лукавого".


P.S.
Ну а вообще, говоря о сборке документов из операций, я имел в виду не только проведение. Но и формирование печатных форм, авто сборку интерфейсов форм, да и, вообще, сборку всего объекта метаданного (включаемая элементы хранения данных и прав доступа к ним). То есть предложенное мной решение - это прямая дорого к стратегии модульных конфигураций, имеющих принципиальное отличие структуры редактируемой конфигурации от конфигурации ИБ (конфигурация ИБ должна генерироваться путём сборки редактируемой конфигурации из множества отдельных составляющих, с отключением неиспользуемых элементов и блоков кода, и применением автогенерации, как алгоритмов, так и даже элементов метаданных; а в идеале ещё и с выполнением макроскриптов преобразований существующих метаданных и выражений кода и генерации новых по заданным шаблонам, параметрам, значениям функциональных опций, и анализу метаданных конфигурации).
Это всё возможно только в стратегия 1. и 2. (ну в 3. тоже возможно, но эта стратегия всё-таки подразумевает применение более простого препроцессора - так что в ней это всё только с ограничениями - а иначе - лучше переходить к стратегии 2.)

P.P.S.
Но да, это всё слишком круто для нынешнего платформы 1С Предприятие 8 - и компания 1С на это вряд ли решится в ближайшие десятилетия - они и так неплохо зарабатывают. Вот когда они нащупают пути расширения бизнеса - особенно в другие странны, тогда они, возможно, будут разрабатывать новый продукт - а-ля 1С: Предприятие 9, который изначально будут закладывать так, чтобы ему было чем потягаться с западными конкурентами. Вот там, возможно, и развернётся борьба за притязательного клиента, где нужно будет завлекать оригинальными фишками и не пасовать перед фишками, уже доступными в конкурирующих продуктах. Вот тогда, уже может и спадёт пелена консерватизма... Ну это уже не при братьях Нуралиевых случится...
Доживём?
30. Summer_13 07.08.19 15:08 Сейчас в теме
Возможно я плохо смотрю,но не могу найти примера именно формирования таблицы движений из какой-то табличной части.Мне вот это более интересно.
31. skv_79 168 07.08.19 15:13 Сейчас в теме
(30) п.2 схемы проведения:
По параметрам этих процедур видно, что они одинаковые. И выполняют одинаковую цель - добавляют в тексты запросов для каждого из регистров, по которым будут сформированы движения, которые будут отражены в регистрах.
Названия у них, как правило: "ТекстЗапроса" + "Таблица" + ИмяРегистра, где ИмяРегистра - имя регистра, движения которого будут формироваться этим запросом.
32. Cyberhawk 117 02.09.19 17:08 Сейчас в теме
В Дополнительные свойства "ДляПроведения" вставляется свойство "РегистрыДляПроведения"
Походу опечатка
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Красноярск
зарплата от 50 000 руб.
По совместительству

Программист 1С
Санкт-Петербург
зарплата от 100 000 руб.
Полный день

Технический лидер, архитектор 1С, руководитель проектов
Санкт-Петербург
зарплата от 150 000 руб.
Полный день

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Специалист техподдержки 1С
Москва
зарплата от 80 000 руб. до 120 000 руб.
Полный день