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

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

Я всегда считал идеалом 1С. Но на форумах ее конкурентов я встречал сообщения, что программист может перейти с 1С на Navision/Axapta, но никогда не перейдет наоборот. И вообще конкуренты всячески восхваляли свои продукты, принижая 1С.

Все это пробуждало во мне здоровое любопытство – вдруг я действительно занимаюсь не тем, что нужно, вдруг Navision/Axapta действительно лучше 1С.

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

Может бросить все, забыть 1С и начать с чистого листа и минимальной зарплаты в Navision/Axapta?

И вот в ноябре 2006 года я воспользовался случайно подвернувшимся предложением фирмы Microsoft, и посетил бесплатные курсы по программированию в Navision (в общей сложности 80 часов) в учебном центре R-Style:

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

В процессе учебы я сравнивал с точки зрения программиста Navision с 1С и понял, что не хочу заниматься Navision. Это не значит, что 1С во всем лучше, чем Navision, просто для программиста переход на Navision после 1С похож на переход от C++ к ассемблеру. Кстати, со мной вместе училась девушка, профессионалка в 1С, и ей тоже Navision не понравился.

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

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

О чем эта статья?

В этой статье сравниваются в основном внутреннее устройство (движок) систем 1С 80 и Navision.

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

Для развития кругозора немного сравнивается функционал, характеристики, цены и принципы построения систем.

Иногда в сравнении участвует Axapta – система, имеющая много общего с Navision, и Access – программа для работы с базами данных, входящая в состав MS Office.

В сравнении иногда упоминаются дополнительные возможности 1С 81 – версии, релиз которой выходит в конце 2006 года. Также упоминается версия 1С 77, которая использовалась до выхода 1С 80.

Благодарности

Хочу поблагодарить программистов 1С (www.forum.mista.ru/index.php?section=dynamics), помогавших мне в данном сравнении.

К сожалению, программисты Navision/Axapta (www.mazzy.ru) негативно отнеслись к моей попытке сравнения и отключили меня от всех посещаемых форумов в Рунете по Navision/Axapta. Считаю такую «религиозную» нетерпимость неприемлемой для конструктивного развития, считаю, что любой человек может задать любой технический вопрос по Navision.

Поэтому некоторые вопросы остались, к сожалению, не до конца уточненными.

Термины

От Navision я ожидал увидеть чего-то необычного, но оказалось, что у Navision и 1С много общего.

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

Платформа (в Navision – Executable, Application) – это собственно двоичный код или движок, который обеспечивает работу системы.

Естественно, платформа развивается и со временем у нее появляются новые версии (глобальные изменения) и релизы (текущие изменения).

Мы изучали Navision 4.0, который я буду сравнивать с 1С 80 и иногда с выходящей в конце 2006 года 1С 81 (в которой добавлено много нового). Иногда я буду производить сравнения с версией 1С 77 – предшественницей платформы 1С 80.

База данных – какой формат базы данных использует платформа для хранения данных. Обычно используется или свой движок, или движок какой-нибудь промышленной СУБД (например, MS SQL Server).

Тип прикладного объекта – объект, поддерживаемый платформой, от которого можно наследовать прикладной объект. В нем заключена полезная функциональность, разработчик может разрабатывать объекты, наследующие поведения прикладного объекта. Примеры: таблица, документ, отчет, библиотека функций.

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

Прикладной объект данных - прикладной объект для хранения данных.

Экземпляр прикладного объекта – конкретный экземпляр прикладного объекта.

Встроенный объект – объект, встроенный в систему, используется как есть, без наследования от него другими объектами. Примеры: объект для работы с файлами, dbf-таблицами, системными переменными Windows и т.п.

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

Настройка конфигурации – процесс ввода/удаления/редактирования прикладных объектов.

Конфигуратор – программа или часть программы для настройки конфигурации. В Navision – Object Designer.

Отчет – прикладной объект для вывода отчетов

Форма – прикладной объект, элемент интерфейса для ввода и отображения данных в диалоге с пользователем.

Метаданные – данные о данных. Т.е. дополнительная информация о прикладных объектах, хранящаяся в конфигурации. Обычно программист может получить программный доступ к составу конфигурации и метаданным.

Функционал – совокупность функций, которые реализованы в конфигурации.

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

Программист – человек, который знает, как программировать и настраивать конфигурацию системы. В функционале он ориентируется значительно меньше, чем консультант.

Также приведем расшифровку аббревиатур:

C/Front - библиотека функций на языке Си для доступа к базе данных Navision.

УРБД – управление распределенными базами данными. Реализованная на уровне движка 1С система обмена данными между распределенными базами 1С.

Конфигуратор

