Зачем их сравнивать?
Раздел можно смело пропустить, если этого вопроса не возникает. Почему, на мой взгляд, является важным сравнение 1C с другими (западными) ERP системами/платформами? Очень большая проблема даже для опытных разработчиков – внедренцев заключается в том, что очень хорошо изучается функционал типовых решений, и часто люди не видят альтернативы. То, что 1С не делает/не предлагает априори невозможно, либо неправильно. У западных систем есть чему поучиться, и не только разработчикам платформы. Многие функциональные особенности доступны и “простому смертному” для использования в своих прикладных решениях. Конечно, подобные “изыскания” полезны только для людей, которые хорошо знают типовые решения 1С. Потому как внедрение какого-то нового подхода требует глубокого понимания его целесообразности и преимуществ над существующим.
В каждом разделе старался выделять курсивом основную мысль, которую, на мой взгляд, можно почерпнуть из сравнения данного функционала. Что можно взять в 1С на вооружение.
Конечно нельзя не упомянуть, что на Инфостарте уже есть публикация на данную тематику: //infostart.ru/public/101933/ . Внимательно перечитал перед тем, как писать. Конечно, ничего общего с ней не получилось:
- Публикация 2008 года, все несколько поменялось. Сейчас уже и 1С 8.2, и Dynamics Nav 2009
- Сравниваем не с Dynamics Nav, а c Dynamics Ax. Кстати, в 2008 году назывались ещё Navision и Axapta, наверное. Axapta всё-таки флагман, ориентированный на средний и крупный бизнес, нужно же равняться на лучших
- Сравниваем не только с позиции разработчика, но и с позиции пользователя и администратора. Потому как 1С это платформа, то прикладное решение возьмём УПП 1.3 (очень бы хотелось ERP 2.0, конечно, но рановато…. как и DAX 2012).
Разработка
Объекты метаданных:
Основа основ, конечно, - дерево объектов метаданных. В Dynamics Ax оно называется репозитарием прикладных объектов
Сам принцип очень похож – метаданные, объекты у которых есть свойства и т.п. Есть даже много совпадений: Reports (отчеты), Jobs (обработки + фоновые задания), Forms (формы), Enums (перечисления), WorkFlow (бизнес-процессы).
Но корень всех различий кроется в Data Dictionary. В Dynamics Ax табличная структура таблиц выделена отдельно. На мой взгляд, это правильно, и обязательно должно учитываться при проектировании прикладных решений. Это отражает классический подход: “сначала подумать о том, какие данные, где, как и для чего мы храним, а уже затем какая логика должна для них присутствовать”. При проектировании нужно отличать объекты вида “регистр, справочник, документ” от объектов “отчет, обработка”.
Редактор кода:
Вопреки ожиданиям до 1С с “прикрученным” к ней снегопатом аксапте далеко. Нет ни продвинутого IntellySence, ни даже простых подсказок. Ctrl+Пробел, конечно, работает, только кого этим удивишь. Но в аксапте с кодом работать проще по другим причинам. Как видно из рисунка, методы объектов присутствуют в самом дереве объектов. Это очень удобно. Кроме того, есть отдельная сущность - классы. О них далее. Кто знаком с ООП, уже сейчас могут позавидовать. Наличие классов вообще позволяет не писать кучу кода в методах объекта. Да, ещё для аксапты тоже есть свой “снегопат”: http://www.axassist.com/
Да, и тут нужно, наверное, сказать про ещё одну особенность – в аксапте нет отдельного приложения для разработки. Имея соответствующие права (и лицензии, кстати) вы можете открыть AOT и исправлять, что заблагорассудится
Контроль версий, поставка и поддержка:
В аксапте есть очень хороший и интересный механизм слоёв. О нём стоит упомянуть. В 1С хоть и есть намёки, но полноценной реализации данного механизма не хватает. Суть в том, что код изначального прикладного решения вы никогда не затираете – вы его “перекрываете”, внося модификации на более высоком слое. Притом перекрываете отдельные методы или отдельный объект. Слоёв, конечно, и не 2, и не 3. Есть системный, который правит только Microsoft, есть специальный слой для решений партнёров (да здравствуют отраслевые), есть слой уже для собственных модификаций – пользовательский. Они обновляются и используются независимо. Естественно, есть возможность сравнивать. В 1С этого, конечно, жутко не хватает, но некоторый намёк на то, как нужно организовывать обновления, можно почерпнуть… конфигурация, которая обновлена без ваших модификаций, у вас всегда должна быть, как и конфигурация до обновления с вашими модификациями. т.е. каждое обновление должно содержать минимум 3 конфигурации. А если отраслевое решение, то хорошо бы и все четыре. Одну из них, конечно, перекрывает “конфигурация поставщика”, но, как показывает практика, лучше сохранить обычным способом.
Система слоёв очень удобна. Внесённые вами изменения можно так же “лёгким движением руки” откатить. Но при этом на полноценную систему контроля версий явно не тянет. А полноценной системы контроля версий в Dynamics Ax нет.
Есть некоторые средства взаимодействия со сторонними системами контроля версий:
В частности, естественно, присутствует интеграция с Visual SoureSafe и Team Foundation Server (ожидаемо, конечно). Но никаких визуальных эффектов при этом и ещё чего-либо вы не заметите. Весь контроль версий осуществляется по сути “в ручном режиме” посредством вызова определенных команд. Главный плюс в данном случае - что на систему контроля версий вы можете повлиять непосредственно из кода Axapta, т.е. как в 1С оно не “зашито в платформу”. Да и сами объекты Dynamics Ax представляют из себя текстовые файлы, хранящиеся в определенном каталоге, т.е. организовать для них систему контроля версий можно и в ручном режиме. Если бы хранилище в 1С работало хотя бы вполовину так же быстро и вызывало только в половину больше проблем, чем Visual SourceSafe, то встроенную и полностью интегрированную систему контроля версий можно было бы считать большим преимуществом 1С.
Структура данных
В Dynamics Ax решили не уходить далеко от сущностей СУБД, таким образом, данные хранятся только в объекте одного типа – “таблица”. С одной стороны, это плохо. Начинающему разработчику трудно разобраться, какие таблицы для чего создавать. В 1С всё просто. Документ – фиксация факта, справочник – набор записей для выбора в реквизиты документа, Регистр – сущность, в которую документ записывает свои данные при “проведении”. Но, с другой стороны, опытный разработчик уже понимает, что не всё и не всегда так просто. А если вы, к примеру, хотите на 1С сделать систему учета обращений? Инцидент - это документ или справочник? Или запись регистра сведений? А переписка по нему – справочник или регистр? Да даже в типовых есть “странные” документы вроде ”регламентных операций”, “расчета себестоимости”, “корректировки регистра”, в конце концов. Странные “справочники” вроде ключей аналитик или серий номенклатуры. Для более сложных учетных задач такое методическое разбиение сущностей уже не слишком подходит. Разработчик с некоторым опытом за плечами должен задумываться скорее не о том, на что данная операция похожа по виду: на “Документ” или на “Справочник”, а скорее, какая структура данных ему нужна для хранения информации. А в итоге структура хранения – это всегда таблицы (по крайней мере, в большинстве современных систем. Не берём эксклюзив вроде NoSQL или Объектных СУБД). В 1С таблицы делятся уже заранее на определенные классы, имеющие фиксированные индексы, реквизиты, свойства и методы. В Dynamics Ax у разработчика в этом отношении полный простор фантазии. Но удобство разработки от этого совсем не страдает. Вспоминаем, что в Dynamics Ax есть поддержка ООП. Собственно, это во многом “развязывает руки” в части повторного использования кода.
Конечно всё не так гладко, как можно подумать на первый взгляд. Наследовать таблицу от таблицы нельзя (НО в Dynamis Ax 2012 уже можно, по крайней мере, по описанию новшеств. В данном случае пишу “нельзя”, потому как в статье рассматриваем наиболее популярную на момент её написания версию – DAX 2009)
Каждое поле таблицы имеет в DAX достаточно много свойств:
Очень заметно свойство “ExtendedDataType”, в котором определяется ещё часть свойств для данного элемента. Сразу бросаются в глаза свойства “Visible” и “AllowEdit”. В DAX это свойства таблицы, а не экранной формы, хотя, конечно, программно повлиять и заполнить можно всё что угодно. Несмотря на то, что с появлением управляемых форм ситуация в корне изменилась, 1С всё-таки ещё есть куда расти в плане декларативного пользовательского интерфейса.
Конечно же, стоит упомянуть, что в отличие от 1С Microsoft совсем не стесняются давать возможность разработчикам создавать индексы на таблицы БД:
Получение остатков
А как же обойтись без регистров? Ведь остатки получаются по регистрам накопления. Там же специальная структура итогов создаётся. А как без них? Проще, наверное, показать на примере:
Открываем в DAX форму “в наличии” для товара и смотрим, какой для неё запрос выполняется:
Как видно из рисунка, всё предельно просто и лаконично: есть индекс и поле “Closed” в индексе. Поле Closed включается в индексы и означает, что товаров (по данному заказу, на данном складе) нет ни в наличии, ни в резерве, если Closed = “Да”, то записи нет на остатках – т.е. она “исчезла из итоговой таблицы”. Естественно, на уровне MsSQL поле Closed не булево, а очень даже int. С учётом того, что при росте базы, скорее всего, строки, которые есть на остатках (не закрыты), будут составлять малую часть всей таблицы, то индекс будет иметь очень хорошую селективность.
Можно долго рассуждать о плюсах и минусах такого подхода, но для того, чтобы сделать реальные выводы, нужно, конечно, проанализировать эксплуатацию в высоконагруженной среде. Как 1С себя ведёт в этом случае, мы все более-менее знаем, а вот про аксапту ничего не могу сказать. Было бы интересно сделать подобное решение по хранению остатков в 1С, на регистрах сведений, но пока руки не доходят. Да и регистры сведений в 1С уже приобрели кластерный индекс по всем измерениям, который делает их не лучшим образом подходящими для решения подобной задачи.
ООП и БСП
Для тех кто не в теме: ООП – это про аксапту, БСП – это про 1С. Появление БСП очень порадовало разработчиков прикладных решений. Функционал, который характерен для всех прикладных решений 1С, собран, переработан и приведён к формату “библиотеки”. Если вы разрабатывали не только на 1С, то такой подход не новость – вспомним Библиотеку VCL в Borland C++, Библиотеку STL в C++, MFC в Visual C++, в конце концов, сборки C#. Это всё имеет схожее назначение. С одной только разницей - С++ (как и X++ в DAX) язык программирования, поддерживающий ООП. Следовательно, библиотеками вы пользовались просто: создавали свои классы – наследники от базовых классов, определенных в библиотеке, и перекрывали нужные методы, добавляли свои… В 1С, по понятным причинам, такого не получится. Именно поэтому, когда вы хотите “Перекрыть” какой-либо метод БСП, вам нужно раза 3-4 “Нажать F12”, “докопаться до сути” и понять, где внести модификации. Меня, если честно, цепочки вызовов функций вида: МодульКонфигурации.КакаяТоФункция() –> МодульПодсистемыБСП.КакаяТоФункция() –> СтандартныеПодсистемы.КакаяТоФункция() –> СтандартныеПодсистемыПереопределяемый.КакаяТоФункция() жутко раздражают. Со временем, конечно, привыкаешь, но с “изящной простотой” ООП такому подходу не сравнится. Тем не менее, осознание, что такой функционал нужен, у 1С, видимо, уже есть. Наверное, при разработке и использовании БСП уже сформировалось и понимание, что поддержка ООП в языке 1С здесь бы очень не помешала.
А если бы ещё была поддержка “наследования таблиц”, как в DAX 2012, – вообще просто сказка. Представьте: при разработке нового прикладного решения создаёте документ “ОбщийДокумент”, прописываете в нём функционал, который необходим для остальных документов, а остальные просто наследуете от него и добавляете специфичный для вида документа функционал. Несмотря на отсутствие поддержки в 1С ООП, я думаю, стремиться к нему всё-таки нужно. Т.е. документ, в котором существует только базовый функционал, создать всё-таки нужно (назвав его при этом “шаблон”, к примеру), остальные документы копировать с него. С актуализацией, конечно, будет трудновато – но тут могут помочь общие модули (в которые нужно постараться переносить максимум функционала) и “библиотечный подход” при создании общих модулей“. Т.е. создать обычный модуль, стандартный модуль и модуль “переопределяемый”, в которые вставить одну и ту же функцию.
Удобство разработки
1) В DAX нормальная ситуация, когда у вас открыто 2 AOT, и между ними вы “перетаскиваете” объекты.
В 1С так можно работать только открыв 2 конфигуратора, подключенных к одному хранилищу. Но удобство такой работы в принципе вызывает сомнения.
2) В DAX все добавленные объекты можно разделить на “Проекты”
А ведь то же самое можно делать и в 1С. Просто мы редко об этом задумываемся. В 1С есть объект “Подсистема”, кроме назначения, которое он приобрёл в 8.2, осталось ещё назначение, которое было в 8.1. Для этого достаточно не ставить галку “Включать в командный интерфейс”. При этом все объекты, которые вы добавили или изменили, вы можете включить в эту подсистему, а в дереве метаданных применить “фильтр по подсистемам”. Но многие ли из интеграторов это делают?
3) Ну и, конечно же, в DAX для того, чтобы обновить базу, не нужно монопольного к ней доступа, без проблем обновляется как код, так и структура данных
Работа с запросами
А вот тут ничего хорошего не могу сказать про аксапту. Слева объект Query – ближайшее в DAX, что похоже на конструктор запроса 1С. Справа конструктор запроса – уже говорит о многом.
В DAX при этом вы не увидите текстов запросов SQL подобных. Вы в коде можете увидеть только что-то вида:
Есть в таких конструкциях и join, и sort, и group by, а вот с вложенными запросами и временными таблицами уже будет сложновато. Так что любителям простоты и лаконичности SQL остаются только прямые SQL запросы (они здесь разрешены, и названия таблиц в БД нормальные) и вспоминать молодость, т.к. писать их придётся руками.
Функционал
Общие интерфейсные механизмы
Прежде всего, открывая MS Dynamics Ax, пользователь видит, что это программный продукт Microsoft:
А видит он уже “стандарт” интерфейса:
- Боковую панель (как в Outlook)
- Рибон (как везде)
- Навигационную строку и кнопки навигации (как в эксплорере)
- Избранное
- Красивые картинки…
Только уже по этим критериям программный продукт Microsoft получает преимущества удобства интерфейса.
Ко всем элементам DAX может быть прикреплен файл:
Естественно, вся функциональность инфраструктуры файлов поддерживается (блокировать, загрузить, создать версию)…
С появлением БСП в 1С данная возможность тоже присутствует для многих объектов, но далеко не для всех. Стоит только вспомнить требование: для каждого объекта, к которому хотите прикреплять файлы, нужно создать отдельный справочник:
На мой взгляд, нет особых технологических ограничений 1С, чтобы исправить эту ситуацию
Также инфраструктура напоминаний поддерживается неким “общим” образом
Инструмент очень удобный. В 1С, по крайней мере в БСП, я видел только напоминания по дате, или системные.
Отчеты
За этот функционал, по моему мнению, разработчикам DAX должно быть стыдно. Вот так выглядят расширенные настройки отчета в DAX (слева) и в 1С (справа)
А вот так выглядят сами отчеты:
Притом то, что вы видите в DAX, - это “как есть”; эту форму даже в Excel сохранить нельзя. Ну а возможности табличного документа в 1С вы и сами знаете.
Конечно, в DAX не всё так плохо, разработчики не оставили пользователей системы “на произвол судьбы” с такими отчетами. Для того, чтобы получить “полноценный” отчет в DAX, нужно воспользоваться функционалом MS Analysis Services, т.е. сделать собственные OLAP кубы и использовать их в отчетах. В качестве клиента – MS Excel подходит, пожалуй, лучшим образом. Такие отчеты уже можно настраивать, они достаточно быстро работают даже на больших объёмах данных, и вполне удобны. Но данные в них уже попадают не online. чтобы построить отчет нужно заново обновить OLAP куб. Как правило, это делается раз в день. Так что оперативные отчеты таким образом получать очень не удобно.
Аудиторский след. Изменение “проведенных”
Изменять “проведенные” (“разнесенные” в терминологии DAX) записи уже нельзя. Информация о “разносках” попадает в “Аудиторский след” (сама таблица, кстати, называется Transaction Log, собственно, и назначение её примерно то же самое). В данной таблице в DAX отсутствуют методы удаления в принципе. Какими бы правами вы ни обладали, средствами DAX данные из этой таблицы удалить невозможно. Исправлять разнесенные уже записи тоже невозможно под любыми правами.
Зачем это делается? Очень просто – разработчики систем пытаются соблюсти требования “отсутствия ошибок” в транзакционных системах. Одной из этих ошибок является “неповторяемое чтение”, т.е. если вы сегодня в 12 часов дня посмотрели остатки по кассе, то и завтра, посмотрев остатки на 12 часов вчерашнего дня, вы должны увидеть ту же самую сумму.
Собственно, в этом основная проблема использования Dynamics Ax бухгалтерами. Слишком уже привыкли, что свои ошибки всегда можно исправить. На самом деле в Dynamics Ax с исправлением ошибок тоже нет никаких проблем, просто там сначала нужно сторнировать записи (что особых проблем не вызывает), а потом ввести их заново.
Конечно, совсем отказаться от изменения проведенных документов, наверное, было бы неправильно. Но в прикладных решениях 1С, всё-таки, возможно, имеет смысл выделять права “интерактивное изменение проведенных” в отдельный профиль, и включать в него далеко не все группы. Так же, наверное, не всегда правильным действием является кнопка по умолчанию “провести и закрыть”, проведение всё-таки для некоторых документов желательно организовывать отдельным действием. Ещё хорошим решением была бы операция “Сторно”, которую можно было бы лёгким движением выполнить для любого документа (ввод на основании, или даже просто команда). Таким образом можно “подтолкнуть” бухгалтеров к работе в системе текущим числом, при этом оставив возможность работы задним числом, “чтобы не было ломки”.
Настройки форм
Как то уже очень похожи настройки форм в Dynamics Ax и в 1C 8.2:
Невооруженным взглядом видно “наследование опыта”. Жаль, что ещё “сохранение настроек форм” и “загрузку настроек форм” 1С пока не так удобно и просто сделали. Но есть надежда, что вскоре исправятся.
Web доступ
В Dynamics Ax Web доступ осуществляется посредством интеграции с SharePoint (что не удивительно). Но для Web доступа к функционалу нужно разрабатывать отдельные формы, которые ориентированы именно на работу через Web интерфейс.
Конечно, здесь “1С ушла далеко вперёд”, но вот только в модулях форм Dynamics Ax нет никаких инструкций &НаКлиенте и &НаСервере. А кода в самих формах очень мало.
Бухгалтерский учет
К сожалению, картинки из реальной жизни бухгалтерского баланса в Dynamics AX не могу показать – ни разу не видел, чтобы его формировали из Dynamics Ax. Также не нашел их в тестовых и даже не тестовых системах. В обновлениях они вроде присутствуют – выпускаются патчи для DAX под обновление Российского законодательства. К сожалению, эти обновления выходят гораздо реже, чем хотелось бы. Как пишут на своих форумах сами разработчики Dynamics Ax, бухгалтерский учет по РСБУ всё-таки удобнее вести в 1С. По крайней мере, налоговую отчетность сдавать точно.
В DAX принята система учета, когда любая хозяйственная операция должна проходить через счета БУ. В отличие от 1С, где часть аналитик и информации мы можем держать в регистрах накопления или даже регистрах сведений, в DAX вся информация по максимуму должна проходить через счета ГК. Но структура хранения информации по “проводкам” достаточно оптимальна, поэтому такой процедуры, как “отложенное проведение”, в DAX, как правило, не используется. Зато есть понятие “системные счета”, на которые может попадать “всякий хлам”.
Да, ещё одна важная деталь – в DAX нет иерархических представлений. (по крайней мере, мне найти не удалось). А это делает работу с планом счетов очень проблемным занятием. Да и вообще удобство пользователей существенно страдает. Это, конечно, снижает нагрузку на SQL Server, но мне лично хотелось бы видеть иерархию в интерфейсе. Слишком уж привычно и удобно.
С печатными формами большие проблемы. Реглаентированных печатных форм я даже в русской локализации не видел. Без доработок из DAX даже платежку не распечатать.
Закрытие периода в DAX – это такой процесс, за который человек в одиночку и в здравом рассудке не возьмётся – по сути всё закрытие счетов – ручное. Это, конечно, обеспечивает некоторую гибкость и отвязывает от национальных стандартов бухгалтерского учета, но для БУ зачем оно нужно? Видел, что есть в локализации вроде даже функционал для формирования регламентированной отчетности, он чем-то напоминает тот, что сделан в 1С:Консолидации – нужно “руками” прописывать все значения в ячейках табличного документа.
А “штатный баланс” выглядит примерно так:
Из положительного стоит отметить “профили разноски”. DAX позволяет достаточно гибко настраивать подбор счетов и проведение в различных случаях.
Управленческий и международный учет
Сразу стоит отметить, что система не ориентирована на ведение “двойного”, “тройного”, “цветного” учета. План счетов в системе один.
Но у счета в DAX куда больше свойств и настроек, чем в 1С:
В DAX, если необходимо разделить бухгалтерский и управленческий учет, или, к примеру, МСФО – вы будете использовать тот же самый план счетов, просто определенные признаки заполнять по-другому и другие коды назначать.
Удобно это или нет – спорный вопрос. Лично мне, конечно, два-три плана счетов нравятся гораздо больше, но это субъективно, возможно, в силу привычки.
А вот то, что количество реквизитов счета можно бы расширить, – это вполне хорошая идея. Сейчас в 1С информация, которая относится непосредственно к счету, разрознена. Можно бы её и дополнить, вплоть до формата вывода в отчеты.
Расчет себестоимости. Учет затрат
Тут всё просто – FIFO, LIFO, по средней... Конечно, ожидали увидеть “вездесущий” в 1С РАУЗ, но я лично подобного подхода не встретил, ни решения СЛУ, ни корреспонденции аналитик.
В DAX FIFO отличается от понятия, принятого в 1С:
1) При определении прихода, по которому нужно начислить себестоимость, может не определяться точная партия, а происходит сопоставление прихода с расходом по определенному набору аналитик.
2) Набор аналитик, по которым происходит сопоставление, можно выбрать.
3) Хронологический порядок в данном случае совсем не обязателен.
Но, возможно с учетом всего вышесказанного про аудиторский след не так это всё и плохо. Можно и FIFO при этом использовать.
Но очень хорошо, что логика расчета себестоимости динамически настраивается набором аналитик, это особенно приятно.
Производство
Здесь, конечно, УПП ещё далеко до Dynamics Ax. К примеру, в аксапте есть информация по всем этапам производства, можно запланировать потребность во времени, материалах, иных ресурсах на каждый этап, даже посчитать предполагаемую себестоимость товара и дату завершения изготовления партии. Вот, к примеру, маршрут изделия в производстве.
В целом блок производства выглядит в DAX гораздо более “продвинутым”, чем в УПП.
Прочие функциональные возможности
1) В DAX намного увереннее выглядит блок закупок. Заказы на закупку проходят целую цепочку (обработанные, отправленные, подтверждённые) в общем, всё на рисунке:
Стоит, правда, отметить, что в УТ11 (особенно с появлением статусов и оплат) функционал стал приближаться к реализованному в DAX, но в УПП такого функционала пока что нет
2) То же самое можно сказать и про CRM.
3) В DAX есть целый блок по управлению проектами. В УПП Проект хоть и практически сквозная аналитика, но дополнительный функционал по ним отсутствует. В DAX у проектов есть (что, конечно же, логично) интеграция с MS Project Server.
4) В DAX склад уже полноценный – с адресным хранением. Хотя для полноценного адресного склада и WMS этого маловато, тем не менее, организовать учет позволяет, но, конечно, без “хитрых” алгоритмов размещения и выделения ячейки.
Администрирование
Как продукт Microsoft, аксапта приятнее в администрировании уже привычностью подходов и интерфейсов.
Интеграция с инфраструктурой
Конечно, организована интеграция с AD, и пользователи, как правило, добавляются в систему импортом из AD. Даже структура компании берётся из AD в идеале.
Собственно, никто не мешает аналогичную функциональность реализовать и в 1С – для этого существует интерфейс WMI, который позволяет получать из AD практически любую информацию. Собственно, об этом уже написано //infostart.ru/public/165702/
Разделение данных
Вся работа пользователя ведётся в рамках одной “компании”, стоит отметить, что данная функциональность больше напоминает разделение данных в 1С, чем RLS.
С этим подходом в DAX полностью согласен – тоже считаю, что “Организация” скорее должна выступать разделителем, чем реквизитом документов, по которому накладывается RLS. Это и работает быстрее, да и правильнее. Мы просто уже привыкли к частой практике, когда для одной компании открывается несколько юр. лиц, с различными целями. В этом случае, мне кажется, нужно либо отделять управленческий учет от бухгалтерского, либо переключаться между этими юридическими лицами как между компаниями, в случае, если они относительно независимы.
Такое разделение также более “надёжно”, чем RLS по организациям, и уже не получится, как в 1С, где бухгалтеры, которые в своё время “насмотрелись” на проблемы с RLS, требуют сделать себе отдельные базы под каждую организацию. Системному администратору (или администратору СУБД) это, соответственно, дополнительная нагрузка.
Кластеризация
Сервер DAX кластеризуется, весьма устойчив. Центрального кластера нет. Подсистему балансировки нагрузки и сервер пакетной обработки можно распределять по разным серверам:
СУБД поддерживает всего две: MS SQL Server и Oracle Database.
Из практики могу сказать положительные слова о надежности. На сервер 1С нужно достаточно регулярно смотреть, хотя бы на предмет использования памяти и “подвисания” рабочих процессов.
Если в 1С по практике могу сказать что для лучшей стабильности, если мощность сервера и количество пользователей позволяют держать только один сервер 1С, то он должен быть один. В DAX, судя по сообщениям (вернее из отсутствию) на форумах и личному опыту, этого можно не бояться.
Блокировки.
Режим блокировок в DAX можно настраивать:
Собственно, режим говорит о том, блокировать ли данные, которые читаются для последующего изменения, или не блокировать. Для чего это делается, я уже писал в статье //infostart.ru/public/91880/ . Собственно, со мной там не все согласились – есть популярное мнение, что “блокировать нужно всё и всегда”. Но разработчики DAX, видимо, с этим мнением тоже не согласны. Блокировки должны быть осмысленными и только там, где этого требует бизнес-логика приложения.
Также очень интересно, что при работе с MS SQL Server DAX использует уровень изоляции Read Commited Snapshot, о котором я тоже писал: //infostart.ru/public/91879/ , его же вроде как и использует уже 1С 8.3.
Права доступа
В целом подход очень похож на тот, что используется в БСП – создаются группы, к ним привязываются права доступа, группы назначаются пользователям.
Самих прав в DAX существенно меньше. По сути их 3, при этом для всех объектов одинаковые. Ну разве что для некоторых (для отчетов, к примеру) правка и создание недоступны (что логично).
Разграничение прав доступа на уровне записей тоже существует. Но в DAX это отдельная таблица, в которую вносятся все эти ограничения. Для ввода ограничений предусмотрен удобный конструктор.
Хранение конфигурации
В DAX, как в 1С, нет единого файла конфигурации, который хранится в СУБД. Соотвтетственно нет и кэша метаданных, и вечных проблем с ним. Все модули хранятся на специально выделенном файловом ресурсе (для него должно быть организовано резервное копирование, и доступ серверов в Ax к нему должен быть быстрый). Также модули хранятся отдельно – в привязке к объектам, для которых они созданы. Т.е. “разрушение” сразу всей конфигурации, как в 1С, крайне маловероятно. Такая структура хранения мне лично более напоминает триггеры в MS SQL, не знаю всех нюансов, но, на мой взгляд, она более предпочтительна, чем один большой и неповоротливый файл конфигурации, который нужно постоянно читать с сервера и записывать на сервер, кэшировать, записывать частями (динамические обновления), потом считывать по частям и собирать (работа после динамического обновления).
Заключение
Итак, несмотря на достаточно существенный разрыв в технологиях, в архитектуре, разработке, стабильности, который 1С пока не удаётся сократить, функционал в 1С существенно проигрывает, пожалуй, только в блоке производства. А в некоторых вопросах (БУ, Отчетность) 1С явно “лицом к пользователю” в отличие от DAX. Вопросы аудиторского следа, изменения проведённых и т.п. можно долго обсуждать и спорить.
Чего 1С точно не хватает, так это стабильности работы и ООП для разработчиков. Если уже без ООП смогли создать почти не уступающее по функционалу решение (УПП), то при наличии такового, я думаю, “догнать по функционалу” Ax было бы вопросом нескольких лет, а за это время можно было бы и над стабильностью поработать. Но пока у 1С другие приоритеты – “мобильная платформа”, “красивые кнопочки” (это я про такси) и т.п. Ну, может, это и правильно. Дальше будет видно.