Главная
О компании
Скачать
Вопрос-ответ
Форум
Новости
Контакты
Подписка на рассылку НК "Услуги для бизнеса":
Эффективное управление бизнесом: просто о сложном

Подписаться письмом

  Наиболее характерные вопросы по TNP-платформе

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

Ответ:
Чтобы сохранить значение можно воспользоваться следующей конструкцией:
TCClientInfoSpace.ConfigVariableManager.SetConfigValue( "имя переменной", "описание переменной", <значение переменной>);

Чтобы прочитать значение:
TCClientInfoSpace.ConfigVariableManager.GetConfigValueServer("имя переменной", <значение по умолчанию>);

Например:
TCClientInfoSpace.ConfigVariableManager.SetConfigValue( "MyIntVar", "Переменная целого типа", 25);
int myIntVar = (int)TCClientInfoSpace.ConfigVariableManager.GetConfigValueServer("MyIntVar", 0);
Вопрос:
Как отобрать определенные данные при вызове справочника?

Ответ:
Отобрать определенные данные при вызове справочника можно с помощью формулы для фильтра справочника. Формула должна возвращать значение "истина" или "ложь". Обычно в качестве фильтра используются довольно простые формулы. Например: "[reference. ID_TYPEPL] = [this.ID_TYPE]", т.е. отбираются только те учетные записи справочника, у которых значение атрибута ID_TYPEPL равно значению атрибута ID_TYPE учетной записи, из которой вызван справочник. Для большинства задач этого достаточно. Вообще, нужно отметить, что в случае фильтра справочника данная формула не вычисляется непосредственно, а транслируется в выражение, используемое в секции WHERE SQL-запроса, получающего записи справочника. К сожалению, далеко не все функции, реализованные в языке формул TNP, могут быть адекватно переведены на язык SQL. Поэтому вероятно, некоторые сложные формулы могут и не работать. Для того, чтобы обойти эту проблему можно предложить следующее: в типе УЗ, из которой вызывается справочник определить вычисляемый атрибут, значение которого может вычисляться по сколь угодно сложной формуле, а формулу фильтра справочника свести к виду "[reference.<хранимый атрибут>] = [this.<вычисляемый атрибут>]".
Вопрос:
Существует ли возможность отфильтровать данные в гриде, наложив на них маску из textbox'a:
  1. расположенного на той же форме?
  2. расположенного одновременно с открытой формой грида?
Если да, то как лучше реализовать?

Ответ:
Для случая, когда TextBox расположен на той же форме, что и грид, можно назначить в качестве обработчика какого либо события TextBox'а бизнес- процедуру, текст которой приведен ниже. В качестве такого события подходит, например, событие TextBox.Validated.

// Обработчик события TextBox.Validated


// Приводим параметр sender к типу TextBox.
System.Windows.Forms.TextBox filterBox = sender as System.Windows.Forms.TextBox;
// Если почему-то приведение на получилось, завершаем работу.
// Можно выбросить исключение.
if (filterBox == null)
return;
// Находим визуальную форму, на которой расположен наш TextBox.
TCVisualForm form = filterBox.FindForm() as TCVisualForm;
if (form == null)
return;
// Находим компонент представления данных.
// Методу FindDataView передаем имя компонента.
TCDataView dataView = form.FindDataView("MOS_ACCOUNT");
if (dataView == null)
return;
if (!String.IsNullOrEmpty(filterBox.Text))
{
// Если в TextBox введен какой-то текст, то ...
// Создаем т.н. "контекст" - коллекцию переменных, используемых
// в формуле фильтра.
TCCalcContext filterContext = new TCCalcContext();
// Добавляем в контекст переменную с именем "criteria"
filterContext.AddVariable("criteria", filterBox.Text);
// Добавляем в коллекцию фильтров представления данных новую схему фильтрации:
dataView.Filters.AddFilterSchema(
// Имя схемы
"TextBoxFiltering",
// Указывает, что фильтр накладывается из программы.
// Этот фильтр не будет виден, если пользователь
// воспользуется стандартноым диалогом фильтрации грида.
TNP.Common.Condition.ECFilterSource.Program,
// Формула, задающая условие отбора.
// В данном примере мы хотим отобрать такие записи,
// значение атрибута "MA_NUM" содержит в себе техт из TextBox'а.
"Contains([this.MA_NUM],[criteria])",
// Созданные нами ранее контекст, содержащий переменную "criteria".
filterContext,
// Указываем, что это серверный фильтр, т.е. формула будет
// соответствующим образом преобразована и включена в SQL-запрос,
// выбирающий данные.
ECFilterType.Server
);
}
else
{
// Если TextBox не содержит текста, то удаляем созданную нами ранее
// схему фильтрации.
// Метод RemoveFilterSchema не выбрасывает исключений, если схема с
// указанным именем и типом отсутствует в коллеции.
dataView.Filters.RemoveFilterSchema(
"TextBoxFiltering", // имя схемы
TNP.Common.Condition.ECFilterSource.Program // тип фильтра.
);
}
// Устанавливаем все фильтры, из коллекции фильтров представления.
dataView.Filters.SetFilter(dataView);

