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

[belugin]

Цитата:

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

Почему сразу не продумал все варианты?

Тут другое интересно, почему вообще возникла задача сделать одно и то же в двух модулях, между которыми нет НИЧЕГО общего. То есть у кастомера и вендора общего не больше чем у кастомера и пирожка с капустой

[macklakov]

Цитата:

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

Тут другое интересно, почему вообще возникла задача сделать одно и то же в двух модулях, между которыми нет НИЧЕГО общего. То есть у кастомера и вендора общего не больше чем у кастомера и пирожка с капустой

Это в жизни у них общего мало. А в системе очень даже много. Ведь с точки зрения системы это лишь отражения счетов в ГК. А у всех счетов ГК много общего друг с другом. У них есть дебет, кредит и балланс.
Девочки операционистки зачастую слишком необразованны чтобы оценить величие и изящество замысла. Когда им звонит клиент, он ожидают видеть баланс клиента, а не баланс на счету AR. И поэтому им каждый раз приходится долго втолковывать что инвойс делает счет клиента положительным, а платеж делает этот счет отрицательным. И все равно путаются какое-то время.
Да что говорить. Процесс закупки настолько отличается от клиентского возврата, что целый модуль procurement and sourcing наваяли. И одобрения платежей. На закупках часто бывает 3-х уровневое одобрение, а возврат клиенту делается на месте. Но при возврате важен исходный платеж. А в оплате покупки такого платежа не было вовсе.
Зато мы не какие-то там быдлокодеры, которые под клиента подстраиваются. У нас наследование и фреймворки. Все как у взрослых

[belugin]

Цитата:

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

Ведь с точки зрения системы это лишь отражения счетов в ГК. А у всех счетов ГК много общего друг с другом.

То есть есть что-то общее и есть кокретное подразделение, которому нужно это общее, правильно?

Цитата:

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

То что есть различия, тоже понятно

Так вы на вопрос не ответили, как возникла вообще потребность сделать одно и то же для двух вещей, между которыми НИЧЕГО общего.

[macklakov]

Цитата:

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

Так вы на вопрос не ответили, как возникла вообще потребность сделать одно и то же для двух вещей, между которыми НИЧЕГО общего.

А откуда этот вопрос проистекает? Где сказано что в бизнесе между этими процессами много общего? Ace of Database говорит что у него джобы зеркально выглядят. Но они зеркально выглядят потому, что в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие. То что можно отзеркалить, вообще не должно в этих таблицах находиться. Справочник адресов и справочник юр. лиц отдельные сделать и все. Никакой иерархии наследования. Никакого зеркалирования. Юр. лицо, это юр. лицо, независимо от того, поставщик это, клиент, сотрудник на контакте, субподрядчик по проекту или еще кто. Проводки и по поставщикам и по клиентам должны отражаться в ГК. Это общее. Но они совершенно по разному отражаются. Разная детализация, разный смысл. Платежи, как уже упоминал, совершенно по разному обрабатываются. Процесс разный, зачастую сопровождается разными документами. И поэтому вся эта иерархия CustVendOutPaym только под ногами путается.

[belugin]

Цитата:

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

А откуда этот вопрос проистекает? Где сказано что в бизнесе между этими процессами много общего? Ace of Database говорит что у него джобы зеркально выглядят. Но они зеркально выглядят потому, что в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие.

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

Вопрос такой: зачем вообще нужна потребность делато что-то одинаковое для закупок и заказов, если между ними нет ничего общего? Например, ко мне не может подойти начальник и сказать "испеки мне скорость и булочки с изюмом" просто потому, что для этих двуз понятий нет никакого общего смысла что-то делать. А вот для AR и AP возникла. Как так получается?

Цитата:

То что можно отзеркалить, вообще не должно в этих таблицах находиться. Справочник адресов и справочник юр. лиц отдельные сделать и все. Никакой иерархии наследования. Никакого зеркалирования.

С совершенно разной структурой или они должны отличаться только данными?

То есть в одном справочнике есть юридический адрес, а в другом на этом месте табуретка?

[mazzy]

Цитата:

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

Между таблицами клиента и поставщика много общего, соответственно очень много одинаковой логики и она дублируется.

На самом деле не очень. А то реально общее - не полностью реализовано.
поставщики и клиенты - это контрагнеты.

контрагенты бывают:
= юрики, физики, банки, государства
= клиенты, поставщики, субподрядчики, перевозчики, охрана, всевозможные брокеры, страховые, нотариусы и прочие третьи лица
и так далее.

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

контрагентов пытались получить на DirParty.
со всей вытекающей сложностью.

Цитата:

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

Чтобы избежать дублирования, изобрели Maps. Всю общую логику переместили в CustVend*. Очень элегантное решение, кстати.

будем справедливы:
1. maps изобрели не чтобы избежать, а чтобы хоть как то работать с дублированием.
2. не всю )
3. не очень элегантное. в стандартном функционале постоянно приходится писать if/switch... методы map имеют чудовищный синтаксис и очень плохо используются.

люди на проектах часто делают врапперы типа такого
https://github.com/mazzy-ax/SysCustVend

Цитата:

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

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

но это действительно разные процессы.

Цитата:

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

Вопрос такой: зачем вообще нужна потребность делато что-то одинаковое для закупок и заказов, если между ними нет ничего общего?

а нет такой потребности.
это просто техническое решение - сделать их похожими.

Цитата:

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

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

Чё это?
Зря ты принижаешь возможности начальника. ))))
Может конечно подойти и может сказать. Это твоя проблема как разработчика объяснить почему ты не будешь делать как начальник сказал ))))

Цитата:

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

То есть в одном справочнике есть юридический адрес, а в другом на этом месте табуретка?

да. у физика нет юридического адреса.

