Как стать автором
Обновить

Комментарии 362

Вроде очевидно почему не 1С нет?
1С — устаревшая пародия на ЯП, которая используется 3 странами в мире и которую стоило уничтожить еще при создании.
1С — устаревшая пародия на ЯП, которая используется 3 странами в мире и которую стоило уничтожить еще при создании.

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

Для бизнеса 1С — это безусловно преимущества. Для развития — это скорее ограничение. Вспомните Kodak, Nokia, Ford (не знаю кто тогда был лидер на рынке лошадей :) ), автогигантов да и вообще любую инновацию на рынке. Там все тоже самое было, понятно что и сети заправок, продаж, сервиса (ремонтов) везде первоначально были на несколько порядков лучше у текущих игроков. Но в этом и фокус, что если ты фундаментально отстаешь, вопрос времени когда ты проиграешь. Пусть не через год, и не через 10 или 20 лет, но проиграешь. Вон сейчас автогиганты пытаются гнаться за Tesla, понятно что они не умрут совсем, но догонят вряд ли. Собственно в том числе поэтому, сейчас Tesla оценивается как все остальные автопроизводители вместе взятые.
Тесла делает автомобили которые имеют все функции доступные другим автомобилям, плюс свою фишки. Человек при покупке теслы ничего не теряет, а только приобретает. Ваше решение пока такими свойствами не балует.
Предвосхищая ответ, что не все сразу делается, скажу что тесла смогла делать и продавать такие автомобили не благодаря тому что они такие хорошие и в неё поверили. В неё до сих пор просто вкладывают огромные деньги.
Вывод: Свергнуть монополиста можно только получив ресурсы соизмеримые с ним. Потихоньку это не сделать.
Человек при покупке теслы ничего не теряет, а только приобретает.

Человек владеющий теслой теряет возможность чинить её самостоятельно, даже в стороннем сервисе. Причем во многом из-за 'инновационной' политики самой теслы
Человек владеющий теслой теряет возможность чинить её самостоятельно, даже в стороннем сервисе.

Почему теряет? Теслы вполне себе ремонтируют, даже убитые в хлам:
www.youtube.com/watch?v=xJr5LRNq0fI
1) с полной потерей гарантии, без которой тесла мало кому нужный кусок железа
2) запчасти не продаются простым смертным

понятно что их ремонтируют из бу запчастей… но это такое себе… я на свой 20 летний рыдван без проблем могу купить практически любую новую деталь, причем 'родную', а не китайский клон, а на 5 летнюю теслу?
1) с полной потерей гарантии, без которой тесла мало кому нужный кусок железа

Хм. Вы точно так же потеряете гарантию, если поедете на неофициальную СТО на любом другом автомобиле. Я правда не совсем понимаю, чем потеря гарантии на Теслу отличается от потери гарантии на другие автомобили. Тесла без свежих прошивок хуже ездить станет, что ли?
2) запчасти не продаются простым смертным

Эм… с чего вы взяли? Я погуглил, вполне себе продаются, и новые, и б/у. Другой вопрос, что доступность так себе, но так и автомобиль нифига не распространённый. И «китайских клонов» пока что нет, что может быть даже недостатком, учитывая конские цены на оригиналы.
Эм… с чего вы взяли? Я погуглил, вполне себе продаются, и новые, и б/у

помоему писали что тесла не продает запчасти на авто на сторону, в принципе. это их модель обслуживания или ремонт по гарантии, или гуляй вася
и
чем потеря гарантии на Теслу отличается от потери гарантии на другие автомобили.

тем что вы не сможете её нигде кроме как в гаражном сервисе и с бу запчастями непойми кем чинить, я уж молчу о перепрошивке

сейчас я на своем 20-летнем крайслере могу приехат к официалам и сделать что угодно, заплатив правда адскую стоимость… но всёже. с теслой меня просто пошлют (насколько я понимаю их реалии с гарантией)

учитывая конские цены на оригиналы.

потому что их в черную продают
помоему писали что тесла не продает запчасти на авто на сторону, в принципе

Она продаёт их своим авторизованным партнёрам, а те вольны делать что угодно — использовать у себя, или продавать в розницу. В данном случае не идёт речь о том, что Тесла специально запрещает ремонтировать её автомобили третьим сторонам. У неё банально не хватает ресурсов обеспечить весь спрос :)
(насколько я понимаю их реалии с гарантией)

Что-то вы их как-то криво понимаете, не так как все остальные. По-гарантии сделают забесплатно. Нет гарантии — сделают за деньги.
Тесла делает автомобили которые имеют все функции доступные другим автомобилям, плюс свою фишки. Человек при покупке теслы ничего не теряет, а только приобретает. Ваше решение пока такими свойствами не балует.

Что значит ничего не теряет? Там тоже курица — яйцо было, когда например количество заправок измерялось десятками, против миллиона ДВС'ых, тоже самое касается сервисов / продаж и всего остального. Не говоря уже о том, что вы салон Тесла видели? Минимализм в чистом виде. Да и с надежностью по слухам там ерунда была (двери не закрывались). Но у них была главная вещь, фундаментально другая машина, с фундаментально другими характеристиками (например скорость разгона, шум, управляемость экологичность). Этого как правило достаточно, все остальное вопрос времени.
Предвосхищая ответ, что не все сразу делается, скажу что тесла смогла делать и продавать такие автомобили не благодаря тому что они такие хорошие и в неё поверили. В неё до сих пор просто вкладывают огромные деньги.

Вы причину со следствием путаете. Они смогли продавать такие автомобили, потому как сделали принципиально другой автомобиль, все остальное вторично (точнее следует из этого). Сделали бы они очередной ДВС никакие бы огромные деньги им не помогли. У Apple кстати тоже в свое время ресурсов было гораздо меньше чем у Nokia ЕМНИП. Да и Tesla начала относительно крупные инвестиции начала привлекать через семь лет и это в США (мекке инноваций и стартапов).

Ну и никто не спорит, что в какой то момент действительно практически всегда нужно привлекать ресурсы, но фаза Proof-of-concept и другие также очень важны, так как в это время ты максимально мобилен / пластичен и не «страдаешь» от кризиса роста.
Они смогли продавать такие автомобили, потому как сделали принципиально другой автомобиль

Вот это и есть заблуждение.
Чтобы продать автомобиль его нужно сделать. Если вы можете делать супер автомобили, но только 10 шт. в год, никакого лидерства вам не увидеть, даже если это супер автомобиль. Как пример печальный опыт DeLorean. Если бы денег в теслу не вложили, не было бы достаточного количество «зарядок», не было бы завода про производству нужного количества батарей. У теслы это все получилось только за счет очень активного «владельца». И деньги он вкладывал заработанные на совсем других вещах.
А Proof-of-concept вы уже показали, даже не только концепт, но и работающий бизнес уже есть.
Чтобы продать автомобиль его нужно сделать. Если вы можете делать супер автомобили, но только 10 шт. в год, никакого лидерства вам не увидеть, даже если это супер автомобиль. Как пример печальный опыт DeLorean. Если бы денег в теслу не вложили, не было бы достаточного количество «зарядок», не было бы завода про производству нужного количества батарей.

Немножко запутался. Понятно, что должна быть хотя бы теоретическая возможность производства продукта за ту стоимость, которая будет меньше чем преимущества, которые этот продукт дает. Если это есть, деньги найдутся рано или поздно. Зарядки и заводы это уже вторично.

Я не очень досконально изучал, как тесла удалось сделать автомобиль с пробегом в 400км на одной зарядке и с OPEX'ами в 120к (CAPEX'ы при таком громадном рынке и текущей стоимости денег не так важны) или около того. Но когда это стало осязаемым, дальше успех Тесла на мой взгляд был вопросом времени (но нет, я в них не вложился в свое время, так что это рассуждения в стиле «как моя жена после»).

Ну и работающий бизнес в определенной степени пока «внутренний» (в смысле indoor), сейчас главный вопрос как его (и можно ли) масштабировать «внешне» (outdoor) и это тоже своего рода Proof-of-Concept. Хотя конечно иметь при этом стабильный cash flow (даже с запасом), возможность для обкатки идей и т.п. безусловно приятный бонус, и позволяет не сильно переживать по поводу взлетит или не взлетит.
Вспомните Kodak, Nokia, Ford (не знаю кто тогда был лидер на рынке лошадей :)

Проблемы-то у них возникли не из-за груза накопленного опыта, а из-за грубых управленческих ошибок. Kodak сдохла, ненадолго пережив рынок фотоплёнок, а её прямой конкурент на том же рынке (кто-то помнит про Fujifilm?) с тех пор вырос раза в два, расширив ассортимент своих плёнок и найдя им новые применения. Nokia сдохла, а Самсунг только вырос.
Это как бы ни о чём конкретном не говорит, просто о том, что успех/поражение 1С лежит в другой плоскости, отнюдь не технологической. Покупать бизнес-приложения будут не ИТ-шники, а менеджеры. И смотреть они будут не на то, какая там внутри красивая объектная архитектура, и как эффективно работает внутренний ORM, а на то, насколько система соответствует текущим потребностями бизнеса «из коробки», насколько она понятна пользователям, какие риски внедрения и т.д.
Проблемы-то у них возникли не из-за груза накопленного опыта, а из-за грубых управленческих ошибок.

Это проблема всех корпораций. По факту все инновации идут за их пределами, так как корпорации слишком инертные. Да и им проще потом купить выскочек, чем самим делать (хотя понятно, что с гуглом, фейсбуком, теслой это например не прокатило, а скажем с инстаграммом или ютюбом прокатило).
И смотреть они будут не на то, какая там внутри красивая объектная архитектура, и как эффективно работает внутренний ORM, а на то, насколько система соответствует текущим потребностями бизнеса «из коробки», насколько она понятна пользователям, какие риски внедрения и т.д.

Так и в тесле люди не на двигатель (под капот) смотрят, но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться (хотя повторюсь мало кто из пользователей знает что под капотом).
но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться

Именно так. Но в случае бизнес-софта, его двигатель — не «программный движок», а функционал, известность, саппорт и доступность специалистов на рынке.
Это с чего вдруг? Функционал, известность, саппорт и доступность специалистов на рынке это кузов / салон авто, бренд, СТО, заправки и наличие механиков. А двигатель это как раз платформа.

То есть с теслой тоже самое было. Где вы ее заправлять будете, где чинить, вы же за город выедете и встанете, она сырая и все такое. Но как обычно инноваторы, early adopter'ы и пошло поехало. Но конечно они это на самой благодатной почве делали — в Калифорнии. В Омске им бы конечно посложнее было :)
Это с чего вдруг? Функционал, известность, саппорт и доступность специалистов на рынке это кузов / салон авто, бренд, СТО, заправки и наличие механиков. А двигатель это как раз платформа.

Это всё образно, конечно, но «двигатель» — то, что решает задачи. У автомобиля задача перевозить пассажиров/грузы. У бизнес-софта задача автоматизировать работу предприятий. Поэтому у автомобиля двигатель вот та штука, которая крутит колёса, у бизнес-софта двигатель — формочки и люди. Красивая внутренняя объектная модель, с которой сталкиваются только программисты, в мире автомобилей — это удобная компоновка подкапотного пространства для быстрого обслуживания. Да, автомеханики такое одобряют, но согласитесь, эта штука крайне слабо влияет на конкурентоспособность той или иной машины на рынке.
Так же и с софтом. Вы вполне успешно продадите такое:
«Наша система позволяет вести партионный учёт, считает себестоимость по FIFO, LIFO, по среднему, умеет вести SKU, интегрируется с… » и так далее.
Но вы никому, кроме небольшой горстки контор, в которых ИТ-директор напрямую лезет в коммерческие вопросы, не продадите: «Наша система имеет эффективный ORM, модульную архитектуру...»
То есть с теслой тоже самое было. Где вы ее заправлять будете, где чинить

С Теслой было не то же самое. Выходя на рынок, они вкинули кучу денег, решив вопросы «где заправлять» и «где чинить».
Так же и с софтом. Вы вполне успешно продадите такое:
«Наша система позволяет вести партионный учёт, считает себестоимость по FIFO, LIFO, по среднему, умеет вести SKU, интегрируется с… » и так далее.

Все зависит от того, что именно считать продуктом на этом рынке. Время «коробок» ушло на постсоветском рынке (и продолжает уходить). Сейчас ИТ-решения это не более чем полуфабрикат (или конструктор), основное в них не то, что есть там изначально (это всего лишь средство, один из факторов), а как это решение можно адаптировать под конкретного заказчика, внедрить в нем все его know how, сделать это бесшовно без рисков остановки бизнеса, а главное чтобы решение постоянно изменялось вместе с бизнесом, адаптируясь под новые идеи и пути развития бизнеса. На западе рынок давно пришел к этому («САП невозможно внедрить, его можно перестать внедрять»), и на постсовестком рынке последние лет 5 тоже (собствено у всех уже как-то что-то автоматизировано, а рынок экстенсивно не растет).

Соответственно в такой парадигме двигатель это именно платформа, то есть то насколько решение будет гибким, модульным и быстро и легко дорабатываться без накопления технического долга.
С Теслой было не то же самое. Выходя на рынок, они вкинули кучу денег, решив вопросы «где заправлять» и «где чинить».

Ну тут мне кажется перепутано причина со следствием, это было одновременно (сначала люди не знали где заправлять и чинить, но все равно покупали из-за инноваций), но постепенно появилось и то и другое. То есть не то что Тесла сначала настроило миллион заправок и обучила миллион техников, а только потом смогла продавать.
Время «коробок» ушло на постсоветском рынке (и продолжает уходить). Сейчас ИТ-решения это не более чем полуфабрикат (или конструктор), основное в них не то, что есть там изначально (это всего лишь средство, один из факторов),

Нет, как раз наоборот. Коробки потеснились (и будут дальше тесниться) онлайн-сервисами, а покупки бессрочных лицензий потеснились подписками. Но спрос на готовые решения только растёт, а спрос на кастомизацию наоборот, падает. Кастомизация — это потребность среднего и крупного бизнеса. 99% остальных заказчиков покрывают все свои потребности типовыми конфигурациями.
То есть не то что Тесла сначала настроило миллион заправок и обучила миллион техников

Они это начали делать одновременно. Ну т.е. первые пользователи Теслы уже имели доступ и к заправкам, и к обслуживанию. Впрочем, с точки зрения маркетинга, действительно первая небольшая волна пользователей-«визионеров» вполне могут потерпеть некоторые недостатки ради общей технологичности продукта. Но съем сливок с продаж происходит отнюдь не от этой волны.
Нет, как раз наоборот. Коробки потеснились (и будут дальше тесниться) онлайн-сервисами, а покупки бессрочных лицензий потеснились подписками. Но спрос на готовые решения только растёт, а спрос на кастомизацию наоборот, падает. Кастомизация — это потребность среднего и крупного бизнеса. 99% остальных заказчиков покрывают все свои потребности типовыми конфигурациями.

Теперь совсем запутался. То что ниша ИТ-решений малого (!) бизнеса постепенно замещается в основном онлайн-сервисами с этим никто не спорит. Но это не про ERP-платформы (и ни про 1С, Dynamics, ни про lsFusion) вообще. В онлайн сервисах не важны ни разработчики (так как нет кастомизации) ни франчи (так как продажи собственно идут онлайн через соотвествующие каналы). Тут важнее интуитивность полученного продукта (material design, документированность причем прямо внутри продукта, то есть всякие подсказки и т.п.), А ИТ-решение для среднего и крупного бизнеса сейчас это именно и только про кастомизацию.

Плюс важный момент- то что во всяком случае на постсоветском пространстве бизнес консолидируется (вертикально — федерально и / или регионально и горизонтально — когда сети например начинают и производством и оптовой и интернет торговлей заниматься) и соответственно все смещается в сторону среднего и крупного бизнеса. А значит спрос на готовые решения наоборот скорее падает, и это очень кстати хорошо видно, если посмотреть по ЕГРЮЛ обороты поставщиков именно коробочного софта в разных нишах.

К слову например если взять белорусский рынок, то скажем в ИТ для банковской сферы есть две компании обороты и количество сотрудников, которых превышает обороты и количество всех 1С франчайзеров вместе взятых. А эти компании только и занимаются что «кастомизацией».
Они это начали делать одновременно. Ну т.е. первые пользователи Теслы уже имели доступ и к заправкам, и к обслуживанию

Ага только по сравнению с ДВС там выбор был ультраограниченный.
Но съем сливок с продаж происходит отнюдь не от этой волны.

Ну это как бы очевидно, но не понятно какое отношение имеет к тому, о чем мы разговариваем.
В онлайн сервисах не важны ни разработчики (так как нет кастомизации) ни франчи (так как продажи собственно идут онлайн через соотвественно).

Ваши представления об онлайн сервисах устарели. Например, QuikBooks Online, Xero, 1С Fresh предлагаю возможность покупки дополнительных модулей и расширений от партнеров и заказную разработку этих модулей.
Ваши представления об онлайн сервисах устарели. Например, QuikBooks Online, Xero, 1С Fresh предлагаю возможность покупки дополнительных модулей и расширений от партнеров и заказную разработку этих модулей.

