AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.06.2017, 17:41   #181  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.?
Не отличается. Вы уж извините за подотчетных лиц, грехи молодости, а нынешнее поколении локализаторов никак не вырежет их нафиг. В стандарте сотрудника можно ассоциировать с поставщиком и оплачивать за один проход. На текущем проекте сделал так, чтобы запись в таблице поставщиков создавалась автоматически, а синхронизация имени идет через ГАК. Аналогично, по государству = налоговому органу автоматически формируется задолженность в РсП.

Однако, задачи модулей РсП и РсК отличаются: в одном случае есть задача платить как можно позднее (все это казначейство, бюджеты и тп) а в другом - получить деньги как можно быстрее (инкассо, collections, cash flow). Поэтому смотреть на это как на одну сущность - это упрощение.
Старый 26.06.2017, 18:19   #182  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Угу, тем более что контрагент может быть одновременно и поставщиком, и покупателем.

С Уважением,
Георгий
Старый 26.06.2017, 23:22   #183  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от macklakov Посмотреть сообщение
В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу.
Насколько я знаю, это зависит от свойств данных и типичных запросов http://www.agiledata.org/essays/mapp...ingInheritance

Инфологическая модель не обязана отражаться в физическую один в один
Старый 27.06.2017, 02:18   #184  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от belugin Посмотреть сообщение
Насколько я знаю, это зависит от свойств данных и типичных запросов http://www.agiledata.org/essays/mapp...ingInheritance
Так об том и речь, что "Mapping Objects to Relational Databases". Моя же точка зрения состоит в том, что более практично было бы делать mapping в другую сторону. Базу данных отражать в объекты. Просто потому, что конечной целью внедрения является отчетность. А отчетность берется из базы. А т.к. в качестве базы у нас, волевым усилием, назначен SQL, то вся суть разносок в том, чтобы заполнить таблицы, по которым удобно и быстро строить разноплановые отчеты.
Цитата:
Сообщение от gl00mie Посмотреть сообщение
А для чего именно SAP замутил свою HANA, неужели для упрощения кода системы, а не для повышения производительности и масштабируемости?
Насколько знаю, они замутили HANA для упрощения построения кубов. Т.е. немцы наладились ружья с казенной части заряжать, вместо того чтобы развивать технологию изготовления кирпичной крошки для чистки стволов.
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Только мне бизнес-пользователи почему-то рассказывали, что им и их контрагентам не интересен баланс "вообще", им интересен баланс в разрезе договоров и проч.
Ну так если вы в рамках отдельного договора работаете, то вам и стандартные Cust и Vend баллансы все равно не особо нужны. Смысл все это городить
С другой стороны, очень простой, жизненный, пример. Сотрудник покупает у родной конторы товар в счет будущей зарплаты...
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Если же вы для себя хотите таким образом данные схлопнуть - крутите отчеты вокруг party.
Отчеты кручу не я, а команды BI или DW. А они просто рыдают при виде party и ledger.
Вот party это как раз яркий признак того, что люди не очень понимали что и зачем они делают. С одной стороны, это как раз логичная попытка создать единый справочник экономических субъектов. В другой стороны, мотивация его создания была чисто техническая, без привязки к бизнесу. Наворотили иерархию, а балланса-то и нет. Даже регистрационные данные туда не перенесли, они так и остались на Cust и Vend. Т.е. лучше чем ничего, но попотеть приходится.
Цитата:
Сообщение от gl00mie Посмотреть сообщение
А как же проводки в Управлении запасами, которые жили, не тужили в одном InventTrans'е, "обсчитываясь" двумя ортогональными иерархиями классов, реализующими всевозможные комбинации правил обновления статусов запасов с источниками этих обновлений? Там сколько разных таблиц надо было сделать, может, по одной на каждый источник (покупка, продажа, перенос, инвентаризация, списание в производство и т.п.)?
Да, по логике CustVend так и выходит. Раскидать InventTrans на несколько таблиц, но некоторые из них покрыть иерархией объектов (ибо како-то сходство наблюдается), а остальные оставить сами по себе т.к. сходства не заметили или руки не дошли. А кому надо консолидированно наличие на складе посмотреть, пусть пользуют DirInventory
__________________
Isn't it nice when things just work?

Последний раз редактировалось macklakov; 27.06.2017 в 04:09.
Старый 27.06.2017, 04:32   #185  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от gl00mie Посмотреть сообщение
крутите отчеты вокруг party.
это, кстати, как раз рождение в муках велосипеда под названием "контрагент". Просто люди никогда велосипеда не видели и не знают зачем нужны велосипеды. Поэтому инженерный процесс непростыми путями следует.
__________________
Isn't it nice when things just work?
Старый 27.06.2017, 07:06   #186  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от macklakov Посмотреть сообщение
Так об том и речь, что "Mapping Objects to Relational Databases". Моя же точка зрения состоит в том, что более практично было бы делать mapping в другую сторону. Базу данных отражать в объекты.
Почитайте что там внутри объектовые свойства не используются те же рассуждения применимы при проектировании физической модели где нет наследования по логической где есть.
Старый 27.06.2017, 07:43   #187  
BIDeveloper is offline
BIDeveloper
Участник
 
