Раньше когда-то давным-давно слышал об этой штуке. Как только узнал, что сделана она на Visual FoxPro, сразу потерял к ней интерес, поскольку был уверен, что ничего масштабного и стоящего на FoxPro нормальные люди никогда делать не возьмутся.
Буквально несколько дней назад съездил на Украину на один из заводов. Там как раз собрались внедрять эту штуку. Поглядел материалы. Был ошеломлен, на сколько развилась система за пару лет. Если всё, что они там понаписали правда, то это весьма интересный жук... У меня был всего один вечер, чтобы полистать документацию в гостинице, поэтому тщательно ее изучить просто не было времени. Особый интерес у меня вызвали модули бухучета. Сдается мне, что конкретно в бухучете они маленько плавают, вплоть до терминологии. И с гибкостью настроек плана счетов имеются проблемы. То есть, имеется ряд предопределенных аналитических справочников и предопределенных аналитических форм. Например, "Оборотные ведомости по подразделениям " или "... по предприятиям " наряду с "Оборотными ведомостями по счетам аналитического учета". Отсюда видно, что "предприятия" и "подразделения" не являются аналитиками, равноценными с другими видами аналитик. Обнаруженный в документации терминологический сумбур сбил меня с толку окончательно. Счета в плане счетов делятся на "синтетические" и "аналитические", при этом для синтетического счета задаются такие параметры:
- вид счета в системе учета: балансовый / забалансовый / аналитический
- ведение аналитического учета по внешним контрагентам или персоналу предприятия в операциях по счету
Далее еще интереснее:
"Система поддерживает 10-уровневую иерархию синтетических счетов и 12-уровневую иерархию аналитических счетов"
...
" - поддержка второй иерархической аналитики"
Я так и не понял, сколько НЕЗАВИСИМЫХ аналитических разрезов может быть у счета - 10, 12 или всего лишь 2. Если последнее, то я тихонько плАчу...
Каким образом синтетические счета имеют аналитические разрезы, тоже не понятно. В НОРМАЛЬНОЙ терминологии бухгалтерского учета синтетический и аналитический счет - это одно и то же. Только синтетический - это свернутый (сагрегированный) в одну итоговую сумму. А аналитический - это с разбивкой этой суммы по аналитическим разрезам. То есть, синтетический счет - это свертка аналитического (того же самого).
Можно высказать предположение, что где-то в этой терминологической каше затерялся третий смысл. Видимо, разработчики системы "придумали" новый вид "небухгалтерского счета", используемого для вспомогательных целей, и назвали его "аналитическим".
Все равно, не вижу причин, по которым "аналитический" и "синтетический" счет имеет разное количество уровней иерархии. Что-то тут нечисто.
Насчет НЕЗАВИСИМЫХ аналитик сильно подозреваю, что их всего две. Если это так, то я поражаюсь логике разработчиков. Я сплошь и рядом сталкиваюсь с задачами, в которых их нужно 4-8 (именно независимых!).
Короче, вопросы-вопросы-вопросы. Буду связываться с этой конторой и уточнять.

Меня поразили некоторые фичи и в положительном плане. В частности, в информационных материалах материалах заявлено, что IT-предприятие стыкуется с большинством CAD и CAM-систем, позволяет по вновь разработанным технологическим модификациям скачивать BOM и технологический маршрут в базу системы из CAD/CAM. Обычно такую возможность имеют системы не самого хилого уровня.

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

AndrewIT2. Какие требования к персоналу (пользователи, программеры)
5. Какая СУБД ?
Если есть люди, владеющие Visual FoxPro, то им будет относительно просто освоить нюансы настройки системы. Поля, таблицы и т.п. - есть в сопроводительной документации. Грубая настройка производится визуальными средствами самого продукта, тонкая - вкручиванием FoxPro-шных макросов.
Продукт работает с MS SQL Server или с Oracle. В зависимости от того, какую СУБД вы выбрали, вам потребуется соответствующий специалист - DBA.

AndrewIT3. Какие требования к технике
В документации они были оговорены, но я не запомнил. Вообще-то, VFP-шные продукты достаточно тяжелые на подъем. Работают с SQL они через ODBC. В общем, обольщаться не стоит, имхо.

AndrewIT4. Что с поддержкой (ориентиовочная стоимость доработок, вызов спеца и пр.)
Видимо, озвучивать конкретные цифры без согласования со сторонами - участниками процесса, не совесм корректно. Поэтому скажу несколько расплывчато и неконкретно. Меня сумма впечатлила. С точки зрения своей доступности. Более дешевого продукта с озвученным функционалом я просто не видел. Относительно дешевые ERP-системы (уровня MAPICS - AXAPTA) стоят в 2,5 - 3 раза дороже. Стоимость поддержки сильно зависит от территориальных особенностей (насколько удобно часто засылать туда спецов). Насколько мне известно, сети предприятий, занимающихся внедрением-сопровождением этого продукта, нет. Внедрением занимаются консультанты самого IT-Предприятия. В связи с постепеным распуханием портфеля заказов у них уже началась напряженка с сопровождением (это слухи, в достоверности информации не уверен).

dichenko... чем так "плох" ODBC для связи с SQL-сервером?
Насколько мне известно, OLEDB работает быстрее. Хотя бы потому, что драйвер не производит излишней интеллектуальной промежуточной обработки информации, как это производится в ODBC. У меня такое предощущение, что обмусоливание данного вопроса может привести к флейму, совершенно не имеющему никакого отношения к сути вопроса. Давайте так, это моё ИМХО, я его никому не навязываю. Если есть непреодолимое желание все-таки схлестнуться, то хочу заметить, что данная тема уже неоднократно поднималась, в частности, на форуме по MS SQL. Вот, например, один из примеров баталии с лично моим участием и с участием именно VFP-шника, информация, касающаяся ODBC/OLEDB начинается отсюда (тред весьма длинный, и в нем затронуто еще много других вопросов).

dichenkoПоясните пожалуйста, чем VFP тяжел на подъем Я видел в инете опубликованную статистика по быстродействию различных алгоритмов, откомпилированных с использованием компиляторов C++, C#, Object Pascal и VB. VB оказался далеко впереди всех (в разы) по длительности выполнения этих тестов (то есть, по тормознутости). На отдельном инет-ресурсе видел сравнение быстродействия некоторых программ, написанных на VB и на VFP. Тут уже VFP уделал VB своими увесистыми тормозами. Видимо, логично предположить, что тормознутость VFP по сравнению с C++, C# и Object Pascal просто супервыдающаяся. Видел эти материалы довольно давно, искать честно говоря, неохота. Но если Вы сильно настаиваете, то могу пошукать. Только имеет ли смысл? Ужели Вы возьметесь утверждать, что VFP бьет по быстродействию C++, C# и Object Pascal?
И еще. Не воспринимайте меня как противника, если, конечно, сможете. Пожалуйста. Я ничего не имею против конкретно VFP. Более того, даже допускаю, что на нем при сильном желании можно сделать ERP-систему. Которая, не смотря на неоптимальность компилятора, может на практике иметь вполне приемлемое быстродействие. Если основная часть бизнес-логики отрабатывает на SQL-сервере, то некоторая приторможенность визуального интерфейса уже не столь существенна. Согласны?