Я в курсе, но это уже тогда PaaS'ы (то есть по сути хостинг) и к классическим онлайн-сервисам имеют опосредованное отношение. И явно не то что автор того, на что я отвечал, имел ввиду.
Не согласен, это все же именно SaaS. Просто вопрос кастомизации SaaS решений многие ставят в приоритет и для той же 1С это одна из ключевых вещей. Поэтому технология расширений у них развивается очень быстро сейчас.
Подождите, важная часть SaaS это multi-tenancy, а если есть доработки (где с multi-tenancy очень много вопрос), то это чистый PaaS и скорее ближе к хостингу. Ну и собственно весь смысл в SaaS это отсутствии тесного контакта с клиентом (в том числе, например, за счет интуитивности интерфейсов и всяческих подсказок), а доработки это как раз классическая модель рынка бизнес-приложений.

И как бы 1С не развивали технологию расширений, но когда все сделано на SQL запросах, но при этом жестко императивно в строках без оптимизатора, когда нет полиморфизма, эти расширения по определению будут очень ограниченными (собственно такая проблема с модульностью яркий тому пример). Уж точно далеко для подходов используемых в lsFusion.
Ну, вот тут вам стоит изучить тему расширений в 1С. Ранее это была возможность катамизировать только код и формочки в multi-tenancy, сейчас же уже можно добавлять новые таблицы (справочники, документы, регистры), добавлять реквизиты и табличные части к существующим документам и справочникам. И все это платформа 1С автоматически обрабатывает на уровне СУБД (создает поля, таблицы и т.д.) в зависимости от подключенных расширений. А их может быть десятки.

Так же магазин расширений и аддонов для учетной SaaS системы это по сути must-have. Без этого конкурировать с Intuit и Xero нет шансов на том же рынке США.

А проблема с модульностью — это проблема на уровне методологии самих продуктов (БП, ЗУП, ERP), разработанных на платформе 1С. Компания пытается как-то двигаться в эту сторону, но слишком уж ресурсоемко это.
Я знаю что такое расширения и упоминал несколько раз в своих статьях.

Нужно понимать, что:
а) во-первых, расширения это частный случай модульности, когда у вас основное решение — один модуль, а расширение — еще один модуль зависящий от этого модуля. Поэтому в идеальной системе должна быть не только возможность добавлять свои модули, но и выключать существующие модули и / или выбирать между ними.
б) в императивных языках возможности расширений очень ограничены (тут я писал об этом). Критически важно уметь расширять запросы, иметь событийную архитектуру, полиморфизм и т.п. (вот тут я приводил примеры этой проблематики и человек мне так ничего и не ответил на них)

И если бы вы чуть больше погрузились в lsFusion, то поняли бы что в плане расширений / модульности lsFusion превосходит существующие технологии на порядок. Впрочем, естественно, никто не мешает вам «подождать на берегу», пока время подтвердит или опровергнет этот тезис :)
Я и не утверждаю, что главная цель расширений — это модульность. С их помощью, конечно, можно ее реализовать в какой-то мере, но я считаю, что главная цель расширений — это кастомизация продуктов без изменения исходного кода и в условиях multi-tenancy.
Теперь совсем запутался. То что ниша ИТ-решений малого (!) бизнеса постепенно замещается в основном онлайн-сервисами с этим никто не спорит

И среднего. Малый и средний бизнес — это как раз тот рынок, на котором снимает сливки 1С и большая часть продуктов Dynamics, и там же есть шансы проявить себя и вашему продукту, если вы предложите качественные готовые решения, либо создадите хорошую команду продажников, которая будет персонализированно продвигать ваш продукт среднему бизнесу. Крупному же бизнесу вам пока предложить банально нечего.
Что касается онлайна, то да, это тренд, тренд логичный и ожидаемый. Собственно, не зря Dynamics прочно ушёл в облако, и 1С движется туда же.
А средний бизнес это какой? Вот у нас сейчас основные клиенты это компании с 4-10к сотрудников и 200-500 млнов долларов в год оборотами. И основное что мы им продаем это как раз то что я писал в этом комментарии. То есть набор модулей из которых собирается решение, но что главное непрерывную реализацию всех хотелок с космической скоростью без накапливания технического долга (собственно у нас по сути на этом рынке в этом плане непонятно кто вообще конкуренты, потому как вести столько проектов одновременно в agile практически никто не может). Сейчас у нас процентов 70 крупного ритейла Беларуси и я думаю в течении ближайших 5-10 лет мы еще больше увеличим эту долю. И все это на мой взгляд именно благодаря платформе (всем этим 30 пунктам этой статьи). Это достаточно уникальное value который мало кто на рынке может предложить.

А рынок готовых решений судя по оборотам в ЕГРЮЛ соответствующих компаний (и общению с ними) наоборот сильно сужается, так как большинство как-то уже автоматизированы и на самом деле по опыту единственный вариант им что-то внедрить, это: внедрить as is с непрерывной интеграцией, после чего превратить в to be из смеси а) того что есть у тебя, б) то что всегда хотел заказчик, но у него не было, в) оставить то что есть, что себя уже зарекомендовало. Ну а дальше непрерывный цикл доработок по agile в рамках новых идей / изменений бизнеса и т.п.
Стоит упомянуть, что у 1С направление розницы развито не столь сильно. В это отрасли у 1С есть крупные внедрения, но вот продукта, который мог бы стать столь же конкурентно способным, как ERP, БР и ЗУП нет. Пока нет.

Так же вам на руку то, что вы начали с Белоруссии и уже имея клиентскую базу и продукт, обкатанный на ней, заходите на другие рынки.
Насколько я могу судить по работе с SMB и Eterprise, то бизнес в первую очередь ищет коробку. Желательно с возможностью быстрой и дешевой кастомизации. И только если нет коробок, удовлетворяющих потребностям бизнеса на приемлемом уровне, уже смотрят в сторону разработки кастомных решений либо силами вендоров, либо силами своего ИТ отдела. А для SMB кастомная разработка вообще недоступна в 99% случаев, у них просто нет столько денег.
А я и не говорю про «разработку кастомных решений». Я как раз говорю про ультрамодульные решения (где из модулей как из кубиков собирается каркас), а потом дорабатывается «as is», а потом непрерывно меняется под «to be» / новые направления / идеи. И в том насколько это возможно быстро и дешево делать, платформа играет важнейшую роль.

Ну и вы правильно заметили, что у малого и среднего бизнеса не то что нет потребности работать по такой модели, а именно что нет денег. Но это опять таки вопрос к платформе, насколько дешевой у вас получится доработка / крупноблочная разработка на ней.
Наличие готовых модулей — это и есть коробочное решение. Не важно, сколько этих модулей — один или тысяча. Дальше стоит вопрос стоимости внедрения, сопровождения и кастомизации.
Ну не знаю, в моем понимании коробочное решение это нажал кнопку установить, потыкал пару галочек и работай. А конструктор это набор некоторых блоков, из которых ты выбираешь часть ( часть которых опять-таки приходится изменять), часть блоков разрабатываешь (ЕМНИП даже САП утверждает, что у них пропорция где-то процентов 60-70 готовых с кастомизацией глубиной процентов 30 + 30-40 абсолютно новых). Но если доработка / добавление подвержены сильному техническому долгу (а это определяется платформой), то даже если у вас и 90 процентов готовых модулей, то в конечном итоге может быть дешевле вообще все с нуля сделать.
Коробочное решение — это именно готовый продукт в части бизнес логики. Модульность, как уже сказал, не особо влияет на это. Можно рассмотреть решение 1С (где с модульностью откровенно беда на уровне типовых решений), SAP (где модульность довольно развита, есть десятки модулей) и ваше (где сотни модулей, по вашим заявлениям). Все это коробки. Т.е. в идеале коробка не требует кастомизация, а только настройки модулей, загрузки НСИ, обучение и в путь.
Разработка своего будет дешевле коробки только в том случае, если подходящей коробки совсем уж нет. Либо собственное решение было ранее и требуется переход на коробку. Разработка любого серьезного решения для учета — это зачастую миллионы человеко-часов.
У вас почему-то две крайности получается. Либо коробка (причем без модульности у вас может быть много лишних данных и проверок, которые придется заполнять или которые просто будут убивать эргономичность), либо разработка с нуля. Хотя очевидно, что идеальное решение это крупноблочное строительство с доработкой отдельных блоков и разработкой недостающих. И модульность с возможностями рефакторинга / быстрой и простой разработки тут выходят на первый план.
Почему же две крайности? Мы обсуждаем, что есть коробочное решение. А кастомизация — это отдельный вопрос. В том или ином виде кастомизация идет, думаю, у 90% пользователей 1С, хотя бы на уровне внешнего отчета или обработки с Инфостарта.
Вы же понимаете, что бизнесу фиолетово коробочное решение или нет. Ему нужно решить свои проблемы (то есть получить ИТ-систему которая будет эффективно автоматизировать именно его процессы, как текущие так и будущие) быстро / дешево / с минимальными рисками. А будет это 100% коробочное решение, 60% коробочное 40% доработки, или 100% разработки, уже дело десятое. Если опять-таки устроит бизнес по срокам и стоимости (так например некоторые бизнесы готовы ждать, некоторые нет и т.п.)
Естественно. Любой бизнес оценивает систему с точки зрения стоимости внедрения, стоимости владения, рисков и возможности удовлетворить потребности бизнеса.

Кстати, именно по этой причине нередко даже очень большие компании используют полностью кастомную разработку именно на 1С, так как: это недорого (лицензии 1С стоят копейки, хоть и не бесплатно), учет автоматизируется очень быстро (может и не как в IsFusion, тут сравнить не могу) и, главное, рынок разработчиков 1С — это более 100 тысяч специалистов. Т.е. нет риска оказать без кадров и возможности сопровождать решение.
очень большие компании используют полностью кастомную разработку

Согласен, даже рынок полного custom made никто не отменял.
Т.е. нет риска оказать без кадров и возможности сопровождать решение.

Ну строго говоря для этого 100к разработчиков не надо. Одного десятка компаний сведет риск к минимальному, и на первое место выйдут уже первые два упомянутых вами фактора: качество платформы и TCO (затраты на покупку ОС, СУБД, платформу, оборудования и т.п.). Плюс важный момент — порог входа, если он очень низкий это даже может дать большие преимущества чем наличие большого количества специалистов (где их может быть много но все равно дефицит)
Одного десятка компаний точно не хватит. Если только вы планируете существовать на уровне пары сотен клиентов, из которых будет не более нескольких десятков действительно крупных.

Ну а про порог входа в 1С не шутит разве ленивый, именно поэтому и появилась возможность наращивать такую ораву разработчиков (что может быть несколько странным при довольном низком уровне развития самого языка).
Одного десятка компаний точно не хватит. Если только вы планируете существовать на уровне пары сотен клиентов, из которых будет не более нескольких десятков действительно крупных.

Да ладно. У того же SAP наверное около одного или нескольких десятков компаний в России, которые реально могут его поддерживать (а не просто значатся в списке партнеров), а если взять количество сотрудников в компаниях, которые работают на SAP, то это количество будет соизмеримо с компаниями работающими на 1С. Ну и у самого 1С, насколько я видел топ-5 франчайзеров покрывают наверное минимум 30 процентов рынка (в Беларуси так точно такая ситуация).
Ну а про порог входа в 1С не шутит разве ленивый

Ну так это в 7.7 было. И то она гораздо менее декларативна чем тот же lsFusion была. А в 8.3 с их управляемыми блокировками, РеквизитамиФормыВЗначение, &НаСервереБезКонтекста, сотней всяких избыточных абстракций и т.п., порог входа уже выше чем в .Net или условный Python (Odoo).

А возможность наращивать ораву появилось скорее из-за того что они Бух и ЗУП консолидировали. Ну и да простота и бесплатность (пиратство) 7.7. помогли.
Скажем, у SAP есть большая фишка — интернациональность. На РФ точно могут работать все компании СНГ (ваши земляки из EPAM тому пример), а так же из любой страны Европы. Судить о квалификации всех 40+ партнеров в РФ не могу.

По поводу количества автоматизированных рабочих мест, последнее, что я видел — это 80+% рабочих мест автоматизированы с помощью 1С.

По порогу вхождения надо смотреть больше не написание кода, а на решение типовых учетных задач. Та же 1С позволяет накидать простую рабочую систему практически без написания кода. Так же есть большой рынок обновлений и простых доработок, которые позволяют зайти в профессию с максимально легких задач (сам так начинал).

Думаю, главная причина в создании такого рынка — это инфраструктура франчайзи в купе с тем, что решения 1С стали стандартом де-факто для SMB в РФ.
Скажем, у SAP есть большая фишка — интернациональность. На РФ точно могут работать все компании СНГ (ваши земляки из EPAM тому пример), а так же из любой страны Европы. Судить о квалификации всех 40+ партнеров в РФ не могу.

Ну по такой логике и Odoo превосходит 1С по числу разработчиков, только в РФ это им не так сильно помогает (хотя и помогает). Собственно SAP хороший пример, что на самом деле даже 40 партнеров (из которых наверное половина бутафорских) более чем достаточно.
По поводу количества автоматизированных рабочих мест, последнее, что я видел — это 80+% рабочих мест автоматизированы с помощью 1С.

В таких случаях обычно эти рабочие места выполняют самые примитивные процессы, а вся сложность и кастомизация все равно в том же SAP. Но например если взять Топ-30 розничных сетей, там большинство все же SAP и местные какие-то самописки.
По порогу вхождения надо смотреть больше не написание кода, а на решение типовых учетных задач. Та же 1С позволяет накидать простую рабочую систему практически без написания кода. Так же есть большой рынок обновлений и простых доработок, которые позволяют зайти в профессию с максимально легких задач (сам так начинал).

Не совсем понял. Все типовые же сейчас на УФ, управляемых блокировках и т.п. Чтобы там что-то дорабатывать нужно понимать «кто все эти люди». Даже если речь о простеньких отчетах, тот же СКД по сложности уже превосходит любую Reporting system, так как туда намешали дикое количество функционала (той же аналитики, которая обычно идет в отдельных контурах).

То есть чтобы ковыряться в том же УТ или БУХ сейчас, нужно иметь очень неслабый уровень интеллекта и опыта, а это как бы основные (самые распространенные) продукты у 1С.
Думаю, главная причина в создании такого рынка — это инфраструктура франчайзи в купе с тем, что решения 1С стали стандартом де-факто для SMB в РФ.

Именно. Причина распространенности такая же как у SAP — «давно тут сидим» ©. Только опять-таки после какого-то уровня (на примере того же SAP) количество разработчиков уже не играет такой роли, а скорее наоборот позволяет дифференцировать себя на рынке (например, не знаю как сейчас, но раньше ABAP разработчики ценились выше 1С, потому как были более редкими).

Хотя как правильно кто-то отмечал ниже, наверное самый простой способ победить 1С, получить распостранение на мировых рынках и сыграть на «чемоданческих настроениях». Во всяком случае по опыту, сейчас так Odoo двигается на российском рынке.
Вы делаете слишком много домыслов. Лучше воздержаться от этого.

А у Odoo, в целом, все нормально в планетарном масштабе. Как понимаю, главная проблема — это отсутствие хорошего продукта для реалий РФ. Найдется партнер и инвестор, будет продукт. Но риски большие не пробиться на оооочень плотный рынок РФ (особенно корпоративный сектор).

По сложности. Если говорить о глобальных доработках, то, действительно, непросто разобраться в первую очередь в самих типовых. Но большая часть кастомизации — это отчетики, печатные формы, АРМ и прочие простые вещи. А СКД в большинстве случаев позволяет за 5 минут накидать очень функциональный отчет, не углубляясь в дебри всех возможностей СКД.

Ну, с распространением на мировых рынках можно только пожелать удачи :) Это будет не сильно проще СНГ и РФ.

На самом деле, у вас есть реально хороший и работающий продукт для розницы, т.е. вы заняли нишу, где у 1С нет сильной линейки продуктов, а тяжеловесы SAP, Oracle и Microsoft хоть и предлагают настоящие best-practices в своих решениях, но делают это за негуманный ценник.
Вы делаете слишком много домыслов. Лучше воздержаться от этого.

Рынок информационных систем он такой. Ни у кого нет общей картины, все сплошные обобщения личного опыта и гипотезы (просто потому что рынок очень большой и неоднородный)
Но большая часть кастомизации — это отчетики, печатные формы, АРМ и прочие простые вещи.

Давайте не смешивать. Отчетики и печатные формы в любой технологии достаточно несложная вещь. Я видел как люди к коробочным решениям на Oracle сбоку подключались и лепили там отчеты на CrystalReports. Порог входа при этом очень низкий в любой технологии. Плюс не забываем про навернутые BI, где пользователи много отчетов сами могут делать.

АРМам (а они ввод предполагают) как раз надо вот это вот все — управляемые формы, управляемые блокировки, как правильно условия для динамических списков писать и т.д. и т.п.

То есть про порог входа, это не личное мнение, а в том числе мнение многих 1С разработчиков, что та же УТ сейчас настолько сложной стало, что лезть туда уже мало кто хочет (а многие даже с 7.7 по этой причине не хотят уходить, так как она гораздо проще).
но именно двигатель дает тесле преимущества, с которыми ни один ДВС не может соревноваться

Тойота продаёт приус уже почти четверть века. Он не имеет проблемы с зарядками, а по экологичности может с теслой посоревноваться. Делали его конечно не для гонок (за 3 сек. до 100 он не разгоняется). Тойота при этом остаётся крупнейшим производителем автомобилей в мире. Тут кстати становится занятно что её капитализация до теслы не дотягивает. Вокруг теслы есть только хайп который специально раскрутили.
Я может чего-то путаю, но Приус это гибрид и по основном характеристикам не сравнится с Тесла (то есть это что-то среднее, ни рыбо ни мясо).

