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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.06.2017, 19:04   #161  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от belugin Посмотреть сообщение
А мне всегда казалось, что это зеркальные части одного и того же процесса, просто видимые с разных точек зрения, ну ладно
Если бы Жаба программировала человека, то для рта и ануса она бы создала РотАнус, с общими функциями/свойствами
сжать - разжать, туда-сюда, молчит - говорит.
Ну и супер-предка - Отверстие.

Общего - до фига. А дублировать код - не по жабьи.
За это сообщение автора поблагодарили: S.Kuskov (5).
Старый 23.06.2017, 19:35   #162  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Мдя... это уже перебор.
__________________
полезное на axForum, github, vk, coub.
Старый 23.06.2017, 20:20   #163  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от mazzy Посмотреть сообщение
Мдя... это уже перебор.
Ну а как иначе сказать? Это не ругательство а наглядный пример так как с телом человека все знакомы. Рот - получаем еду, "зеркальный рот" - выводим. То же что и с Accounts "In" и "Out".
Масса общего если задуматься.

Ну и от лица той инопланетной жабы могу сказать что обьединение не с потолка взято, а из природы.
Вторичноротые.
https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%83%D1%81
У кишечнополостных и у плоских червей анальное отверстие отсутствует, у вторичноротых животных анальное отверстие развивается на месте первичного зародышевого рта.

По моему прекрасный пример абсурда моделирования когда мы не хотим дублировать код. Функция "Сжать" должна быть членом класса Отверстие. И так далее.

Последний раз редактировалось ax_mct; 23.06.2017 в 20:23.
Старый 23.06.2017, 20:46   #164  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ax_mct Посмотреть сообщение
По моему прекрасный пример
нет. как раз наоборот.
поинтересуйтесь, поизучайте.

например, https://www.youtube.com/watch?v=X6-DKuwHyjY
а также Висцеральная теория сна https://www.youtube.com/watch?v=2c7G_ml791w
и другие примеры оверинжиниринга в эволюции

только, пожалуйста, общие обсуждение оверинжиниринга - в специальную ветку
Оver-engineering - "зачем так сложно?" - Мортира Карл

ax_mct, давайте я сделаю предупреждение еще раз.
будете гадить в этой ветке, буду банить.

здесь тема про Аксапту
Оver-engineering - "зачем так сложно?"
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 23.06.2017 в 21:09.
Старый 24.06.2017, 11:26   #165  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от macklakov Посмотреть сообщение
в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие.
Я очень долго думал о причине разделения таблиц CustTable и VendTable.
Никак не мог для себя понять. ЗАЧЕМ было разделять таблицу контрагентов на две независимые таблицы.
Единственное, что меня успокоило и более или менее оправдало это решение - это разграничение прав доступа.
Ведь в Ах ранних версий настроить права доступа по записям было на два порядка сложнее, чем разграничить права доступа к разным таблицам.
Видимо только поэтому родились Cust и Vend вместо Contragent.
Ну а после того, как родился этот уродец с одним телом, но двумя головами, пошла поехала вся даунутая родня уродского семейства CustVend.
И Мапы таблиц придумали не от хорошей жизни, а как раз из-за необходимости одеть одну шапочку одновременно на две головы. (я ничего не имею против Мапов самих по себе. Решение интерфейсов к таблицам идеальное)

