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

[Ace of Database]

Цитата:

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

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

А я часто копи-пастю джобы, меняю в них Cust на Vend, Sales на Purch - и работает! Это как раз хороший, добрый программизм.

[macklakov]

Цитата:

Сообщение от Ace of Database

А я часто копи-пастю джобы, меняю в них Cust на Vend, Sales на Purch - и работает! Это как раз хороший, добрый программизм.

Самому не стыдно? Твой код приходится менять. Почему сразу не продумал все варианты? Ведь у тебя же есть иерархия. Мог бы объявить объект класса-родителя, инициировать конкретного наследника через factory, исходя из параметров. Ну и потом почему поленился, нормально, через SysOperation, делать? Ведь это гораздо более универсальный механизм чем jobs.

Цитата:

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

Я не против дублирования в принципе, просто оно должно быть обосновано.

А я не против "серьезных" программстских подходов. Паттерны, абстракции, обощения и т.д. Просто оно должно быть обосновано

[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 возникла. Как так получается?

Цитата:

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

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

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

[ta_and]

Цитата:

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

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

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