И собственно Тойота хороший пример, что имей ты хоть бесконечно денег, огромную долю на рынке, опыт, сервисы и все такое, если ты фундаментально отстаешь, в перспективе (пусть и глобальной) ты все равно проиграешь.

Но да многие все сваливают на хайп, не понимая, что путают причину со следствием.
по основном характеристикам не сравнится с Тесла

По каким? Задумайтесь что такого сверх нового в тесле? Какую инновацию они привнесли кроме «автопилота»? В чем главное преимущество электромобиля перед бензиновым?
Но да многие все сваливают на хайп, не понимая, что путают причину со следствием.

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

Проиграет в чем? Тойота стала хуже продаваться? Инвесторы от неё отвернулись?
По каким? Задумайтесь что такого сверх нового в тесле? Какую инновацию они привнесли кроме «автопилота»? В чем главное преимущество электромобиля перед бензиновым?

Ну это был по сути первый полноценный седан с возможностью проезжать 450км (а не 150), быстрой зарядки, нормальной динамики и безопасности, оригинальными (пусть и спорными) дизайнерскими решениями в духе минимализма и т.п. То есть именно законченный MVP.
Продолжатся так бесконечно не будет.

Я все тоже самое слышал и про эппл и про убер и особенно про фейсбук в свое время. И? Назовите мне хоть один реально лопнувший такой «пузырь» за последние 10 лет?
Проиграет в чем? Тойота стала хуже продаваться? Инвесторы от неё отвернулись?

Ну то что рост продаж у Теслы в разы превосходит Тойоту, и Тесла уже стоит в 2 раза дороже Тойоты и так с огромной вероятностью будет всегда.
Ну это был по сути первый полноценный седан с возможностью проезжать 450км (а не 150)

Любой седан с ДВС может это.
быстрой зарядки

Это за несколько часов по сравнению с заправкой за 5 мин?
оригинальными (пусть и спорными) дизайнерскими решениями в духе минимализма и т.п

Как будто другие компании не выпускали «спорные» с дизайнерской точки зрения машины.
особенно про фейсбук

Фейсбук делал совершенно новый продукт. Рынок соц. сетей с ним только появлялся. Кто-то думает что сейчас может появится другой фейсбук?
Ну то что рост продаж у Теслы в разы превосходит Тойоту

Вырасти с 10 000 до 20 000 это не тоже самое что с 1 000 000 до 2 00 000.
так с огромной вероятностью будет всегда/blockquote>
С чего вдруг? Какие экономические показатели это объясняют? Инвесторы в итоге захотят превратить свой доход в деньги. Они это либо сделают за счет получения дивидендов, либо продажи акций. Но кто захочет дальше покупать если не увидит перспективы?
Текущие успехи теслы только за счет успехов Маска с ракетами. Все думают что раз он совершил революцию в запусках, то сможет и тут. Но в отличии от ракет, в автомобилях такой революции не свершилось.

Любой седан с ДВС может это.

Я думал мы с другими электромобилями сравниваем. Ок тогда все это плюс разгон за 4 секунды, без передач и вообще трущихся частей (то есть гораздо меньше обслуживания надо), с очень крутой безопасностью (нельзя перевернуть, двигатель в салон не уедет), бесшумность, экологичность, возможность заправлять ночью (пусть и очень долго).
Как будто другие компании не выпускали «спорные» с дизайнерской точки зрения машины.

Кстати именно такие нет. Но опять-таки я тут все вместе сравнивал.
Фейсбук делал совершенно новый продукт. Рынок соц. сетей с ним только появлялся. Кто-то думает что сейчас может появится другой фейсбук?

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

То есть переход с бензина на электричество (и скажем зарядка автомобилей дома по ночам) — это не революция? Ну ок.
переход с бензина на электричество

Ради чего? чем электрический лучше бензинового? Это как раз то, с чего я начал сравнение с приусом. Экологичность производства и эксплуатации теслы очень сомнительная вещь. Пока её произведут столько «вредного» выкинут. Пока электричество для неё выработают тоже столько СО в атмосферу отправят. Просто не рядом с владельцем теслы. Приус в этом смысле тоже чистый. ДВС работает на самых эффективных режимах, если надо, может проехать на выключенном двигателе. Прототип Ё-мобиля (который в Белоруссии тестировали) тоже достаточно чистый.
Я в тесле из революцинного вижу только автопилот.
Похоже что мы уже слишком далеко ушли от первоначальной темы. Кажется пора закруглятся.
Ради чего? чем электрический лучше бензинового?

Много чем. В стоимости эксплуатации и сложности обслуживания, в надёжности, в возможности зарядить дома и на работе, в объеме багажника, в безопасности, в динамике, в комфорте езды — всё это достигается простой заменой ДВС на электромотор.

Начнем с того, что это не ЯП, а фреймворк. Ну и далее по тексту ложь про 3 страны, плюс агрессия. У вас там все хорошо?

1с — это новое слово в Rapid Application Development, систем подобного класса в мире нет.
А то бы Украина уже давно на них соскочила, но увы.
То что появился достойный конкурент 1С — меня очень радует. Да ещё и открытая платформа. Тут специалисты скажут свое весомое мнение при выборе платформы.

Однако у 1С главное преимущество (как я понимаю) в нескольких аспектах:
1. Законодательство. Они очень быстро вносят необходимые правки и максимально поддерживают текущие требования закона. Есть даже миф что 1С сами проталкивают изменения в законодательстве чтоб чаще менять формы, тем самым заставляя бизнес платить за обновления.
2. Франчайзинг (партнеры 1С). Судя по всему их десятки тысяч. Если бизнесу нужно что-то сделать в 1С, они идут в фирму и получают услугу в виде выездного специалиста. Если бизнес только собирается покупать 1С, то всегда есть специалист готовый приехать и обучить персонал.
3. Сотни готовых решений под любой бизнес. Пиццерия, магазин автозапчастей, швейная мастерская. Под всё есть решения.

lsFusion будет очень сложно конкурировать на этом поле.
Хотя решение в виде MyCompany даёт мелкому и среднему бизнесу качественный и бесплатный инструмент. Которое всё равно нужно обновлять под изменения законодательства. Как с этим обстоят дела?

Поддерживаю оратора с добавлениями.
п.2. решаем (теоретически) бизнес-моделью. 1С сделало красиво — фиксированные цены для end-user и отваливать половину франчайзи. Отлично работает.
п.3. тоже решаем по правилу Парето — 90% (образно) клиентов удовлетворены тремя стандартными конфигурациями (причем актуальность важна только для двух — БП и ЗУП).
А вот п.1. — это всё. Первое, что говорит бухгалтер на предложение заменить 1С — "я на всё согласная, но один вопрос — как сдавать отчетность?".
Вот об это разбито просто вагон проектов.
То есть пока этот бешеный принтер в налоговой работает альтернатива 1С под большим вопросом.

Так бухгалтеру никто и не предлагает заменять 1С. Пусть сидит там считает свои налоги. Во всем мире бухгалтера работают в отдельном специализированном софте (скажем в США это какой нибудь Intuit) и никто не переживает по этому поводу.
Пусть сидит там считает свои налоги

Вы себе представляете что это такое? Думаете он так вот сел, и решил посчитать налоги и все? Думаете ему ничего из «управленческих» данных ничего для этого не нужно? Ему это как вводить, вручную?
Нет, естественно интеграция с бухсистемами должна быть (выгрузка или уже агрегированных проводок или первичных данных). И в MyCompany и даже в самих 1С решениях она есть (как и везде в мире). Но этого как правило в управленческих решениях более чем достаточно.
Так любая интеграция это большая головная боль. Особенно когда интегрируемые системы развиваются независимо в своих интересах. Кто будет заниматься актуализацией? В результате, какой заказчик захочет жить в условиях постоянной опасности что в один прекрасный день, что-то может не работать?
Вы надеюсь в курсе, что даже у 1С в подавляющем большинстве случаев УНФ/УТ/ERP ставится отдельно от БУХ и ЗУП? Как собственно и то, что во всем остальном мире бухгалтерию чаще всего ведут отдельно?
Ну так там развитием занимается один поставщик, он и занимается актуализацией.
А какая разница один или не один поставщик? Понятно что любой поставщик управленческих решений (коих тысячи) занимается актуализацией интеграции с бухгалтерией. Более того уверен в 1С этим занимается отдельный отдел / люди (то есть по сути «другой» поставщик).
Разница в том, что этот «один» поставщик точно имеет актуальную информацию по планам развития и оперативно актуализирует это самую «интеграцию». Когда поставщика 2, один обязательно «прошляпит» изменения у другого.
Что значит прошляпит? Ничто не мешает второму поставщику просто подстраиваться под изменения первого (первый выпустил новую версию, второй в течении короткого периода времени обновил интеграции). Например в России есть куча провайдеров всяких центральных сервисов аля Честный знак, ЕГАИС, Меркурий, и все как то актуализируют интеграцию с ними. То есть проблема явно надумана. Вон SAP даже как-то живет, а это весьма большая и как следствие не очень поворотливая махина.
Ничто не мешает второму поставщику просто подстраиваться под изменения первого (первый выпустил новую версию, второй в течении короткого периода времени обновил интеграции).

почему это второй должен подстраиваться под первого, а не наоборот? А потом мы имеем "эффективный" код и "ломучие" интеграции...

Что значит почему? Потому как если в данной области распространен этот поставщик, то под него и подстраиваться. Если основной движок интернет магазинов условная Joomla, то все будут подстраиваться под него, если у есть всего один сервис Честный знак все будут подстраиваться под него, если 90% касс это Сервис-плюс и Кристаллсервис, все будут подстраиваться под них, если 90 процентов бухгалтерий 1С: Бухгалтерия, все будут подстраиваться под нее и так далее. Так всегда и везде работает.
в подавляющем большинстве случаев УНФ/УТ/ERP ставится отдельно от БУХ и ЗУП

Тут причина в том что УНФ/УТ/ERP нельзя так часто обновлять как хотелось бы налоговой/1C
Как собственно и то, что во всем остальном мире бухгалтерию чаще всего ведут отдельно?

тут плохо применим опыт других стран. у нас бывает что целый поход нужен чтобы правильно сделать выгрузку в бухгалтерскую программу, чтобы подсчитать налог на прибыль… а если у вас еще валюта фигрурует с авансами… то всё, вы там повеситесь просто…
как вы будете выгружать «просто проводки» по расчетам с клиентом в долларах когда у вас куча авансов и отгрузок? пересчет валютных разниц мозг даже одинесником со стажем и главбухом мозг выносит… когда оказывается что точка зрения налоговой, разработчиков бухгалтерских программ и законов не совпадают друг с другом… точне их все трактуют по разному… типа 10% от общей цифры операций считать или от каждой и результат суммировать?
если логику таких расчетов оставлять в бухгалтерской программе то туда придется тащить кучу бизнеслогике которой там не место, если всё считать в управленческой системе — то опять всё скатится к поддержке законодательства а-ля 1С но своими силами
Что-то я не понял. У вас первый ответ, противоречит второму. В том плане, что если управленческое и бухгалтерское решение ставят и обновляют отдельно, как тогда решается проблема, которую вы сформулировали в конце.

Это чисто вопрос ценника, и предметной области, но а любом случае бух всегда присутствует для сдачи налоговых отчётов.

не надо задним числом работать. тогда головняка не будет.
а для заднего числа писать регламент
С чего вы взяли что весь «головняк» из-за работы задним числом?
UPD:
«С чего взяли» догадываюсь. Но опыт показывает, что это не самая большая проблема.
из практики.
озвучьте другие проблемы интеграций. большие.
Из практики, больше всего проблеме из-за структурных различий в интегрируемых системах. Например неоднозначные связи (один и тот же объект источник может загружаться в разные приемники), архитектурные различия в обработке данных (одна система поддерживает работу «задним числом, а другая нет). Таких проблемы бывают конечно всегда, но при интеграции систем сделанных на одной платформе, или еще лучше одним поставщиком, этих проблему будет существенно меньше.

Ну вообще в США налоги считают в AccountingSuite которая к слову тоже 1С ;)

В США хоть об этом знают?
полтора человека-мигранты из РФ чтоли?
Нет там расчета налогов. Даже налог с продаж там считается через онлайн сервис. Вообще, налоговый учет в США отделен от бухгалтерского учета намного больше, чем у нас.
1. Законодательство. Они очень быстро вносят необходимые правки и максимально поддерживают текущие требования закона. Есть даже миф что 1С сами проталкивают изменения в законодательстве чтоб чаще менять формы, тем самым заставляя бизнес платить за обновления.

Вообще это обычно касается фискального и регламентированного учета. То есть по сути БУХ и ЗУП, которые даже с «управленческими» 1С решениями (то есть с УНФ, УТ, ERP и т.п.) в большинстве случаев ставятся отдельно. Более того 1С пытаясь двигать свой ERP на мировой рынок так и говорит, в качестве бухгалтерии используйте местный софт.
2. Франчайзинг (партнеры 1С). Судя по всему их десятки тысяч. Если бизнесу нужно что-то сделать в 1С, они идут в фирму и получают услугу в виде выездного специалиста.

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

Тут соглашусь, но это вопрос времени. Тем более, что часто кастомизация превышает «специализацию», то есть «рыбы» в виде MyCompany или lsFusion ERP может быть достаточно для того чтобы на выходе получить даже более качественное решение, чем уже «готовое».
Которое всё равно нужно обновлять под изменения законодательства. Как с этим обстоят дела?

Это если честно не ко мне вопрос (я к MyCompany прямого отношения не имею). Но я полагаю, что в нем естественно поддерживаются / будут поддерживаться изменения законодательства, тем более что если исключить БУХ и ЗУП, этих изменений не так много как принято считать.
Это, кстати, самый полный ответ почему бизнес выбирает 1С и тот же битрикс с шопскриптом а не благословенный Lavarel. Потому что бизнес не хочет пол года искать программиста что бы решить мелкую проблему.
Бизнес вообще не хочет завязываться на конкретного программиста.
У меня есть история как крупнейший интернет-магазин в отрасли был на самописном движке какой-то украинской студии. Тут наступил всем известный майдан.
И все. Интернет-магазин обслуживать не получилось. В России, ВНЕЗАПНО, фрилансеры не брались совсем (не охота разбираться в чужом говнокоде, ага). На ставку никто не хотел идти по той же причине. Пришлось срочно переделывать магаз на Битрикс. С потерей SEO и прочих плюшек.
Слава богу урок был не мой, но у меня теперь простое решение.
Продается интернет-магазин?
Самописный или редкий/не поддерживающийся движок? Нафиг сразу. Даже бесплатно.
Потому что бизнес не хочет пол года искать программиста что бы решить мелкую проблему

Работаете на пол ставки в битрикс? Я вам могу сказать совершенно обратную ситуацию, адекватного разраба, который может работать с битрикс днем с огнем не найдешь. Большинство битриксоидов это вчерашние вордпрессеры изучившие тему по паре 5 минутных роликов с ютуба. Система сертификации битрикса, грош цена ей. Так что с утверждением что битриксоида проще все найти я в корне не согласен. Его найти ровно так же сложно как и любого другого под нормальную платформу. Единственный случай когда я могу оправдать применение битрикса, так это при разработке интернет магазина, потому что такого уровня e-commerce решения увы больше не найти, а самому такой аналог можно довольно долго реализовывать
Работаете на пол ставки в битрикс?

Нее) Это точно не ко мне)
Я вам могу сказать совершенно обратную ситуацию, адекватного разраба, который может работать с битрикс днем с огнем не найдешь. Большинство битриксоидов это вчерашние вордпрессеры изучившие тему по паре 5 минутных роликов с ютуба. Система сертификации битрикса, грош цена ей. Так что с утверждением что битриксоида проще все найти я в корне не согласен. Его найти ровно так же сложно как и любого другого под нормальную платформу.

Я столкнулся с другим. Проще реализовать самому, чем написать ТЗ и проверить потом за фрилансером. Времени уходит БОЛЬШЕ, плюс еще денег заплатить надо.
Но вот на крупные задачи — вопрос исключительно $$. Берешь топ-студию, пишешь ТЗ, договор и вперед.
Единственный случай когда я могу оправдать применение битрикса, так это при разработке интернет магазина, потому что такого уровня e-commerce решения увы больше не найти, а самому такой аналог можно довольно долго реализовывать

Исключительно интернет-магазин. Для других целей есть абсолютно другие решения.
Для интернет-магазина на просторах РФ сейчас по факту есть Битрикс и Шоп скрипт. Где-то дальше OpenCart и Magento.
Собственно, ИМХО, больше особо выбирать не из чего.
Ну если вы хотите более-менее ГОТОВЫЙ продукт. А не я тебя поставил и пошел делать 150 модулей, потому что оплаты нет, доставки нет, веса товаров нет, чеков нет и тд.
У меня есть сайт не магазин на битриксе, который я сопровождаю. Делала какая-то контора, причем далеко не последняя. Меня убило то, что там нет вменяемого ЧПУ из коробки, часть данных лежит в базе, часть лежит прям в файлах. До этого занимался сайтами на MODx. Битрикс хорош там, где надо что-то быстро наговнокодить. Да, оно будет работать, но это будет треш. А вот MODx это и есть доведенный до ума битрикс.
а че не на вордпрессе или джумла? Есть ведь и другие стандарты помимо битрикса
а че не на вордпрессе или джумла? Есть ведь и другие стандарты помимо битрикса