Для случая, когда TextBox и TCDataView находятся на разных формах вместо
TCVisualForm form = filterBox.FindForm() as TCVisualForm;
следует найти необходимую форму в коллекции открытых форм (статическое свойство TCBaseForm.OpenForms).

foreach (Form openForm in TCBaseForm.OpenForms)
{
TCVisualForm form = openForm as TCVisualForm;
// Не все формы этой коллекции имеют тип TCVisualForm.
if (form != null)
{
// Логика принятия решения, та ли это форма.
}
}

Несколько слов следует сказать по поводу типа фильтра (серверный или клиентский) и особенностей работы компонента TCDataView. Существует два сценария работы с данными.
  1. Мы открываем таблицу, содержащую неизвестное количество строк, не накладывая заранее никаких фильтров. Очевидно, что если таблица содержит сотни тысяч, а то и миллионы записей, загрузить их все на клиент мы не сможем, программа просто упадет. В этом случае нужно загружать данные относительно небольшими порциями по требованию клиента. Для этого у компонента TCDataView существует свойство PageSize, значение которого задает количество записей, одновременно загружаемых на клиент. Например, если мы укажем PageSize=200, то при открытии представления методом TCDataView.Open() SQL-запрос выберет первые 200 записей в соответствии с текущей сортировкой и на клиент попадут только они. При обращении к 201-й записи, например, если пользователь будет перемещаться по записям в гриде, будут загружены следующие 200 записей, а предыдущие удалены из памяти. С одной стороны, такой подход позволяет нам обращаться к большим объемам данных, не задумываясь о последствиях, с другой стороны, будет происходить довольно частая подкачка данных, требующая определенного времени. В этом случае лучше использовать серверный фильтр - это скорее всего будет быстрее. При использовании клиентского фильтра в режиме страничного доступа загрузка очередной страницы может происходить в несколько этапов: сначала на клиент будут переданы 200 записей, потом каждая из них проверена на соответствие условиям фильтра, затем, если не все записи прошли проверку, будет загружена следующая порция записей и так до тех пор, пока не наберется полная страница. Очевидно, что это отрицательно скажется на быстродействии.
  2. Мы заранее накладываем довольно жесткий серверный фильтр, и уверены, что количество записей не превысит нескольких десятков или сотен. В этом случае лучше загрузить на клиент сразу все данные и не обращаться к БД до тех пор, пока не потребуется сохранить изменения или обновить данные. Для этого значение свойства PageSize нужно установить равным нулю. В такой ситуации лучше использовать клиентский фильтр, чтобы избежать лишнего обращения к серверу.

При использовании серверного фильтра нужно иметь в виду, что в нем нельзя использовать ссылочные, агрегатные и вычисляемые атрибуты. В случае если такие атрибуты все-таки нужно использовать, можно комбинировать серверный и клиентский фильтры.
Вопрос:
Мы планируем разработку на вашей TNP-платформе CRM масштаба предприятия. Обработка разнородных разрозененных данных в этом проекте отсутствует. Единственная база целиком лежит на MS SQL Server. Ознакомившись с TNP-платформой и документацией на нее, мы озадачились вопросом: а чем, собственно, в этом случае, ваша платформа лучше чем связка Visual Studio + DevExpress + Cristal Report? Хотелось бы услышать ваше пояснение и (или) ссылку на такое сравнение.

