Comments 17
Асинизатора вызывайте, спасайте Хабр
Вот если бы можно было текст опубликовать как текст... Или Вы думаете, если кому-то это понадобится, он не сможет открыть эти картинки в FineReaderе и скопировать оттуда текст?
Исправил на текст.
Добавил ссылку по которой можно скачать примеры кода
https://disk.yandex.ru/d/nm2ZTNl8MoOyXw
Прошу обратить внимание, что программисты 1С никогда группами не дизлайкают программистов языков низших уровней, потому как сами зачастую владеют этими языками.
Во-первых, неплохо бы описать в бизнес-терминах, что хотели считать. Потом объяснить выбор объектов -
что считаем на каждом регистре и зачем. А уже потом переходить к коду.
Во-вторых, код ужасен:
Очень много участков копипаста, где можно было общие действия вынести за предел веток "если". Было бы и компактнее, и понятнее.
Сообщения пользователю малоинформативны. Пример: "Попытка продать больше, чем есть" - что продавали? сколько было в регистре? Вы ради интереса выделите 50 документов в списке, запустите их проведение, пусть 5 из них выкинут ошибку с этим текстом - и попробуйте определить, к чему это и о чем.
Некоторые вещи в принципе лишние. В тексте запроса (соединение) "ПО ПродажаИнструментов.БиржевойИнструмент = НаличиеИнструментовОстатки.БиржевойИнструмент" не нужно, т.к. вы уже отбираете из виртуальной таблицы только 1 биржевой инструмент, и в основной таблице документа тоже только 1 инструмент, никаких других там не будет. Достаточно условия соединения "ПО Истина".
Группировка в этом же запросе по биржевому инструменту зачем? Откуда там появится несколько строк, чтобы их группировать? По-моему, бесполезная нагрузка на СУБД.
Использование блоков "попытка исключение" в механизме проведения - оно зачем? Если там вывалится исключение, даже если оно обработается таким блоком - то все равно будет "в данной транзакции уже происходили ошибки" и отказ от действия.
Код приведен не потому, что он особо умный. Просто в демо версии по ссылке он отсутствует. Это просто открытие кода по просьбе потенциальных покупателей тестирующих мое решение. Любой может купить и доработать по своим предпочтениям. Как я понимаю типовые решения не нравятся никому.
Красиво размазал
Архитектурные ошибки:
Про "количество" и "исполнено" в одном документе. Скорее всего это попытка описать ордера на покупку и продажу. В один момент они устанавливаются, а в другой исполняются. Эти моменты могут быть сильно разнесены во времени. Думаю, надо было делать 2 разных документа. Потому что при учете на одном документе, будет казаться, что оба события происходят в момент установки ордера.
Про "количествоОжидается" и "количество" - опять же попытка описать 2 разнесенных во времени события в одном регистре. Скорее всего надо было делить на 2 регистра: один для операций "ожидающихся", один для "выполнившихся".
Желание внутри процедуры проведения документа писать в используемые в документе справочники (для поддержания даты первой покупки) - плохо. Потому что вы пытаетесь менять данные, на основе которых и формируете движения документа. Скорее всего надо было сделать отдельный регистр сведений под это. Это и работать будет на порядки быстрее.
Спасибо за комментарии. Я подумаю.
На данный момент код написан так, чтобы он был легко понятен людям которые хотят и имеют финансы для того, чтобы создавать на этом шаблоне свои системы на платформе 1С. Это обычно люди с профессиями менеджер, бухгалтер, директор, владелец бизнеса. Именно поэтому код написан максимально просто и на языке 1С. (Отсюда и дублирование Если. Чтобы не править 10 страничные запросы кода запроса или текста проведения) Не думаю, что программный продукт на других языках, или написанный на 1С, но более сложно сможет заинтересовать инвесторов без опыта программирования. Большая часть Ваших предположений неверно.
Посмотреть и скачать свободную версию если вдруг захотите можно по приведенной выше ссылке. Лучше использовать СУБД PostreSQL. По моему мнению она действует не как транзакционник, а как версионник. Ей все равно куда писать в регистр сведений или в справочник.
Пользователи не создают руками эти документы. Поэтому сообщения системы и не читают никогда.
За более чем 5 летний опыт эксплуатации и тестирования системы ни разу не выдалось ошибки транзакции или нехватки остатков.
Так что согласно требованиям 1С "Если что то надо сделать не по стандартам экзамена и по другому никак, то можно нарушить стандарты."
"количество" и "исполнено" в одном документе это поля QUIK. Когда Вы выставляете заявку на покупку 10 лотов, то Количество равно 10. А исполнено это сколько из этой заявки на данный момент биржа обработала и исполнила. Оно меняется с течением времени. данный документ многократно перезаписывается. Если заявка исполнится полностью то количество будет 10 и исполнено 10. Иначе Количество будет 10, а исполнено например 5.
Куски блоков Если продублированы потому, что QUIK для такого рода заявки может поставить как статус "выполнено", так и "отменено". Хотя формально 5 лотов Вы все таки купили. Соответственно куски кода заранее разделены на блоки "если", чтобы если поведение QUIK при очередном обновлении изменится, то максимально быстро проанализировать и исправить код 1С.
Так как система в реальном времени многократно в секунду читает и записывает данные, то некоторыми правилами 1С для бухгалтерских учетных систем пришлось пожертвовать именно для ускорения работы.
Дополнительная группировка в запросе сделана для того, чтобы система построила дополнительный индекс по полю "Биржевой инструмент". Это интуитивное предположение для ускорения работы.
Дополнительная группировка в запросе сделана еще и для того, чтобы система гарантированно не сбойнула если вдруг в процессе передачи по ODBC MSACCESS из QUIK в 1С не получилось вдруг 2 или более записей информации по 1 биржевому инструменту. Формально при обрыве и восстановлении связи QUIK чистит таблицы передачи MSACCESS и выводит в них записи однократно. Но к сожалению это не гарантировано. Если пользователь выберет много инструментов для экспорта в QUIK то могут быть сбои. QUIK выдает в ACCESS информацию судя по всему по каждому тику (это мелкие доли секунды) и ODBC сильно напрягается на не особо мощных ПК/ серверах. Придется останавливать всю систему. Брать чистый файл ACCESS (именно чистый, а не с обнуленными записями) и запускать весь процесс с 0. Поэтому группировки вставлены во многие места в запросах, в которых в типовых учетных конфигурациях они излишни. В моем случае они являются дополнительным предохранителем от дублирования записей во вспомогательных промежуточных таблицах ACCESS.
Так как система не бухгалтерская, то в ней не сотни пользователей. В ней пишут основную информацию всего два регламентных задания. Они между собой не конкурируют. Поэтому наверно писать все в единый справочник будет быстрее с учетом скорости изменения данных (напомню это тики, а не секунды)
Вся дополнительная расчетная информация разнесена по отдельным регистрам. Они пишется / читается другими регламентными заданиями.
Дополнительная группировка в запросе сделана еще и для того, чтобы система гарантированно не сбойнула если вдруг в процессе передачи по ODBC MSACCESS из QUIK в 1С
Абсолютно не важно, откуда вы до этого загружали данные. Вы уже их разложили по объектам внутри 1с и у этих объектов простые и понятные правила: где может быть только 1 значение, а где несколько.
И в том запросе и при том расположении данных не появится 2 строки никогда. Поэтому группировать - это бесполезно тратить ресурсы.
Поэтому наверно писать все в единый справочник будет быстрее с учетом скорости изменения данных (напомню это тики, а не секунды)
Относительно чего? В 1с есть оптимизированные для быстрой записи объекты - это регистры сведений. Из-за своей нессылочной природы, более простого расположения данных по таблицам СУБД, а также возможности записи большим набором записей - они существенно быстрее справочников и документов.
Дополнительная группировка в запросе сделана для того, чтобы система построила дополнительный индекс по полю "Биржевой инструмент". Это интуитивное предположение для ускорения работы.
И это ложное предположение, так это не работает. А ведет к замедлению работы.
Я внимательно обдумал Ваше предложения разнесения по отдельным регистрам сведений информации (а так же и другие требования). Вынужден Вам отказать. Данное предложение не будет внесено в мое типовое решение. Основной причиной является то, что это приведет к необходимости многократного использования конструкций типа "ЗАПРОС В ЦИКЛЕ" (независимо от принципа воплощения хоть в запросной модели хоть в объектной), что заметно скажется на производительности системы. Напомню данные из QUIK в выдаются в интервале тик (мелкая доля секунды)
Сформулированные Вами требования законны, но в основной для систем бухгалтерского учета, в которых документы вводятся однократно либо редко меняются пользователями. В таких системах основной задачей является обеспечение постоянной скорости работы максимального числа пользователей и получение итоговой информации по внесенным данным.
В моей же системе основной задачей является обеспечение максимальной скорости работы 1-2 регламентных заданий, занимающихся постоянной синхронизацией информации QUIK и 1С через вспомогательные файлы ACCESS по ODBC. Напомню лучше использовать PostgreSQL базу данных для хранения информации из за особенностей хранения данных (версионирования новых объектов, а не изменения старых через транзакции как в MS SQL).
Мне кажется, что запись новых версий меньшего числа взаимосвязанных данных будет происходить быстрее.
Если Вы вдруг решите воспользоваться моим решением и твердо уверены в Вашей правоте, то сможете самостоятельно разнести информацию по разным регистрам. На данный же момент в процессе моделирования и воплощения системы я посчитал, что многократная перезапись 1 справочника и 1 документа будет происходить намного быстрее, чем если при этом будет еще и перезапись взаимосвязанных справочников и регистров сведений, куда будет вынесена вспомогательная информация. На эту мысль меня в свое время натолкнуло воплощение данных таблиц QUIK. Там вся информация сосредоточена в единой записи таблицы текущих торгов. Это информация и о самом инструменте и о ценах и об объемах. Это несмотря на то, что 3 нормальная форма таблиц существует уже сто лет.
Все остальные решения в моей системе были так же основательно мною ранее продуманы и внесены на основании анализа. Возможно Вы просто не достаточно хорошо вникли в суть задачи и способ ее воплощения.
Основной причиной является то, что это приведет к необходимости многократного использования конструкций типа "ЗАПРОС В ЦИКЛЕ" (независимо от принципа воплощения хоть в запросной модели хоть в объектной)
Это, конечно, сильно зависит от того, как вы пишете. Но в целом это будет работать быстрее, чем ваш вариант.
Потому что вы допустили ошибку при декомпозиции: вы смешали в кучу редкоизменяемые данные (название биржевого инструмента и вообще "о биржевом инструменте") и частоизменяемые (дату первой покупки. которая скорее является аналитической информацией над продажами). Природа этих данных различна: биржевой инструмент вам достаточно один раз создать, он никогда не изменится; а вот дата первой покупки может меняться условно тысячи раз в зависимости от того, как вы будете подсовывать файлы с данными для загрузки (например, самый неудачный вариант - подсовываем данные в обратном порядке, сначала самые новые, а затем к старым - дата первой покупки будет изменяться на каждую строку). Это создает тысячи перезаписей для не самого легкого объекта - справочника.
На эту мысль меня в свое время натолкнуло воплощение данных таблиц QUIK. Там вся информация сосредоточена в единой записи таблицы текущих торгов. Это информация и о самом инструменте и о ценах и об объемах. Это несмотря на то, что 3 нормальная форма таблиц существует уже сто лет.
И в этом есть хорошая идея. Но ошибка в декомпозиции все сильно испортила.
Комментарий для всех:
На данный момент разработанное мною решение может быть доработано как мною по пожеланиям покупателя, так и покупателем самостоятельно. Все зависит от наличия знаний покупателя в области ИТ. Продажа решения осуществляется по типовому лицензионному договору 1С (Неисключительная лицензия.) как самостоятельное решение, добавление к 1С Бухгалтерия 3, и как добавление к 1C Документооборот 3 КОРП.
Получение сертификата 1С совместимо не предполагается, так как QUIK работает только в Windows.
Существует возможность покупки комплекта поддержки решения. Т.е. своего рода получения свежих обновлений идей, которые поступят от других пользователей / покупателей решения.
Лично мне, чем больше покупателе выскажет свои пожелания, тем больше вариантов развития. Оставляю за собой право отказать в изменении типового функционала моего решения, но готов сделать платные доработки лично под заказчика исходя из его технического задания.
Так как данная сфера жестко не регламентирована законодательными актами, то вопрос скорости может совершенствоваться бесконечно. Спорить от теоретически выкладках бесконечно бессмысленно.
Существующая скорость меня устраивает. Других решений на платформе 1С в данной сфере пока нет. (хотя по идее должно быть много).
Более подробную информацию можно получить по ссылке приведенной выше.
При наличии заказчика, готового оплачивать разработку с 0 решения по его ТЗ могу предложить свои знания для разработки на Java, С, Python, MSSQL, PostgreSQL.
Каких либо религиозных убеждений как и на каком именно языке делать я не имею. При наличии аванса и ТЗ воплощаю любые фантазии заказчика. При наличии крупного аванса могу предложить дополнительно песни или сказки.
Оплата возможна как по безналу так и по Ю-Касса. Система налогообложения УСН 6%. Возможно расширение штата при наличии бюджета у заказчика. Оставляю за собой право отказать заказчику, при наличии более выгодных предложений.
Контактная информация в профиле.
Как торговать на Московской Бирже на русском языке (Платформа 1С Предприятие 8)