Ну если вы хотите МАГАЗИН — делайте на движке магазина.
Если совсем КРАТКО.
WP/Joomla как интернет-магазин это прям ФЕЕРИЧНЫЙ геморрой. Прям на старте.
WP — это всякие Woocoomerce.
Ну вот по-минимуму для начала.
Каталог в виде дерева. С одним товаром, лежащим в нескольких категориях.
Оплата эквайринг 3-4 банков хотя бы. Мы же энтерпрайз… А там один сбер и тот с трудом.
Расчет доставки Почтой России. Про версия 79$
Нормальный модуль СДЭК — 79$ (тот который в битриксе бесплатный. Ага… И в шоп скрипте он тоже бесплатный)
Всякие «непопулярные» службы доставки типа CSE, DPD, Boxberry — геморроя еще больше.
Онлайн-касса с пробитием чеков онлайн? Вы о чем вообще
В целом если вам нужен МАЛЕНЬКИЙ магазин на 10 товаров и вы не планируете расти дальше woo это ваш выбор.
Джумлу вообще рассматривать не стоит. Потому что проще уже любой фреймворк взять и написать с нуля, чем поднимать на корявой джумле интернет-магазин. Все равно все придется писать.
У меня у знакомого VirtueMart и он уже 3й год (не сказать что активно ищет но все же) не может подключить интернет-эквайринг.
Потому что надо найти банк, который предоставит свою кассу, которая лупит чеки на онлайн оплаты в обход сайта, и у которого есть модуль для VirtueMart…
Потому что с 1с оно связаться не может. А кассу к сайту не подключить — модулей нет…
При этом битриксовая касса умеет шлепать чеки и на наличку и на онлайн оплаты и за указанные законом 5 минут. Из коробки. Вообще без допилов.
не могу судить, из веб-магазинов сталкивался только с Woocomece (на своем сайте) и Битрикс (у 1с-клиентов)
но сдается мне, что вы выпячиваете достоинства Битрикса. Таки тут конкуренция порядочная (в сфере веб-сайтов).
Нет. Я просто говорю, что битрикс из коробки для Российских реалий В РАЗЫ лучше Woo.
И сделать с нуля интернет-магазин на bitrix или Shopscript с нормальным набором российских реалий типа расчета почты, сдэк, эквайрингов и прочего в разы проще.
Если вы хотите просто продать 3 товара и обрабатывать каждый заказ манагером вручную — вам вообще все равно какой движок использовать. Но когда заказов 10-20 в день все становится сильно сложнее.
А кроме Woo вы ничего не знаете?
CS-Cart, Open Cart, NetCat.

для примера:

По данным BuiltWith, на OpenCart в России работают 54 500 интернет-магазинов. Это достаточно много. Для сравнения — на Битриксе работает 172 000 сайтов, и только часть из них — интернет-магазины.
Чуть выше мой коммент.
Исключительно интернет-магазин. Для других целей есть абсолютно другие решения.
Для интернет-магазина на просторах РФ сейчас по факту есть Битрикс и Шоп скрипт. Где-то дальше OpenCart и Magento.

Opencart приятно удивил у конкурента когда он на него переходил. И ценником перехода и функционалом. Но ему ни интеграция с 1с не нужна, ни чеки. Что там по ним — я хз.
CS Cart и Netcat…
Последний раз когда я их смотрел было грустно. Очень грустно.
Посмотрел. CS Cart стоит дороже битрикса. В РАЗЫ.
marketplace.cs-cart.com/prolongatiovipservice.html
Ценники на простейшие модули в 50-100$… ну я прям не знаю. За 100-150$ в битриксе топовые модули с оооочень широким функционалом.
marketplace.cs-cart.com/affiliate-add-on-for-cs-cart.html
стандартный функционал.
marketplace.cs-cart.com/mailchimp-advanced.html
Бесплатный на битриксе.
marketplace.cs-cart.com/pre-order.html
штатный функционал.
marketplace.cs-cart.com/make-an-offer.html
штатный функционал в большинстве шаблонов.
marketplace.cs-cart.com/product-bundles.html
штатный функционал
Если я сейчас свой магаз с РЕАЛЬНО РАБОТАЮЩИМ функицоналом накидаю модулями CS cart он встанет тысячи в 3 баксов по минимуму. Причем у меня из платных только шаблон и пару мелких модулей до 1000р.
В России, ВНЕЗАПНО, фрилансеры не брались совсем (не охота разбираться в чужом говнокоде, ага). На ставку никто не хотел идти по той же причине.

единственное объяснение, которое у меня есть — жадность работодателя


И все. Интернет-магазин обслуживать не получилось.

вот прямо студия взяла и отказалась? или возникли проблемы с оплатой? те же биткоины вроде не вчера придумали

единственное объяснение, которое у меня есть — жадность работодателя

Не, ну за 1000000 в месяц и я сяду разбираться. Но за 1000000 в месяц, внезапно, оно не нужно от слова совсем.
вот прямо студия взяла и отказалась? или возникли проблемы с оплатой? те же биткоины вроде не вчера придумали

Все проще — платежи в/на Украину и их получение из РФ стало, внезапно очень проблематичным. А за наличку и всякие Яндекс деньги, внезапно, далеко не все конторы готовы работать. Белый и пушистый бизнес хочет белые и пушистые документы.
это преимущество 1с для бизнеса.
а есть еще преимущество для программистов — скорость разработки.
есть небольшие базы данных, которые на 1с автоматизируются с нуля за пару дней.
вот тут Фузина очень даже конкурент.
Тяжело ли в вашем продукте реализовать расчет/перерасчет зарплаты со всеми нюансами?
Есть ли механизм настройки ограничения прав доступа к отдельным записям?
Предусмотрен ли электронный документооборот и использование ЭЦП, сейчас или в планах?
Тяжело ли в вашем продукте реализовать расчет/перерасчет зарплаты со всеми нюансами?
Если речь идет о платформе, то точно не тяжелее, чем на 1С. Просто задача расчета зарплаты очень гибкая, и часто лучше делать специализированное решение под конкретный процесс расчета премий и штрафов, чем универсальный, как в ЗУП.
Есть ли механизм настройки ограничения прав доступа к отдельным записям?
На уровне платформы — нет. Обычно это делается на уровне конкретной «конфигурации». В той же MyCompany сделана такое ограничение на основе привязки пользователей к местам хранения (и дальнейшей фильтрации заказов, поступлений и т.д.)
Предусмотрен ли электронный документооборот и использование ЭЦП, сейчас или в планах?
Это опять же делается на уровне конфигурации. Например, в MyCompany реализована интеграция с CryptoPro путем простого подключения библиотеки JCP. Вот исходный код непосредственно подключения.
На уровне платформы — нет.

Я бы сказал — пока нет. В принципе можно добавить возможность для класса задавать фильтры что-то типа:
CLASS X {
FILTERS hasAccess(X, currentUser());
}
Который будет добавлять блок FILTERS во все формы, где есть объекты этого класса. Это несложно реализуется, а мощный оптимизатор запросов разрулит все проблемы с производительностью.

Но тут проблема, что такой cross-cutting будет давать много нежелательных эффектов, так как формы универсальный механизм использующийся в том числе и для экспортов и для отчетов. Соответственно можно отфильтровать лишние данные и это может быть критично. Впрочем, надо будет посмотреть как это в других платформах решается (тот же RLS в 1C).
и дальнейшей фильтрации заказов, поступлений и т.д.

И эту фильтрацию нужно делать в каждом месте? А если её нужно подкорректировать?
Да, в каждом месте одной строкой добавляется конструкция вида (где hasAccess свойство, построенное ранее по какому угодно фильтру):
FILTERS hasAccess(object, currentUser())

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

Попуститесь пацаны. Вам еще год назад писали, почему ваша поделка отстой. Обстоятельно писали, с примерами и обоснованием.

Насколько я помню год назад писали:
Странное ощущение — что именно то не выдерживает критики? Я опытный разработчик 1С и могу подтвердить что всё что тут перечисленно большая боль для меня — и самое больное что 1С совсем не собирается что то сделать полезное, всё что она может это изолироваться и поддерживать клуб любителей такой изоляции.

И это были самые заплюсованные комментарии.

Все остальное было лишено конструктива, и сводилось к тому, что «автор не разобрался». На вопрос в чем именно не разобрался, ответов не было.

В любом случае не нравится не читайте. У нас свое видение, у вас свое.
И это были самые заплюсованные комментарии.

Ну Вы же понимаете: это хабр; комментарии, где критикуется 1С, плюсуются безоговорочно независимо от смысла.
Есть такое. Но конструктива, где претензии были или необоснованными или незначительными, все равно было очень мало. Хотя с другой стороны человеку ни разу ни использовавшему ни явную типизацию, ни наследования с полиморфизмом, ни нормальные IDE действительно тяжело понять зачем это все нужно.
Есть такое. Но конструктива, где претензии были или необоснованными или незначительными, все равно было очень мало.

Опять-таки, это хабр. Здесь в критике 1С всегда мало конструктива. Больше на эмоциях как-то основываются.
Хотя с другой стороны человеку ни разу ни использовавшему ни явную типизацию, ни наследования с полиморфизмом, ни нормальные IDE действительно тяжело понять зачем это все нужно.

Какое-то, не связанное с предыдущим предложением, утверждение. Но ок. А с чего Вы взяли, что человек с этим никогда не сталкивался и никогда это не использовал?
Опять-таки, это хабр. Здесь в критике 1С всегда мало конструктива. Больше на эмоциях как-то основываются.

Стоп, я не про критику 1С, а про критику критики 1С. Как раз в этих двух статьях я пытался подходить максимально предметно, без абстрактных вещий, аппелируя к общепринятым понятиям / механизмам и т.п. И в общем то поэтому хотелось увидеть более предметную реакцию, а не эмоции как вы говорите. И причины на мой взгляд почему именно так происходит на мой взгляд именно в:
Хотя с другой стороны человеку ни разу ни использовавшему ни явную типизацию, ни наследования с полиморфизмом, ни нормальные IDE действительно тяжело понять зачем это все нужно.

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

Тогда я значит Вас не так понял, Вы как-то незаметно с критики 1С на критику критики 1С перескочили.
Или у вас есть другое объяснение, почему часто 1С разработчики отвечают строго эмоционально, а не могут предметно сформулировать свои мысли / возражения?

Часто — это ведь тоже эмоциональное суждение, нес па? По моему опыту, конструктивность диалога зависит строго от вменяемости оппонента, а не от строгой типизации, вменяемого IDE(а где он кстати вменяемый) и уж тем более не от наследования с полиморфизмом.
Тогда почему у статей EvilBeaver не много-много минусов?
Потому что они были в таком стиле:
Я опытный разработчик 1С и могу подтвердить что всё что тут перечисленно большая боль для меня — и самое больное что 1С совсем не собирается что то сделать полезное, всё что она может это изолироваться и поддерживать клуб любителей такой изоляции.


Такое здесь любят :)

Это где это у меня были статьи в таком стиле??

где писали?
где примеры и обоснования?
я на мисте спрашивал, где это все?
тишина. Как говорится, Фузину не смотрел, но осуждаю.

ну и как она в итоге?

Диаграмма в заголовке прикольная.
Вопрос только: а Вас не напрягает, что на ней все альтернативные решения сгруппированы по кластерам (то есть каждый кластер заточен под какой-то срез задач и все решения из этого кластера имеют схожие параметры), а IsFusion расположен в какой-то отдельной области, где больше ничего нет? Может он решает свой срез задачи таким способом, который на рынке не популярен? (не в смысле «не в тренде», а в смысле «не самый экономически эффективный»)
Ну, строго говоря, все альтернативные решения используются именно для разработки информационных систем. Скажем решения для банков и крупного ритейла часто пишут на PL/SQL, T-SQL (в смысле всю бизнес-логику) + каком-нибудь чисто UI-фреймворке (скажем дельфи или веб), но бывает, что эти же решения пишут и на 1С и на Java Spring. А например ERP решения для производства чаще всего пишут на ERP-фреймворках, но бывают когда также как для банков на PL/SQL или на .Net. Высоконагруженные корпоративные бизнес-приложения (где простая бизнес-логика, но огромная нагрузка) чаще пишут на каких-нибудь Java EE, но бывает и из PL/SQL (или даже ERP платформ) выжимают все что можно.

Собственно эта диаграмма в заголовке показывает, что потенциально технология аля lsFusion может заменить PL/SQL, ERP-фреймворки и RAD-средства. До ORM она не дотянет в плане гибкости и масштабируемости (ультра высоконагруженности).
1С это для бухгалтера. Если нужна какая-то другая автоматизация нужно отдельное специализированное решение адаптированное под предметную область. По аналогии как Додо делало для своих пиццерий.
Это решение либо покупается, либо пилится внутри компании усилиями 3-4 разработчиков на каком-то мейнстримовом языке вроде java/c#/go
1С это для бухгалтера. Если нужна какая-то другая автоматизация нужно отдельное специализированное решение адаптированное под предметную область.

Это у вас опыт внедрения и того и того говорит?
на каком-то мейнстримовом языке вроде java/c#/go

Решение делается ведь не на языке. Язык не важен. Важен фреймворк на котором сделано решение. Писать под каждое решение свой фреёмворк точно не в интересах конечного заказчика.
Есть опыт over 10 лет по .NET. Есть опыт взаимодействия с 1С, SAP и ресторанными системами iiko и rKeeper. Есть вещи которые банально не делаются в рамках бухгалтерских программ, бухгалтеры страдают но ничего сами не попросят. Есть вещи которые связаны с передачей данных между системами и их верификаций.
Чем сильнее конфигурация 1С отличается от стандартной — тем больше с ней возни и проблем.

В интересах конечного заказчика чтобы решение работало просто эффективно
каком-то мейнстримовом языке вроде java/c#/go
Либо на том же lsFusion. Например, пять из восьми крупнейших розничных сетей Беларуси работают на решении, разработанной на lsFusion. А по оборотам они все входили бы в ТОП-20 розничных сетей РФ. То есть это не ларьки.
Уважаемый, вы назовите «ТОП-20» розничных сетей РФ, ну чисто, чтобы ваши слова не выглядели пустым надуванием щёк.
На счёт Белоруссии — там всё возможно. Если бы мне бы сказали что 1С не подходит и нужно что-то еще, то IsFusion безусловно мной бы рассматривался как один из вариантов.

Почему такая любоффь к 1С? Да нет никакой любви — банально 99% людей, которых вы принимаете на работу с ней умеют работать.
А Вы с точки зрения кого говорите? С точки зрения бизнеса или интегратора? Если мы говорим про обычных пользователей (не бухгалтеров), то с 1С работали далеко даже не 30%, а значительно меньше. И большинству из них все равно на чем работать — на чем скажут, на том и будут.
не, 1с не для бухгалтера. 1с для бухгалтера было только во времена 6.0 и то, на 6.0 писали уже упр.учет на счетах.
Весна… Фузиновцы обострились.
lsFusion и 1С это платформы для создания прикладных решений. Следовательно важны не они сами по себе, а прикладные решения который создаются с их использованием. Главная цель для них это «нести» пользу конечному пользователю. Потребители по большому счёту не важно на чем он работает. По этому показателю 1С является лидером. Конкуренция с 1С начнется только тогда, когда конечному потребителю будут предоставлены все те же удобства что он имеет сейчас.
Для бухгалтера важно соответствие законодательству. С 1С он может за 10 мин зарегистрироваться на 1cfresh.com и доступ облачному решению которое всегда актуально, и ему не нужно думать ни о чем, он просто пользуется, даже устанавливать ничего не надо.
Для руководителя предприятия при внедрении ERP важно найти максимально подходящее под его требования решение и иметь возможность за минимальные деньги и сроки реализовать все необходимые «доработки».
Для них слова «мы нагружаем СУБД и не сервер приложения» не важны.
А где посмотреть, что новенького появилось в lsFusion 4.1 по сравнению с 3.1?

Можно попробовать здесь

Круто ребята вбрасывают. В статье «Почему не 1С» в качестве примеров берут реальные, так сказать промышленные куски кода, которые будучи вырванными из контекста всегда будут выглядеть неадекватно и монструозно. А в этой статье в качестве решения проблем предлагается метод «Ну допустим, есть товар А с ценой Б и количеством В. Тогда сумму мы вычислим вот таким простым способом в одну строчку. Сравните с 1С.». Это называется по-другому, а именно «нечестный полемический прием».

Ну и, честно говоря, неглубокое понимание архитектуры 1С автором тоже не делает ему чести и доверия. Взять хотя бы ошибочную версию автора, что виртуальные таблицы 1С — всего лишь представления (view). Что заставило автора думать, что в их параметрах можно использовать только константы и не позволило решить такую простую задачу, как вывод в динамическом списке товаров их остатки по складам.

UPD 14:42
Изучаю вашу демку ERP. Ну что сказать… А где блокировка бизнес-объектов от изменения одновременно несколькими пользователями? Или так задумано —
Не совсем понял. В этой статье «прямые» сравнения это:

  • про отсутствие оптимизатора запросов — там пример один в один
  • с ограничениями — там есть небольшая разница(хотя даже в первой статье специально была выбрана именно проверка очень простого ограничения вроде текущего остатка), но, собственно основной смысл, что в lsFusion задаешь как вычисляется показатель, а дальше просто вешаешь ограничение на него одной строкой. А в 1С нужно танцы бубном из триггеров и временных таблиц городить
  • с разделением сервера и клиента — но там как раз у 1С и будет жутко монструозно из-за всех этих НаСервере и НаКлиенте

