Оver-engineering - "зачем так сложно?"

[Raven Melancholic]

Клиенты-поставщики всего лишь небольшая часть проблемы классификации, выделения общих и различающихся признаков и совсем не являются уникальной проблемой не только Аксапты, но даже и не связанной вообще с ERP. Большинство знает афоризм про определение того, к какой науке относится явление (если зеленое, то.., если пахнет, то…).
Почему их разделили в разные справочники, а потом нарисовали код, который их обрабатывает как что-то похожее? Ну принято было такое решение, ему и следуют и нам тоже приходится следовать. Другие варианты были? Конечно были, многие в других системах видели реализацию других вариантов. Лучше другие варианты или хуже? В одних ситуациях лучше, в других хуже.
Достаточно давно встречал описание того, как определить является ли архитектор приложения профессионалом. Если на вопрос «как правильно реализовать вот эту штуку?» начинаются ответы, что «вот только так..», то это новичок, профессионал начнет свой ответ «это смотря с какой стороны посмотреть…».
Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.? Тем более, что один и тот же реальный контрагент может выступать в одних сделках как клиент, в других как поставщик, в третьих как акционер – вариантов множество.
Проблема в отсутствии какого-то единого подхода в разделении и объединении. Понятно, что управлять взаимоотношениями с клиентами, поставщиками, сотрудниками, акционерами это совсем разные задачи. Понятно, что есть какие-то общие задачи – те же взаиморасчеты (но со своими нюансами с каждой категорией).
Будет ли каждая категория выделена в отдельный справочник и реализованы механизмы обработки общих принципов в отдельном семействе классов с деталями, зависящими от справочника или все категории слиты в один справочник и разные механизмы будут основываться на типе договора или на каком-то другом признаке не особенно важно. Хотелось бы, чтобы подход в разных частях системы был единым. Если делаем сопоставление, что почему для клиентов/поставщиков механизм один, а для подотчетников другой? Можно сказать, что для последних есть отличия, но так они и для клиентов/поставщиков есть – почему тогда не разделили сопоставление для клиентов/потавщиков?

[ax_mct]

Цитата:

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

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

Одна шляпа - это программизм. Если бы и таблицы и код были отдельны и независимы всем было бы лучше. Кроме программистов которым больно смотреть на дублирование кода и данных.

Цитата:

Сообщение от Raven Melancholic

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

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

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

ООП должно быть подчинено процессу и обслуживать процесс.
Не контрагент.Действие(), а действие(Контрагент).
Никому не нужна общность отверстий кроме программистского мозга.
"Принимать пищу", "Усвоить пищу", "Выводить усвоенное" - реализация этих функций нужна, а не реализация "рот беззубый зеркальный". И сколько бы не было мнимого дублирования - если это повышает независимость и надёжность, то и замечательно.

[Raven Melancholic]

Цитата:

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

Программистский подход - искать общее, объединять.

Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

Линней, Менделеев, всемирная организация здравоохранения, международное агенство по атомной энергетике и прочие организации и люди, пытающиеся найти какие-то общине подходы к сложным задачам, которые были бы понятны многим и помогали бы им в работе это все программистские подходы?
ax_mct, чем лично Вам мешает жить таблица Менделеева? Чем могут Вам, учитывая Ваш бизнес, помешать какие-то правила, помогающие не только реализовать "сейчас" и получить деньги, а дальше "трава не расти", но и предусмотреть дальнейшее развитие, я понимаю. Но чем учет взаимосвязей разных процессов и объектов, когда контрагент.Действие(), а действие(Контрагент) только один из вариантов может помешать тем, кто работает в других условиях, я понять не могу.

Ответил в Курилке.
Оver-engineering - "зачем так сложно?" - Мортира Карл

Именно что программистский учет не должен отражать то чего нет в реальности. Дублирование кода - наименьшее зло.

Цитата:

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

[macklakov]

Цитата:

Сообщение от Raven Melancholic

.Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.? Тем более, что один и тот же реальный контрагент может выступать в одних сделках как клиент, в других как поставщик, в третьих как акционер – вариантов множество.

Вот именно! Само понятие контрагента, т.е. счета второй стороны сделки, действительно общее для всех процессов. Причем общее с точки зрения бизнеса.
А из-за того что такого понятия нет, в AX крайне поддерживать баланс контрагента крайне сложно. К примеру, если это компания-партнер, которая покупает товары, оказывает вам услуги, берет у вас в долг и держит на руках ваши акции. А еще они одалживают оборудование и дают свой товар на ответственное хранение. И вот мы должны посмотреть, кто чего и кому должен... И вот здесь все становится очень сложно. Без хитрых фреймворков такой функционал станет совершенно несопровождаемым.
Но причина-то ведь не в ООП! Причина в ошибках дизайна БД! Именно из-за того что структура таблиц неадекватно отражает бизнс-сущности, и возникает необходимость применять высший архитектурный пилотаж. Ярчайший пример, новая ГК, не к ночи будет помянута. Ради нее одной огромное количество новшеств в программную среду внесено. ГК это ведь такая простая вещь, по своей сути. В каждой второй смописке есть и почти никогда это не является bottleneck. Но у нас это чудовищный монстр, забивающий базу с экспоненциальной скростью, из-за чего система начинает тормозить уже на среднем объеме проводок.

[EVGL]

Цитата:

Сообщение от Raven Melancholic

Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.?

Не отличается. Вы уж извините за подотчетных лиц, грехи молодости, а нынешнее поколении локализаторов никак не вырежет их нафиг. В стандарте сотрудника можно ассоциировать с поставщиком и оплачивать за один проход. На текущем проекте сделал так, чтобы запись в таблице поставщиков создавалась автоматически, а синхронизация имени идет через ГАК. Аналогично, по государству = налоговому органу автоматически формируется задолженность в РсП.

Однако, задачи модулей РсП и РсК отличаются: в одном случае есть задача платить как можно позднее (все это казначейство, бюджеты и тп) а в другом - получить деньги как можно быстрее (инкассо, collections, cash flow). Поэтому смотреть на это как на одну сущность - это упрощение.