Цитата:
Сообщение от
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