Взять хотя бы ошибочную версию автора, что виртуальные таблицы 1С — всего лишь представления (view).

Что значит «всего лишь представления»? Да, в SQL и в других технологиях представления это и есть виртуальные таблицы (просто по определению). Другое дело, что в 1С виртуальные таблицы еще несколько мелких вещей «сверху» умеют делать (например автоматически группировать, когда не все измерения указаны и т.п.), но это просто небольшой синтаксический сахар сверху.
Вы сначала полноценную конфу уровня УТ хотя бы запилите, а потом на ее примере демонстрируйте успехи…

Ну например вот (исходники, если хотите сравнить код), система на которой работают 70% крупных розничных сетей Беларуси (там конечно нет части функционала УТ, зато есть огромное количество функционала которого нет в УТ)
Изучаю вашу демку ERP. Ну что сказать… А где блокировка бизнес-объектов от изменения одновременно несколькими пользователями? Или так задумано —

А вы статью читали (в том числе заключение)? В этом магия lsFusion, она не читает (а потом и записывает) объект целиком. То есть вполне допускает одновременное редактирование данных (аля google docs или условно git), при этом полностью гарантирует целостность данных, и то что одно изменение пользователя не затрет изменение другого пользователя (если один поменял одни данные, а второй другие).
А если оба пользователя вносят «идентичные» данные в разные строки?
Идея «работать без блокировок» — всегда опасна. Потому что ударить может в любой момент и неизвестно где. И как потом искать неправильные данные.
Сработает ограничение (если оно есть) на наличие двух «идентичных» данных. То есть целостность данных вы не нарушите никак.

Ну и в любом случае «большая сила влечёт за собой большую ответственность» (с) Человек-Паук.
То есть предлагаете это переложить на плечи пользователей? Интересное решение…
Как раз такую проблему и решает блокировка объекта. И ситуаций, когда она может пригодиться — не счесть. А если все моменты сбрасывать на пользователей — то зачем вообще программа, когда есть Excel?
Нет, почему. Пользователи как раз меняют, каждый свои данные спокойно и не мешая друг другу (как в google docs). То есть один изменил цену в одной строке, другой в другой. Вас же не смущает, что в google docs несколько человек могут править один документ? И ситуаций, где это может пригодиться — не счесть.
Один изменил цену в накладной — отлично.
А другой через секунду поменял цену на другую, а третий зашел и махнул пересчет цен в процентах на все позиции. Что вышло в итоге надо, внезапно, проверять руками.
Очень забавная, скажу я вам, работа. Когда накладная на 3000 позиций и на 10 лямов денег…
Так тот кто махнет пересчет цен в процентах на все позиции, он по определению не будет смотреть ни на первого ни второго. Даже если он увидит предупреждение он все равно махнет. И изменения первого и второго потеряются в любом случае.

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

Собственно смотрите, во всем мире в битвах — версионник (оптимистичные блокировки) / блокировочник (пессимистичные), расшаренный excel / google docs, блокировочные VCS / Git победили оптимистичные блокировки (с иногда опциональными пессимистичными).
Но это какая то надуманная проблема. И если она для какой-то информации реально существует на практике, ну так включите для этой информации пессимистичные блокировки, делов-то. А для остальных 95 процентов случаев, когда описанная вами ситуация очень маловероятна / некритична оставьте параллельный ввод (что значительно ускорит работу пользователей).

Вы работаете с деньгами и со строгой отчетностью. Я не могу представить себе ситуацию, когда два человека в одном ДЕНЕЖНОМ документе что-то одновременно правят и данный результат считается НОРМАЛЬНЫМ.
Один получил информацию от руководства о предоставлении скидки на все позиции, второй применил право персональной скидки на 1 позицию и вот она надуманная проблема.
В вашей «надуманной проблеме» я, фиксируя состояние документа, фиксирую и чужие правки, которые я в глаза мог не видеть потому что они тупо на 2-3 странице документа. И подписывая его я фактически подписываю и несу ответственность за чужие правки.
Хочешь испортить жизнь манагеру? Дождись пока он зайдет в документ перед подписью и поставь на 3 странице цены по 1 рублю. Он не увидит, подпишет и будет все ок. Отвечать будет он)
Хочешь испортить жизнь манагеру? Дождись пока он зайдет в документ перед подписью и поставь на 3 странице цены по 1 рублю. Он не увидит, подпишет и будет все ок. Отвечать будет он)

Хоть убей не понял этого примера. Так человек же и будет смотреть что подписывает и увидит там цены по рублю и не подпишет.
Вы кривите. Сравнение с ГуглДокс некорректно.
В ГуглДокс все видят, кто правит в данный момент какую ячейку. Постоянно. То есть есть информация о том, что кто-то работает в этом документе. В вашей же программе такого не будет.
Так что жду от вас «корректного» примера, где с данными работают без блокировок, как в вашей. Иначе — это «ноу хау» в стиле «пусть сами разгребают».
З.Ы. — безопасность всегда стоит выше эфемерного удобства. Если в системе могут работать десятки человек — без блокировок велик риск, что в один момент они подправят один-другой документ некорректно. И когда это определят и как будут исправлять — песня из матов, сначала в сторону пользователей, ну а как разберутся в чем причина — в вашу сторону.
В вашей же программе такого не будет.

Это с чего вдруг? Это как раз технически очень не сложная задача. Закидываешь все изменения в сессиях в какую-нибудь таблицу, и подсвечиваешь эти изменения в интерактивном представлении форм. В принципе можно реализовать, но по опыту проблема реально сильно надуманна.

Кстати в том же ГуглДокс ЕМНИП подсветка того кто правит в данный момент ячейку появилась далеко не в первой версии и работали как-то.

Так что жду от вас «корректного» примера, где с данными работают без блокировок, как в вашей. Иначе — это «ноу хау» в стиле «пусть сами разгребают».

Собственно смотрите, во всем мире в битвах — версионник (оптимистичные блокировки) / блокировочник (пессимистичные), расшаренный excel / google docs, блокировочные VCS / Git победили оптимистичные блокировки (с иногда опциональными пессимистичными).

То что в бизнес-приложениях (не считая SQL, а на верхнем уровне) мало где использовались оптимистичные блокировки, так это потому что реализация их в бизнес-приложениях (как впрочем и везде) ГОРАЗДО сложнее. Но в lsFusion это удалось сделать.

З.Ы. — безопасность всегда стоит выше эфемерного удобства. Если в системе могут работать десятки человек — без блокировок велик риск, что в один момент они подправят один-другой документ некорректно. И когда это определят и как будут исправлять — песня из матов, сначала в сторону пользователей, ну а как разберутся в чем причина — в вашу сторону.

Что значит подправят некорректно? Вот один исправил цену, а второй через пару минут пересчитал все (он то не просматривает старые значения вообще, он записывает новые). Это некорректно?

lsFusion гарантирует, что ни одна проверка целостности не будет нарушена. Если для вас что-то критично, просто добавьте соответствующую проверку, она вам все равно будет нужна даже при однопользовательском вводе. Ну или в крайнем случае включите для КОНКРЕТНОГО процесса пессимистичную блокировку. Зачем мучать пользователей на ВСЕХ процессах?
Дадада, всё у вас удалось. Ни у кого в мире не удавалось, но у вас конечно всё есть.
«В принципе можно реализовать, но по опыту проблема реально сильно надуманна» — а по моему опыту проблема очень даже не надуманная. Хотя, возможно, это результат ошибки выжившего. Вы создаете ПО в текущих реалиях, когда многие пользователи уже «научились» на других программах, что так делать нельзя, поэтому пользовательская грамотность слегка другая. 1С создавалась в других реалиях, когда компьютеры еще были в диковинку, поэтому пользователи намного чаще делали ошибки. Но это не значит, что сейчас надо надеяться на грамотность пользователя. Это ошибка в подходе, которая может больно аукнуться.
«Зачем мучать пользователей на всех процессах» — как вы будете определять, в какой ситуации нужна пессимистичная блокировка, а где оптимистичная?
И вообще, мне надоело, что вы вместо ответов на конкретный вопрос начинаете сами себе задавать вопросы и на них отвечать.
Дадада, всё у вас удалось. Ни у кого в мире не удавалось, но у вас конечно всё есть.

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

А как вы определяете где нужна в 1С управляемая блокировка, а где нет? Даю подсказку, аналитически или по факту инцидента.

И вы упорно игнорируете факт про победу версионников над блокировочниками (скажем у Oracle и Postgres так и не появился блокировочный режим, а у MS SQL появился версионный и его даже 1С частично начал использовать), победу git над блокировочными системами контроля версий, победу google docs над расшаренным excel / word и т.п. Может прокомментируете? Или там типа ошибок на миллион нет (хотя везде есть / могут быть).
А если оба дописали примечание в документ, то прав останется последний. При этом первый будет уверен, что записал свои изменения. Вот ровно только что провел такой эксперимент в вашей демо-ERP, и все сработало по данному сценарию. В общем, спорное решение. Могу я предположить, что если кому-то по бизнес-логике понадобится реализовать механизм монопольного редактирования объектов, то он будет выглядеть монструозным и костылеватым, т.к. вы не поддерживаете этого на уровне платформы?
Ну вы вырожденный случай выбрали. Скажем если примечания будут строками, то несколько строк отлично добавятся в документ параллельно.

И нет, пессимистичные блокировки тоже делаются очень легко. Тут есть пример (описание системных действий lock, unlock встроенных в платформу)

То есть можно сделать просто:

lock(o);
IF lockResult() THEN
     TRY
          edit(o);
     FINALLY
          unlock(o);
ELSE
     MESSAGE 'Используется другим пользователем'

Но на практике это используется очень редко. Когда пользователи привыкли к Google Docs, использовать расшаренный по сети Excel-файл уже никто не хочет.
Независимое редактирование «строк документа» можно и в 1С сделать, если что.
Но это, согласитесь, костыль на регистрах. Все-таки парадигма 1С — изменение данных цельными блоками. Другое дело, что автор опять делит мир на олдскул и ньюскул, безапеляционно утверждая, что принцип работы 1С — это расшаренный по сети Excel по сравнению с Google Docs.
Что значит безапеляционно утверждая? А вы сами этой аналогии не видите?
Нет, не вижу. Лично я вижу разные парадигмы обработки данных и поддержания их целостности у 1С и у вашего решения. В обоих случаях есть плюсы, а есть минусы. Если очень надо, то действительно, как сказал gennayo, очень просто сделать табличную часть документа не в виде табличной части, а в виде подчиненного документа или справочника. И даже достаточно конфигураций, которые именно так и работают. В основном WMS-ки, где, к примеру, сразу множество кладовщиков одну приемку делают. И это тоже очень просто, как дважды два — просто «ПКМ->Добавить» в конфигураторе. А еще есть множество ситуаций, когда над заказом работает пара менеджеров, и в текстовом поле Комментарий пишут важные замечания по заказу. В вашей демо-ERP вот прямо сейчас можно открыть два сеанса, в каждом сеансе по окну одного документа «Заказ (закупка)», допустим, номер 9080111, изменить и сохранить в них одно и то же поле, к примеру «Примечание», и сохранится только последняя правка, а правка первого сохранившего молча пойдет лесом. Базовая парадигма 1С — не допустить такого сценария ни при каких раскладах. Ваша — да и пофиг, если надо — сами лок делайте при открытии. И при этом вы утверждаете, что это прогрессивно.
Лично я вижу разные парадигмы обработки данных и поддержания их целостности у 1С и у вашего решения


Нет, в 1С есть только пессимистичные блокировки, а в lsFusion и те и другие. Плюсы и минусы обоих подходов хорошо известны (и встречаются во многих областях), но фактически везде побеждают оптимистичные.

Если очень надо, то действительно, как сказал gennayo, очень просто сделать табличную часть документа не в виде табличной части, а в виде подчиненного документа или справочника. И даже достаточно конфигураций, которые именно так и работают. В основном WMS-ки, где, к примеру, сразу множество кладовщиков одну приемку делают.

Не совсем понял, а как потому эти подчиненные документы «объединяются» в один? А как это потом все редактируется? Это же треш и угар будет. Причем в lsFusion это все из коробки делается.

А еще есть множество ситуаций, когда над заказом работает пара менеджеров, и в текстовом поле Комментарий пишут важные замечания по заказу

Это как раз один вырожденный случай, со строкой, в которую дописывают в конец. Хотя в том же lsFusion, для этого просто делают записи комментариев (так удобнее и с точки логирования например этих изменений), и тогда вводите параллельно без проблем.
Базовая парадигма 1С — не допустить такого сценария ни при каких раскладах. Ваша — да и пофиг, если надо — сами лок делайте при открытии. И при этом вы утверждаете, что это прогрессивно.

Конечно прогрессивно:
Собственно смотрите, во всем мире в битвах — версионник (оптимистичные блокировки) / блокировочник (пессимистичные), расшаренный excel / google docs, блокировочные VCS / Git победили оптимистичные блокировки (с иногда опциональными пессимистичными).
Почему на регистрах? Вполне себе и на документах варианты есть. Но да, с точки зрения «фузиновцев» — это костыль.
А с точки зрения 1Сцев нет? Ну тогда и наследование можно на if'ах делать. Тоже не костыль. И вообще по такой логике C от Java ничем не отличается.
Ну да, ну да. Использование возможностей платформы — это костыль. Кто бы сомневался…
Боюсь, это может создать много неявных проблем.
Вот, например, в 1с в документах бывают зависимые реквизиты (например, контрагент и договор контрагента. Договор контрагентам принадлежат контрагенту). Пользовательские формы в 1с построены так, что показывают только договоры контрагента выбранного контрагента, но в 1с то при этом сам документ блокируется. А тут мы получим, что один пользователь изменил контрагент, другой изменил договор — и мы легко потеряли зависимость между ними, потеряв целостность данных.
Нет, при проведении сработает ограничение, что выбран договор не того контрагента, после того как пользователь нажмет ОК, данные обновятся и он увидит другого контрагента и сможет выбрать другой договор.

Но опять-таки правило Парето и разница между оптимистичными и пессимистичными блокировками. В 99 процентов удобнее работать параллельно, а в 1 проценте случаев главное чтобы поддерживалась целостность и с большего указывалось в чем проблема ее нарушения. Это дает куда лучший баланс, чем просто все запретить, и слушать крики на весь офис «Маша дай отредактировать документ, когда ты его уже отпустишь».
Да, именно так — надо кричать «Маша дай отредактировать документ, когда ты его уже отпустишь». Ибо не заметив, что кто-то параллельно внес правку в открытый тобой документ, можно и счет клиенту не на ту сумму отправить… А потом ищи концы, какая там Маша что в этот момент делала. Так некоторые учетные системы можно превратить в полную помойку.
А если Маша зашла в документ просто «посмотреть»? Или я хочу зайти посмотреть? А в 95% случаев документ просматривают, а не правят.
Если Маша зашла в документ просто «посмотреть», то он не заблокируется. Блокировка начнет работать только при начале редактирования — то есть при изменении свойства Модифицированность открытого объекта.
а это тоже опасно, она открыла документ, смотрит 50000рублей, уходит, наливает чай, возвращается, тыкает печать и идет к принтеру… а там накладная на 50000рублей но на совсем другого контрагента с похожим названием… пока она глядела не меняя документ, его уже ктото изменил (вот не надо только 'обязана сверять'… я уже наслушался такого, когда поток документов по несколько тысяч на человека в сутки, у Маши крыша поедет)

Дак не запишется документ — напишет про несоответствие версий. Честь Маши не пострадала!

не запишется кем? при печати документа — его не надо записывать? или предлагаете блокировать запись документа если его ктото открыл?

че толку открывать документ если он в любой момент может стать неконсистентным… маша нафигачила туда 100500 строк… а оно ему… ой чёто изменилось, перезагрузить?
Печать документа производится не по данным формы, а по данным объекта из БД.
конечно, по этому на печать попадет не то что человек видит перед собой в документе
Да, но уйдет фактическое его состояние.

Так же нет проблем реализовать контроль на изменение версии объекта перед печатью с предложением перечитать его или автоматическим перечитываением.

маша нафигачила туда 100500 строк… а оно ему… ой чёто изменилось, перезагрузить


А вот это уже исключается автоматическим накладыванием объектной блокировки на уровне сервера приложений при начале редактирования объекта.
Не будет так работать. В большинстве случаев если документ посчитается системой «измененным» — то он потребует перезаписи. А если изменен другим пользователем — то он потребует, чтобы его «перечитали». И тогда Маша увидит измененные данные и печатать будет правильный документ. Рассматривать ситуацию, что сначала Маша распечатала, а потом кто-то этот документ изменил не имеет смысла, потому что это уже не техническая ошибка, а организационная и решается на уровне пользователей, а не программы.
Рассматривать ситуацию, что сначала Маша распечатала, а потом кто-то этот документ изменил не имеет смысла, потому что это уже не техническая ошибка, а организационная и решается на уровне пользователей, а не программы.

