Comments 799
Я надеюсь, что все больше разработчиков 1с будут смотреть на мир через парадигму «я знаю, какой язык лучше подойдет для этой задачи», не боясь изучать и применять python, js, c++, c# или java. Кроме того, хочется, чтобы и новые разработчики приходили с таким отношением, это во многом зависит от того, на сколько привлекательной будет инфраструктура разработки для молодых разработчиков, которые не боятся нового, не боятся совмещать.

Мой кейс таков: я начал «разрабатывать» год назад с 1с, а благодаря знакомству с oscript за последние полгода успел решить бизнес задачи на python и js, познакомишись с bootstrap, mvp, docker.
Никто не заметил тут пропаганду oscript, ага. Еще одна поделка сбоку к 1с, не поддерживаемая вендором. И бизнес 1с автор не знает и не понимает. Бизнес в том, чтобы создать массовый спрос на работу фирм партнёров, которым выгодно массово продавать клиентам коробки и лицензии и попутно — бесконечные обновления, доработки и «работу» недоученных специалистов, сменяющих друг дружку каждый день (ибо их легион). Клиентам, кроме траты денег, это не приносит ничего хорошего, но и альтернатив не много (и неспроста). Лишь бухгалтерия и ЗУП могут считаться относительно полезными решениями, помогающими бизнесу отчитываться перед государством. Все остальные решения и их перепиленные армиями одинесников вариации — создают лишь проблемы бизнесу, которые нужно постоянно решать, постоянно оплачивая труд радующихся такому положению вещей «недоучек». Это всегда намного дороже, чем профильные облачные решения и сервисы, покупаемые в аренду.
Еще одна поделка сбоку к 1с, не поддерживаемая вендором

Какой ужас. Сообщество разработчиков делает open source инструменты для автоматизации своей работы без участия вендора. Ни для одной платформы такого нет, только в богомерзкой 1С.

Клиентам, кроме траты денег, это не приносит ничего хорошего, но и альтернатив не много (и неспроста).… Это всегда намного дороже, чем профильные облачные решения и сервисы, покупаемые в аренду.

Угу. Так и есть. Хорошо для 1С, что кроме вас этого никто не понял, поэтому бизнес продолжает покорно платить 1С за то, что та им создает проблемы. Это ведь так типично для бизнеса — не считать свои деньги, да.
Ну теперь-то вы им глаза открыли, надеюсь?
Хорошо для 1С, что кроме вас этого никто не понял, поэтому бизнес продолжает покорно платить 1С за то, что та им создает проблемы

Конечно хорошо для 1С. Монополия всегда хороша для монополиста.
Как же монополия? Вон, смотрите и ls fusion есть, и ofBiz, и SAP, и Dynamics, и на C# вон кто-то сам себе написал решение. И все лучше чем 1С.
Просто бизнес он глупый. Продолжает есть кактус за свои деньги.

Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.

Как там у Гоголя?
«Год 2000 апреля 43 числа. <...>Теперь передо мною все открыто. Теперь я вижу все как на ладони. А прежде, я не понимаю, прежде все было передо мною в каком-то тумане.»
Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.


Как раз проблема именно в сложном законодательстве. В частности, в области бухгалтерского учета (неоправданная сложность) и начисления заработной платы (во многом из-за того, что налоги на зарплату платит организация, а не сотрудник, но и опять же ненужная сложность). Плюс нет стандартной, для всего мира, разделения на финансовые (Bil / Invoice) и товарные (Receipt / Shipment) документы, так как ТОРГ-12 в себе совмещает оба документа сразу.

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

О да, сложное законодательство только в РФ. В США, например, совсем простое. Наверное именно по этой причине многие производители ПО для бизнеса там даже ни не берутся самостоятельно посчитать, например, Sales Tax. Он всего навсего зависит от Штата, дня недели, месяца, времени суток, типа товара, наличия льгот, лиценщий, праздников и т.п.

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

Насколько помню в мире "белых людей" прайс производителей софта ExVAT то есть в прайсе не учитываются локальные налоги. Я считаю это правильно. По какой окончательной формуле будет показана для меня цена это вопрос к торговой площадке. Если производитель желает продать мне напрямую, то заморачиваются с платежной системой. НДС, доставка до меня и прочее.

Насколько помню в мире «белых людей» прайс производителей софта ExVAT то есть в прайсе не учитываются локальные налоги. Я считаю это правильно. По какой окончательной формуле будет показана для меня цена это вопрос к торговой площадке. Если производитель желает продать мне напрямую, то заморачиваются с платежной системой. НДС, доставка до меня и прочее.


Это вынуждено.
Если вы про ЕС — банально — там НДС очень разный в разных странах. Если про США, то там налог с продаж разный в разных местах.
В РФ в этом нет необходимости — ибо всё едино.
Загадка почему в Японии налог с продаж нужно самому добавлять, там вроде нет сложных исключений.
Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.

Как раз проблема именно в сложном законодательстве


Е-рун-да.

Как человек со всем этим работающий утверждаю.

На предприятиях зачастую:

торговая конфигурация 1С + бухгалтерская, между ними загрузка выгрузка.
или
производственная конфигурация 1С + бухгалтерская 1С, между ними загрузка выгрузка
или
другой вариант для оперативного управленческого учета + бухгалтерская 1С, между ними загрузка-выгрузка.

И т.п.

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

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

Чувствительной к законам является только бухгалтерская 1С. Да, та обновляется часто.

За последние 20 лет можно по пальцам одной руки пересчитать что именно пришлось сколько-нибудь серьезно изменять в производственной/торговой/оперучетных, чтобы привести к требованиям законодательства.

Онлайн-кассы, учет алкоголя. Корректировочные счета-фактуры — да и то не для всех, многие делают их в бухгалтерской 1С. Изменение транспортных документов, но это не такое уж и сложное изменение. И… да пожалуй все. Мелкие изменения форм документов, типа добавить ГТД в счет-фактуру — ну такого плана изменения еще раза 10 за 20 лет были критичны, но я не считаю это за серьезную проблему. На этом всё.

В львиной доле случаев достаточно просто регулярно обновлять бухгалтерскую свежими версиями от 1С.

К чему я это?

К тому, что обладая действительно классным продуктом вы вполне можете конкурировать с 1С — просто заняв нишу торговых/производственных/пр. предназначенных для оперативного учета.

А ведь, утверждаю из опыта, именно там и основные деньги. Если вещи нужны фирме как воздух. Это ее ежедневная деятельность. Это её конкурентное преимущество и пр. и пр.

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

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

Полностью с Вами согласен насчет относительной неважности бухгалтерского и фискального учета.

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

У них во всех решениях всегда три документа: Order / Invoice / Shipment. У них нормально, когда Вам поставляют товар в течение месяца без каких-либо документов с ценами. Вы их приходуете по какой-то условной цене из заказа. А потом вам выставляют на них счет (причем цена может не совпасть с ценой в заказе). В постсовке же вы не можете без финансового документа (например, ТОРГ-12 или ТТН, в котором есть цены) оприходовать товар.

И, например, вот это обстоятельство достаточно сильно влияет на логику процессов приемки и отгрузки. По этой причине тот же Odoo из коробки под РФ ну никак не подходит. Если конечно, не делать двойной ввод в 1С и иметь разную себестоимость в Odoo и 1C.
И, например, вот это обстоятельство достаточно сильно влияет на логику процессов приемки и отгрузки. По этой причине тот же Odoo из коробки под РФ ну никак не подходит. Если конечно, не делать двойной ввод в 1С и иметь разную себестоимость в Odoo и 1C.


Вы путаете отгрузку, где себестоимость не нужна и аналитику, где уже важна себестоимость.

Их можно считать сразу, а можно и не сразу — зависит от бизнес-требований.

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

Эта вещь не всегда связанная с отгрузкой.

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

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

Которые специалисту очевидны.
Вы не поняли меня. Чтобы было понятнее, ответьте мне на простой вопрос:

Могу ли я в РФ ЗАКОННО отгрузить покупателю товар без каких-либо документов, в которых указаны цены, а он в свою очередь принять его (в том числе и по бухгалтерскому учету)? Документы на оплату с ценами при этом ему выставить через месяц.

А в англосаксонских и европейских моделях учета — это в порядке вещей.
Могу ли я в РФ ЗАКОННО отгрузить покупателю товар без каких-либо документов, в которых указаны цены, а он в свою очередь принять его (в том числе и по бухгалтерскому учету)? Документы на оплату с ценами при этом ему выставить через месяц.


Это вообще не проблема софта и программиста.
Это проблема юриста и бухгалтера.

Знаю многих что так делают. С 1С.
Как это соответствует закону — не знаю.
Спросите лучше на форуме бухгалтеров.

По крайней мере под такой способ отгрузки никак доработать 1С не просят — значит, устраивает штатный механизм.

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

А в других странах — это стандартная схема. И поэтому там во многих местах другие процессы, под которые и заточены у них многие программы. По этой причине большинство из них не подходит для РФ из коробки и требует, как минимум, адаптации.
Так мне не надо спрашивать у бухгалтеров. У меня очень большой опыт в этой области. И ответ простой: незаконно. И понятно почему — кризис доверия между бизнесом и государством.


Ваш большой опыт не знает что такое договор ответственного хранения и агентский договор?

А в других странах — это стандартная схема. И поэтому там во многих местах другие процессы, под которые и заточены у них многие программы. По этой причине большинство из них не подходит для РФ из коробки и требует, как минимум, адаптации.


Разумеется, не подходит, если брать как полное комплексное решение всех задач.

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

Проблема скорее будет в печатных формах документов, если их изменение не предусмотрено в «импортном» решении.

Но не в самой сути учета.

уже потом отложенной реализации — вполне себе реализуема

Как она может быть реализуема, если незаконна?

Как Вы сделаете печатную форму документа в Odoo для Delivery Order, если там в документе цен нет вообще? Что Вы там напечатаете?

Ваш большой опыт не знает что такое договор ответственного хранения и агентский договор?

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


Как она может быть реализуема, если незаконна?

Как Вы сделаете печатную форму документа в Odoo для Delivery Order, если там в документе цен нет вообще? Что Вы там напечатаете?


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

Да и не только. Вы забываете, что отгрузка товара != переход прав собственности.

Обычно это так, да. Это и ввело вас в заблуждение.