26 / 11 (1) +
Регистрация: 27.11.2016
Цитата:
Сообщение от macklakov Посмотреть сообщение
Просто потому, что конечной целью внедрения является отчетность. А отчетность берется из базы. А т.к. в качестве базы у нас, волевым усилием, назначен SQL, то вся суть разносок в том, чтобы заполнить таблицы, по которым удобно и быстро строить разноплановые отчеты.
Не так все просто ) Для ERP ещё важно, чтобы одновременно сотни/тысячи пользователей могли вставлять/обновлять быстро и без блокировок множество записей. И для этого как раз лучше подходит более нормализованная модель. То, что в Аксапте кубы настраивались прямо на рабочую базу - это исключение из правила ) Обычно для dwh делают отдельную, более денормализованную базу.
Старый 27.06.2017, 08:06   #188  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от BIDeveloper Посмотреть сообщение
И для этого как раз лучше подходит более нормализованная модель.
Ну и по какой форме у нас нынче DirParty нормализована?
__________________
Isn't it nice when things just work?
Старый 27.06.2017, 19:32   #189  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
У меня сейчас одна из задач в AX2012 обеспечить установку primary vendor на уровне site в разрезе customer/customer group.

ООП вроде бы крутое везде и всюду с наследованием контрактов и прочим, а мне надо искать и заменять все вхождения inventTable.PrimaryVendor на что-то типа salesLine.getPrimaryVendor().

ООП надо чтобы salesLineType.getPrimaryVendor() то есть расширение конкретной функциональности, а не затем чтобы переставлять технический код местами чтобы расчлененка была более кровавой.
При этом если бы не было в системе ООП вообще а было что-то типа процедурно getPrimaryVendor_SalesLine(salesLine) то я бы не плакал. И клиент не рыдал

То есть пользы от ООП в АX я не вижу, только вред.

Последний раз редактировалось ax_mct; 27.06.2017 в 19:35.
Старый 27.06.2017, 19:43   #190  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Цитата:
Сообщение от ax_mct Посмотреть сообщение
ООП вроде бы крутое везде и всюду с наследованием контрактов и прочим, а мне надо искать и заменять все вхождения inventTable.PrimaryVendor на что-то типа salesLine.getPrimaryVendor().
Это значит, что не всюду вот в этом конкретном месте (в таблицах) нет инкапсуляции.
Старый 27.06.2017, 19:46   #191  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от macklakov Посмотреть сообщение
Вот party это как раз яркий признак того, что люди не очень понимали что и зачем они делают. С одной стороны, это как раз логичная попытка создать единый справочник экономических субъектов. В другой стороны, мотивация его создания была чисто техническая, без привязки к бизнесу. Наворотили иерархию, а балланса-то и нет. Даже регистрационные данные туда не перенесли, они так и остались на Cust и Vend. Т.е. лучше чем ничего, но попотеть приходится.
Нет, протестую. На одном проекте на AX2009 по требованию клиента (международный концерн) пришлось шагнуть еще дальше чем DirParty-2017, а именно ввести компанейно-зависимую роль адреса. Когда один multinational поставляет другому multinational, и дело происходит в Европе, где 2 столицы находятся на расстоянии 60 км, то одного и того же клиента могут обслуживать несколько юрлиц концерна, которые еще и состоят во внутрихолдинговых отношениях друг с другом. Возникает проблема синхронизации справочников между компаниями и даже автоматического перевода названия города с одного языка на другой как в AX7. Регистрационные данные, кстати, теперь частично перенесли, но непрактично (пытался объяснить PM'ам в московском центре разработки, почему, но был не понят).
За это сообщение автора поблагодарили: gl00mie (2).
Старый 28.06.2017, 02:08   #192  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от EVGL Посмотреть сообщение
Нет, протестую.
Не понял, протестуешь против возможности посмотреть общий баланс по контрагенту?
__________________
Isn't it nice when things just work?

Последний раз редактировалось sukhanchik; 28.06.2017 в 08:02.
Старый 28.06.2017, 11:09   #193  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от macklakov Посмотреть сообщение
Не понял, протестуешь против возможности посмотреть общий баланс по контрагенту?
Нет, протестую против "мотивация его создания была чисто техническая, без привязки к бизнесу".
Старый 28.06.2017, 12:57   #194  
Morpheus is offline
Morpheus
Участник
Аватар для Morpheus
Соотечественники
 
602 / 164 (7) ++++++
Регистрация: 30.03.2005
Адрес: Київ-København-Düsseldorf
Цитата:
Сообщение от ax_mct Посмотреть сообщение
То есть пользы от ООП в АX я не вижу, только вред.
Методы, содержащие по несколько тысяч строк, написаны разделяющими Ваше мнение людьми.
Старый 28.06.2017, 13:10   #195  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от EVGL Посмотреть сообщение
Нет, протестую против "мотивация его создания была чисто техническая, без привязки к бизнесу".
Значит я неправильно донес мысль. Что DirParty выделили это хорошо и правильно. Но то как ее реализовали, вызывает сомнения в том, что присутствовало отчетливое понимание.
__________________
Isn't it nice when things just work?
Старый 29.06.2017, 08:35   #196  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
642 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
Если подумать, то и наследование таблиц - также over-engineering. При нормализации таблиц уже до 3-й формы наследование излишне. У меня когда-то лет 7 назад была идея, а что если у таблиц сделать наследование полей, как в ООП... начал ковырять и пришел к нормализации таблицы :-)
__________________
// no comments
За это сообщение автора поблагодарили: Ace of Database (2).
Старый 29.06.2017, 09:02   #197  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
642 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
Цитата:
Сообщение от ax_mct Посмотреть сообщение
При этом если бы не было в системе ООП вообще а было что-то типа процедурно getPrimaryVendor_SalesLine(salesLine) то я бы не плакал. И клиент не рыдал