Конфигуратор Navision внешне напоминает конфигуратор Access (прикладные объекты выводятся списком):

Конфигуратор Navision:

Конфигуратор Access:

Конфигуратор 1С имеет несколько другую структуру (прикладные объекты выводятся в виде дерева):

Конфигуратор 1С:

Списки прикладных объектов

Когда объектов становится очень много, иерархический вид просмотра становится менее удобным, чем просмотр в виде списков.

Однако в 1С каждый объект можно отнести к одной или нескольким подсистемам (категории) и фильтровать по подсистемам.

В Navision приходится всегда иметь дело с большим списком объектов, который к тому же почему-то нельзя отсортировать в произвольном порядке (например, по идентификаторам).

Копирование прикладных объектов через буфер обмена сделано лучше в Navision – в 1С можно скопировать только один прикладной объект, в Navision – несколько.

Общие особенности интерфейса

Встречают, как известно, по одежке.

Интерфейс конфигуратора Navision выглядит хуже, чем интерфейс 1С:

Symbol Menu, основное средство для ускорения ввода кода в Navision, периодически срабатывает неправильно.

Окошко свойств (используется чаще всего в Navision) иногда можно вызвать по правой кнопке мышки, а иногда нельзя – только по shift+F4.
Большинство списков имеют огромный размер и в них нельзя выполнять отбор или сортировку – например выбор типа реквизита. Приходится запоминать номера, чтобы вводить их, экономя время выбора из списка.
В Navision нет панели открытых окон - только классический список окон в пункте меню Window. В 1С каждому открытому окну соответствует иконка на панели окон. Очень удобно, когда окон открывается очень много.
Нельзя закрепить окна (Docking).

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

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

К тому же, планируется, что все средства разработки Dynamics (Navision/Axapta в том числе) будут переведены на Visual Studio. А значит, интерфейс разработчика изменится в лучшую сторону.

Редактор кода

Вот так выглядит редактор кода в 1С:

А вот так выглядит редактор кода в Navision:

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

Вот список недостатков редактора Navision по сравнению с редактором 1С:

Отсутствует цветовая разметка синтаксиса.
Не работает кнопка табуляции
Отсутствует автодополнение – когда программист вводит первые буквы идентификатора и нажимает кнопку автодополнения, редактор 1С показывает список доступных в данном контексте идентификаторов, начинающихся с этих букв
Нет автоматического форматирования текста по синтаксису языка (1С умеет форматировать выделенный блок кода по синтаксису языка)
Нет возможности кнопками комментировать/снимать комментарии для блока кода. В принципе, Navision это можно простить, т.к. возможны многострочные вложенные комментарии.
Контекстная справка по функции – в 1С можно выделить название функции и по нему получить сразу же справку, в Navision приходится копировать имя функции в буфер обмена и уже там смотреть
Отсутствует быстрый переход к месту определения функции, на которой стоит курсор.
Отсутствует список функций модуля – в 1С есть окошко, где можно выбрать функцию и быстро перейти к ней.
Нет шаблонов, т.е. кратких фрагментов кода, которые при вводе автоматически заменяются другим кодом. В 1С шаблоны могут быть настроены персонально программистом под свои привычки.
Выдается только одна синтаксическая ошибка, в 1С выдаются все такие ошибки.
Редактор Navision воспринимает весь текст как набор записей, т.е. как таблицу базы данных, отсюда и невозможность работы с кнопкой Tab и многие другие странности редактора.

В Navision у каждой функции есть список ее переменных/параметров, в который можно добавлять новые элементы с помощью мышки. Было бы удобно, если бы эти переменные/параметры показывались также и в тексте программы. Из-за такой схемы весь блок кода нельзя быстро скопировать одним куском в другой текстовый редактор, там отредактировать, а затем вставить обратно.

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

Редактор форм

Редактор форм Navision тоже отстает от 1С:

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

Копирование элементов через буфер обмена работает нормально в обеих системах.

Выгрузка/загрузка и модификация конфигурации

К сожалению нигде пока не реализована возможность из встроенного языка изменять конфигурацию – добавлять/изменять/удалять прикладные объекты.

В 1С 80 это вообще невозможно, т.к. структура конфигурации закрыта, в Navision возможно через C/Front.

Поэтому для программной обработки конфигурации чаще всего используется выгрузка/загрузка объектов, где преимущества у Navision:

В Navision прикладной объект выгружается целиком (даже у формы выгружается описание всех ее элементов управления), в 1С выгружается только программный код объекта.
В Navision можно выгрузить/загрузить любой прикладной объект конфигурации.
Соответственно в Navision можно загрузить несколько выгруженных объектов. В 1С можно загрузить только программный код этих объектов.
Все объекты Navision, даже формы, выгружаются в легко поддающийся анализу txt файл (хотя все-таки в идеале логичнее было бы использовать XML).
Если необходимо передать прикладные объекты 1С в другую конфигурацию, они выгружаются в виде файла конфигурации, содержащего описание всех прикладных объектов конфигурации. Далее, можно из этого файла загрузить нужные прикладные объекты в другую конфигурацию. Процесс выгрузки всей конфигурации и сравнения объектов для загрузки занимает очень большое время, особенно для больших конфигураций.
В Navision сопоставление объектов идет по номерам прикладных объектов. Номера доступны программисту для просмотра и изменения.
В 1С сопоставление объектов идет по идентификаторам прикладных объектов. Идентификаторы доступны программисту для просмотра и изменения. Однако в некоторых оговоренных случая сравнение идет по внутренним номерам прикладных объектов, которые никак не доступны программисту.
1С 80 позволяет в конфигураторе просматривать прикладные объекты в выгруженных файлах именно в виде прикладных объектов, а не в формате файле выгрузки. Navision такое не позволяет.

Отладчик

В обеих системах есть:

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

Есть и нюансы:

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

Мастера

В Navision есть мастера для построения форм и отчетов – очень простые, аналогичные таким же мастерам в Access.

В 1С есть мастера:

Конструктор форм.
Конструктор запросов на языке SQL
Конструктор отчетов
Конструктор практически всех прикладных объектов.

Конструктор запросов SQL в 1С очень широко используются на практике. Такой конструктор может разобрать имеющийся код из текста и представить его для визуального редактирования в схематическом виде:

Защита кода

В Navision если лицензия не позволяет, код прикладного объекта нельзя посмотреть. Однако его можно увидеть в отладчике или при экспорте объекта. Как правило – только при экспорте. Так как в основном, в лицензиях не включен доступ к отладчику.

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

Коллективная разработка

В конфигураторе есть полноценное средство для коллективной разработки конфигурации – хранилище конфигурации. Оно включено в платформу и не требует дополнительной оплаты.

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

Инструмент удобный и интуитивно понятный.

Язык программирования

Язык 1С больше похож на Visual Basic, язык Navision – на паскаль.

В Navision необходимо явное указание типов переменных (раннее связывание типов), в 1С это не требуется (позднее связывание типов).

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

Обработка строк в Navision морально устарела и служит источником лишнего труда для программиста. Учитывая, что любая обработка строк происходит в памяти и заведомо быстрее, чем обращение к базе данных, сейчас на скорости обработки строк при работе в СУБД не экономят. В Navision же программисту приходится следить за длиной строки, но мало этого – он не может обрабатывать строки длиной более 1024 символа (255 символов до версии 40).

В Navision нет таких полезных конструкций, как прерывание цикла и пропуск цикла.

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

В Navision нельзя использовать разыменование переменных, что делает использование типа Variant малоэффективным. Например, если в переменной Ф находится некая форма, в строке М – название метода этой формы, то нельзя вызвать метод формы по его имени вызовом вида Ф[М]. В 1С такое возможно и используется широко.

Очень печально, что в Navision нет обработки исключений. Невозможно написать надежное приложение без такой обработки.

В Navision не предусмотрено использование такого объекта данных, как структура (коллекция). Это большой недостаток, из-за которого программистам Navision приходится использовать массивы, что делает код нечитаемым. В Navision 5.0 планируют все же ввести структуры.

В Navision очень мало типов данных. Например, нет типа для элементов управления и т.п. А тип для форм хоть и есть, но с ним мало что можно сделать – разве что запустить форму. Соответственно невозможно эффективно работать с такими объектами.

Различия в прикладных объектах

Метаданные

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

Однако в 1С можно получить и более детальную информацию о прикладном объекте, например:

· список реквизитов этого объекта (название, тип значения)

· связи между прикладными объектами

· какие формы разработаны для прикладного объекта и т.п.

Поэтому в 1С метаданные часто используются.

В Navision подобную информацию можно получить только через C/Front.

Прикладные объекты данных

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

Существенное отличие 1С от Navision/Axapta и других классических систем (Access) в том, что она создала прикладные объекты, которые для программиста и пользователя выглядят одинаково - как объекты предметной области, для которой они реализованы. При этом такие объекты состоят из множества взаимосвязанных таблиц, но их обработка осуществляется в терминах предметной области, а не в терминах реляционной базы данных. При этом, однако, можно получить доступ к этим объектам, как к совокупности составляющих их таблиц, например, с помощью SQL запросов.

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

Достоинства использования прикладных объектов предметной области

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

Аналогом 1С в данном случае может выступать только СУБД Cashe.

Вот некоторые из разработанных в 1С типов прикладных объектов:

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

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

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

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

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

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