То есть Вы предлагаете при внедрении Odoo со всеми покупателями заключать договора комиссий / ответственных хранений? Даже если им просто пачку бумаги продаете?
а потом вы за эту пачку выставляете цену равную в пропорции НДС уплаченному за квартал и требуете с государства возмещения ибо доверие между бизнесом и государством? Имхается мне за такие схемы в любом государстве будут ожидать проблемы.
Вопросы определения НДС и прибыли. Прибыль считается как разница выручки и затрат. Затраты >= себестоимость. Если себестоимость is null то Прибыль is null тоже, а это не тот ответ, который устроит ФНС в конце налогового периода. Схема с определением себестоимости и НДС входящего в конце налогового периода мысль конечно заманчивая, но см. п.1
Посмотрите вот эти ссылки:
https://www.odoo.com/documentation/user/13.0/inventory/management/reporting/valuation_methods_anglo_saxon.html
https://www.odoo.com/documentation/user/13.0/inventory/management/reporting/valuation_methods_continental.html

Там внизу примеры, когда цены в заказе (PO) отличаются от цен в накладной/счете(Invoice). И посмотрите, как у них вообще проводки разносятся по счетам, и какие там счета есть.

Например, как Вам такой классный счет, как:
23000 Goods Received Not Purchased

Какой его аналог в РФ (это именно не неоплаченные, а некупленные товары)?
некупленные, т.е. взятые на хранение? чем ответственное хранение не подходит, сейчас попробуй еще найти дурака который не через ответственное хранение работает, вплоть до самой покупки в рознице. Правда ЭДО с онлайн фискальниками скорее всего положит конец этой налогоуменьшающей практике или даст начало использованию ИИ в прогнозировании остатка собственного товара и продаж в ближней перспективе
Нет, именно с переходом права собственности, а не взятые на хранение. Но без документов на оплату (и в частности, без цен и сумм). Вы смотрели ссылки выше? Там же есть примеры.
Отгружайте на ответственное хранение по любым ценам с правом продажи. Отгружайте на комиссию, опять же указав цены по которым товар уйдет конечному потребителю, отражайте на забалансе суммы прихода плюс минус по рыночным ценам кого бы они там сильно волновали, как мне кажется проблема надумана.
Отгрузить можете.
Принять к складскому учету без цен можно, к бухгалтерскому — нельзя.
А вот в западном бухгалтерском учете — можно принять по цене из заказа. В этом и принципиальное различие (в том числе и в счетах).
UFO landed and left these words here
Я не знаю в чем проблема многих крутых программистов. А вот у вас явно трудности с сарказмом.

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

А теперь просто посмотрите на ситуацию глазами студента, которому нужно купить квартиру, т.к. после вечеринки студентка от него залетела и жениться — придется:
25 килорублей «стажер» на частичной занятости, пока диплом не получил. 60-80 килорублей — «помошник программиста 1С» на первый год после института. 150-200 килорублей с примерно третьего года после института до пенсии. Стабильно. Независимо от кризисов. Не надо каждый год осваивать новый фреймворк. Не надо шесть раз в год разбираться как в новомодной парадигме правильно делать 3-д эффекты при открытии формы ввода… Никаких нервотрепок, никаких авралов, при желании — все свободное время можно посвятить подработкам, которые дают хорошую «прибавку к пенсии», т.к. очень много мелких фирм, которые не могут себе позволить платить ежегодную мзду интегратору, но которым пару раз в год что-то надо в 1С подправить…
Я бы сам уже лет десять бы как подался бы в 1С, но лично у меня любое соприкосновение с финансами и бухгалтерией вызывает уверенность, что они должны быть запрещены как особо извращенные виды пыток. Но я был знаком с несколькими людьми, у которых подобная работа вызывает радость, экстаз и чувство глубокого удовлетворения.
Никаких нервотрепок, никаких авралов

Очень смешно))

т.к. очень много мелких фирм, которые не могут себе позволить платить ежегодную мзду интегратору, но которым пару раз в год что-то надо в 1С подправить…

Ну с такими обычно и проблем больше. Вам же они тоже не захотят платить

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

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

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

И да, еще важный момент, не надо путать бухгалтерию и программиста 1С. Программист 1С никак в подготовке отчетов не участвует и никакой ответственности за то, что бухгалтера опоздали или накосячили — не несет. Если вдруг программист накосячил так, что к отчетному периоду от него что-то кому-то нужно… Ну это нужно тщательно постараться. И уметь. И иметь опыт.

Очень смешно))

Ага. То, что у 1С-ника считается авралом, у ГИПа и ПМа на строительстве, например, ЦОДа называется «как здорово, что отпуск, и тебя никто не дергает!»
Я когда гиповал, «в отпуске» обычным делом было штук пять звонков в день с необходимостью принять решение, ошибка в каждом из которых (все ещё) может вылиться в пару лет отсидки…
UFO landed and left these words here
угумс, и начинаются авралы по НДФЛ, мы ж про «стандартный ЗУПе»?
Авралы по НДСу возникают вне зависимости от используемого ПО, хоть Бух хоть эксель, хотя конечно же, стандартный бух сам вбивает первичку, сам проверяет наличие документов, обзванивает поставщиков, подрядчиков и т.д. Авралы возникают по тысяче причин, среди которых далеко не последнее это резкое переобувание руководства при получении реальных цифр за период отчетности и желание с ними что то да сделать. И ПО тут пятым в очереди.
UFO landed and left these words here
Я бы сам уже лет десять бы как подался бы в 1С, но лично у меня любое соприкосновение с финансами и бухгалтерией вызывает уверенность, что они должны быть запрещены как особо извращенные виды пыток

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

А вот сопутствующие задачки (с финансами связанные косвенно) типа WMS | логистики | интеграций с удовольствием решаю. Так что там не все так плохо.

Иногда возникает вопрос: «а чего бы все это не делать на java», но один из ответов — внезапно, некоторые собственники не хотят решений не на 1С. Не потому что «1С это супер, ничего лучше нет», а потому что они на подсознательном уровне не хотят плодить зоопарк систем, т.к. чувствуют, что поддержку если что, им будет искать сложнее/дороже.
Плюс у некоторых есть негативный опыт с проваленными внедрениями и при этом позитивный при работе/внедрении 1С (это примерно как у некоторых комментаторов в этой статье, но с противоположным знаком).
Попервости тоже 1С-ом зарабатывал. Потом на С перешел и сейчас Java-Kotlin. На яве стрессов и дедлайнов хватате, но от работы во франче 1С у меня самые жуткие воспоминания остались в плане нервотрепок. Весь негатив (зачастую вполне заслуженный) по поводу 1С и фирмы которую ты представляешь — на тебя изливается. А народ, который пользуется услугами франча весьма… специфичный… за копейку удавятся и тебе весь мозг съедят, а от этих копеек твой доход напрямую зависит.
Когда ушел оттуда — мне обычная разработка показалась просто заповедником спокойствия и околонулевого стресса. Я уж лучше буду фреймворки каждый год изучать, тем более что мне это интереснее чем изучать очередные нововведения в бухучете.
Да и не нужно это так часто делать, тот-же спринг, например, один из основных используемых фреймворков на Яве, он вполне эволюционно развивается, новые важные изменения в нем не так часто происходят, что-бы их изучение как-то напрягало. А большинство хайповых тем вообще в IT, и изучать нет особого смысла — бабочки однодневки.
Ну опять же, «Работа с 1С != Работа во франче» и «Работа с 1С != Работа с бухгалтерией». Так-то да, франч это бизнес по продаже коробок + потогонка с простыми задачами за мелкий прайс, в большинстве своем. Но в какой-нибудь условной веб-студии будет плюс минус тоже самое.
Стоит только перейти к разработке условно-коробочного решения или проектным работам и появляется спокойствие, время на изучение и использование современных технологий (в т.ч. и не 1С) и т.д.

Я в сфере 1с проработал более 15 лет, и за это время деградация кадров шла по экспоненте. И завтра этот ваш студент будет конкурировать за поддержку 1с с бывшими дворниками, продавцами и другими специалистами широкого профиля. Поэтому да, ипотеку придется платить 25 лет.

Самое интересное, что автор этого поста и автор oscript — это одно и тоже лицо :)
Андрей, спасибо тебе за твою работу! Реально в одиночку сделал просто мега инструмент. Используем oscript для сборки и тестирования своего решения.
Теперь что касается: «бизнес 1с автор не знает и не понимает». Наоборот! Все достаточно точно и по делу. Бизнес сам решает платить вендору или партнёрам или нет. Верно? Если бизнес платит, значит его все устраивает и у него нет других альтернатив. Да, все далеко не идеально, но есть вещи, которые очень удобны. Помню, как в 2007 знакомился с 1С и был впечатлён в 1С 7.7 табличным документом и посекционным выводом в отчетах (до этого имел счастье работать с Fast Report в Delphi), а тут все было настолько просто и функционально, что я был просто шокирован.
Легионы недоучек, проблемы бизнесу решениями от 1С…
Суть в том, что за такие деньги других вменяемых альтернатив нет. И бизнес выбирает 1С за то, что есть уже готовые решения их проблем, которые можно довольно-таки легко подпилить. И есть масса специалистов, пусть даже недоучек и, кого вы там назвали…
Возьмите Java, вы даже недоучку с трудом найдёте, а готового решения для бизнеса российского вообще нет.
На самом деле все понимают, что 1С то подвинуть не сложно: сделайте аналогичные решения позволяющие автоматизировать учёт и отчётность. Да хотя бы отчётность автоматизируйте, а учёт, как показывает практика, всё равно, кто во что гаразд делает у себя. Однако, воз и поныне там. Ни кто напрягаться не хочет. Потому что это затратно на первоначальном этапе. Чтобы написать и выкатить в массы такой продукт и приучить бизнес к нему, нужно десятилетие. Мало кто может себе позволить 10 лет работать в убыток, чтобы потом получать какие-то крохи в конкуренции с «монополистом».
Монополии то нет у 1С. Ну, может быть тот факт что наше законодательство налоговое сильно извращено и постоянно меняется, и за это кто-то приплачивает — это может такое быть в нашей стране. Но в остально, ни кто не припятствует выйти на рынок и сразиться с 1С. Но желающих не возникает. Бизнес устраивает то, что есть.
Отдельно от лица недоучек вам отвечу. В станах python, java и проичих хватает также недоучек, которых берут, за неимением лучшего, или же по знакомству, и в довольно-таки крупных компаниях, даже государственного сектора процветает такой говнокод, за такие деньги высокие, что 1С'ники отдыхают, даже самые занюханные франчи. А, кстати, и про аутсорсеров от java тоже наслышан. Там тоже процветает схема, продавать за дорого стажоров, под видом крутых специалистов. А специалистов, только на презентациях показывают заказчикам, чтобы пыль в глаза бросить.

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

