Выборка данных через AOS vs SQL Server

[sukhanchik]

Цитата:

Сообщение от fed

Так что фактически Микрософт под видом версии x.0 без сервис-паков выпускает бету и смотрит что получится.

А еще новый офис и Windows распространяется среди сотрудников МС, которых де-факто вынуждают тестировать эти продукты. А вот АХ к сожалению так не протестируешь.

А если МС хотя бы изнутри протестировал - он бы много багов нашел, о которых и не подозревал

[fed]

Цитата:

Сообщение от sukhanchik

А еще новый офис и Windows распространяется среди сотрудников МС, которых де-факто вынуждают тестировать эти продукты. А вот АХ к сожалению так не протестируешь.

А если МС хотя бы изнутри протестировал - он бы много багов нашел, о которых и не подозревал

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

[sukhanchik]

Цитата:

Сообщение от fed

По моему это беда любых ERP.

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

Другое дело - что у МСа АХ не единственная система (GP, SL, NAV еще есть).
Но при желании - придумать как протестировать ту же АХ вполне возможно.

[fed]

Цитата:

Сообщение от sukhanchik

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

Другое дело - что у МСа АХ не единственная система (GP, SL, NAV еще есть).
Но при желании - придумать как протестировать ту же АХ вполне возможно.

Можно. Но тогда мы протестируем бизнес-процессы только Microsoft В котором, ну например, нету серьезного производства, нету WMS, и вообще по большому счету даже и логистики серьезной нету...

[mazzy]

Цитата:

Сообщение от sukhanchik

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

Локальный - на Навике (по слухам).
В полном соответствии со своими же рекомендациями по выбору систем.

[sukhanchik]

Цитата:

Сообщение от fed

Можно. Но тогда мы протестируем бизнес-процессы только Microsoft В котором, ну например, нету серьезного производства, нету WMS, и вообще по большому счету даже и логистики серьезной нету...

Ну это уже лучше чем ничего. В целом - конечно согласен.

Цитата:

Сообщение от mazzy

Не зна-а-а-аю... За DirParty* и PrintMgmtSetup* просто убить готов... Руки кодерам/постановщикам оторвать...

Да я еще в сладких грезах в 4.0/3.0 . Хотя за этот многочисленный распил таблиц на более мелкие - тоже б руки оторвал.

Цитата:

Сообщение от mazzy

Локальный - на Навике (по слухам).
В полном соответствии со своими же рекомендациями по выбору систем.

Ну тогда АХ "попала" из-за того, что у МСа не одна система. Не могут же МСы работать сразу во всех системах, которые купили.

[mazzy]

Цитата:

Сообщение от sukhanchik

Хотя за этот многочисленный распил таблиц на более мелкие - тоже б руки оторвал.

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

В 2009 процесс пошел дальше. Готовься

[Ivanhoe]

Цитата:

Сообщение от mazzy

Локальный - на Навике (по слухам).
В полном соответствии со своими же рекомендациями по выбору систем.

Вроде бы, был пресс-релиз, что локальный кадровый учет и расчет ЗП на Dynamics AX сделан?

[mazzy]

Цитата:

Сообщение от Ivanhoe

Вроде бы, был пресс-релиз, что локальный кадровый учет и расчет ЗП на Dynamics AX сделан?

Хм... почти так. На Dynamics.
Вот только я не помню двух буковок "AX"

В общем, конечно в этом вопросе, возможно, я не прав.
Сразу так и написал - "по слухам".

[George Nordic]

Цитата:

Сообщение от sukhanchik

А ничто не мешает их использовать в собственной работе. Например, для сдачи собственной же отчетности в нашу (РФ) налоговую .
Пусть у локального офиса будет своя компания, а у штаб-квартиры - своя - посмотрим как там трансляция работает .Другое дело - что у МСа АХ не единственная система (GP, SL, NAV еще есть).

Корпоративной системой финансового учета в Microsoft является SAP. Это ни для кого не секрет. Как и то, что CRM - от Oracle (которому пытаются натянуть интерфейс от MS CRM, а впоследствии и полностью на него заменить)

Цитата:

Сообщение от mazzy

Хм... почти так. На Dynamics.
Вот только я не помню двух буковок "AX"

А вот зря - расчеты с персоналом как раз в Dynamics AX. Внедряли коллеги из АНД:

Цитата:

Проект внедрения решения на базе Microsoft Dynamics AX был реализован специалистами департамента консалтинга и технической поддержки корпоративных заказчиков Microsoft в России при поддержке компании «АНД Проджект» – партнера Microsoft по направлению Microsoft Dynamics. В рамках проекта были развернуты модули кадрового учета и расчета заработной платы Microsoft Dynamics AX, внедрена функциональность формирования и ведения штатного расписания, ведения персонифицированного учета в соответствии с требованиями российского законодательства, учета распоряжений по персоналу, хранения конфиденциальной информации о сотрудниках, расчета заработной платы и налогов с доходов сотрудников.

http://www.andproject.ru/news/162.html

С Уважением,
Георгий

[lev]