Последний раз редактировалось ta_and; 24.06.2017 в 11:33.
За это сообщение автора поблагодарили: macklakov (5).
Старый 24.06.2017, 13:24   #166  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Клиенты-поставщики всего лишь небольшая часть проблемы классификации, выделения общих и различающихся признаков и совсем не являются уникальной проблемой не только Аксапты, но даже и не связанной вообще с ERP. Большинство знает афоризм про определение того, к какой науке относится явление (если зеленое, то.., если пахнет, то…).
Почему их разделили в разные справочники, а потом нарисовали код, который их обрабатывает как что-то похожее? Ну принято было такое решение, ему и следуют и нам тоже приходится следовать. Другие варианты были? Конечно были, многие в других системах видели реализацию других вариантов. Лучше другие варианты или хуже? В одних ситуациях лучше, в других хуже.
Достаточно давно встречал описание того, как определить является ли архитектор приложения профессионалом. Если на вопрос «как правильно реализовать вот эту штуку?» начинаются ответы, что «вот только так..», то это новичок, профессионал начнет свой ответ «это смотря с какой стороны посмотреть…».
Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.? Тем более, что один и тот же реальный контрагент может выступать в одних сделках как клиент, в других как поставщик, в третьих как акционер – вариантов множество.
Проблема в отсутствии какого-то единого подхода в разделении и объединении. Понятно, что управлять взаимоотношениями с клиентами, поставщиками, сотрудниками, акционерами это совсем разные задачи. Понятно, что есть какие-то общие задачи – те же взаиморасчеты (но со своими нюансами с каждой категорией).
Будет ли каждая категория выделена в отдельный справочник и реализованы механизмы обработки общих принципов в отдельном семействе классов с деталями, зависящими от справочника или все категории слиты в один справочник и разные механизмы будут основываться на типе договора или на каком-то другом признаке не особенно важно. Хотелось бы, чтобы подход в разных частях системы был единым. Если делаем сопоставление, что почему для клиентов/поставщиков механизм один, а для подотчетников другой? Можно сказать, что для последних есть отличия, но так они и для клиентов/поставщиков есть – почему тогда не разделили сопоставление для клиентов/потавщиков?
За это сообщение автора поблагодарили: macklakov (5).
Старый 24.06.2017, 15:37   #167  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от ta_and Посмотреть сообщение
...Ну а после того, как родился этот уродец с одним телом, но двумя головами, пошла поехала вся даунутая родня уродского семейства CustVend.
И Мапы таблиц придумали не от хорошей жизни, а как раз из-за необходимости одеть одну шапочку одновременно на две головы. (я ничего не имею против Мапов самих по себе. Решение интерфейсов к таблицам идеальное)
Одна шляпа - это программизм. Если бы и таблицы и код были отдельны и независимы всем было бы лучше. Кроме программистов которым больно смотреть на дублирование кода и данных.

Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
...Проблема в отсутствии какого-то единого подхода в разделении и объединении. Понятно, что управлять взаимоотношениями с клиентами, поставщиками, сотрудниками, акционерами это совсем разные задачи. Понятно, что есть какие-то общие задачи – те же взаиморасчеты (но со своими нюансами с каждой категорией).
Будет ли каждая категория выделена в отдельный справочник и реализованы механизмы обработки общих принципов в отдельном семействе классов с деталями, зависящими от справочника или все категории слиты в один справочник и разные механизмы будут основываться на типе договора или на каком-то другом признаке не особенно важно. Хотелось бы, чтобы подход в разных частях системы был единым...
Программистский подход - искать общее, объединять. Если есть общие свойства, признаки, функции - должна быть иерархия, чтобы общее - в одном месте. В результате имеем монолит где большая часть наших усилий идёт на обслуживание нереальности объектных иерархий.

Объектный взгляд на мир когда объект.функциональность - он вреден в системе предоставляющей бизнес-функции.
Модуль Закупки - это Закупать.
Модуль Продажи - Продавать.
В модуле Закупаем нам не нужны клиенты, а только поставщики.
В модуле Продаём нам не нужны поставщики.
Модуль - это модуль.
Там где функции ценообразования в продажах нужна информация о поставщиках,
это функциональный вопрос, но не объектная общность по признакам.

ООП должно быть подчинено процессу и обслуживать процесс.
Не контрагент.Действие(), а действие(Контрагент).
Никому не нужна общность отверстий кроме программистского мозга.
"Принимать пищу", "Усвоить пищу", "Выводить усвоенное" - реализация этих функций нужна, а не реализация "рот беззубый зеркальный". И сколько бы не было мнимого дублирования - если это повышает независимость и надёжность, то и замечательно.
Старый 24.06.2017, 15:38   #168  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от ta_and Посмотреть сообщение
Я очень долго думал о причине разделения таблиц CustTable и VendTable.
Несомненно свысока своего опыта мы понимаем, что было бы лучше, что хуже.На мой взгляд просто перестраховались, так как вендор и кастер (ну предположим Вася Пупкин) совершенно разные единицы в управленческом и бухгалтерском учете.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 24.06.2017, 16:14   #169  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Программистский подход - искать общее, объединять.
Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.
Старый 24.06.2017, 16:40   #170  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.
Ответил в Курилке.
Оver-engineering - "зачем так сложно?" - Мортира Карл

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