А может господин комментатор не знает и не понимает бизнес 1с? В 90-е и 00-е вендору было экономически выгодно развивать партнерскую сеть в целях экспансии. Но уже в конце 00-х началась политика покупки крупных партнеров.

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

А думаете франчам интересно быть просто «кузнецей кадров» для рынка и превращать за свой счет вчерашних студентов в завтрашних штатных сотрудников для своих же клиентов? Думаете выгодно вместо использования налаженного конвейера продаж вкалывать за каждую копейку?
UFO landed and left these words here
Да нет там лярдов, коллега. Узкая геморойноемкая специфика, на очень ограниченные, очень скупые и стагнирующие рынки, клиенты которых (их и так не сотни) после каждого скачка бакса сыпятся как осенние листья. Какой смысл вкладываться в долгую в падающий рынок с туманными перспективами масштабирования, жесточайшей зависимостью от вендора и вероятностью подсесть на реализации всех тех хотелок нашего правительства? Когда как мировой рынок все еще не окучен?
UFO landed and left these words here
Вообще, его довольно успешно «продали» 1С-никам как замену powershell — т.е. вроде и решаешь задачи вне 1С, а вроде как и на привычном языке пишешь.
В итоге на нем реализовали ряд решений из мира «взрослого DevOps и CI/CD», только с местным, так сказать, колоритом. Фактически — снизили порог входа для 1С-ников в мир современных технологий.
Редкая статья про 1с от 1сника с которой я согласен за исключением некоторых спорных пунктов но которые обсасывали во всех спорах по 10 раз и повторяться бессмысленно. Упомяну разве что пару мелочей
На сегодняшний день, хранение исходников 1С в git с привязкой коммитов к задачам в Jira, ревью в Crucible, накатка кнопкой из Дженкинса и отчеты Allure о тестировании кода в 1С и даже статический анализ в SonarQube — это уже далеко не новость, а, скорее, мейнстрим в компаниях где есть много разработки на 1С.

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

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

Как человек делавший (по крайней мере на то время 17-18 год) самый крупный проект на мобильной 1с для предприятия (магнит тогда 3к лицензий на мобильную платформу купил) — в этом пункте вы ну ооооочень лукавите. Во первых разработка рест апи и механизма синхронизации при больших объемах справочников, необходимости работы оффлайн и невозможности удобно собирать логи — та еще боль, а для среднестатистического 1сника и вовсе задача с которой он ни разу не сталкивался. Во вторых — все равно пришлось начинать вникать в нативную разработку чтобы реализовать рядом пару других приложений мобильных для общения с мобильной 1с чтобы удовлетворить требования. В третьих из за ограничений платформы мы вообще едва не попали на необходимость писать все на нативе с нуля поскольку 1с не проходила аудит безопасников магнита. Им нужна была довольно тесная интеграция приложения с мдм системой, шифрование базы и прочее, а все это возможно только через подключение SDK вендора к приложению. И внешней компонентой это не решалось ибо требовало именно что встроить очень крепко, прямо в платформенный код. Да, сейчас, когда я уже год только и занимаюсь нативной разработкой под андроид я бы это осилил, но боюсь это бы противоречило лицензионному соглашению с 1с, сделало бы практически невозможной обновление (ибо не факт что патч бинарника одной платформы подошел бы к другой) и заняло бы дофига времени. В итоге аудит мы прошли, но чисто административными методами, а бодания заняли примерно год.

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

Было бы классно послушать Ваш рассказ о реальном положении дел в мобиле для 1С и о том проекте

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

Тоже занимаюсь разработкой и поддержкой мобильного приложения на платформе 1С. Ничего не изменилось:)

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

Веселая была история, когда гугл плэй вывалил требование — теперь только x64 приложения! — а сборщик мобильных приложений умел только x32. Пришлось допиливать сборщик, а фирма 1С новый сборщик выкатила только спустя сколько-то месяцев.

Веселая была история, когда гугл плэй вывалил требование — теперь только x64 приложения!

Это зачем им?
Ведь полное еще 32-битный аппаратов.
C августа обязалово Google Play Store. К слову многие разработчики фрейморков озадачились заранее поддержкой 64х платформы ведройда и в июне\июле уже выкатили релизы сборщиков. Странно, если верить выше написанному, что 1С нет.
Так и камней еще предостаточно. Но… "каменный век закончился не потому, что закончились камни" (с)
Я занимался поддержкой мобильного приложения для супервайзеров в аэропорту. Бэк тоже 1С, синхронизация через web-сервисы. Мобильная платформа 1с не подходит для систем, критичных к производительности. Скорость работы низкая по сравнению с нативными приложениями, т.к. девайсы были не первой свежести со старым андроидом. Стабильность работы никакая, фоновая синхронизация из-за проблем со связью виснет, лечится только перезапуском приложения. Вылазили системные ошибки при синхронизации, вылечилось, правда обновлением версии мобильной платформы.Ну и ограниченная функциональность, пришлось разбираться во внутренностях андроид для решения проблем взаимодействия с другим приложением. Но зато быстрый прототип, это да.

Дешевле было (а на самом деле, бесплатно) просто в фигме прототипировать.

И еще — если к вам пришел наниматься 1С-ник, то 1С-ника можно смело ставить на должность лида аналитиков.

Похоже у кого-то скоро собеседование… </мысли в слух>

Нет, но я время от времени собеседую людей, в т.ч. не на 1С-ные позиции.

Редкой объективности статья про 1С. Впрочем, видя кем она написана — не удивительно. Респект.


Хочется добавить, что если очень нужно, брендировать интерфейс 1С теперь тоже умеет, просто это отдельная фича и не для всех.

Цвета перекрасить — вполне для всех. Стили в управляемом приложении стали доступны (с 8.3.13) и перекрасить приложение можно.

Перекрасить можно, но оно все равно будет узнаваемой 1С-кой. Иногда корп-дизайн это ключевой фактор для UI. А иногда наоборот — не имеет значения. Я лишь обозначил этот момент, чтобы было проще принимать решение.

Я ответил лишь на замечание, что перекрасить можно не всем.
А «стандартный» дизайн можно рассматривать и как «про»: практически любой новый пользователь ИС уже умеет этой системой пользоваться, так и «контра»: нельзя сделать то, что очень хочетсянужно в данном конкретном месте ИС.
Опят показывает, что в обсуждениях про 1С никогда не удаётся поставить точку )
Скоро все закончится. Сейчас тренд — облачные решения и сервисы, работа с большими данными, микросервисы и т.п. В этих сферах 1с пролетает мимо и с большим свистом. Архитектура микросервисов позволяет взять и переписать любой сервис на НОВОЙ технологии, если она появилась, на ЛЮБОМ языке или фреймворке, если он лучше старого. Это избавляет от ловушек легаси, в которой застряла 1с и скоро просто утонет после того, как появятся государственные облачные сервисы, решающие задачи с учетом и отчетностью. Непонимание этой тенденции не оставляет в покое многих пытаться безуспешно выходить с технологиями прошлого века на международные рынки и тягаться там на поле с местными мастодонтами. Это глупо, как и глупо пытаться искать программистов 1с в среду, где зарабатывают на консалтинге и продажах коробок/лицензий.
Да, но два нюанса.
Первый — для того, чтобы клиент (маленькая шаражка на 10 человек) ощутила от этого выгоды — она должна быть клиентом SaaS сервиса (в котором внутри и отказоустойчивость, и микросервисы и все-все-все), но тут внезапно выясняется, что, во-первых, Ваши данные — не Ваши (они в облаке и принадлежат ему), а, во-вторых, если Вам очень нужна какая-то функциональность, то ее могут реализовывать годами, ибо Вы — не в приоритете. В случае НОРМАЛЬНЫХ SaaS (типа Slack) это решается богатым АПИ, которое клиент может использовать и тягать любые данные к себе. И наоборот.
Второй момент — получается, все эти микросервисы и прочее могут позволить только большие клиенты, т.к. у них есть возможность отстегивать за это кучу денег. Это реально дорого. Сложность программного обеспечения перемещается из одного уровня (в монолите вся сложность где-то внутри) на уровень связи между всеми этими микросервисами. С одной стороны, это позволяет быть просто супер-гибкими (действительно -не нравится микросервис — взяли, выкинули, внедрили новый). С другой — шаурмячная себе это позволить в принципе не сможет, но это ей и не нужно.

> как появятся государственные облачные сервисы, решающие задачи с учетом и отчетностью.

Это вообще мечта всех, наверное… Чтобы были качественные облачные гос. сервисы… экономящие деньги и силы граждан и других клиентов.
Не совсем так. Облачные решения — это сфера еще более массовая, чем тот сегмент рынка, что сейчас есть у 1с. И решения делаются еще более приспособленными для массоаого пользователя. И по цене в том числе. А от государства они будут еще и бесплатными.
шаурмячная себе это позволить в принципе не сможет, но это ей и не нужно

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

А если серьезно, то как раз в мелким клиентам всякие «1С:Fresh», «МойСклад» и т.д. легче заходят. Без всякой доработки. Такой парадокс, что те кто может себе позволить платить деньги за доработку SAAS решения, предпочитает сервер держать поближе к себе (ну или в каком-нибудь надежном далеком датацентре, но на своем выделенном сервере).

Спасибо! Отличный обзор! Очень посмеялся, очень хорошо написано, жизненно.


конструкции finally У меня есть гипотеза, что эта конструкция отсутствует из-за того, что не подобрали удачного перевода ее на русский язык :)

можно было сделать


ПОПРОБУЙ
  здесь_код
ИСКЛ
  обработка_ошибок
НАКОНЕЦ
  обработка_finally

видимо, выглядит некрасиво


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

не хватает сравнения с "великим и ужасным" SAP.

Лучше так: :)

ПОПРОБУЕМ
  здесь_код
НЕВЫШЛО
  обработка_ошибок
ИВСЁТАКИ
  обработка_finally

Есть ещё слова "эпилог", "финал" (или "финиш"), "исход", так же по смыслу может подойти слово "однако".

конструкции finally У меня есть гипотеза, что эта конструкция отсутствует из-за того, что не подобрали удачного перевода ее на русский язык :)
В конце концов,

Пока читал, в голове вертелось "ПОЛЮБОМУ", что соответствует целевому смыслу применения, а не подстрочнику. Ну или "ОБЯЗАТЕЛЬНО". Предложенные выше варианты, мне кажется, этому критерию не соответствуют, кроме разве что "финиша".

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

