Comments 241
В 1С регистр накопления:
В 1С регистр сведений:
- Строка документа может порождать "много" записей в регистре остатков(оборотов) — например, списание по партиям при партионном учете
- Есть промежуточные итоги, а не только актуальные.
В 1С регистр сведений:
- Грубо говоря plain-таблица с периодом и без, с наличием итоговых записей начала и конца периода и без них.
- Если говорить о периодическом регистре с итогами: можно хранить не только последнюю "цену", но и другие данные...
- И да, в 1С можно вносить данные по всем измерениям в один период (секунду) — но только при наличии дополнительного упорядочивания по документу, так и называется "По позиции регистратора".
Статья маркетинговая фигня
p.s. слава богу в 1С нет ООП. Незачем ООП тащить в DSL — чем проще, тем лучше.
Это не отменяет того факта, что ООП в 1С нету, и регистры там реализуются императивно.
price 'Цена' (Stock st, Sku sk, DATETIME dt) =
GROUP LAST price(PriceLedger l)
ORDER dateTime(l), l
WHERE dateTime(l) <= dt
BY stock(l), sku(l);А это что, тоже называется "Декларативно"?
В 1С вообще -программист не реализовывает регистры… а как там реализовано по большому счету все равно.
Вы понимаете разницу между декларативностью и императивностью?
Да, вот только проведение по регистрам и ограничения делаются как раз 1С-программистом вручную императивно.
В 1С вообще -программист не реализовывает регистры… а как там реализовано по большому счету все равно.
Да, вот только проведение по регистрам и ограничения делаются как раз 1С-программистом вручную императивно.
Бизнес логика — она в любом случае есть, если не говорить про регистр типа "sku, count".
Проведение по регистрам в 1С:
Движения.ПартииТоваровНаСкладах.Записать();или так:
Движения.ПартииТоваровНаСкладах.Записывать = Истина;Ага, только вот пример кода из документации:
Только самое забавное, что в УТ сделано все не так, как у них в документации. Так как в 1С сами понимают, что этот код дико тормозит и нужно переходить на плоский SQL. Скиньте, для примера, код из УТ который просто проводит по движению и проверяет на то, что остаток больше 0 (можете вырезать всю мишуру, а оставить самый простой случай). Только спрячьте под спойлер, а то там будет очень много (по сравнению с тем, что в статье).
Только самое забавное, что в УТ сделано все не так, как у них в документации. Так как в 1С сами понимают, что этот код дико тормозит и нужно переходить на плоский SQL. Скиньте, для примера, код из УТ который просто проводит по движению и проверяет на то, что остаток больше 0 (можете вырезать всю мишуру, а оставить самый простой случай). Только спрячьте под спойлер, а то там будет очень много (по сравнению с тем, что в статье).
Формирование движений и запись в регистр — разные вещи…
Если интересен пример формирования движений и проведения:
Методика оперативного проведения и управляемые блокировки https://1c.chistov.pro/2013/07/blog-post_25.html
Это все круто. Но для человека со стороны это все выглядит как «Кто все эти люди ?». Откуда такая сложность в простой задаче? В современном программировании наоборот стараются все упрощать. Причем 1С-программисты делают вид и убеждают всех, что так и надо. Отсюда собственно и шутка про паралимпиаду по программированию.
"Сложность" понятие субъективное… мне например все понятно, и для чего и почему...
- очищаем старые движения — логично?
- проверяем что достаточно товара — логично?
- ставим блокировку (параллельное проведение) — что бы не списалось одно и тоже при параллельном проведении, логично?
- заполняем движения по партиям — после блокировки списываем партии, логично?
Чего делать не надо не в 1С?
В lsFusion ничего этого делать не надо. Это все делается автоматически платформой.
А можно увидеть пример списания партий, что бы это было вот как вы пишете прям в платформе!
Что бы можно было настроить FIFO, FEFO, LIFO — вот прям в интерфейсе?
Да нигде ничего делать не надо, все везде само, о чем речь
В статье написан полный код для поддержки регистра. Больше ничего писать не надо.
Для конструктивного обсуждения скиньте, пожалуйста, код на 1С.
Для конструктивного обсуждения скиньте, пожалуйста, код на 1С.
Код создания регистра? В 1С его нет, он мышкой создается. Вы мне скажите вот что: Я одно время преподавал студентам 1С.
Мы брали учебную версию и за 1 лабораторную (2 акк. пары) создавали полноценную управленческую учетную систему «Купил-продал» с репортингом, UI и веб-клиентом. При этом мы написали не более 20 строк кода. Результатом 2 часов работы студентов можно вполне вести упр.учет мелкого магазинчика. Под «управленческим» я понимаю учет без расчета налогов, только для собственника: сколько у меня денег, сколько у меня товара, сколько я продал, какой фин. результат?
Ваша система может дать мне за 2 часа+20 строк кода веб-клиент, UI и управленческую отчетность с гибкими фильтрами-группировками? Если да, я охотно порекомендую ее коллегам-преподавателям.
Мы брали учебную версию и за 1 лабораторную (2 акк. пары) создавали полноценную управленческую учетную систему «Купил-продал» с репортингом, UI и веб-клиентом. При этом мы написали не более 20 строк кода. Результатом 2 часов работы студентов можно вполне вести упр.учет мелкого магазинчика. Под «управленческим» я понимаю учет без расчета налогов, только для собственника: сколько у меня денег, сколько у меня товара, сколько я продал, какой фин. результат?
Ваша система может дать мне за 2 часа+20 строк кода веб-клиент, UI и управленческую отчетность с гибкими фильтрами-группировками? Если да, я охотно порекомендую ее коллегам-преподавателям.
Давайте не будем устраивать холивар на тему графическое vs текстовое программирование. Для мелких разработок начинающими программистами возможно графическое лучше. Но когда разработка делается командой и там куча функционала, то проблемы системы контроля версий и рефакторинга выходят на первый план, и там будет лучше код.
Мышкой там делается wizard, который генерирует тот же код. Если его хоть немного менять, то назад мышкой редактировать вы уже не сможете. Опять же, не хочу устраивать холивар на тему визард vs архитектурное программирование.
Вообще да, сможете. У нас будет статья как сделать простой склад.
Но вообще смысла делать с нуля склад никакого нету. Если речь идет о какой-то другой информационной системе (например, турнирная таблица), то все эти регистры бухгалтерий и прочего становятся неприменимыми. И в 1С будет куча ненужных вам абстракций.
Кроме того, не забываем, что 1С — коммерческий продукт с очень жесткой системой лицензирования. А lsFusion по LGPLv3 лицензией, адаптированный под работу с PostgreSQL.
Код создания регистра? В 1С его нет, он мышкой создается. Вы мне скажите вот что: Я одно время преподавал студентам 1С.
Мышкой там делается wizard, который генерирует тот же код. Если его хоть немного менять, то назад мышкой редактировать вы уже не сможете. Опять же, не хочу устраивать холивар на тему визард vs архитектурное программирование.
Ваша система может дать мне за 2 часа+20 строк кода веб-клиент, UI и управленческую отчетность с гибкими фильтрами-группировками? Если да, я охотно порекомендую ее коллегам-преподавателям.
Вообще да, сможете. У нас будет статья как сделать простой склад.
Но вообще смысла делать с нуля склад никакого нету. Если речь идет о какой-то другой информационной системе (например, турнирная таблица), то все эти регистры бухгалтерий и прочего становятся неприменимыми. И в 1С будет куча ненужных вам абстракций.
Кроме того, не забываем, что 1С — коммерческий продукт с очень жесткой системой лицензирования. А lsFusion по LGPLv3 лицензией, адаптированный под работу с PostgreSQL.
Я уже посмотрел ваш демо пример. У меня больше нет к вам вопросов. А подача материала и тон ответов окончательно закрывает вопрос о целесообразности изучения вашей системы.
Спасибо за ваше мнение. Мы за плюрализм, и считаем, что всегда у людей должен быть выбор, и каждый решает сам, что ему лучше.
Понимаете в чем дело… (дальше ИМХО)
Вы решили рассказать о том, что 1С: Предприятие — это плохая система, а ваша система — хорошая. Вы в этом уверены и не допускаете, что может быть по-другому.
Вести конструктивную дискуссию при таком подходе очень тяжело. Просто по-определению такого подхода.
Вы не предполагаете, что у ваших оппонентов могут быть причины делать так, как они сделали. И таких причин может быть очень много. Причем как у тех, кто платформу делает, так и у тех, кто конфигурации делает.
Но уже приняв решение (и не допуская другого), вы лозунги озвучиваете другие.
Вы решили рассказать о том, что 1С: Предприятие — это плохая система, а ваша система — хорошая. Вы в этом уверены и не допускаете, что может быть по-другому.
Вести конструктивную дискуссию при таком подходе очень тяжело. Просто по-определению такого подхода.
Вы не предполагаете, что у ваших оппонентов могут быть причины делать так, как они сделали. И таких причин может быть очень много. Причем как у тех, кто платформу делает, так и у тех, кто конфигурации делает.
Но уже приняв решение (и не допуская другого), вы лозунги озвучиваете другие.
Вы решили рассказать о том, что 1С: Предприятие — это плохая система, а ваша система — хорошая
Это не так. Тут не белое и черное. У каждого подхода и технологии есть свои преимущества и недостатки.
Это конкретная статья про конкретный кейс. И тут очевидно, что преимущество не на стороне 1С. Удивительно, что 1С программисты не хотят этого признать. Со своей стороны, я вот совершенно согласен, что в 1С дизайн лучше. Есть еще вещи, которые реализованы в 1С лучше, чем в lsFusion. Что не отменяет того факта, что многое в lsFusion лучше чем в 1С.
Простите, а вот это что (пост)?
Вопрос в том, что 1С умудрился накосячить как раз во всем в чем мог. Если честно даже удивительно. Они взяли все самое худшее от существующих технологий, при этом выкинув самое лучшее.Да, это не персонально вы, но это «ваша» сторона дискуссии :)
Это конкретная статья про конкретный кейс. И тут очевидно, что преимущество не на стороне 1С.
Я-бы ни с интересом почитал вашу статья, если-бы в ней приводилась какая-то осмысленная конкретика. Вот демо-пример, вот тестовая база, вот результаты на одном и том же железе, вот версии софта. И т.д.
Но вы приводите пример сферического регистра в вакууме (а для примеров такие сферические модели всегда идеально подходят) и на этом основании делаете какие-то выводы. Не важно, что в реальной жизни сфера становится почти плоским многоугольником.
И вот на это и агрятся читатели, плотно и профессионально связанные с Предприятием.
Но сравнивать надо сравнимое. И при этом одинаково профессионально знать обе сравниваемые системы. А здесь этого, извините, нет.
ЗЗЫ: Что-то у меня цитаты весь текст порушили и поправить не получается, извините :(
Формирование движений и запись в регистр — разные вещи…
Для решения одной задачи.
формирование движений будет происходить в любой системе кодом. Если там что то сложнее от склад, товар, количество.
Запись в регистр, да возможно где то и автоматом… но по секрету, в 1С тоже можно автоматом — просто это медленнее.
"Запись движений при проведении" — "Записывать модифицированные" — можете погуглить
формирование движений будет происходить в любой системе кодом. Если там что то сложнее от склад, товар, количество.
Оно может происходить декларативно, а может императивно. А проблема императивного подхода, например, что при изменении документа оно требует провести обработку всего документа (то есть всех строк). В lsFusion если вы поменяли одну строку, обрабатываться будет только эта одна строка.
«Запись движений при проведении» — «Записывать модифицированные» — можете погуглить
Гуглил. Автоматом можно только в самых примитивных случаях. Появляется хоть один if или ссылка / join — вперед for'ы/запросы руками писать.
При стандартном подходе 1С — один документ много строк. Но никто не мешает сделать один документ на строку, и один документ-владелец.
Получится такой же эффект — просто никому это не надо...
Это уже реализовано в нескольких WMS-системах на 1С.
При стандартном подходе 1С — один документ много строк. Но никто не мешает сделать один документ на строку, и один документ-владелец.
Получится такой же эффект — просто никому это не надо...
А когда надо ввести один документ на 100 строк, будете их по одной вводить. Издеваетесь?
Но вообще вы похоже, не поняли. В lsFusion вы вводите документ как обычно. Потом можете открыть его на редактирование, поменять только одну строку. И о чудо она обновит данные только для этой одной строки (со всеми регистрами, ограничениями и т.п.).
Вообще в lsFusion можно один документ параллельно разными пользователями вводить при необходимости (у нас были такие кейсы), и она отлично все разрулит сама.
Идею вы не поняли, так как платформу 1С не очень хорошо знаете. И вообще, вы сравниваете свою платформу с конфигурациями 1С, а не с платформой 1С. Надо отделять мух от котлет.
Как раз я последний месяц с ней разбирался, это с учетом того что у меня огромный опыт работы с различными платформами разработки (начиная от Foxpro и .Net/Java и заканчивая совсем экзотическими).
И 1С идеологически подразумевает перепроведение всего документами. И разработчики УТ со мной походу согласны. Или думаете они тоже платформу 1С не очень хорошо знают?
И 1С идеологически подразумевает перепроведение всего документами. И разработчики УТ со мной походу согласны. Или думаете они тоже платформу 1С не очень хорошо знают?
Вы изучали не платформу, а типовые решения на этой платформе. Поэтому, сравнивая типовые решения 1С со своей платформой, вы показываете себя не в лучшем свете.
Еще раз я изучал платформу. Вот тут и тут:
its.1c.ru/db/metod8dev
its.1c.ru/db/v8315doc
Ну и естественно обращался к решениям на 1С за бест-практис. Потому как если что-то делают именно разработчики 1С, тяжело возразить что они это делают не правильно.
И сравниваются конкретные механизмы ПЛАТФОРМЫ регистры и ограничения на примере типовых решений. Или по вашему есть другие более простые и эффективные способы работы с ними, о которых даже разработчики УТ не знают?
its.1c.ru/db/metod8dev
its.1c.ru/db/v8315doc
Ну и естественно обращался к решениям на 1С за бест-практис. Потому как если что-то делают именно разработчики 1С, тяжело возразить что они это делают не правильно.
И сравниваются конкретные механизмы ПЛАТФОРМЫ регистры и ограничения на примере типовых решений. Или по вашему есть другие более простые и эффективные способы работы с ними, о которых даже разработчики УТ не знают?
Сравнивайте типовые решения на вашей платформе, и типовые на 1С, и вопросов к вам будет. Если как-то сделано в типовых, это не значит, что по-другому в платформе нельзя, это не значит, что это наиболее эффективный способ. Причины, почему именно так реализовано в типовых, лежат несколько в иной плоскости.
Если как-то сделано в типовых, это не значит, что по-другому в платформе нельзя
Ок, тогда расскажите как по другому сделать проверку, что например сумма остатков должно быть больше 0, потому как я всю документацию облазил, форумы перечитал, типовые пересмотрел, и пришел к выводу (сюрприз !) что разработчики типовых сделали это единственным эффективным способом (с 400 строк кода вместо одной в lsFusion)
Что значит «сумма остатков больше 0»? Ну, и вы должны понимать, что в любом случае:
1. Не зная постановки задачи судить об эффективности кода нельзя.
2. Любое универсальное решение будет избыточнее и сложнее специализированного.
Поэтому, сравнивать можно только реализацию конкретного, непротиворечивого, ТЗ на различных платформах. Всё остальное — профанация и умозрительные заключения.
1. Не зная постановки задачи судить об эффективности кода нельзя.
2. Любое универсальное решение будет избыточнее и сложнее специализированного.
Поэтому, сравнивать можно только реализацию конкретного, непротиворечивого, ТЗ на различных платформах. Всё остальное — профанация и умозрительные заключения.
Что значит «сумма остатков больше 0»?
Что именно вам непонятно. Остаток по любому товару складу в текущий момент должен всегда быть >0. Что тут может быть не понятного?
2. Любое универсальное решение будет избыточнее и сложнее специализированного.
Поэтому, сравнивать можно только реализацию конкретного, непротиворечивого, ТЗ на различных платформах. Всё остальное — профанация и умозрительные заключения.
Ок, покажите пример склада как тут на 1С. Я помню такая конфигурация когда-то существовала (под более ранние версии), но сейчас не могу найти.
Извините, я, наверное, глуповат. Вы можете привести по обеим случаем бизнес-требования и постановку задачи не как, например «Информационная система будет состоять из подмножества модулей, в каждом из которых реализуется некоторая логически обособленная функциональность.»?
Извините, я, наверное, глуповат. Вы можете привести по обеим случаем бизнес-требования и постановку задачи не как, например «Информационная система будет состоять из подмножества модулей, в каждом из которых реализуется некоторая логически обособленная функциональность.»?
Ну там действительно, есть много технического текста, можно его пропускать. В любом случае, вот онлайн демо (оно же на lsfusion.org/try):
demo.lsfusion.org/mm
Ну и я точно помню, что у 1С был пример такого же простого склада когда-то, но я почему-то не могу его найти.
Да в 1С все выглядит как один документ, а вот обновляется построчно.
И да — все проверки и движения будут построчно.
И редактировать документ можно раздельно.
Просто это отклонения от общепринятых стандартнов
Речь о другом, при редактировании документа он перепроводится целиком. Потому как иначе придется отслеживать изменение каждого реквизита везде руками. А это ну очень трудоемко.
Нет, это не так. Изменяете одну строку — проводится один документ, который и является этой строкой. Контроль же всего документа в целом нужно будет будет реализовывать отдельно, это да. Но ведь и в вашей платформе так-же?
Нет, это не так. Изменяете одну строку — проводится один документ, который и является этой строкой.
Я сейчас зашел в УТ. Изменил одну строку отгрузки. Дальше дебажу и вижу что во всех временных таблицах, расписывании по партиям обрабатываются ВСЕ строки этого документа, даже которые я не менял.
Но ведь и в вашей платформе так-же?
Нет, если изменяется одна строка, а весь документ на 10к строк, будет обрабатываться / читаться только одна строка / товар этой строки.
Ещё раз, это НЕ является ограничением платформы, это принятый РАЗРАБОТЧИКАМИ ТИПОВЫХ (и рекомендуемый вендором) способ работы. Платформа может и так, как описано мною выше.
Про обработку документа в целом вы опять не до конца поняли. Например, нам нужно контролировать наличие товаров на складе, и максимальную/минимальную сумму заказа. Остатки мы контролируем на уровне измененной строки, а сумму заказа мы контролируем по документу в целом. Но в типовых это не так, да.
Про обработку документа в целом вы опять не до конца поняли. Например, нам нужно контролировать наличие товаров на складе, и максимальную/минимальную сумму заказа. Остатки мы контролируем на уровне измененной строки, а сумму заказа мы контролируем по документу в целом. Но в типовых это не так, да.
Ок, давайте остановимся на том, что разработчики типовых просто не умеют правильно использовать возможности платформы. А на самом деле можно все было делать гораздо проще и эффективнее.
Если вам от этого будет легче — я с вами соглашусь. В окончание разговора всё же отмечу, зря вы продвигаете свое решение через сравнение с 1С. Это путь в никуда.
Забавно, что SQL-ки в статье про функциональную СУБД, говорили что зря вы продвигаете ее сравнивая с SQL, сравнивайте с 1С. .Net'овцы тоже говорили, что зря мы сравниваем с .Net, вот вы говорите, что зря сравниваем с 1С.
А собственно все эти технологии решают одни и те же задачи — разработку информационных систем / бизнес-приложений.
Но вообще, это естественно. Большинство людей не хочет изучать что-то новое и выходить из зоны комфорта. С другой стороны, вы же понимаете, что на первом этапе в любых инновациях расчет никогда не делается на большинство.
А собственно все эти технологии решают одни и те же задачи — разработку информационных систем / бизнес-приложений.
Но вообще, это естественно. Большинство людей не хочет изучать что-то новое и выходить из зоны комфорта. С другой стороны, вы же понимаете, что на первом этапе в любых инновациях расчет никогда не делается на большинство.
Большинство людей не хочет изучать что-то новое— изучать что-то новое имеет смысл когда оно хотя бы потенциально несет какой-то профит. Ваша система особых преимуществ не имеет, кроме тех, которые вы сами себе придумали. Народ ополчился на, откровенно говоря, безграмотное сравнение себя с лидерами рынка.
Посравнивайте себя с той же Кубой (https://www.cuba-platform.ru/), вы где-то примерно в одной нише.
Ваша система особых преимуществ не имеет, кроме тех, которые вы сами себе придумали
Я тоже самое и про iPhone, и про Tesla, и про Mongodb слышал. Конечно далеко не все ими становятся, но абсолютно все новые вещи на рынке изначально получают такую реакцию. Была даже такая шутка про обсуждение в баре первого автомобиля (не помню дословно):
— Да я за эти деньги две лошади и овса им на всю жизнь куплю.
Что-то я не помню чтобы в кейноутах Apple хоть раз упоминались конкуренты в негативном ключе.
А как они touchscreen по вашему представляли? Что кнопочные телефоны неудобны. Равно как и электромобили — что бензиновые автомобили загрязняют окружающую среду, а mongodb — что SQL базы не масштабируются.
Собственно все нормальные продукты идут от проблем существующих продуктов, а не от возможностей. И так и должно быть, иначе в чем смысл этих продуктов.
Собственно все нормальные продукты идут от проблем существующих продуктов, а не от возможностей. И так и должно быть, иначе в чем смысл этих продуктов.
Вы смешиваете критику подхода (вообще кнопочный телефон) и критику конкретной модели (например, Nokia 3210).
Ну а то, что электромобили не загрязняют окружающую среду — это вообще, любимый пример передергивания, зашкаливающего за понятие «вранье».
Ну а то, что электромобили не загрязняют окружающую среду — это вообще, любимый пример передергивания, зашкаливающего за понятие «вранье».
Вы смешиваете критику подхода (вообще кнопочный телефон) и критику конкретной модели (например, Nokia 3210).
Ну если бы, как на постсоветском рынке, на рынке были бы только Nokia 3210, то критиковали бы именно их. Посмотрите презы AMD и Intel они постоянно друг с другом сравнивают.
Ну а то, что электромобили не загрязняют окружающую среду — это вообще, любимый пример передергивания, зашкаливающего за понятие «вранье».
Но идея была не в этом. А в самом факте сравнения с конкурентами.
Еще раз: когда я говорю «кнопочный телефон» — я не упоминаю конкурента. Когда я говорю «нативное приложение» или «веб приложение» — я не упоминаю создателя приложения. Не важно, что в конкретном контексте уши конкурента светятся как фонарь :)
Но как только я сказал «приложение Microsoft» — я стал на очень скользкую дорожку. Вначале все может быть красиво и прилично, а потом бац — и просто ложь в сравнении :)
Но как только я сказал «приложение Microsoft» — я стал на очень скользкую дорожку. Вначале все может быть красиво и прилично, а потом бац — и просто ложь в сравнении :)
Ну раз вы ответили :))
Я ничего не имею против вашей платформы, я вижу, что некоторые ваши решения лучше, чем у 1С, идея подбора в отдельной вкладке, например, вполне здравая :)). Но когда вы критикуете 1С как платформу, приводя при этом в пример типовые конфигурации, и не замечая, что платформа 1С «умеет» и по-другому, это реально огорчает. Кстати, продвигать свой продукт сравнением с 1С пытались как минимум Ultima, CUBA и Ананас. В конечном итоге, все они стали продвигать только свои достоинства, не упоминая 1С. Задумайтесь об этом…
Я ничего не имею против вашей платформы, я вижу, что некоторые ваши решения лучше, чем у 1С, идея подбора в отдельной вкладке, например, вполне здравая :)). Но когда вы критикуете 1С как платформу, приводя при этом в пример типовые конфигурации, и не замечая, что платформа 1С «умеет» и по-другому, это реально огорчает. Кстати, продвигать свой продукт сравнением с 1С пытались как минимум Ultima, CUBA и Ананас. В конечном итоге, все они стали продвигать только свои достоинства, не упоминая 1С. Задумайтесь об этом…
Что значит в вашем понимании «перепроводится целиком»?
В понимании платформы «проведение» — это лишь некий статус при сохранении объекта. Ну и вызов некоторой цепочки методов-обработчиков. Исторически сложилось, что при этом формируются движения по регистрам. Но вся логика этого формирования целиком на совести разработчика.
В понимании платформы «проведение» — это лишь некий статус при сохранении объекта. Ну и вызов некоторой цепочки методов-обработчиков. Исторически сложилось, что при этом формируются движения по регистрам. Но вся логика этого формирования целиком на совести разработчика.
Исторически сложилось, что при этом формируются движения по регистрам. Но вся логика этого формирования целиком на совести разработчика.
Это не исторически так сложилось, это 1С так предполагает. И как по другому делать даже разработчики типовых не знают. Не от хорошей жизни же они так и делают, да и я не могу придумать как по другому. Поэтому:
Я сейчас зашел в УТ. Изменил одну строку отгрузки. Дальше дебажу и вижу что во всех временных таблицах, расписывании по партиям обрабатываются ВСЕ строки этого документа, даже которые я не менял.
это 1С так предполагает— в данном случае под «1С» вы имеете ввиду платформу или разработчиков фирмы 1С?
Методология именно такая. К производительности многих механизмов типовых решений есть вопросы, особенно по работе с БД (скорость очень страдает от преобразований с языка запросов 1с на T-SQL и отсутствие возможности использовать DML). Но пока это не стало критическим в работе, данный принцип никому не мешает. Очень редко создается документ с >1000 строк. А если потребуется, не составит проблемы в 1с работать напрямую с регистрами или сделать механизм, чтобы работать со списком документов как с одним документом для построчной модификации регистра.
Строка документа может порождать «много» записей в регистре остатков(оборотов) — например, списание по партиям при партионном учете
Это цитата из их документации. Не отрицаю того факта, что как обычно бывает в 1С, есть еще сбоку куча костылей, которые позволяют это реализовать.
По регистр сведений не очень понял, чем это противоречит тому, что написано в статье. Можете привести конкретную цитату?
В отличие от регистра накоплений, регистр сведений рассчитывает не сумму показателя, а последнее значение действующее на определенное время.
Вы описали только периодический регистр сведений.
В индекс и в порядок добавляется сам регистр, так как, в отличие от 1С, в lsFusion могут быть записи с одинаковым временем.
В периодическом регистре в 1С могут быть записи с одинаковым временем по всем измерениям.
Это цитата из их документации.
Ну вот пришли… считайте это недосмотром 1С, все совсем по другому… желательно было дать почитать любому программисту 1С
Хорошо, изменил немного статью, чтобы соответствовать терминологии 1С.
Я конечно не специалист по 1С, но в других технологиях принято доверять официальной документации. Тем не менее, в статье не утверждается, что это нельзя реализовать.
Ну вот пришли… считайте это недосмотром 1С, все совсем по другому… желательно было дать почитать любому программисту 1С
Я конечно не специалист по 1С, но в других технологиях принято доверять официальной документации. Тем не менее, в статье не утверждается, что это нельзя реализовать.
но в других технологиях принято доверять официальной документации
Так вы ей не пользовались :( Приведенной вами цитаты:
Система обеспечивает контроль уникальности записей, хранящихся в регистре накопления. Благодаря этому в регистре накоплений не может находиться двух записей, относящихся к одной и той же строке одного и того же документа.
нет в официальной документации. В взяли рекламную информацию и решили, что это документация.
http://v8.1c.ru/overview/Term_000000176.htm
То есть вот это рекламные материалы? Странная реклама какая-то…
И как я понимаю, Вы утверждаете, что их рекламная информация не соответствует реальному положению дел? В чем еще они врут у себя на официальном сайте?
И что за официальная документация? Дайте на нее ссылку, пожалуйста…
То есть вот это рекламные материалы? Странная реклама какая-то…
И как я понимаю, Вы утверждаете, что их рекламная информация не соответствует реальному положению дел? В чем еще они врут у себя на официальном сайте?
И что за официальная документация? Дайте на нее ссылку, пожалуйста…
Я утверждаю, что рекламная и техническая информация — это не одно и тоже.
То, что они врут — это вы придумали (как в том анекдоте: это вам со страху показалось).
Ссылка на официальную документацию вот: its.1c.ru/db/v83doc Для использования нужна подписка на ИТС.
То, что они врут — это вы придумали (как в том анекдоте: это вам со страху показалось).
Ссылка на официальную документацию вот: its.1c.ru/db/v83doc Для использования нужна подписка на ИТС.
В 1С платная документация? Видимо, чтобы случайно начинающие разработчики не поняли, в какой треш они попадут. А дальше уже как South Park: «ты не сможешь выбросить то, за что уже заплачены деньги».
Раньше еще хуже было, сейчас хоть какую то документацию местами бесплатно открыли, ну, по крайней мере еще недавно часть документации точно открыта была, прямо сейчас не в курсе.
Никогда электронная документация не была в открытом доступе. Только по подписке на ИТС. Недавно открыли другие полезные материалы, но не доку.
На английском же есть :))
1c-dn.com/library/1c_enterprise_documentation
1c-dn.com/library/1c_enterprise_documentation
К сожалению, в англоязычном сегменте она никому не нужна, так как сама платформа никакой ценности без бухгалтерии и налогового учета (читай конфигурации) особо не несет. А этого добра там и своего хватает. Поэтому и документация открыта.
Мне всегда было интересно отношение 1С апологетов к Apple. Ведь Apple поступает же абсолютно также — у них все закрытое, проприетарное и платное. При этом фанаты Apple всем доказывают, что так и надо, а все остальное — говно. Как я понимаю все 1Совцы ходят с iPhone'ами?
Мне всегда было интересно отношение 1С апологетов к Apple. Ведь Apple поступает же абсолютно также — у них все закрытое, проприетарное и платное. При этом фанаты Apple всем доказывают, что так и надо, а все остальное — говно. Как я понимаю все 1Совцы ходят с iPhone'ами?
в англоязычном сегменте она никому не нужна, так как сама платформа никакой ценности без бухгалтерии и налогового учета (читай конфигурации) особо не несет.
Это вы сами придумали? Или данные имеете какие-то? Тут рядом ваш коллега утверждал, что никакой предвзятости в сторону 1С у вас нет :)
Как я понимаю все 1Совцы ходят с iPhone'ами?
У каждого минимум по два. И если они не самые свежие — штраф огромный. Иначе нельзя.
Это вы сами придумали? Или данные имеете какие-то? Тут рядом ваш коллега утверждал, что никакой предвзятости в сторону 1С у вас нет :)
А вы реально придумаете конкурентные преимущества у 1С хотя бы перед .Net. У последних хотя бы LINQ есть, а не пещерный век:
Код
СтруктураВременныеТаблицы = ДополнительныеСвойства.ДляПроведения.СтруктураВременныеТаблицы;
Запрос = Новый Запрос;
ОформлятьСначалаНакладные = Константы.ПорядокОформленияНакладныхРасходныхОрдеров.Получить() = Перечисления.ПорядокОформленияНакладныхРасходныхОрдеров.СначалаНакладные;
Запрос.УстановитьПараметр("ОформлятьСначалаНакладные", ОформлятьСначалаНакладные);
Запрос.УстановитьПараметр("Регистратор", Отбор.Регистратор.Значение);
Запрос.МенеджерВременныхТаблиц = СтруктураВременныеТаблицы.МенеджерВременныхТаблиц;
// Рассчитывается изменение нового набора относительно текущего с учетом накопленных изменений
// и помещается во временную таблицу.
Запрос.Текст =
"ВЫБРАТЬ
| ТаблицаИзменений.ДокументОтгрузки КАК ДокументОтгрузки,
| ТаблицаИзменений.Номенклатура КАК Номенклатура,
| ТаблицаИзменений.Характеристика КАК Характеристика,
| ТаблицаИзменений.Назначение КАК Назначение,
| ТаблицаИзменений.Серия КАК Серия,
| ТаблицаИзменений.Склад КАК Склад,
| ТаблицаИзменений.Получатель КАК Получатель,
| СУММА(ТаблицаИзменений.КОтгрузкеИзменение) КАК КОтгрузкеИзменение,
| СУММА(ТаблицаИзменений.СобираетсяИзменение) КАК СобираетсяИзменение,
| СУММА(ТаблицаИзменений.СобираетсяИзменение) КАК СобраноИзменение
|ПОМЕСТИТЬ ДвиженияТоварыКОтгрузкеИзменение
|ИЗ
| (ВЫБРАТЬ
| Таблица.ВидДвижения КАК ВидДвижения,
| Таблица.ДокументОтгрузки КАК ДокументОтгрузки,
| Таблица.Номенклатура КАК Номенклатура,
| Таблица.Характеристика КАК Характеристика,
| Таблица.Назначение КАК Назначение,
| Таблица.Серия КАК Серия,
| Таблица.Склад КАК Склад,
| Таблица.Получатель КАК Получатель,
| Таблица.КОтгрузкеПередЗаписью КАК КОтгрузкеИзменение,
| Таблица.СобираетсяПередЗаписью КАК СобираетсяИзменение,
| Таблица.СобраноПередЗаписью КАК СобраноИзменение
| ИЗ
| ДвиженияТоварыКОтгрузкеПередЗаписью КАК Таблица
|
| ОБЪЕДИНИТЬ ВСЕ
|
| ВЫБРАТЬ
| Таблица.ВидДвижения,
| Таблица.ДокументОтгрузки,
| Таблица.Номенклатура,
| Таблица.Характеристика,
| Таблица.Назначение,
| Таблица.Серия,
| Таблица.Склад,
| Таблица.Получатель,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА -Таблица.КОтгрузке
| ИНАЧЕ Таблица.КОтгрузке
| КОНЕЦ,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА Таблица.Собирается
| ИНАЧЕ -Таблица.Собирается
| КОНЕЦ,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА Таблица.Собрано
| ИНАЧЕ -Таблица.Собрано
| КОНЕЦ
| ИЗ
| РегистрНакопления.ТоварыКОтгрузке КАК Таблица
| ГДЕ
| Таблица.Регистратор = &Регистратор) КАК ТаблицаИзменений
|
|СГРУППИРОВАТЬ ПО
| ТаблицаИзменений.ВидДвижения,
| ТаблицаИзменений.ДокументОтгрузки,
| ТаблицаИзменений.Номенклатура,
| ТаблицаИзменений.Характеристика,
| ТаблицаИзменений.Назначение,
| ТаблицаИзменений.Серия,
| ТаблицаИзменений.Склад,
| ТаблицаИзменений.Получатель
|
|ИМЕЮЩИЕ
| (СУММА(ТаблицаИзменений.КОтгрузкеИзменение) > 0
| ИЛИ СУММА(ТаблицаИзменений.СобираетсяИзменение) > 0
| ИЛИ СУММА(ТаблицаИзменений.СобраноИзменение) > 0)
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| Т.Номенклатура КАК Номенклатура,
| Т.Характеристика КАК Характеристика,
| Т.Назначение КАК Назначение,
| Т.Серия КАК Серия,
| Т.Склад КАК Склад,
| Т.Склад КАК Получатель,
| СУММА(Т.УвеличениеПрихода) КАК УвеличениеПрихода
|ПОМЕСТИТЬ ДвиженияТоварыКОтгрузкеИзменениеСводно
|ИЗ
| (ВЫБРАТЬ
| Таблица.ВидДвижения КАК ВидДвижения,
| Таблица.Номенклатура КАК Номенклатура,
| Таблица.Характеристика КАК Характеристика,
| Таблица.Назначение КАК Назначение,
| Таблица.Серия КАК Серия,
| Таблица.Склад КАК Склад,
| Таблица.Склад КАК Получатель,
| -Таблица.ВРезервеКОтгрузкеПередЗаписью КАК УвеличениеПрихода
| ИЗ
| ДвиженияТоварыКОтгрузкеПередЗаписью КАК Таблица
|ГДЕ
| Таблица.Серия <> ЗНАЧЕНИЕ(Справочник.СерииНоменклатуры.ПустаяСсылка)
| И Таблица.Склад.КонтролироватьОперативныеОстатки
|
| ОБЪЕДИНИТЬ ВСЕ
|
| ВЫБРАТЬ
| Таблица.ВидДвижения,
| Таблица.Номенклатура,
| Таблица.Характеристика,
| Таблица.Назначение,
| Таблица.Серия,
| Таблица.Склад,
| Таблица.Получатель,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА Таблица.ВРезерве + Таблица.КОтгрузке
| ИНАЧЕ -Таблица.ВРезерве - Таблица.КОтгрузке
| КОНЕЦ
| ИЗ
| РегистрНакопления.ТоварыКОтгрузке КАК Таблица
| ГДЕ
| Таблица.Регистратор = &Регистратор) КАК Т
|ГДЕ
| Т.Серия <> ЗНАЧЕНИЕ(Справочник.СерииНоменклатуры.ПустаяСсылка)
| И Т.Склад.КонтролироватьОперативныеОстатки
|
|СГРУППИРОВАТЬ ПО
| Т.ВидДвижения,
| Т.Номенклатура,
| Т.Склад,
| Т.Получатель,
| Т.Характеристика,
| Т.Назначение,
| Т.Серия
|
|ИМЕЮЩИЕ
| СУММА(Т.УвеличениеПрихода) > 0
|;
|
|////////////////////////////////////////////////////////////////////////////////
|УНИЧТОЖИТЬ ДвиженияТоварыКОтгрузкеПередЗаписью";
ЗапросПакет = Запрос.ВыполнитьПакет();
Выборка = ЗапросПакет[0].Выбрать();
Выборка.Следующий();
// Новые изменения были помещены во временную таблицу.
// Добавляется информация о ее существовании и наличии в ней записей об изменении.
СтруктураВременныеТаблицы.Вставить("ДвиженияТоварыКОтгрузкеИзменение", Выборка.Количество > 0);
Выборка = ЗапросПакет[1].Выбрать();
Выборка.Следующий();
СтруктураВременныеТаблицы.Вставить("ДвиженияТоварыКОтгрузкеИзменениеСводно", Выборка.Количество > 0);И это не говоря про явную типизацию, ООП, замыкания и огромное community.
Т.е. данных у вас нет и вы решили просто поиграть в телевизионного «эксперта». Хм…
Если рассматривать Платформу как универсальное средство разработки — таких достоинств нет. Если рассматривать как инструмент, для которых этот инструмент создавался — ситуация сильно меняется и вопросов к .NET ну много возникнет. Потому, что и платформа и .NET и Go и прочие языки и фреймворки существуют не просто для удовлетворения мечтаний об ООП и т.д., а для решения конкретных задач. И перед Платформой ставится задача автоматизации экономической деятельности.
И платформа именно эту задачу вполне себе решает. Например тем, что дает готовые механизмы реализации очень большого количества вещей, которые нужны для решения задачи автоматизации бизнеса.
Как говорит один широко известный товарищ, давайте не путать «можно сделать» и «сделано». На .NET можно сделать и систему управления распределенными базами данных и регистры накопления, ПВХ, механизмы разделения и все-все-все.
НО. Сколько это времени и денег на этой уйдет? Кто будет этот продукт поддерживать, когда автору надоест дальше этот продукт развивать?
Т.е. ключевое преимущество Предприятия в данный момент — это заточенность для решения конкретных задач. А комьюнити — Россия и весь exUSSR, Польша, Вьетнам, Румыния, Турция, Китай (это из того, что сходу вспоминается). Внедрения решений на платформе — там десятки стран. Да, оно не такое обширное, как у .NET, но оно есть и растет.
Если рассматривать Платформу как универсальное средство разработки — таких достоинств нет. Если рассматривать как инструмент, для которых этот инструмент создавался — ситуация сильно меняется и вопросов к .NET ну много возникнет. Потому, что и платформа и .NET и Go и прочие языки и фреймворки существуют не просто для удовлетворения мечтаний об ООП и т.д., а для решения конкретных задач. И перед Платформой ставится задача автоматизации экономической деятельности.
И платформа именно эту задачу вполне себе решает. Например тем, что дает готовые механизмы реализации очень большого количества вещей, которые нужны для решения задачи автоматизации бизнеса.
Как говорит один широко известный товарищ, давайте не путать «можно сделать» и «сделано». На .NET можно сделать и систему управления распределенными базами данных и регистры накопления, ПВХ, механизмы разделения и все-все-все.
НО. Сколько это времени и денег на этой уйдет? Кто будет этот продукт поддерживать, когда автору надоест дальше этот продукт развивать?
Т.е. ключевое преимущество Предприятия в данный момент — это заточенность для решения конкретных задач. А комьюнити — Россия и весь exUSSR, Польша, Вьетнам, Румыния, Турция, Китай (это из того, что сходу вспоминается). Внедрения решений на платформе — там десятки стран. Да, оно не такое обширное, как у .NET, но оно есть и растет.
Т.е. данных у вас нет и вы решили просто поиграть в телевизионного «эксперта». Хм…
Нет, это именно в процессе изучения 1С. И я на это потратил куда больше времени, чем любой потенциальные англоязычный пользователь.
И платформа именно эту задачу вполне себе решает. Например тем, что дает готовые механизмы реализации очень большого количества вещей, которые нужны для решения задачи автоматизации бизнеса
Какие механизмы? Как в примере что я написал? Запросы прямо в строке? Так уже лет 10 никто не пишет. Это привет 90е.
систему управления распределенными базами данных
Кому она нужна в 21 веке то?
регистры накопления
MATERIALIZED INDEXED VIEW даже в MS SQL умеет куда больше
ПВХ, механизмы разделения и все-все-все.
Ага и отказ от SQL механизмов (аналитических / табличных функций, замыканий), которые умеют куда больше чем 1С.
НО. Сколько это времени и денег на этой уйдет? Кто будет этот продукт поддерживать, когда автору надоест дальше этот продукт развивать?
.Net цев как грязи. Где вы столько 1Сцев найдете?
Польша, Вьетнам, Румыния, Турция, Китай (это из того, что сходу вспоминается)
Это кто вам такой бред сказал. Посмотрите количество вакансий 1С в Польше, Китае и Турции.
Внедрения решений на платформе — там десятки стран. Да, оно не такое обширное, как у .NET, но оно есть и растет.
По пять штук? Ну ну. И что там внедряют УТ? Где половину российского функционала, вроде ЕГАИС и интеграции с российской же бухгалтерией, которая в китае нафиг не нужна?
Понимаете в чем дело… По данному обсуждению я вижу следующие факты: 1. не вы, не ваши рекламщики Платформу не знаете (вы даже в рекламном сравнении врете) 2. вы считаете, что мир монохромный, а это не так. 3. у меня есть некоторые сомнения в том, что лично вы знаете как работает рынок автоматизации, на что там обращают внимание и за что платят.
Когда вам говорят про те места, где вы неправы — вы надеваете каску и начинаете говорить про неполноценность свои оппонентов.
Давайте вы или будете все-таки корректно общаться или стоит завершить разговор.
И да, почти все мои высказывания можно подтвердить разными ссылками…
Когда вам говорят про те места, где вы неправы — вы надеваете каску и начинаете говорить про неполноценность свои оппонентов.
Давайте вы или будете все-таки корректно общаться или стоит завершить разговор.
И да, почти все мои высказывания можно подтвердить разными ссылками…
не вы, не ваши рекламщики Платформу не знаете (вы даже в рекламном сравнении врете)
Ну вы тоже lsFusion не знаете. Но я то конкретные вопросы задаю, а вы вместо того чтобы ответить, как это сделать, и почему разработчики типовых так не сделали, отвечаете: «вы просто не знаете платформу», «у разработчиков типовых были свои причины». В таком ключе действительно нет смысла продолжать разговор.
у меня есть некоторые сомнения в том, что лично вы знаете как работает рынок автоматизации, на что там обращают внимание и за что платят.
Ну я в этом бизнесе уже 21 год, и напрямую учавствовал в продаже, внедрении и поддержке нескольких сотен в сумме проектов, от заводов до фондов. И кстати к примеру на дизайн никто не жаловался, всех интересуют стоимость, скорость доработок, возможность бесшовного перехода с существующих систем и т.п.
Когда вам говорят про те места, где вы неправы — вы надеваете каску и начинаете говорить про неполноценность свои оппонентов.
На личности кстати вы переходите, равно как и на аргументацию в стиле:
И да, почти все мои высказывания можно подтвердить разными ссылками…
Ну так подтвердите раз можно.
Ну вы тоже lsFusion не знаете.
Так вы же про других врете :) Как вы про lsFusion
На личности кстати вы переходите
Я не перехожу. Ибо ваши личностные качества я не затрагивал. Моя аргументация немного отличается от этой:
«1С умудрился накосячить как раз во всем в чем мог.»
«Это кто вам такой бред сказал.»
«в англоязычном сегменте она никому не нужна, так как сама платформа никакой ценности без бухгалтерии и налогового учета (читай конфигурации) особо не несет»
«И я на это потратил куда больше времени, чем любой потенциальные англоязычный пользователь.»
Человек, который в этом бизнесе 21 год — он, обычно, говорит ну совсем другие слова. По крайней мере такой человек значительно менее монохромен :) Он знает, мир сложен и многообразен
Ну так подтвердите раз можно.
Зачем? Вам же этого не надо. Вы уже знаете, что 1с гавно.
Так вы же про других врете :) Как вы про lsFusion вретеговорите — я не знаю :)
Ничего не понял.
Человек, который в этом бизнесе 21 год — он, обычно, говорит ну совсем другие слова. По крайней мере такой человек значительно менее монохромен :) Он знает, мир сложен и многообразен
Я это знаю. Собственно ирония в том, что из этих нескольких сотен проектов, для большинства продажа, как и внедрение были по своему уникальным кейсом.
Но многообразие чего-либо, не означает, что это что-либо не надо анализировать, систематизировать, оценивать, а главное сравнивать друг с другом. В противном случае непонятно как вообще принимать какие-то решения на этом рынке.
Плюс все что я спрашиваю в этих комментариях, я делаю не для того чтобы «потопить» конкурентов (поверьте после первого дня эти комменты мало кто читает), а именно чтобы разобраться как именно у них все работает. И опыт показал, что если человек не может быстро и просто ответить на вопрос, то этого ответа, во всяком случае у него, попросту нет.
Плюс сейчас мы готовим более объемную статью про 1С в стиле этой, и нам на самом деле важно получить ответы на интересующие нас вопросы. Например как в динамическом списке добавить редактируемое поле (смотри комменты к предыдущей статье), или как сделать ограничение в 1С.
Ничего не понял.
Что вы не поняли?
Хорошо, скажу по-другому: ваше сравнение lsFusion с другими продуктами содержит ложь про другие продукты. Указывать где эта ложь я вам не буду (зачем жизнь облегчать?).
чтобы разобраться как именно у них все работает.
Когда хотят разобраться — спрашивают по-другому. Ваши примеры вопросов я показал :)
Плюс сейчас мы готовим более объемную статью про 1С в стиле
Последний совет — не делайте ее. По-крайней мере в сравнении с другим (любым) продуктом. У вас это плохо получается. Напишите про то, как вы классно решили какую-то вашу проблему (и почему именно так, без сравнения с другими) — и это будет интересно и позитива будет сильно больше.
это будет интересно и позитива будет сильно больше.
Так и в этой позитива много. Посмотрите на плюс 21 в статье и всего один минус.
Хорошо, скажу по-другому: ваше сравнение lsFusion с другими продуктами содержит ложь про другие продукты. Указывать где эта ложь я вам не буду (зачем жизнь облегчать?).
Ага, знаю, но вам не скажу. Плавали, знаем.
Забавно, что, например, ораклоиды реагируют наоборот, что большинство прочитают и поверят, и поэтому сразу бросаются разъяснять, что именно не так. Но 1Сцы видимо на своей волне.
Когда хотят разобраться — спрашивают по-другому. Ваши примеры вопросов я показал :)
Там знак вопроса в конце стоит?
Я кучу вопросов сверху задавал, и про ограничения, и про редактирование динамических списков, и про пример простенького склада на 1с. Но все неудобные вопросы 1с разработчики странным образом игнорируют, ограничиваясь ответами: «вы просто не знаете платформу», «у разработчиков типовых были свои причины».
Последний совет — не делайте ее. По-крайней мере в сравнении с другим (любым) продуктом. У вас это плохо получается. Напишите про то, как вы классно решили какую-то вашу проблему (и почему именно так, без сравнения с другими) — и это будет интересно и позитива будет сильно больше.
Посмотрим. Почему не SQL? отлично зашла, лучшее за все время в нескольких хабах (ну или на первой странице).
В любом случае, «чтобы купить что-то не нужное, нужно продать что-то не нужное». И проблему прежде всего нужно показывать на примере существующих решений, иначе проблема надуманна по определению.
Ага, знаю, но вам не скажу. Плавали, знаем.
Пока вы мне про бред не рассказывали — тоже сказать хотел. Но кажется, что вам помогать не нужно.
Пока вы мне про бред не рассказывали — тоже сказать хотел. Но кажется, что вам помогать не нужно.
Честно не хотел никого обидеть. Просто два дня обсуждений в этой и предыдущей статье отбили хоть какую то надежду услышать в комментариях хоть что-то конструктивное, поэтому вспылил немного. Так что придется довериться методическому пособию, документации, типовым ну и учебной версии платформы.
Да пусть пишут. Хайпанут лишний раз, почешут своё ЧСВ. Потом поймут, как и остальные, кто таким путем пошел, что только время зря потратили.
Оно а) не на русском и б) не очень последнее, так скажем.
del
Это цитата из их документации. Не отрицаю того факта, что как обычно бывает в 1С, есть еще сбоку куча костылей, которые позволяют это реализовать.
ВЫ просто её(цитату) неверно поняли. Строка документа и строка регистра — это разные вещи.
По регистр сведений не очень понял, чем это противоречит тому, что написано в статье. Можете привести конкретную цитату?
Не противоречит, просто регистров сведений есть несколько видов, каждый со своей спецификой, а не только тот вид, который описан.
Строка документа может порождать «много» записей в регистре остатков(оборотов) — например, списание по партиям при партионном учете
И? Так и агрегаций можно много создавать порождая «много записей в регистре»
Есть промежуточные итоги, а не только актуальные.
И? Никто не мешает и промежуточные итоги создавать. Скажем:
balance(Stock st, SkuGroup sk) = GROUP SUM balance(st, Sku sku) IF skuGroup(sku) = sk MATERIALIZED;
Расскажите как кстати такие промежуточные итоги в 1С делать (чтобы они еще хранились)
В 1С регистр сведений:
То есть в 1С регистры сведений просто таблица с несколькими ключами. И? Какое отношение это к наследованию и полиморфизму имеет.
Комментарий — маркетинговая фигня.
p.s. слава богу в 1С нет ООП. Незачем ООП тащить в DSL — чем проще, тем лучше.
Ага, а потом открываешь УТ и кровь из глаз идет, от огромного количества if'ов в стиле:
ЕстьИзмененияВТаблице(ДанныеТаблиц,«ДвиженияТоварыКОтгрузкеИзменениеСводно»)
СтруктураДействий.Свойство(«ПересчитатьКоличествоУпаковокПоФакту»)
Разговор немого с глухими…
Я описал недочёты(ошибки) в статье, которые кардинальным образом влияют на функционал.
Давайте напишем какая 1С говно — и на этом фоне прорекламируем себя?
Подавляющие большинство программистов будет кивать гривами(бородой), соглашаться и ставить плюсы.
Давайте напишем какая 1С говно — и на этом фоне прорекламируем себя?
Подавляющие большинство программистов будет кивать гривами(бородой), соглашаться и ставить плюсы.
Не поверите, но все новые продукты выходят на рынок в сравнении с существующими продуктами. Хотя конкретно эта статья это так — один маленький кейс, у 1С есть куда более фундаментальные проблемы.
Ну проблемы может и есть… Но с другой стороны я не знаю ни одной системы сравнимой с 1С по возможностям и технологиям в одном флаконе, которые доступны сразу из коробки…
Все понятно, что на си шарпе или еще на чемто это все можно реализовать, вопрос в какие сроки и какой кровью…
Все понятно, что на си шарпе или еще на чемто это все можно реализовать, вопрос в какие сроки и какой кровью…
Не знаю, но я сейчас смотрю код УТ и у меня кровь из глаз идет. Я тут в комментах приводил отрывки кода для решения отдельных мелких задач, типа проверки ограничений, организации flow и т.п.
Ведь по сути 1С одновременно отказались от ORM, всех стандартов SQL после 92 года (аналитических функций, рекурсивных CTE, представлений), автоматических блокировок (CI в ACID), автоматического control flow, автоматического обеспечения синхронности. При этом не добавив ни типизации, ни наследования, ни замыканий, ни аналога LINQ. То есть выкинули все лучшее что может быть в платформах высокого уровня, не взяв ничего лучшего из языков общего назначения. Да с ними кто угодно сравнится. Даже .Net, не говоря уже о lsFusion.
Ведь по сути 1С одновременно отказались от ORM, всех стандартов SQL после 92 года (аналитических функций, рекурсивных CTE, представлений), автоматических блокировок (CI в ACID), автоматического control flow, автоматического обеспечения синхронности. При этом не добавив ни типизации, ни наследования, ни замыканий, ни аналога LINQ. То есть выкинули все лучшее что может быть в платформах высокого уровня, не взяв ничего лучшего из языков общего назначения. Да с ними кто угодно сравнится. Даже .Net, не говоря уже о lsFusion.
Это с точки зрения языка… А с точки зрения возможностей?
Часто Вы видели реально живую трехзвенку? Причем которая работает на нескольких типах SQL серверов? Ну и под разными платформами?
Которая имеет как толстого, так и веб клиента, которые работают без переписывания исходного кода?
Часто ли вы видели чтобы один и тот же код можно было запустить как на толстом клиенте, так и в мобильной аппликухе, даже если учесть ограничения?
Что-то мне подсказывает, что ее недостатки это следствие ее достоинств…
Это с технической точки зрения…
А с практической — где можно заработать денег больше и проще (мы же ведь работаем, а не развлекаемся) и быстрее удовлетворить заказчика? Не считая обучения персонала, который будет работать с этим…
Попробуйте повторить ту же УТ на Net… Не вопрос, что может УТ было бы проще даписать на Net, но ее нет под Net… И думаю что и не будет.
Часто Вы видели реально живую трехзвенку? Причем которая работает на нескольких типах SQL серверов? Ну и под разными платформами?
Которая имеет как толстого, так и веб клиента, которые работают без переписывания исходного кода?
Часто ли вы видели чтобы один и тот же код можно было запустить как на толстом клиенте, так и в мобильной аппликухе, даже если учесть ограничения?
Что-то мне подсказывает, что ее недостатки это следствие ее достоинств…
Это с технической точки зрения…
А с практической — где можно заработать денег больше и проще (мы же ведь работаем, а не развлекаемся) и быстрее удовлетворить заказчика? Не считая обучения персонала, который будет работать с этим…
Попробуйте повторить ту же УТ на Net… Не вопрос, что может УТ было бы проще даписать на Net, но ее нет под Net… И думаю что и не будет.
Это с точки зрения языка… А с точки зрения возможностей?
Часто Вы видели реально живую трехзвенку? Причем которая работает на нескольких типах SQL серверов? Ну и под разными платформами?
Которая имеет как толстого, так и веб клиента, которые работают без переписывания исходного кода?
Часто ли вы видели чтобы один и тот же код можно было запустить как на толстом клиенте, так и в мобильной аппликухе, даже если учесть ограничения?
Видел. Я более того скажу, что lsFusion умеет это все и даже больше. И работает на таких объемах, где конкурентов на 1с нет и не предвидится (только в распределенных базах)
Что-то мне подсказывает, что ее недостатки это следствие ее достоинств…
Нет, все это можно было реализовать без отказа от всех тех прелестей жизни, что я описал. Но они решили что разработчики и так съедят. И были правы. Съели и не заметили.
А с практической — где можно заработать денег больше и проще (мы же ведь работаем, а не развлекаемся) и быстрее удовлетворить заказчика? Не считая обучения персонала, который будет работать с этим…
Попробуйте повторить ту же УТ на Net… Не вопрос, что может УТ было бы проще даписать на Net, но ее нет под Net… И думаю что и не будет.
Мы повторили. Не 1-в-1 конечно, у нас есть много вещей которых у них нет, ну и наоборот. Но тут важнее другое, мы можем кастомизировать под заказчика, так что у него будет только 60% из общего функционала (причем можно не брать ненужный общий функционал, чего в УТ к примеру нельзя сделать) и 40% своего. Как что-то дописывать / изменять в УТ для меня загадка? Там реально страшно что-то трогать, потому как непонятно что при этом сломается. Никаких проверок типов, в частности нет, ну и всю жутко императивно сделано.
Хотя уверен что УТ можно и на .Net повторить. Вы же в курсе что 1С это чисто российская фишка, то есть <1% мирового рынка. Остальной мир живет же как-то.
Видел. Я более того скажу, что lsFusion умеет это все и даже больше. И работает на таких объемах, где конкурентов на 1с нет и не предвидится (только в распределенных базах)
Это сколько? В документах/терабайтах?
Съели и не заметили.
Заметили. И что? Если задача поставить именно 1С?
Мы повторили.
Невопрос. И сколько клиентов и каких размеров у вас есть?
Там реально страшно что-то трогать, потому как непонятно что при этом сломается. Никаких проверок типов, в частности нет, ну и всю жутко императивно сделано.
Ну тут без вопросов… Хотя такое легко и на ООП ломается…
Вы же в курсе что 1С это чисто российская фишка, то есть <1% мирового рынка. Остальной мир живет же как-то.
Кож спорит… Процессинги на КОБОЛе и подобном работают до сих пор… ИБМ не просто так же до сих пор майнфреймы выпускает…
А реальные примеры? Со сравнением? Типовые конфигурации?
На сайт lsFusion я зашел… Не нашел мобильных приложений, не нашел толстого клиента… Вообще не понял какой язык используется…
Это сколько? В документах/терабайтах?
3,5 млн инвойсов, 35 млн строк инвойсов. И это я не самого большого клиента взял. Чеков на самом деле уже давно больше млрда, это статистика для внутреннего оптимизатора (ее нет смысла обновлять).
Заметили. И что? Если задача поставить именно 1С?
Заказчику обычно все равно на чем решение, ему главное чтобы работало.
Невопрос. И сколько клиентов и каких размеров у вас есть?
Даже тут уже отвечали несколько раз вроде. Около 40, но достаточно крупных от 50 одновременных пользователей. Около десятка 400-1000 одновременных пользователей.
Ну тут без вопросов… Хотя такое легко и на ООП ломается…
Одним ООП проблему декомпозиции сложности не решить, нужны еще события, ограничения, расширения и т.п.
А реальные примеры? Со сравнением? Типовые конфигурации?
Сравнение чего? Сравнение платформ тут. Решения тут, под них будет отдельный сайт, так как мы их напрямую не связываем. Но там не совсем понятно что сравнивать, модули практически те же что и в ут. А формы сравнивать это уже странновато будет.
Толстый клиент (справа снизу):
Справа снизу. Для мобильных react обычно используем, тут немного подробнее.
Еще вопрос — почему сравнение идет с 1С 8.2 а не 8.3? 8.2 давно устарела…
Ну и второй вопрос — насколько большой рынок труда для програмиста на этой системе? Это как бы тоже немаловажный параметр, потому что изучить какую-то систему — это не взять какуюто крутую дополнительную библиотеку к известному языку…
Т.к. при использовании библиотеки — ты остаешься специалистом по этому языку, и знания можно применить и в других направлениях/фирмах.
Поэтому у вас есть шанс так и остаться узкоспециализированным решением. А 1С со своими недостатками будет продолжать жить и развиваться…
Ну и второй вопрос — насколько большой рынок труда для програмиста на этой системе? Это как бы тоже немаловажный параметр, потому что изучить какую-то систему — это не взять какуюто крутую дополнительную библиотеку к известному языку…
Т.к. при использовании библиотеки — ты остаешься специалистом по этому языку, и знания можно применить и в других направлениях/фирмах.
Поэтому у вас есть шанс так и остаться узкоспециализированным решением. А 1С со своими недостатками будет продолжать жить и развиваться…
Еще вопрос — почему сравнение идет с 1С 8.2 а не 8.3? 8.2 давно устарела…
Я сравниваю как раз с 8.3. Потому как именно там они от модальности отказались. Все жду, что они в 8.4 от if'ов еще откажутся и перейдут на goto. И назовут управляемыми переходами. И самое смешное, что разработчики и это съедят, рынок же.
Ну и второй вопрос — насколько большой рынок труда для програмиста на этой системе? Это как бы тоже немаловажный параметр, потому что изучить какую-то систему — это не взять какуюто крутую дополнительную библиотеку к известному языку…
Т.к. при использовании библиотеки — ты остаешься специалистом по этому языку, и знания можно применить и в других направлениях/фирмах.
Поэтому у вас есть шанс так и остаться узкоспециализированным решением. А 1С со своими недостатками будет продолжать жить и развиваться…
Ну в Беларуси не пропадете уже. В России вопрос времени. 1С тоже в свое время был узкоспециализированным решением.
Но шанс есть всегда, мы то в любом случае его будем развивать, мы на этом сейчас деньги зарабатываем, и пока проблем с этим даже в очень долгосрочной перспективе не предвидится (у нас уже достаточно большой диверсифицированный пул крупных клиентов на самом устойчивом к кризисам рынке)
Я имею в виду по ссылке в коментарии тут. Там именно 8.2
1С года с момента появления 7.7 перестала быть узкоспециализированной… А это было ну очччень давно…
1С года с момента появления 7.7 перестала быть узкоспециализированной… А это было ну очччень давно…
Там >=8.2. Не очень давно 1С воспринимали именно как решение для бухгалтерии (да и сейчас многие так делают). Лет 15 назад только это начало меняться.
Ну
Время летит быстро ;) 15 лет назад это 2004 год — в этом году уже массово были конфигурации под разные учетные нужды…
1С как была так и есть программа для учетных, управленческих и околобухгалтерских дел. Как была так и осталась… В них она и хороша.
Там >=8.2.означает что вы не делаете отличий между 8.2 и 8.3, а они реальные и большие в возможностях.
Лет 15 назад
Время летит быстро ;) 15 лет назад это 2004 год — в этом году уже массово были конфигурации под разные учетные нужды…
1С как была так и есть программа для учетных, управленческих и околобухгалтерских дел. Как была так и осталась… В них она и хороша.
означает что вы не делаете отличий между 8.2 и 8.3, а они реальные и большие в возможностях.
Так ирония в том, что как раз в фундаментальных вещах 1с по сути деградирует:
Отказались от ORM, Отказались от автоматических блокировок, Отказались от обычного приложения, Отказались от обычных форм, Отказались от синхронности / модальности. Все на протяжении от 8.1-8.3. Причем по факту они не решили проблемы, а просто переложили их на разработчика. Просто заменив слово ручные на управляемые.
То до чего производители ручных коробок передач кстати не додумались. Надо было управляемыми их назвать и продвигать как возможность, а не лишнее действие.
Отказались от ORM, Отказались от автоматических блокировок,
Ну можно включить. Но под большой нагрузкой будут проблемы. Вы же не расстраиваетесь. когда надо на постгрессе самому начать транзакцию, заблокировать нужные записи и закомитить?
Отказались от ORMта по сути 1с и есть она большая орм… Раздражает язык запросов… это да… Но все равно это вопрос привычки.
Отказались от обычного приложения, Отказались от обычных форм,
Это где они отказались? Легко можно создать обычную форму… Только вот в вебе и на мобилке она работать не будет. На винде — пожалуйста
Ну можно включить. Но под большой нагрузкой будут проблемы. Вы же не расстраиваетесь. когда надо на постгрессе самому начать транзакцию, заблокировать нужные записи и закомитить?
Так в этом и фокус. Что можно было сделать нормально как в lsFusion (я приводил уже объемы) и никаких проблем не было бы.
PS: На постгерс как раз не надо блокировать нужные записи, на update conflict'ы как правило полагаются.
та по сути 1с и есть она большая орм… Раздражает язык запросов… это да… Но все равно это вопрос привычки.
Так в том то и дело, что сейчас решения на 1с это pure sql, причем года так 92. Непонятно зачем тут вообще 1с, в таком стиле и на php писать можно.
Это где они отказались? Легко можно создать обычную форму… Только вот в вебе и на мобилке она работать не будет. На винде — пожалуйста
Я сейчас на 8.3 в учебной версии ОткрытьФормуМодально сделал, и она уже ошибку выдала (нужно вручную переключать режим). Вы же понимаете что выпиливание обычных форм и других режимов вопрос времени, причем не очень далекого (судя по их риторике).
Что можно было сделать нормально как в lsFusion (я приводил уже объемы) и никаких проблем не было бы.
Посмотрим на вас лет через 15 развития системы… Если она будет иметь кучу инсталляций и будетраспростронена, как 1С… что у вас там будет…
1с это pure sql,
Ну когда она была 7.7 это было еще хуже… А что — лучше ОРМ или прямой скл — это большой вопрос…
Я сейчас на 8.3 в учебной версии ОткрытьФормуМодально сделал, и она уже ошибку выдала (нужно вручную переключать режим)
Ну я думаю что если в вашей системе написать какую-то хрень она тоже не переварит.
выпиливание обычных форм и других режимов вопрос времени, причем не очень далекого
Та кто его знает… Кроме того я не сказал бы, что под новые формы писать тяжелее… Я бы сказал — что легче… Правда мышление надо несколько переделывать, это да… Но это такое…
Вот модульность да, это слабое место 1С, особенно в типовых. Концентрируйтесь на своих реальных преимуществах для бизнеса, а не для разработчиков.
Мы пока прощупываем рынок, до кого проще достучаться. Хотя учитывая, что основной рынок IT в мире — англоговорящий, может это и пустая трата времени. Там вроде все по другому работает.
Конечно пустая. Потеснить 1С можно, но затраты на это будут намного выше, чем полученный профит…
Тут то как раз фокус, что рынок высокомаржинальный, пяток относительно крупных проектов отбивают и все премиум акаунты, и пиар во всех сми, и контент менеджеров, и людей которые в каждой ветке будут дискуссии устраивать. Под пустой тратой времени я имел ввиду, что если рынок более восприимчив к инновациям, нет смысла доказывать что-то тем, кто изначально негативно настроен.
В этом смысле вот что весьма забавно. У нас есть небольшие проекты с американцами, и по опыту они очень легки на подъем: давайте это попробуем, и это попробуем. Их надо наоборот убеждать, зачем вам это надо.
А на постсовке все с точностью до наоборот. У нас с одним заказчиком переговоры 2 (!) года шли, хотя у него практически никаких других вариантов не было.
В этом смысле вот что весьма забавно. У нас есть небольшие проекты с американцами, и по опыту они очень легки на подъем: давайте это попробуем, и это попробуем. Их надо наоборот убеждать, зачем вам это надо.
А на постсовке все с точностью до наоборот. У нас с одним заказчиком переговоры 2 (!) года шли, хотя у него практически никаких других вариантов не было.
Если рассматривать вариант — внедрение с нуля, то да. А вот если рассматривать переход с уже существующей системы — всё становится уже не так радужно. Ну и я всё равно никак не могу понять, кто ваш клиент в России, который будет выбирать между коробками 1С и заказной разработкой на вашей платформе.
Еще раз. Вы всерьез полагаете, что мы с нуля все проекты разрабатываем? Нет у нас за 12 лет, есть набор из сейчас наверное 1300 кубиков (модулей, количество которых постоянно растет) из которых мы как из лего собираем сначала базовое решение, а потом донастраиваем под конкретного заказчика (хотя у 30% клиентов что по меньше идет как есть).
Вопрос, в том можно ли считать на текущий момент ERP продуктом? На мой взгляд можно (особенно ближе познакомившись с УТ), но не я принимаю решения в этом плане.
Хотя в целом я за продвижение ERP именно как полуфабрикат / конструктор. Вы из кубиков (подключая нужный подграф модулей как 30 так и 800) собираете ровно то что вам надо, плюс по мелочам кастомизируете под конкретные требования. То есть такой серийный custom made получается. И не ешьте что дают, но и по срокам стоимости достаточно быстро / дешево. Собственно это мы сейчас и продаем и пока вроде достаточно успешно.
Вопрос, в том можно ли считать на текущий момент ERP продуктом? На мой взгляд можно (особенно ближе познакомившись с УТ), но не я принимаю решения в этом плане.
Хотя в целом я за продвижение ERP именно как полуфабрикат / конструктор. Вы из кубиков (подключая нужный подграф модулей как 30 так и 800) собираете ровно то что вам надо, плюс по мелочам кастомизируете под конкретные требования. То есть такой серийный custom made получается. И не ешьте что дают, но и по срокам стоимости достаточно быстро / дешево. Собственно это мы сейчас и продаем и пока вроде достаточно успешно.
Вы про внедрение в целом, я же про рынок 1С, от которого вы хотите откусить малую толику. Для этого рынка даже описанное вами — это заказная разработка.
Так вы же понимаете, что этот процесс можем не только мы выполнять. Даже у нас сейчас компания занимающаяся платформой, и компания занимающаяся
решениями (их даже несколько уже по сути) это разные люди. И компания с решениями работает и конкурирует с компаниями продающими 1С. Но последние по сути коробки продают (которые сейчас по сути уже не нужны, они на растущем рынке в основном продаются, так как сейчас у всех все уже автоматизировано), а мы на lsFusion custom made продаем по адекватной цене даже по сравнению с коробками.
решениями (их даже несколько уже по сути) это разные люди. И компания с решениями работает и конкурирует с компаниями продающими 1С. Но последние по сути коробки продают (которые сейчас по сути уже не нужны, они на растущем рынке в основном продаются, так как сейчас у всех все уже автоматизировано), а мы на lsFusion custom made продаем по адекватной цене даже по сравнению с коробками.
Это хорошо. Но, всё-таки, можете описать абстрактно, какие бизнесы в России как-то автоматизированные на текущий момент, ваши потенциальные клиенты?
Ну сейчас конкретно, это рынки, который мы знаем и понимаем: FMCG сети — там где сейчас Супермаг, Gestori, самописки, Астор и т.п. И заказные разработки, где сейчас excel, всякие нестандартные CRM / billing / project management и т.п.
Не думаю, что сети, до сих пор работающие на Джестори, могут позволить себе смену программы автоматизации. Они скорее всего с околонулевой рентабельностью работают. Знаю вокруг в городе милионнике 3 примерно такие сетки, сдохшие за 2 последних года.
2 экономических и один фискальный кризис научили меня тому, что у продовольствственной розницы деньги есть всегда. И чем их меньше тем лучше, тогда они с меньшей вероятностью принимают глупые финансовые решения вроде найма своего IT отдела или покупки sap, платных СУБД или коробочных решений. При этом они ещё больше заботятся об эффективности своей работы, а в fmcg рознице это возможно только за счёт it и поэтому серийный дешёвый custom made им заходит на ура. Проверено опытом. У нас лучшие продажи были во времена кризисов.
Ситуация сейчас другая. Крупные федеральные сети давят и поглощают мелкие, контроль со стороны государства с вводом онлайн касс вырос, всё идёт к тому, что останется только крупняк, Ашоты с 1-2 магазинами и полунищая розница типа облпотребсоюзов в глухих сёлах. Среди них потенциальных клиентов lsFusuon я никак не вижу.
А вы давно на этом рынке?
На самом деле у первых 10 сетей всего 30 процентов рынка. У нас у одной 20. И рост на 3 процента в год. То есть даже 50 процентов лет через 5 только сети достигнут. Так что место больше чем достаточно. Но поживем увидим.
Откуда у вас такие данные? Можете подтвердить какой-нибудь ссылкой?
Из приведенной ссылки кстати:
Что-то не похоже, что крупные сети под себя все подминают.
Начиная с 2008 г., на российском рынке сетевой продовольственной розницы доминировали федеральные операторы, обеспечивающие около 47-48% оборота торговых сетей. Однако в 2018 г., по предварительной оценке M.A. Research, федеральные сети сформировали 45% рынка сетевого FMCG-ритейла в РФ, в то время как доля региональных операторов выросла до 46%.
Региональные FMCG-сети наиболее многочисленны и разнообразны по объему выручки и количеству магазинов. Среди них есть крупные сети, входящие в топ-10 и топ-15 торговых сетей, но большая часть сетей насчитывает порядка 5-20 магазинов небольшого формата.
Что-то не похоже, что крупные сети под себя все подминают.
Не видя полного исследования сложно что-то сказать. Возможно, в некоторых регионах одна крупная местная сеть успешно противостоит федералам. У нас, в Нижегородской области таковой является сеть Спар компании Сладкая Жизнь (кстати, работают на 1С, если что) Кроме них и федералов больше сетей крупнее 4-5 магазинов не наблюдается.
Не видя полного исследования сложно что-то сказать
Но при этом вы уверенно заявляете:
Ситуация сейчас другая. Крупные федеральные сети давят и поглощают мелкие, контроль со стороны государства с вводом онлайн касс вырос, всё идёт к тому, что останется только крупняк, Ашоты с 1-2 магазинами и полунищая розница типа облпотребсоюзов в глухих сёлах. Среди них потенциальных клиентов lsFusuon я никак не вижу.
Есть еще много исследований на эту тему с теми же выводами. Ну и наш внутренний market research их подтверждает. Хотя возможно у вас в нижегородской области все по другому. Но это типичный «эффект окружения».
кстати, работают на 1С, если что
Кстати интересно на чем? Астор? Далион? Магазька? Или УТ + Розница в РИБ?
В ситуации «одна региональная сеть противостоит федералам» вам всё равно ничего не светит. Если эта сеть выжила — значит с автоматизацией там всё в порядке.
В Спарах что на фронте не знаю, в бэке самописка на 1С, и WMS на 1С. WMS, кстати, обрабатывает примерно 250 тыс. строк заказов на отгрузку в сутки, и не тормозит :))
В Спарах что на фронте не знаю, в бэке самописка на 1С, и WMS на 1С. WMS, кстати, обрабатывает примерно 250 тыс. строк заказов на отгрузку в сутки, и не тормозит :))
Если эта сеть выжила — значит с автоматизацией там всё в порядке.
Поверьте, все не так просто, у нас большой опыт в этом вопросе. В любом случае, поживем, увидим. Спасибо за информацию.
PS: Кстати а у них единая база или распределенная. И по RDP или тонкий клиент?
Не нашёл там 30%. 47-48 вроде…
Ничего страшного. Хватит и половины российского рынка. Вы скорее динамику посмотрите. Или они 10 лет концы с концами сводят, но никак не сведут?
Там прямо в заголовке 17. 47-48 это федеральные но это и по 20 магазинов сети, просто у которых в нескольких регионах магазины. Если чуть глубже копнуть видно что, экспоненциально выручка в топе убывает.
И кстати там же есть картинка, что рост процента доли рынка топ 10 сетей остановился в последние пару лет.
слава богу в 1С нет ООП. Незачем ООП тащить в DSL — чем проще, тем лучше.
Не соглашусь. Положим, наследовать объекты может и действительно нужно раз в 10 лет, но инкапсуляции реально не хватает.
Ну как сказать проще… Отсутствие ООП в 1С порождает огромное количество дублирующего кода. Платформе 1С на это фиолетово, а вот программисту сидеть во всей этой каше разбираться — занимает немало времени. Система, представленная автором статьи, как я понимаю, лишена этого недостатка
При чем ООП и дублирование кода?
В 1С есть общие модули, формы и т.п. и ничего адекватному программисту не мешает выделить дублированный код в отдельную функцию…
Да — очень много похожего кода… но он разный
Действительно, зачем «умные» люди придумали ООП? Есть же Copy/Paste.
Мне почему-то вспоминается Шариков: «А то пишут, пишут… конгресс, немцы какие-то… Голова пухнет. Взять всё, да и поделить...»
Мне почему-то вспоминается Шариков: «А то пишут, пишут… конгресс, немцы какие-то… Голова пухнет. Взять всё, да и поделить...»
Вот и я про тоже. Ради одного нового свойства (реквизита) или изменения типа текущего, в 1С копируется весь объект метаданных
Ради одного нового свойства (реквизита) или изменения типа текущего, в 1С копируется весь объект метаданных
Это кто вам сказал такую глупость? Вы хоть типовые посмотрели бы, например у документов бывают десятки свойств отображаемые пользователю и заполняемые ситуативно. Следуя вашей логике например в Бухгалтерии бюджетного учреждения должно быть документов тьма просто, тот же ПКО вместо одного должно с десяток быть. И с каждым обновлением еще с 1000 новых добавляться каждый месяц))
Есть составные типы, есть возможность прикрутить характеристики с произвольным набором свойств…
Если объект метаданных копируется, значит есть причины которые нужно искать не в ограничениях Платформы 1С а в первую очередь Бизнес-логике прикладного решения или ТЗ на разработку.
Платформа позволит вообще все засунуть в один объект метаданных, но это ведь не значит что решение будет хорошим? как и в любом ООП…
И точно такое же утверждение можно сказать про любой ООП язык, что для добавления нового метода/свойства нужно создать новый класс наследованный от некоторого базового… И данное утверждение будет и верным и не верным в зависимости от решаемой задачи.
Ну как при чем? Наследование и полиморфизм позволяют уменьшить дублирование кода. А в ООП есть наследование и полиморфизм.
Так именно об этом статья. Что можно применять ООП, например, для реализации регистров.
Так как мы не можем один класс наследовать от другого дважды, то для того, чтобы провести по регистру повторно, создадим агрегированный объект нового класса TransferSkuLedger, который затем наследуем от SkuLedger
Что то не убедили в целесообразности...
Создаешь тип документ в 1С, и хочешь создать точно такой же, но с «перламутровыми пуговицами». В 1С решается это копипастой и последующим редактированием. В ООП это решается наследованием красиво и просто
Можно бизнес-пример, а не перламутровые пуговицы?
Обычно документы связаны логически, если одинаковые добавляют "Вид операции"...
добавляют «Вид операции»
И со временем обычно появляются реквизиты специфичные для одного вида операции а для другого не нужные, знаем, плавали.
Neikist
Что удобней? Получить 20 разных документов — или несколько лишних реквизитов?
По ситуации. Может там вообще композиция нужна. Но лишние поля — ооочень нежелательны как по мне.
Ну так в 1С и есть композиция...
Neikist puyol_dev2 вот вы реально думаете что станет лучше и легче? Вот эта та кнопка которая все сделает?
Ок… будет 100 похожих документов, что будет с их хранением? В разных таблицах или одной? Что будет с производительностью join-ов? Что с нормализацией базы? Как будут происходить миграции? Вы думали как раздуются запросы?
Я не совсем в таком виде композицию имел, но да ладно. И да, после того как я ушел с языка 1с на котлин мне действительно стало намного комфортней писать код, пусть задачи и другие.
А о связи с базой я вообще ничего не говорил, на мой взгляд это все же отдельным слоем должно быть.
А о связи с базой я вообще ничего не говорил, на мой взгляд это все же отдельным слоем должно быть.
Ну а где по вашему хранятся дополнительные реквизиты?
Одно дело использовать ООП для объектов хранящихся в памяти — другое дело смапить все ООП и данные в БД. Да, это возможно — но это очень и очень неудобно. А говорить об адекватной миграции, изменении классов родителей — так вообще жуть.
Ну собсно вы сами ответили, разделить то с чем в данный момент работаем и данные в базе, я же и говорю про документы как объекты в памяти которые нужно валидировать, выполнять связанную бизнес логику (вроде оповещений на почту), отображать на экране, форматировать для отчетов и хз что еще придумать можно.
Вы в своей практике делали маппинг в базу объектов( с наследованием) или вы только мечтаете о таком?
Я бы тоже не отказался… еще и автоматический, еще бы и с миграциями)
Да я скорее откажусь от наследования — чем соглашусь руками все прописывать)
Пока масштаб проектов не тот, но вообще Room под андроид вполне неплохие средства работы с БД предоставляет.
Я бы на месте 1с ников про маппинг между объектами метаданных 1с и таблицами в субд вообще молчал. Если посмотреть какой запрос делает платформа в субд — можно ужаснуться количеству join ов даже для одного «документа» 1с
предложите варианты решения… что делать когда сотни связанных данных?
Я вижу всего 2 варианта работы в реляционной БД: либо жесткая денормализация, либо join-ы.
Как вариант выкинуть реляционные и использовать графовые БД, но они не так давно то и появились(хорошего уровня) — и у них свои проблемы...
Стоит вначале посмотреть на оригинальный запрос. Может столько джойнов — это результат бездумного обращения «через точку» у автора оригинального запроса?
пусть задачи и другие.
Может в этом дело? ;)
А потом кто-то меняет базовый класс и внезапно все ломается во всех унаследованных документах. Особенно если это на внедрении (а там сильный стресс), особенно, если у внедренца квалификации не хватает.
А если на N-ый год развития системы выясняется, что существующая иерархия классов перестает устраивать с точки зрения развития системы? А там же совместимость надо поддержать, ведь уже много чего унаследовано.
Это я к тому, что нет серебряной пули (@evilBearer — это я не про вас ;)). Каждый способ имеет свои плюсы и минусы. И уж точно — это не ключевой момент в автоматизации экономики.
А если на N-ый год развития системы выясняется, что существующая иерархия классов перестает устраивать с точки зрения развития системы? А там же совместимость надо поддержать, ведь уже много чего унаследовано.
Это я к тому, что нет серебряной пули (@evilBearer — это я не про вас ;)). Каждый способ имеет свои плюсы и минусы. И уж точно — это не ключевой момент в автоматизации экономики.
Мне много раз было грустно от того что некоторые паттерны вроде наблюдателя или шаблонного метода какого невозможно адекватно реализовать, только кучей кривоватого кода, а они вполне себе нередко к месту что в бизнес логике были, что в работе с формами.
Придирки по мелочам:
Довольно часто бизнес-схемы подразумевают условную отгрузку в минус, т.е если по отгрузке выполняются некие условия(причем динамически настраиваемые), то отгружать можно в минус. Оцените боль программистов, у которых ограничение на отрицательные остатки зашиты в платформу.
Строка документа≠строка набора записи. На строку документа может создавать сколько угодно строк в регистре. Контроль уникальности записей подразумевает невозможность существования в регистре двух записей с одинаковым ключом.
Схема регистров в 1С позволяет хранить довольно большой объем информации с более-менее приемлемой скоростью получения необходимых данных. Композиция — это просто следствие того, что есть два уровня логики — внешний и внутренний, которые естественно должны быть связаны; это точно не главное свойство регистров и документов, тем более, что есть возможность создавать записи регистров без связи с документами и документы без связи с регистрами.
В целом — да, полноценного ООП в 1С не хватает. Вся беда в том, что то, что уже есть (документы, регистры и т.д.) покрывает 99% потребностей для описания логики бизнес-процессов(а собственно это и есть область применения 1С). А на оставшийся процент — ну есть ведь внешние компоненты, которые тоже можно использовать.
Кстати, было бы интересно провести эксперимент: взять какую-то более-менее рабочую(в том смысле, что не высосанную из пальца) бизнес-схему и попробовать реализовать на разных фреймворках, а потом сравнить по производительности, количеству используемой памяти, времени на разработку и т.д.
P.S. В целом: статья — это интересный взгляд ещё с одной стороны на эту сферу разработки.
Платформа будет автоматически контролировать то, что при записи в регистр, остаток останется больше нуля. Если условие будет нарушено, то изменения не запишутся в базу данных, а пользователю будет выдано соответствующее сообщение. Кстати, желающие могут сравнить, как это ограничение реализовано в 1С УТ, чтобы оценить истинную боль, испытываемую 1С программистами.
Довольно часто бизнес-схемы подразумевают условную отгрузку в минус, т.е если по отгрузке выполняются некие условия(причем динамически настраиваемые), то отгружать можно в минус. Оцените боль программистов, у которых ограничение на отрицательные остатки зашиты в платформу.
К слову, в 1С с этим есть определенные проблемы, так как строка документа может порождать только одну запись в регистре:
Система обеспечивает контроль уникальности записей, хранящихся в регистре накопления. Благодаря этому в регистре накоплений не может находиться двух записей, относящихся к одной и той же строке одного и того же документа.
Строка документа≠строка набора записи. На строку документа может создавать сколько угодно строк в регистре. Контроль уникальности записей подразумевает невозможность существования в регистре двух записей с одинаковым ключом.
Схема регистров в 1С позволяет делать то, что в обычном программировании реализуется при помощи наследования и композиции (там регистр был бы просто интерфейсом).
Схема регистров в 1С позволяет хранить довольно большой объем информации с более-менее приемлемой скоростью получения необходимых данных. Композиция — это просто следствие того, что есть два уровня логики — внешний и внутренний, которые естественно должны быть связаны; это точно не главное свойство регистров и документов, тем более, что есть возможность создавать записи регистров без связи с документами и документы без связи с регистрами.
В целом — да, полноценного ООП в 1С не хватает. Вся беда в том, что то, что уже есть (документы, регистры и т.д.) покрывает 99% потребностей для описания логики бизнес-процессов(а собственно это и есть область применения 1С). А на оставшийся процент — ну есть ведь внешние компоненты, которые тоже можно использовать.
Кстати, было бы интересно провести эксперимент: взять какую-то более-менее рабочую(в том смысле, что не высосанную из пальца) бизнес-схему и попробовать реализовать на разных фреймворках, а потом сравнить по производительности, количеству используемой памяти, времени на разработку и т.д.
P.S. В целом: статья — это интересный взгляд ещё с одной стороны на эту сферу разработки.
Оцените боль программистов, у которых ограничение на отрицательные остатки зашиты в платформу.
Они не зашиты в платформу. Вы как раз можете ими управлять очень гибко. Например:
godMode = DATA BOOLEAN (User);
CONSTRAINT balance(Stock st, Sku sk) < 0 AND NOT godMode(currentUser())
MESSAGE 'Остаток по товару на складе должен быть положительным';
И для пользователя, у которого включена галочка godMode, сможет проводить без ограничения. И там выражения можно делать очень разные.
Не для юзера. Для набора условий. Причем набор условий(остатки, склад, условия договора, задолженность, приоритет контрагента и т.д.) может меняться без участия программиста самим пользователем. То есть нужно не хардкодить условия, а создавать инструмент, при помощи которого пользователь будет управлять условиями. Это и будет «гибко». И если всё это реализовать, то получится в общем-то тоже самое, что и в 1С УТ(которая приводится, как образец боли программиста).
P.S. Давать godMode пользователю — это то же самое, что и давать пациенту возможность выписывать самому себе лекарства. Это оочень плохая идея, поверьте.
P.S. Давать godMode пользователю — это то же самое, что и давать пациенту возможность выписывать самому себе лекарства. Это оочень плохая идея, поверьте.
godMode я привел для примера и хорошо осознаю последствия. Справедливости ради набор условий, который не привязан к складу, а к конкретным операциям также дает кучу возможностей для манипуляции, так как завязывается на последовательность операций. То есть можно будет взять всех «приоритетные» документы, распровести их, провести неприоритетные, а затем обратно приоритетные. И получится, что ограничение обошли.
Но в целом, это также легко и декларативно реализуется. Вот например:
И опять же выражение можно усложнять как угодно. Или добавлять, например, несколько ограничений.
Да, конечно. Только это делается 1С-программистом, а не самой платформой, которая слабо ему в этом помогает.
Но в целом, это также легко и декларативно реализуется. Вот например:
checkNegative = DATA BOOLEAN (Stock);
allowNegative = DATA BOOLEAN (Customer);
CONSTRAINT CHANGED(quantity(SkuLedger l)) AND balance(stock(l), sku(l)) < 0
AND checkNegative(stock(l)) AND NOT allowNegative(customer(l))
MESSAGE 'Остаток по товару на складе должен быть положительным';
И опять же выражение можно усложнять как угодно. Или добавлять, например, несколько ограничений.
То есть нужно не хардкодить условия, а создавать инструмент, при помощи которого пользователь будет управлять условиями
Да, конечно. Только это делается 1С-программистом, а не самой платформой, которая слабо ему в этом помогает.
heckNegative = DATA BOOLEAN (Stock);
allowNegative = DATA BOOLEAN (Customer);
CONSTRAINT CHANGED(quantity(SkuLedger l)) AND balance(stock(l), sku(l)) < 0
AND checkNegative(stock(l)) AND NOT allowNegative(customer(l))
MESSAGE 'Остаток по товару на складе должен быть положительным';А этот код кто будет писать, не программист ли часом? Какие преимущества описания ограничений в платформе, по сравнению с описанием ограничений в конкретной конфигурации?
Напишите сначала про какое описание ограничений в конкретной конфигурации идет речь? Это часом не 1С-программист делает?
Остатков, и аналогично делает программист...
Да, только в моем примере это делается красиво декларативно, а в 1С — смотрите код ниже.
Красиво можете "1+1=2" написать, давайте не сравнивать платформу и конфигурацию.
Все сводится к одному: в платформе 1С нет встроенного контроля отрицательных остатков. Все!
А вот вопрос его целесообразности — это уже вкусовщина
Мы сравниваем именно 2 платформы. На одной один функционал реализуется несколькими строками, а в другой — тонной странного кода.
В 1С нету много чего еще. Это всего лишь один случай, описанный в статье. Например, там также через тонной бессмысленного кода реализуется Подбор, по сравнению с минимальным кодом в lsFusion.
Все сводится к одному: в платформе 1С нет встроенного контроля отрицательных остатков. Все!
В 1С нету много чего еще. Это всего лишь один случай, описанный в статье. Например, там также через тонной бессмысленного кода реализуется Подбор, по сравнению с минимальным кодом в lsFusion.
А вы видели, как в УТ такие ограничения проверяются? Я напомню:
В ПередЗаписи регистра (например ТоварыКОтгрузке):
Потом в ПослеЗаписи:
И потом в КонтрольПроведения (который должен быть во всех документах влияющих на этот регистр !):
И потом еще код по проверке ограничения. Они больные? В lsFusion это одной строкой кода делается. И это примитивное ограничение. Представляю как бы CONSTRAINT приведенный выше в 1С выглядел.
В ПередЗаписи регистра (например ТоварыКОтгрузке):
Код
// Текущее состояние набора помещается во временную таблицу
// чтобы при записи получить изменение нового набора относительно текущего.
Запрос = Новый Запрос;
Запрос.УстановитьПараметр("Регистратор", Отбор.Регистратор.Значение);
Запрос.МенеджерВременныхТаблиц = ДополнительныеСвойства.ДляПроведения.СтруктураВременныеТаблицы.МенеджерВременныхТаблиц;
Запрос.Текст =
"ВЫБРАТЬ
| Таблица.ВидДвижения КАК ВидДвижения,
| Таблица.ДокументОтгрузки КАК ДокументОтгрузки,
| Таблица.Номенклатура КАК Номенклатура,
| Таблица.Характеристика КАК Характеристика,
| Таблица.Назначение КАК Назначение,
| Таблица.Серия КАК Серия,
| Таблица.Склад КАК Склад,
| Таблица.Получатель КАК Получатель,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА Таблица.ВРезерве + Таблица.КОтгрузке
| ИНАЧЕ -Таблица.ВРезерве - Таблица.КОтгрузке
| КОНЕЦ КАК ВРезервеКОтгрузкеПередЗаписью,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА Таблица.КОтгрузке
| ИНАЧЕ -Таблица.КОтгрузке
| КОНЕЦ КАК КОтгрузкеПередЗаписью,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА -Таблица.Собирается
| ИНАЧЕ Таблица.Собирается
| КОНЕЦ КАК СобираетсяПередЗаписью,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА -Таблица.Собрано
| ИНАЧЕ Таблица.Собрано
| КОНЕЦ КАК СобраноПередЗаписью
|ПОМЕСТИТЬ ДвиженияТоварыКОтгрузкеПередЗаписью
|ИЗ
| РегистрНакопления.ТоварыКОтгрузке КАК Таблица
|ГДЕ
| Таблица.Регистратор = &Регистратор";
Запрос.Выполнить();
Потом в ПослеЗаписи:
Код
СтруктураВременныеТаблицы = ДополнительныеСвойства.ДляПроведения.СтруктураВременныеТаблицы;
Запрос = Новый Запрос;
ОформлятьСначалаНакладные = Константы.ПорядокОформленияНакладныхРасходныхОрдеров.Получить() = Перечисления.ПорядокОформленияНакладныхРасходныхОрдеров.СначалаНакладные;
Запрос.УстановитьПараметр("ОформлятьСначалаНакладные", ОформлятьСначалаНакладные);
Запрос.УстановитьПараметр("Регистратор", Отбор.Регистратор.Значение);
Запрос.МенеджерВременныхТаблиц = СтруктураВременныеТаблицы.МенеджерВременныхТаблиц;
// Рассчитывается изменение нового набора относительно текущего с учетом накопленных изменений
// и помещается во временную таблицу.
Запрос.Текст =
"ВЫБРАТЬ
| ТаблицаИзменений.ДокументОтгрузки КАК ДокументОтгрузки,
| ТаблицаИзменений.Номенклатура КАК Номенклатура,
| ТаблицаИзменений.Характеристика КАК Характеристика,
| ТаблицаИзменений.Назначение КАК Назначение,
| ТаблицаИзменений.Серия КАК Серия,
| ТаблицаИзменений.Склад КАК Склад,
| ТаблицаИзменений.Получатель КАК Получатель,
| СУММА(ТаблицаИзменений.КОтгрузкеИзменение) КАК КОтгрузкеИзменение,
| СУММА(ТаблицаИзменений.СобираетсяИзменение) КАК СобираетсяИзменение,
| СУММА(ТаблицаИзменений.СобираетсяИзменение) КАК СобраноИзменение
|ПОМЕСТИТЬ ДвиженияТоварыКОтгрузкеИзменение
|ИЗ
| (ВЫБРАТЬ
| Таблица.ВидДвижения КАК ВидДвижения,
| Таблица.ДокументОтгрузки КАК ДокументОтгрузки,
| Таблица.Номенклатура КАК Номенклатура,
| Таблица.Характеристика КАК Характеристика,
| Таблица.Назначение КАК Назначение,
| Таблица.Серия КАК Серия,
| Таблица.Склад КАК Склад,
| Таблица.Получатель КАК Получатель,
| Таблица.КОтгрузкеПередЗаписью КАК КОтгрузкеИзменение,
| Таблица.СобираетсяПередЗаписью КАК СобираетсяИзменение,
| Таблица.СобраноПередЗаписью КАК СобраноИзменение
| ИЗ
| ДвиженияТоварыКОтгрузкеПередЗаписью КАК Таблица
|
| ОБЪЕДИНИТЬ ВСЕ
|
| ВЫБРАТЬ
| Таблица.ВидДвижения,
| Таблица.ДокументОтгрузки,
| Таблица.Номенклатура,
| Таблица.Характеристика,
| Таблица.Назначение,
| Таблица.Серия,
| Таблица.Склад,
| Таблица.Получатель,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА -Таблица.КОтгрузке
| ИНАЧЕ Таблица.КОтгрузке
| КОНЕЦ,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА Таблица.Собирается
| ИНАЧЕ -Таблица.Собирается
| КОНЕЦ,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА Таблица.Собрано
| ИНАЧЕ -Таблица.Собрано
| КОНЕЦ
| ИЗ
| РегистрНакопления.ТоварыКОтгрузке КАК Таблица
| ГДЕ
| Таблица.Регистратор = &Регистратор) КАК ТаблицаИзменений
|
|СГРУППИРОВАТЬ ПО
| ТаблицаИзменений.ВидДвижения,
| ТаблицаИзменений.ДокументОтгрузки,
| ТаблицаИзменений.Номенклатура,
| ТаблицаИзменений.Характеристика,
| ТаблицаИзменений.Назначение,
| ТаблицаИзменений.Серия,
| ТаблицаИзменений.Склад,
| ТаблицаИзменений.Получатель
|
|ИМЕЮЩИЕ
| (СУММА(ТаблицаИзменений.КОтгрузкеИзменение) > 0
| ИЛИ СУММА(ТаблицаИзменений.СобираетсяИзменение) > 0
| ИЛИ СУММА(ТаблицаИзменений.СобраноИзменение) > 0)
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| Т.Номенклатура КАК Номенклатура,
| Т.Характеристика КАК Характеристика,
| Т.Назначение КАК Назначение,
| Т.Серия КАК Серия,
| Т.Склад КАК Склад,
| Т.Склад КАК Получатель,
| СУММА(Т.УвеличениеПрихода) КАК УвеличениеПрихода
|ПОМЕСТИТЬ ДвиженияТоварыКОтгрузкеИзменениеСводно
|ИЗ
| (ВЫБРАТЬ
| Таблица.ВидДвижения КАК ВидДвижения,
| Таблица.Номенклатура КАК Номенклатура,
| Таблица.Характеристика КАК Характеристика,
| Таблица.Назначение КАК Назначение,
| Таблица.Серия КАК Серия,
| Таблица.Склад КАК Склад,
| Таблица.Склад КАК Получатель,
| -Таблица.ВРезервеКОтгрузкеПередЗаписью КАК УвеличениеПрихода
| ИЗ
| ДвиженияТоварыКОтгрузкеПередЗаписью КАК Таблица
|ГДЕ
| Таблица.Серия <> ЗНАЧЕНИЕ(Справочник.СерииНоменклатуры.ПустаяСсылка)
| И Таблица.Склад.КонтролироватьОперативныеОстатки
|
| ОБЪЕДИНИТЬ ВСЕ
|
| ВЫБРАТЬ
| Таблица.ВидДвижения,
| Таблица.Номенклатура,
| Таблица.Характеристика,
| Таблица.Назначение,
| Таблица.Серия,
| Таблица.Склад,
| Таблица.Получатель,
| ВЫБОР
| КОГДА Таблица.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
| ТОГДА Таблица.ВРезерве + Таблица.КОтгрузке
| ИНАЧЕ -Таблица.ВРезерве - Таблица.КОтгрузке
| КОНЕЦ
| ИЗ
| РегистрНакопления.ТоварыКОтгрузке КАК Таблица
| ГДЕ
| Таблица.Регистратор = &Регистратор) КАК Т
|ГДЕ
| Т.Серия <> ЗНАЧЕНИЕ(Справочник.СерииНоменклатуры.ПустаяСсылка)
| И Т.Склад.КонтролироватьОперативныеОстатки
|
|СГРУППИРОВАТЬ ПО
| Т.ВидДвижения,
| Т.Номенклатура,
| Т.Склад,
| Т.Получатель,
| Т.Характеристика,
| Т.Назначение,
| Т.Серия
|
|ИМЕЮЩИЕ
| СУММА(Т.УвеличениеПрихода) > 0
|;
|
|////////////////////////////////////////////////////////////////////////////////
|УНИЧТОЖИТЬ ДвиженияТоварыКОтгрузкеПередЗаписью";
ЗапросПакет = Запрос.ВыполнитьПакет();
Выборка = ЗапросПакет[0].Выбрать();
Выборка.Следующий();
// Новые изменения были помещены во временную таблицу.
// Добавляется информация о ее существовании и наличии в ней записей об изменении.
СтруктураВременныеТаблицы.Вставить("ДвиженияТоварыКОтгрузкеИзменение", Выборка.Количество > 0);
Выборка = ЗапросПакет[1].Выбрать();
Выборка.Следующий();
СтруктураВременныеТаблицы.Вставить("ДвиженияТоварыКОтгрузкеИзменениеСводно", Выборка.Количество > 0);
И потом в КонтрольПроведения (который должен быть во всех документах влияющих на этот регистр !):
Код
Если ЕстьИзмененияВТаблице(ДанныеТаблиц,"ДвиженияТоварыКОтгрузкеИзменениеСводно") Тогда
МассивКонтролей.Добавить(Врег("ДвиженияТоварыКОтгрузкеСводно"));
ТекстЗапроса = ТекстЗапроса +
"
|ВЫБРАТЬ
| Остатки.Номенклатура КАК Номенклатура,
| Остатки.Номенклатура.ЕдиницаИзмерения КАК ЕдиницаИзмерения,
| Остатки.Характеристика КАК Характеристика,
| Остатки.Назначение КАК Назначение,
| Остатки.Склад КАК Склад,
| Остатки.Серия КАК Серия,
| СУММА(Остатки.Количество) КАК Количество
|
|ИЗ
|(ВЫБРАТЬ
| Т.Номенклатура КАК Номенклатура,
| Т.Характеристика КАК Характеристика,
| Т.Назначение КАК Назначение,
| Т.Склад КАК Склад,
| Т.Серия КАК Серия,
| -Т.ВРезервеОстаток - Т.КОтгрузкеОстаток КАК Количество
|ИЗ
| РегистрНакопления.ТоварыКОтгрузке.Остатки(
| ,
| (Номенклатура, Характеристика, Назначение, Склад, Серия) В
| (ВЫБРАТЬ
| Т.Номенклатура,
| Т.Характеристика,
| Т.Назначение,
| Т.Склад,
| Т.Серия
| ИЗ
| ДвиженияТоварыКОтгрузкеИзменениеСводно КАК Т)) КАК Т
|ОБЪЕДИНИТЬ ВСЕ
|
|ВЫБРАТЬ
| Т.Номенклатура КАК Номенклатура,
| Т.Характеристика КАК Характеристика,
| Т.Назначение КАК Назначение,
| Т.Склад КАК Склад,
| Т.Серия КАК Серия,
| Т.ВНаличииОстаток КАК Количество
|ИЗ
| РегистрНакопления.ТоварыНаСкладах.Остатки(
| ,
| (Номенклатура, Характеристика, Назначение, Склад, Серия) В
| (ВЫБРАТЬ
| Т.Номенклатура,
| Т.Характеристика,
| Т.Назначение,
| Т.Склад,
| Т.Серия
| ИЗ
| ДвиженияТоварыКОтгрузкеИзменениеСводно КАК Т)) КАК Т
|) КАК Остатки
|
|СГРУППИРОВАТЬ ПО
| Остатки.Номенклатура,
| Остатки.Характеристика,
| Остатки.Назначение,
| Остатки.Склад,
| Остатки.Серия
|
|ИМЕЮЩИЕ
| СУММА(Остатки.Количество) < 0
|;
|///////////////////////////////////////////////////////////////////
|";
КонецЕсли;
И потом еще код по проверке ограничения. Они больные? В lsFusion это одной строкой кода делается. И это примитивное ограничение. Представляю как бы CONSTRAINT приведенный выше в 1С выглядел.
Есть такая штука, называется «скорость работы». Есть у меня подозрение, что приведенный код работает на порядок(а с учетом параллельной работы в базе пары тысяч пользователей, так и на несколько порядков) быстрее, чем то, что в IsFusion делается одной строкой. И приведенный отрывок — это не проверка, а получение данных, необходимых для записи с учетом всех нужных проверок. Хотя запрос — да, кривоватый.
Есть такая штука, называется «скорость работы». Есть у меня подозрение, что приведенный код работает на порядок(а с учетом параллельной работы в базе пары тысяч пользователей, так и на несколько порядков) быстрее, чем то, что в IsFusion делается одной строкой.
Есть. И решения уровня ERP на lsFusion работают в FMCG-сетях с терабайтными базами и сотнями (а иногда и тысячами) одновременных пользователей на оборудовании стоимостью 10-20к. И там именно вот такие декларативные ограничения в одну строку. Вот кстати репозитарий общего набора модулей:
github.com/lsfusion-solutions/erp/tree/master/erp-logics/src/main/lsfusion
И приведенный отрывок — это не проверка, а получение данных, необходимых для записи с учетом всех нужных проверок.
Хоть убей не понял что вы написали. Я делал CTRL+SHIFT+F ДвиженияТоварыКОтгрузкеИзменениеСводно, ДвиженияТоварыКОтгрузкеПередЗаписью. И они используются чисто для проверки ограничений.
Хотя запрос — да, кривоватый.
То есть люди, которые писали второе самое распространенное решение на 1С, написали его криво. Может проблема в консерватории?
И решения уровня ERP на lsFusion работают в FMCG-сетях с терабайтными базами и сотнями (а иногда и тысячами) одновременных пользователей на оборудовании стоимостью 10-20к.
Без сравнения функционала не получится оценить производительности.
Хоть убей не понял что вы написали. Я делал CTRL+SHIFT+F ДвиженияТоварыКОтгрузкеИзменениеСводно, ДвиженияТоварыКОтгрузкеПередЗаписью. И они используются чисто для проверки ограничений.
Я сужу чисто по коду: первый отрывок — выбираются все данные по товарам к отгрузке по данному документу и изменяются с учетом отложенного резервного товара, второй отрывок — эти данные проверяются на выбранные условия и проверяются на то, как они влияют на другие отгрузки, видимо далее где-то идет запись в регистр проверенных данных, а третий отрывок — это уже собственно контроль данных итоговой таблицы.
То есть люди, которые писали второе самое распространенное решение на 1С, написали его криво. Может проблема в консерватории?
Это всего лишь моя оценка запроса, я просто не знаю всей информации по данному процессу, может быть у людей написавших это и были свои резоны.
Без сравнения функционала не получится оценить производительности.
Я же написал уровня ERP. Понятно что в деталях есть отличия, но объем функционала, даже больше чем УТ, но хотя наверное все же поменьше чем 1С ERP. Но если что, можете там коммиты глянуть, задач в таск трекере и кода конкретных клиентов вы не увидите, но хотя бы по их тексту и самим изменениям в коде приблизительное впечатление можно составить.
первый отрывок — выбираются все данные по товарам к отгрузке по данному документу и изменяются с учетом отложенного резервного товара
Нет, ДвиженияТоварыКОтгрузкеПередЗаписью, ДвиженияТоварыКОтгрузкеИзменениеСводно используются только в этих 3 кусках кода. Можете сами проверить. То есть это чисто проверка ограничения.
Это всего лишь моя оценка запроса, я просто не знаю всей информации по данному процессу, может быть у людей написавших это и были свои резоны.
Так там таких проверок в этой процедуре 2400 строк. И все по одной / похожей схеме сделаны. А вы же говорили, что с УТ периодически работаете.
Нет, ДвиженияТоварыКОтгрузкеПередЗаписью, ДвиженияТоварыКОтгрузкеИзменениеСводно используются только в этих 3 кусках кода. Можете сами проверить. То есть это чисто проверка ограничения.
Ещё раз внимательно прочитайте тексты приведенных Вами же примеров. Кроме проверки на остаток там много ещё чего.
Так там таких проверок в этой процедуре 2400 строк. И все по одной / похожей схеме сделаны. А вы же говорили, что с УТ периодически работаете.
Сделаны по похожей схеме — не означает дублирование кода. Потому как даже в Ваших примерах кроме проверки делается много действий. И тем более, я сомневаюсь, что все 2400 строк модуля посвящены проверке остатка. Под рукой УТ 11.3 у меня нет(имеется в виду же эта версия?), а то, что я с ней периодически работаю — не означает, что я помню наизусть тексты всех модулей.
Ещё раз внимательно прочитайте тексты приведенных Вами же примеров. Кроме проверки на остаток там много ещё чего.
Потому как даже в Ваших примерах кроме проверки делается много действий.
Еще раз первый и второй код ТОЛЬКО заполняют временные таблицы (больше этот код ничего не делают):
- ДвиженияТоварыКОтгрузкеПередЗаписью
- ДвиженияТоварыКОтгрузкеИзменение
- ДвиженияТоварыКОтгрузкеИзменениеСводно
Эти таблицы используются ТОЛЬКО в третьем коде. Который ТОЛЬКО проверяет ограничение.
Да, УТ — 11.3.4.
Еще раз первый и второй код ТОЛЬКО заполняют временные таблицы (больше этот код ничего не делают):
Ещё раз: внимательно посмотрите КАК и ЧЕМ они заполняются.
Update: видимо слишком строг к Вам. Посмотрите внимательно: наименования полей «КОтгрузкеИзменение», «СобираетсяИзменение», «СобраноИзменение» — неужели Вы думаете, что это вроде как одно и то же и это просто решили продублировать? Или это все-таки несколько разных полей, которые используются для разных целей, каждое для своей? А то, что последний кусок у вас обрывается на формировании текста запроса Вас не смутило? Может быть там далее ещё что-то есть? А строка МассивКонтролей.Добавить(...) — неужели не натолкнула Вас на мысль, что там(и не только там) используется целый массив с перечнем контролей и что ради одной жалкой проверки на остатки не было смысла городить целый механизм с возможностью динамического формирования системы проверок? И что глобальный поиск по наименованию временной таблицы не равноценен выяснению всего пути от начала и до конца, по которому движутся данные?
Этот МассивКонтролей используется в одном месте:
Я собственно и написал, что есть еще код по выдаче самого ограничения (да у меня тоже глаза слезятся от такого). Все больше следов нет. Я даже теоретически не нашел где это может использоваться. Может есть еще какие то секретные знания, но это к вопросу о техническом долге, и тому как эту все ерунду поддерживать.
Код
ПакетЗапросов.Текст = ТекстЗапроса;
ПакетЗапросов.МенеджерВременныхТаблиц = ДанныеТаблиц.МенеджерВременныхТаблиц;
МассивРезультатов = ПакетЗапросов.ВыполнитьПакет();
Итератор = -1;
Для Каждого Результат Из МассивРезультатов Цикл
Итератор = Итератор + 1;
Если Результат.Пустой() Тогда
Продолжить;
КонецЕсли;
ИмяКонтроля = МассивКонтролей[Итератор];
Если ИмяКонтроля = Врег("ТоварыКОтгрузке") Тогда
СообщитьОбОшибкахПроведенияПоРегиструТоварыКОтгрузке(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ОбеспечениеВременнаяТаблица1") Тогда
ИначеЕсли ИмяКонтроля = Врег("ОбеспечениеВременнаяТаблица2") Тогда
ИначеЕсли ИмяКонтроля = Врег("Обеспечение") Тогда
СообщитьОбОшибкахПроведенияПоРегистрамСвободныеОстаткиИДвижениеТоваров(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ДенежныеСредстваКВыплате") Тогда
СообщитьОбОшибкахПроведенияПоРегиструДенежныеСредстваКВыплате(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("РасчетыСКлиентами") Тогда
СообщитьОбОшибкахПроведенияПоРегиструРасчетыСКлиентами(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ВременнаяТаблицаДанныеДоговоровПредварительные") Тогда
// Временная таблица
ИначеЕсли ИмяКонтроля = Врег("ВременнаяТаблицаДанныеДоговоров") Тогда
// Временная таблица
ИначеЕсли ИмяКонтроля = Врег("ВременнаяТаблицаОбъектыРасчетов") Тогда
// Временная таблица
ИначеЕсли ИмяКонтроля = Врег("ОграничениеСуммыЗадолженности") Тогда
СообщитьОбОшибкахПроведенияПриОграниченииСуммыЗадолженности(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("КонтрольСрокаЗадолженности") Тогда
СообщитьОбОшибкахПроведенияПриКонтролеСрокаЗадолженности(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ЗаказыНаПеремещение") Тогда
СообщитьОбОшибкахПроведенияПоРегиструЗаказыНаПеремещение(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ЗаказыНаВнутреннееПотребление") Тогда
СообщитьОбОшибкахПроведенияПоРегиструЗаказыНаВнутреннееПотребление(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = ВРег("ТМЦВЭксплуатации") Тогда
СообщитьОбОшибкахПроведенияПоРегиструТМЦВЭксплуатации(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ЗаказыКлиентов")
Или ИмяКонтроля = Врег("ЗаказыПоставщикам") Тогда
СообщитьОбОшибкахПроведенияПоРегиструЗаказыКлиентовПоставщикам(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ДвиженияЗаказыКлиентовИзменениеМерныеТовары")
ИЛИ ИмяКонтроля = Врег("ВТДопустимыеОтклоненияЗаказыКлиентов")
ИЛИ ИмяКонтроля = Врег("ВТЗаказыКлиентовОстатки") Тогда
// временная таблица
ИначеЕсли ИмяКонтроля = Врег("ЗаявкиНаВозвратТоваровОтКлиентов") Тогда
СообщитьОбОшибкахПроведенияПоРегиструЗаявкиНаВозвратТоваровОтКлиентов(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ЗаказыНаСборку") Тогда
СообщитьОбОшибкахПроведенияПоРегиструЗаказыНаСборку(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ВТМногооборотнаяТара") Тогда
// временная таблица
ИначеЕсли ИмяКонтроля = Врег("ВТЯчейкиКонтролироватьОбособление") Тогда
// временная таблица
ИначеЕсли ИмяКонтроля = Врег("ТоварыВЯчейках") Тогда
СообщитьОбОшибкахПроведенияПоРегиструТоварыВЯчейках(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("НесколькоНазначенийВОбособленныхЯчейках") Тогда
СообщитьОбОшибкахПроведенияПоРегиструТоварыВЯчейкахНесколькоНазначений(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ТоварыНаСкладах") Тогда
СообщитьОбОшибкахПроведенияПоРегиструТоварыНаСкладах(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ВременнаяТаблицаОстатковСТоварнымиМестами")
Или ИмяКонтроля = Врег("ВременнаяТаблицаОборотовСТоварнымиМестами")
Или ИмяКонтроля = Врег("ВременнаяТаблицаОстатков")
Или ИмяКонтроля = Врег("ВременнаяТаблицаОборотов")
Или ИмяКонтроля = Врег("ТоварныеМестаНоменклатуры") Тогда
// временная таблица
ИначеЕсли ИмяКонтроля = Врег("ТоварыКОтбору") Тогда
СообщитьОбОшибкахПроведенияПоРегиструТоварыКОтбору(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ТоварыОрганизацийКОформлению") Тогда
СообщитьОбОшибкахПроведенияПоРегиструТоварыОрганизацийКОформлению(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ДвиженияОбеспечениеЗаказовИзменениеМерныеТовары")
ИЛИ ИмяКонтроля = Врег("ВТДопустимыеОтклоненияОбеспечениеЗаказов") Тогда
//временная таблица
ИначеЕсли ИмяКонтроля = Врег("ОбеспечениеЗаказов") Тогда
СообщитьОбОшибкахПроведенияПоРегиструОбеспечениеЗаказов(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ДвиженияТоварыКОтгрузкеСводно") Тогда
СообщитьОбОшибкахПроведенияПоРегиструСерии(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ПринятаяВозвратнаяТара") Тогда
СообщитьОбОшибкахПроведенияПоРегиструПринятаяВозвратнаяТара(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ПереданнаяВозвратнаяТара") Тогда
СообщитьОбОшибкахПроведенияПоРегиструПереданнаяВозвратнаяТара(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ОбеспечениеЗаказовРаботами") Тогда
СообщитьОбОшибкахПроведенияПоРегиструОбеспечениеЗаказовРаботами(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ОстаткиОрганизацийВТ") Тогда
// Временная таблица
ИначеЕсли ИмяКонтроля = Врег("ТоварыОрганизаций") Тогда
СообщитьОбОшибкахПроведенияПоРегиструТоварыОрганизаций(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ПрочиеРасходы") Тогда
СообщитьОбОшибкахПроведенияПоРегиструПрочиеРасходы(Объект, Отказ, Результат);
ИначеЕсли ИмяКонтроля = Врег("ТоварыКОформлениюЗаявленийОВвозе") Тогда
СообщитьОбОшибкахПроведенияПоРегиструТоварыКОформлениюЗаявленийОВвозе(Объект, Отказ, Результат);
Иначе
ВызватьИсключение НСтр("ru = 'Ошибка контроля проведения!'");
КонецЕсли;
КонецЦикла;
Я собственно и написал, что есть еще код по выдаче самого ограничения (да у меня тоже глаза слезятся от такого). Все больше следов нет. Я даже теоретически не нашел где это может использоваться. Может есть еще какие то секретные знания, но это к вопросу о техническом долге, и тому как эту все ерунду поддерживать.
да у меня тоже глаза слезятся от такого
Почему? Вам трудно читать на русском?
Все больше следов нет. Я даже теоретически не нашел где это может использоваться.
Хорошо. Если у Вас кончились идеи, я дам вам совет(если разумеется осталось время и желание). Забейте в окно глобального поиска любое из названий контроля(а там ведь их больше 30, если не ошибаюсь). И поищите, где оно может инициализироваться. А если лень, то я вам в общих чертах расскажу: в тех местах где необходим контроль(а это ведь не только документы), собираются нужные данные(в каждом месте — контролируются свои показатели и свои данные, и соответственно везде свой запрос), там же настраивается система проверок(тот самый массив контролей), далее — собранные данные через менеджер временных таблиц(те самые ДанныеТаблиц) и система проверок через МассивКонтролей передается сюда, в это место. И здесь по каждой из проверок определяется был ли нарушен контроль в тех данных, которые передаются через ДанныеТаблиц.
Почему? Вам трудно читать на русском?
Нет, мне плевать на русский. От такого количество однотипных If в одном месте, и прикладных объектов в строках, которые ни одна IDE не найдет.
Хорошо. Если у Вас кончились идеи, я дам вам совет(если разумеется осталось время и желание). Забейте в окно глобального поиска любое из названий контроля(а там ведь их больше 30, если не ошибаюсь). И поищите, где оно может инициализироваться. А если лень, то я вам в общих чертах расскажу: в тех местах где необходим контроль(а это ведь не только документы), собираются нужные данные(в каждом месте — контрллируются свои показатели и свои данные, и соответственно везде свой запрос), там же настраивается система проверок(тот самый массив контролей), далее — собранные данные через менеджер временных таблиц(те самые ДанныеТаблиц) и система проверок через МассивКонтролей передается сюда, в это место. И здесь по каждой из проверок определяется был ли нарушен контроль в тех данных которые передаются через ДанныеТаблицы.
Еще раз я не к тому зачем нужен массивконтролей. Это конечно код в стиле привет 70е, я такой код видел 20 лет назад и думал больше его не увижу, но пришлось. В любом случае не суть. Я говорил про три куска кода, которые я привел. Их ЕДИНСТВЕННАЯ функция проверка что ТоваровКОтгрузке > 0. Можно его вырезать и ничего не изменится, кроме того что проверка исчезнет. И по сути на эту проверку написано под 300 строк кода. Это нормально по вашему?
От такого количество однотипных If в одном месте
Что поделать, так реализован switch в 1С. Но ведь и про С++ Вы бы написали, что у Вас слезятся глаза от такого количества однотипных case, верно?
прикладных объектов в строках, которые ни одна IDE не найдетбоюсь, тут проблема не в IDE. Те, кто работает с 1С ищут и находят же.
Что-то я устал от дискуссии. Применительно ко всем комментариям под статьей — эффект Даннига-Крюгера в чистом виде.
Что поделать, так реализован switch в 1С. Но ведь и про С++ Вы бы написали, что у Вас слезятся глаза от такого количества однотипных case, верно?
Просто для этого ООП, а точнее наследование и полиморфизм придумали, чтобы не было такого количества IF. О чем собственно и статья частично.
боюсь, тут проблема не в IDE. Те, кто работает с 1С ищут и находят же.
Ну на COBOL'е тоже люди как-то пишут. Но когда привыкаешь к хорошему, от плохого быстро отвыкаешь.
Что-то я устал от дискуссии.
Если честно я тоже устал, но в любом случае спасибо за более-менее конструктивную дискуссию.
ага, ага… списание только с определенного склада, при реализации только от одной организации определенному контрагенту и только при "не переходе права собственности"
Красиво выглядит, не более того. В реальных условиях — будет тот же самый код.
Оцените боль программистов, у которых ограничение на отрицательные остатки зашиты в платформу.
Безотносительно, того что ограничения можно делать условными, снимать для администраторов и т.п., оцените боль администраторов и пользователей, которые не могут понять какого черта остаток вдруг стал отрицательным и что с этим теперь делать.
В целом — да, полноценного ООП в 1С не хватает. Вся беда в том, что то, что уже есть (документы, регистры и т.д.) покрывает 99% потребностей для описания логики бизнес-процессов(а собственно это и есть область применения 1С). А на оставшийся процент — ну есть ведь внешние компоненты, которые тоже можно использовать.
Вы код УТ к примеру видели? Для меня если честно загадка, как в нем хоть что-то можно изменить.
То есть с теми абстракциями, которые как вы говорите покрывают 99% потребностей бизнес-процессов, конечное решение вроде УТ это нативный SQL с тоннами if'ов и императивного кода с техническим долгом такого уровня, что я не уверен, что разработчики этой конфигурации сами разбираются в этом коде. А что делать обычному разработчику, когда его попросят что-то изменить? Остается только как в SAP сказать вы просто неправильно работаете.
Вы код УТ к примеру видели? Для меня если честно загадка, как в нем хоть что-то можно изменить.
… с теми абстракциями, которые как вы говорите покрывают 99% потребностей бизнес-процессов, конечное решение вроде УТ это нативный SQL с тоннами if'ов и императивного кода с техническим долгом такого уровня, что я не уверен, что разработчики этой конфигурации сами разбираются в этом коде.
Вы не поверите, но я с ней периодически работаю. Технического долга там не очень много, а у тех версий, которые уже давным давно вылизаны, так и вовсе. И работа кода вполне прозрачна.
Вся беда в том, что сейчас — это «нативный SQL с тоннами if'ов и императивного кода с техническим долгом» использующий стандартные возможности, известные всем, кто работает с этими возможностями и есть вероятность, что разработчик окажется достаточного уровня, чтобы со всем этим разобраться. А вот альтернатива — это «идеально вылизанный ООП продукт»(созданный с использованием «домашней» библиотеки), в котором, кроме автора разобраться никто не сможет. Собственно и сейчас есть возможность пристегнуть свои внешние компоненты(как раз те самые «вылизанные ООП продукты») и вот когда с таким сталкиваешься — вот это реальная боль программиста.
Технического долга там не очень много
Мы наверное разное понимаем под техническим долгом, я в данном случае говорю о дублировании абстракций, а там если открыть какой-нибудь КонтрольПроведения видно что там с десяток проверок делающих очень похожие вещи. Но может это субьективное ощущение.
Вся беда в том, что сейчас — это «нативный SQL с тоннами if'ов и императивного кода с техническим долгом» использующий стандартные возможности, известные всем, кто работает с этими возможностями и есть вероятность, что разработчик окажется достаточного уровня, чтобы со всем этим разобраться
Круто. То есть если сильно повезет, кто-то во всем этом разберется. Но даже если так повезет, представляете сколько он будет стоить? Ведь по сути это человек уровня Full-stack JS Developer'а (так как 1С умудрился отказаться одновременно и от ORM, и от всех нормальных возможностей SQL, в том числе блокировок, одного flow для сервера и клиента, с этими дурацким &НаКлиенте, &НаСервере, ну и как вишенка на торте модальности — предлагая всем перейти на callback'и) со знанием предметной области торговли.
А вот альтернатива — это «идеально вылизанный ООП продукт»(созданный с использованием «домашней» библиотеки), в котором, кроме автора разобраться никто не сможет.
Нет, альтернатива — идеально вылизанный ООП продукт, построенный на основе самых распространенных в мире технологий (Java, IDEA, Git, JasperReports), который позволяет одновременно создавать максимально модульный и декомпозированный код, и делать это на очень высоком уровне абстрагирования (где целостность, материализации, события, синхронизация сервера и клиента, модальности и т.п. поддерживаются из коробки, а не руками как в 1С), в котором разберется даже человек без опыта в IT.
Собственно и сейчас есть возможность пристегнуть свои внешние компоненты(как раз те самые «вылизанные ООП продукты») и вот когда с таким сталкиваешься — вот это реальная боль программиста.
Ну если смешать даже бочку меда с ложкой дегтя вы сами знаете что получается.
там если открыть какой-нибудь КонтрольПроведения видно что там с десяток проверок делающих очень похожие вещи. Но может это субьективное ощущение.
Не очень понимаю, что такое «открыть КонтрольПроведения», но если Вы имеет в виду проверку на условия, подобные упомянутому в статье, то в объекте(документе) происходит только настройка структуры условий, а сама проверка по этим условиям — происходит в общем модуле(в частности в УТ модуль для проверок, связанных с перемещением материальных ценностей, так и называется — «Управление запасами»).
Но даже если так повезет, представляете сколько он будет стоить? Ведь по сути это человек уровня Full-stack JS Developer'а (так как 1С умудрился отказаться одновременно и от ORM, и от всех нормальных возможностей SQL, в том числе блокировок, одного flow для сервера и клиента, с этими дурацким &НаКлиенте, &НаСервере, ну и как вишенка на торте модальности — предлагая всем перейти на callback'и) со знанием предметной области торговли.
Ну ради справедливости, &НаКлиенте и &НаСервере — это довольно удобный инструмент, помогающий оптимизировать выполнение кода, правда таких случаев, когда он реально необходим — не очень много.
А в целом: да, всё верно, такой специалист стоит дорого. И да, без знания предметной области здесь тоже делать нечего. Так как, если абстрагировать логику от самой предметной области, то во-первых, на это нужен отдельный человек(который тоже стоит дорого) и плюс отдельно — разработчик. В сумме — дороговато получается. А так за в несколько раз меньшую сумму — получаем человека разбирающегося и в логике продукта, и в бизнес логике(а ведь ещё и законодательство нужно знать, это же не просто цифры, это вполне конкретные люди, предметы и действия, и за некоторые сочетания этих трех компонентов положена административная или уголовная ответственность). Получается, что тупо экономически невыгодно идти по пути самых распространенных в мире технологий, просто не взлетит.
Ну если смешать даже бочку меда с ложкой дегтя вы сами знаете что получается.
Да, только в тех случаях, с которыми сталкивался я, ложкой дегтя была отнюдь не 1С.
Не очень понимаю, что такое «открыть КонтрольПроведения», но если Вы имеет в виду проверку на условия, подобные упомянутому в статье, то в объекте(документе) происходит только настройка структуры условий, а сама проверка по этим условиям — происходит в общем модуле(в частности в УТ модуль для проверок, связанных с перемещением материальных ценностей, так и называется — «Управление запасами»).
Я про ПроведениеСерверУТ.ВыполнитьКонтрольРезультатовПроведения.
Ну ради справедливости, &НаКлиенте и &НаСервере — это довольно удобный инструмент, помогающий оптимизировать выполнение кода, правда таких случаев, когда он реально необходим — не очень много.
У него другая проблема, он разбивает flow, то есть если вам нужно сделать:
f() <- someData();
DIALOG myForm OBJECTS a INPUT DO // ОткрытьФорму
IF isSomething(a) DO
DIALOG otherForm OBJECTS b = a DO { // ОткрытьФорму
g(b) <- someInput(b);
APPLY;
}
Вам придется штук 5 процедур сделать (потому как ОткрытьФорму можно только на клиенте, а к данным обратиться только на сервере).
Плюс при таком явном flow на клиенте, неизбежно возникает проблема с блокированием EDT (что особо критично в веб). И как следствие там еще callback'и добавлять, а значит еще несколько процедур сделать. То есть их штук 7 в таком примитивном бизнес-процессе будет. Это нормально по вашему?
А так за в несколько раз меньшую сумму
Вы считаете что человек-оркестр стоит дешевле двух узких специалистов? Это заблуждение, тут зачастую наоборот, дешевле и проще найти двух «обычных» разработчиков, научившихся «делать по аналогии», чем одну «звезду».
Да, только в тех случаях, с которыми сталкивался я, ложкой дегтя была отнюдь не 1С.
Что не отрицает того факта, что 1С очень далек от бочки меда. Кстати в современном варианте, 1С от JS вообще не сильно отличается. Только без возможности использования функций в качестве значений и замыканий, а это то немногое из-за чего JS вообще имеет смысл использовать.
То есть их штук 7 в таком примитивном бизнес-процессе будет. Это нормально по вашему?
Это будет штук 7 читаемых, практически стандартных процедур. Для меня, в случае высоконагруженной базы главный критерий — это её работоспособность. И да, если база работает с 7 несуразными процедурами, но встает с одной красивой строкой кода, то 7 процедур — это нормально.
Вы считаете что человек-оркестр стоит дешевле двух узких специалистов? Это заблуждение, тут зачастую наоборот, дешевле и проще найти двух «обычных» разработчиков, научившихся «делать по аналогии», чем одну «звезду».
Нет, я считаю, что человек-оркестр стоит дешевле двух специалистов «широкого» профиля, а если брать «обычных»специалистов «узкого» профиля(а тем более научившихся только делать «по аналогии»), то их нужно уже человек пять, а это получается дороже.
Что не отрицает того факта, что 1С очень далек от бочки меда.
Так никто же не говорит, что 1С — это какой-то непогрешимый идеал. Это просто инструмент со своими недостатками. Как впрочем и любой другой из перечисленных в этой теме.
Это будет штук 7 читаемых, практически стандартных процедур.
Как 7 процедур из одной строки с рандомными названиями и callback'ами могут быть читаемыми?
Для меня, в случае высоконагруженной базы главный критерий — это её работоспособность. И да, если база работает с 7 несуразными процедурами, но встает с одной красивой строкой кода, то 7 процедур — это нормально.Не, это я как раз понимаю. Но в 1С вместо того, чтобы сделать простую разработку масштабируемой, просто переложили все на разработчика, то есть сказали это теперь ваши проблемы. То есть повысили порог вхождения до очень высокого уровня, плюс заодно добавили кучу возможностей выстрелить себе в ногу.
Нет, я считаю, что человек-оркестр стоит дешевле двух специалистов «широкого» профиля, а если брать «обычных»специалистов «узкого» профиля(а тем более научившихся только делать «по аналогии»), то их нужно уже человек пять, а это получается дороже.
Даже пять человек будут дешевле. Но опять таки речь о другом. Как раз платформа должна решать большинство проблем, и тогда достаточно будет человека даже без опыта в IT. И найти его куда проще, проверено опытом.
Так никто же не говорит, что 1С — это какой-то непогрешимый идеал.
Вопрос в том, что 1С умудрился накосячить как раз во всем в чем мог. Если честно даже удивительно. Они взяли все самое худшее от существующих технологий, при этом выкинув самое лучшее.
Придирки по мелочам:
Придирки не по мелочам: описывать структуры данных текстом, как предлагает lsfusion, да еще и руслишем в наше время это дичайшая дичь.
Полторы тысячи таблиц и десятки тысяч их атрибутов в боевой системе, сотни тысяч пропертей этих атрибутов и таблиц (на каждом размерность, тип, индексируемость, доступность) — совсем не редкость. Писать все тестом, следя за правильностью написания, соответствие размерностям, отслеживать связи.
Система гарантирует глупую ненужную работу колоссального объема специалистам.
Это будет тот еще адский ад.
1С хороша согласованными инструментами, которые избавляют специалиста от геморроя.
Опять вы со своим визуальным программированием. Ну плохо оно работает на больших проектах с большими командами хотя бы из-за системы контроля версий. Как вы будете gitflow поддерживать, например? Как merge conflict'ы решать? Смиритесь наконец.
Писать все тестом, следя за правильностью написания, соответствие размерностям, отслеживать связи.
Вообще это все IDE complet'ит, проверяет ошибки и раскрашивает. Особенно если в языке есть явная типизация.
1С хороша согласованными инструментами, которые избавляют специалиста от геморроя.
Серьезно? Полотна кода с процедурами по 2400 строк и сотнями if'ов и ручных sql запросов, без каких либо проверок типов.
https://lsfusion.org/comparison — за гранью добра и зла...
Очень аргументированно.
А что там аргументировать? Вы перейдите и посмотрите…
"No ORM, Yes SQL"
"Эффективное общение клиента с сервером"
"Бесшовное подключение Java-библиотек / SQL-функций"
"Эргономичный язык"
Ну перешел. И что?
Так в 1С если в цикле обращаться по ссылке, то для 100 записей будет 100 запросов. Собственно поэтому 1С и рекомендует везде писать SQL запросы руками (то есть грубо говоря забить на 1С)
Ну так запустите УТ, откройте какой-нибудь документ и увидите, что там сначала будет 25 текущих вызовов, потом на любом следующем около 4. Ну или попробуйте тонкого клиента на нестабильной сети (которая TCP/IP пакеты теряет) какой-нибудь запустить.
Ну расскажите, как в 1С сторонний код подключить к серверу приложений. Так чтобы затрат на вызов не было, а не упаси боже ActiveX. Ну и заодно про то как custom SQL функции подключать в 1С, учитывая что там лицензионно запрещено лазить в базу.
Ну и как в 1С к примеру с явной типизацией или замыканиями? Вы же понимаете, что более убогий язык чем 1С надо поискать. Это такой JavaScript, в котором вырезали все его преимущества.
No ORM, Yes SQL
Так в 1С если в цикле обращаться по ссылке, то для 100 записей будет 100 запросов. Собственно поэтому 1С и рекомендует везде писать SQL запросы руками (то есть грубо говоря забить на 1С)
Эффективное общение клиента с сервером
Ну так запустите УТ, откройте какой-нибудь документ и увидите, что там сначала будет 25 текущих вызовов, потом на любом следующем около 4. Ну или попробуйте тонкого клиента на нестабильной сети (которая TCP/IP пакеты теряет) какой-нибудь запустить.
Бесшовное подключение Java-библиотек / SQL-функций
Ну расскажите, как в 1С сторонний код подключить к серверу приложений. Так чтобы затрат на вызов не было, а не упаси боже ActiveX. Ну и заодно про то как custom SQL функции подключать в 1С, учитывая что там лицензионно запрещено лазить в базу.
Эргономичный язык
Ну и как в 1С к примеру с явной типизацией или замыканиями? Вы же понимаете, что более убогий язык чем 1С надо поискать. Это такой JavaScript, в котором вырезали все его преимущества.
Так в 1С если в цикле обращаться по ссылке, то для 100 записей будет 100 запросов. Собственно поэтому 1С и рекомендует везде писать SQL запросы руками (то есть грубо говоря забить на 1С)
Грубо говоря — для разных задач 1С позволяет использовать разный инструмент — правильно? Где то можно и по ссылке использовать, где то оптимальным будет запрос написать… в чем минус то? В lsFusion — нельзя написать запрос в цикле?
Эффективное общение клиента с сервером
25 вызовов… на любом следующем 4 — это ж хорошо — часть данных закешировалась… Конечно идеально было бы один вызов всегда, но так ли это смертельно; веб сайты не сильно отличаются обновил страницу хабра — 50 запросов.
В 1С есть и шифрование и сжатие...
Ну расскажите, как в 1С сторонний код подключить к серверу приложений
внешние компоненты по технологии native api, и да в 1С я могу и java библиотеки использовать...
Ну и как в 1С к примеру с явной типизацией или замыканиями?
никак с типизацией и замыканиями, это не типизированный и не функциональный язык… я даже больше скажу там операций инкремента на единицу нет...
Грубо говоря — для разных задач 1С позволяет использовать разный инструмент — правильно? Где то можно и по ссылке использовать, где то оптимальным будет запрос написать… в чем минус то? В lsFusion — нельзя написать запрос в цикле?
В lsFusion можно написать FOR, но он в большинстве случаев скомпилируется в один SQL запрос. А если 1С писать не нативным SQL, то будет классическая N+1 проблема. А в 1С даже никакого prefetching'а как в других ORM нет.
25 вызовов… на любом следующем 4 — это ж хорошо — часть данных закешировалась… Конечно идеально было бы один вызов всегда, но так ли это смертельно
Если у вас сервак в облаке то очень критично. Собственно зайдите на demo-ma.1c.ru. Там монитор в окно кинуть хочется от этих задержек. Или вы думаете себе 1С не мог позволить нормальный сервак поставить?
внешние компоненты по технологии native api, и да в 1С я могу и java библиотеки использовать
Ну про SQL вы не ответили. А про native api это вы это имеете ввиду? Очень бесшовно.
никак с типизацией и замыканиями, это не типизированный и не функциональный язык
Ну то есть язык убогий, чуть менее чем полностью. Собственно что в сравнении и отмечено.
В lsFusion можно написать FOR, но он в большинстве случаев скомпилируется в один SQL запрос.
То есть возможна ситуация с некачественной генерацией. Чего в 1С можно избежать запросом… правильно я вас понял?
Если у вас сервак в облаке то очень критично. Собственно зайдите на demo-ma.1c.ru.
Никто ж не говорит что стандартные конфигурации идеально оптимизированы
Ну про SQL вы не ответили. А про native api это вы это имеете ввиду? Очень бесшовно.
Достаточно раз написать и обернуть удобным образом...lsFusion позволяет подключать dll, позволяет работать с Com-компонентами — бесшовно?
Ну то есть язык убогий, чуть менее чем полностью
И вы не понимаете что это далеко не главное?
То есть возможна ситуация с некачественной генерацией. Чего в 1С можно избежать запросом… правильно я вас понял?
Нет, если вы в 1С напишете цикл это будет цикл. В lsFusion
FOR f(a) DO
g(a) <- h(a);
Скомпилируется в:
g(a) <- h(a) WHERE f(a);
И выполнится одним запросом.
Никто ж не говорит что стандартные конфигурации идеально оптимизированы
Ну если даже стандартные не идеально оптимизировано, что тогда творится с нестандартными, где нет миллионных бюджетов.
Достаточно раз написать и обернуть удобным образом...lsFusion позволяет подключать dll, позволяет работать с Com-компонентами — бесшовно?
В lsFusion достаточно написать
myAction INTERNAL 'MyAction' (A);
Все подключился java-класс в ту же виртуальную машину.
doSomething(A a) {
myAction(a);
}
Или можно в lsfusion.xml:
<util:list id="customLifecycleListeners">
<ref bean="equipmentServer"/>
</util:list>
И при помощи Java Spring автоматически подключится любой java-сервер. То есть именно фишки динамического java classloading используются.
И вы не понимаете что это далеко не главное?
Так в сравнении это один из 33 пунктов.
Это мне напомнило сравнение 1с и Аксапты/САПа персонажем по имени «Гений 1С» aka fixin. Примерно такой же уровень получился…
Обращение сервера к клиенту — минусы в колонках с 1С явно перепутаны.
Там вот какая штука скорее всего имеется ввиду. В ОФ(1С<8.2), там один flow, то есть пишется какой-то бизнес-процесс, в нем надо что-то спросить у пользователя — не вопрос: ставим ОткрытьФормуМодально, читаем то что надо, поехали дальше. А в УФ (1С>=8.2 условно) надо извращаться — там сверху был коммент NitroJunkie на эту тему.
Я возможно упустил из виду. Вопрос про количество реальных внедрений решений на базе этого IsFusion уже был?
Господи, что это?! Фортраноподобный 1С?
А у Вас фортранофобия? Вообще тут совершенно другой принцип работы с данными и логикой GUI по сравнению с 1С.
Ну GUI в статье отсутствовал, так что про него судить не могу. У меня да, фортранофобия и паскалефобия, я привык к современным языкам. Это не значит, что они лучше фортрана, но фобии и предпочтения это же дело персональное, правда?
Так это вообще была локальная статья именно про регистры. Про GUI будут отдельные статьи. Посмотрите, например, реализацию Подбора.
А Вы считаете 1С современным языком?
я привык к современным языкам
А Вы считаете 1С современным языком?
Сравнение с Фортраном основано только на том, что ключевые слова пишутся большими буквами?
Не только. Хотя да, на SAP ABAP оно похоже чуть больше, чем на Фортран
Это все схожести на лексическом уровне. То есть Fortran (вернее не Fortran, а скорее Algol или Oberon) напоминает большими буквами в ключевых словах, ABAP большим количеством ключевых слов (больше не знаю, чем может напоминать, но я видел мало кода на ABAP). Так можно и c SQL сравнить, хотя с SQL схожесть можно найти уже не только на лексическом уровне. Но если посмотреть чуть выше, хотя бы на синтаксический уровень, то нет, не похож lsfusion ни на Fortran, ни на ABAP, совсем.
Хм… посмотрел на UI в демо примере. Вы уверены, что стоит выносить это в паблик?
Ну а как запретить неадекватным личностям что-то редактировать, но разрешить адекватным? Сейчас товарищи с мисты успокоятся и перевосстановим базу.
1) Можете показать реальные расчет остатка по 1 позиции из таблицы в 10 млн.записей?
2) Как насчет реструктуризации таблицы при ее изменении с этими 10 млн?
2) Как насчет реструктуризации таблицы при ее изменении с этими 10 млн?
Я вижу, что Виталик все-таки добрался в отпуске до интернета и одобрил древние комментарии.
1) А можете уточнить, о каком расчете идет речь и в какой таблице должно быть 10 млн. записей? На практике в похожих регистрах в рабочих базах у нас бывает по несколько сот миллионов записей. Естественно, текущий остаток в них помечен как MATERIALIZED и его обновление идет по индексу в таблице с остатками. При этом соответственно неважно сколько всего записей в таблице с регистром, а обновление идет за логарифм от количества записей в таблице с остатками.
2) О какой реструктуризации идет речь? Добавление пустой колонки в PostgreSQL идет в любую таблицу практически мгновенно (такая у них структура хранения данных). Но на практике иногда приходилось добавлять и пересчитывать колонки в таблицы с сотнями миллионов записей. На это могло уходить до часа.
1) А можете уточнить, о каком расчете идет речь и в какой таблице должно быть 10 млн. записей? На практике в похожих регистрах в рабочих базах у нас бывает по несколько сот миллионов записей. Естественно, текущий остаток в них помечен как MATERIALIZED и его обновление идет по индексу в таблице с остатками. При этом соответственно неважно сколько всего записей в таблице с регистром, а обновление идет за логарифм от количества записей в таблице с остатками.
2) О какой реструктуризации идет речь? Добавление пустой колонки в PostgreSQL идет в любую таблицу практически мгновенно (такая у них структура хранения данных). Но на практике иногда приходилось добавлять и пересчитывать колонки в таблицы с сотнями миллионов записей. На это могло уходить до часа.
Да, вы меня правильно поняли, спасибо за ответ.
и всё-таки хотелось бы знать 1) по времени
и всё-таки хотелось бы знать 1) по времени
Вообще в эксплуатации всегда включен MATERIALIZED на текущий остаток. Поэтому чтение идет из соответствующей таблицы с остатками по индексу в среднем за миллисекунды.
Если же не хранить текущий остаток, а рассчитывать на основе регистра, то время зависит от очень многих факторов. Как минимум, должен быть индекс ко товару-складу (иначе будет прогон по всей таблице). При наличии индекса расчет будет идти по индексу только на основе записей с этим товаром и складом. Скорость его зависит от того, есть ли нужные страницы в shared buffers СУБД или кэше диска, а также от количества записей. Если в кэше нету, то тогда пойдет обращение к диску и все будет зависеть от скорости диска. Кроме того, может включиться параллелизм, а может не включаться. В общем параметров очень много, но в среднем на 10 млн записей по индексу, если записи в кэше, то будет несколько сот миллисекунд я думаю.
Если же не хранить текущий остаток, а рассчитывать на основе регистра, то время зависит от очень многих факторов. Как минимум, должен быть индекс ко товару-складу (иначе будет прогон по всей таблице). При наличии индекса расчет будет идти по индексу только на основе записей с этим товаром и складом. Скорость его зависит от того, есть ли нужные страницы в shared buffers СУБД или кэше диска, а также от количества записей. Если в кэше нету, то тогда пойдет обращение к диску и все будет зависеть от скорости диска. Кроме того, может включиться параллелизм, а может не включаться. В общем параметров очень много, но в среднем на 10 млн записей по индексу, если записи в кэше, то будет несколько сот миллисекунд я думаю.
Авторы статьи явно совершенно не компетентны в обсуждении 1С. Имеют исключительно поверхностные знания как о платформе так и о прикладных решениях (конфигурациях).
Хочется верить, что статья — всего лишь плод этих ошибок и недостатка знания об 1С, а не продукт созданный с целью преднамеренного введения в заблуждение читателя.
А вообще как-то не очень красиво, когда конструктор танка начинает сравнивать своё детище с бомбардировщиком, имея чисто обывательское представление об авиации.
Хотите сравнить два продукта — ради бога. Только потрудитесь разобраться в обоих хоть чуть-чуть поглубже, чем только по рекламным статьям с сайта 1С.
Хочется верить, что статья — всего лишь плод этих ошибок и недостатка знания об 1С, а не продукт созданный с целью преднамеренного введения в заблуждение читателя.
А вообще как-то не очень красиво, когда конструктор танка начинает сравнивать своё детище с бомбардировщиком, имея чисто обывательское представление об авиации.
Хотите сравнить два продукта — ради бога. Только потрудитесь разобраться в обоих хоть чуть-чуть поглубже, чем только по рекламным статьям с сайта 1С.
Во-первых, эта статья — просто Tutorial по тому, как в lsFusion реализовывать функционал регистров как в 1С. Сравнение тут не было самоцелью.
Во-вторых, на хабре принято аргументировать и приводить факты, а не просто обвинять в чем-то. Если есть какие-то претензии к статье, то, пожалуйста, укажите пункты, где была дезинформация. Если она подтвердится, то статья будет скорректирована.
К сожалению, во всем мире принято полагаться на данные с официального сайта производителя. Цитаты приведены именно с него, и нигде не указано, что это рекламные материалы и не соответствуют действительности.
Во-вторых, на хабре принято аргументировать и приводить факты, а не просто обвинять в чем-то. Если есть какие-то претензии к статье, то, пожалуйста, укажите пункты, где была дезинформация. Если она подтвердится, то статья будет скорректирована.
Только потрудитесь разобраться в обоих хоть чуть-чуть поглубже, чем только по рекламным статьям с сайта 1С
К сожалению, во всем мире принято полагаться на данные с официального сайта производителя. Цитаты приведены именно с него, и нигде не указано, что это рекламные материалы и не соответствуют действительности.
Sign up to leave a comment.
Как могли бы выглядеть регистры в 1С при наличии ООП