Скажу честно, для меня новость, что Microsoft Dynamics Ax тестируется не из аксапты, а внешними какими то программами
Все равно что тестировать ладу Калину, катаясь на БМВ

[fed]

Цитата:

Сообщение от lev

Скажу честно, для меня новость, что Microsoft Dynamics Ax тестируется не из аксапты, а внешними какими то программами
Все равно что тестировать ладу Калину, катаясь на БМВ

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

[mazzy]

Цитата:

Сообщение от fed

По секрету тебе скажу - все системы автоматизированного тестирования являются внешними программами

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

будет ли это внутренней программой (ключевое слово select, класс query на том же самом AOS, запись логов из AOS в отдельную базу как в TraceParser) или внешней программой - не важно. Важен механизм доступа (select/query - один механизм, прямой запрос/connection - другой механизм).

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

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

но чего ни в коем случае не должны делать разработчики - придумывать совсем другой механизм доступа к данным!

[lev]

Цитата:

Сообщение от mazzy

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

полностью согласен! ведь народ который использует эту программу, пользуется механизмами, которые написаны в самой аксапте, на Х++. А не внешними программами, которые написанны (+ ко всему) на других языках.
что собственно mazzy уже не в первом посте пытается донести!

[fed]

Цитата:

Сообщение от lev

полностью согласен! ведь народ который использует эту программу, пользуется механизмами, которые написаны в самой аксапте, на Х++. А не внешними программами, которые написанны (+ ко всему) на других языках.
что собственно mazzy уже не в первом посте пытается донести!

С большим трудом представляю себе клиента или партнера, который, ну например, много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов
Забудтье про клиентов и партнеров - это юнит-тесты. Такого на реальных внедрениях не бывает...

[mazzy]

Цитата:

Сообщение от fed

С большим трудом представляю себе клиента или партнера, который, ну например, много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов
Забудтье про клиентов и партнеров - это юнит-тесты. Такого на реальных внедрениях не бывает...

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

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

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

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

Если бы встроенный в Аксапту модуль unitTest умел бы работать именно так, то я был бы щастлив.

[lev]

Цитата:

Сообщение от fed

С большим трудом представляю себе клиента или партнера, который, ну например, много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов

Ну например розничная торговля:
Есть сеть магазинов, например 50, есть РЦ. В каждом магазине заказывается товар, возьмем например Масло подсолнечное. Соответственно у каждого магазина примерно известно кол-во потребляемого масла, и по потребностям магазина делается закупка на РЦ. При физ разноске закупки на РЦ автоматом формируются Заказы на Розничного клиента с разными складами (каждый склад, свой магазин).
Так как потребность у магазина постоянно примерно одинаковая (не считая сезонные всплески\падения по отдельным позициям), Вот и получается: "много раз, программным путем вставляет в таблички salesTable/salesLine фиксированный набор заказов для конкретных клиентов" как то так...

P.S. ещё добавлю. А если магазинов не 50, а 1000 и эти магазины разбиты по менеджерам по 100-штук например. То получаем что 10 пользователей одновременно для 1000 магазинов(клиентов) вставляют записи в таблички salesTable\salesLine

[fed]

Цитата:

Сообщение от mazzy

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


но чего ни в коем случае не должны делать разработчики - придумывать совсем другой механизм доступа к данным!

Обрати внимание - шаги 1 и 3 - это фактически тупое перенесение данных в таблички аксапты, грубо говоря, из Excel и последующее вынимание результирующих данных с целью сравнения с Excel. Какой сакральный смысл в использовании Аксаптовских мезанизмов для этой задачи ? Что мы проверим - генерацию recid, способность подставлять dataAreaId в записи, работу RLS ? Стоит ли гемор с работой через .net bc, столь скромных результатов ?
Все равно те данные которые мы читаем и пишем имеют мало отношения к реальности и мало чего позволяют оттестировать. Это же юнит-тест, просто ловушка для глупых ляпов. Тупо табличку записали, потом тупо прочитали...
Комплексного тестирования юнит-тесты не заменяют, и смысла из юнит-теста пытаться сделать универсальный тест и для ядра и для .net bc и для злосчастной логистики я не вижу...
Просто по хорошему после юнит-тестов время от времени должен проходить комплексный тест (уже не автоматический), а живыми людми делаемый. И боюсь как раз с этим-то в разработке аксапты и нехорошо....

[mazzy]

Цитата:

Сообщение от fed

Обрати внимание - шаги 1 и 3 - это фактически тупое перенесение данных в таблички аксапты, грубо говоря, из Excel и последующее вынимание результирующих данных с целью сравнения с Excel. Какой сакральный смысл в использовании Аксаптовских мезанизмов для этой задачи ?

Ты перечитай какие параметры должны учитываться в этом "тупом перенесении данных" и "тупом вынимании"
Выборка данных через AOS vs SQL Server

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

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

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

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

[kashperuk]

Цитата:

Сообщение от sukhanchik

А еще новый офис и Windows распространяется среди сотрудников МС, которых де-факто вынуждают тестировать эти продукты. А вот АХ к сожалению так не протестируешь.

А если МС хотя бы изнутри протестировал - он бы много багов нашел, о которых и не подозревал

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