Ответ:
Любая информационная система масштаба предприятия должна содержать в своем составе, помимо бизнес-логики, различные административные функции. Хороший пример - разграничение доступа пользователей к информации и функциям системы. Задача не самая простая, а ведь это еще далеко не все. Разработка бизнес-логики также потребует решения различных типовых задач. Мало иметь хороший компонент "грид", помимо этого нужно обеспечить в нем поиск и фильтрацию данных. Кроме того, и данные нужно как-то получать. Если речь идет о системе масштаба предприятия, а предприятие большое, то данных будет много и их невозможно будет загрузить на клиент целиком, а значит придется их как-то ограничивать, загружать порциями и т.п. Все подобные задачи можно решить с помощью Visual Studio и различных библиотек компонентов. Как их решать - известно, на этот счет существует множество литературы и технической документации. Но на это потребуется несколько человеко-месяцев или, по крайней мере, недель. А время - деньги, в том числе выплаченные программистам в качестве зарплаты. Кроме того, Visual Studio и различные компоненты тоже стоят денег. В TNP все эти задачи уже решены и разработчикам нужно думать только о бизнес-логике.
Вопрос:
Планируется ли реализовать версионирование в правильном смысле этого слова, чтобы видеть кто какие изменения делал, иметь возможность к откату к предыдущим версиям и т.д. , а не только фиксировать авторство и последнее изменения, как это делается сейчас?

Ответ:
В ближайшее время не планируется.
Вопрос:
Планируется ли реализовать визуальный конструктор SQL запросов?

Ответ:
Необходимость такого инструмента представляется сомнительной. Дело в том, что в распространяемую версию такой конструктор встроен. В результате анализа более чем десятилетнего использования конструктора мы пришли к выводу, что для написания запросов типа "SELECT * FROM таблица" он не нужен, да и необходимости в таких запросах в TNP нет, достаточно имени таблицы. А в случае более сложных запросов возможностей визуального конструктора все равно будет не хватать и текст запроса придется дорабатывать вручную.

В результате в ближайшее время включение конструктора SQL-запросов не планируется. В перспективе - в зависимости от пожеланий клиентов.
Вопрос:
Будет ли реализован компонент OLAP анализа?

Ответ:
Потребность в таком инструменте есть, но насчет сроков пока ничего сказать нельзя.
Вопрос:
Будет ли реализован фильтр по выделенному с логикой как в MS Access? Удобной, интуитивно понятной?

Ответ:
Честно говоря, нам логика MS Access в этом смысле не представляется такой уж удобной и интуитивно понятной. Поэтому точно так же, как в Access, мы делать не будем.
Вопрос:
Не нашли возможность отладки кода. Есть ли возможность пошагового выполнения кода и просмотра состояния объектов?

Ответ:
В текущей версии, к большому сожалению такой возможности нет. В ближайшем будущем, надеемся, появится.
Вопрос:
Существует ли документация по API платформы?

Ответ:
Да, есть. В ближайшее время будет опубликована на сайте. До этого может быть выслана по e-mail.
Вопрос:
Возможно ли использование посторонних компонентов при программировании в среде TNP-платформы? В частности компоненты DevExpress.

Ответ:
Технически такая возможность есть, но она искусственно ограничена и пользователю пока недоступна.
Вопрос:
Будут ли реализована пользовательская группировка и итоги в гриде (суммирование по группе)?

Ответ:
В основе идеологии TNP лежит простая мысль: большинство задач должно решаться без привлечения высококвалифицированных специалистов. В идеале разработчик должен иметь в своем распоряжении 5-10 компонентов, у каждого из которых есть 5-10 свойств и событий. Этого ему хватит для решения 90% задач, но зато эти задачи он будет решать быстро, без длительного изучения гигабайтов технической документации. Остальными 10% задач придется пожертвовать. В полном объеме эту идею выдержать не удалось, и текущее состояние TNP представляет собой компромисс между простотой восприятия и разнообразием возможностей. В перспективе планируется сделать два варианта интерфейса разработчика: один для обеспечения максимума возможностей, другой - упрощенный в стиле "для чайников".

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

