В 1С одним из ключевых элементов системы являются регистры. Этот термин имеет свой аналог в английском языке — ledger. Он первоначально появился в бухгалтерской практике, но со временем его логика начала использоваться и в других сферах.
В отличие от 1С, где регистры являются одним из встроенных типов, в самой платформе lsFusion такого понятия нет. Зато в ней есть наследование, полиморфизм и агрегации, что, в частности, позволяет реализовать аналогичную логику регистров. В этой статье на примерах я покажу как именно.
Регистр — это набор записей, каждая из которых отражает некоторое изменение состояния для некоторого множества субъектов (или измерений).
В 1С различают 4 вида регистров:
Первые два являются узкоспециализированными и используется только для бухгалтерского учета и расчета заработной платы. Так как lsFusion — это универсальная платформа для разработки бизнес-приложений, то я рассматривать их не буду, хотя реализовать их достаточно просто. Остановимся только на последних двух типах регистров.
Регистры накоплений
Любую запись в регистре можно рассматривать как объект некоторого абстрактного класса. Предположим нужно реализовать простой регистр, который рассчитывает остаток по товару на складе.
Для этого объявим абстрактный класс SkuLedger:
CLASS ABSTRACT SkuLedger 'Регистр изменения остатка товара'; |
Формально, один экземпляр которого будет отражать единичное изменение остатка по заданному товару и заданному складу на определенное количество (положительное или отрицательное).
Зададим у него измерения как абстрактные свойства типов Sku (товар) и Stock (склад) соответственно. Их нужно будет реализовать при наследовании конкретных классов от класса регистра:
sku 'SKU' = ABSTRACT Sku (SkuLedger); |
Добавим свойство, которое будет обозначать время изменения остатка:
dateTime 'Дата/время' = ABSTRACT DATETIME (SkuLedger); |
И, наконец, добавим то, что называется в 1С ресурсом. А именно количество, на которое изменяется остаток данной записью регистра.
quantity 'Кол-во' = ABSTRACT NUMERIC[14,2] (SkuLedger); |
Теперь посчитаем текущий остаток на основе записей в регистре:
balance (Stock st, Sku sk) 'Остаток' = GROUP SUM quantity(SkuLedger l) IF stock(l) = st AND sku(l) = sk; |
По умолчанию, в базе данных не будет храниться текущий остаток. При обращении к нему будет формироваться запрос, который рассчитает его исходя из текущего состояния регистра. Чтобы оно хранилось постоянно и автоматически обновлялось при изменении регистра, нужно в конце его объявления добавить ключевое слово MATERIALIZED. Наличием этого флага, по сути, и определяется будет это регистр накопления остатков или оборотов в терминологии 1С.
Существует возможность на построенный таким образом остаток добавить ограничение на то, что он должен быть всегда положительным:
CONSTRAINT balance(Stock st, Sku sk) < 0 |
Платформа будет автоматически контролировать то, что при записи в регистр, остаток останется больше нуля. Если условие будет нарушено, то изменения не запишутся в базу данных, а пользователю будет выдано соответствующее сообщение. Кстати, желающие могут сравнить, как это ограничение реализовано в 1С УТ, чтобы оценить истинную боль, испытываемую 1С программистами.
При необходимости быстро считать оборот по товару, например, за год можно построить следующее свойство:
balance (Stock st, Sku sk, INTEGER year) = |
Обращение к значениям этого свойства будет мгновенным и не будет вообще трогать данные регистра. Похожим образом можно постоянно хранить любые выражения, рассчитанные на основе регистра, а платформа сама возьмет на себя ответственность за их обновление.
Аналогичным образом можно построить свойство, которое будет определять остаток на определенное время:
balance 'Остаток на время' (Stock st, Sku sk, DATETIME dt) = |
Для расчета этого значения будет сделан запрос, в соответствии с которым регистр будет прочитан полностью от начала до заданной даты. Но на практике обычно обращение идет к наиболее поздним датам. Поэтому, если текущий остаток является хранимым (MATERIALIZED), то логично рассчитывать это свойство в обратную сторону от текущего остатка:
balance 'Остаток на время' (Stock st, Sku sk, DATETIME dt) = |
Естественно, это будет эффективно выполняться, только если по свойству dateTime построен индекс:
INDEX dateTime(SkuLedger l); |
Весь код по созданию одного такого регистра логично положить в отдельный модуль, который затем подключать по мере необходимости.
Теперь покажем, как проводить по регистру документы. Предположим у нас объявлен документ поступления товаров на склад:
CLASS Receipt 'Поступление на склад'; |
Необходимо сделать, чтобы он проводился по созданному нами регистру. Для этого мы возьмем строку поступления ReceiptDetail и унаследуем ее от абстрактного класса SkuLedger:
EXTEND CLASS ReceiptDetail : SkuLedger; |
После этого нужно реализовать все абстрактные свойства регистра, указав конкретные свойства строки поступления, из которых будут браться значения:
dateTime(ReceiptDetail d) += dateTime(receipt(d)); |
Количество и товар мы подставляем непосредственно из строки, а время и склад из документа.
Рассмотрим более сложный случай, когда объявлен документ перемещения со склада на склад:
Перемещение со склада на склад
CLASS Transfer 'Перемещение со склада на склад'; |
Его также нужно провести по этому регистру, но уже дважды. Один раз он должен списать со склада (откуда) перемещенное количество по товару, а второй раз добавить его к складу назначения. Для того, чтобы списать товар будем использовать ту же логику наследования:
Проведение расхода
EXTEND CLASS TransferDetail : SkuLedger; |
Так как это расходная операция, то количество берем с минусом, а в качестве склада подставляем склад отправителя.
Так как мы не можем один класс наследовать от другого дважды, то для того, чтобы провести по регистру повторно, создадим агрегированный объект нового класса TransferSkuLedger, который затем наследуем от SkuLedger:
CLASS TransferSkuLedger 'Перемещение на склад (регистр)' : SkuLedger; |
Конструкция AGGR указывает платформе, что для каждой строки перемещения, у которой задан склад назначения, нужно создавать новый объект класса TransferSkuLedger, у которого будет ссылка на исходную строку. При удалении такой строки будет также автоматически удаляться и агрегированный объект.
Остается только реализовать абстрактные свойства для нового класса:
dateTime(TransferSkuLedger d) += dateTime(transfer(transferDetail(d))); |
Пользуемся тем, что у вновь созданного класса есть ссылка на исходный, который его породил.
К слову, в 1С с этим есть определенные проблемы, так как строка документа может порождать только одну запись в регистре:
Система обеспечивает контроль уникальности записей, хранящихся в регистре накопления. Благодаря этому в регистре накоплений не может находиться двух записей, относящихся к одной и той же строке одного и того же документа.
Также важным отличием является то, что вся логика задается декларативно, а не императивно на проведении документа. Это позволяет более эффективно обновлять регистр при изменениях в документе, не требует полного распроведения и проведения документов. Если изменилась только одна запись в документе, то обновления в регистре затронут только одну запись.
Регистр сведений
В отличие от регистра накоплений, регистр сведений рассчитывает не сумму показателя, а последнее значение действующее на определенное время.
Объявление такого регистра абсолютно идентично логике регистра накоплений. Построим для примера регистр изменения цены поступления:
Регистр изменения цены поступления
CLASS ABSTRACT PriceLedger 'Регистр изменения цены поступления'; |
Для расчета последней цены поступления используем следующую конструкцию:
price 'Цена' (Stock st, Sku sk, DATETIME dt) = |
К сожалению, материализовать ее не получится, так как значение этого свойство определено для бесконечного количества точек во времени. Однако, если построить нужный индекс, то обращение будет происходить относительно быстро за логарифмическое время:
INDEX stock(PriceLedger l), sku(l), dateTime(l), l; |
В индекс и в порядок добавляется сам регистр, так как, в отличие от 1С, в lsFusion могут быть записи с одинаковым временем. В этом случае, в качестве дополнительного выражения будет использоваться внутренний код записи регистра.
Проведение по регистру сведений идет также, как и в регистре накоплений:
EXTEND CLASS ReceiptDetail : PriceLedger; |
Заключение
Схема регистров в 1С позволяет делать то, что в обычном программировании реализуется при помощи наследования и композиции (там регистр был бы просто интерфейсом). Тем самым, они пытаются в частном случае решить проблему отсутствия этих механизмов в 1С платформе. Хотя, фактически, регистр является интерфейсом, который может реализовывать либо сама строка документа, либо некий агрегированный объект (композиция), созданный на ее основе.
В lsFusion же наследование и полиморфизм реализованы в общем случае, что делает ее значительно более универсальной и применимой в большем количестве случаев. Фактически, в ней можно реализовать любую логику регистров, ведь они отличаются исключительно способом расчета вычисляемых свойств на основе данных из этих регистров.
MinimaJack
В 1С регистр накопления:
В 1С регистр сведений:
Статья маркетинговая фигня
p.s. слава богу в 1С нет ООП. Незачем ООП тащить в DSL — чем проще, тем лучше.
LeshaLS
Это не отменяет того факта, что ООП в 1С нету, и регистры там реализуются императивно.
MinimaJack
А это что, тоже называется "Декларативно"?
В 1С вообще -программист не реализовывает регистры… а как там реализовано по большому счету все равно.
CrushBy
Вы понимаете разницу между декларативностью и императивностью?
Да, вот только проведение по регистрам и ограничения делаются как раз 1С-программистом вручную императивно.
MinimaJack
Бизнес логика — она в любом случае есть, если не говорить про регистр типа "sku, count".
Проведение по регистрам в 1С:
или так:
CrushBy
Ага, только вот пример кода из документации:
Только самое забавное, что в УТ сделано все не так, как у них в документации. Так как в 1С сами понимают, что этот код дико тормозит и нужно переходить на плоский SQL. Скиньте, для примера, код из УТ который просто проводит по движению и проверяет на то, что остаток больше 0 (можете вырезать всю мишуру, а оставить самый простой случай). Только спрячьте под спойлер, а то там будет очень много (по сравнению с тем, что в статье).
MinimaJack
Формирование движений и запись в регистр — разные вещи…
Если интересен пример формирования движений и проведения:
Методика оперативного проведения и управляемые блокировки https://1c.chistov.pro/2013/07/blog-post_25.html
CrushBy
Это все круто. Но для человека со стороны это все выглядит как «Кто все эти люди ?». Откуда такая сложность в простой задаче? В современном программировании наоборот стараются все упрощать. Причем 1С-программисты делают вид и убеждают всех, что так и надо. Отсюда собственно и шутка про паралимпиаду по программированию.
MinimaJack
"Сложность" понятие субъективное… мне например все понятно, и для чего и почему...
Чего делать не надо не в 1С?
CrushBy
В lsFusion ничего этого делать не надо. Это все делается автоматически платформой.
MinimaJack
А можно увидеть пример списания партий, что бы это было вот как вы пишете прям в платформе!
Что бы можно было настроить FIFO, FEFO, LIFO — вот прям в интерфейсе?
CrushBy
Давайте опять же не смешивать платформу и конфигурацию. Кроме того, не уходите от темы. Про расписывание партий возможно будет отдельная статья. И там тоже значительно проще, чем в 1С.
Конкретно здесь идет сравнение ограничений по остаткам. И в 1С это сделано очень печально.
MinimaJack
В платформе 1С нет контроля за остатками. Что сравниваем?
EvilBeaver
Да нигде ничего делать не надо, все везде само, о чем речь
CrushBy
В статье написан полный код для поддержки регистра. Больше ничего писать не надо.
Для конструктивного обсуждения скиньте, пожалуйста, код на 1С.
EvilBeaver
Код создания регистра? В 1С его нет, он мышкой создается. Вы мне скажите вот что: Я одно время преподавал студентам 1С.
Мы брали учебную версию и за 1 лабораторную (2 акк. пары) создавали полноценную управленческую учетную систему «Купил-продал» с репортингом, UI и веб-клиентом. При этом мы написали не более 20 строк кода. Результатом 2 часов работы студентов можно вполне вести упр.учет мелкого магазинчика. Под «управленческим» я понимаю учет без расчета налогов, только для собственника: сколько у меня денег, сколько у меня товара, сколько я продал, какой фин. результат?
Ваша система может дать мне за 2 часа+20 строк кода веб-клиент, UI и управленческую отчетность с гибкими фильтрами-группировками? Если да, я охотно порекомендую ее коллегам-преподавателям.
CrushBy
Давайте не будем устраивать холивар на тему графическое vs текстовое программирование. Для мелких разработок начинающими программистами возможно графическое лучше. Но когда разработка делается командой и там куча функционала, то проблемы системы контроля версий и рефакторинга выходят на первый план, и там будет лучше код.
Мышкой там делается wizard, который генерирует тот же код. Если его хоть немного менять, то назад мышкой редактировать вы уже не сможете. Опять же, не хочу устраивать холивар на тему визард vs архитектурное программирование.
Вообще да, сможете. У нас будет статья как сделать простой склад.
Но вообще смысла делать с нуля склад никакого нету. Если речь идет о какой-то другой информационной системе (например, турнирная таблица), то все эти регистры бухгалтерий и прочего становятся неприменимыми. И в 1С будет куча ненужных вам абстракций.
Кроме того, не забываем, что 1С — коммерческий продукт с очень жесткой системой лицензирования. А lsFusion по LGPLv3 лицензией, адаптированный под работу с PostgreSQL.
EvilBeaver
Я уже посмотрел ваш демо пример. У меня больше нет к вам вопросов. А подача материала и тон ответов окончательно закрывает вопрос о целесообразности изучения вашей системы.
CrushBy
Спасибо за ваше мнение. Мы за плюрализм, и считаем, что всегда у людей должен быть выбор, и каждый решает сам, что ему лучше.
o4karek
Понимаете в чем дело… (дальше ИМХО)
Вы решили рассказать о том, что 1С: Предприятие — это плохая система, а ваша система — хорошая. Вы в этом уверены и не допускаете, что может быть по-другому.
Вести конструктивную дискуссию при таком подходе очень тяжело. Просто по-определению такого подхода.
Вы не предполагаете, что у ваших оппонентов могут быть причины делать так, как они сделали. И таких причин может быть очень много. Причем как у тех, кто платформу делает, так и у тех, кто конфигурации делает.
Но уже приняв решение (и не допуская другого), вы лозунги озвучиваете другие.
CrushBy
Это не так. Тут не белое и черное. У каждого подхода и технологии есть свои преимущества и недостатки.
Это конкретная статья про конкретный кейс. И тут очевидно, что преимущество не на стороне 1С. Удивительно, что 1С программисты не хотят этого признать. Со своей стороны, я вот совершенно согласен, что в 1С дизайн лучше. Есть еще вещи, которые реализованы в 1С лучше, чем в lsFusion. Что не отменяет того факта, что многое в lsFusion лучше чем в 1С.
o4karek
Простите, а вот это что (пост)?
NitroJunkie
Для решения одной задачи.
MinimaJack
формирование движений будет происходить в любой системе кодом. Если там что то сложнее от склад, товар, количество.
Запись в регистр, да возможно где то и автоматом… но по секрету, в 1С тоже можно автоматом — просто это медленнее.
"Запись движений при проведении" — "Записывать модифицированные" — можете погуглить
NitroJunkie
Оно может происходить декларативно, а может императивно. А проблема императивного подхода, например, что при изменении документа оно требует провести обработку всего документа (то есть всех строк). В lsFusion если вы поменяли одну строку, обрабатываться будет только эта одна строка.
Гуглил. Автоматом можно только в самых примитивных случаях. Появляется хоть один if или ссылка / join — вперед for'ы/запросы руками писать.
MinimaJack
При стандартном подходе 1С — один документ много строк. Но никто не мешает сделать один документ на строку, и один документ-владелец.
Получится такой же эффект — просто никому это не надо...
gennayo
Это уже реализовано в нескольких WMS-системах на 1С.
MinimaJack
Да я и сам разрабатывал такие формы...
gennayo
Ну, это как бы промышленные решения, применяемые во многих крупных компаниях.
NitroJunkie
А когда надо ввести один документ на 100 строк, будете их по одной вводить. Издеваетесь?
Но вообще вы похоже, не поняли. В lsFusion вы вводите документ как обычно. Потом можете открыть его на редактирование, поменять только одну строку. И о чудо она обновит данные только для этой одной строки (со всеми регистрами, ограничениями и т.п.).
Вообще в lsFusion можно один документ параллельно разными пользователями вводить при необходимости (у нас были такие кейсы), и она отлично все разрулит сама.
gennayo
Идею вы не поняли, так как платформу 1С не очень хорошо знаете. И вообще, вы сравниваете свою платформу с конфигурациями 1С, а не с платформой 1С. Надо отделять мух от котлет.
NitroJunkie
Как раз я последний месяц с ней разбирался, это с учетом того что у меня огромный опыт работы с различными платформами разработки (начиная от Foxpro и .Net/Java и заканчивая совсем экзотическими).
И 1С идеологически подразумевает перепроведение всего документами. И разработчики УТ со мной походу согласны. Или думаете они тоже платформу 1С не очень хорошо знают?
gennayo
Вы изучали не платформу, а типовые решения на этой платформе. Поэтому, сравнивая типовые решения 1С со своей платформой, вы показываете себя не в лучшем свете.
NitroJunkie
Еще раз я изучал платформу. Вот тут и тут:
its.1c.ru/db/metod8dev
its.1c.ru/db/v8315doc
Ну и естественно обращался к решениям на 1С за бест-практис. Потому как если что-то делают именно разработчики 1С, тяжело возразить что они это делают не правильно.
И сравниваются конкретные механизмы ПЛАТФОРМЫ регистры и ограничения на примере типовых решений. Или по вашему есть другие более простые и эффективные способы работы с ними, о которых даже разработчики УТ не знают?
gennayo
Сравнивайте типовые решения на вашей платформе, и типовые на 1С, и вопросов к вам будет. Если как-то сделано в типовых, это не значит, что по-другому в платформе нельзя, это не значит, что это наиболее эффективный способ. Причины, почему именно так реализовано в типовых, лежат несколько в иной плоскости.
NitroJunkie
Ок, тогда расскажите как по другому сделать проверку, что например сумма остатков должно быть больше 0, потому как я всю документацию облазил, форумы перечитал, типовые пересмотрел, и пришел к выводу (сюрприз !) что разработчики типовых сделали это единственным эффективным способом (с 400 строк кода вместо одной в lsFusion)
gennayo
Что значит «сумма остатков больше 0»? Ну, и вы должны понимать, что в любом случае:
1. Не зная постановки задачи судить об эффективности кода нельзя.
2. Любое универсальное решение будет избыточнее и сложнее специализированного.
Поэтому, сравнивать можно только реализацию конкретного, непротиворечивого, ТЗ на различных платформах. Всё остальное — профанация и умозрительные заключения.
NitroJunkie
Что именно вам непонятно. Остаток по любому товару складу в текущий момент должен всегда быть >0. Что тут может быть не понятного?
Ок, покажите пример склада как тут на 1С. Я помню такая конфигурация когда-то существовала (под более ранние версии), но сейчас не могу найти.
gennayo
Извините, я, наверное, глуповат. Вы можете привести по обеим случаем бизнес-требования и постановку задачи не как, например «Информационная система будет состоять из подмножества модулей, в каждом из которых реализуется некоторая логически обособленная функциональность.»?
NitroJunkie
Ну там действительно, есть много технического текста, можно его пропускать. В любом случае, вот онлайн демо (оно же на lsfusion.org/try):
demo.lsfusion.org/mm
Ну и я точно помню, что у 1С был пример такого же простого склада когда-то, но я почему-то не могу его найти.
MinimaJack
Да в 1С все выглядит как один документ, а вот обновляется построчно.
И да — все проверки и движения будут построчно.
И редактировать документ можно раздельно.
Просто это отклонения от общепринятых стандартнов
NitroJunkie
Речь о другом, при редактировании документа он перепроводится целиком. Потому как иначе придется отслеживать изменение каждого реквизита везде руками. А это ну очень трудоемко.
gennayo
Нет, это не так. Изменяете одну строку — проводится один документ, который и является этой строкой. Контроль же всего документа в целом нужно будет будет реализовывать отдельно, это да. Но ведь и в вашей платформе так-же?
NitroJunkie
Я сейчас зашел в УТ. Изменил одну строку отгрузки. Дальше дебажу и вижу что во всех временных таблицах, расписывании по партиям обрабатываются ВСЕ строки этого документа, даже которые я не менял.
Нет, если изменяется одна строка, а весь документ на 10к строк, будет обрабатываться / читаться только одна строка / товар этой строки.
gennayo
Ещё раз, это НЕ является ограничением платформы, это принятый РАЗРАБОТЧИКАМИ ТИПОВЫХ (и рекомендуемый вендором) способ работы. Платформа может и так, как описано мною выше.
Про обработку документа в целом вы опять не до конца поняли. Например, нам нужно контролировать наличие товаров на складе, и максимальную/минимальную сумму заказа. Остатки мы контролируем на уровне измененной строки, а сумму заказа мы контролируем по документу в целом. Но в типовых это не так, да.
NitroJunkie
Ок, давайте остановимся на том, что разработчики типовых просто не умеют правильно использовать возможности платформы. А на самом деле можно все было делать гораздо проще и эффективнее.
gennayo
Если вам от этого будет легче — я с вами соглашусь. В окончание разговора всё же отмечу, зря вы продвигаете свое решение через сравнение с 1С. Это путь в никуда.
NitroJunkie
Забавно, что SQL-ки в статье про функциональную СУБД, говорили что зря вы продвигаете ее сравнивая с SQL, сравнивайте с 1С. .Net'овцы тоже говорили, что зря мы сравниваем с .Net, вот вы говорите, что зря сравниваем с 1С.
А собственно все эти технологии решают одни и те же задачи — разработку информационных систем / бизнес-приложений.
Но вообще, это естественно. Большинство людей не хочет изучать что-то новое и выходить из зоны комфорта. С другой стороны, вы же понимаете, что на первом этапе в любых инновациях расчет никогда не делается на большинство.
Asmody
Посравнивайте себя с той же Кубой (https://www.cuba-platform.ru/), вы где-то примерно в одной нише.
NitroJunkie
Я тоже самое и про iPhone, и про Tesla, и про Mongodb слышал. Конечно далеко не все ими становятся, но абсолютно все новые вещи на рынке изначально получают такую реакцию. Была даже такая шутка про обсуждение в баре первого автомобиля (не помню дословно):
— Да я за эти деньги две лошади и овса им на всю жизнь куплю.
Asmody
Что-то я не помню чтобы в кейноутах Apple хоть раз упоминались конкуренты в негативном ключе.
NitroJunkie
А как они touchscreen по вашему представляли? Что кнопочные телефоны неудобны. Равно как и электромобили — что бензиновые автомобили загрязняют окружающую среду, а mongodb — что SQL базы не масштабируются.
Собственно все нормальные продукты идут от проблем существующих продуктов, а не от возможностей. И так и должно быть, иначе в чем смысл этих продуктов.
o4karek
Вы смешиваете критику подхода (вообще кнопочный телефон) и критику конкретной модели (например, Nokia 3210).
Ну а то, что электромобили не загрязняют окружающую среду — это вообще, любимый пример передергивания, зашкаливающего за понятие «вранье».
NitroJunkie
Ну если бы, как на постсоветском рынке, на рынке были бы только Nokia 3210, то критиковали бы именно их. Посмотрите презы AMD и Intel они постоянно друг с другом сравнивают.
Но идея была не в этом. А в самом факте сравнения с конкурентами.
o4karek
Еще раз: когда я говорю «кнопочный телефон» — я не упоминаю конкурента. Когда я говорю «нативное приложение» или «веб приложение» — я не упоминаю создателя приложения. Не важно, что в конкретном контексте уши конкурента светятся как фонарь :)
Но как только я сказал «приложение Microsoft» — я стал на очень скользкую дорожку. Вначале все может быть красиво и прилично, а потом бац — и просто ложь в сравнении :)
gennayo
Ну раз вы ответили :))
Я ничего не имею против вашей платформы, я вижу, что некоторые ваши решения лучше, чем у 1С, идея подбора в отдельной вкладке, например, вполне здравая :)). Но когда вы критикуете 1С как платформу, приводя при этом в пример типовые конфигурации, и не замечая, что платформа 1С «умеет» и по-другому, это реально огорчает. Кстати, продвигать свой продукт сравнением с 1С пытались как минимум Ultima, CUBA и Ананас. В конечном итоге, все они стали продвигать только свои достоинства, не упоминая 1С. Задумайтесь об этом…
Asmody
Что значит в вашем понимании «перепроводится целиком»?
В понимании платформы «проведение» — это лишь некий статус при сохранении объекта. Ну и вызов некоторой цепочки методов-обработчиков. Исторически сложилось, что при этом формируются движения по регистрам. Но вся логика этого формирования целиком на совести разработчика.
NitroJunkie
Это не исторически так сложилось, это 1С так предполагает. И как по другому делать даже разработчики типовых не знают. Не от хорошей жизни же они так и делают, да и я не могу придумать как по другому. Поэтому:
Asmody
NitroJunkie
Ну как бы и то и другое. Или вы думаете разработчики 1С плохо знают платформу и неэффективно ее используют?
VitalyB24 Автор
Это цитата из их документации. Не отрицаю того факта, что как обычно бывает в 1С, есть еще сбоку куча костылей, которые позволяют это реализовать.
По регистр сведений не очень понял, чем это противоречит тому, что написано в статье. Можете привести конкретную цитату?
MinimaJack
Вы описали только периодический регистр сведений.
В периодическом регистре в 1С могут быть записи с одинаковым временем по всем измерениям.
Ну вот пришли… считайте это недосмотром 1С, все совсем по другому… желательно было дать почитать любому программисту 1С
VitalyB24 Автор
Хорошо, изменил немного статью, чтобы соответствовать терминологии 1С.
Я конечно не специалист по 1С, но в других технологиях принято доверять официальной документации. Тем не менее, в статье не утверждается, что это нельзя реализовать.
o4karek
Так вы ей не пользовались :( Приведенной вами цитаты:
нет в официальной документации. В взяли рекламную информацию и решили, что это документация.
VitalyB24 Автор
http://v8.1c.ru/overview/Term_000000176.htm
То есть вот это рекламные материалы? Странная реклама какая-то…
И как я понимаю, Вы утверждаете, что их рекламная информация не соответствует реальному положению дел? В чем еще они врут у себя на официальном сайте?
И что за официальная документация? Дайте на нее ссылку, пожалуйста…
o4karek
Я утверждаю, что рекламная и техническая информация — это не одно и тоже.
То, что они врут — это вы придумали (как в том анекдоте: это вам со страху показалось).
Ссылка на официальную документацию вот: its.1c.ru/db/v83doc Для использования нужна подписка на ИТС.
LeshaLS
В 1С платная документация? Видимо, чтобы случайно начинающие разработчики не поняли, в какой треш они попадут. А дальше уже как South Park: «ты не сможешь выбросить то, за что уже заплачены деньги».
Neikist
Раньше еще хуже было, сейчас хоть какую то документацию местами бесплатно открыли, ну, по крайней мере еще недавно часть документации точно открыта была, прямо сейчас не в курсе.
o4karek
Никогда электронная документация не была в открытом доступе. Только по подписке на ИТС. Недавно открыли другие полезные материалы, но не доку.
gennayo
На английском же есть :))
1c-dn.com/library/1c_enterprise_documentation
CrushBy
К сожалению, в англоязычном сегменте она никому не нужна, так как сама платформа никакой ценности без бухгалтерии и налогового учета (читай конфигурации) особо не несет. А этого добра там и своего хватает. Поэтому и документация открыта.
Мне всегда было интересно отношение 1С апологетов к Apple. Ведь Apple поступает же абсолютно также — у них все закрытое, проприетарное и платное. При этом фанаты Apple всем доказывают, что так и надо, а все остальное — говно. Как я понимаю все 1Совцы ходят с iPhone'ами?
o4karek
Это вы сами придумали? Или данные имеете какие-то? Тут рядом ваш коллега утверждал, что никакой предвзятости в сторону 1С у вас нет :)
У каждого минимум по два. И если они не самые свежие — штраф огромный. Иначе нельзя.
NitroJunkie
А вы реально придумаете конкурентные преимущества у 1С хотя бы перед .Net. У последних хотя бы LINQ есть, а не пещерный век:
o4karek
Т.е. данных у вас нет и вы решили просто поиграть в телевизионного «эксперта». Хм…
Если рассматривать Платформу как универсальное средство разработки — таких достоинств нет. Если рассматривать как инструмент, для которых этот инструмент создавался — ситуация сильно меняется и вопросов к .NET ну много возникнет. Потому, что и платформа и .NET и Go и прочие языки и фреймворки существуют не просто для удовлетворения мечтаний об ООП и т.д., а для решения конкретных задач. И перед Платформой ставится задача автоматизации экономической деятельности.
И платформа именно эту задачу вполне себе решает. Например тем, что дает готовые механизмы реализации очень большого количества вещей, которые нужны для решения задачи автоматизации бизнеса.
Как говорит один широко известный товарищ, давайте не путать «можно сделать» и «сделано». На .NET можно сделать и систему управления распределенными базами данных и регистры накопления, ПВХ, механизмы разделения и все-все-все.
НО. Сколько это времени и денег на этой уйдет? Кто будет этот продукт поддерживать, когда автору надоест дальше этот продукт развивать?
Т.е. ключевое преимущество Предприятия в данный момент — это заточенность для решения конкретных задач. А комьюнити — Россия и весь exUSSR, Польша, Вьетнам, Румыния, Турция, Китай (это из того, что сходу вспоминается). Внедрения решений на платформе — там десятки стран. Да, оно не такое обширное, как у .NET, но оно есть и растет.
NitroJunkie
Нет, это именно в процессе изучения 1С. И я на это потратил куда больше времени, чем любой потенциальные англоязычный пользователь.
Какие механизмы? Как в примере что я написал? Запросы прямо в строке? Так уже лет 10 никто не пишет. Это привет 90е.
Кому она нужна в 21 веке то?
MATERIALIZED INDEXED VIEW даже в MS SQL умеет куда больше
Ага и отказ от SQL механизмов (аналитических / табличных функций, замыканий), которые умеют куда больше чем 1С.
.Net цев как грязи. Где вы столько 1Сцев найдете?
Это кто вам такой бред сказал. Посмотрите количество вакансий 1С в Польше, Китае и Турции.
По пять штук? Ну ну. И что там внедряют УТ? Где половину российского функционала, вроде ЕГАИС и интеграции с российской же бухгалтерией, которая в китае нафиг не нужна?
o4karek
Понимаете в чем дело… По данному обсуждению я вижу следующие факты: 1. не вы, не ваши рекламщики Платформу не знаете (вы даже в рекламном сравнении врете) 2. вы считаете, что мир монохромный, а это не так. 3. у меня есть некоторые сомнения в том, что лично вы знаете как работает рынок автоматизации, на что там обращают внимание и за что платят.
Когда вам говорят про те места, где вы неправы — вы надеваете каску и начинаете говорить про неполноценность свои оппонентов.
Давайте вы или будете все-таки корректно общаться или стоит завершить разговор.
И да, почти все мои высказывания можно подтвердить разными ссылками…
NitroJunkie
Ну вы тоже lsFusion не знаете. Но я то конкретные вопросы задаю, а вы вместо того чтобы ответить, как это сделать, и почему разработчики типовых так не сделали, отвечаете: «вы просто не знаете платформу», «у разработчиков типовых были свои причины». В таком ключе действительно нет смысла продолжать разговор.
Ну я в этом бизнесе уже 21 год, и напрямую учавствовал в продаже, внедрении и поддержке нескольких сотен в сумме проектов, от заводов до фондов. И кстати к примеру на дизайн никто не жаловался, всех интересуют стоимость, скорость доработок, возможность бесшовного перехода с существующих систем и т.п.
На личности кстати вы переходите, равно как и на аргументацию в стиле:
Ну так подтвердите раз можно.
o4karek
Так вы же про других врете :) Как вы про lsFusion
вретеговорите — я не знаю :)Я не перехожу. Ибо ваши личностные качества я не затрагивал. Моя аргументация немного отличается от этой:
«1С умудрился накосячить как раз во всем в чем мог.»
«Это кто вам такой бред сказал.»
«в англоязычном сегменте она никому не нужна, так как сама платформа никакой ценности без бухгалтерии и налогового учета (читай конфигурации) особо не несет»
«И я на это потратил куда больше времени, чем любой потенциальные англоязычный пользователь.»
Человек, который в этом бизнесе 21 год — он, обычно, говорит ну совсем другие слова. По крайней мере такой человек значительно менее монохромен :) Он знает, мир сложен и многообразен
Зачем? Вам же этого не надо. Вы уже знаете, что 1с гавно.
NitroJunkie
Ничего не понял.
Я это знаю. Собственно ирония в том, что из этих нескольких сотен проектов, для большинства продажа, как и внедрение были по своему уникальным кейсом.
Но многообразие чего-либо, не означает, что это что-либо не надо анализировать, систематизировать, оценивать, а главное сравнивать друг с другом. В противном случае непонятно как вообще принимать какие-то решения на этом рынке.
Плюс все что я спрашиваю в этих комментариях, я делаю не для того чтобы «потопить» конкурентов (поверьте после первого дня эти комменты мало кто читает), а именно чтобы разобраться как именно у них все работает. И опыт показал, что если человек не может быстро и просто ответить на вопрос, то этого ответа, во всяком случае у него, попросту нет.
Плюс сейчас мы готовим более объемную статью про 1С в стиле этой, и нам на самом деле важно получить ответы на интересующие нас вопросы. Например как в динамическом списке добавить редактируемое поле (смотри комменты к предыдущей статье), или как сделать ограничение в 1С.
o4karek
Что вы не поняли?
Хорошо, скажу по-другому: ваше сравнение lsFusion с другими продуктами содержит ложь про другие продукты. Указывать где эта ложь я вам не буду (зачем жизнь облегчать?).
Когда хотят разобраться — спрашивают по-другому. Ваши примеры вопросов я показал :)
Последний совет — не делайте ее. По-крайней мере в сравнении с другим (любым) продуктом. У вас это плохо получается. Напишите про то, как вы классно решили какую-то вашу проблему (и почему именно так, без сравнения с другими) — и это будет интересно и позитива будет сильно больше.
CrushBy
Так и в этой позитива много. Посмотрите на плюс 21 в статье и всего один минус.
o4karek
Наше дело предложить — ваше дело отказаться :)
NitroJunkie
Ага, знаю, но вам не скажу. Плавали, знаем.
Забавно, что, например, ораклоиды реагируют наоборот, что большинство прочитают и поверят, и поэтому сразу бросаются разъяснять, что именно не так. Но 1Сцы видимо на своей волне.
Там знак вопроса в конце стоит?
Я кучу вопросов сверху задавал, и про ограничения, и про редактирование динамических списков, и про пример простенького склада на 1с. Но все неудобные вопросы 1с разработчики странным образом игнорируют, ограничиваясь ответами: «вы просто не знаете платформу», «у разработчиков типовых были свои причины».
Посмотрим. Почему не SQL? отлично зашла, лучшее за все время в нескольких хабах (ну или на первой странице).
В любом случае, «чтобы купить что-то не нужное, нужно продать что-то не нужное». И проблему прежде всего нужно показывать на примере существующих решений, иначе проблема надуманна по определению.
o4karek
Пока вы мне про бред не рассказывали — тоже сказать хотел. Но кажется, что вам помогать не нужно.
NitroJunkie
Честно не хотел никого обидеть. Просто два дня обсуждений в этой и предыдущей статье отбили хоть какую то надежду услышать в комментариях хоть что-то конструктивное, поэтому вспылил немного. Так что придется довериться методическому пособию, документации, типовым ну и учебной версии платформы.
o4karek
А дело не в обиде. Таким общением вы задаете тон и стиль дискуссии. И вам этот тон и стиль возвращается в ответах.
gennayo
Да пусть пишут. Хайпанут лишний раз, почешут своё ЧСВ. Потом поймут, как и остальные, кто таким путем пошел, что только время зря потратили.
o4karek
Оно а) не на русском и б) не очень последнее, так скажем.
gennayo
Это скорее шутка была, чем серьезный аргумент :)
gennayo
del
Nilpferd
ВЫ просто её(цитату) неверно поняли. Строка документа и строка регистра — это разные вещи.
Не противоречит, просто регистров сведений есть несколько видов, каждый со своей спецификой, а не только тот вид, который описан.
NitroJunkie
И? Так и агрегаций можно много создавать порождая «много записей в регистре»
И? Никто не мешает и промежуточные итоги создавать. Скажем:
balance(Stock st, SkuGroup sk) = GROUP SUM balance(st, Sku sku) IF skuGroup(sku) = sk MATERIALIZED;Расскажите как кстати такие промежуточные итоги в 1С делать (чтобы они еще хранились)
То есть в 1С регистры сведений просто таблица с несколькими ключами. И? Какое отношение это к наследованию и полиморфизму имеет.
Комментарий — маркетинговая фигня.
MinimaJack
Разговор немого с глухими…
Я описал недочёты(ошибки) в статье, которые кардинальным образом влияют на функционал.
Давайте напишем какая 1С говно — и на этом фоне прорекламируем себя?
Подавляющие большинство программистов будет кивать гривами(бородой), соглашаться и ставить плюсы.
NitroJunkie
Не поверите, но все новые продукты выходят на рынок в сравнении с существующими продуктами. Хотя конкретно эта статья это так — один маленький кейс, у 1С есть куда более фундаментальные проблемы.
vtc
Ну проблемы может и есть… Но с другой стороны я не знаю ни одной системы сравнимой с 1С по возможностям и технологиям в одном флаконе, которые доступны сразу из коробки…
Все понятно, что на си шарпе или еще на чемто это все можно реализовать, вопрос в какие сроки и какой кровью…
NitroJunkie
Не знаю, но я сейчас смотрю код УТ и у меня кровь из глаз идет. Я тут в комментах приводил отрывки кода для решения отдельных мелких задач, типа проверки ограничений, организации flow и т.п.
Ведь по сути 1С одновременно отказались от ORM, всех стандартов SQL после 92 года (аналитических функций, рекурсивных CTE, представлений), автоматических блокировок (CI в ACID), автоматического control flow, автоматического обеспечения синхронности. При этом не добавив ни типизации, ни наследования, ни замыканий, ни аналога LINQ. То есть выкинули все лучшее что может быть в платформах высокого уровня, не взяв ничего лучшего из языков общего назначения. Да с ними кто угодно сравнится. Даже .Net, не говоря уже о lsFusion.
vtc
Это с точки зрения языка… А с точки зрения возможностей?
Часто Вы видели реально живую трехзвенку? Причем которая работает на нескольких типах SQL серверов? Ну и под разными платформами?
Которая имеет как толстого, так и веб клиента, которые работают без переписывания исходного кода?
Часто ли вы видели чтобы один и тот же код можно было запустить как на толстом клиенте, так и в мобильной аппликухе, даже если учесть ограничения?
Что-то мне подсказывает, что ее недостатки это следствие ее достоинств…
Это с технической точки зрения…
А с практической — где можно заработать денег больше и проще (мы же ведь работаем, а не развлекаемся) и быстрее удовлетворить заказчика? Не считая обучения персонала, который будет работать с этим…
Попробуйте повторить ту же УТ на Net… Не вопрос, что может УТ было бы проще даписать на Net, но ее нет под Net… И думаю что и не будет.
NitroJunkie
Видел. Я более того скажу, что lsFusion умеет это все и даже больше. И работает на таких объемах, где конкурентов на 1с нет и не предвидится (только в распределенных базах)
Нет, все это можно было реализовать без отказа от всех тех прелестей жизни, что я описал. Но они решили что разработчики и так съедят. И были правы. Съели и не заметили.
Мы повторили. Не 1-в-1 конечно, у нас есть много вещей которых у них нет, ну и наоборот. Но тут важнее другое, мы можем кастомизировать под заказчика, так что у него будет только 60% из общего функционала (причем можно не брать ненужный общий функционал, чего в УТ к примеру нельзя сделать) и 40% своего. Как что-то дописывать / изменять в УТ для меня загадка? Там реально страшно что-то трогать, потому как непонятно что при этом сломается. Никаких проверок типов, в частности нет, ну и всю жутко императивно сделано.
Хотя уверен что УТ можно и на .Net повторить. Вы же в курсе что 1С это чисто российская фишка, то есть <1% мирового рынка. Остальной мир живет же как-то.
vtc
Это сколько? В документах/терабайтах?
Заметили. И что? Если задача поставить именно 1С?
Невопрос. И сколько клиентов и каких размеров у вас есть?
Ну тут без вопросов… Хотя такое легко и на ООП ломается…
Кож спорит… Процессинги на КОБОЛе и подобном работают до сих пор… ИБМ не просто так же до сих пор майнфреймы выпускает…
А реальные примеры? Со сравнением? Типовые конфигурации?
На сайт lsFusion я зашел… Не нашел мобильных приложений, не нашел толстого клиента… Вообще не понял какой язык используется…
NitroJunkie
3,5 млн инвойсов, 35 млн строк инвойсов. И это я не самого большого клиента взял. Чеков на самом деле уже давно больше млрда, это статистика для внутреннего оптимизатора (ее нет смысла обновлять).
Заказчику обычно все равно на чем решение, ему главное чтобы работало.
Даже тут уже отвечали несколько раз вроде. Около 40, но достаточно крупных от 50 одновременных пользователей. Около десятка 400-1000 одновременных пользователей.
Одним ООП проблему декомпозиции сложности не решить, нужны еще события, ограничения, расширения и т.п.
Сравнение чего? Сравнение платформ тут. Решения тут, под них будет отдельный сайт, так как мы их напрямую не связываем. Но там не совсем понятно что сравнивать, модули практически те же что и в ут. А формы сравнивать это уже странновато будет.
Толстый клиент (справа снизу):
Справа снизу. Для мобильных react обычно используем, тут немного подробнее.
vtc
Еще вопрос — почему сравнение идет с 1С 8.2 а не 8.3? 8.2 давно устарела…
Ну и второй вопрос — насколько большой рынок труда для програмиста на этой системе? Это как бы тоже немаловажный параметр, потому что изучить какую-то систему — это не взять какуюто крутую дополнительную библиотеку к известному языку…
Т.к. при использовании библиотеки — ты остаешься специалистом по этому языку, и знания можно применить и в других направлениях/фирмах.
Поэтому у вас есть шанс так и остаться узкоспециализированным решением. А 1С со своими недостатками будет продолжать жить и развиваться…
NitroJunkie
Я сравниваю как раз с 8.3. Потому как именно там они от модальности отказались. Все жду, что они в 8.4 от if'ов еще откажутся и перейдут на goto. И назовут управляемыми переходами. И самое смешное, что разработчики и это съедят, рынок же.
Ну в Беларуси не пропадете уже. В России вопрос времени. 1С тоже в свое время был узкоспециализированным решением.
Но шанс есть всегда, мы то в любом случае его будем развивать, мы на этом сейчас деньги зарабатываем, и пока проблем с этим даже в очень долгосрочной перспективе не предвидится (у нас уже достаточно большой диверсифицированный пул крупных клиентов на самом устойчивом к кризисам рынке)
vtc
Я имею в виду по ссылке в коментарии тут. Там именно 8.2
1С года с момента появления 7.7 перестала быть узкоспециализированной… А это было ну очччень давно…
NitroJunkie
Там >=8.2. Не очень давно 1С воспринимали именно как решение для бухгалтерии (да и сейчас многие так делают). Лет 15 назад только это начало меняться.
vtc
Ну
означает что вы не делаете отличий между 8.2 и 8.3, а они реальные и большие в возможностях.Время летит быстро ;) 15 лет назад это 2004 год — в этом году уже массово были конфигурации под разные учетные нужды…
1С как была так и есть программа для учетных, управленческих и околобухгалтерских дел. Как была так и осталась… В них она и хороша.
NitroJunkie
Так ирония в том, что как раз в фундаментальных вещах 1с по сути деградирует:
Отказались от ORM, Отказались от автоматических блокировок, Отказались от обычного приложения, Отказались от обычных форм, Отказались от синхронности / модальности. Все на протяжении от 8.1-8.3. Причем по факту они не решили проблемы, а просто переложили их на разработчика. Просто заменив слово ручные на управляемые.
То до чего производители ручных коробок передач кстати не додумались. Надо было управляемыми их назвать и продвигать как возможность, а не лишнее действие.
vtc
Ну можно включить. Но под большой нагрузкой будут проблемы. Вы же не расстраиваетесь. когда надо на постгрессе самому начать транзакцию, заблокировать нужные записи и закомитить?
та по сути 1с и есть она большая орм… Раздражает язык запросов… это да… Но все равно это вопрос привычки.
Это где они отказались? Легко можно создать обычную форму… Только вот в вебе и на мобилке она работать не будет. На винде — пожалуйста
NitroJunkie
Так в этом и фокус. Что можно было сделать нормально как в lsFusion (я приводил уже объемы) и никаких проблем не было бы.
PS: На постгерс как раз не надо блокировать нужные записи, на update conflict'ы как правило полагаются.
Так в том то и дело, что сейчас решения на 1с это pure sql, причем года так 92. Непонятно зачем тут вообще 1с, в таком стиле и на php писать можно.
Я сейчас на 8.3 в учебной версии ОткрытьФормуМодально сделал, и она уже ошибку выдала (нужно вручную переключать режим). Вы же понимаете что выпиливание обычных форм и других режимов вопрос времени, причем не очень далекого (судя по их риторике).
vtc
Посмотрим на вас лет через 15 развития системы… Если она будет иметь кучу инсталляций и будетраспростронена, как 1С… что у вас там будет…
Ну когда она была 7.7 это было еще хуже… А что — лучше ОРМ или прямой скл — это большой вопрос…
Ну я думаю что если в вашей системе написать какую-то хрень она тоже не переварит.
Та кто его знает… Кроме того я не сказал бы, что под новые формы писать тяжелее… Я бы сказал — что легче… Правда мышление надо несколько переделывать, это да… Но это такое…
gennayo
Вот модульность да, это слабое место 1С, особенно в типовых. Концентрируйтесь на своих реальных преимуществах для бизнеса, а не для разработчиков.
NitroJunkie
Мы пока прощупываем рынок, до кого проще достучаться. Хотя учитывая, что основной рынок IT в мире — англоговорящий, может это и пустая трата времени. Там вроде все по другому работает.
gennayo
Конечно пустая. Потеснить 1С можно, но затраты на это будут намного выше, чем полученный профит…
NitroJunkie
Тут то как раз фокус, что рынок высокомаржинальный, пяток относительно крупных проектов отбивают и все премиум акаунты, и пиар во всех сми, и контент менеджеров, и людей которые в каждой ветке будут дискуссии устраивать. Под пустой тратой времени я имел ввиду, что если рынок более восприимчив к инновациям, нет смысла доказывать что-то тем, кто изначально негативно настроен.
В этом смысле вот что весьма забавно. У нас есть небольшие проекты с американцами, и по опыту они очень легки на подъем: давайте это попробуем, и это попробуем. Их надо наоборот убеждать, зачем вам это надо.
А на постсовке все с точностью до наоборот. У нас с одним заказчиком переговоры 2 (!) года шли, хотя у него практически никаких других вариантов не было.
gennayo
Если рассматривать вариант — внедрение с нуля, то да. А вот если рассматривать переход с уже существующей системы — всё становится уже не так радужно. Ну и я всё равно никак не могу понять, кто ваш клиент в России, который будет выбирать между коробками 1С и заказной разработкой на вашей платформе.
NitroJunkie
Еще раз. Вы всерьез полагаете, что мы с нуля все проекты разрабатываем? Нет у нас за 12 лет, есть набор из сейчас наверное 1300 кубиков (модулей, количество которых постоянно растет) из которых мы как из лего собираем сначала базовое решение, а потом донастраиваем под конкретного заказчика (хотя у 30% клиентов что по меньше идет как есть).
Вопрос, в том можно ли считать на текущий момент ERP продуктом? На мой взгляд можно (особенно ближе познакомившись с УТ), но не я принимаю решения в этом плане.
Хотя в целом я за продвижение ERP именно как полуфабрикат / конструктор. Вы из кубиков (подключая нужный подграф модулей как 30 так и 800) собираете ровно то что вам надо, плюс по мелочам кастомизируете под конкретные требования. То есть такой серийный custom made получается. И не ешьте что дают, но и по срокам стоимости достаточно быстро / дешево. Собственно это мы сейчас и продаем и пока вроде достаточно успешно.
gennayo
Вы про внедрение в целом, я же про рынок 1С, от которого вы хотите откусить малую толику. Для этого рынка даже описанное вами — это заказная разработка.
NitroJunkie
Так вы же понимаете, что этот процесс можем не только мы выполнять. Даже у нас сейчас компания занимающаяся платформой, и компания занимающаяся
решениями (их даже несколько уже по сути) это разные люди. И компания с решениями работает и конкурирует с компаниями продающими 1С. Но последние по сути коробки продают (которые сейчас по сути уже не нужны, они на растущем рынке в основном продаются, так как сейчас у всех все уже автоматизировано), а мы на lsFusion custom made продаем по адекватной цене даже по сравнению с коробками.
gennayo
Это хорошо. Но, всё-таки, можете описать абстрактно, какие бизнесы в России как-то автоматизированные на текущий момент, ваши потенциальные клиенты?
NitroJunkie
Ну сейчас конкретно, это рынки, который мы знаем и понимаем: FMCG сети — там где сейчас Супермаг, Gestori, самописки, Астор и т.п. И заказные разработки, где сейчас excel, всякие нестандартные CRM / billing / project management и т.п.
gennayo
Не думаю, что сети, до сих пор работающие на Джестори, могут позволить себе смену программы автоматизации. Они скорее всего с околонулевой рентабельностью работают. Знаю вокруг в городе милионнике 3 примерно такие сетки, сдохшие за 2 последних года.
Veidt
2 экономических и один фискальный кризис научили меня тому, что у продовольствственной розницы деньги есть всегда. И чем их меньше тем лучше, тогда они с меньшей вероятностью принимают глупые финансовые решения вроде найма своего IT отдела или покупки sap, платных СУБД или коробочных решений. При этом они ещё больше заботятся об эффективности своей работы, а в fmcg рознице это возможно только за счёт it и поэтому серийный дешёвый custom made им заходит на ура. Проверено опытом. У нас лучшие продажи были во времена кризисов.
gennayo
Ситуация сейчас другая. Крупные федеральные сети давят и поглощают мелкие, контроль со стороны государства с вводом онлайн касс вырос, всё идёт к тому, что останется только крупняк, Ашоты с 1-2 магазинами и полунищая розница типа облпотребсоюзов в глухих сёлах. Среди них потенциальных клиентов lsFusuon я никак не вижу.
Veidt
А вы давно на этом рынке?
Veidt
На самом деле у первых 10 сетей всего 30 процентов рынка. У нас у одной 20. И рост на 3 процента в год. То есть даже 50 процентов лет через 5 только сети достигнут. Так что место больше чем достаточно. Но поживем увидим.
gennayo
Откуда у вас такие данные? Можете подтвердить какой-нибудь ссылкой?
Veidt
Ну вот к примеру:
https://www.retail.ru/rbc/pressreleases/m-a-research-top-10-fmcg-setey-obespechili-17-oborota-roznichnoy-torgovli-rf-v-2018-godu/
CrushBy
Из приведенной ссылки кстати:
Что-то не похоже, что крупные сети под себя все подминают.
gennayo
Не видя полного исследования сложно что-то сказать. Возможно, в некоторых регионах одна крупная местная сеть успешно противостоит федералам. У нас, в Нижегородской области таковой является сеть Спар компании Сладкая Жизнь (кстати, работают на 1С, если что) Кроме них и федералов больше сетей крупнее 4-5 магазинов не наблюдается.
CrushBy
Ок, Гугл:
Первое, что нашел.
Еще искать?
gennayo
О, это прекрасный пример. Эта сеть сдала в 2016 году 90% своих магазинов X5, а в этом году были закрыты оставшиеся 6 магазинов…
Veidt
Но при этом вы уверенно заявляете:
Есть еще много исследований на эту тему с теми же выводами. Ну и наш внутренний market research их подтверждает. Хотя возможно у вас в нижегородской области все по другому. Но это типичный «эффект окружения».
Кстати интересно на чем? Астор? Далион? Магазька? Или УТ + Розница в РИБ?
gennayo
В ситуации «одна региональная сеть противостоит федералам» вам всё равно ничего не светит. Если эта сеть выжила — значит с автоматизацией там всё в порядке.
В Спарах что на фронте не знаю, в бэке самописка на 1С, и WMS на 1С. WMS, кстати, обрабатывает примерно 250 тыс. строк заказов на отгрузку в сутки, и не тормозит :))
Veidt
Поверьте, все не так просто, у нас большой опыт в этом вопросе. В любом случае, поживем, увидим. Спасибо за информацию.
PS: Кстати а у них единая база или распределенная. И по RDP или тонкий клиент?
gennayo
Даже если автоматизация не идеальна, переход на другую, совершенно инородную для текущего ИТ-ландшафта платформу, это очень большой риск и затраты.
Про детали как там у них что работает не знаю ничего, инсайдеров там у меня нет :))
NitroJunkie
У нас 5 таких крупных проектов за последние несколько лет было. Да, не просто, но мы научились это делать с минимальными рисками / затратами.
gennayo
Не нашёл там 30%. 47-48 вроде…
CrushBy
Ничего страшного. Хватит и половины российского рынка. Вы скорее динамику посмотрите. Или они 10 лет концы с концами сводят, но никак не сведут?
Veidt
Там прямо в заголовке 17. 47-48 это федеральные но это и по 20 магазинов сети, просто у которых в нескольких регионах магазины. Если чуть глубже копнуть видно что, экспоненциально выручка в топе убывает.
И кстати там же есть картинка, что рост процента доли рынка топ 10 сетей остановился в последние пару лет.
Nilpferd
Не соглашусь. Положим, наследовать объекты может и действительно нужно раз в 10 лет, но инкапсуляции реально не хватает.
puyol_dev2
Ну как сказать проще… Отсутствие ООП в 1С порождает огромное количество дублирующего кода. Платформе 1С на это фиолетово, а вот программисту сидеть во всей этой каше разбираться — занимает немало времени. Система, представленная автором статьи, как я понимаю, лишена этого недостатка
MinimaJack
При чем ООП и дублирование кода?
В 1С есть общие модули, формы и т.п. и ничего адекватному программисту не мешает выделить дублированный код в отдельную функцию…
Да — очень много похожего кода… но он разный
LeshaLS
Действительно, зачем «умные» люди придумали ООП? Есть же Copy/Paste.
Мне почему-то вспоминается Шариков: «А то пишут, пишут… конгресс, немцы какие-то… Голова пухнет. Взять всё, да и поделить...»
puyol_dev2
Вот и я про тоже. Ради одного нового свойства (реквизита) или изменения типа текущего, в 1С копируется весь объект метаданных
Ivanko63rus
Это кто вам сказал такую глупость? Вы хоть типовые посмотрели бы, например у документов бывают десятки свойств отображаемые пользователю и заполняемые ситуативно. Следуя вашей логике например в Бухгалтерии бюджетного учреждения должно быть документов тьма просто, тот же ПКО вместо одного должно с десяток быть. И с каждым обновлением еще с 1000 новых добавляться каждый месяц))
Есть составные типы, есть возможность прикрутить характеристики с произвольным набором свойств…
Если объект метаданных копируется, значит есть причины которые нужно искать не в ограничениях Платформы 1С а в первую очередь Бизнес-логике прикладного решения или ТЗ на разработку.
Платформа позволит вообще все засунуть в один объект метаданных, но это ведь не значит что решение будет хорошим? как и в любом ООП…
И точно такое же утверждение можно сказать про любой ООП язык, что для добавления нового метода/свойства нужно создать новый класс наследованный от некоторого базового… И данное утверждение будет и верным и не верным в зависимости от решаемой задачи.
DAleby
Ну как при чем? Наследование и полиморфизм позволяют уменьшить дублирование кода. А в ООП есть наследование и полиморфизм.
MinimaJack
LeshaLS
DAleby
Да никто не спорит с этим… только в 1С нет "фигур для которых надо считать площадь". Можно пример бизнес задачи — где такое может потребоваться?
LeshaLS
Так именно об этом статья. Что можно применять ООП, например, для реализации регистров.
MinimaJack
Что то не убедили в целесообразности...
puyol_dev2
Создаешь тип документ в 1С, и хочешь создать точно такой же, но с «перламутровыми пуговицами». В 1С решается это копипастой и последующим редактированием. В ООП это решается наследованием красиво и просто
MinimaJack
Можно бизнес-пример, а не перламутровые пуговицы?
Обычно документы связаны логически, если одинаковые добавляют "Вид операции"...
Neikist
И со временем обычно появляются реквизиты специфичные для одного вида операции а для другого не нужные, знаем, плавали.
MinimaJack
Neikist
Что удобней? Получить 20 разных документов — или несколько лишних реквизитов?
Neikist
По ситуации. Может там вообще композиция нужна. Но лишние поля — ооочень нежелательны как по мне.
MinimaJack
Ну так в 1С и есть композиция...
Neikist puyol_dev2 вот вы реально думаете что станет лучше и легче? Вот эта та кнопка которая все сделает?
Ок… будет 100 похожих документов, что будет с их хранением? В разных таблицах или одной? Что будет с производительностью join-ов? Что с нормализацией базы? Как будут происходить миграции? Вы думали как раздуются запросы?
Neikist
Я не совсем в таком виде композицию имел, но да ладно. И да, после того как я ушел с языка 1с на котлин мне действительно стало намного комфортней писать код, пусть задачи и другие.
А о связи с базой я вообще ничего не говорил, на мой взгляд это все же отдельным слоем должно быть.
MinimaJack
Ну а где по вашему хранятся дополнительные реквизиты?
Одно дело использовать ООП для объектов хранящихся в памяти — другое дело смапить все ООП и данные в БД. Да, это возможно — но это очень и очень неудобно. А говорить об адекватной миграции, изменении классов родителей — так вообще жуть.
Neikist
Ну собсно вы сами ответили, разделить то с чем в данный момент работаем и данные в базе, я же и говорю про документы как объекты в памяти которые нужно валидировать, выполнять связанную бизнес логику (вроде оповещений на почту), отображать на экране, форматировать для отчетов и хз что еще придумать можно.
MinimaJack
Вы в своей практике делали маппинг в базу объектов( с наследованием) или вы только мечтаете о таком?
Я бы тоже не отказался… еще и автоматический, еще бы и с миграциями)
Да я скорее откажусь от наследования — чем соглашусь руками все прописывать)
Neikist
Пока масштаб проектов не тот, но вообще Room под андроид вполне неплохие средства работы с БД предоставляет.
puyol_dev2
Я бы на месте 1с ников про маппинг между объектами метаданных 1с и таблицами в субд вообще молчал. Если посмотреть какой запрос делает платформа в субд — можно ужаснуться количеству join ов даже для одного «документа» 1с
MinimaJack
предложите варианты решения… что делать когда сотни связанных данных?
Я вижу всего 2 варианта работы в реляционной БД: либо жесткая денормализация, либо join-ы.
Как вариант выкинуть реляционные и использовать графовые БД, но они не так давно то и появились(хорошего уровня) — и у них свои проблемы...
o4karek
Стоит вначале посмотреть на оригинальный запрос. Может столько джойнов — это результат бездумного обращения «через точку» у автора оригинального запроса?
o4karek
Может в этом дело? ;)
Neikist
Ну так я периодически вспоминаю 1сный опыт и прикидываю как какие то элементы из текущей работы было бы удобно там использовать.
o4karek
А потом кто-то меняет базовый класс и внезапно все ломается во всех унаследованных документах. Особенно если это на внедрении (а там сильный стресс), особенно, если у внедренца квалификации не хватает.
А если на N-ый год развития системы выясняется, что существующая иерархия классов перестает устраивать с точки зрения развития системы? А там же совместимость надо поддержать, ведь уже много чего унаследовано.
Это я к тому, что нет серебряной пули (@evilBearer — это я не про вас ;)). Каждый способ имеет свои плюсы и минусы. И уж точно — это не ключевой момент в автоматизации экономики.
Neikist
Мне много раз было грустно от того что некоторые паттерны вроде наблюдателя или шаблонного метода какого невозможно адекватно реализовать, только кучей кривоватого кода, а они вполне себе нередко к месту что в бизнес логике были, что в работе с формами.
Nilpferd
Придирки по мелочам:
Довольно часто бизнес-схемы подразумевают условную отгрузку в минус, т.е если по отгрузке выполняются некие условия(причем динамически настраиваемые), то отгружать можно в минус. Оцените боль программистов, у которых ограничение на отрицательные остатки зашиты в платформу.
Строка документа?строка набора записи. На строку документа может создавать сколько угодно строк в регистре. Контроль уникальности записей подразумевает невозможность существования в регистре двух записей с одинаковым ключом.
Схема регистров в 1С позволяет хранить довольно большой объем информации с более-менее приемлемой скоростью получения необходимых данных. Композиция — это просто следствие того, что есть два уровня логики — внешний и внутренний, которые естественно должны быть связаны; это точно не главное свойство регистров и документов, тем более, что есть возможность создавать записи регистров без связи с документами и документы без связи с регистрами.
В целом — да, полноценного ООП в 1С не хватает. Вся беда в том, что то, что уже есть (документы, регистры и т.д.) покрывает 99% потребностей для описания логики бизнес-процессов(а собственно это и есть область применения 1С). А на оставшийся процент — ну есть ведь внешние компоненты, которые тоже можно использовать.
Кстати, было бы интересно провести эксперимент: взять какую-то более-менее рабочую(в том смысле, что не высосанную из пальца) бизнес-схему и попробовать реализовать на разных фреймворках, а потом сравнить по производительности, количеству используемой памяти, времени на разработку и т.д.
P.S. В целом: статья — это интересный взгляд ещё с одной стороны на эту сферу разработки.
CrushBy
Они не зашиты в платформу. Вы как раз можете ими управлять очень гибко. Например:
godMode = DATA BOOLEAN (User);
CONSTRAINT balance(Stock st, Sku sk) < 0 AND NOT godMode(currentUser())
MESSAGE 'Остаток по товару на складе должен быть положительным';
И для пользователя, у которого включена галочка godMode, сможет проводить без ограничения. И там выражения можно делать очень разные.
Nilpferd
Не для юзера. Для набора условий. Причем набор условий(остатки, склад, условия договора, задолженность, приоритет контрагента и т.д.) может меняться без участия программиста самим пользователем. То есть нужно не хардкодить условия, а создавать инструмент, при помощи которого пользователь будет управлять условиями. Это и будет «гибко». И если всё это реализовать, то получится в общем-то тоже самое, что и в 1С УТ(которая приводится, как образец боли программиста).
P.S. Давать godMode пользователю — это то же самое, что и давать пациенту возможность выписывать самому себе лекарства. Это оочень плохая идея, поверьте.
CrushBy
godMode я привел для примера и хорошо осознаю последствия. Справедливости ради набор условий, который не привязан к складу, а к конкретным операциям также дает кучу возможностей для манипуляции, так как завязывается на последовательность операций. То есть можно будет взять всех «приоритетные» документы, распровести их, провести неприоритетные, а затем обратно приоритетные. И получится, что ограничение обошли.
Но в целом, это также легко и декларативно реализуется. Вот например:
checkNegative = DATA BOOLEAN (Stock);
allowNegative = DATA BOOLEAN (Customer);
CONSTRAINT CHANGED(quantity(SkuLedger l)) AND balance(stock(l), sku(l)) < 0
AND checkNegative(stock(l)) AND NOT allowNegative(customer(l))
MESSAGE 'Остаток по товару на складе должен быть положительным';
И опять же выражение можно усложнять как угодно. Или добавлять, например, несколько ограничений.
Да, конечно. Только это делается 1С-программистом, а не самой платформой, которая слабо ему в этом помогает.
MinimaJack
А этот код кто будет писать, не программист ли часом? Какие преимущества описания ограничений в платформе, по сравнению с описанием ограничений в конкретной конфигурации?
CrushBy
Напишите сначала про какое описание ограничений в конкретной конфигурации идет речь? Это часом не 1С-программист делает?
MinimaJack
Остатков, и аналогично делает программист...
CrushBy
Да, только в моем примере это делается красиво декларативно, а в 1С — смотрите код ниже.
MinimaJack
Красиво можете "1+1=2" написать, давайте не сравнивать платформу и конфигурацию.
Все сводится к одному: в платформе 1С нет встроенного контроля отрицательных остатков. Все!
А вот вопрос его целесообразности — это уже вкусовщина
CrushBy
Мы сравниваем именно 2 платформы. На одной один функционал реализуется несколькими строками, а в другой — тонной странного кода.
В 1С нету много чего еще. Это всего лишь один случай, описанный в статье. Например, там также через тонной бессмысленного кода реализуется Подбор, по сравнению с минимальным кодом в lsFusion.
NitroJunkie
А вы видели, как в УТ такие ограничения проверяются? Я напомню:
В ПередЗаписи регистра (например ТоварыКОтгрузке):
Nilpferd
Есть такая штука, называется «скорость работы». Есть у меня подозрение, что приведенный код работает на порядок(а с учетом параллельной работы в базе пары тысяч пользователей, так и на несколько порядков) быстрее, чем то, что в IsFusion делается одной строкой. И приведенный отрывок — это не проверка, а получение данных, необходимых для записи с учетом всех нужных проверок. Хотя запрос — да, кривоватый.
NitroJunkie
Есть. И решения уровня ERP на lsFusion работают в FMCG-сетях с терабайтными базами и сотнями (а иногда и тысячами) одновременных пользователей на оборудовании стоимостью 10-20к. И там именно вот такие декларативные ограничения в одну строку. Вот кстати репозитарий общего набора модулей:
github.com/lsfusion-solutions/erp/tree/master/erp-logics/src/main/lsfusion
Хоть убей не понял что вы написали. Я делал CTRL+SHIFT+F ДвиженияТоварыКОтгрузкеИзменениеСводно, ДвиженияТоварыКОтгрузкеПередЗаписью. И они используются чисто для проверки ограничений.
То есть люди, которые писали второе самое распространенное решение на 1С, написали его криво. Может проблема в консерватории?
Nilpferd
Без сравнения функционала не получится оценить производительности.
Я сужу чисто по коду: первый отрывок — выбираются все данные по товарам к отгрузке по данному документу и изменяются с учетом отложенного резервного товара, второй отрывок — эти данные проверяются на выбранные условия и проверяются на то, как они влияют на другие отгрузки, видимо далее где-то идет запись в регистр проверенных данных, а третий отрывок — это уже собственно контроль данных итоговой таблицы.
Это всего лишь моя оценка запроса, я просто не знаю всей информации по данному процессу, может быть у людей написавших это и были свои резоны.
NitroJunkie
Я же написал уровня ERP. Понятно что в деталях есть отличия, но объем функционала, даже больше чем УТ, но хотя наверное все же поменьше чем 1С ERP. Но если что, можете там коммиты глянуть, задач в таск трекере и кода конкретных клиентов вы не увидите, но хотя бы по их тексту и самим изменениям в коде приблизительное впечатление можно составить.
Нет, ДвиженияТоварыКОтгрузкеПередЗаписью, ДвиженияТоварыКОтгрузкеИзменениеСводно используются только в этих 3 кусках кода. Можете сами проверить. То есть это чисто проверка ограничения.
Так там таких проверок в этой процедуре 2400 строк. И все по одной / похожей схеме сделаны. А вы же говорили, что с УТ периодически работаете.
Nilpferd
Ещё раз внимательно прочитайте тексты приведенных Вами же примеров. Кроме проверки на остаток там много ещё чего.
Сделаны по похожей схеме — не означает дублирование кода. Потому как даже в Ваших примерах кроме проверки делается много действий. И тем более, я сомневаюсь, что все 2400 строк модуля посвящены проверке остатка. Под рукой УТ 11.3 у меня нет(имеется в виду же эта версия?), а то, что я с ней периодически работаю — не означает, что я помню наизусть тексты всех модулей.
NitroJunkie
Еще раз первый и второй код ТОЛЬКО заполняют временные таблицы (больше этот код ничего не делают):
Эти таблицы используются ТОЛЬКО в третьем коде. Который ТОЛЬКО проверяет ограничение.
Да, УТ — 11.3.4.
Nilpferd
Ещё раз: внимательно посмотрите КАК и ЧЕМ они заполняются.
Update: видимо слишком строг к Вам. Посмотрите внимательно: наименования полей «КОтгрузкеИзменение», «СобираетсяИзменение», «СобраноИзменение» — неужели Вы думаете, что это вроде как одно и то же и это просто решили продублировать? Или это все-таки несколько разных полей, которые используются для разных целей, каждое для своей? А то, что последний кусок у вас обрывается на формировании текста запроса Вас не смутило? Может быть там далее ещё что-то есть? А строка МассивКонтролей.Добавить(...) — неужели не натолкнула Вас на мысль, что там(и не только там) используется целый массив с перечнем контролей и что ради одной жалкой проверки на остатки не было смысла городить целый механизм с возможностью динамического формирования системы проверок? И что глобальный поиск по наименованию временной таблицы не равноценен выяснению всего пути от начала и до конца, по которому движутся данные?
NitroJunkie
Этот МассивКонтролей используется в одном месте:
Nilpferd
Почему? Вам трудно читать на русском?
Хорошо. Если у Вас кончились идеи, я дам вам совет(если разумеется осталось время и желание). Забейте в окно глобального поиска любое из названий контроля(а там ведь их больше 30, если не ошибаюсь). И поищите, где оно может инициализироваться. А если лень, то я вам в общих чертах расскажу: в тех местах где необходим контроль(а это ведь не только документы), собираются нужные данные(в каждом месте — контролируются свои показатели и свои данные, и соответственно везде свой запрос), там же настраивается система проверок(тот самый массив контролей), далее — собранные данные через менеджер временных таблиц(те самые ДанныеТаблиц) и система проверок через МассивКонтролей передается сюда, в это место. И здесь по каждой из проверок определяется был ли нарушен контроль в тех данных, которые передаются через ДанныеТаблиц.
NitroJunkie
Нет, мне плевать на русский. От такого количество однотипных If в одном месте, и прикладных объектов в строках, которые ни одна IDE не найдет.
Еще раз я не к тому зачем нужен массивконтролей. Это конечно код в стиле привет 70е, я такой код видел 20 лет назад и думал больше его не увижу, но пришлось. В любом случае не суть. Я говорил про три куска кода, которые я привел. Их ЕДИНСТВЕННАЯ функция проверка что ТоваровКОтгрузке > 0. Можно его вырезать и ничего не изменится, кроме того что проверка исчезнет. И по сути на эту проверку написано под 300 строк кода. Это нормально по вашему?
Nilpferd
Что поделать, так реализован switch в 1С. Но ведь и про С++ Вы бы написали, что у Вас слезятся глаза от такого количества однотипных case, верно?
боюсь, тут проблема не в IDE. Те, кто работает с 1С ищут и находят же.
Что-то я устал от дискуссии. Применительно ко всем комментариям под статьей — эффект Даннига-Крюгера в чистом виде.
NitroJunkie
Просто для этого ООП, а точнее наследование и полиморфизм придумали, чтобы не было такого количества IF. О чем собственно и статья частично.
Ну на COBOL'е тоже люди как-то пишут. Но когда привыкаешь к хорошему, от плохого быстро отвыкаешь.
Если честно я тоже устал, но в любом случае спасибо за более-менее конструктивную дискуссию.
MinimaJack
ага, ага… списание только с определенного склада, при реализации только от одной организации определенному контрагенту и только при "не переходе права собственности"
Красиво выглядит, не более того. В реальных условиях — будет тот же самый код.
NitroJunkie
Сверху приводили, равно как и код на 1С.
NitroJunkie
Безотносительно, того что ограничения можно делать условными, снимать для администраторов и т.п., оцените боль администраторов и пользователей, которые не могут понять какого черта остаток вдруг стал отрицательным и что с этим теперь делать.
Вы код УТ к примеру видели? Для меня если честно загадка, как в нем хоть что-то можно изменить.
То есть с теми абстракциями, которые как вы говорите покрывают 99% потребностей бизнес-процессов, конечное решение вроде УТ это нативный SQL с тоннами if'ов и императивного кода с техническим долгом такого уровня, что я не уверен, что разработчики этой конфигурации сами разбираются в этом коде. А что делать обычному разработчику, когда его попросят что-то изменить? Остается только как в SAP сказать вы просто неправильно работаете.
Nilpferd
Вы не поверите, но я с ней периодически работаю. Технического долга там не очень много, а у тех версий, которые уже давным давно вылизаны, так и вовсе. И работа кода вполне прозрачна.
Вся беда в том, что сейчас — это «нативный SQL с тоннами if'ов и императивного кода с техническим долгом» использующий стандартные возможности, известные всем, кто работает с этими возможностями и есть вероятность, что разработчик окажется достаточного уровня, чтобы со всем этим разобраться. А вот альтернатива — это «идеально вылизанный ООП продукт»(созданный с использованием «домашней» библиотеки), в котором, кроме автора разобраться никто не сможет. Собственно и сейчас есть возможность пристегнуть свои внешние компоненты(как раз те самые «вылизанные ООП продукты») и вот когда с таким сталкиваешься — вот это реальная боль программиста.
NitroJunkie
Мы наверное разное понимаем под техническим долгом, я в данном случае говорю о дублировании абстракций, а там если открыть какой-нибудь КонтрольПроведения видно что там с десяток проверок делающих очень похожие вещи. Но может это субьективное ощущение.
Круто. То есть если сильно повезет, кто-то во всем этом разберется. Но даже если так повезет, представляете сколько он будет стоить? Ведь по сути это человек уровня Full-stack JS Developer'а (так как 1С умудрился отказаться одновременно и от ORM, и от всех нормальных возможностей SQL, в том числе блокировок, одного flow для сервера и клиента, с этими дурацким &НаКлиенте, &НаСервере, ну и как вишенка на торте модальности — предлагая всем перейти на callback'и) со знанием предметной области торговли.
Нет, альтернатива — идеально вылизанный ООП продукт, построенный на основе самых распространенных в мире технологий (Java, IDEA, Git, JasperReports), который позволяет одновременно создавать максимально модульный и декомпозированный код, и делать это на очень высоком уровне абстрагирования (где целостность, материализации, события, синхронизация сервера и клиента, модальности и т.п. поддерживаются из коробки, а не руками как в 1С), в котором разберется даже человек без опыта в IT.
Ну если смешать даже бочку меда с ложкой дегтя вы сами знаете что получается.
Nilpferd
Не очень понимаю, что такое «открыть КонтрольПроведения», но если Вы имеет в виду проверку на условия, подобные упомянутому в статье, то в объекте(документе) происходит только настройка структуры условий, а сама проверка по этим условиям — происходит в общем модуле(в частности в УТ модуль для проверок, связанных с перемещением материальных ценностей, так и называется — «Управление запасами»).
Ну ради справедливости, &НаКлиенте и &НаСервере — это довольно удобный инструмент, помогающий оптимизировать выполнение кода, правда таких случаев, когда он реально необходим — не очень много.
А в целом: да, всё верно, такой специалист стоит дорого. И да, без знания предметной области здесь тоже делать нечего. Так как, если абстрагировать логику от самой предметной области, то во-первых, на это нужен отдельный человек(который тоже стоит дорого) и плюс отдельно — разработчик. В сумме — дороговато получается. А так за в несколько раз меньшую сумму — получаем человека разбирающегося и в логике продукта, и в бизнес логике(а ведь ещё и законодательство нужно знать, это же не просто цифры, это вполне конкретные люди, предметы и действия, и за некоторые сочетания этих трех компонентов положена административная или уголовная ответственность). Получается, что тупо экономически невыгодно идти по пути самых распространенных в мире технологий, просто не взлетит.
Да, только в тех случаях, с которыми сталкивался я, ложкой дегтя была отнюдь не 1С.
NitroJunkie
Я про ПроведениеСерверУТ.ВыполнитьКонтрольРезультатовПроведения.
У него другая проблема, он разбивает flow, то есть если вам нужно сделать:
f() <- someData(); DIALOG myForm OBJECTS a INPUT DO // ОткрытьФорму IF isSomething(a) DO DIALOG otherForm OBJECTS b = a DO { // ОткрытьФорму g(b) <- someInput(b); APPLY; }Вам придется штук 5 процедур сделать (потому как ОткрытьФорму можно только на клиенте, а к данным обратиться только на сервере).
Плюс при таком явном flow на клиенте, неизбежно возникает проблема с блокированием EDT (что особо критично в веб). И как следствие там еще callback'и добавлять, а значит еще несколько процедур сделать. То есть их штук 7 в таком примитивном бизнес-процессе будет. Это нормально по вашему?
Вы считаете что человек-оркестр стоит дешевле двух узких специалистов? Это заблуждение, тут зачастую наоборот, дешевле и проще найти двух «обычных» разработчиков, научившихся «делать по аналогии», чем одну «звезду».
Что не отрицает того факта, что 1С очень далек от бочки меда. Кстати в современном варианте, 1С от JS вообще не сильно отличается. Только без возможности использования функций в качестве значений и замыканий, а это то немногое из-за чего JS вообще имеет смысл использовать.
Nilpferd
Это будет штук 7 читаемых, практически стандартных процедур. Для меня, в случае высоконагруженной базы главный критерий — это её работоспособность. И да, если база работает с 7 несуразными процедурами, но встает с одной красивой строкой кода, то 7 процедур — это нормально.
Нет, я считаю, что человек-оркестр стоит дешевле двух специалистов «широкого» профиля, а если брать «обычных»специалистов «узкого» профиля(а тем более научившихся только делать «по аналогии»), то их нужно уже человек пять, а это получается дороже.
Так никто же не говорит, что 1С — это какой-то непогрешимый идеал. Это просто инструмент со своими недостатками. Как впрочем и любой другой из перечисленных в этой теме.
NitroJunkie
Как 7 процедур из одной строки с рандомными названиями и callback'ами могут быть читаемыми?
Не, это я как раз понимаю. Но в 1С вместо того, чтобы сделать простую разработку масштабируемой, просто переложили все на разработчика, то есть сказали это теперь ваши проблемы. То есть повысили порог вхождения до очень высокого уровня, плюс заодно добавили кучу возможностей выстрелить себе в ногу.
Даже пять человек будут дешевле. Но опять таки речь о другом. Как раз платформа должна решать большинство проблем, и тогда достаточно будет человека даже без опыта в IT. И найти его куда проще, проверено опытом.
Вопрос в том, что 1С умудрился накосячить как раз во всем в чем мог. Если честно даже удивительно. Они взяли все самое худшее от существующих технологий, при этом выкинув самое лучшее.
trdm
Придирки не по мелочам: описывать структуры данных текстом, как предлагает lsfusion, да еще и руслишем в наше время это дичайшая дичь.
Полторы тысячи таблиц и десятки тысяч их атрибутов в боевой системе, сотни тысяч пропертей этих атрибутов и таблиц (на каждом размерность, тип, индексируемость, доступность) — совсем не редкость. Писать все тестом, следя за правильностью написания, соответствие размерностям, отслеживать связи.
Система гарантирует глупую ненужную работу колоссального объема специалистам.
Это будет тот еще адский ад.
1С хороша согласованными инструментами, которые избавляют специалиста от геморроя.
CrushBy
Опять вы со своим визуальным программированием. Ну плохо оно работает на больших проектах с большими командами хотя бы из-за системы контроля версий. Как вы будете gitflow поддерживать, например? Как merge conflict'ы решать? Смиритесь наконец.
trdm
Это решается планированием и согласованием, этой проблемы в следствие существования её решения не существует.
Зато другие описанные выше проблемы в вашей системе существуют "от дизайна". И эти проблемы куда серьезнее, чем вы думаете.
CrushBy
Издеваетесь? А git придумали дураки, да? Они же не знали такого простого решения, которое знают истинные 1совцы.
NitroJunkie
Вообще это все IDE complet'ит, проверяет ошибки и раскрашивает. Особенно если в языке есть явная типизация.
Серьезно? Полотна кода с процедурами по 2400 строк и сотнями if'ов и ручных sql запросов, без каких либо проверок типов.
MinimaJack
https://lsfusion.org/comparison — за гранью добра и зла...
Veidt
Очень аргументированно.
MinimaJack
А что там аргументировать? Вы перейдите и посмотрите…
"No ORM, Yes SQL"
"Эффективное общение клиента с сервером"
"Бесшовное подключение Java-библиотек / SQL-функций"
"Эргономичный язык"
Veidt
Ну перешел. И что?
Так в 1С если в цикле обращаться по ссылке, то для 100 записей будет 100 запросов. Собственно поэтому 1С и рекомендует везде писать SQL запросы руками (то есть грубо говоря забить на 1С)
Ну так запустите УТ, откройте какой-нибудь документ и увидите, что там сначала будет 25 текущих вызовов, потом на любом следующем около 4. Ну или попробуйте тонкого клиента на нестабильной сети (которая TCP/IP пакеты теряет) какой-нибудь запустить.
Ну расскажите, как в 1С сторонний код подключить к серверу приложений. Так чтобы затрат на вызов не было, а не упаси боже ActiveX. Ну и заодно про то как custom SQL функции подключать в 1С, учитывая что там лицензионно запрещено лазить в базу.
Ну и как в 1С к примеру с явной типизацией или замыканиями? Вы же понимаете, что более убогий язык чем 1С надо поискать. Это такой JavaScript, в котором вырезали все его преимущества.
MinimaJack
Грубо говоря — для разных задач 1С позволяет использовать разный инструмент — правильно? Где то можно и по ссылке использовать, где то оптимальным будет запрос написать… в чем минус то? В lsFusion — нельзя написать запрос в цикле?
25 вызовов… на любом следующем 4 — это ж хорошо — часть данных закешировалась… Конечно идеально было бы один вызов всегда, но так ли это смертельно; веб сайты не сильно отличаются обновил страницу хабра — 50 запросов.
В 1С есть и шифрование и сжатие...
внешние компоненты по технологии native api, и да в 1С я могу и java библиотеки использовать...
никак с типизацией и замыканиями, это не типизированный и не функциональный язык… я даже больше скажу там операций инкремента на единицу нет...
Veidt
В lsFusion можно написать FOR, но он в большинстве случаев скомпилируется в один SQL запрос. А если 1С писать не нативным SQL, то будет классическая N+1 проблема. А в 1С даже никакого prefetching'а как в других ORM нет.
Если у вас сервак в облаке то очень критично. Собственно зайдите на demo-ma.1c.ru. Там монитор в окно кинуть хочется от этих задержек. Или вы думаете себе 1С не мог позволить нормальный сервак поставить?
Ну про SQL вы не ответили. А про native api это вы это имеете ввиду? Очень бесшовно.
Ну то есть язык убогий, чуть менее чем полностью. Собственно что в сравнении и отмечено.
MinimaJack
То есть возможна ситуация с некачественной генерацией. Чего в 1С можно избежать запросом… правильно я вас понял?
Никто ж не говорит что стандартные конфигурации идеально оптимизированы
Достаточно раз написать и обернуть удобным образом...lsFusion позволяет подключать dll, позволяет работать с Com-компонентами — бесшовно?
И вы не понимаете что это далеко не главное?
Veidt
Нет, если вы в 1С напишете цикл это будет цикл. В lsFusion
FOR f(a) DO g(a) <- h(a);Скомпилируется в:
И выполнится одним запросом.
Ну если даже стандартные не идеально оптимизировано, что тогда творится с нестандартными, где нет миллионных бюджетов.
В lsFusion достаточно написать
myAction INTERNAL 'MyAction' (A);
Все подключился java-класс в ту же виртуальную машину.
doSomething(A a) { myAction(a); }Или можно в lsfusion.xml:
<util:list id="customLifecycleListeners"> <ref bean="equipmentServer"/> </util:list>И при помощи Java Spring автоматически подключится любой java-сервер.То есть именно фишки динамического java classloading используются.
Так в сравнении это один из 33 пунктов.
o4karek
Это мне напомнило сравнение 1с и Аксапты/САПа персонажем по имени «Гений 1С» aka fixin. Примерно такой же уровень получился…
EvilBeaver
Вот и мне напомнило :)
EvilBeaver
Саша, кажется он недалеко…
o4karek
:) Не буди лихо, пока оно тихо :)
botokash
Обращение сервера к клиенту — минусы в колонках с 1С явно перепутаны.
Veidt
Там вот какая штука скорее всего имеется ввиду. В ОФ(1С<8.2), там один flow, то есть пишется какой-то бизнес-процесс, в нем надо что-то спросить у пользователя — не вопрос: ставим ОткрытьФормуМодально, читаем то что надо, поехали дальше. А в УФ (1С>=8.2 условно) надо извращаться — там сверху был коммент NitroJunkie на эту тему.
Asmody
Я возможно упустил из виду. Вопрос про количество реальных внедрений решений на базе этого IsFusion уже был?
CrushBy
Около половины крупнейших FMCG сетей Беларуси.
o4karek
А в штуках сколько? Порядка 5-10 внедрений?
Я, к сожалению, не владею информацией по ассортименту торговых сетей Белоруссии.
CrushBy
Всего, на данный момент, около 40 внедрений. Но все — относительно крупные клиенты (от 50 до 1000 одновременно работающих пользователей).
o4karek
Спасибо
EvilBeaver
Господи, что это?! Фортраноподобный 1С?
CrushBy
А у Вас фортранофобия? Вообще тут совершенно другой принцип работы с данными и логикой GUI по сравнению с 1С.
EvilBeaver
Ну GUI в статье отсутствовал, так что про него судить не могу. У меня да, фортранофобия и паскалефобия, я привык к современным языкам. Это не значит, что они лучше фортрана, но фобии и предпочтения это же дело персональное, правда?
CrushBy
Так это вообще была локальная статья именно про регистры. Про GUI будут отдельные статьи. Посмотрите, например, реализацию Подбора.
А Вы считаете 1С современным языком?
DAleby
Сравнение с Фортраном основано только на том, что ключевые слова пишутся большими буквами?
EvilBeaver
Не только. Хотя да, на SAP ABAP оно похоже чуть больше, чем на Фортран
DAleby
Это все схожести на лексическом уровне. То есть Fortran (вернее не Fortran, а скорее Algol или Oberon) напоминает большими буквами в ключевых словах, ABAP большим количеством ключевых слов (больше не знаю, чем может напоминать, но я видел мало кода на ABAP). Так можно и c SQL сравнить, хотя с SQL схожесть можно найти уже не только на лексическом уровне. Но если посмотреть чуть выше, хотя бы на синтаксический уровень, то нет, не похож lsfusion ни на Fortran, ни на ABAP, совсем.
EvilBeaver
Хм… посмотрел на UI в демо примере. Вы уверены, что стоит выносить это в паблик?
CrushBy
Ну а как запретить неадекватным личностям что-то редактировать, но разрешить адекватным? Сейчас товарищи с мисты успокоятся и перевосстановим базу.
EvilBeaver
Сделать рид-онли и давать доступ после регистрации на почту. А «на посмотреть» записать видео-демо.
Это был бесплатный маркетинговый совет. Первый и последний, не благодарите.
CrushBy
Только даже у 1С не так. Заходи кто хочешь и правь что хочешь.
И вообще — у нас нету маркетологов. Мы обычные простые технари от сохи. Даже не продаем платформу, как гении маркетинга из 1С, а раздаем бесплатно под LGPL. Что с нас возьмешь… Дурачки одним словом.
mayorovp
Можно базу демонстрационную базу восстанавливать по расписанию.