Последний раз редактировалось ax_mct; 24.06.2017 в 16:43.
Старый 24.06.2017, 17:45   #171  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от Pustik Посмотреть сообщение
Несомненно свысока своего опыта мы понимаем, что было бы лучше, что хуже.
Не только мы. Ну не любят некоторые участники форума правил, наработанного опыта и т.п., но еще в 50-60 годах 20 века обсуждалось "правило жирафа".
"Спросите у специалистов, почему у жирафа такая длинная шея и получите много абсолютно правильных и обоснованных ответов, почему так получилось. А теперь спросите, раз это все так важно, то почему у жирафа шея длинная, а у зебры нет?" это должно быть помечено (С), но я не знаю чьим.
Старый 25.06.2017, 05:09   #172  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
.Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.? Тем более, что один и тот же реальный контрагент может выступать в одних сделках как клиент, в других как поставщик, в третьих как акционер – вариантов множество.
Вот именно! Само понятие контрагента, т.е. счета второй стороны сделки, действительно общее для всех процессов. Причем общее с точки зрения бизнеса.
А из-за того что такого понятия нет, в AX крайне поддерживать баланс контрагента крайне сложно. К примеру, если это компания-партнер, которая покупает товары, оказывает вам услуги, берет у вас в долг и держит на руках ваши акции. А еще они одалживают оборудование и дают свой товар на ответственное хранение. И вот мы должны посмотреть, кто чего и кому должен... И вот здесь все становится очень сложно. Без хитрых фреймворков такой функционал станет совершенно несопровождаемым.
Но причина-то ведь не в ООП! Причина в ошибках дизайна БД! Именно из-за того что структура таблиц неадекватно отражает бизнс-сущности, и возникает необходимость применять высший архитектурный пилотаж. Ярчайший пример, новая ГК, не к ночи будет помянута. Ради нее одной огромное количество новшеств в программную среду внесено. ГК это ведь такая простая вещь, по своей сути. В каждой второй смописке есть и почти никогда это не является bottleneck. Но у нас это чудовищный монстр, забивающий базу с экспоненциальной скростью, из-за чего система начинает тормозить уже на среднем объеме проводок.
__________________
Isn't it nice when things just work?

Последний раз редактировалось macklakov; 25.06.2017 в 05:27.
Старый 25.06.2017, 06:13   #173  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от ta_and Посмотреть сообщение
Ведь в Ах ранних версий настроить права доступа по записям было на два порядка сложнее, чем разграничить права доступа к разным таблицам.
Доступ на уровне записей и сейчас лучше не использовать. Быстродействие убивает. Дело в другом. Дело именно в увлеченностью ООП.
ООП прекрасный подход для написания всяких фреймворков и системных вещей. К примеру, drag-n-drop, на ООП выглядит очень красиво, элегантно и просто. Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться. Внедрять в бизнес-логику ООП, в то время как у тебя используется RDB, бессмысленно.
Но в AX пошли именно по пути ООП, это очевидно по ряду признаков. В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу. И в случае CustVend, у нас такой таблицы нет. Т.е. пляска идет не от базы, а от ООП. И именно эта общая стратегия привела к появлению сперва Maps, а потом уже и наследования таблиц. Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.
__________________
Isn't it nice when things just work?