Ну класс. Причем этот случай ГОРАЗДО более вероятен чем одновременное изменение и печать документа. Собственно в 95% случаев «некорректных» данных будет именно такой сценарий. Так за что тогда борьба если проблема «организационная и решается на уровне пользователей, а не программы».
То есть вы решили проигнорировать половину сообщения, описывающую реальную проблему, а ответить в своём стиле…
Мы говорили про необходимость блокировок, когда пользователи «открыли» данные или одновременно их используют. И в примере про «печать» как раз рассматривали ситуацию, когда пользователь сидит в документе, он был изменен, после чего она его печатает (она его не меняла). В этот момент и срабатывает блокировка.
Обратную ситуацию, когда она сначала распечатала, потом кто-то поменял я просто упомянул, но эта ситуация — не та, ради которой устраивается блокировка. Ту ситуацию ни в одной системе нельзя обойти, только организационно.
Вы же вместо ответа на основное сообщение переводите фокус на «ситуацию-исключение», как будто это и было основным вопросом. И отвечаете в своём стиле «это никому не нужно».
Ту ситуацию ни в одной системе нельзя обойти, только организационно.

Так, а смысл бороться с ситуацией, если вы в 95 процентов случае все равно получите проблему. Это как если бы вероятность смерти от рака уменьшалась бы на 5 процентов, если вы не будете пить, ложится спать в 9, не есть ничего вредного и т.п. Знаете что большинство пользователей сказало бы? Ну его нафиг. То есть опять-таки баланс рисков / возможностей.

Потому что мы рассматривали ДРУГУЮ ситуацию…
Все, меня уже не хватает. Либо вы тролли, либо действительно не понимаете о чем речь. Но в любом из этих случаев ваш фузион так и закончится на хабре

Ну так вы сами игнорируете все неудобные вопросы и просто по сути подгоняете решение под ответ. Но согласен, спор уже стал малоконструктивным, так как вы явно начали на личности переходить. Давайте каждый останется при своем, а сторонний читатель сам разберется. Мир, дружба, жвачка.
Грубо говоря — вы перекладываете с больной головы на здоровую.
Ну я могу точно также сказать. В любом случае «Убивайте всех, Господь распознает своих» ©. В смысле сторонний читатель сам разберется, какая позиция ему ближе.
И опять манипуляция.
Сторонний читатель, незнакомый с вопросом, часто ведётся на красивые картинки. В вашей статье — они красивые, поэтому он на них поведется. Очередной маркетинговый фокус. Никаких «сторонний читатель разберется».
Вы мне кажется явно недооцениваете сторонних читателей, особенно читателей хабра. Уверен здесь многие знают и про типизацию и про полиформизм и про модульность и про IDE (в смысле что это и для чего это надо).
Рассматривать ситуацию, что сначала Маша распечатала, а потом кто-то этот документ изменил не имеет смысла, потому что это уже не техническая ошибка, а организационная и решается на уровне пользователей, а не программы.

Вообще-то техническая. Если нельзя вносить изменения в документ после его распечатывания, то печать документа должна отправлять документ в readonly статус «Распечатан».
Да, именно так — надо кричать «Маша дай отредактировать документ, когда ты его уже отпустишь». Ибо не заметив, что кто-то параллельно внес правку в открытый тобой документ, можно и счет клиенту не на ту сумму отправить…

Это вроде проверяется проверкой версии документа при нажатии кнопки (сохранения / печати /отправки). Если данные успели поменяться другим человеком, пишем об этом и пытаемся смержить. Если удалось — смержить (поменялись другие поля) пишем, что за время редактирования обновлены такие-то поля, пожалуйста проверьте. Если были изменены теже поля, что и у пользователя, соответственно их не мержим и либо извиняемся, что перезатерли их серверными, либо спрашиваем у пользователя что выбрать. В особо тяжёлых случаях при частых можно хранить историю изменений.
Проблема может в связанных записях / справочниках. Но это интерфейсная проблема (как показать изменения, не перегружая интерфейс) и аналитическая (какие данные считать связанными, а какие нет). Алгоритмически там ничего сложного нет. Могут быть сложности с одновременным редактирование больших текстов, но и для них есть решения по разбиению редактирования на атомарные команды и объединение их в батч.
На мой взгляд, блокировать документ или какую-то запись намного геморройнее, потому что нельзя точно выяснить, продолжает человек с документом работать, но например в другой программе, или уже ушёл на обед.
Вообще мне кажется это как раз правильно решается, как вы написали, переводом в статус Распечатан, ограничением, что распечатанные документы изменять нельзя (а точнее нельзя изменять данные которые важны для этого документа, скажем сумму документа), и распечатыванием документа уже после того как документ успешно переведен в статус Распечатан (то есть транзакция успешно завершилась). Собственно lsFusion это все может отлично автоматически разрулить в оптимистическом режиме без блокировки. То есть если транзакция изменяющего будет первой, то документ переведется в распечатанный и распечатается с этим изменением, если нет — распечатается без этого изменения, а изменяющему будет сказано «извините, распечатанный документ нельзя изменять». И хоть десять человек могут изменять этот документ одновременно, пока его не распечатают.

Я только не понял из вашего объяснения, а в 1С, кто вот это все мерженье, проверки какие именно поля изменились и т.п. предполагается должен делать? Платформа или разработчик руками?
Я только не понял из вашего объяснения, а в 1С, кто вот это все мерженье, проверки какие именно поля изменились и т.п. предполагается должен делать?

Понятия не имею, я с 1С только как с переводчиком игр в начале нулевых дело имел. В абстрактной платформе наверное должны быть какие-то уже готовые стратегии обработки, и плюс к этому возможность написания своих. Я писал по опыту того, что сам разрабатывал.
Вы некорректно интерпретируете правило Парето.
Точнее так — вы используете его как универсальный ответ на вопрос «почему не реализовано это» — «а вот по правилу Парето это нужно будет в 1% случаев». К сожалению, при разработке ПО:
1) использовать его нельзя. ПО должно учитывать все возможные ситуации и минимизировать риски пользовательской ошибки при работе. Всегда нужна «защита от дурака»
2) когда люди, руководствуясь правилом Парето в виде «80% пользователей пользуются только 20% функционала» решают реализовать 20% функционала, чтобы получить 80% продаж, они натыкаются на проблему, что каждый пользователь использует РАЗНЫЕ 20% функционала.
1) использовать его нельзя. ПО должно учитывать все возможные ситуации и минимизировать риски пользовательской ошибки при работе. Всегда нужна «защита от дурака»

Что значит нельзя? Смысл в том, что если у тебя в 5 процентов случаев могут быть проблемы их и нужно решать в 5 процентов случаев. В гололед надо ездить не больше 50 и очень аккуратно, а в нормальную погоду с разрешенной скоростью и гораздо с меньшей аккуратностью. Если все в нормальную погоду будут ездить как в гололед, город вечно в пробках будет стоять.
Как ваша программа будет определять, когда нужно включать «защиту», а когда не надо?
Ваша аналогия некорректна. IT — достаточно уникальная среда, чтобы не сравнивать ее с простыми «житейскими» ситуациями.
Если пользователь может совершить ошибку — однажды он ее совершит. Задача разработчика ПО — как можно сильнее заблокировать пользователю возможности «совершить ошибку».
Вы же пытаетесь вечно выехать на аналогиях, вместо понимания проблемы, которую вы строите
Как ваша программа будет определять, когда нужно включать «защиту», а когда не надо?

Так это администратор по большому счету должен решать, ну и разработчик (естественно максимально декларативно).

Как например должно по вашему определяться где в 1С должны ставиться управляемые блокировки, а где нет. То то же.
Ваша аналогия некорректна. IT — достаточно уникальная среда, чтобы не сравнивать ее с простыми «житейскими» ситуациями.

Точно, законы логики, оптимизации и вероятностей там не работает.
Если пользователь может совершить ошибку — однажды он ее совершит. Задача разработчика ПО — как можно сильнее заблокировать пользователю возможности «совершить ошибку».

Ну тогда можно просто сделать базу однопоточной и все будет ок. Ну или просто заблокировать пользователю все возможности. Еще раз это всегда вопрос баланса возможностей и рисков. Just business.

Ну и в сто первый раз, lsFusion дает выбор (!), а 1С нет. А сейчас все эти споры мне до боли начинают напоминать классическое «все беды от мяса».

Так покажите, как реализовывается этот выбор. Вы же просто выдает перл за перлом вместо конкретного ответа.
И постоянные переходы на гиперболу… хорошее и логичное действие.

Выбор, что хотите, ставите пессимистичную блокировку (я писал выше как), хотите нет. Что вам конкретно непонятно? Если действительно непонятно, ответьте на вопрос:
Как например должно по вашему определяться где в 1С должны ставиться управляемые блокировки, а где нет.

И все само встанет на свои места.
И вот еще один аспект этой же проблемы: это ответственность пользователей за документы. В 1с из-за явной блокировки документа мы получаем гарантию, что пользователь видел актуальное состояние документа, оценил его, внес изменения и записал. И поэтому можем говорить, что он полностью отвечает за свои исправления.
А как быть в фьюжене, когда даже в процессе редактирования дока, в него уже могут быть внесены изменения другими пользователями? Думаю, это приведет к ситуации, когда никто не может нести ответственность ни за документ, ни за исправления.
В 1с из-за явной блокировки документа мы получаем гарантию, что пользователь видел актуальное состояние документа, оценил его, внес изменения и записал. И поэтому можем говорить, что он полностью отвечает за свои исправления.

Ну так я также могу и про Google docs сказать. Плюс часто за разные данные в одном документе отвечают разные люди, особенно когда документ сложный или содержит много данных.

Еще раз никто не мешает повесить пессимистичную блокировку. Просто в 99 процентов случаев это не нужно и не удобно. Собственно поэтому например блокировочные системы контроля версий умерли под натиском того же git (хотя там тоже можно те же аргументы про актуальное состояние, его оценку и т.д. привести).

Ну и главное. Основной посыл в том, что lsFusion поддерживает и оптимистичные и пессимистичные блокировки (без хитрых вывертов по сути из коробки), а 1С только пессимистичные.
Когда ваш эфемерный «1%» будет стоить вам миллионы — может задумаетесь о том, что при разработке ПО пользоваться правилом «Парето» (который обычно берут на вооружение продаваны для впаривания) — непозволительная роскошь.
Когда ваш эфемерный «1%» будет стоить вам миллионы

Когда будет стоить миллионы, тогда и включите пессимистичную блокировку (ну или лучше ограничениями поработаете). Пример про гололед я уже приводил выше. Ну и про борьбу оптимистичных блокировок с пессимистичными (кстати борьба SQL-серверов версионников с блокировочниками ну вот прямо один-в-один то что вы говорите, напомнить кто там выиграл).
В том и фишка разработки ПО, что там этот 1% должен быть исключен. Иначе цена вашего ПО — 0 копеек.
Тогда бы все СУБД были блокировочниками. И вообще все бизнес-приложения однопоточными.

Еще раз в бизнесе это всегда про соотношение: Затраты на решение проблемы + затраты на преодоление ограничений от ее решений (например менее эффективную работу сотрудников) vs вероятность возникновения проблему * ущерб ее устранения.

И вместо ответа — гипербола и уход от ответа. Верной дорогой идете.

Какая гипербола? Это вы уходите от ответа.

Вы же в курсе что версионный режим СУБД МЕНЕЕ целостный (то есть вот эта ваша ошибка на миллион), но гораздо более масштабируемый. И все равно абсолютное большинство сложных нагруженных систем используют именно версионные СУБД. Потому что баланс рисков / возможностей. Или вы не согласны с формулой:
Еще раз в бизнесе это всегда про соотношение: Затраты на решение проблемы + затраты на преодоление ограничений от ее решений (например менее эффективную работу сотрудников) vs вероятность возникновения проблему * ущерб ее устранения.

Так и есть. Привели сборку текста запроса заказов клиентов в прошлой статье. И пишут: "Вот!!!". А я спрашиваю: "А что вот то?".
А они: "Ну как это можно поддерживать?"

А я спрашиваю: «А что вот то?».

То что весь этот код нужен ТОЛЬКО для проверки ОДНОГО ограничения, а в lsFusion для этого одна декларативная строка кода.

Ну нет же. Не может одна строка кода полностью заменить "километровый" запрос SQL.
Если, конечно, этот километр в одну километровую строку...

Имеется ввиду, что если у вас есть уже в программе какая-то вычисляемая величина, например, "Остаток". То, например, установить ограничение на то, что этот остаток должен быть всегда неотрицательный, можно одной строкой. Независимо от того, от чего эта величина зависит. Да, там может быть в результате километровый SQL-запрос, если эта величина сложно вычисляется, но запрос будет сформирован платформой.

Вы комментарии накручиваете? Я не о том писал.

Нет, я пробовал на пальцах пояснить, что имелось ввиду в комментарии, на который вы ответили "Не может одна строка кода полностью заменить "километровый" запрос SQL."

Мне конкетанировать последовательно свои комментарии в этой ветке? Там запрос таблицы заказов клиентов.

Может. Если платформа сама сгенерит такой инкрементальный запрос. Кстати, строго говоря, с материализованными представлениями тот же Oracle ЕМНИП например так и делает.

Запрос таблицы заказов клиентов это не проверка одного ограничения. А накручивать комментарии к статье не хорошо.

Весь тот код, что есть в первой статье только для проверки одного ограничения. Вы думаете я с кодом не умею работать? Если так то откройте исходники УТ и покажите, где он еще используется. Может я действительно что-то пропустил.

Так это вы накручиваете. Мне если честно не доставляет столько удовольствия, объяснять одни и те же вещи по 100 раз.
Насчет монструозных кусков кода. В контексте проблемы неэффективного получения данных вы приводили пример наполнения таблиц к проведению документа из, видимо, УТ. В частности, процедуру ИнициализироватьДанныеДокумента. Видимо, как пример избыточного получения данных и сложных танцев с бубном. Правда, свой контрпример вы привели (и здесь это подтвердили) как проверку очень простого ограничения вроде текущего остатка. А в 1С процедура проведения, для которой и собираются все эти таблицы, выполняет гораздо более широкий набор действий с объектами по определенной бизнес-логике. Это и расчет сопутствующих показателей для всех регистров, и контроль остатков, и различные блокировки на время записи документа, и даже проверка необходимости изменять записи в таблицах, если они не изменились с момента предыдущей записи. Вот по этому я и говорю — вы сравниваете выдранные из контекста боевых решений алгоритмы со своими академичными примерами, а это неправильно.

Насчет разделения на контекст клиента и сервера. Это сделано для уменьшения количества обращений к серверу. В вашем же случае как минимум необходимо постоянное получение обновленных данных об объекте с сервера, что не слишком-то оптимально. Ну или хотя бы постоянная проверка состояния. Опять же, по вашим словам — любая манипуляция происходит в едином контексте на сервере, от вашего клиента поступают лишь команды на манипуляцию. В 1С можно заложить множество бизнес-логики на исполнение только на клиенте, что заметно снизит количество обращений к серверу. И да, для написания максимально оптимального решения программисту необходимо понимать потоки данных Клиент-Сервер.

Далее, про представления. Вы сами на примере некорректно написанного запроса пытались показать, что виртуальные таблицы, к примеру, не подходят для решения такой простой задачи, как вывод остатков в динамическом списке номенклатуры, т.к. будут неоптимально обращаться сразу ко всей таблице остатков без фильтрации по номенклатуре… Хотите верьте хотите нет, но запрос для динамического списка
ВЫБРАТЬ
	Товары.Наименование КАК Наименование,
	ЕСТЬNULL(ТоварыНаСкладах.КоличествоОстаток, 0) КАК КоличествоОстаток
ИЗ
	Справочник.Номенклатура КАК Товары
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Склад = &Склад) КАК ТоварыНаСкладахОстатки
		ПО (Товары.Ссылка = ТоварыНаСкладахОстатки.Номенклатура)

будет работать оптимально, и выбирать остатки только по тем товарам, которые в данный момент видны на экране пользователю. Более того, даже такой, казалось бы неоптимальный, запрос
ВЫБРАТЬ
	СпрККТ.Ссылка КАК Ссылка,
	ВложенныйЗапрос.Дата КАК ДатаПоследнегоЧека
ИЗ
	Справочник.ККТ КАК СпрККТ
		ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
			МАКСИМУМ(ЧекККМ.Дата) КАК Дата,
			ЧекККМ.ККТ КАК ККТ
		ИЗ
			Документ.ЧекККМ КАК ЧекККМ
		
		СГРУППИРОВАТЬ ПО
			ЧекККМ.ККТ) КАК ВложенныйЗапрос
		ПО СпрККТ.Ссылка = ВложенныйЗапрос.ККТ

будет работать оптимально и не вызовет получения лишних данных
Вот по этому я и говорю — вы сравниваете выдранные из контекста боевых решений алгоритмы со своими академичными примерами, а это неправильно.

Стоп. Я когда выдирал алгоритм, специально поиском проверял, что это код нужен ТОЛЬКО для проверки одного ограничения, что количество товара который отгружается не больше количества товара который приходуется / оприходован. Я там даже пометку сделал
PS: Проверено, эти временные таблицы нигде больше не используются, только для проверки одного простого ограничения.

Если вы найдете, где эти временные таблицы еще используются в УТ, то напишите где этот код найти (правда может за год что-то изменилось). И в любом случае вот это все:
и различные блокировки на время записи документа, и даже проверка необходимости изменять записи в таблицах, если они не изменились с момента предыдущей записи