В Navision же индексы нужно указывать очень часто. Поэтому любое отключение или изменение индексов может послужить причиной отказа программы. В 1С изменение индексов влияет только на производительность, но не на работоспособность системы.

Таблицы имеют мало свойств – это список полей, индексов, у каждого поля свойства поля. Поэтому метаданные (данные о прикладных объектах) в Navision дают мало информации программисту. В то же время объекты прикладной области имеют большое разнообразие свойств, многие из которых могут быть заданы на этапе разработки, а не выполнения и все вместе составляют обширные метаданные 1С. Поэтому анализ метаданных широко используется в 1С и дает программисту представление об особенностях именно прикладного объекта, с которым он работает, а не об особенностях таблиц, из которых он состоит.

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

Неудивительно, что программирование в 1С более удобно, чем в Navision.

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

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

Недостатки использования прикладных объектов предметной области

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

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

В 1С большое введение большого количества аналитик требует больших затрат ресурсов и на практике используется не более 3-5 аналитик.

С другой стороны, реализация механизма аналитик, подобного Navision, невозможна, т.к. нет возможности написать свой эффективный прикладной объект, состоящий из нескольких таблиц. А составлять такой объект из уже имеющихся сложных объектов неэффективно.

Перспективы использования прикладных объектов предметной области

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

Возможность разрабатывать свои прикладные объекты, описывая код или на встроенном языке системы (Axapta), или на языке базы данных (не реализовано). Правда, в последнем случае могут возникнуть проблемы с совместимостью кода с различными базами данных.
Автоматическое создание таблиц для хранения экземпляров прикладных объектов (1С).
Создание новых типов прикладных объектов, от которых, наследуя, можно создавать новые типы и т.п. (Axapta).

Идентификация прикладных объектов конфигурации

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

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

Общие свойства прикладных объектов

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

В Navision, в обработчике события прикладного объекта, нельзя вызвать стандартный обработчик события. Это очень неудобно, приходится дублировать типовой функционал.

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

Обработка данных

Обработка данных в Navision

Язык SQL уже давно является стандартом для обработки данных, хранящихся в реляционных базах данных. Однако в Navision программисты могут работать только с таблицами Navision и временными таблицами.

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

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

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

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

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

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

Поэтому программисты Navision редко пробуют свои силы в изменении типового кода, потому что он слишком сложный по сравнению с типовым кодом 1С.

Обработка данных в 1C

1С 80 поддерживает полноценные SQL запросы на чтение данных, с объединениями множества таблиц. Модификация данных через SQL не используется.

Под SQL запросами подразумевается не прямой доступ к базе MS SQL, который можно реализовать практически в любой системе (в том числе и Navision), а именно доступ к прикладным объектам через SQL-подобный язык. Прямой доступ к базе обычно не используется в типовом функционале, а вот SQL-подобные запросы используются широко и штатно в 1С.

При запросе к прикладным объектам можно получить различные представления этого объекта (view). Т.е. при запросе к одному и тому же прикладному объекту мы можем получать его представление в виде различных таблицы с различным составом колонок.

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

В версии 81 можно использовать временные таблицы в базе данных, аналогично Navision, для хранения больших объемов информации.

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

Часто для работы с таблицами в Navision нужно указывать, какие использовать индексы. 1С подбирает индексы автоматически.

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

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

Лично меня, больше всего от Navision отталкивает именно ограниченный набор средств обработки данных. В той же Axapta, например, существует SQL-подобный язык запросов.

Таблицы

В Navision существует только один прикладной объект для хранения данных – таблица.

В 1С для хранения данных существует большое разнообразие типов прикладных объектов (справочник, документ, регистр, план счетов), что облегчает работу программиста с разнообразными данными.

В Navision лучше, чем в Access и 1С, организована связь между таблицами. Для поля можно указать, не только с какими таблицами связано это поле, но и при каком условии поле связано с какой таблицей.

В Access поле может быть связано только с одной таблицей.

Примеры сложных связей таблиц в Navision:

Если значение реквизита «Вид документа» таблицы «Журнал» равно «Приходная накладная», то реквизит «Документ» (первичный ключ) этой таблицы связан с реквизитом «Код» (первичным ключом) таблицы «Приходные накладные».
Иначе если значение реквизита «Вид документа» таблицы «Журнал» равно «Расходная накладная», то реквизит «Документ» (первичный ключ) этой таблицы связан с реквизитом «Код» (первичным ключом) таблицы «Расходные накладные».

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

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

В 1С связи реализованы с помощью универсального ключа – ссылки, которую имеет каждый объект, т.е. связать можно любые объекты.