Только почему-то все забывают цену "впрыжка" туда....

И то что есть цена выпрыгивания обратно, микросервисы — не панацея вообще ни разу
я кстати думал об этом. это не невозможно. над CI/CD нужно будет конечно поработать, плюс нужна совершенно иная система обмена данными (на нормальных технологиях и отличных от текущих принципах), плюс облачную интеграцию закостылить (сквозная авторизация, балансировка и пр), но в целом, думаю, я смог бы запилить систему с нормальным откликом. Другое дело — кто готов вывалить мешок денег за это? ))
UFO landed and left these words here

А много ли в мире учётных систем на микросервисах? Ну то есть не чтоб мелочёвка сбоку, а чтобы прямо главную книгу банка или что-то подобное на микросервисах?

А 1С предназначена исключительно для "главной книги банка"?


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


Аргумент "НЕ НУЖНО" выглядит по меньшей мере странно.

Не совсем монолит, но в силу изначального рождения как продукт исключительно для учёта, дальнейшие "мутации" не могли ослабить доминанту. 1С это очень хорошее решение для учета. В первую очередь для учета в торговли в РФ. Это было заложено в продукт "с рождения".
В силу этой генетической особенности решения, игрища с разными подходами к эволюционному развитию мало применимы и вредны. 1С это не нужно от слова совсем.


Даже отдельные разработки которые велись в стране не на базе 1С, но могли интегрироватся не могли улучшить ситуацию. Отдельные разрабатываемые модули "взлетели" и даже есть удачные примеры внедрения, но массового интереса к этим продуктам нет, и не планируется быть массовым.
Аналогично с Дамгаардом. Решение было с рождения приспособлено для учета и планирования на производственно-сбытовых предриятиях.

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


На самом деле, нет.

Проблема, безусловно, касается монстроидальной УПП, но УПП уже почила в бозе (более развиваться не будет, только поддержка).

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

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

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

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

«сел и сразу поехал» это принципиальный момент.

Посчитайте стоимость серверного железа и лицензий на серверное ПО (1С, MS, MS SQL) при нагрузке хотя бы в 100 человек online. Чтобы на типовом решении «сесть и сразу поехать» нужен очень большой бюджет. И становится весьма спорно, а перевешивают ли плюсы минусы.

Ну серверное железо в любом случае нужно, независимо от стека технологий. Без сервера не заработает. Железо на "100 человек онлайн" нужно весьма скромное. Лицензии да, нужны, но тут какое дело — если надо 100 человек но нет денег на лицензии, значит не нужно 100 человек. Обычно, если решение делается под сотни пользователей — покупаются ключи по 500 и бюджет особо не смущает. А когда нет денег на сотку, то скорее всего, конторка слабовата, хоть и хочет себе "большой" сервер.

Если вам продали клиентские лицензии по 500 рублей, вас, я извиняюсь, обманули. Ну и, соответственно, вся дальнейшая математика неверна.
Железо на «100 человек онлайн» нужно весьма скромное
Это либо у нас разные представление о скромности, либо вас обманули дважды.
«по 500» это не «по 500 рублей», а «комплект лицензий по 500 штук».
Ну так и пишите, а то не совсем понятно. Там выгода получается: 3552 руб. против 6300 руб. Так понятнее было бы всем.
Железо на «100 человек онлайн» нужно весьма скромное


Это либо у нас разные представление о скромности, либо вас обманули дважды.


Зарплата, налоги, офис на 100 человек — это порядка 10 000 000 рублей ежемесячно из расчета средней 50 000 зарплаты на человека.

И что по сравнению с 10 000 000 рублей ежемесячных трат вы считаете дорогим в вопросе одноразовых трат на покупку сервера?

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


Затраты в 10 млн. рублей в месяц на 100 сотрудников, на запрату, налоги, офис — даже заниженные.

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


Я этими разработками занимаюсь профессионально уже очень много лет.
Нет ничего страшного.

Главное:

По сравнению с 100% разработкой под себя — доработка типового решения это тьфу, копейки. Ну и времени куда как меньше. И результат гарантированее.

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

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

Разумеется.
Бизнес не стал бы платить, если ли бы для него это были действительно существенные деньги.

Фокус в том, что «для предприятия копейки, а для человека очень даже дофига».

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


Не вижу никакой неразрешимой проблемы.

Есть только одна-единственная сложность: всё дело только в том, что за человек занимается принятием решений — где брать типовую, а где пилить своё.

Какова квалификация этого конкретного человека и каковы конкретные требования бизнеса.
доработка типового решения это тьфу, копейки

В корне неверное мнение, покупка коробки — это да, тьфу копейки. Но на этом только все начинается. Я знаю очень много заваленных примеров внедрения решений 1С, тут можно назвать и УТ, и УПП, и ERP, местами даже ЗУП умудряются завалить. Вот в чем проблема.
В корне неверное мнение, покупка коробки — это да, тьфу копейки. Но на этом только все начинается. Я знаю очень много заваленных примеров внедрения решений 1С, тут можно назвать и УТ, и УПП, и ERP, местами даже ЗУП умудряются завалить. Вот в чем проблема.


Я этим занимаюсь профессионально очень много лет. Видел и удачные внедрения без каких-либо доработок вовсе. Видел и переписанные с нуля.

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

Потом, возможно, будут еще доработки. Но для начала эксплуатации множество доработок при внедрении — не типичная ситуация.

Не означает, конечно, что описанной вами ситуации нет в принципе. Отчего же — есть. Но нечасто.

Я эти ситуации в своей карьере хорошо помню, так как это хорошие деньги мне лично. К сожалению они не типичны, не часты.
UFO landed and left these words here
Посчитайте стоимость серверного железа и лицензий на серверное ПО (1С, MS, MS SQL) при нагрузке хотя бы в 100 человек online. Чтобы на типовом решении «сесть и сразу поехать» нужен очень большой бюджет. И становится весьма спорно, а перевешивают ли плюсы минусы.


1) Почему MS-SQL, а не бесплатный PostgreSQL, с которым 1С уже много лет умеет работать?

2) Давайте посчитаем на 100 человек ежемесячный бюджет. Зарплата + налоги + физические рабочие места. При зарплате в 50 000 рублей в месяц — это около 10 000 000 рублей расходов в месяц. Ежемесячно. Что на этом фоне разовая стоимость внедрения (последующая тех. поддержка уже значительно дешевле чем первичное внедрение)?

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

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

И становится весьма спорно, а перевешивают ли плюсы минусы.


Фирму интересуют не столько деньги, сколько сроки. Ибо не успел — и потерял кучу потенциальной прибыли.

«Сел и поехал» VS «Разрабатывать своё в течение пары лет» (с рисками что не получится, что специалист уйдет)?

Бизнес уже дал ответ на это.

Лет 20 назад не пилил своё только ленивый. Сейчас — типично как раз что подавляющее большинство сидит на готовых решениях (в большинстве это 1С: Предприятие).

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

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

Уникальные не типовые куски проекта делают у меня только отдельные специфические задачи, только те, где они заведомо на порядки выгоднее типовых решений.
Почему MS-SQL, а не бесплатный PostgreSQL, с которым 1С уже много лет умеет работать?

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

Да ладно! Господин Дорошкевич, если вы нас слышите, не могли бы вы набросать зачетных примеров внедрения на постгресах?

Сомневаюсь, что он что-то толковое ответит… Франчи обычно работают по принципу — выставил клиенту побольше заоблачных часов и свалил поскорее и подальше, пока тот не опомнился. А разгребать будут совсем другие ребята.
Если вы думаете, что PostgreSQL — это серебряная пуля, поздравляю, вы молоды и только в начале пути.

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

А есть толковые мануалы для людей уровня сисадмина — как тюнить Postgress для 1С? Сталкивались с тем, что на Postgress проблемы с производительностью, переходишь на MS SQL — проблемы уходят.

У нас нет опыта тюнинга Postgress, рекомендуем приобретать MS SQL. Клиент приобретает.

Возможно, это неправильно, но клиенту надо работать здесь и сейчас, он не будет ждать, пока мы найдем причину тормозов в связке Postgress + 1С, а MS SQL вполне отработан.

Толковые мануалы — мануалы по постгресу и иногда ради любопытства заглядывание в планы запросов. Обычно все решаемо. Запросы очень часто могут работать на разных СУБД с разной скоростью, это норма. Вполне себе бывают запросы, которые ложатся на MS, но работают на PG. Кроме того, для нагруженных 1С существует коммерческая версия PostgresPro, которая по бенчмаркам уделывает коммерческий же MS SQL (но я ее не щупал).


он не будет ждать, пока мы найдем причину тормозов в связке Postgress + 1С, а MS SQL вполне отработан.

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

Открою вам пару секретов:
1) Тюнингом параметров всех проблем производительности не решить. Бенчмарки дело хорошее, но если бы всё было так просто, никто бы и не смотрел в сторону MS SQL.
2) Цена коммерческой версии PostgresPro сопоставима с ценой MS SQL, политика лицензирования также похожа (есть варианты на ядра, есть на пользователей). Думаю, очевидно, почему так.

Хм… тюнингом не решить, переписыванием запросов не решить, а чем решить?

В прошлом холиваре один внедренец предлагал сначала реорганизовать бизнес-процесс клиента, а только потом лезть в оптимизацию.

В зависимости от степени неадекватности существующих процессов у клиента это может быть и не самый плохой путь.

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

P.S. вот пока писал, вспомнил, что на одном из мест работы похожим образом была организована работа фин. отдела, потому что много лет назад обмен между ИС запускали вручну. и пару раз в день («так исторически сложилось»). Меняли процесс в обратную сторону — запустили регулярный автоматический обмен, но так и не нашли понимания у привыкших к старому режиму финансистов, даже просили «вернуть как было».
У того комментатора посыл был в том что если запросы тяжелые или их нужно делать часто — значит нужно менять бизнес процессы чтобы их не было. Всегда. А оптимизировать запросы бессмысленно и неправильно поскольку на его взгляд разрабатывать качественную с технической точки зрения систему дорого и долго. Нужно брать коробку и подгонять бизнес процессы к ней. Если бизнес процессы не укладываются в коробки — значит они неправильны.
Ну, если заменить «всегда нужно» на «возможно нужно», то мнение имеет право на жизнь.

Так делает сап, это их прямо методичка: наши процессы выверены и непогрешимы, если у нас чего то нет — вам это не нужно. Ну а то, что склад называется "завод" это надо просто принять и поверить. С вас $2 млн