Это чистая accidental complexity которая в 1С есть, а в lsFusion нет.
В 1С можно заложить множество бизнес-логики на исполнение только на клиенте, что заметно снизит количество обращений к серверу. И да, для написания максимально оптимального решения программисту необходимо понимать потоки данных Клиент-Сервер.

Знаете что такое premature оптимизация и правило Парето? Безусловно возможно есть случаи, где такая тонкая оптимизация может понадобиться. И важно чтобы такая возможность была (и в lsFusion скажем она тоже есть). Но в 97 процентов случаев такая оптимизация все-таки не нужна от слова вообще, а разработчику приходится делать всю эту лишнюю работу, по разделению на &НаКлиенте и &НаСервере, создавая тонны запутанного кода. То есть они с водой ребенка выплеснули.
будет работать оптимально и не вызовет получения лишних данных

А зачем тогда весь этот огород с:
Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)
Если она сама все протолкнет и не «вызовет получение лишних данных».
Стоп. Я когда выдирал алгоритм, специально поиском проверял, что это код нужен ТОЛЬКО для проверки одного ограничения, что количество товара который отгружается не больше количества товара который приходуется / оприходован. Я там даже пометку сделал

Вообще-то в процедуре ИнициализироватьДанныеДокумента собираются и, где это возможно, вычисляются все данные для проведения документа по регистрам и дальнейшей проверки на ненулевой остаток. В первую очередь для проведения. Кстати, в статье «Почему не 1С» вы в главе «Отсутствие ограничений и событий для значений регистров» не совсем разобрались зачем нужно получать значения из регистров перед записью и что с ними делается при записи. А именно, вычисляется — какие записи были изменены таким образом, что это может вызвать отрицательные остатки. И проверять отрицательный остаток только для тех регистров, в которых такое вообще могло произойти. А в вашей системе, выходит, агрегирование для контроля остатка производится безусловно, даже если этого можно и не делать? А строк, знаете ли, могут быть миллионы…
Знаете что такое premature оптимизация и правило Парето? Безусловно возможно есть случаи, где такая тонкая оптимизация может понадобиться.

Моя многолетняя практика 1С показывает, что если ERP-система выходит из рамок локальной сети в интернет, то разделение контекстов на клиент и сервер уже не является пустым звуком. Взять хотя бы загрузку данных в условный отчет комиссионера из того же экселя. Он может весить туеву хучу. Зачем гонять его на сервер? Вполне достаточно разобрать его полностью на клиенте и отправить минимальный объем данных на сервер, ну и так далее, боевые примеры могу приводить бесконечно.
А зачем тогда весь этот огород с:
Номенклатура В (
ВЫБРАТЬ Номенклатура
ИЗ Документ.РасходнаяНакладная.Состав
ГДЕ Ссылка = &Документ)
Если она сама все протолкнет и не «вызовет получение лишних данных».

Это чей-то мозговой клин. Программисты самой 1С — тоже люди. Можете смело удалить это условие из параметров виртуальной таблицы — план запроса не изменится.
А в вашей системе, выходит, агрегирование для контроля остатка производится безусловно, даже если этого можно и не делать? А строк, знаете ли, могут быть миллионы…

Нет, в этом и фокус. Всю эту тонну кода, который в 1С разработчик делает руками, lsFusion делает АВТОМАТИЧЕСКИ. Она сама определяет какие данные изменились, сама записывает во временные таблицы, сама строит инкрементальные запросы и т.п.
Моя многолетняя практика 1С показывает, что если ERP-система выходит из рамок локальной сети в интернет, то разделение контекстов на клиент и сервер уже не является пустым звуком. Взять хотя бы загрузку данных в условный отчет комиссионера из того же экселя. Он может весить туеву хучу. Зачем гонять его на сервер? Вполне достаточно разобрать его полностью на клиенте и отправить минимальный объем данных на сервер, ну и так далее, боевые примеры могу приводить бесконечно.

Можно, только в 95 процентов нафиг не нужно (да и в вашем случае сомнительно). Ну сэкономите вы 10% на оборудовании (и то не факт), зато очень сильно увеличите стоимость доработок (так как код будет куда более сложным / непонятным), уменьшите надежность (так как при большем количестве кода куда больше ошибок и т.п.). Классическая premature оптимизация. Опять таки многолетний опыт на очень сложных системах крупной розницы с очень большим объемом данных / пользователей.
Это чей-то мозговой клин. Программисты самой 1С — тоже люди. Можете смело удалить это условие из параметров виртуальной таблицы — план запроса не изменится.

Что значит мозговой клин? Это офдокументация. И что значит не изменится план запроса? Запрос к SQL базе не изменится или план не изменится? Потому как в postgres или файловой очень даже изменится (почитайте этот раздел). Да и в MS SQL, если сгенерится какой нибудь COALESCE (например FULL JOIN), план запроса тоже очень даже изменится. Собственно поэтому в типовых эти предикаты и проталкивают руками.

Для того чтобы это все нормально работало под postgres и даже MS SQL, нужен нормальный аля-CBO оптимизатор запросов сверху, а для этого нужна статистика и много чего еще, а 1С даже более простые вещи не реализовал.

Какой клин? Зачем вообще устанавливают параметры виртуальной таблицы?

Прекратите везде пихать «правило Парето», как универсальный аргумент. Вы не понимаете границ его использования, так еще и лихо меняете, то 97%, то 99%. По факту — это просто демагогический приём манипулирования. Так обычно действуют продаваны, когда хотят туфту пихнуть покупателю.
И да, если любите «правило Парето» — полюбите и «закон Мёрфи» — если что-то плохое может произойти — оно обязательно произойдет. Вот этот закон должен быть основой при разработке ПО, в котором крутятся миллионы.
Прекратите везде пихать «правило Парето», как универсальный аргумент. Вы не понимаете границ его использования, так еще и лихо меняете

Это вы не понимаете его суть. То что в 80 (или 95) процентов может делаться просто должно делаться просто. В остальных случаях должна быть ВОЗМОЖНОСТЬ сделать сложно. Заставлять делать лишнюю работу разработчика это в лучшем случае premature оптимизация и одно из самых больших зол в разработке.

Закон Мерфи — это вообще говоря сатирический (несерьезный) закон. Причем тут он не понятно. И крутятся миллионы это демагогический прием, если вы посчитаете затраты на борьбу с проблемой и сравните с вероятностью проблемы умноженной на ущерб все будет совсем не так как вы видите.
То есть вы предлагаете заставлять делать пользователей 100 раз одну и ту же работу? Вместо того, чтобы разработчику 1 раз сделать так, чтобы это не приходилось делать?
Еще раз — ваш принцип «пусть сами разбираются» не должен быть основным при разработке массового ПО
Причем тут пользователи? У пользователей как раз все зашибись они работают параллельно, система сама следит за целостностью (гарантируя ее). Те же ситуации когда кто-то кого то затер с тем же пересчетом надуманные, так как пересчет с гораздо (!) большей вероятностью пройдет через 5 секунд после изменения первого пользователя и будут те же яйца.

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

С учето полного отсутствия каких-то прудов при постоянном аппелировании к этим крупным клиентам — их наличие вообще под вопросом

Вероятность — хитрая штука. У меня постоянно выстреливают события, вероятность которых составляет сотые. Любая программа должна учитывают ситуация, какая бы малая вероятность возникновения ее не была.
Если у вас постоянно выстреливают события, вероятность которых составляет сотые, значит вы просто неправильно оценили вероятность.
Любая программа должна учитывают ситуация, какая бы малая вероятность возникновения ее не была.

Ну это из разряда, что давайте откажемся от автомобилей в пользу общественного транспорта, так как есть вероятность погибнуть в ДТП. Опять-таки баланс рисков / затрат / возможностей, сверху сто раз уже обсасывалось.
И опять странные аналогии, в которых вы пытаетесь съехать на «ну посмотрите ну». Сфера ПО настолько отличается от «житейских вещей», что построить грамотную аналогию очень тяжело.
Начиная с того, что ПО — такой товар, который можно создать 1 раз, а продать хоть миллион.
И да, вот вам пример даже из «житейского уровня» — автомобильные гиганты зря что ли делают бесплатную «замену» своим покупателям при появлении в НЕКОТОРЫХ дефекта, который «ну очень маловероятен»? Или «это другое»?) Ведь шанс, что во всех машинах эта проблема воспроизведется — «крайне мала». Но замену делают на всю линейку машин, а это десятки или даже сотни тысяч машин.
Они просто считают вероятность проблемы, сумму судебного иска, и стоимость отзыва машин. Если вероятность * сумма иска из-за возникновения проблемы > стоимости отзыва — отзывают. Нет, не отзывают. Уверен на один отзыв, существует сотни выявленных «детских» проблем где это сравнение в обратную сторону и никаких машин при этом не отзывают.
Это всё ваши домыслы. Но вы говорите об этом, как о факте. Вы, случайно, не в руководстве у всех этих фирм?)
Хотя вам не впервой свои фантазии выдавать за реальность
Это всё ваши домыслы. Но вы говорите об этом, как о факте. Вы, случайно, не в руководстве у всех этих фирм?)

Нет, они монетку бросают отзывать или не отзывать. Не, вы серьезно не понимаете как решения, особенно в бизнесе, принимаются? Там простой KPI максимизация матожидания прибыли (естественно с ограничениями по дисперсии).
нет, это и близко не из этого разряда. Т.к. отказ от авто — проблема удобства/комфорта/возможностей. А вот написать лишний код — это совсем иное. Это как раз и есть стабильное, работающее ПО.
Не совсем понял. Сделать документ однопользовательским / неразделяемым это тоже проблема удобства / комфорта / возможностей. Можно и Excel файл по очереди редактировать только это неудобно. Точно также как и все файлы в системе контроля версий можно менять по очереди, но это неудобно когда есть git.
Софт должен обеспечивать безопасность и целостность данных. Сколько видел систем, везде есть блокировки, чтобы как раз не было таких проблем. Когда у Вас идет речь про мульены денег, такое выглядит совсем иначе.
Да, но для безопасности и целостности не обязательно делать базу «однопоточной» (пессимистичными блокировками). Это крайность. Как правило оптимистичные блокировки — это идеальный баланс между целостностью и удобством / масштабируемостью, и собственно поэтому де-факто стали стандартом в мире / во многих областях.
Да я не про конкретные вещи, а именно про вероятность. Меня смущает софт, который не учитывает ситуации, вероятность которых мала. Для меня допустимая вероятность события, которое не нужно учитывать, это нуль.
Стоп. Я уже писал, что никто не мешает а) сделать пессимистичную блокировку б) и это более правильно, повесить необходимое ограничение на целостность (скажем что не должно быть 2 строк с одинаковым товаром), которое сведет вероятность ситуации к 0. Ведь если такого ограничения не будет, может включиться человеческий фактор и человек допустит ситуацию просто по ошибке. Не говоря уже о том что пользователи могут просто разминутся и никакая пессимистичная блокировка не поможет. Да и просто предупреждение, что кто-то отредактировал запись, пользователь может тупо проигнорировать.

ну 1с ведь не сразу дорос до своего уровня, в 1с тоже был 7.7. Фузина тоже дорастёт

А зачем вы сравниваете свое решение с 1С? Хотите сделать рекламу «нападением» на армию 1С-ников, которых, думаю существенно больше? Пытаться «выехать» за счет «унижения» другого не самый честный способ (хотя думаю унизить будет сложно, все же 1С хорошая платформа для решения задач для которых она предназначена). Многие 1С-ники сами не в восторге от своего инструмента, но им она даёт больше чем другие. И многим будет интересно просто узнать про возможности других систем.
Например 1С на хабре не занимается сравнением себя с другими, а просто пишут (мало) что и почему они делают.
Потому что когда они НЕ сравнивают себя с 1С (или SQL, или еще кем-то), то их статьи игнорируют (никто не пишет комментариев, плюсы только от 20 сотрудников компании на Хабре).

А с чем идет сравнение в наших двух предыдущих статьях?

В последней статье от 9 февраля, аббревиатура «1С» в тексте поста встречается 7 раз. Даже тег стоит «замена 1С»
Ну строго говоря если взять статьи по количеству просмотров и комментов, статей где идет акцент на 1С хорошо если 20%. Ну и с другой стороны это логично, это все же самый распространенный инструмент на постсоветском пространстве.
Всё просто — это их маркетинговая основа.
Вместо того, чтобы говорить, что в фузион хорошо — они пишут, что в 1С плохо. Причем плохо именно по их «авторитетному» мнению, а почему — потому что «правило Парето» и «это не нужно в 99% случаев».
Потому что если будут пытаться показать достоинства своей программы без унижения других — рассказывать почти не о чем. Да и тяжелее будет переводить критику в полемику типа «а вот в 1С хуже»
Всё просто — это их маркетинговая основа.
Вместо того, чтобы говорить, что в фузион хорошо — они пишут, что в 1С плохо. Причем плохо именно по их «авторитетному» мнению, а почему — потому что «правило Парето» и «это не нужно в 99% случаев».
Потому что если будут пытаться показать достоинства своей программы без унижения других — рассказывать почти не о чем. Да и тяжелее будет переводить критику в полемику типа «а вот в 1С хуже»

Преимущества обратная сторона недостатков. Большинство реклам начинаются с показов проблем (типа рвется рубашка, что-то липнет и т.п.). Это как бы основа маркетинга. Понятно что многие могут сказать ну липнет и липнет, ну загрязняет окружающую среду и загрязняет, ну нет того-то и нет. Но реклама то как раз расчитана на тех кто понимает проблему, а не тех кого «все устраивает». Тем кого все устраивает и нет смысла ничего объяснять.
В том и дело, что во всех рекламах:
1) что-то липнет, предлагают решение — это же реклама чистящего средства, а не «против грязи». Грязь не обвиняют, грязь — проблема.
2) когда предлагают своё решение, никогда не поливают грязью других (кроме редких «идейных» противостояний типа пепси-кока, айфон-андроид). В 99% (раз вы любите это число) случаев против «правильного» товара противопоставлен «любой другой товар такого типа». То есть «конкурент» — обезличен. Это негласное правило рекламы, но в других сферах за такое могут и засудить.
Вы же вместо озвучивания проблемы говорите «1С делает это плохо, а Фузион — хорошо». При этом вы сравниваете совершенно различные функциональные элементы. Про это вам уже выше писали. Это как показывать калькулятор свой и чужой на примере «2+2=4». И говорить, что ваш калькулятор оптимизирован, а чужой нет, потому что на примере «2+2=4» он работает быстрее и код меньше. image
1) что-то липнет, предлагают решение — это же реклама чистящего средства, а не «против грязи». Грязь не обвиняют, грязь — проблема.

Ну я имел ввиду, что при использовании другого чистящего средства что-то липнет.
когда предлагают своё решение, никогда не поливают грязью других (кроме редких «идейных» противостояний типа пепси-кока, айфон-андроид). В 99% (раз вы любите это число) случаев против «правильного» товара противопоставлен «любой другой товар такого типа». То есть «конкурент» — обезличен. Это негласное правило рекламы, но в других сферах за такое могут и засудить.

У обезличивания всегда есть проблема, что человек начинает думать, что это у других чистящих средств проблемы, а у его все хорошо. Ну и про негласное правило рекламы это конечно весело. Пикирование бмв — ауди помните? И кто там кого засудил?
Вы же вместо озвучивания проблемы говорите «1С делает это плохо, а Фузион — хорошо».

Не понял, я озвучил проблемы на мой взгляд (но при этом пытаясь максимально привязаться к общепризнанным проблемам — блокировок, типизации, полиморфизма и т.п.), показал как они решаются в 1С, и показал как решаются в lsFusion. Если кто-то не согласен, не вопрос, жду в комментах. Вон человек выше начал аппелировать к пункту об отсутствии оптимизатора запросов (что предикат не надо проталкивать), я ему задал вопрос, он исчез (видимо ушел разбираться). Я честно очень ждал еще в прошлой статье, чтобы кто-то предметно что-то опроверг (но все свелось к сам дурак, автор ничего не понимает, это все не нужно и т.п.). Ну ок.

Про картинку совсем не понял. Про 4 пункт ответил абзацем выше, с 3 во многих пунктах есть проблема с метрикам, но где мог я их использовал (показывая сколько кода, приблизительно правда, в 1С, а сколько в lsFusion получается, например в ограничениях и разделении сервера и клиента), с 2 мы наоборот делаем продукт максимально не похожим, ну а 1 пункт про детализацию это как раз и есть разбор по 30 конкретным пунктам, куда уж детальнее.
1) это и есть недобросовестное сравнение. И да — «липнет» в вашем примере — существует только в вашем воображении. Это как «не думай о розовом кролике». Проблемы может в принципе не быть, но её придумывают, хотя раньше проблемой это не считалось.
2) пикирование многих известных брендов — это поддерживаемая ими игра. Использовать прямое противопоставление мало кто решается. И в любом случае это далеко не «добросовестная реклама».
3) «показывая сколько кода» — ну да, только в 1С этот кусок кода используется и в других местах, но об этом вы, конечно, «забываете». И не надо заливать, вы сравниваете не возможности платформы, а конкретные РЕШЕНИЯ с вашими выверенными примерами, которые вы сами подбираете. Это как говорится «тут считаем, тут не считаем, тут переворачиваем».
Про разделения на клиент и сервер — вам уже писали. Ранее разделения не было, потом решили добавить… Хм… Может была ПРИЧИНА такого разделения?) Хотя нет, бред. Всё, что сделано в 1С — по определению плохо.
30 «конкретных пункта, которые мы придумали» ) вам неоднократно высказывались про сомнительность вашего выбора и аргументации в пунктах.
И да — «липнет» в вашем примере — существует только в вашем воображении. Это как «не думай о розовом кролике». Проблемы может в принципе не быть, но её придумывают, хотя раньше проблемой это не считалось.