В 1С для связей между таблицами используется тип GUID, вместо обычного для СУБД (16 байт) типа LONGINT (8 байт), что влечет некоторый перерасход памяти и меньшую скорость поиска.

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

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

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

Поэтому очень большой недостаток 1С по сравнению с Navision – то что в ней не реализованы триггеры на уровне поля. В Navision есть триггер OnValidate, который срабатывает при изменении значения поля. В 1С программист вынужден дублировать в каждой форме события изменения значения поля или ввода новой строки в документ. Вообще, это широко распространенный недостаток 1С, во многих прикладных объектах не хватает событий – например, события, связанного с добавлением/удалением строки в табличную часть документа.

В Navision можно программно выполнить обработку, отключив вызов соответствующего триггера, например можно удалить запись, отключив триггер контроля возможности удаления записи. В 1С, к сожалению, отключить вызов триггера нельзя. Это не очень удобно, в частности, при обмене данными.

Формы

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

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

В Navision нет полноценной библиотеки работы с формами, нет даже типов для формы и элементов управления. Работа с формами в Navision находится на уровне 1С 77.

Вот список того, что можно делать с формами в 1С и нельзя в Navision:

Получить форму-родителя данной формы. В 1С такой механизм широко используется при подборе данных.
Создавать динамически элементы управления. В 1С это часто используется, чтобы не заниматься ручной корректировкой типовых форм. В Navision можно только, как в 1с 77, прятать ненужные или недоступные элементы управления.
Активизировать заданный элемент управления.
Форма 1С может работать в полноэкранном режиме, например на рабочем месте кассира.

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

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

Также в 1С не хватает некоторых событий и свойств форм, например нельзя получить событие получения формой фокуса (активизации) и нельзя определить, к какой форме(или панели) принадлежит элемент управления. В Navision событие активизации формы есть.

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

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

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

Отчеты

В отчетах используются диаметрально противоположные подходы – в 1С отчеты похожи на Excel, в Navision на Access.

В Navision отчет можно сохранить только в HTML формат (а оттуда уже сохранить в Excel). В 1С можно сохранять отчет в Excel, HTML и внутреннем Excel-подобном формате 1С MXL.

В 1с каждая колонка в разных строках может иметь свою ширину, при чем такое форматирование в 1С 81 корректно отображается при переносе в Excel.

В Navision нельзя программно обработать уже сформированный отчет. Поэтому для вывода отчета в другой формат (например, в Excel) программисту приходится дописывать код практически во всех разделах отчета. В 1С программист получает доступ и к уже сформированному отчету, может обрабатывать его, как захочет, и экспортировать куда угодно.

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

Вот пример конструктора отчета в Navision:

Построитель отчета в Navision:

А вот пример конструктора отчета в Access:

В 1С используется Excel-подобный макет:

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

В 1С запросы могут строиться не только на основе таблиц, но и на основе коллекций значений и SQL-запросов, что ускоряет разработку отчетов. Причем текст SQL-запросов редактируется визуально.

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

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

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

Резюмируя, объективно можно сказать, что отчеты в 80 существенно лучше отчетов Navision.

Журналы

В Navision и 1С используются журналы – списки документов разного вида. В 1С журналы реализованы на уровне платформы, достаточно указать виды документов и реквизитов, которые попадают в журнал.

В Navision журналы реализованы на уровне функционала. Учитывая, что в Navision составной тип значения поля элегантно реализован, таблицы эти достаточно простые.

SIFT и регистры накопления/бухгалтерии

Описание технологии SIFT

Технология Sum Index Fields (SIFT) присуща только Navision.

Это действительно высокопроизводительная технология, которая позволяет очень быстро получать итоговые данные. Однако технология была оптимизирована под файловый формат базы данных, в в базах MS SQL сервера она работает медленнее.

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

Пример:

Движение товара по складу, последняя колонка – SIFT поле:

1 янв Пиво +10 10

2 янв Пиво -1 9

5 фев Пиво -3 6

6 мар Пиво +5 11

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

Аналогом в 1С 80 служат не менее производительные регистры накопления и SQL запросы в 1С.

SIFT реализован в терминах базы данных, поэтому для ее использования необходимо уметь работать с индексами.

Регистры 1С – это объект предметной области, поэтому работа с ними проще работы с SIFT.

Рассмотрим подходы Navision и 1C на примере.

Пример:

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

Нам нужно получить отчет об остатках товара за период дат с А по Б.

Решение Navision:

Создаем таблицу Motions (Движения) со структурой:

Date – дата движения
Stock - склад
Item - товар
Quant – количество

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

В таблицу Item (Товары) добавляем вычислимое поле:

Rest – вычислимое поле, формула SUM(Quant) WHERE (Date<=&A AND Item=&Item AND Stock=&Stock)