UFO landed and left these words here

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

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

Не забывайте за развивающуюся тематику "импортозамещения". Все госы в ближайшее время уйдут с MS, а это — огромные бабки для 1С. Поэтому взаимодействие типовых решений с PG тоже будет развиваться, нет сомнений

Сомнений может и нет, но в типовых как будет? Если MSSQL, то такой запрос, а иначе вот такой? Там и так жесть творится, когда строка запроса «собирается» из кучи мест, а будет еще жестче?

Ну прям очень странно так говорить.
Открываешь справочник внедренных решений, содержащий отчеты от фирм партнеров и смотришь.


Любому клиенту или внедренцу можно позвонить и спросить действительно ли это так.


http://1c.ru/rus/partners/solutions/search.jsp?q=&Version=8&workingMode=2&dbServer=2&small=&big=&smallDbConns=&bigDbConns=&smallThinClientConns=&bigThinClientConns=&smallWebClientConns=&bigWebClientConns=&labelgeo_id=&geo_id=&DateSince=&DateTill=&isArchive=1&showParams=0

А что тут странного. Приведите пример УТ, ERP, БУ, где 100+ рабочих мест на PostgerSQL. Ну есть ДО 300 рабочих на PostgreSQL 1c.ru/rus/partners/solutions/solution.jsp?SolutionID=968986. Но это документооборот всего лишь. Сравнение вообще ни о чем, не та интенсивность работы, ни тот функционал.

Мне известно внедрение в одном федеральном министерстве на 1000+ пользователей на постгрес.

Ооо… Слова красивые, но покажите цифры.
Что за конфигурация, сколько документов одного вида, какая интенсивность работы док/час. И главное, бюджет…
Вы думали, какого-то впечатлили фразой «в одном федеральном министерстве»…

Есть такое слово — коммерческая тайна. Иногда лучше помолчать, уж извините. Не верите — я переживу.

Мы сейчас используем PostgeSQL в нашем облаке на типовых отраслевых 1С конфигурациях. На нодах от 100 до 300 активных пользователей. Работает отлично.

Вот вы говорите, что при ежемесячных тратах бизнеса 10 000 000 на 100 человек, цена закупки это копейки. Это справедливо для небольшого количества фирм с бешенной маржинальностью. У большинства, при расходах в 10 000 000 рублей в месяц, реальная прибыль максимум 10% в наличном эквиваленте. А теперь еще возьмите во внимание то, что это для сотрудников деньги какой-то «фирмы». Для собственника, который принимает решение о затратах, это прямой убыток из кармана. Причем прям ровно на сумму затрат. А теперь подумайте, что таких разовых закупок как закупка серверов, каждый месяц хватает. После этого вы поймете почему в подавляющем количестве фирм, которые не живут на гос датациях, закупка всякого «важнейшего» с точки зрения айтишников, железа — это не копейки.

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

Там в картинке много смыслов, в том числе и такой, как вы сказали. Еще на картинке не виден момент добавления тролля на чашку. А ну как она резко пойдет вниз? :)

Спасибо автору, после такой статьи, можно перестать скрывать что пишешь на русском )
Всем добрый день, я Денис и я программирую на 1С с 2007 года
*Вялые аплодисменты и вздохи сочувствия
угу. т.е. 1Сники, по вашей логике, должны совершить каминг-аут? вы на чьей стороне??? )))

На стороне 1С-ников, безусловно. :) На дворе 2019 год и делать каминг-ауты модно и почетно. Никаких "вздохов сочуствия", только всеобщее одобрение и восторги :trollface:

А ещё мы должны требовать, чтобы во всех фильмах про хакеров в команде присутствовал как минимум один 1С-ник!
Если бы проблемой языка была русскоязычность… Автор как раз вполне верно описал минусы языка. Вот без шуток — из современных языков вижу наиболее подходящим для платформы дарт. Многопоточности нет, есть изоляты работающие по модели акторов и встраивающиеся в механизм асинхронности через async/await. Типизация по умолчанию статическая, но есть простенький вывод типов позволяющий меньше кода писать. Причем работает не только для переменных но и для параметров функций. Также есть тип dynamic для совсем маргинальных случаев. Очень удобные методы работы с коллекциями
например collection if/for вообще до того ни в каких языках не видел
Dart 2.3 also introduced collection if and collection for, which you can use to build collections using conditionals (if) and repetition (for).

Here’s an example of using collection if to create a list with three or four items in it:

var nav = [
'Home',
'Furniture',
'Plants',
if (promoActive) 'Outlet'
];


Here’s an example of using collection for to manipulate the items of a list before adding them to another list:

var listOfInts = [1, 2, 3];
var listOfStrings = [
'#0',
for (var i in listOfInts) '#$i'
];
assert(listOfStrings[1] == '#1');


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

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

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

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

Как минимум вики-чан и stackoverflow с вами не согласны.
wiki
In computer programming, an anonymous function (function literal, lambda abstraction, or lambda expression) is a function definition that is not bound to an identifier. — условия о замыкании нет.

SO
A lambda is just an anonymous function — a function defined with no name. — аналогично.

Я перед каментом почитал википедию: "Применяется как правило для объявления анонимных функций по месту их использования, и обычно допускает замыкание на лексический контекст, в котором это выражение использовано." Это определение совпадает с тем, как я себе понимал отличия собственно лямбда-функций от просто функций, как объектов первого класса. Я, конечно, могу ошибаться, но и в достоверности камента на stackoverflow тоже позволю себе усомниться.

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

Окей, тогда я поясню мысль: функции первого порядка в 1С нужны. Замыкания — не уверен.

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

Вам нагуглить классический пример с лямбдой и циклом for по замыкаемой переменной?

ОбработкаОповещения + ДополнительныеПараметры.
В php решено конструкцией use, в js — доступностью всего контекста. Или как это правильно написать?
Да ну, в 1с (как и в общем случае в обычной бизнес-логике) половина кода — это унылое перекладывание данных в коллекциях в циклах. Лямбды и мапы типа laravel collections сделали бы это занятие гораздо приятнее и веселее.
Вторая половина — это запросы, и аналог linq to sql тоже очень бы пригодился. Причем 1с вроде бы тоже так думает и даже что-то сделала, но настолько неудобное, что этим никто не пользуется.
UFO landed and left these words here
Вот только 1с в последнее время позиционирует себя отнюдь не как система для ларьков. В том и дело.
И нет, студенту с тем же дартом или питоном разобраться не сложнее чем с язком 1с, а преимущества они дают значимые. Хотя конечно более заметные только при разработке конфигураций с нуля или создании больших подсистем новых. И поддержке с рефакторингом созданного.
UFO landed and left these words here
Я если что говорю о замене встроенного языка 1с с сохранением всей 1сной инфраструктуры и стандартных конфигураций. Т.е. тот же ЗУП на платформе 1с но вместо встроенного языка дарт или питон. А не о написании прикладных решений с нуля для замены ЗУП того же.
UFO landed and left these words here
Ну питон не самый лучший вариант. Дарт больше бы подошел. А дают эти языки более выразительные средства для построения абстракций которые нужны при больших доработках/разработках систем с нуля, а так же упрощают сопровождение и рефакторинг.
Говорю вам как человек перешедший с 1с на котлин — работа очень облегчается за счет отличной инструментальной поддержки, а средства построения абстракций позволили бы например для каждой конфигурации делать свой DSL, для конкретной предметной области конфигурации. Ну правда простые средства для построения DSL это к дарту и питону относится меньше чем к котлину, тем не менее котлин и посложнее в освоении чем язык 1с, а вот дарт и питон освоить ни разу не труднее, и любой кто освоил 1с смог бы и их с тем же успехом освоить. Тот же питон используют часто вообще не программисты, а как раз специалисты в своей области. Биологи, экономисты и прочие для анализа данных.
UFO landed and left these words here
Все просто объясняется, ни разу не тем что язык 1с такой хороший, во время создания 1с их язык был по тем меркам более менее современным, да и задачи они гораздо проще решали чем сейчас, потому они очень хорошо зашли на рынок СНГ плюс они удачно организовали бизнес модель с франчайзингом и теперь за счет этого имеют массовость и запас капитала (человеческого и финансового) на противостояние конкурентам, что конкуренты тоже понимают.
С тех пор языки эволюционировали очень сильно, в отличие от языка 1с, но бодаться с 1с на рынке СНГ за мелкие фирмочки разрабам на этих языках очень сложно за счет того что потребуется просто огромное количество трудозатрат на разработку похожего фреймворка с нуля, нескольких прикладных решений на нем, а так же просто гигантские затраты на маркетинг, завоевание доверия клиентов которые выбирают пусть менее удачные но проверенные временем решения, и создание сети разработчиков подготовленных для работы с этим фреймворком.
В общем успех 1с на рынке СНГ объясняется отнюдь не технологическим превосходством (под которым я понимаю в т.ч. удобство разработки и поддержки решений).
И нет, если бы сложность разработки не зависела от языка — мы бы так до сих пор и писали на C/asm/алголе и прочих динозаврах.
UFO landed and left these words here
Я тоже вас не понимаю. У вас какое то искаженное представление о мире по моим ощущениям. В котором вы считаете что 1с захватило дорогие рынки. При том что наиболее денежный ентерпрайз сидит на C#/java/scala/etc. Наиболее опытные разработчики и ИТ компании вовсе на рынок СНГ не смотрят. Зачем, если работать на забугорье выгоднее.
А захватывать дешевые рынки с малыми фирмочками не очень выгодно, а потребует в СНГ дофига затрат. Кроме 1с никому это особо не нужно. Невелика потеря.
UFO landed and left these words here
Почему, по прошествии стольких лет, остальные системы так и не переключились на бизнес.

Если вы чего-то не видите, это не означает что чего-то нет.
Проекты вроде сбора данных из различных систем крайне трудно сделать типовым решением, чтобы тиражировать как 1С. Они всегда на заказ, под ключ и зачастую под NDA. Потому что системы бывают весьма разнообразными и важными для бизнеса.
То, что имеет маркетинговое имя и продвигается в медиа — это кубики для сборки продукта. Например для запуска по расписанию вроде Apache Airflow, для мониторинга ELK, для обработки вроде Apache Spark или компоненты для хранения вроде того же Hadoop.

UFO landed and left these words here
Извините заранее, немного вклинюсь в ваше диалог.