Ответ:
В настоящее время используются компоненты SyncFusion версии 7.4, т.е. не совсем старые. Возможностей, предоставляемых этой версией компонент более чем достаточно для текущего состояния и текущих задач TNP. Поэтому в ближайшее время переход на новую версию не планируется. В перспективе, по мере развития как проекта TNP, так и Essential Studio, переход на новую версию компонент Syncfusion возможен.
Вопрос:
Вы пишете: "предназначенной для быстрой разработки программ любой степени сложности". Какие программы можно разрабатывать?

Ответ:
Относительно того какие программы: по сути любые, но лучше, конечно информационные, с большим количеством разнообразной информации, или учетные. А еще можно собрать данные из разных программ и обработать их. Например, есть у Вас часть данных в Exel, что-то в Word, а что-то в почте то можно написать алгоритм сбора и обработки данных.
Вопрос:
Какие задачи ваша платформа решает и каким образом? И в чем отличие от того же SharePoint, например?

Ответ:
SharePoint - это другое. SharePoint может быть использован для создания сайтов, предоставляющих пользователям возможность для совместной работы, документооборот, HelpDesk.

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

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

Также встроенные возможности могут применяться для интеграции различных приложений, при этом мы не получаем бесшовной интеграции в полном смысле этого слова, но и избегаем сложностей, с которыми сталкиваются шины. Нам нет необходимости менять исходные приложения. Самое главное, чтобы имеющиеся приложения могли экспортировать и импортировать данные в используемых нами форматах. Например, txt, xml, db, dbf, xls и др.

Итак, мы можем рекомендовать использования TNP для решения трех задач:
  • быстрая разработка приложений;
  • инструмент бизнес аналитика для сбора и обработки информации из различных приложений$
  • интеграции разрозненного ПО.
Вопрос:
А я вот под Linux-ом сижу, у меня получится попробовать?

Ответ:
Пока TNP работает только под Windows. Linux в планах.
Вопрос:
Каким практическим функционалом обладает TNP?

Ответ:
В TNP нет функционала, который можно предлагать, как законченное коммерческое решение для конечных пользователей. Пока создана только платформа, полезная разработчикам и бизнес-аналитикам.
Вопрос:
А чем TNP лучше, чем, скажем, ESB?

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

ESB - позиционируется как средство интеграции.

Соответственно, в отличие от TNP, на ESB написать, например, CRM не получится. Если надо разрабатывать ПО, то TNP с такими задачами хорошо справляется, а ESB вообще не годится.

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

TNP работает по другому принципу. Нам главное, чтобы имеющиеся приложения могли экспортировать и импортировать данные в используемых нами форматах. Например, txt, xml, db, dbf, xls и др. После экспорта далее данные обрабатываются (можно обрабатывать по сложным прописанным в TNP алгоритмам) и затем импортируются в другое приложение в нужном формате.
Вопрос:
В чем отличие TNP от NsgSoft Framework?

