Kashperuk Ivan: Microsoft Dynamics AX 4.0 data model overview

[gl00mie]

может, заодно, и переводчики заявят о себе?

[mazzy]

Людей было много.
Перевод выполнялся в рамках оплачиваемого проекта по заказу Майкрософта.
руководитель проекта со стороны Майкрософта - Вадим Корепин.
Вопросы о возможности публикации имен к нему.

[mazzy]

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

[MikeR]

Цитата:

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

может, заодно, и переводчики заявят о себе?

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

[Gustav]

Цитата:

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

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

Если предполагается второе издание текущего текста, то попадались какие-то грамматические ошибки, в т.ч. и в названиях полей, и в типах данных - т.е. в исходном англоязычном документе. Однако, внешнему неспециалисту-отчетнику будет неважно, на каком этапе подготовки текста была допущена ошибка - неверное имя поля приведет его к аварийной остановке. Впрочем, думается, что неспециалист-отчетник будет видеть таблицы и поля через СУБД и сообразит, что и как надо исправить.

В целом считаю, что перевод хорош и в текущем виде, ибо "разумному - достаточно" (а другие, наверное, и не собираются им пользоваться)

Есть некоторые концептуальные соображения по развитию документа (неважно кем - сотрудниками Microsoft или добровольцами AxForum'а):

1. Коль скоро документ позиционируется как предназначенный "для экспертов, которые хотят получить данные из таблиц для дальнейшего анализа и построения отчетов, но не являются специалистами в Microsoft Dynamics AX", т.е. доступ предполагается не через Аксапту, а напрямую через СУБД, то следует приводить SQL-названия полей таблиц (равно как и таблиц, если такие попадутся в будущем). Сегодняшний же пример: таблица TaxTable, поле RepFieldBaseUseTaxOffsetCreditNote (длина имени 34 символа, т.е. > 30) - вместо этого названия следует привести 30-символьное SQL имя: REPFIELDBASEUSETAXOFFSETCRED41, ну или для удобства восприятия в Pascal-нотации: RepFieldBaseUseTaxOffsetCred41.

2. Для России нужны существенные добавление по российской локализации. Неспециалист извне не сможет получить данные об основных средствах, если будет обращаться к таблицам, перечисленным в документе. Вместо этого нужны таблицы с префиксом RAsset.

[mazzy]

Цитата:

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

Если предполагается второе издание текущего текста, то попадались какие-то грамматические ошибки, в т.ч. и в названиях полей, и в типах данных - т.е. в исходном англоязычном документе. Однако, внешнему неспециалисту-отчетнику будет неважно, на каком этапе подготовки текста была допущена ошибка - неверное имя поля приведет его к аварийной остановке. Впрочем, думается, что неспециалист-отчетник будет видеть таблицы и поля через СУБД и сообразит, что и как надо исправить.

Как раз хотелось бы такие ошибки вычистить.

Цитата:

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

1. Коль скоро документ позиционируется как предназначенный "для экспертов, которые хотят получить данные из таблиц для дальнейшего анализа и построения отчетов, но не являются специалистами в Microsoft Dynamics AX", т.е. доступ предполагается не через Аксапту, а напрямую через СУБД, то следует приводить SQL-названия полей таблиц (равно как и таблиц, если такие попадутся в будущем). Сегодняшний же пример: таблица TaxTable, поле RepFieldBaseUseTaxOffsetCreditNote (длина имени 34 символа, т.е. > 30) - вместо этого названия следует привести 30-символьное SQL имя: REPFIELDBASEUSETAXOFFSETCRED41, ну или для удобства восприятия в Pascal-нотации: RepFieldBaseUseTaxOffsetCred41.

Хм... Не знаю. Если следовать этой логике, то придется писать два набора полей - для SQL и для Oracle. Названия могут различаться.

Цитата:

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

2. Для России нужны существенные добавление по российской локализации. Неспециалист извне не сможет получить данные об основных средствах, если будет обращаться к таблицам, перечисленным в документе. Вместо этого нужны таблицы с префиксом RAsset.

Да, поскольку у нас такое "отдельно-стоящее" приложение, то для его описания нужны отдельные усилия. И немалые. Этот вопрос обсуждался.

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

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

[Gustav]

Цитата:

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

Если следовать этой логике, то придется писать два набора полей - для SQL и для Oracle. Названия могут различаться.

Разве правило не более 30 символов в названии действует только для Oracle?

Ок. Можно не писать два набора, а приводить SQL-имя, например, в скобках. И только для тех полей, у которых AOT-имя и SQL-имя отличаются.

[mazzy]

Цитата:

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

Разве правило не более 30 символов в названии действует только для Oracle?

У Оракла, насколько я помню другое количество символов.
У MS SQL - 30 символов.
А у Oracle - 32 или 36. Не помню. Давно это было.

[Gustav]

У меня - Oracle. Поэтому за его 30 сиволов - "зуб даю"!

P.S. В русской книжке по 4-ке написано, что везде по 30 (стр.418 вверху).

[mazzy]

Цитата:

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

Вот что решил сделать для ВСЕХ.

не знаю что скажут остальные, но по-моему замечательная идея.
Давай спросим Майкрософт в лице Корепина и пусть будет html.
если и выкладывать, то по-моему, лучше сделать либо на сайте Майкрософт или в базе знаний http://erpkb.com.

[Vadim Korepin]

Цитата:

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

не знаю что скажут остальные, но по-моему замечательная идея.
Давай спросим Майкрософт в лице Корепина и пусть будет html.
если и выкладывать, то по-моему, лучше сделать либо на сайте Майкрософт или в базе знаний http://erpkb.com.

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