При построении отчета по товарам Item мы передаем различные варианты сочетания Stock, Item, Quant и вместо даты подставляем то A, то Б, получая начальный и конечный остаток.

Решение 1С:

В 1С мы создаем регистр накопления Остатки со структурой:

Дата
Склад
Товар
Количество
Приход – системное поле, есть в каждом регистре

Все движения по товарам заносятся в эту таблицу, приход с флагом Приход = истина, расход с флагом Приход = ложь.

В виртуальной таблице Остатки(А, Б) , к которой мы можем обратиться через SQL запрос, содержатся сочетания Дата, Склад, Товар, для которых значение остатка ненулевое и соответственно колонки с начальным и конечным остаткам на указанную дату.

В Navision остатки – это сумма всех движений по документу, тем не менее, считается очень быстро, т.к. SQL сервер легко справляется с запросами типа суммирования, особенно если есть подходящие индексы.

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

Внешний вид SIFT:

Sum("Seminar Ledger Entry"."Total Price" WHERE (Seminar No.=FIELD(No.),Posting Date=FIELD(Date Filter),Charge Type=FIELD(Charge Type Filter),Chargeable=CONST(No)))

Внешний вид регистров 1С:

Права доступа

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

1С работает с базой данных MS SQL под одним пользователем, Navision каждому пользователю заводит отдельный логин в базу.

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

И в 1С и в Navision можно управлять правами доступа, добавляя свой код в триггеры событий доступа к данным.

Меню пользователя

Начиная с 40, в Navision используется меню типа Outlook:

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

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

В 1С используется стандартное меню Windows, туда добавляются пункты:

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

Меню Navision можно реализовать средствами 1С, меню 1С нельзя реализовать средствами Navision, т.к. главное меню Navision недоступно для динамического программного изменения.

Особенности обновления конфигураций

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

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

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

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

Если в Navision существенные обновления выходят 2 раза в год, то в 1С обновления выходят чаще. В любом случае, обновление конфигурации – нетривиальная задача для программиста.

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

Для облегчения задачи используются следующие методики:

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

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

Например, если нужно, чтобы функция F(X) возвращала значение на единицу больше, чем она возвращает сейчас:

Class A

Function F(X)

F:=X*2;

End Function

Class B->A

Function F(X)

F:=A::F(X)+1;

End Function

Elem=New A();

R:=Elem.F(1);

Пока мы не опубликуем класс B, в переменную R будет заноситься двойка, после публикации класса B вместо класса A всегда будет создаваться класс B, и в переменную R будет заноситься тройка.

Идеальную методику системы Axapta невозможно реализовать в 1С 80 и Navision. Но в 1С 81 придумали некоторую альтернативу (подписка на события), в то время как программисты Navision вообще ничего не имеют в этом плане.

База данных

Формат базы данных

Navision и 1С могут работать с базой данных собственного файлового формата, или использовать промышленную СУБД MS SQL Server, которая проще в администрировании, производительнее и масштабируемее, чем базы данных собственного формата.

Не имеет смысл сравнивать по производительности файловые версии Navision и 1С, так как в промышленных масштабах у обеих систем используется MS SQL SERVER.

Версия 1С 81 дает возможность работы сервера 1С на ОС Linux, при этом в качестве СУБД используется Postgre SQL. При этом клиенты, правда, остаются на Windows.

Архитектура клиент/сервер

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

1С 80 – это более прогрессивное трехзвенное приложение. Данные могут обрабатываться на клиенте и на сервере. Программист имеет возможность указать, где именно должна выполняться обработка.

Трехзвенка работает только в случае покупки сервера приложений, и только под MS SQL Server. В противном случае все операции выполняются на клиенте.

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

Транзакции и блокировки

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

В файловой версии Navision можно заблокировать таблицу, в SQL-версии блокировки игнорируются, т.е. использовать блокировки нельзя.

Для организации контроля за параллельно используемыми ресурсами в Navision используется версионность записей:

· Когда запись считывается, запоминается ее версия.

· Когда запись записывается, ее версия увеличивается на единицу

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

В 1С можно управлять началом и концом транзакции, можно программно вызвать откат транзакции. Но большинство транзакций начинается само, аналогично Navision.

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

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

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

Память клиента

Обычно сетуют на то, что клиент 1С 80 использует большие объемы памяти.

Пустая конфигурация 1С 80 использует 50 Мб памяти. Конфигурации с большим числом объектов (УПП) могут занимать 200-300 Мб памяти. Это связано с тем, что 80 загружает в память все скомпилированные прикладные объекты. В 81 такое поведение системы изменили, объекты грузятся в память по требованию, неиспользуемые удаляются, под хранение прикладных объектов отведено ограниченное место.