Ответ:
На данном этапе у нас нет никакой функциональности для бизнеса. В качестве одного из преимуществ, следует отметить тот факт, что для разработки приложения в TNP ничего кроме самого TNP не требуется. В случае с NsgSoft Framework это не так, там не обойтись без Visual Studio или другой среды разработки. Даже по видео-уроку NsgSoft можно заметить, что процесс разработки пользовательского интерфейса достаточно сложен. Сложен, по крайней мере, в том смысле, что требует совершения множества специфических действий: генерации кода, внесения изменений в этот код, компиляция и т.д. В TNP ничего подобного делать не надо, у нас есть все необходимое для разработки, в частности, визуальный редактор форм, аналогичный таковому в Visual Studio или других средствах разработки. Вследствие вышеизложенного, процессы генерации кода и его компиляции (там, где они есть), максимально скрыты от глаз пользователя. Кстати, у нас большая часть метаданных интерпретируется, а если и компилируется, то только та часть, которая нужна в настоящий момент, и только если она еще не была откомпилирована. Таким образом, создав или изменив описание любой сущности, пользователь (разработчик) может немедленно увидеть свои изменения в действии без утомительного ожидания. Это существенно сокращает время разработки приложения. Вторым следствием этого подхода является простота распространения метаданных по клиентским рабочим местам. В случае NsgSoft метаданные и исполняемый код нужно распространить на все рабочие станции и убедиться в том, что везде установлена текущая версия. Возможно, NsgSoft имеет какие-то средства для облегчения этого процесса, но на их сайте мы не смогли прочитать про них. В TNP же на клиентской рабочей станции не нужно ничего, кроме исполняемого кода клиента TNP. Все метаданные хранятся централизовано на сервере приложений и выдаются клиенту по мере надобности. При этом гарантируется, что клиент всегда получает актуальную версию метаданных. При изучении NsgSoft Framework (правда, довольно поверхностном) у нас создалось впечатление, что в качестве СУБД можно использовать только MS SQL Server. Если это действительно так, то в качестве еще одного преимущества TNP можно указать, что уже сейчас мы можем работать с MS SQL Server, Oracle и с некоторыми ограничениями с источниками данных, доступными ядру MS Jet. К тому же, список поддерживаемых СУБД может быть достаточно легко расширен, поскольку особенности диалектов SQL описываются специальными метаданными. Кроме того, TNP может одновременно работать с несколькими базами данных на разных серверах БД. При этом бизнес-логике приложения абсолютно все равно, где находятся те или иные данные. Это очень краткий и, видимо, далеко не полный список преимуществ TNP. Приводя его, мы никоим образом не пытаемся умалить достоинств продукта NsgSoft Framework, а только лишь хотим указать на наши преимущества.
Вопрос:
Дайте, пожалуйста, еще сравнение с Искрой.

Ответ:
С Искрой сравниваться тяжелее, поскольку, судя по описаниям Искры, возможности продуктов примерно одинаковые. Различия, безусловно, есть, но они не имеют принципиального характера, и, вполне вероятно, что дело тут может быть в личных предпочтениях каждого. Например, бизнес-процедуры на C# в TNP против Pascal-скриптов в Искре.

В качестве существенного преимущества TNP можно отметить более богатые возможности визуализации данных по сравнению с Искрой. У нас есть дизайнер визуальных форм в стиле Visual Studio, позволяющий произвольным образом располагать на форме визуальные компоненты (список компонентов довольно обширен), связывать любые свойства компонентов с данными, обрабатывать события. В Искре же визуальные формы обеспечивают в основном только табличное представление данных.

"У Искры и TNP совсем уж разные, скажем так, объектные модели и принципы создания приложений. К примеру, тот же каталог дисков, для сравнения. Цель одна, но способы ее достижения - разные" - такое мнение высказал один из специалистов на форуме.
Вопрос:
"Стандартная" бизнес-логика делается через настройки? Кем она делается - вендором или клиентами?

Ответ:
Сейчас вендором она сделана в минимальном объеме. Мы планируем это расширять. В любом случае, клиент может это делать самостоятельно. На это и направлено продвижение TNP на данном этапе.
Вопрос:
Сам язык будет бизнес-ориентированным (конструкции языка в терминах предметных областей)?

Ответ:
Нет. Там, где это требуется, будет C# или Visual Basic. Мы предоставляем иерархию классов, которая облегчает разработку бизнес логики.
Вопрос:
ERP система "Компас" написана на платформеTNP?

Ответ:
Текущая версия разработана не на ней. На платформе TNP будет разработана следующая версия ERP-системы "Компас".
Вопрос:
"Разные бизнес - процедуры можно писать на разных языках"... Это как?

Ответ:
Если не получилось все, что требовалось, сделать настройками (кнопочно-галочными), пишутся бизнес-процедуры. Бизнес-процедура - это фрагмент программного кода, который пишется либо на C#, либо на VB.net. Каждая бизнес-процедура может быть написана на своем языке. Например, если работает несколько программистов, и каждый пишет свою процедуру, то договариваться, на каком языке будут писать, не надо.
Вопрос:
Поддерживает ли TNP объектную парадигму в ходе моделирования и проектирования?

Ответ:
TNP поддерживает объектную парадигму для некоторых сущностей.
Вопрос:
Существует ли кодогенерация, подобная BOLD?

