1С VS MS Dynamics Ax. Чим "Ми" гірше?

1. Навіщо їх порівнювати? Розділ можна сміливо припустити, якщо цього питання не виникає. Чому, на...
2. функціонал
3. адміністрування
4. Висновок

Навіщо їх порівнювати?

Розділ можна сміливо припустити, якщо цього питання не виникає. Чому, на мій погляд, є важливим порівняння 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С інші пріоритети - "мобільна платформа", "красиві кнопочки" (це я про таксі) і т.п. Ну, може, це і правильно. Далі буде видно.