> Не понимаю. Честно
Хм… Я вот вижу противоречие. Чуть выше пытаться доказать, что 1С полностью захватил нишу, а потом удивляться, почему в неё не лезут другие. Так все просто. Рынок занят и для откусывания от него куска нужно вложить большем, чем этот рынок способен дать.
Друзья и коллеги, в последнее время на Хабре участились статьи с хейтом в адрес 1С, как платформы для разработки, и выступлениями ее защитников. Эти статьи обозначили одну серьезную проблему


Эти статьи обозначили известность, распространенность и популярность продукта 1С: Предприятие.

Из чего последовало: а почему бы не попиариться за счет хейта такого продукта?
Ровно то же происходило и с MS, когда положение MS было не поколебимо на рынке ОС. Не пинал MS только ленивый.

Ну банально: сколько я соберу комментов/лайков под статьёй про какую-нибудь MyCRM (название выдумано)? 1-2-5?
А стоит написать про 1С, да обкакать покрасивше — так я только для начала заполучу сходу десятки комментариев от тех, кто 1С действительно знает и способен объективно мне возражать. Так и тех, кто не в теме и просто пришёл поесть попкорна понаблюдать за срачем. Гарантировано.
Если человек хорошо представляет о чем говорит, то почему бы ему про это не написать? Грамотная и годная техническая статья.
Я вообще за большее количество статей от людей с большим опытом, а не от "двадцатитрехлетних синьеров" пишухих очередную CMS/убийцу_гугла/фрейворк.
Если человек хорошо представляет о чем говорит, то почему бы ему про это не написать? Грамотная и годная техническая статья.


Да, конкретно этот человек — представляет то, о чем он пишет.

Я про другие статьи.
Например:

О сравнении специализированного решения 1С с языками программирования общего назначения.

Тем безусловно, будет понятная большинству Хабра, что пишет именно на языках общего назначения. Им будет приятно почувствовать превосходство своего инструментам по решению любых задач.

В этих статьях почему-то не пишется о том, что типовая задача «БД + форма ввода данных» полноценно решается в 1С за 10 секунд (буквально, без преувеличения). Наверное, потому что в языках общего назначения это решается за в десятки раз большее время в самом оптимистичном случае? И хайпа на такой статье не словишь — ведь ты покажешь не плюсы, а минусы языков, на которых пишет большая часть Хабра?
Я про другие статьи.
Например:

Можно конкретный пример, со ссылкой на статью?
Я про другие статьи.

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


Бездумная ура-риторика типа «MS говно делает, даешь Linux, он заведомо хорош просто потому что бесплатен и открыт и наплевать на корявый графический интерфейс Linux»? Я про такое.

Ругают MS только потому что она на верху пищевой цепочки.
Альтернативы уступают по универсальности Винде, умеют значительно меньше, но при этом все равно содержат огромное количество косяков.

Только крайне узкоспециализированные, ограниченные решения (типа голой командной строки Linux, без GUI) не конкурируют с Windows по количеству косяков.

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


Вопрос как ругать.
Вот статья автора вполне себе объективна.

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

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

Запросто это делается.

И еще — если к вам пришел наниматься 1С-ник, то 1С-ника можно смело ставить на должность лида аналитиков.

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

Кроме того, вы ка кто элегантно обошли тот факт, что 1с использует СУБД как тупую хранилку.
Забыли упомянуть про фантастический оверхед выборок.
А как весело 1с обращается с тем же pg, это просто нечто: когда я увидел lock на information_schema да еще с таймаутом в 5 минут, мне хотелось убивать.

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

Если учесть контекст "(и потом «ой, а почему у нас дырки»)", то задача
сквозной нумератор сущностей, с разрезом уникальности по некоторому набору ключей, префиксацией, так чтобы это не блокировало базу при параллельном вводе данных.

становиться сложнее.

Окей. Отмасштабируйте решение на 4 движка СУБД и добавьте периодичность нумерации по ключам "Год/месяц/день", "Вид сущности" и возможность указания произвольного префикса в начале генерируемого номера.

Про движки ответ у меня простой: любой каприз за ваши деньги. Oracle/MSSQL/PostgreSQL имеют схожий функционал, я думаю разобраться можно.

create table my_precious_docs(
   id serial,
   doc_number varchar not null,
   doc_year char(4) not null default to_char(current_date, 'YYYY'),
   doc_sum decimal(18,2) not null default 0,
   primary key(id),
   unique(doc_year,doc_number)
);

create or replace function id_for_year() returns trigger
   language plpgsql AS
$$
declare
   seqname text := 'seq_' || new.doc_year;
   prefix char(1) := 'Н'; -- можно и в справочник
begin
   if seqname is not null then
      execute 'create sequence if not exists ' || seqname;
      execute 'select $1||nextval($2)' into new.doc_number using prefix,seqname::regclass;
   end if;

   return new;
end;$$;


create trigger id_for_year before insert on my_precious_docs for each row
   execute procedure id_for_year();


Как видите, ВСЕ ваши требования сейчас реализованы. Хотя вроде «Вид сущности» пропустил, но тут надо описание сути, понимаете же, мне ничего не стоит еще конкатенацию добавить.
В соединение1 выполнили insert. Выполнился инкремент sequence. В соединении2 происходил такой же процесс. Они выполнялись транзакционно (допустим на уровне serializable). Соединение1 долго тупило и в итоге получили rollback. Вопросы:
1) возникла ли при этом блокировка?
2) возникла ли при это дыра в сквозной нумерации?
>Отмасштабируйте решение на 4 движка СУБД и добавьте периодичность нумерации

ANSI SQL вам в помощъ.

Но зачем такое в трезвом уме и памяти?
Это такое извращенное видение мира одноэсника?
Делает так, потому что может?
UFO landed and left these words here
>Так вот когда 1Сник не задумывается про СУБД, разработка получается быстрой и качественной.

Разработка быстрая, продукт на практике так себе. Но для ларьков сойдет.
Как правило, «1Сник не задумывается».
UFO landed and left these words here
Он не решает задачу «без дырок» в условиях конкурентного доступа и минимизации блокирования.
Тогда в примере выше ставим default для doc number а тригер переделываем под after insert

Усложним задачу: нужна сквозная нумерация на несколько таблиц, например счета-фактуры и счета-фактуры на аванс — это разные сущности, хранящиеся в разных таблицах с разной структурой данных, которые должны иметь общий нумератор.

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

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

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

Имя, сестра, имя даешь статью "как правильно сделать энумератор с заданными условиями". И посмотрим.

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

Если выдадите списочком условия то вполне можно подумать, даже с плюсами и минусами подходов.

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

Обычная рядовая задача. С моей точки зрения я ее решил 8 коментариев назад.

Зы вы кстати этой «отпиской» уклонились от ответа на сотальные доводы)

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

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

Нет, не решил:


  • after insert — это не тоже самое, что before commit. Между after insert и commit есть промежуток времени, в который может прилететь rollback.
  • если используете честный before commit, то не можете в одной транзакции вставить связанные документы. Не знаю, правда, нужно ли это в контексте 1С и подобных систем.
Сиквенс вы можете использовать в разных таблицах.
Второй вариант:

create table documents(
document_id serial not null
)

create table orders(
order_specific field varchar
)
inherits documents

Прямо-таки запросто? Ну-ка ну-ка? Слабо оформить в виде туториала на Хабре или хотя бы основную идею здесь в каменте пояснить?

Это отписка, а не путь решения. Вопрос был — сможете ли вы написать более развернутое решение/описание идеи в виде статьи, с возможностью критики сообществом Хабра. Попробуйте и увидите, что sequence не подойдет.

В виде статьи точно нет, у меня просто нет времени пока. А решение вон сверху, критикуйте

UPD я вообще очень плохо пишу абстрактные вещи, вот если бы полностью вы написали что и почему, тогда интересней)
Ну например я ничего плохого в дырках не вижу
Ну например я ничего плохого в дырках не вижу

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

Не знаю, как сейчас, но несколько лет назад законодательство требовало, чтобы нумерация счетов-фактур была последовательной и без пропусков. А это уже из области внешних требований (на которые нельзя влиять).
Никогда такого не было. Она должна быть возрастающей. Но про отсутствие пропусков речи не было. Свое положение о нумерации выпускаем и вуаля. У нас так идет: ГГГГММДДННН
Выше уже сказали, что я не прав. Возможно, это наведенное воспоминание.
Ну например я ничего плохого в дырках не вижу
Зато это хорошо видит налоговая, которая придет в компанию с вопросом, куда делить документы между номерами и почему их нет в декларации!
Внесу финальных пять копеек.
На технарям конечно кажется, что «ну чего страшного, ну дырка и дырка». Но взгляните на это с другой стороны. Бух. отчетность это кипы физической бумаги. И вот наша условная МарьВанна делает сверку листая бумажные доки смотря при этом на нумерацию: "1… 2… 4… Ой, 3 нет… это документ не распечатали? Потеряли? Сейчас поищем...". И начинаются раскопки в недрах учетной системы с целью понят, был ли вообще документ 3. При сквозной последовательной нумерации наличие дырки сразу говорит о том, что документ где-то продолбали без заглядывания в учетную систему.
Бухгалтера как никто знают что на нумерацию полагаться нельзя. Можно снять с проведения документ, можно его удалить, заказ может быть отменен, может быть выпущено новое положение о нумеровании.

ЗЫ Бух отчетность это вовсе не кипы физической бумаги.
Я уже более сотни раз ловил на вещах типо привязки обработки пользователей к их расположению в дереве.


Речь видимо о том, когда группа пользователей (ветка в вашей терминологии), в которую входит пользователь, выполняет конкретные функции? Скажем, стоит поместить пользователя в группу «Бухгалтера» и он автоматически получает доступ к финансовым документам.

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

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

Вывод: вполне разумное решение для небольшого предприятия без выделенного сисадмина.
Нет, речь не о группе, а о папочке в которой в данный момент находится пользователь.
Если есть отдельный справочник, в котором расписано соответствие «папочки» свойствам пользователя — то почему нет? Это нормально и хорошо. Плохо когда оно (имя элемента) действительно захардкожено.
Пользователь находиться в группе «продажники», потом бух берет его и тащит в папку «уволенные», ибо список уже запредельный, отчет делает «кряк», и никто не в курсе, потому что документации нету от слова совсем.
и никто не в курсе, потому что документации нету от слова совсем.

Все денег стоит.

Хорошее документирование — существенно поднимает стоимость разработки и снижает скорость. А в бизнесе крайне важно «сделать еще вчера».

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

А иногда и талмуд с документацией (там другая проблема — и как в ней найти нужное в подробнейшей документации).

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