Ответ:
По поводу кодогенерации. На наш взгляд, есть два принципиально отличающихся сценария ее применения. В первом случае автоматически сгенерированный код исполняется без каких-либо изменений. Во втором случае в автоматически сгенерированный код вносятся изменения и дополнения с целью реализации какой-либо нестандартной логики, находящейся за пределами возможностей кодогенератора и\или исходного языка. Очевидно, что в первом случае наличие или отсутствие кодогенерации является всего лишь внутренней особенностью реализации системы, неинтересной конечному пользователю. Второй случай заслуживает рассмотрения. С одной стороны, мы получаем почти неограниченные возможности расширять функциональность нашего приложения. С другой стороны, мы попадаем в следующую не совсем простую ситуацию. Мы описали нашу модель, по описанию сгенерировали промежуточный код, внесли в этот код свои дополнения, получили какой-то результат. А теперь нам нужно внести изменения в исходное описание. Мы опять генерируем промежуточный код и нам опять нужно вносить в него изменения и дополнения. Чтобы упростить этот процесс, необходимо как-то отделять автоматически генерируемый код от кода, созданного вручную. То есть, в сущности, нас интересует возможность реализации нестандартных алгоритмов с помощью какого-либо языка программирования, а вовсе не автоматическая кодогенерация.

В TNP большая часть метаданных итерпретируется в момент использования, что обеспечивает возможность мгновенно увидеть результат изменений, внесенных в метаданные. По крайней мере, это касается объектов бизнес-логики и пользовательского интерфейса. При этом можно разрабатывать, т.н. "бизнес-процедуры" - небольшие программы на C# или Visual Basic, с помощью которых и можно реализовать нестандартную логику. Бизнес-процедуры могут вызываться непосредственно или использоваться в качестве обработчиков различных событий.

При этом нельзя сказать, что автоматическая кодогенерация отсутствует совсем. В части доступа к данным она есть. Так, например, SQL-запросы могут генерироваться автоматически. Сгенерированные запросы могут быть модифицированы и сохранены для дальнейшего использования, либо автоматически формироваться непосредственно перед использованием.
Вопрос:
Возможно ли декларативное построение интерфейса? Интерфейс классический? Мастре-дитейл, деревья? Или базирующийся на концепциях объекта, связей, операций поведения?

Ответ:
Автоматическое построение интерфейса означает, что на основе описания структуры данных могут быть автоматически сформированы описания визуальных форм для отображения этих данных. Тоже своего рода кодогенерация. В дальнейшем эти описания могут быть изменены или дополнены. Существует визуальный редактор форм, позволяющий располагать на форме различные компоненты, указывать значения их свойств, привязку свойств к данным, обработку событий
Вопрос:
Возможно ли использования прямого UML моделирования (например MDA), поддерживается ли OCL или нечто подобное?

Ответ:
Использование прямого UML моделирования пока невозможно.
Вопрос:
В чем особая революционность проекта? Возможно ли создание web-приложений?

Ответ:
Создание web-приложений планируется в недалеком будущем.
Вопрос:
TNP это скорее инструмент программиста или "датабазника"? Как он помогает решать задачи бизнес аналитика?

Ответ:
TNP - это в первую очередь инструмент для разработчика. При этом мы позиционируем TNP и как средство для бизнес-аналитика, т. к.:
  1. Если бизнес-аналитик может выступать в качестве постановщика задач, то он может и автоматизировать данную задачу, используя "кнопочно-галочные" настройки. Программировать при этом не требуется.
  2. TNP позволяет работать с данными в разных форматах и из различных баз данных. Перед аналитиками иногда стоят задачи получения всевозможной отчетности на основе таких данных. В этом случае после написания процедуры сбора данных аналитик может создать алгоритм их обработки. Такой алгоритм можно сделать без программирования.
Вопрос:
А как можно посмотреть вашу программу? Она бесплатно распространяется? Где скачать?

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


Вернуться к главному перечню вопросов


Проекты

Заключен договор на внедрение модуля КОМПАС: Путевые листы и ГСМ у автоперевозчика "ЮНИКАР".
Подписка на рассылку компании "КОМПАС":
Повышаем эффективность бизнеса - бесплатные online-семинары

Подписаться письмом
Рейтинг ИТ-компаний - 80
Rambler's Top100
Rambler's Top100
Яндекс.Метрика