Navision использует кэш ограниченного объема для хранения скомпилированных прикладных объектов.

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

Объем памяти клиента 1C 80 может расти, т.к. система может использовать память клиента для обработки данных. Результаты SQL запросов могут считываться последовательно или сразу быть переданы на клиента. Использование памяти клиента разгружает сервер и уменьшает трафик, но на слабых клиентских машинах преимущества выливаются в недостатки. Поэтому клиентские машины для 80 должны быть достаточно производительными.

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

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

Распределенные базы данных

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

Для 1С 80 разработан штатный механизм для создания распределенных баз данных. Он включен в платформу и не требует дополнительного лицензирования.

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

Для Navision есть решения от сторонних поставщиков, но необходимо учитывать больше нюансов, чем в 1С, т.к. в 1С возможность реализована на уровне платформы, а в Navision – на уровне функционала.

Интеграция

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

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

Обмен данными

В Navision реализованы специальные прикладные объекты для обмена данными в формате TXT(CSV) и XML.

В 1С такие возможности реализованы на уровне встроенных объектов. В ранних версиях можно было пользоваться OLE-Automation для доступа к XML-парсеру.

В 1С, за счет использования метаданных, широко развиты средства для обмена данными между базами данных, даже с различными конфигурациями. Существует специальная конфигурация «1С:Конвертация Данных» для настройки правил обмена.

Торгово-учетное оборудование

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

На уровне движка в 1С есть возможность обработки в форме события от внешнего оборудования.

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

Администрирование

Обновление платформы

К сожалению, вынужден отметить, что 1С 80 пережила переход от версии 77 к 80 без обратной совместимости – из 77 можно перенести только структуру данных и сами данные, но код полностью несовместим.

Насколько мне известно, в Navision таких резких переходов не было.

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

Видимо в Navision механизм обновления платформы реализован аналогично.!!!

Обновление конфигурации

Для внесения любого изменения в конфигурацию (даже несущественного) в 1с нужно отключать всех пользователей. Это существенное неудобство администрирования. Общая сумма простоев пользователей по этой причине составила за время существования 1С большую цифру.

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

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

Функционал

Среда для разработки приложений

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

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

Этому способствуют простота разработки в 1С, простая политика лицензирования и низкая цена самой платформы (без типовой конфигурации).

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

Поэтому если Navision/Axapta ценны только вместе с типовым функционалом, то 1С – неплохой инструмент для быстрой разработки среднего размера баз данных.

Политика развития типового функционала

Navision (и Axapta) развивают одну типовую конфигурацию.

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

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

Такой подход обеспечивает концентрацию сил на развитие одной конфигурации. Кроме того, сторонние разработчики имеют один ориентир – типовую конфигурацию и им проще разрабатывать доработки.

В 1С, к сожалению, все обстоит хуже.

1С развивает несколько типовых конфигураций.

По сути, наиболее функциональное из них – это Управление Производственным Предприятием (УПП), которое включает в себя весь функционал других вложенных конфигураций, а именно:

Бухгалтерия Предприятия (БП)
Зарплата и Управление Персоналом (ЗУП)
Управление Торговлей (УТ)

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

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

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

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

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

Когда мы говорим о функционале Navision, мы говорим о функционале одной типовой конфигурации, а когда говорим о функционале 1С, нужно уточнять, о какой именно конфигурации идет речь.

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

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

Первоначально 1С не претендовала на конкуренцию по функционалу и производительности с Navision, однако новая платформа 80 дала возможность 1С выйти из ниши мелких и средних предприятий.

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

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

Количественный объем функционала

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

В УПП 1.1.9.3 получается 1276 таблиц, полный список приведен в файле 1s_objects_list.xls.

В Navision 4.0 851 таблица, полный список приведен в файле navision_objects_list.xls.

Подсчеты говорят о том, что функционал УПП не менее сложный, чем функционал Navision. Конечно же, это только количественная оценка, функционал может быть развит в разных областях (бухгалтерия, торговля, кадры, менеджмент и т.п.).

Особенности типового функционала

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

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

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

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

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

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

В Navision на плане счетов можно использовать любое количество аналитик, не нагружая систему. В 1С обычно используется не более 3-5 аналитик на каждый счет. Штатными механизмами невозможно сделать производительную систему большого числа аналитик. Хотя обычно такое большое количество аналитик не нужно для бухгалтерского учета, но, тем не менее, это говорит о возможностях бухгалтерского учета.

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

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

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

В Navision декларируется принцип простоты (simplicity) – сложные данные пытаются организовать как можно проще, с помощью таблиц. В принципе неплохой подход, но разработка прикладных объектов для предметной области (1С) еще больше увеличивает простоту разработки.