Цитата:

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

А вот для AR и AP возникла. Как так получается?
С совершенно разной структурой или они должны отличаться только данными?

Собственно это и есть тема этой ветки:
Оver-engineering - "зачем так сложно?"

[belugin]

Цитата:

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

среди действительно общих операций можно отметить только расчет курсовой разницы.

а также сугубо технические операции типа сопоставления дебет-операций с кредит-операциями.

То есть структура сущностей имеет что-то общее, операции существенно разные так?

В каком смысле сопоставление "техническая" операция?

Цитата:

будем справедливы:
1. maps изобрели не чтобы избежать, а чтобы хоть как то работать с дублированием.

"Как-то работать" это и есть в каком-то смысле избежать. Например избежать дублирование кода который как-то работает.

Цитата:

3. не очень элегантное. в стандартном функционале постоянно приходится писать if/switch... методы map имеют чудовищный синтаксис и очень плохо используются.

Почему вообще возникает потребность делать общий код, если общего мало? Почему просто не продублировать?

Цитата:

люди на проектах часто делают врапперы типа такого
https://github.com/mazzy-ax/SysCustVend

Они все оверэнжиниры?

Цитата:

а нет такой потребности.
это просто техническое решение - сделать их похожими.

Только что выше ты сказал, что потребность есть. Все мепы и классы и прочее.

Цитата:

да. у физика нет юридического адреса.

Мы говорим о разнице между AR и AP а не физиками и лириками. В АR у юрика есть юр адрес, а в AP нет?

Цитата:

Собственно это и есть тема этой ветки:
Оver-engineering - "зачем так сложно?"

Так я хотел, просто понять точку зрения как бы сделали если бы эти справочники были независимы.

[macklakov]

Цитата:

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

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

Не, ну в принципе да, процесс один. Только есть один маленький нюанс

Цитата:

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

Вопрос такой: зачем вообще нужна потребность делато что-то одинаковое для закупок и заказов, если между ними нет ничего общего?

Очень хороший вопрос. Ведь эти модули естественным образом расползаются, один в Procurement and Sourcing, а другой в Sales and Marketing. В чем тогда сермяжная правда двуединства Accounts Receivable и Accounts Payable? Может в слове Accounts?

Цитата:

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

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

Ну иерархию в DirParty сделали ведь. Значит и скорость испечь сможете. Технически вы отборные специалисты, лучшие на рынке. Значит справитесь.

[ax_mct]

Цитата:

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

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

Если бы Жаба программировала человека, то для рта и ануса она бы создала РотАнус, с общими функциями/свойствами
сжать - разжать, туда-сюда, молчит - говорит.
Ну и супер-предка - Отверстие.

Общего - до фига. А дублировать код - не по жабьи.

[ta_and]

Цитата:

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

в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие.

Я очень долго думал о причине разделения таблиц CustTable и VendTable.
Никак не мог для себя понять. ЗАЧЕМ было разделять таблицу контрагентов на две независимые таблицы.
Единственное, что меня успокоило и более или менее оправдало это решение - это разграничение прав доступа.
Ведь в Ах ранних версий настроить права доступа по записям было на два порядка сложнее, чем разграничить права доступа к разным таблицам.
Видимо только поэтому родились Cust и Vend вместо Contragent.
Ну а после того, как родился этот уродец с одним телом, но двумя головами, пошла поехала вся даунутая родня уродского семейства CustVend.
И Мапы таблиц придумали не от хорошей жизни, а как раз из-за необходимости одеть одну шапочку одновременно на две головы. (я ничего не имею против Мапов самих по себе. Решение интерфейсов к таблицам идеальное)

[Pustik]

Цитата:

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

Я очень долго думал о причине разделения таблиц CustTable и VendTable.

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

[Raven Melancholic]

Цитата:

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

Несомненно свысока своего опыта мы понимаем, что было бы лучше, что хуже.

Не только мы. Ну не любят некоторые участники форума правил, наработанного опыта и т.п., но еще в 50-60 годах 20 века обсуждалось "правило жирафа".
"Спросите у специалистов, почему у жирафа такая длинная шея и получите много абсолютно правильных и обоснованных ответов, почему так получилось. А теперь спросите, раз это все так важно, то почему у жирафа шея длинная, а у зебры нет?" это должно быть помечено (С), но я не знаю чьим.

[macklakov]

Цитата:

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

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

Доступ на уровне записей и сейчас лучше не использовать. Быстродействие убивает. Дело в другом. Дело именно в увлеченностью ООП.
ООП прекрасный подход для написания всяких фреймворков и системных вещей. К примеру, drag-n-drop, на ООП выглядит очень красиво, элегантно и просто. Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться. Внедрять в бизнес-логику ООП, в то время как у тебя используется RDB, бессмысленно.
Но в AX пошли именно по пути ООП, это очевидно по ряду признаков. В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу. И в случае CustVend, у нас такой таблицы нет. Т.е. пляска идет не от базы, а от ООП. И именно эта общая стратегия привела к появлению сперва Maps, а потом уже и наследования таблиц. Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.

[Raven Melancholic]

Цитата:

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

Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться.

Точно, что для ERP главное это база данных? Разве не предметная область?
Когда я должен дать ответ по данным кассового чека, сколько покупатель может получить бонусов за эту покупку в зависимости от текущих акций, то какая разница получил ли я данные чека из базы, в которую он уже сохранен, получил ли этот чек прямым запросом из кассовой системы через Connector или получил его запросом через WEB сервис от консультанта торгового зала с планшета?

[belugin]

Цитата:

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

В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу.

Насколько я знаю, это зависит от свойств данных и типичных запросов http://www.agiledata.org/essays/mapp...ingInheritance

Инфологическая модель не обязана отражаться в физическую один в один