То есть пользы от ООП в АX я не вижу, только вред.
Технически код
X++:
vendor = salesLine.getPrimaryVendor();
трактуется компилятором так:
X++:
vendor = SalesLine::getPrimaryVendor(salesLine);
где SalesLine тупо работает как scope, т.е. область видимости, а salesLine - табличная переменная.
сам метод интерпретируется как
X++:
public VendTable getPrimaryVendor(SalesLine _salesLine)
{
;
    this = _salesLine;
    ...
}
Работа с this происходит неявно и нам удобнее работать с меньшим числом параметров. Но дело не в этом.
ООП предназначено для другого: наследование, инкапсуляция и полиморфизм. Не будь наследования, мы бы погрязли в дублировании кода. Полиморфизм позволяет работать с базовым классом, и не держать руку на пульсе, каждый раз спрашивая себя, а с функцией какой сущности (то бишь класса) я работаю?
Вот инкапсуляция - это да, она конкретно не доработана. Очень не хватает свойств, хотя методы доступа get/set/parm есть, но с ними не так удобно.
__________________
// no comments
Старый 29.06.2017, 09:15   #198  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от dech Посмотреть сообщение
Если подумать, то и наследование таблиц - также over-engineering. При нормализации таблиц уже до 3-й формы наследование излишне
мне кажется, это была попытка сначала нормализовать структуру данных "правильно, по тру-программистски", а когда стало очевидно что любое обращение к ней требует соединения дюжины-двух таблиц - материализовать эту структуру. Правильно это или нет - сказать сложно. В AOT смотришь - вроде удобно и логично, в DirPartyTable в БД - кровавое месиво какое-то. Но в целом - работает
__________________
-ТСЯ или -ТЬСЯ ?
Старый 29.06.2017, 09:43   #199  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
642 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
Цитата:
Сообщение от Vadik Посмотреть сообщение
мне кажется, это была попытка сначала нормализовать структуру данных "правильно, по тру-программистски", а когда стало очевидно что любое обращение к ней требует соединения дюжины-двух таблиц - материализовать эту структуру. Правильно это или нет - сказать сложно. В AOT смотришь - вроде удобно и логично, в DirPartyTable в БД - кровавое месиво какое-то. Но в целом - работает
Я бы посмотрел в сторону View, но они в аксапте как-то не очень активно используются, например по сравнению с WEB-системами. Если глянуть тот же Wordperss или Drupal, там вьюхи используются чуть ли не чаще, чем сами таблицы. Да и поддержка на уровне БД. Тем более, что обычно нужны не все поля, а некоторый набор. Другое дело, когда на разные нужды требуются разные наборы полей.
__________________
// no comments
За это сообщение автора поблагодарили: ta_and (4).
Старый 29.06.2017, 09:50   #200  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
По моему, главная проблема с наследованием таблиц в Ax - это решение о том что родитель содержит в себе все поля всех наследников. Из за этого им пришлось в ранних версиях автоматически делать outer join родителя ко всем наследникам, а в поздних версиях - просто складывать все поля наследников в одну большую таблицу-родителя.
В классической системе мэппинга объектных отношений в реляционную БД, обращение к таблице наследнику, неявно делает inner join с таблицей родителем. В обращение к родителю ни к каким автоматическим join не приводит. Из за того что MS решил пойти своим путем, использование наследования привело к большому оверхиду - либо из за джойнов, либо из за тучи неиспользуемых полей в таблице.
За это сообщение автора поблагодарили: Vadik (1).
Теги
sysoperation framework

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: The INSERT statement conflicted with the FOREIGN KEY constraint "FK_ModelElementData_HasModelId_LayerId". The conflict occurred in database "YourDataBaseName_model", table "dbo.Model" Blog bot DAX Blogs 0 23.05.2014 13:11
Dynamics AX Sustained Engineering: Performance issue in "Open Transaction Edit" form Blog bot DAX Blogs 0 26.10.2009 20:05
Зачем нужны "Параметры кодов аналитики"? Кирилл DAX: Программирование 2 16.04.2004 14:22
Зачем нужна "Потребность в номенклатуре" Tony Green DAX: Функционал 4 02.02.2004 00:24
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:39.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.