Работа задним числом

В Navision/Axapta используется идеология запрета заднего числа, т.е. после проведения документа невозможно отменить его проведение.

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

Аудиторский след – каждый документ оставляет свой след в системе, невозможно скрыть какое-либо действие.
По количеству корректировок можно судить о том, как качественно работают подразделения предприятия.
Операторы приучаются работать без ошибок, по принципу семь раз отрежь – один отмерь.

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

Однако идеологи запрета заднего числа не правы:

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

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

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

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

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

Бухгалтерия в наших суровых условиях работает методом подбора, к сожалению, идеология функционала Navision мало ей подходит (что написано пером – не вырубишь топором). У нас правила слишком часто переигрываются.

Navision/Axapta позиционируют себя, как единая система для любой страны мира. Но, увы, для России ее идеология мало подходит именно из-за невозможности работы задним числом.

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

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

Работа пользователя с программой

Посмотрим на работу Navision и 1С с точки зрения пользователя (не особо отделяя движок от функционала):

В Navision нет календариков для ввода дат и выбора периода. Дату нужно набивать вручную. С другой стороны, в Navision можно использовать буквенные сокращения для текущей даты, квартала и т.п.
В Navision нет иерархии в справочниках.
Фильтры справочников и документов есть в Navision и 1С, в Navision можно еще фильтровать и строки документов.
Любой список в 1С и Navision можно вывести в таблицу, а затем в эксель.
Любой отчет в 1С можно сохранить в Excel. В Navision раньше отчет можно было только распечатать, сейчас можно сохранить отчет в HTML, а из него в Excel.
Отчеты в Navision черно-белые и не интерактивные. Вместо интерактивных отчетов используются отчетные формы, но их нельзя распечатать.
Цвет в Navision практически не используется. В 1С цвет используется широко.
Поддержка мультиязычности есть в обеих системах. Но в 1С нет поддержки разного наименования товаров на разных языках.
В Navision можно получить гиперссылку на любой отчет или форму.
В 1С есть ошибки, которые платформа отлавливает, выдает о них сообщение и в принципе, могла бы продолжать работу, но после этого программа закрывается. Это очень раздражает пользователей. В Navision даже ошибка переполнения стека отлавливается, и программа не закрывается.
1С может завершиться аварийно из-за нехватки памяти. Navision памяти всегда достаточно.

Внедрение. Переход со старой учетной системы

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

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

Кроме того, в 1С существует мощный инструмент для настройки правил переноса данных из одной системы в другую – конфигурация «Конвертация данных».

Требования к программистам

В 1С язык программирования и названия объектов – русские, в Navision – английские. Поэтому программист Navision должен знать технический английский.

1С обучаться проще, чем Navision, потому что программист работает с более простыми объектами, чем таблицы. В Navision, кроме того, нужно изучить много фактического материала – правила именования и виды таблиц, способы проведения документов, правила использования таблиц и индексов и т.п. Иными словами, программисту 1С нужно изучить меньше функционала, чтобы нормально работать в системе. Отсюда возник даже общеупотребительный термин «Тупой 1Сник», характеризующий легкость освоения программирования в 1С.
Программистов 1С больше, чем программистов Navision, но, тем не менее, спрос на обе категории превышает предложение. Профессия пользуется спросом.
Легкость программирования в 1С приводит к тому, что программист 1С меньшими затратами может сделать большее. Поэтому у него остается больше времени на изучение функционала и в результате программист 1С становится неплохим консультантом, хорошо ориентирующемся в функционале системы.

Сертификация

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

Примеры продуктов: Платформа (знание движка), ЗУП (конфигурация зарплата и управление персоналом), УТ (Управление торговлей) и т.п.

Сертификат привязан к фирме, которая оплачивает сдачу экзамена или к человеку, если он сдает экзамен за свой счет.

По сертификации в Navision у меня нет данных.

Выводы

В данной статье я попытался систематизировать свои знания об 1С и системах Dynamics – Navision и Axapta.

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

Поэтому мне не интересна система Navision. Немного интересна Axapta, в ней есть много перспективных вещей, но интерес сугубо познавательный – 1С все-таки использует самые новые технологии программирования, которые пока еще не реализованы нигде.

Кроме того, 1С – популярная и доступная вещь, она есть везде, поэтому можно не заботиться о трудоустройстве.

Как результат – останусь в 1С.

В приложении navision_vis_1s.xls указан список отличий Navision от 1С, правда, в виде черновика.

(-C) Осипов Сергей Алексадрович aka Гений 1С aka Fixin
2006 декабрь

fixin@mail.ru

http://fixin.com.ru

ICQ: 203-136-830