Проблема высосана из пальца.

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

Ну а то что Вы никогда не косячите, я уже понял.
Впрочем, в это не верю.

Сделайте галку, создайте справочник, регистр сведений, да что угодно, но делать так — последнее дело.
В 1С качественная изоляция прикладного кода от слоя работы с БД. Там нельзя типизировать таблицы на низком уровне и косяки малокомпетентных джуниоров на уровне БД там невозможны.

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

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

FK спорен? Это в каком смысле? Нормальная РСУБД решает вопрос консистентности данных на своем уровне и не приходится тащить эту логику в рантайм приложения. Какие тут могут быть сомнения в полезности данного механизма?

Лень искать критику FK, думаю вы сможете ее найти. Общий смысл — FK нужны там где они нужны, а не просто "везде, где есть связи".

Ну тогда оно ни сколько не спорное при использовании там, где они нужны.

Ну вот в кейсах применения 1С — не нужны. Вернее не так, минусы от их использования перевешивают плюсы.

И какие минуса (отсуствие битих ссилок)?
А с партиции 1с не поддерживает, ви их создаете на уровне БД, что кстати запрещено лицензионним соглашением. Ну и они чудно пропадут при перестроении.

У вас кнопка ы поломалась )
Минусы, если не ошибаюсь, были описаны в одной из статей Сергея Нуралиева о том, почему в 1С нет FK. Эти доводы весьма объективны, можно поискать статью.


А так — да, иногда битые ссылки это не плохо, а наоборот — хорошо. Вопрос компромисса между бизнес-кейсами и минимально-достаточной непротиворечивости данных. Еще можно вспомнить такие вещи, как шардинг, например. Это не в 1С, но в таких системах FK тоже часто лишний груз.

Вот и главное. Для меня даные в БД должны быть достоверными, а не с формолировкой
минимально-достаточной непротиворечивости данных
. Да и выбор в етом 1С мне не дал.
По поводу FK — они берут на себе огромную часть БЛ. Имеют оверхед в виде необходимости индексов.
Ну и поверхносное гугление статью не дало.
Ну а поддержка многих баз — ето лиш говорит о том что 1С нормально не поддерживае ни одну.
А и да «ы» у меня нет. пользуюсь буфером обмена :)

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

UFO landed and left these words here
Все равно что человек заявляет, я бы с удовольствием услышал другую точку зрения. Вы говорите FK не нужны? ок, можно аргументы? Без посылов в гугл

Про партиционирование сейчас из каждого утюга, но по сути 99% фирм оно нафиг не сдалось.
Вы говорите FK не нужны? ок, можно аргументы?


Да запросто.

С голыми FK не столь гибко получается.

В 1С есть несколько способов перехвата записи/удаления объекта — выбирай удобный.

Там можно куда как более извращенную бизнес-логику реализовать. Что полезно при этом: в момент этой проверки вы имеет доступ ко всей прикладной сути.

В терминах СУБД этот функционал называется trigger.

P.S.:
В каком-то виде FK в 1С имеются, кстати.

Не скажу на уровне СУБД или на уровне движка платформы — не проверял/или проверял давно и не помню.

Но вы далеко не во всех случаях можете удалить объект из БД, если он где-то еще используется.

Другой довод против FK — зависимость от той или иной нормализации. А нормализация влияет на производительность и на удобство. То есть опять таки малая гибкость. Чтобы сделать FK нам нужно заточиться на определенную структуру.

Что вступает в противоречие с концепциями 1С: быстрая разработка, удобство, оперативные изменения под постоянно изменяющиеся бизнес-процессы.

Когда вы делаете отдельную таблицу только, чтобы включить FK, а для иного дела таблица и не нужна — это не гуд.

FK безусловно хорошо себя показывает только в сравнительно простой бизнес-логике. Но по мере усложнения — уже не все так однозначно.

С голыми FK не столь гибко получается.

Не столь гибко что? Неконсистентные записи создавать? Ну это да, бедаа…

В терминах СУБД этот функционал называется trigger.

всю жизнь мечтал осуществлять контроль целостности ручками)

Не скажу на уровне СУБД или на уровне движка платформы

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


Видимо, вы только начинаете карьеру и еще не сталкивались с сколько нибудь сложными бизнес-процессами, когда без этого никуда.

На уровне движка, с бд 1с обращается как с тупой хранилкой.


И это правильно.
Позволяет реализовать крайне гибкие бизнес-процессы, которые контролировать одними только средствами СУБД или невозможно или гораздо более трудоемко.
Видимо, вы только начинаете карьеру и еще не сталкивались

Если вы архитектуреные споры переводите на личности то вам пора заканчивать с карьерой.

с сколько нибудь сложными бизнес-процессами, когда без этого никуда.

Пример в студию.

когда без этого никуда

Нуда, а вы видимо никогда не видели развивающийся годами продукт, где этим никуда обмазано все сверху донизу в таком объеме, что даже тронуть страшно, а нужно.
Поглядите код модулей регистров в 1С в типовых, к примеру. Реализовать подобные необходимые для решения бизнес задач вещи на голых FK? Вы быстро начнете объяснять что это не нужно, невозможно, что эти идиотские бизнес-процессы и пр.

Но бизнесу это надо и подобные отмазки, что вы не можете это сделать — просто заставят вас уволить. И на 1С это легко решается.

Пример в студию.

Вы и сами привели такой пример:

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


Вот именно поэтому это и плохое решение.
Вариант предлагаемый 1С гораздо удобнее в модернизации при отличной гибкости.

даже тронуть страшно

Ага. Сложность на голых FK разрастается крайне радикальными темпами.
Поглядите код модулей регистров в 1С в типовых,

точнее, каких? там все примитивно.

Вот именно поэтому это и плохое решение.

Это как раз ручные проверки целостности данных.

Ага. Сложность на голых FK разрастается крайне радикальными темпами.

Что такое голых? А есть одетые? И с чего бы вдруг им разрастаться? Ну конкретно, пример, один.
точнее, каких? там все примитивно.

Разумеется, должно быть просто по возможности.
Тот кто усложняет код безосновательно — попросту плохой программист.

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


«Одетые» — это те, что аналоги решения 1С, trigger, где можно куда как больше фантазии реализовать.

«Голые» — это только foreign key

И с чего бы вдруг им разрастаться?

Вы же сами написали:
обмазано все сверху донизу в таком объеме, что даже тронуть страшно, а нужно.

Вам виднее, где это.

Это как раз ручные проверки целостности данных.

Ну конкретно, пример, один.

Я уже дал вам отсылку — см. модули регистров. Возьмите тот, что побольше.

И представьте что вы это реализуется только через FK.

«Там есть сложные штуки, но где — не скажу», классный разговор.


Если у вас нет доступа к конфигурации 1С — любой пример вам ничего не даст. Бизнес логика все же вещь такая, что её нужно смотреть в комплексе, чтобы понять.

Если есть доступ к типовой конфурации — просто поглядите.

Если вы действительно понимаете о чем речь — там и искать ничего не нужно.

Сразу заходите в модули регистров и просто смотрите.
Я уже дал вам отсылку — см. модули регистров. Возьмите тот, что побольше.

Офигенная ссылка, может в ленинскую библиотеку сразу?

И представьте что вы это реализуется только через FK.

Делал

Если у вас нет доступа к конфигурации 1С

Во первых есть во вторых я итак помню половину ее структуры.

Сразу заходите в модули регистров и просто смотрите.

Смотрю, не вижу ничего сверхъестественного.
Офигенная ссылка, может в ленинскую библиотеку сразу?


Для того, что понимает тот аспект, что мы тут с вами обсуждаем — ссылка вполне конкретная.

Модуль именно что регистра.
В типовой конфигурации.
Той что у вас под рукой.

Это вполне конкретное место.
И представьте что вы это реализуется только через FK.

Делал

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

Так вот в варианте предлагаемом 1С — не страшно.
Даже с вычурной бизнес-логикой.

Смотрю, не вижу ничего сверхъестественного.

Именно!
Потому что в варианте предлагаемом 1С это выглядит удобно для программиста.

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

Нет не конкретная, потому что регистры — примитивные структуры данных.

И представьте что вы это реализуется только через FK.

И ничего страшного. Аргументов от вас как небыло так и нет

И вы сами прокомментировали ситуацию так:

Этот коммент относился к контролю целостности в ручном режиме, и выше это уже указано, дважды.

Даже с вычурной бизнес-логикой.

Пример «вычурной» бизнес логики я тоже так и не увижу?

Конечно. Потому что в варианте предлагаемом 1С это выглядит удобно для программиста.

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

ЗЫ я понял, для меня спор — способ получить новые знания. Для вас — место где нужно перекричать оппонента и доказать правоту. Аргументы и примеры в студию пожалуйста или позвольте мне откланяться.

Распределённые базы попроектируйте. Как раз до этого момента многие в FK верят. :)

Например при распределенной БД (мега фича 1с, которой нигде больше не видел) можно сделать узел на складе, в который будут прилетать только складские ордера, и вместо документов оснований для них — будут битые ссылки. При этом сама база узла будет работать на десктопного уровня компьютере и размером быть в единицы процентов от основной. Вообще эта технология позволяет вместо одного сервера на 2000+ сотрудников по стране сделать 10-100 серверов по филиалам и суммарно нехило сэкономить на железе. Да и в надежности тоже. Те же каналы связи в каком-нибудь Сыктывкаре часто оставляют желать лучшего. А в случае поломке на месте можно пустить (временно) в базу на уровень выше по иерархии и отпочковать клон нужного узла после починки сервера на месте.
В надежности? То есть когда у вас в Сыктывкаре навернется сервер, то кто его там поднимать будет? Кто свежие данные оттуда на резервные перенесет?
Сейчас основной тренд на облака, а Вы — про распределенки…
Я не Сергей Нуралиев, и не видел его статью. Поэтому скажу две вещи, из жизни так сказать.
1. Foreign Keys имеют цену.
2. «Так» делали и 25 лет назад. Так — это когда пользователю предоставлена закрытая система, то есть он не может залезть прямо в таблицы данных и что то ручками поправить, за всё что касается ссылок отвечает приложение. Любой, кто хотя б прочитал книжку «СУБД для чайников» или «SQL для чайников» найдёт по меньшей мере 4 довода, что это ну очень плохая практика. Но это было, и… есть. Не ошибусь если скажу что большинство стартапчиков (ну например, какой нибудь Инстаграм) использовали в проекте на старте нормализованную СУБД с FK и прочими правильными вещами. Всё по книжкам, всё как учили преподы в универах. Но как только мощностей того условного ноутбука, на котором был запущен проект не хватало, сразу же и избавлялись от узких мест типа FK. Кто позже, кто раньше. Потому что см. п. 1.
1. Вы про индексы?
2. Тогда нужно продолжать мысль. И запилили свой контроль целостности и добавили к нему «проверку структуры дб», «исправление структуры бд» или просто на консистентность данных им плевать.

