Опыт подсказывает, что недостатки есть так же и у вас.
Вы невнимательно читаете. У LsFusion нет недостатков (или их тщательно скрывают).
Я для себя из статей вынес следующие факты:
1) Если сравнивать 1С,SQL,SAP… и LSFusion по критериям «быстро, дешево, качественно» — LSFusion выигрывает по всем трем показателям.
2) 1С,SQL,SAP… примитивнее, но изучить LSFusion проще и быстрее.
3) 1С,SQL,SAP… это дорого, но разработчики на LSFusion зарабатывают больше и условия труда лучше.
4) Если чего-то в LsFusion нет, то только по одной из причин:
а) это неправильно;
б) это не нужно пользователям;
в) это не нужно программистам;
г) слишком просто и не интересно делать;
Я не знаю, что такое табличный документ. Это какой-то плод больной фантазии одного из разработчиков 1С. Есть формы. Зачем нужна вторая абстракция?
Табличный документ — это свой велосипед 1С, который они написали для того чтобы не привязываться к Excel. Так же как и файловая база у них появилась, когда использование SQL не планировалось.
Вы поступили проще — взяли готовые решения.
А зачем разработчики типовых это делают 3-мя запросами. В lsFusion тоже самое делается одной строкой.
1) возможно, внутренние стандарты команды или 1С;
2) возможно, неотрефакторенная кодовая база от ERP (т.е. в ERP используется аналогичный запрос, но делаются дополнительные проверки);
3) возможно, legacy или говнокод;
4) еще масса причин, которую точно смогут сказать только авторы конкретной типовой.
Нет, исходя из ответов на другие мои комментарии не одной строкой. Само свойство quantityAvailable(st,sk) «описывается ранее».
quantityReserved в данном примере — это просто ранее объявленное свойство с соотвествующей логикой, вычисляющей то, что она должна по примеру вычислять.
Отлично. Мы вышли на финишную прямую.
Теперь повторю первоначальный вопрос: чем отличается «ранее объявленное свойство с соответствующей логикой», которое вы загоняете в CONSTRAINT от «объявленной ранее функции 1С ПроверитьОтрицательныеОстатки(Документ)», обращение к которой будет загнано в событие «ОбработкаПроведения»?
И там и там нужно заранее написать код. И там и там в нужном месте указать его вызов (да, я понимаю что у вас это не совсем «вызов метода», но с точки зрения трудозатрат программиста по нажиманию кнопок клавиатуры разница небольшая).
*ирония* Получается, что когда 1С не дает редактировать данные в динамических списках, то это минус 1С. Когда у вас нет возможности (при необходимости!) использовать для интерактивной работы табличный документ — это все равно недостаток 1С?
В теме про подбор люди предлагали отчеты использовать для реализации WYSIWYG интерфейсов ввода.
Потому что для работы с информацией, которую не надо печатать, есть формы
В теме про подбор, вами (возможно, не лично, а кем-то из коллег), утверждалось, что подбор «как в excel» реализовать невозможно. Вариант с табличным документом приводился как один из возможных вариантов реализации, причем в номинации «ну если хотите, можно и так извратиться».
Непонятно зачем нужные, когда есть формы. И ни в одной другой технологии их нет.
Не совсем понимаю вас. Есть возможность использовать табличный документ как простую неинтерактивную форму.
Есть возможность, навешивать на табличный документ события и работать с ним интерактивно.
В чем проблема-то у вас? Не нравится — не используйте. У меня пользователи просили реализовать им интерактивность в печатных формах. Не вижу в этом проблемы.
Еще раз. В 1с это делается 1(!) запросом строчек на 10. Пример на Мисте лично я вам приводил. Это если мы говорим о простой табличке SKU|Stock|Quantity и таком же простом документе, без дополнительной логики.
Вы реально не понимаете как это делается в lsFusion?
Нет, это вы меня не понимаете, как мне кажется.
Как ваша платформа понимает, что делать когда вы пишете «quantityReserved(st,sk)»?
Как много таких «предопределенных» действий определено и как будет выглядеть условие, если мы выходим за рамки простой захардкоженной проверки по 1-2 реквизитам, а условие накладывается в зависимости от данных в других таблицах?
Если колонка Reserved находится в другой таблице, как платформа понимает, что quantityReserved нужно считать именно по ней?
Хм. Т.е. если жадный и некомпетентный заказчик будет искать себе java разработчика за тарелку супа, то это признак того что java — говно?
Примечательно, что в описанном случае заказчик себе исполнителя так и не нашел.
Перечитайте мои комментарии в этой ветке. Участки текста, которые начинаются с большой буквы и заканчиваются знаком "?" — называются вопросами. Пожалуйста, ответьте на все или часть из них.
Я хорошо понимаю что такое модульность. Но раз уж вы сравниваете ужей с ежами, считаю себя в праве заниматься тем же.
С точки зрения заказчика, ваша модульность от «поставим галку и теперь у вас есть скидки» не отличается ничем.
С точки зрения разработчика различие не более чем вопрос удобства.
Вы столько уже написали в обсуждениях нашей платформы, но до сих пор не поняли, что никаких «процедур» в обсуждаемом контексте у нас нет.
Детский сад, штаны на лямках.
Что скрывается за «quantityAvailable(Stock st, Sku sk) > 0»?
Что такое «quantityAvailable»? Функция? Процедура? Оператор?
Для любого существующего во вселенной условия у вас уже есть встроенный оператор(процедура, функция) вида «Condition42()» или для сложной бизнес-логики придется писать свой оператор(процедуру, функцию)?
А то, что расширения в 1С сделаны криво доказывает то, что УТ и ERP их не используют в коробке
Расширения предназначались для настройки решения при внедрении, поэтому в коробке ими и не пользуются.
УТ — это составная часть ERP, по сути — ERP это УТ + модули. Кодовая база одна.
То что у вас «модульность, когда мы клиенту подключаем за денежку то что ему нужно и ничего лишнего», в 1С — механизм функциональных опций, когда все уже внутри коробки, но появляется в интерфейсе/используется в коде только после установки галочки в настройках.
Что-то не думаю, что внутри его процедура isWarehouseN менее монструозна, чем в 1С, если речь идёт хоть о какой-то минимально сложной проверке.
Но эту процедуру мы не увидим. По крайней мере до сих пор, все эти процедуры скромно скрывались.
На предложение точно также прятать проверку остатков в 1С за процедуру «НетОтрицательныхОстатков(Документ)» реагируют тоже не слишком адекватно.
Ну т.е. идет сравнение ужа с ежом:
— простые встроенные в платформу проверки из lsfusion, которые быстро превращаются в цепочку вызовов неизвестных внешних процедур, как только проверка становится сложнее чем «проверить чтобы не ноль».
— сложные проверки с кучей условий, написанные в одном из типовых решений на 1С.
Да, если бы такие ограничения были встроенными в платформу, наверное было бы полезно. Но на практике, я могу вспомнить буквально пару-тройку случаев, когда такой простой проверки бы хватило для решений, которые я разрабатывал/поддерживал.
Вероятно, той же логики придерживались и разработчики платформы.
Можно считать это синдромом утенка или чем угодно, но если абстрагироваться от «круто было бы, если бы в платформе было все что только можно придумать», примерной аналогией будет карандаш с ластиком на конце. Да, удобно, но на практике все равно в комплект к нему нужно покупать нормальный.
Еще раз, поправьте меня, если я буду в чем-то не прав.
1) Есть таблица БД с тремя колонками:
Stock и SKU — в терминах 1С это «измерения регистра»
? некоторая колонка «количество» — в терминах 1С это «ресурс регистра».
Для данного ресурса вы задаете красивое и простое ограничение «quantityAvailable(Stock st, Sku sk) > 0;», что подразумевает, что по любой комбинации Stock и SKU не должно быть отрицательного остатка (ну и в контексте описанной).
Ок. Отлично.
В 1С такая проверка также делается 1 простым запросом, который вам приводился на стороннем форуме.
Но после этого начинаются интересные вопросы:
1) Как будет выглядеть проверка, если нужно контролировать остатки только по части складов/SKU? В 1С — добавляем условие в запрос, у вас — добавляем внешние функции с проверками, которые будут порождать дополнительный запрос (ну ок, у вас волшебный оптимизатор, который автоматически склеивает все в один запрос к БД).
2) Как будет выглядеть это ограничение, если нужно проверять не только «остаток не стал нулевым», а «остаток с учетом резервов не стал нулевым»? Опять же — в 1С мы редактируем все тот же запрос. А у вас?
Любопытно увидеть для вариантов «резерв это еще одна колонка таблицы» и «резерв, это колонка в другой таблице БД»?
Это я к тому, что отчеты в 1С зачем-то пытаются использовать для задач, для которых они не предназначены.
А как же ваше непоколебимое заверение «пользователи хотят как в excel»?
Ну и пример можно — «задач для которых они не предназначены»?
И кстати, исходя из какой логики вы считаете что «не предназначены»?
Расшифровку куда проще сделать на формах, зачем тянуть этот функционал в печатные формы?
Вот вы опять. Не «печатная форма», а «табличный документ». Который действительно может быть «печатной формой» («бланк договора», «бланк накладной», «этикетка») — и в таких случаях расшифровка не используется и никакой интерактивности (больше чем «разрешить внести изменения/изменить параметры печати») обычно не добавляется, и «выходная форма отчета», в которой в качестве «расшифровки» и «интерактивности» предполагается переходы к более детальным отчетам, открытия форм документов/справочников, упомянутых в отчетах и т.д. И, внезапно, добавляется это обычно по просьбе пользователей.
Платформа 1С для любого реквизита позволяет задать минимальное или максимальное значение. При записи можно выполнить так называемую «проверку заполнения», откуда совершенно элементарно можно
Автор говорит про контроль отрицательных остатков. Он во всех темах этот пример приводит, мол «у нас контроль отрицательных остатков на уровне платформы, а в 1С обязательно надо писать килобайты кода размазанного по сотне процедур».
Хотя
а) этот код можно было бы написать проще, но в типовых придерживаются определенных стандартов (пусть и не идеальных) и универсальности (т.е. есть ряд других проверок и условий выполнения данной проверки);
б) сравнивая 1С и lsfusion показывает огромные запросы для 1С и вызовы процедур на lsfusion. Тот факт, что эти запросы в 1С можно тоже «спрятать» в процедуре автора не смущает. При этом, когда задается вопрос вида «если не нужно контролировать остатки для склада N, как это сделать?», отвечает в стиле «всего-лишь вызвать процедуру isWarehouseN(Warehouse)» не описывая что происходит внутри этой процедуры.
и т.д.
Вы невнимательно читаете. У LsFusion нет недостатков (или их тщательно скрывают).
Я для себя из статей вынес следующие факты:
1) Если сравнивать 1С,SQL,SAP… и LSFusion по критериям «быстро, дешево, качественно» — LSFusion выигрывает по всем трем показателям.
2) 1С,SQL,SAP… примитивнее, но изучить LSFusion проще и быстрее.
3) 1С,SQL,SAP… это дорого, но разработчики на LSFusion зарабатывают больше и условия труда лучше.
4) Если чего-то в LsFusion нет, то только по одной из причин:
а) это неправильно;
б) это не нужно пользователям;
в) это не нужно программистам;
г) слишком просто и не интересно делать;
и т.д.
Табличный документ — это свой велосипед 1С, который они написали для того чтобы не привязываться к Excel. Так же как и файловая база у них появилась, когда использование SQL не планировалось.
Вы поступили проще — взяли готовые решения.
1) возможно, внутренние стандарты команды или 1С;
2) возможно, неотрефакторенная кодовая база от ERP (т.е. в ERP используется аналогичный запрос, но делаются дополнительные проверки);
3) возможно, legacy или говнокод;
4) еще масса причин, которую точно смогут сказать только авторы конкретной типовой.
Нет, исходя из ответов на другие мои комментарии не одной строкой. Само свойство quantityAvailable(st,sk) «описывается ранее».
Отлично. Мы вышли на финишную прямую.
Теперь повторю первоначальный вопрос: чем отличается «ранее объявленное свойство с соответствующей логикой», которое вы загоняете в CONSTRAINT от «объявленной ранее функции 1С ПроверитьОтрицательныеОстатки(Документ)», обращение к которой будет загнано в событие «ОбработкаПроведения»?
И там и там нужно заранее написать код. И там и там в нужном месте указать его вызов (да, я понимаю что у вас это не совсем «вызов метода», но с точки зрения трудозатрат программиста по нажиманию кнопок клавиатуры разница небольшая).
Удобство, убогость и т.п. это все-таки вкусовщина.
Желаю вам найти заинтересованных в вашей платформе клиентов и разработчиков.
*ирония* Получается, что когда 1С не дает редактировать данные в динамических списках, то это минус 1С. Когда у вас нет возможности (при необходимости!) использовать для интерактивной работы табличный документ — это все равно недостаток 1С?
В теме про подбор, вами (возможно, не лично, а кем-то из коллег), утверждалось, что подбор «как в excel» реализовать невозможно. Вариант с табличным документом приводился как один из возможных вариантов реализации, причем в номинации «ну если хотите, можно и так извратиться».
Не совсем понимаю вас. Есть возможность использовать табличный документ как простую неинтерактивную форму.
Есть возможность, навешивать на табличный документ события и работать с ним интерактивно.
В чем проблема-то у вас? Не нравится — не используйте. У меня пользователи просили реализовать им интерактивность в печатных формах. Не вижу в этом проблемы.
Еще раз. В 1с это делается 1(!) запросом строчек на 10. Пример на Мисте лично я вам приводил. Это если мы говорим о простой табличке SKU|Stock|Quantity и таком же простом документе, без дополнительной логики.
Нет, это вы меня не понимаете, как мне кажется.
Как ваша платформа понимает, что делать когда вы пишете «quantityReserved(st,sk)»?
Как много таких «предопределенных» действий определено и как будет выглядеть условие, если мы выходим за рамки простой захардкоженной проверки по 1-2 реквизитам, а условие накладывается в зависимости от данных в других таблицах?
Если колонка Reserved находится в другой таблице, как платформа понимает, что quantityReserved нужно считать именно по ней?
Примечательно, что в описанном случае заказчик себе исполнителя так и не нашел.
Ну… 1С вообще-то и не говорят что у них ORM (https://habr.com/ru/company/1c/blog/334050/)
Перечитайте мои комментарии в этой ветке. Участки текста, которые начинаются с большой буквы и заканчиваются знаком "?" — называются вопросами. Пожалуйста, ответьте на все или часть из них.
Для простоты добавлю ссылки на комментарии:
habr.com/ru/company/lsfusion/blog/468415/#comment_20698057
habr.com/ru/company/lsfusion/blog/468415/#comment_20698375
С точки зрения заказчика, ваша модульность от «поставим галку и теперь у вас есть скидки» не отличается ничем.
С точки зрения разработчика различие не более чем вопрос удобства.
Детский сад, штаны на лямках.
Что скрывается за «quantityAvailable(Stock st, Sku sk) > 0»?
Что такое «quantityAvailable»? Функция? Процедура? Оператор?
Для любого существующего во вселенной условия у вас уже есть встроенный оператор(процедура, функция) вида «Condition42()» или для сложной бизнес-логики придется писать свой оператор(процедуру, функцию)?
Расширения предназначались для настройки решения при внедрении, поэтому в коробке ими и не пользуются.
УТ — это составная часть ERP, по сути — ERP это УТ + модули. Кодовая база одна.
То что у вас «модульность, когда мы клиенту подключаем за денежку то что ему нужно и ничего лишнего», в 1С — механизм функциональных опций, когда все уже внутри коробки, но появляется в интерфейсе/используется в коде только после установки галочки в настройках.
Критерии отбора не подойдут?
Но эту процедуру мы не увидим. По крайней мере до сих пор, все эти процедуры скромно скрывались.
На предложение точно также прятать проверку остатков в 1С за процедуру «НетОтрицательныхОстатков(Документ)» реагируют тоже не слишком адекватно.
Ну т.е. идет сравнение ужа с ежом:
— простые встроенные в платформу проверки из lsfusion, которые быстро превращаются в цепочку вызовов неизвестных внешних процедур, как только проверка становится сложнее чем «проверить чтобы не ноль».
— сложные проверки с кучей условий, написанные в одном из типовых решений на 1С.
Да, если бы такие ограничения были встроенными в платформу, наверное было бы полезно. Но на практике, я могу вспомнить буквально пару-тройку случаев, когда такой простой проверки бы хватило для решений, которые я разрабатывал/поддерживал.
Вероятно, той же логики придерживались и разработчики платформы.
Можно считать это синдромом утенка или чем угодно, но если абстрагироваться от «круто было бы, если бы в платформе было все что только можно придумать», примерной аналогией будет карандаш с ластиком на конце. Да, удобно, но на практике все равно в комплект к нему нужно покупать нормальный.
1) Есть таблица БД с тремя колонками:
Stock и SKU — в терминах 1С это «измерения регистра»
? некоторая колонка «количество» — в терминах 1С это «ресурс регистра».
Для данного ресурса вы задаете красивое и простое ограничение «quantityAvailable(Stock st, Sku sk) > 0;», что подразумевает, что по любой комбинации Stock и SKU не должно быть отрицательного остатка (ну и в контексте описанной).
Ок. Отлично.
В 1С такая проверка также делается 1 простым запросом, который вам приводился на стороннем форуме.
Но после этого начинаются интересные вопросы:
1) Как будет выглядеть проверка, если нужно контролировать остатки только по части складов/SKU? В 1С — добавляем условие в запрос, у вас — добавляем внешние функции с проверками, которые будут порождать дополнительный запрос (ну ок, у вас волшебный оптимизатор, который автоматически склеивает все в один запрос к БД).
2) Как будет выглядеть это ограничение, если нужно проверять не только «остаток не стал нулевым», а «остаток с учетом резервов не стал нулевым»? Опять же — в 1С мы редактируем все тот же запрос. А у вас?
Любопытно увидеть для вариантов «резерв это еще одна колонка таблицы» и «резерв, это колонка в другой таблице БД»?
И т.д. и т.п.
А как же ваше непоколебимое заверение «пользователи хотят как в excel»?
Ну и пример можно — «задач для которых они не предназначены»?
И кстати, исходя из какой логики вы считаете что «не предназначены»?
Вот вы опять. Не «печатная форма», а «табличный документ». Который действительно может быть «печатной формой» («бланк договора», «бланк накладной», «этикетка») — и в таких случаях расшифровка не используется и никакой интерактивности (больше чем «разрешить внести изменения/изменить параметры печати») обычно не добавляется, и «выходная форма отчета», в которой в качестве «расшифровки» и «интерактивности» предполагается переходы к более детальным отчетам, открытия форм документов/справочников, упомянутых в отчетах и т.д. И, внезапно, добавляется это обычно по просьбе пользователей.
Т.к. я не настоящий сварщик — подскажите на примере, какую задачу (в терминах бизнеса или техническую/интерфейсную) вы хотите решить?
Автор говорит про контроль отрицательных остатков. Он во всех темах этот пример приводит, мол «у нас контроль отрицательных остатков на уровне платформы, а в 1С обязательно надо писать килобайты кода размазанного по сотне процедур».
Хотя
а) этот код можно было бы написать проще, но в типовых придерживаются определенных стандартов (пусть и не идеальных) и универсальности (т.е. есть ряд других проверок и условий выполнения данной проверки);
б) сравнивая 1С и lsfusion показывает огромные запросы для 1С и вызовы процедур на lsfusion. Тот факт, что эти запросы в 1С можно тоже «спрятать» в процедуре автора не смущает. При этом, когда задается вопрос вида «если не нужно контролировать остатки для склада N, как это сделать?», отвечает в стиле «всего-лишь вызвать процедуру isWarehouseN(Warehouse)» не описывая что происходит внутри этой процедуры.
и т.д.