Хотя конечно всегда интересен механизм подсчета всех этих процентов. Компании часто используют систему A для одних процессов, а систему Б для других процессов. Например, тот же SAP закрывает оперативную часть, а 1С - бухгалтерию. Как тогда интересно процентики считаются...
То, что вы лезете в формат исходников - исключительно ваша осознанная воля, а может, даже и провокация.
Что за ерунда ? Смотрите, в базовой версии что-то поменяли в конфигурации (не в коде, а то, что приводит к изменениям в конфигурационных xml-файлах). Вы у себя тоже что-то поменяли. Далее при слиянии в git'е вы получаете конфликт. Как вы его смержите не лезя в формат хранения ?
Так Вы сами уходите от аргументированного разговора. Просто утверждаете, что все хорошо.
Вы отрицаете тот факт, что 1С хранит метаданные в xml-формате ? Мне местами приходится сливать такие файлы (jrxml в JasperReports) - удовольствие еще то. Xml-формат вообще не очень хорошо подходит под разные слияния, так как там различия в строках видны очень плохо, и много лишних символов/слов. И опять же, получается, что для разработки на 1С мне нужно знать их формат хранения данных параллельно с визуальным интерфейсом ?
Вы отрицаете, что в типовых конфигурациях 1С типичный спагетти-код ? Ну вот вам пример :
Как это можно править и потом нормально "сливать" ?
Или давайте посмотрим код проведения, например, поступления, который построен на времянка. Если это не говнокод, то что ? А это в первую очередь придется и править и сливать.
Я понимаю, что в вашем выдуманном мире это все делается легко и красиво, а на практике, сливание спагетти-кода и главное конфигурационных xml-файлов - это жесточайшая боль. Но согласен, что спорить об этом бесполезно.
Поэтому меня и интересует, как это делается не в фантазиях, а на практике. Вот, например, у Ламоды и УНФ.
А можно поподробнее ? Как вы сливаете исправленный код, если не используете расширений ? Что вы делали с "лишним" кодом, который есть в типовой, но вам не нужен, или который надо исправить под свои нужды ?
С каких пор надо покупать open source ? Но вообще да, стоило брать lsfusion. Особенно веселит, что надо платить за лицензии 1С для подключений терминалов. То есть мало того, что сам все пишешь, так ещё и платишь 1с ни за что.
В целом, можно работать и на типовом, если готов пожертвовать какими-то хотелками.В рамках корпорации...
В рамках крупных компаний действительно всегда требуются доработки, поэтому качество платформ в части расширяемости (а именно модульности, поддержки ООП и т.д) действительно важны.
Однако и для малого бизнеса тоже доработки важны. Ведь малый бизнес часто и выживает за счет того, что может предлагать определенную гибкость, а также имеет свои специфические процессы. Ведь, если малый бизнес будет работать "как все", то он тупо проиграет большим игрокам просто за счет оборота и удельных издержек. Другое дело, что у него нет больших ресурсов на доработки. И ему нужно делать все быстро и дешево.
По этой причине аргументы, что вот важен функционал коробок, а платформа не важна - очень странные.
Поэтому изменения пилим в конфе, но с сохранением поддержки.
А можно уточнить, что значит с сохранением поддержки ?
Там просто у вас в видео говорится, что вот как классно, что УНФ развивается и даже как-то сохраняется возможность обновлений. Можете на практике объяснить, как это выглядит ?
То есть вот появляется новая версия УНФ. Как вы дальше merge делаете ? При переработке 30% функционала там же повесится можно, сливая по сути спагетти код (а я видел код типовых конфигураций, который на времянках построен для оптимизации). Даже в IntelliJ IDEA это не так легко, а в 1С - это же вообще вилы будут. То есть, например, у вас разные люди что-то правили с какими-то целями. Кто потом будет определять, а нужно применить изменения из типовой, или брать ваши изменения ? А если они противоречат ?
А многие почему-то говорят, что продукты 1С просто идеальные и закрывают 100% бизнеса. А оказывается, что даже для стандартного розничного магазина одежды есть только 70% функционала, а остальные 30% приходится все-таки самому допиливать. А дальше привет всем косякам платформы 1С.
Кстати, по этому поводу вопрос. А вот эти 30% доработок вы делали, как расширения ? Или просто правили напрямую код УНФ ? Если правили, то как я понимаю, дальше УНФ будет жить своей жизнью, а ваши решения своей ?
MS SQL - "блокировочник", соответственно блокировки там встречаются гораздо чаще, чем в PostgreSQL (он "версионник"). В MS SQL есть режим snapshot isolation, но это позволяет лишь частично использовать режим версионника.
Формально, MS SQL заявляет, что он умеет работать как версионник, а именно через READ_COMMITTED_SNAPSHOT :
If you set the READ_COMMITTED_SNAPSHOT database option to ON, the database engine uses row versioning and snapshot isolation as the default, instead of using locks to protect the data.
ALTER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON
Так а на практике, вы часто включаете такой режим ? Или в 95% случаев оставляете блокировочник ?
Встречали ситуации, когда БД временных таблиц не справляется с нагрузкой (многочисленные блокировки и прочие ситуации). Поэтому режим MVCC в MS SQL, особенно в связке с 1С, надо использовать осторожно и обязательно анализировать на предмет проблем с tempDB.
А в чем связь ? Как версионность связана с временными таблицами ? Даже, если в MS SQL, как в PostgreSQL, используются системные каталоги для хранения информации по временным таблицам, то это же разные записи и блокировок быть должно (по крайней мере, в PostgreSQL такого нет).
Часто возникают ситуации, когда запрос выполняется за доли секунды на любом количестве данных (это я про моделирование), но при этом он накладывает избыточные блокировки и начинает влиять на другие запросы.
Вроде же Microsoft SQL Server поддерживает MVCC, разве нет ? Причем, насколько я помню, хотя возможно ошибаюсь, он там реализован немного по-другому. Там запись идет сразу в таблицы, а старые данные сохраняются сбоку (в Oracle вроде также). И это избавляет от необходимости vacuum (хотя имеет тоже свои недостатки).
Дело в том, что по опыту в PostgreSQL блокировки мимальные (фактически, только на записи). Проблемы там возникают, если кто-то решил в одной записи хранить что-то, что изменяют сразу сотни пользователей. Мне вот интересно, а часто Вы в своей практике используете MVCC для MS SQL Server, и он нормально работает ? Если нет, то почему не использовать ?
Также бывает, что запросу не хватает каких-то индексов, он выполняет избыточные чтения, отнимает ресурсы у других.
К сожалению, тут палка о двух концах. Если на каждый неэффективный запрос добавлять индекс (начнем с того, что это не всегда помогает), то будет как минимум две проблемы. Во-первых, база будет расти и замедляться транзакции, так как больше индексов будет нужно будет обновлять. А во-вторых, возможны ситуации (у нас такие были), когда добавление одного индекса начинает валить другие запросы, когда они радостно его видят, и начинают использовать. После этого план может стать таким, что запрос замедлиться в разы. То есть это нарушает принцип, что я вроде не менял в определенном месте, а все стало тормозить.
Но это может быть долго и повлечет за собой возможные функциональные ошибки. Поэтому индексный тюнинг - это простой, незатратный способ, который нельзя исключать.
К сожалению, очень ограниченный тюнинг. Нам, в lsFusion, конечно проще, так как мы можем добавить MATERIALIZED на любом промежуточное вычисление, и гарантированно функционал не измениться. Но разработчики тоже часто этим злоупотребляют, что приводит к тем же проблема, что я и описал выше с индексами.
В каждом случае можно найти подходящее решение и компромисс.
Ну тут решение простое. Просто использовать специализированную не совсем оперативную аналитическую базу, как Вы и написали выше. Только обычно для этого мы используем не копию основной, а именно СУБД заточенную под быстрые запросы (как правило, Druid). Скорость будет просто в десятки (если не сотни) раз выше. Но да, под нее отчеты пишутся отдельно. Просто когда поступает задача на отчетность, то сразу надо принимать решение к какой базе делать.
У нас просто немного другой опыт. Администраторы обычно либо сразу валят, что это не наша зона ответственности, а "криво" написана программа - идите к разработчикам. Но все равно, по умолчанию, проблема возвращается к тому разработчику, который делал задачу. А потом, если он не знает, как оптимизировать, то проблема уходит на более высокий уровень, то есть к разработчикам, которые лучше разбираются.
Но в любом случае, все вернется к разработчику. То есть в 95% процентах случаях проблема в кривом коде, а не настройках. Даже, если аудит выявит проблему, то все равно нужен разработчик, чтобы переделать код.
Более того, часто приходится и к бизнесу обращаться. То есть, например, бывает бизнес просит : а сделайте отчет, который за последние 5 лет по всем розничным чекам найдет какую-то корреляцию. Понятно, что чудес не будет, и тут есть essential complexity. Запрос будет сильно насиловать базу, но разработчик с этим мало что может сделать. Максимум, что он может сделать - это преподсчеты, или инкрементное обновление с увеличением времени транзакций. Но опять же, это надо согласовывать с бизнесом, так как оперативность данных может измениться.
Мы (как разработчики) просто тоже сталкивались с внешним аудитом, и, если честно, не уверен, что в этом была польза. Со стороны аудита, как правило, действительно находятся умные и разбирающиеся люди (как и с нашей стороны). Но они не знают глубоко специфики работы программы. Да, они тратят время и находят узкие места, о которых мы и сами знаем. Но, как правило, там нет простого решения (если бы оно было, мы бы сами его давно сделали). И любое изменение имеет свои минусы, на которые, например, бизнес не хочет идти (или что приведет к другим техническим проблемам).
А как разработчик 1С это увидит? У него этой информации нет. Более того, среднестатистический разработчик даже не хочет ее иметь и максимально ограждает себя от нее: «Моя работа код писать, а база тормозит у админов, разбирайтесь с настройками, у меня все хорошо, на стенде отчет летает».
Что, реально так говорит ? Это точно разработчик ? Даже, когда сделает что-то типа SELECT * FROM a FULL JOIN b ON ...? И у него будет на 100 записях работать, а на 50.000 не выполнится никогда ? Или просто for'ом начнет сотни тысяч запросов делать.
Мне кажется, что в таких случаях не аудит нужен. А разработчика просто менять...
Касса - это маленькая часть розницы. Да и в базовой кассе 1С тоже нету очень много чего. Например, сложной системы лояльности с накоплением бонусов и прочим. А в lsFusion ERP есть из коробки.
Ну сильно предвзято. Никакой особой боли нет, просто надо учитывать, что это предметно-ориентированная платформа, а не язык общего назначения.
Ага, только вручную надо управлять логикой клиент-сервер, блокировками, писать псевдо-SQL и т.д.
А если еще посмотреть "оптимизированный" код в базовых версиях, который на времянках построен, то называть "легко" дорабатывать этот спагетти-код язык не поворачивается.
Ну конечно. Я вижу, Вы не особо имеете представление, какие задачи есть в крупной рознице (начиная от всяких акций, ассортиментных матриц, допвыкладкой, планограммами и таких там еще десятки). Именно эти коробки в базовой версии ну никак не подходят для крупной розницы. Ровно по той же самой причине, почему и lsFusion ERP не подходит для производственных предприятий.
Т.е. вот так прямо сами посылаете к 1С. Законченного, комплексного решения нет.Сразу вопрос - если бух-рия у нас на 1С, то зачем нам еще другая хорошая ERP?Чтобы держать программистов под разные системы?
Бухгалтерия - это одна маленькая задача относительно всей автоматизации предприятия. Там можно обойтись вообще без доработок и использовать ее для решения проблемы "бешеного принтера". Программистов под нее можно не держать, а пользоваться коробкой или аутсорсом.
Почему тогда весь учет не сделать в 1С ?
Потому что важен не учет, а управление. А вот управление не стандартизировано. Там каждый бизнес хочет чего-то своего, и доработка на 1С - это большая головная боль из-за некачественной платформы.
Держать зоопарк разных систем?
А Вы не в курсе, что часто у 1С бывает отдельно стоят 1С : БУХ, 1С : УТ и 1С : Розница. Это не зоопарк ? Почему 1С не может все сделать в одной системе ? Вот, например, у меня крупная розничная сеть. Можете мне предложить готовое решение, где будет и бухгалтерия, и ассортиментные матрицы, и печать ценников, и кассы и все это в одной конфигурации ?
Потребность там глобальная - автоматизировать бизнес-процессы компании розничной торговли. Да, только в статье по функционалу описаны, как именно автоматизируются конкретные процессы. Но дело в том, что такие процессы достаточно узкоспециализированы и интересны лишь небольшому кругу читалей, поэтому пока таких статей не делали. Но возможно в будущем сделаем.
Другие же статьи описывают более общие схемы (такие как подбор товаров в любых документах или логика изменения параметров). И это касается уже значительно большего числа процессов.
Про "мигрируем", то не вижу кейсов миграции с 1С. На столько все плохо?
Из 1С обычно идет миграция или через Excel файлы, или через Enterprise Data. Чаще всего именно из 1С мигрируем. Но в принципе, там не так важно, что за система с той стороны. Важен принцип и процесс перехода (а как именно делать импорт - это больше технический вопрос).
Вот, кстати, отличный повод написать статью про 2500 пользователей. Я бы с удовольствием почитал. И не маркетинговая статья нужна, а про реальные кейсы, их решение, уровень поддержки (SLA), возникшие в ходе внедрения и эксплуатации проблемы.
Так писали же. Только не относительно одного внедрения, а многих.
Объективная реальность показывает, что 1С лучше, т.к. количество внедрений 1С на много порядков больше, чем количество внедрений изфьюжн.
Всегда то, что появилось раньше - используют больше. По такой логике SAP в разы лучше, так как на нем работают гораздо больше. А на практике бывает, как правило, наоборот. То, что более свежее, не обладает тем техническим долгом, который есть у устаревших продуктов.
Было бы интересно увидеть несколько статей про внедрение этой штуки с подробным описанием и тестированием производительности, юзабилити и всего прочего.
И что именно Вы бы хотели увидеть ? Вот демка - это основа, на которой работают розничные сети (хотя понятно, что каждая сеть уникальна, и много чего доделывается под конкретные процессы). И в целом, в блоге lsFusion много описано подробностей того, как это все дорабатывается и внедряется.
Вы считаете, что это все бутафория, и на самом деле клиенты вымышленные ? Что касается надежности, то есть много клиентов, у которых кассы (не FMCG) работают в онлайне с основным сервером (как обычные пользователи). То есть любое падение сервера - это остановка магазинов. Так что выводы по надежности платформы можете сделать сами.
У вас тут 147% получилось :
Хотя конечно всегда интересен механизм подсчета всех этих процентов. Компании часто используют систему A для одних процессов, а систему Б для других процессов. Например, тот же SAP закрывает оперативную часть, а 1С - бухгалтерию. Как тогда интересно процентики считаются...
Что за ерунда ? Смотрите, в базовой версии что-то поменяли в конфигурации (не в коде, а то, что приводит к изменениям в конфигурационных xml-файлах). Вы у себя тоже что-то поменяли. Далее при слиянии в git'е вы получаете конфликт. Как вы его смержите не лезя в формат хранения ?
Так Вы сами уходите от аргументированного разговора. Просто утверждаете, что все хорошо.
Вы отрицаете тот факт, что 1С хранит метаданные в xml-формате ? Мне местами приходится сливать такие файлы (jrxml в JasperReports) - удовольствие еще то. Xml-формат вообще не очень хорошо подходит под разные слияния, так как там различия в строках видны очень плохо, и много лишних символов/слов. И опять же, получается, что для разработки на 1С мне нужно знать их формат хранения данных параллельно с визуальным интерфейсом ?
Вы отрицаете, что в типовых конфигурациях 1С типичный спагетти-код ? Ну вот вам пример :
Hidden text
Процедура ОбработатьСтрокуТЧ(ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения) Экспорт Если КэшированныеЗначения = Неопределено Тогда КэшированныеЗначения = ОбработкаТабличнойЧастиКлиентСервер.ПолучитьСтруктуруКэшируемыеЗначения(); КонецЕсли; ПроверитьАссортиментСтроки( ТекущаяСтрока, СтруктураДействий); ЗаполнитьНоменклатуруПоНоменклатуреПоставщикаВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьНоменклатуруПоставщикаПоНоменклатуреВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПроверитьСопоставленнуюНоменклатуруПоставщикаВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьСлужебныеРеквизитыПоНоменклатуреВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПроверитьКорректностьЗаполнитьХарактеристикиИУпаковки( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПроверитьКорректностьЗаполнитьХарактеристикиКиЗ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоНеОтгружатьСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ЗаполнитьGTINВСтроке( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоУпаковокПоФактуВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоУпаковокСуффиксИзОтклоненияВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоЕдиницВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоЕдиницСуффиксВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоУпаковокВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоУпаковокСуффиксВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоОтклонение( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоУпаковокПоВесу( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьКоличествоУпаковокПоОбъему( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьВесОбъемВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьЦенуЗаУпаковкуВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьЦенуЗаказаЗаУпаковкуВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьВидЦеныВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ЗаполнитьЦенуПродажиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьЦенуПродажиПоАссортиментуВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьЦенуЗакупкиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьУсловияПродажВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьУсловияЗакупокВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ЗаполнитьПартиюТМЦВЭксплуатации( ТекущаяСтрока, СтруктураДействий); ЗаполнитьСтавкуНДСВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьСтавкуНДСПоНоменклатуреВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ПересчитатьЦенуСНДС( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьСтавкуНДСВозвратнойТарыВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуРучнойСкидкиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуАвтоматическойСкидкиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьПроцентРучнойСкидкиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуВСтрокеТЧРасхождения( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьЦенуСкидкуПоСуммеВПродажахВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьЦенуСкидкуПоСуммеВЗакупкахВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьЦенуПоСуммеВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПересчитатьСуммуПродажиПоСуммеСНДС( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьЦенуПродажиПоСуммеПродажиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуСУчетомАвтоматическойСкидкиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуСУчетомРучнойСкидкиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуСУчетомСкидкиБонуснымиБалламиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПересчитатьСуммуСУчетомПогрешностиОкругленияВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПересчитатьСуммуНДСВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуСНДСВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуБезНДСВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуРеглВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьНДСРеглВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуПродажиВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуПродажиНДСВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьРеквизитыПоНоменклатуреВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПроверитьСтатьюАналитикуРасходов( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ОчиститьСуммуВознагражденияВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.УстановитьАктивностьСтроки( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПроверитьЗаполнитьСкладВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПроверитьЗаполнитьОбеспечениеВСтрокеТЧДокументаПродажи( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПроверитьЗаполнитьОбеспечениеВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ПроверитьПолучитьВариантКомплектации( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьФлагиРасхождениеИИзлишекПорча( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ОчиститьСуммуВзаиморасчетовВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ОчиститьАвтоматическуюСкидкуВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий); ЗаполнитьСодержаниеУслуги( ТекущаяСтрока, СтруктураДействий); ЗаполнитьСтатьюАналитикуРасходовПоУмолчанию( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьПартнера( ТекущаяСтрока, СтруктураДействий); ЗаполнитьПомещение( ТекущаяСтрока, СтруктураДействий); ЗаполнитьПродавца( ТекущаяСтрока, СтруктураДействий); ЗаполнитьУчетноеКоличествоНоменклатуры( ТекущаяСтрока, СтруктураДействий); ЗаполнитьПризнакНаличияНоменклатурыПродаваемойСовместно( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьПризнакБезВозвратнойТары( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьПризнакОтмененоБезВозвратнойТары( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьПризнакАктивностьБезВозвратнойТары( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьДубликатыЗависимыхРеквизитов( ТекущаяСтрока, СтруктураДействий); ПроверитьСериюРассчитатьСтатус( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ПересчитатьСуммуСверхЗаказаВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); УстановитьПризнакДляЗаполненияТекстовогоОписания( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьВариантОтраженияКорректировкиРеализации( ТекущаяСтрока, СтруктураДействий); ЗаполнитьВариантОбеспеченияПоДатеОтгрузки( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.НоменклатураПриИзмененииПереопределяемый( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ХарактеристикаПриИзмененииПереопределяемый( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьПризнакПринимаетсяКНУ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьПризнакАналитикаРасходовОбязательна( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьПризнакРаспределениеНДС( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьПризнакАналитикаДоходовОбязательна( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьПризнакАналитикаАктивовПассивовНеИспользуется( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьПризнакАналитикаРасходовЗаказРеализация( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьТипСтатьи( ТекущаяСтрока, СтруктураДействий); ЗаполнитьПризнакАдресногоХранения( ТекущаяСтрока, СтруктураДействий); ЗаполнитьПризнакИспользованияПомещений( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьПризнакиКатегорииЭксплуатации( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьРасхожденияПослеОтгрузки( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьРасхожденияПослеПриемки( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьРасхождения( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьПризнакНаличияКомментарияПриемка( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьПризнакНаличияКомментарияОтгрузка( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьПризнакНаличияКомментария( ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ЗаполнитьПризнакТоварногоМестаТребуетсяОбработка( ТекущаяСтрока, СтруктураДействий); ЗаполнитьПризнакДвиженияПоСкладскимРегистрам(ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ПриИзмененииТипаНоменклатурыИлиВариантаОбеспечения(ТекущаяСтрока, СтруктураДействий); ОбработкаТабличнойЧастиКлиентСервер.ПроверитьЗаполнитьНазначениеВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ОбработкаТабличнойЧастиКлиентСервер.ПриИзмененииНазначенияВСтрокеТЧ( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); ЗаполнитьНоменклатуруЕГАИС( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); АкцизныеМаркиКлиентСервер.ЗаполнитьИндексАкцизнойМаркиДляСтрокиТабличнойЧасти( ТекущаяСтрока, СтруктураДействий); ЗаполнитьСтрануПроисхожденияДляНомераГТД( ТекущаяСтрока, СтруктураДействий); ЗаполнитьСпособОпределенияСебестоимости( ТекущаяСтрока, СтруктураДействий); ЗаполнитьСпособОпределенияСебестоимостиСтрокой( ТекущаяСтрока, СтруктураДействий); ПоместитьОбработанныеСтрокиВКэшированныеЗначения( ТекущаяСтрока, СтруктураДействий, КэшированныеЗначения); КонецПроцедурыКак это можно править и потом нормально "сливать" ?
Или давайте посмотрим код проведения, например, поступления, который построен на времянка. Если это не говнокод, то что ? А это в первую очередь придется и править и сливать.
Я понимаю, что в вашем выдуманном мире это все делается легко и красиво, а на практике, сливание спагетти-кода и главное конфигурационных xml-файлов - это жесточайшая боль. Но согласен, что спорить об этом бесполезно.
Поэтому меня и интересует, как это делается не в фантазиях, а на практике. Вот, например, у Ламоды и УНФ.
А можно поподробнее ? Как вы сливаете исправленный код, если не используете расширений ? Что вы делали с "лишним" кодом, который есть в типовой, но вам не нужен, или который надо исправить под свои нужды ?
С каких пор надо покупать open source ? Но вообще да, стоило брать lsfusion. Особенно веселит, что надо платить за лицензии 1С для подключений терминалов. То есть мало того, что сам все пишешь, так ещё и платишь 1с ни за что.
В рамках крупных компаний действительно всегда требуются доработки, поэтому качество платформ в части расширяемости (а именно модульности, поддержки ООП и т.д) действительно важны.
Однако и для малого бизнеса тоже доработки важны. Ведь малый бизнес часто и выживает за счет того, что может предлагать определенную гибкость, а также имеет свои специфические процессы. Ведь, если малый бизнес будет работать "как все", то он тупо проиграет большим игрокам просто за счет оборота и удельных издержек. Другое дело, что у него нет больших ресурсов на доработки. И ему нужно делать все быстро и дешево.
По этой причине аргументы, что вот важен функционал коробок, а платформа не важна - очень странные.
А можно уточнить, что значит с сохранением поддержки ?
Там просто у вас в видео говорится, что вот как классно, что УНФ развивается и даже как-то сохраняется возможность обновлений. Можете на практике объяснить, как это выглядит ?
То есть вот появляется новая версия УНФ. Как вы дальше merge делаете ? При переработке 30% функционала там же повесится можно, сливая по сути спагетти код (а я видел код типовых конфигураций, который на времянках построен для оптимизации). Даже в IntelliJ IDEA это не так легко, а в 1С - это же вообще вилы будут. То есть, например, у вас разные люди что-то правили с какими-то целями. Кто потом будет определять, а нужно применить изменения из типовой, или брать ваши изменения ? А если они противоречат ?
А многие почему-то говорят, что продукты 1С просто идеальные и закрывают 100% бизнеса. А оказывается, что даже для стандартного розничного магазина одежды есть только 70% функционала, а остальные 30% приходится все-таки самому допиливать. А дальше привет всем косякам платформы 1С.
Кстати, по этому поводу вопрос. А вот эти 30% доработок вы делали, как расширения ? Или просто правили напрямую код УНФ ? Если правили, то как я понимаю, дальше УНФ будет жить своей жизнью, а ваши решения своей ?
Я про то, когда там из-за FULL JOIN и неправильной статистики одной из частей включится Nested Loop, то привет N^2.
Формально, MS SQL заявляет, что он умеет работать как версионник, а именно через READ_COMMITTED_SNAPSHOT :
Так а на практике, вы часто включаете такой режим ? Или в 95% случаев оставляете блокировочник ?
А в чем связь ? Как версионность связана с временными таблицами ? Даже, если в MS SQL, как в PostgreSQL, используются системные каталоги для хранения информации по временным таблицам, то это же разные записи и блокировок быть должно (по крайней мере, в PostgreSQL такого нет).
Вроде же Microsoft SQL Server поддерживает MVCC, разве нет ? Причем, насколько я помню, хотя возможно ошибаюсь, он там реализован немного по-другому. Там запись идет сразу в таблицы, а старые данные сохраняются сбоку (в Oracle вроде также). И это избавляет от необходимости vacuum (хотя имеет тоже свои недостатки).
Дело в том, что по опыту в PostgreSQL блокировки мимальные (фактически, только на записи). Проблемы там возникают, если кто-то решил в одной записи хранить что-то, что изменяют сразу сотни пользователей. Мне вот интересно, а часто Вы в своей практике используете MVCC для MS SQL Server, и он нормально работает ? Если нет, то почему не использовать ?
К сожалению, тут палка о двух концах. Если на каждый неэффективный запрос добавлять индекс (начнем с того, что это не всегда помогает), то будет как минимум две проблемы. Во-первых, база будет расти и замедляться транзакции, так как больше индексов будет нужно будет обновлять. А во-вторых, возможны ситуации (у нас такие были), когда добавление одного индекса начинает валить другие запросы, когда они радостно его видят, и начинают использовать. После этого план может стать таким, что запрос замедлиться в разы. То есть это нарушает принцип, что я вроде не менял в определенном месте, а все стало тормозить.
К сожалению, очень ограниченный тюнинг. Нам, в lsFusion, конечно проще, так как мы можем добавить MATERIALIZED на любом промежуточное вычисление, и гарантированно функционал не измениться. Но разработчики тоже часто этим злоупотребляют, что приводит к тем же проблема, что я и описал выше с индексами.
Ну тут решение простое. Просто использовать специализированную не совсем оперативную аналитическую базу, как Вы и написали выше. Только обычно для этого мы используем не копию основной, а именно СУБД заточенную под быстрые запросы (как правило, Druid). Скорость будет просто в десятки (если не сотни) раз выше. Но да, под нее отчеты пишутся отдельно. Просто когда поступает задача на отчетность, то сразу надо принимать решение к какой базе делать.
У нас просто немного другой опыт. Администраторы обычно либо сразу валят, что это не наша зона ответственности, а "криво" написана программа - идите к разработчикам. Но все равно, по умолчанию, проблема возвращается к тому разработчику, который делал задачу. А потом, если он не знает, как оптимизировать, то проблема уходит на более высокий уровень, то есть к разработчикам, которые лучше разбираются.
Но в любом случае, все вернется к разработчику. То есть в 95% процентах случаях проблема в кривом коде, а не настройках. Даже, если аудит выявит проблему, то все равно нужен разработчик, чтобы переделать код.
Более того, часто приходится и к бизнесу обращаться. То есть, например, бывает бизнес просит : а сделайте отчет, который за последние 5 лет по всем розничным чекам найдет какую-то корреляцию. Понятно, что чудес не будет, и тут есть essential complexity. Запрос будет сильно насиловать базу, но разработчик с этим мало что может сделать. Максимум, что он может сделать - это преподсчеты, или инкрементное обновление с увеличением времени транзакций. Но опять же, это надо согласовывать с бизнесом, так как оперативность данных может измениться.
Мы (как разработчики) просто тоже сталкивались с внешним аудитом, и, если честно, не уверен, что в этом была польза. Со стороны аудита, как правило, действительно находятся умные и разбирающиеся люди (как и с нашей стороны). Но они не знают глубоко специфики работы программы. Да, они тратят время и находят узкие места, о которых мы и сами знаем. Но, как правило, там нет простого решения (если бы оно было, мы бы сами его давно сделали). И любое изменение имеет свои минусы, на которые, например, бизнес не хочет идти (или что приведет к другим техническим проблемам).
Что, реально так говорит ? Это точно разработчик ? Даже, когда сделает что-то типа SELECT * FROM a FULL JOIN b ON ...? И у него будет на 100 записях работать, а на 50.000 не выполнится никогда ? Или просто for'ом начнет сотни тысяч запросов делать.
Мне кажется, что в таких случаях не аудит нужен. А разработчика просто менять...
Касса - это маленькая часть розницы. Да и в базовой кассе 1С тоже нету очень много чего. Например, сложной системы лояльности с накоплением бонусов и прочим. А в lsFusion ERP есть из коробки.
Ага, только вручную надо управлять логикой клиент-сервер, блокировками, писать псевдо-SQL и т.д.
А если еще посмотреть "оптимизированный" код в базовых версиях, который на времянках построен, то называть "легко" дорабатывать этот спагетти-код язык не поворачивается.
Ну конечно. Я вижу, Вы не особо имеете представление, какие задачи есть в крупной рознице (начиная от всяких акций, ассортиментных матриц, допвыкладкой, планограммами и таких там еще десятки). Именно эти коробки в базовой версии ну никак не подходят для крупной розницы. Ровно по той же самой причине, почему и lsFusion ERP не подходит для производственных предприятий.
Бухгалтерия - это одна маленькая задача относительно всей автоматизации предприятия. Там можно обойтись вообще без доработок и использовать ее для решения проблемы "бешеного принтера". Программистов под нее можно не держать, а пользоваться коробкой или аутсорсом.
Потому что важен не учет, а управление. А вот управление не стандартизировано. Там каждый бизнес хочет чего-то своего, и доработка на 1С - это большая головная боль из-за некачественной платформы.
А Вы не в курсе, что часто у 1С бывает отдельно стоят 1С : БУХ, 1С : УТ и 1С : Розница. Это не зоопарк ? Почему 1С не может все сделать в одной системе ? Вот, например, у меня крупная розничная сеть. Можете мне предложить готовое решение, где будет и бухгалтерия, и ассортиментные матрицы, и печать ценников, и кассы и все это в одной конфигурации ?
Потребность там глобальная - автоматизировать бизнес-процессы компании розничной торговли. Да, только в статье по функционалу описаны, как именно автоматизируются конкретные процессы. Но дело в том, что такие процессы достаточно узкоспециализированы и интересны лишь небольшому кругу читалей, поэтому пока таких статей не делали. Но возможно в будущем сделаем.
Другие же статьи описывают более общие схемы (такие как подбор товаров в любых документах или логика изменения параметров). И это касается уже значительно большего числа процессов.
Из 1С обычно идет миграция или через Excel файлы, или через Enterprise Data. Чаще всего именно из 1С мигрируем. Но в принципе, там не так важно, что за система с той стороны. Важен принцип и процесс перехода (а как именно делать импорт - это больше технический вопрос).
Так писали же. Только не относительно одного внедрения, а многих.
Вот как настраивается и работает сервер приложений. Тут про СУБД. Как дорабатываем. Как мигрируем со старых систем. Как работают интерфейсы (динамические списки, логика ввода всяких прайсов и прочего, подбор в документах). Как оптимизируем. Вот какие проблемы бывают с пользователями. Как ищем разработчиков. И, собственно, вот статья по функционалу решения, которое внедряется в эти компании.
Или нужна статья в стиле "Все топ-менеджеры были счастливы, продажи увеличились на X%, а расходы сократились на Y%" ?
Всегда то, что появилось раньше - используют больше. По такой логике SAP в разы лучше, так как на нем работают гораздо больше. А на практике бывает, как правило, наоборот. То, что более свежее, не обладает тем техническим долгом, который есть у устаревших продуктов.
И что именно Вы бы хотели увидеть ? Вот демка - это основа, на которой работают розничные сети (хотя понятно, что каждая сеть уникальна, и много чего доделывается под конкретные процессы). И в целом, в блоге lsFusion много описано подробностей того, как это все дорабатывается и внедряется.
Вы считаете, что это все бутафория, и на самом деле клиенты вымышленные ? Что касается надежности, то есть много клиентов, у которых кассы (не FMCG) работают в онлайне с основным сервером (как обычные пользователи). То есть любое падение сервера - это остановка магазинов. Так что выводы по надежности платформы можете сделать сами.