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

[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

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

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

[EVGL]

Цитата:

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

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

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

Aging в AP - экзотика, но в балансе разделяют кратковременную и долговременную (дольше года) задолженность. Для этой реклассификации можно в теории использовать отчет.

[Vadik]

Цитата:

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

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

Это вопрос с подвохом ? Так же и затем же, что и в AR. "Оплати быстро и получи скидку", "кому, сколько и когда мы должны платить". По курсовым, я так понял, вопросов не возникло? Тогда предположу, что "искуственные иерархии сущностей" не такие уж и искуственные, и схожего в задачах реализуемых в AR и AP достаточно ? И (осторожно, крамола) даже возможно ограниченное применение ООП ?

Цитата:

Зачем такие аналитики нужны? Я вот видел системы где счета через черточку и AR это буквальным образом счет accounts receivable в ГК и один из сегментов это именно клиент

Клиент в качестве аналитики ГК - это один из способов разнообразить свою сексуальную жизнь в конце года при выверке GL с AR. Ну и отчасти признак качественного внедрения

Цитата:

Мне вся эта ситуация с новой ГК видится вот как. Купил мужик на ebay 2 велика

Ну вот, а 8 часов назад собирались AR с AP упразднять за ненужностью

Цитата:

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