Ну или наоборот проблема существует, просто вы ее не видите. Думаю сто лет назад, люди ездящие на лошадях тоже проблем не видели, ну ездят и ездят.

Хотя в данном случае большая часть проблем уже стандарты в других областях.
И в любом случае это далеко не «добросовестная реклама».

Не помню из какого фильма, но осталась в голове фраза: «Тогда тем более нет смысла играть честно».
3) «показывая сколько кода» — ну да, только в 1С этот кусок кода используется и в других местах

Я уже четвертый раз спрашиваю. В каких еще местах используется это кусок кода. Так никто не может УТ открыть и показать мне этот кусок.
И не надо заливать, вы сравниваете не возможности платформы, а конкретные РЕШЕНИЯ с вашими выверенными примерами, которые вы сами подбираете. Это как говорится «тут считаем, тут не считаем, тут переворачиваем».

Честно устал повторять, что я просто взял ПРИМЕРЫ из типовых решений. Не знаю как вам еще это объяснить. Давайте сторонний читатель сам решит.
Может была ПРИЧИНА такого разделения?)

Бритву Хэнлона помните? «Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью». Хотя я называл причину, так было проще, и очень по программерски, просто переложить проблему на других программистов.
вам неоднократно высказывались про сомнительность вашего выбора и аргументации в пунктах.

Да, но никто по существу ничего не написал. Ну не всерьез же воспринимать аргументы, что полиморфизм это все происки империализма, if'ов более чем достаточно.
1) проблема есть, потому что ВЫ так сказали?) А другие проблемы надуманные (с которыми Фузион не справится), потому что ВЫ так сказали?) Мне если честно уже смешно читать ваши ответы, когда одни проблемы существуют по вашей воле, а другие таковыми не признаются по вашей же воле. Удобно.
2) Вот это и вся суть вашего маркетинга. Грязные приёмы для очернения конкурента. Но мы — не в политике. И тут такое не считается нормой. А реальным пользователям и покупателям нужна не грязь других, а плюсы вашего решения.
3) Всем просто лень. ВЫ вытащили этот код, так ПОТРУДИТЕСЬ посмотреть его использование. Бремя доказательства висит на обвинении. Вы обвиняете решение в том, что часть кода используется для решения малой задачи. Так ДОКАЖИТЕ это. А требовать доказательств от защиты — «удобно».
4) В том то и дело. Вы ВЗЯЛИ примеры из типовых РЕШЕНИЙ. УДОБНЫЕ вам примеры. И сравниваете с УДОБНЫМ вам РЕШЕНИЕМ. Это не сравнение двух платформ. Это сравнение решений, где вы сами выбираете «оружие», «арену» и «правила». В итоге всё сравнение оказывается пшиком. Сранений платформы тут очень мало.
5) О да, всё глупость, если связано с 1С. И всё гениально, если сделано мной) ещё одна «удобная» парадигма маркетинга.
6) В том и фишка, что ваши «аргументы» настолько несостоятельны, что пытаться их логически опровергнуть тяжела. Это как доказывать человеку, что Земля не плоская) И любой ваш аргумент он перебьет своей очередной фантазией.
1) проблема есть, потому что ВЫ так сказали?) А другие проблемы надуманные (с которыми Фузион не справится), потому что ВЫ так сказали?) Мне если честно уже смешно читать ваши ответы, когда одни проблемы существуют по вашей воле, а другие таковыми не признаются по вашей же воле. Удобно.

Ну я точно тоже самое могу сказать про ВАС. Еще раз, не надо считать читателей за идиотов, тем более что все читатели разные и для кого то что-то проблема, а для кого-то нет. Я уже приводил, что для кого-то кто на лошадях ездит, тоже проблем нет. И?
2) Вот это и вся суть вашего маркетинга. Грязные приёмы для очернения конкурента. Но мы — не в политике. И тут такое не считается нормой. А реальным пользователям и покупателям нужна не грязь других, а плюсы вашего решения.

Не понял где вы нашли грязь? В статье показано как те или иные вещи делаются в 1С, и к каким проблемам на взгляд автора они приводят. Не считаете это проблемами, ок, ваше право. Уверен многие потребители тех же ДВС автомобилей не считают многие преимущества Тесла преимуществами (и соответственно недостатки ДВС недостатками), тоже их право.
3) Всем просто лень. ВЫ вытащили этот код, так ПОТРУДИТЕСЬ посмотреть его использование. Бремя доказательства висит на обвинении. Вы обвиняете решение в том, что часть кода используется для решения малой задачи. Так ДОКАЖИТЕ это. А требовать доказательств от защиты — «удобно».

Ничего себе лень? Я там со всех сторон облазил код, чтобы найти другие использования не нашел. И как мне доказывать, записать видео, где я ищу по названиям временных таблиц или хожу по дереву вызовов и не нахожу других использований? Как раз единственный вариант что-то доказать — это наоборот найти использование, но что-то пока никто не может.
4) В том то и дело. Вы ВЗЯЛИ примеры из типовых РЕШЕНИЙ. УДОБНЫЕ вам примеры. И сравниваете с УДОБНЫМ вам РЕШЕНИЕМ. Это не сравнение двух платформ. Это сравнение решений, где вы сами выбираете «оружие», «арену» и «правила». В итоге всё сравнение оказывается пшиком. Сранений платформы тут очень мало.

Строго говоря, я нашел вообще первый попавшийся пример. Если вы найдете как в УТ ставится ограничение на остаток декларативно одной строкой, без триггеров, построения дельт и т.п. (хотя я понимаю что это теоретически в 1С не возможно), милости прошу.
5) О да, всё глупость, если связано с 1С. И всё гениально, если сделано мной) ещё одна «удобная» парадигма маркетинга.
6) В том и фишка, что ваши «аргументы» настолько несостоятельны, что пытаться их логически опровергнуть тяжела. Это как доказывать человеку, что Земля не плоская) И любой ваш аргумент он перебьет своей очередной фантазией.

Я так и понял. «Ой, все». Серьезно, такой спор реально не имеет смысла, давайте завязывать.
Большинство реклам начинаются с показов проблем (типа рвется рубашка, что-то липнет и т.п.)

Да, но там сравнивают с «Обычным стиральным порошком».
Преимущества обратная сторона недостатков

Тогда опишите свои недостатки.
Ваша реклама на хабре для кого? Кого пытаетесь привлечь? Конечный потребитель суда заходит редко. Переманить на свою сторону «армию» 1С-ников? Многие ваши примеры для большинства 1С-ников не являются проблемой из-за которой они должны менять свой основной инструмент (превращение 1С в почти монополию тому доказательство). В результате те 1С-сники что хорошо знают свой инструмент и более активны чем остальные, становятся скорее вашими противниками чем сторонниками.
1С и lsFusion это инструмент для зарабатывания денег. Люди готовы менять инструмент только если он будет приносить им больший доход. Лучше покажите на примере «абстрактного» внедренца, почему он будет зарабатывать больше.
Да, но там сравнивают с «Обычным стиральным порошком».

Так я бы наоборот гордился, что 1С стал настолько нарицательным, что его считают «обычным стиральным порошком».
Тогда опишите свои недостатки.

Мы когда-то начинали описывать. Но платформа меняется поэтому некоторые недостатки могут появляться / уходить.
Ваша реклама на хабре для кого? Кого пытаетесь привлечь? Конечный потребитель суда заходит редко. Переманить на свою сторону «армию» 1С-ников? Многие ваши примеры для большинства 1С-ников не являются проблемой из-за которой они должны менять свой основной инструмент (превращение 1С в почти монополию тому доказательство). В результате те 1С-сники что хорошо знают свой инструмент и более активны чем остальные, становятся скорее вашими противниками чем сторонниками.
1С и lsFusion это инструмент для зарабатывания денег. Люди готовы менять инструмент только если он будет приносить им больший доход. Лучше покажите на примере «абстрактного» внедренца, почему он будет зарабатывать больше.

Есть такая штука — кривая Роджерса (кривая восприятия инноваций). Ее фишка в том что 85 процентов всегда будет воспринимать любые инновации негативно. Так было с Эппл, теслой, фейсбуком, Биткойнами и с чем угодно. И такие люди пересядут на условную теслу, только когда на ней уже все будут ездить. А пока для этих majority / lagards все новое (что apple'ы, что теслы в свое время) это выскочки глючные и неудобные.

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

То есть если подытожить, все эти материалы для 2% innovators и частично для 13% early adopters. Пытаться угодить остальным 85% это бесперспективная вещь, и как ни парадоксально хейт от них даже часто работает в плюс (так как лучше отделяет и позиционирует тебя на рынке). Ну и опять-таки написание таких статей занимает не слишком много времени, а в спорах рождается истина (начинаешь гораздо лучше понимать свои сильные и слабые стороны, на что лучше делать акценты и т.п.).

Ну а зарабатывать будет больше, так как сможет предложить более гибкий, технологичный, дешевый в сопровождении и т.д. продукт заказчику. То есть дать заказчику больше, потратив на это меньше времени, тем самым больше заработав. Где-то снизу я уже про это писал.
Не тешьте себя фантазиями. Вы не эппл. и не Тесла, вам США не будут деньги подкидывать из военного бюджета для войны с 1С.
Как можно «зарабатывать больше», если продукт будет «дешевый в сопровождении»?)
Не тешьте себя фантазиями. Вы не эппл. и не Тесла, вам США не будут деньги подкидывать из военного бюджета для войны с 1С.

Да, да. Я в курсе что Теслы, SpaceX'ы, Apple'ы и прочие фейсбуки это все пузыри, существуют только благодаря военным бюджетам и обману инвесторов, и скоро лопнут и все такое. Ведь только у одного Маска есть деньги, его же конкуренты бедны как мыши.
Как можно «зарабатывать больше», если продукт будет «дешевый в сопровождении»?)

Так заказчик будет платить в два раза меньше чем остальным, а вы будете тратить времени в 4 раза меньше. Итого в 4 раза больше сделаете и в 2 раза больше заработаете. Win-win.
Итого в 4 раза больше сделаете и в 2 раза больше заработаете

Это при неограниченном спросе. Вы ведь понимаете что спрос по большей части сейчас весь удовлетворён.
А когда вы станете монополистом, половине тех кто сейчас этим занимается нужно будет менять сферу деятельности.
Это при неограниченном спросе. Вы ведь понимаете что спрос по большей части сейчас весь удовлетворён.

Ну не знаю. У нас заказчики постоянно фонтанируют новыми идеями / доработками / изменениями текущих процессов. И многие не наши заказчики понимают, что их текущие решения накопили огромные технические долги, и ищут соответственно чем их заменить (правда чтобы не потерять то что есть, сделать все бесшовно и не очень дорого).
По поводу Теслы — по финансовым отчетам фирма в глубоком минусе по теме с автомобилями. Держится за счёт других проектов.
По поводу «больше продать» — спрос всегда ограничен. Особенно рынок мелких решений, на который нацелен Фузион. А при составлении «сложных» решений без наличия «комплектов» АКА «типовых» — становится не так уж и дёшево по вашим же названным ценам «часа»
Особенно рынок мелких решений, на который нацелен Фузион.

Да конечно. Нам, например, мелкие решения наоборот не настолько интересны. У нас 70% крупного ритейла Беларуси клиенты (это больше 4к сотрудников и больше 200 млнов долларов в год обороты). И типовые есть, то же lsFusion ERP (хотя это скорее набор из тысяч модулей), из модулей которого как из кубиков составляется решение, которое потом начинает достраиваться под конкретное видение заказчика.
Многие 1С-ники сами не в восторге от своего инструмента, но им она даёт больше чем другие. И многим будет интересно просто узнать про возможности других систем.
Так наилучший способ это сделать — показать, как проблемы 1С решаются в других системах. Для этого сначала надо сформулировать проблемы (что было сделано в статье «Почему не 1С»), а затем предложено решение. Что не так?
Ну как говорится «все познается в сравнении». Собственно когда человек выбирает любой инструмент (не только в ИТ), он как правило читает про недостатки одних инструментов и преимущества других (собственно недостатки и преимущества всегда являются зеркальным отражениям друг друга).
Статья — очень странная попытка вылезти в сравнении с 1С. Большая часть перечисленного давным давно реализована на сервере приложений. Такое ощущение, что автор сравнивает свое «Решение» с 7.7. 1С — это не только отлаженная бизнес-модель, но и универсальность и гибкость. Да и 99% рынка в РФ никто не отменял. Так что… Вы для начала СКД хотя бы реализуйте;)
Наоборот как раз. Части проблем этой / предыдущей статьи в 7.7 нет (например из-за ОФ, автоматических блокировок и т.п.).
но и универсальность и гибкость

Ага только скорость / стоимость разработки, надежность, поддерживаемость решений в последних версиях оставляет мягко говоря желать лучшего (я сейчас не про примитивный CRUD, а когда на руках уже сложная система аля УТ, или даже хотя бы УНФ). Собственно в этой статье и заключении я насчитал только под 30 пунктов.
Да и 99% рынка в РФ никто не отменял

Ну прям таки 99%. Даже в БУХ и ЗУП хорошо если 90%. А скажем в управленческих решениях крупного ритейла или банках того же 1Са очень мало. Ну или если горизонтально смотреть, в WMS они не лидер, в CRM тоже нет, в электронном документообороте тоже мимо, ну и т.п.
хорошо если 90%

Вы в денежном или количественном выражении?
Ведь если 10% это 100 клиентов, а 90 это 10000 то позиции совершенно разные. Кто в этом случае «крепче» стоит на ногах можно поспорить.
В пользовательском :) Но вообще ключевое в том предложении БУХ и ЗУП, а не сама цифра.
Ничего не понятно, но очень интересно! )
Первый вопрос, раз статья на хабра, значит желаете привлечь в первую очередь ИТ специалистов. Дайте ссылку на туториал, как развернуть систему и написать простейшую учетную систему, например «Домашняя бухгалтерия». Посмотрите по аналогии с 1С «Радченко. Практическое пособие разработчика.», ознакомление с платформой в таком ключе было бы максимально понятным.

Дорабатывать на базе MyCompany сможет любой продвинутый пользователь Excel.

Вот это страшно! 1С когда-то вместо «пользователь Excel» использовала слово «бухгалтер».
Это наследие до сих пор не дает спокойно спать по ночам многим 1Сникам.

Далее, вы упираете только на бесплатность, простоту разработки(и то пока под вопросом), и скорость? Или еще что-то есть?
Чтобы, например, презентовать систему руководству компании должно быть что-то еще.

И потом, вы пишете что платформа все делает сама, супер круто и супер эффективно. И что разработчику ничто низкоуровневое не нужно.
Блин! Я такое уже слышал про 1С! «Какие ваши доказательства?»(с)

В этом блоге есть уже довольно много статей с ответами на, по крайней мере, часть ваших вопросов.

Первый вопрос, раз статья на хабра, значит желаете привлечь в первую очередь ИТ специалистов. Дайте ссылку на туториал, как развернуть систему и написать простейшую учетную систему, например «Домашняя бухгалтерия». Посмотрите по аналогии с 1С «Радченко. Практическое пособие разработчика.», ознакомление с платформой в таком ключе было бы максимально понятным.

ru-documentation.lsfusion.org/pages/viewpage.action?pageId=2228236
ru.lsfusion.org/try

Хотя согласен есть над чем работать.
Вот это страшно! 1С когда-то вместо «пользователь Excel» использовала слово «бухгалтер».
Это наследие до сих пор не дает спокойно спать по ночам многим 1Сникам.

Ну так 1С всегда был чистой императивщиной. Они пытались ее замаскировать визуальным программированием, но это тоже самое в другой обертке.
Далее, вы упираете только на бесплатность, простоту разработки(и то пока под вопросом), и скорость? Или еще что-то есть?
Чтобы, например, презентовать систему руководству компании должно быть что-то еще.

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

Но на самом деле основное все же скорость / простота разработки, так как это по факту дает три вещи:
1. Бизнес начинает управляться через ИТ-систему (по факту процессы внедряются именно в ИТ-систему, создавая декларативные ограничения, которые пользователи не могут обойти и по факту им приходится работать как надо, «организационное» управление становится вторичным)
2. ИТ-система подстраивается под бизнес, а не наоборот (что позволяет реализовывать именно свои know how, а не универсальный бест-практис, который подходит только какому-то среднему бизнесу и по сути нивелирует конкретно твои конкурентные преимущества)
3. ИТ-система внедряется постепенно бесшовно без риска для бизнеса, сначала as is (причем с полной интеграцией по мастерданным, часто в обе стороны) потом постепенно мигрируя в to be.

И вот эти вещи на самом деле мы как правило продаем.

А вообще тут на первой странице собрано про платформу (про продуктам отдельные сайты есть / делаются и там вот это все сверху есть / будет):
ru.lsfusion.org
Еще модульность (это один из важных кейсов, причем как вертикальная, так и горизонтальная, то есть поставляю