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

[macklakov]

Цитата:

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

Соответственно пример со ртом и анусом мне непонятен и почему вендор - взят из реальности, а контрагент - нет тоже

В учете есть множество устоявшихся классификаций, которые просто надо отразить в системе и весе. Никакого аналитического подвига. В AR и AP общее это Accounts. Это просто счет 2-й стороны сделки. Иначе говоря конт-агент. Все просто. И в это понятие совершенно естественным образом попадают и сотрудники и арендаторы и даже банки.
Есди продолжать проводить аналогии с биологической классификацией, то oris и anus объединили по каким-то общим признакам, а вот нос, желудок, верхние и средние разделы кишечника, протоки желез в эту классификацию почему-то не попали. При этом физиологически они сделаны разными, а вот перифирийная нервная система из одного узла активируется.

[belugin]

Цитата:

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

В учете есть множество устоявшихся классификаций, которые просто надо отразить в системе и весе. Никакого аналитического подвига. В AR и AP общее это Accounts. Это просто счет 2-й стороны сделки. Иначе говоря конт-агент. Все просто.

Цитата:

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

Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию.

Я так понял концепция поменялась - не слишком много обобщили, а недостаточно обобщили?

[macklakov]

Цитата:

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

Я так понял концепция поменялась - не слишком много обобщили, а недостаточно обобщили?

Одновременно и слишком много и недостаточно. А все потому, что не было понимания, что и зачем обообщают.
В принципе, в древних системах, в CustTrans и VendTrans нужды вообще не было. Ты просто делаешь аналитику Клиент по этим счетам ГК и прямо оттуда можешь баллансы смотреть. В 2012-ю как раз этот допотопный механизм и притащили с таким героическими усилиями. Именно для этого и созданны все эти account structures. Заполняешь аналитику Customer в проводке, которая идет в AR счет. А дальше когда надо проводки по этому клиенту посмотреть, или балланс, прямо из ГК и берешь. Там даже сопоставление есть. А на AP счетах у тебя аналитика Vendor. Тоже все просто. Все можно делать тупо через журлал ГК с типом счета Ledger.
И вот в системе у нас ГК, которая делает CustTrans, VendTrans ненужными. Но и CustVendTrans тоже никуда не неделись. При этом TaxTrans почему-то в эту чудесную иерархию не попадают. И payroll тоже. И даже для банков у нас какой-то причудливый reconciliation, который, по сути дела, тот же settlement, только чудовищно кривой.
Т.е. как раз дублирования в коде и функционале выше крыши. И чтобы это дублирование поддерживать, приходится писать всякие феерические reconciliation reports. Количество дублирования только нарастает. Но при этом произвольные куски вдруг покрыты иерархиями. В то время как другие вполне себе отдельно живут.

[Vadik]

Цитата:

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

Одновременно и слишком много и недостаточно. А все потому, что не было понимания, что и зачем обообщают.
В принципе, в древних системах, в CustTrans и VendTrans нужды вообще не было. Ты просто делаешь аналитику Клиент по этим счетам ГК и прямо оттуда можешь баллансы смотреть. В 2012-ю как раз этот допотопный механизм и притащили с таким героическими усилиями. Именно для этого и созданны все эти account structures. Заполняешь аналитику Customer в проводке, которая идет в AR счет. А дальше когда надо проводки по этому клиенту посмотреть, или балланс, прямо из ГК и берешь. Там даже сопоставление есть. А на AP счетах у тебя аналитика Vendor. Тоже все просто. Все можно делать тупо через журлал ГК с типом счета Ledger

Скидки по оплате, просроченную дебиторку, курсовые, aging - смотреть будем тупо там же, в ГК ? А что, мне нравится. А то понапридумывают фреймворков-шмеймфорков непонятных

[macklakov]

Цитата:

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

Скидки по оплате, просроченную дебиторку, курсовые, aging - смотреть будем тупо там же

Отличный пример! Именно об этом я говорю. Все эти вещи к AP практически никакого отношения не имеют. Это чистый AR. Зачем было городить искуственную иерархию сущностей, между которыми общего столько же, сколько и почти с любым другим модулем?
И зачем было в ГК встраивать возможность вести учет в разрезе клиента или единицы номенклатуры, когда есть специализированные модули?

[Vadik]

Цитата:

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

Отличный пример! Именно об этом я говорю. Все эти вещи к AP практически никакого отношения не имеют. Это чистый AR

Вы ошибаетесь. "Все эти вещи" вполне себе используются в AP (возможно, не на Вашем проекте, но это уже частности)

Цитата:

И зачем было в ГК встраивать возможность вести учет в разрезе клиента или единицы номенклатуры, когда есть специализированные модули?

Это всего-навсего возможность создавать entity backed финансовые аналитики в 2012. Где Вы там увидели учет и что Вы в это понятие вкладываете?

Цитата:

Зачем было городить искуственную иерархию сущностей, между которыми общего столько же, сколько и почти с любым другим модулем?

Вы делаете глобального характера выводы на основе своих, достаточно частных и порой спорных, экспириенсов. Это их сильно девальвирует (да простят меня читающие за англицизмы)

[macklakov]

Цитата:

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

Вы ошибаетесь. "Все эти вещи" вполне себе используются в AP (возможно, не на Вашем проекте, но это уже частности)

скидки по оплате и aging? можешь описать как и зачем?

Цитата:

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

Это всего-навсего возможность создавать entity backed финансовые аналитики в 2012. Где Вы там увидели учет и что Вы в это понятие вкладываете?

Зачем такие аналитики нужны? Я вот видел системы где счета через черточку и AR это буквальным образом счет accounts receivable в ГК и один из сегментов это именно клиент. Очень сильно напоминает эти самые entity backed. И еще очень характерная технология это journal transfer. Т.е. проводки пишутся журналами и лишь потом, отдельной операцией, переносятся в ГК. Ничего не напоминает?
Т.к. мы заменяли эту замечательную систему на AX, нам даже требование впендюрили, наладить периодический перенос журналов. Что было с легкостью реализованно ибо у нас теперь есть синхронная, асинхронная и batch разноска. Вы все еще думаете это великий замысел, с целью разгрузить сервера? Такой великий замысел что пришлось покрыть каждый модуль reconciliation reports, чтобы проводки между модулями и ГК не слишком сильно расходились.

Цитата:

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

Вы делаете глобального характера выводы на основе своих, достаточно частных и порой спорных, экспириенсов. Это их сильно девальвирует (да простят меня читающие за англицизмы)

Это правда, мой опыт в последние годы ограничен диковатой колонией и несколькими варварскими странами.