Последний раз редактировалось macklakov; 25.06.2017 в 06:16.
За это сообщение автора поблагодарили: ax_mct (10), sukhanchik (5), Alexius (6).
Старый 25.06.2017, 16:19   #174  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от macklakov Посмотреть сообщение
Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться.
Точно, что для ERP главное это база данных? Разве не предметная область?
Когда я должен дать ответ по данным кассового чека, сколько покупатель может получить бонусов за эту покупку в зависимости от текущих акций, то какая разница получил ли я данные чека из базы, в которую он уже сохранен, получил ли этот чек прямым запросом из кассовой системы через Connector или получил его запросом через WEB сервис от консультанта торгового зала с планшета?
За это сообщение автора поблагодарили: macklakov (5), mazzy (2).
Старый 25.06.2017, 19:34   #175  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
...
Ответил в курилке.
Оver-engineering - "зачем так сложно?" - Мортира Карл
Старый 26.06.2017, 02:49   #176  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Точно, что для ERP главное это база данных? Разве не предметная область?
Предметная область в разы лучше реализуется всякими специализированными решениями. ERP обычно внедряют для того, чтобы повысить управляемость конторы в целом, а не для повышения эффективности операционистов (которого обычно не происходит). ERP это, своего рода, лекарство от болезней роста. Управляемость же достигается за счет консолидации информации, позволяющей строить разноплановую отчетность в реальном времени. Именно поэтому в маркетинге Dynamics такое значительное место занимает BI. Менеджмент хочет видеть что у них в конторе творится.
Т.е. если у на то пошло, то пляска идет даже не от базы, а от построителей отчетности. И я не знаю хороших построителей отчености по объектным базам данных, к примеру. А вот SAP, решили что им даже обычная RDB недостаточно, хороша, и потому запустили HANA.
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: mazzy (2), Raven Melancholic (2).
Старый 26.06.2017, 12:53   #177  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от macklakov Посмотреть сообщение
ООП прекрасный подход для написания всяких фреймворков и системных вещей. К примеру, drag-n-drop, на ООП выглядит очень красиво, элегантно и просто. Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться. Внедрять в бизнес-логику ООП, в то время как у тебя используется RDB, бессмысленно. Но в AX пошли именно по пути ООП, это очевидно по ряду признаков. В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу. И в случае CustVend, у нас такой таблицы нет. Т.е. пляска идет не от базы, а от ООП. И именно эта общая стратегия привела к появлению сперва Maps, а потом уже и наследования таблиц. Доминирует язык, а не база.
Что-то тема наследования таблиц никак не отпустит - давайте на минуту отвлечемся от нее. А как же журналы, которые есть в Аксапте с давних времен, когда и нормального ООП хотя бы с модификаторами доступа для методов в ней не было? Там тоже ООП не к месту? Может, надо было нашлепать по отдельной таблице на каждый тип журнала ГК и УЗ, а в разноске тупо копипастить общую логику?
А как же проводки в Управлении запасами, которые жили, не тужили в одном InventTrans'е, "обсчитываясь" двумя ортогональными иерархиями классов, реализующими всевозможные комбинации правил обновления статусов запасов с источниками этих обновлений? Там сколько разных таблиц надо было сделать, может, по одной на каждый источник (покупка, продажа, перенос, инвентаризация, списание в производство и т.п.)? А как надо было бы отвечать на вопрос, сколько товара на складе или откуда списать в резерв?..
Цитата:
Сообщение от macklakov Посмотреть сообщение
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно. Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.
А для чего именно SAP замутил свою HANA, неужели для упрощения кода системы, а не для повышения производительности и масштабируемости? Разве не работал он десятилетиями на РБД сторонних производителей и разве не на этих РБД он завоевал свою долю рынка? Или, может, он свою долю рынка завоевал не благодаря РБД, а вопреки?..
Цитата:
Сообщение от macklakov Посмотреть сообщение
Вот именно! Само понятие контрагента, т.е. счета второй стороны сделки, действительно общее для всех процессов. Причем общее с точки зрения бизнеса. А из-за того что такого понятия нет, в AX крайне поддерживать баланс контрагента крайне сложно.
Есть такое понятие - называется party, и справочник отдельный для всех-всех контрагентов есть. Если нормально связывать сущности из разных модулей (клиентов, поставщиков, сотрудников, etc) через party и строить отчеты вокруг нее, то всё получится. Только мне бизнес-пользователи почему-то рассказывали, что им и их контрагентам не интересен баланс "вообще", им интересен баланс в разрезе договоров и проч. И сопоставлять проводки "вообще" контрагенты не позволяют: платит, допустим, клиент за отгрузки и явным образом уточняет, что это вот за те две недельной давности, а не за три другие месячной давности. Удивительные люди...
Цитата:
Сообщение от macklakov Посмотреть сообщение
К примеру, если это компания-партнер, которая покупает товары, оказывает вам услуги, берет у вас в долг и держит на руках ваши акции. А еще они одалживают оборудование и дают свой товар на ответственное хранение. И вот мы должны посмотреть, кто чего и кому должен...
А у вас это в системе должно быть отражено: кто чего, кому и в каком разрезе должен Надо консолидированно - крутите отчеты, а не заставляйте систему суммировать теплое с мягким. Потому что условия везде разные, и зачастую нельзя просто так схлопнуть дебиторку за аренду с кредиторкой за отгрузки или с выплатами дивидендов - регулирование, арбитраж, ответственность, условия везде разные. Если же вы для себя хотите таким образом данные схлопнуть - крутите отчеты вокруг party.
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.?
Проклятое наследие прошлого Для модулей РСК и РСП были отгрузки и оплаты, было сопоставление проводок - вот кому-то и показалось, что можно выделить общую логику. Для модуля управления персоналом такого сопоставления не требовалось - вот и не выделили. А расчетов с акционерами, инвесторами и заемщиками исторически вроде и вовсе не было.
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Проблема в отсутствии какого-то единого подхода в разделении и объединении. Понятно, что управлять взаимоотношениями с клиентами, поставщиками, сотрудниками, акционерами это совсем разные задачи. Понятно, что есть какие-то общие задачи – те же взаиморасчеты (но со своими нюансами с каждой категорией). Хотелось бы, чтобы подход в разных частях системы был единым.
Пока что общий подход выливается во что-нить вроде Source Document Framework
Старый 26.06.2017, 13:07   #178  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Мне кажется, в Аксапте изначально всё довольно логично было спроектировано: вот есть отдельный модуль, у него есть свои основные сущности, есть движения по этим сущностям, есть журналы, которыми пользователям удобнее вводить информацию об этих движениях, есть запросы и отчеты, ну и еще настройки модуля. Далее, по ходу реализации выяснялось, что у модулей РСК и РСП много общего, а у других модулей - не так вроде много, поэтому ленивые программисты стали пытаться избавляться от копипаста и выносить общую бизнес-логику. Справочники так и не объединили, потому что по изначальной задумке они в каждом модуле - свои. Но общие вещи в итоге-таки вынесли в тот же ГАК.
Объективно ERP автоматизирует достаточно сложные сущности и процессы окружающего мира, и это определяет некий минимальный порог сложности самой системы. А разработка ПО крутится, с одной стороны, вокруг борьбы со сложностью, а с другой, - вокруг повторного использования кода. Две эти задачи неплохо решаются с помощью ООП, поэтому логично, что в Аксапте как сложной системе ООП используется достаточно широко и для борьбы со сложностью, и для повторного использования кода. Конечно, есть "перекосы на местах", конечно, кое-где выделение общей логики для повторного использования подчас сделано топорно и приносит больше проблем, чем пользы, особенно когда имеешь дело с методами в сотни строк кода. Но не стоит, по-моему, с водой выплескивать и ребенка, заявляя, что все проблемы Аксапты - от ООП.
Старый 26.06.2017, 16:10   #179  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Может, надо было нашлепать по отдельной таблице на каждый тип журнала ГК и УЗ, а в разноске тупо копипастить общую логику?
А почему нет? Если "нет" только потому что это не соответствует ООП и нежеланию копипастить, то да, лучше нашлепать и тупо копипастить общую логику.

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Конечно, есть "перекосы на местах", конечно, кое-где выделение общей логики для повторного использования подчас сделано топорно и приносит больше проблем, чем пользы, особенно когда имеешь дело с методами в сотни строк кода. Но не стоит, по-моему, с водой выплескивать и ребенка, заявляя, что все проблемы Аксапты - от ООП.
Проблемы Аксапты не от ООП как полезного инструмента, а от того что что вместо инструмента это стало религией для слишком многих. Любой код и таблицу можно "нормализовывать". Все знают о шести нормальных формах в проектировании БД,
но к сожалению таких четких форм нормальности/достаточности ООП - нет.

Мысль macklakov мне кажется очень интересной.
Цитата:
Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.
Старый 26.06.2017, 16:24   #180  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Да не в SQL все дело.
А в оторванности от практики людей, создающих прикладной код аксапты.

Делают вроде по науке, но не замечают той грани после которой наука побеждает здравый смысл и получается еще хуже чем было.
За это сообщение автора поблагодарили: gl00mie (2), macklakov (3).
Теги
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, время: 21:02.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.