1с отказывается от контроля целостности не изза «цены». Ключи являются ценой использования их абстракции.

Тремя руками голосую за ту часть, которая касается развития языка (то что надо и что не надо). Умри Денис, лучше не предложишь!

А можно более подробно, что плохого в ООП в бизнес-приложениях?

Например, вот логика. Есть класс Контрагент. Документы вроде Счет должны ссылаться на Контрагент. От него наследуется Физическое лицо и Организация. У первого есть свойства Имя, Отчество и Фамилия, а у Организация — Форма собственности, ИНН, ОКПО и т.д.

Альтернатива этому без ООП — просто закинуть все свойства в Контрагент и показывать и использовать их в зависимости от какого-то boolean (или типа). Но это тоже самое, что говорить, что зачем нужен полиморфизм, если все можно сделать на if'ах.
Почему если говорят про ооп в бизнес приложениях так любят бизнес домен вспоминать? Причем почему то обязательно про наследование. ООП оно же чисто для служебного кода основные плюшки дает. DI, композиция объектов с поведением, повышенное удобство переиспользования и прочее. И вот для бизнес логики его не хватает. А бизнес сущности — уж фиг с ними, раз так большинство желает.

В 1с можно наследоваться от базовых классов, в данном примере Организация, Контрагент и ФищЛицо это классы унаследованные от базового класса Справочник. Или проще — это справочники.


В каких случаях для какого решения надо от каких классов базовых наследоваться можно почитать в стандарте:
https://its.1c.ru/db/v8std#content:683:hdoc


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

Организация, Контрагент и ФищЛицо это классы унаследованные от базового класса Справочник


Вы не поняли логики. ФизЛицо наследуется от Контрагент, так как ФизЛицо является Контрагентом, также как и Организация. Это не 3 разных сущности.

Такое наследование потом в базу складывать — то еще удовольствие. И всякие костыли в ORM-фреймворках типа EF, которые авторы усложняют и закостыливают ради обеспечения гибкого наследования в языке. 1С же наоборот — отказалась от наследования ради снижения сложности и повышения адекватности ORM.

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

И всякие костыли в ORM-фреймворках типа EF

Все зависит от конкретной платформы. Где-то наследование может быть сделано костылями, а где-то — нет.

Я хорошо знаю Entity Framework. Там это костыли. Но я сильно, очень сильно сомневаюсь, что ближайший конкурент hibernate сделал как-то иначе и лучше.


Разработчику должно быть все равно какие запросы при этом генерируются

это прекрасно. Да, разработчику, как правило и все равно. А потом сервера ложатся под нагрузкой. И EF-Core генерирует гораздо более говенные запросы, чем тот же 1С. И да, что в 1С, что в .NET рядовой разработчик даже не задумывается над тем, что пойдет в СУБД.


Однако, мой опыт (безусловно субъективный) показывает, что 1С-ники гораздо сильнее заморачиваются с оптимизацией запросов, чем их коллеги из мира .net

Если в EF сделали плохую оптимизацию запросов, то это не значит, что во всех платформах и ORM кривые запросы. А в том же 1С автоматически даже не делается JPPD, и его надо делать вручную 1С-разработчику.

Я не говорил, что во всех плохо. Расскажите, в какой это делается хорошо?

В lsFusion, например, мы очень много времени и сил потратили на то, чтобы оптимизировать все запросы под выполнение их СУБД (пока только в PostgreSQL). Автоматическая поддержка JPPD — это самая простая из оптимизаций.

lsFusion это не ORM общего назначения, уж простите. Допускаю, что там что-то оптимизировано, но, без обид, я смотрел вашу демку. Впечатляет ровно никак. Я буду рад, если у вас получится, конкуренция это хорошо, это путь к развитию.

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

Но основное мое утверждение то касалось не ORM. А того, что ООП в бизнес-приложениях (именно в высокоуровневых платформах) можно и нужно использовать.

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

Да ладно, отличная ж была система. Жаль не сохранились статьи про «слабосильные 1С и SAP» — согревали кресло холодными зимними вечерами.
Но зато на их новом сайте diaspar.business можно в буллшит-бинго играть, например.
Лично у меня встреча в тексте lsFusion ассоциируется с тем, что скоро будет вброс какой-то ненужной бесполезной хрени.

И как правило, так и происходит, бгггг

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

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

Ну ладно, пусть будет «композиция вместо наследования». Писалось именно ради
офигеть, как сложно это написать кириллицей
мы ж про 1с говорим :)

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


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


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


Действительно в контрагент добавляются некоторые реквизиты которые не используются для некоторых типов в зависимости от значения реквизита типа. Обычно это не представляет проблем, потому что просто скрывают их с формы и добавляют правило проверки значений реквизитов иное. Например ИНН для ЮрЛица — 10 символов, для ИП — 12 символов, а у физ лица его может вообще не быть.

Ну и стоит добавить, что ФизЛицо как сущность может фигурировать и как свой сотрудник, и как подрядчик, и как покупатель, и как директор в каком-то юр-лице. Здесь не наследование, а самая что ни на есть композиция.

Идентификаторы записей в БД. 1С приняла волевое решение — все идентификаторы ссылок абсолютно синтетические и всё тут. И нет проблем с распределенными базами и обменами.


Производительность и место таблиц и индексов. Разве нет?
Одно дело, когда ключами являются LONG (как в lsFusion), другое дело, когда, например, 32-байтные строки. Понятно, что JOIN'ы по LONG'ам будут гораздо быстрее и потреблять меньше памяти, чем по 32-байтной строке.

стоп-стоп, чейта UUID вдруг стал 32-БАЙТНОЙ строкой? В LsFusion, раз уж вы упомянули, авторы заранее заложили сложность создания распределенных баз данных и обменов между системами. Да, памяти меньше. Если критерием оптимизации является память — long хорошее решение. Если критерием оптимизации является стоимость реализации бизнес-кейса — long ужасное решение.


Если ваше решение доживет до необходимости запуска распределенных обменов на нем — вас ждет сюрприз.

Я же написал: «например». Преимущества long, что это тип, который нативный для процессора и лучше всего обрабатывается на низком уровне. Понятно, что UUID занимает всего в 2 раза больше, но архитектура процессора 64-битная пока-что.

Если ваше решение доживет до необходимости запуска распределенных обменов на нем — вас ждет сюрприз.

В современном мире необходимости распределенных баз уже значительно меньше. У нас есть клиент на 570 магазинов в деревнях и селах и даже там, нет проблема с интернетом. Но, в целом, сделать UUID вместо LONG — достаточно несложно.
1с идентификаторы это не UUID это поля типа bytea, где в hex живет одинэсовский айди с перестановками.
А сколько он занимает? И получается, что в запросах идет JOIN по bytea?
4 байта плюс 32 шестнадцатеричных символа. Два шестнадцатеричных символа на байт, итого 20 (наврал вначале, забыл что там два на байт)
Да джоин идет по нему, плюс ко многим ключам есть еще 2 поля с указанием на тип таблицы и ее id.
Мне вот тоже интересно, и я засомневался. Но это же несложно проверить — достаточно посмотреть в SQL Server Management Studio. У меня просто нет инсталляции 1С под рукой. А Вы можете глянуть?

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

Разница в производительности на выборках и джойнах ключа 8 байт (long) и 16-байтного binary настолько мала на общем фоне, что это точно можно не учитывать. Так-то посмотреть и строки в однобайтных кодировках меньше занимают. И binary collation быстрее. И тот же RCSI гораздо дороже для отдельных запросов, но его точно надо включать в MS SQL.

Друзья и коллеги, в последнее время на Хабре участились статьи с хейтом в адрес 1С...

Можно хотя бы пару ссылок для примера?
Негусто для «в последнее время участились». Хейтом, кстати, та статья не является — это разбор некоторых проблем 1С с подробной технической аргументацией.
Дело в том, что даже конструктивную критику иногда воспринимают, как просто «хейт». Но это в больше степени касается 1С. Статью Почему не SQL почему-то никто не начал называть «хейтом SQL»…
Возможность сразу писать бизнес логику да еще и на родном языке это просто мечта, 1С отличный российский продукт.
Зачем вообще finally? Если посмотреть на поток выполнения программы, от него ни жарко ни холодно (особенно когда нет типа перехватываемого исключения):
Скрытый текст
image

Изначально — для контроля ресурсов. Потом там много интересного навертели, особенно в части логирования и трассировки.

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

И чем это отличается освобождением ресурсов после КонецПопытки? А уж сколько шишек набито из-за ТранзакцияАктивна — не пересчитать. Больше, наверное, только с НПП в преставлениях чисел.

Тем, что за "КонецПопытки" в случае исключения не всегда надо заходить. А коли так — то надо писать освобождение ресурсов 2 раза — внутри Попытки и внутри Исключения. Странно, что вы до сих пор с этим не столкнулись, будучи 1С-ником.


<troll-mode>возможно вы не паритесь из-за не освобожденных ресурсов</troll-mode>
А зачем за него не заходить? Пишите освобождение ресурсов один раз — после КонецПопытки и с высокой долей вероятности в него попадете. См. картинку в исходном комментарии.
Я просто не пойму чем принципиально отличаются картинки в исходном комментарии, учитывая, что в любой квадратик можно закинуть любое количество строк кода. Мы же про логический (да и не только) поток выполнения программы говорим. Если картинка с finally должна быть другой, то нарисуйте (почему на вы? столько раз общались на ISevent и та ты) нужную. Быстро можно прям онлайн plantuml.com, исходный вариант моей картинки:
Скрытый текст
@startuml

start

:Программа;
if (Попытка) then (Исключение)
:Обработка исключения;
endif
:Программа;

stop

start

:Программа;
if (Попытка) then (Исключение)
:Обработка исключения;
endif
:Finally;
:Программа;

stop

@enduml


мануал тут: plantuml.com/ru/activity-diagram-beta
Что будет если «Обработка исключения» тоже бросит исключение? А что делать если я в «Обработка исключения» просто хочу залоггировать исключение и пробросить его выше по стеку?