Z
Падажжи, так ты ут 10.3 привёл как пример хорошей архитектуры или плохой?
Как причину появления текущей архитектуры, потому что в ут 10.3 было не удобно.
Size: a a a
2021 March 11
АС
Механизмы корректировки данных отдельными документами. Рекомендую. Заодно и дисциплинирует пользователей хорошо.
а я делал цепочку из разных документов регистрацию - корректировку-подтверждение-корректировку-корректировку подтверждение-закрытие. Не сказать, что прям сильно кого то там дисциплинировала
ПМ
Дмитрий
Ну значит он не должен быть документом. Но и справочником ему быть не с руки, значит в платформе не хватает объекта, имеющего жизненный цикл.
Чем плохо коммерческое предложение?, поддерживает несколько версий, согласование. Уже после утряски всех моментов преобразуется в один или несколько заказов.
Z
С архитектурной точки зрения и там и там все хорошо. С точки зрения пардигмы, в ут 11 не по канону. Зато в ут 11 удобно, а в ут 10.3 нет.
NG
С архитектурной точки зрения и там и там все хорошо. С точки зрения пардигмы, в ут 11 не по канону. Зато в ут 11 удобно, а в ут 10.3 нет.
Погоди. Ты же сам говоришь, что подход ут 10.3 позволяет делать резервы в минус. Это же дыра. Как это может быть хорошей архитектурой?
Д
Чем плохо коммерческое предложение?, поддерживает несколько версий, согласование. Уже после утряски всех моментов преобразуется в один или несколько заказов.
Не смотрел, а кто это и как поддерживает? [она в ЕРП 2.4 есть, или только в 2.5 или вовсе в УХ ] У нас то вся ерунда с утрясаниями и версиями в ДО, то есть на справочниках.
Z
Погоди. Ты же сам говоришь, что подход ут 10.3 позволяет делать резервы в минус. Это же дыра. Как это может быть хорошей архитектурой?
Это возникает изза того что нужно четко настраивать систему прав на внедрении, а франчи это делать не хотели, в итоге маленькие компании не имеющие штатных программистов страдали.
ПМ
Дмитрий
Не смотрел, а кто это и как поддерживает? [она в ЕРП 2.4 есть, или только в 2.5 или вовсе в УХ ] У нас то вся ерунда с утрясаниями и версиями в ДО, то есть на справочниках.
Во всех типовых ут есть.
NG
Это возникает изза того что нужно четко настраивать систему прав на внедрении, а франчи это делать не хотели, в итоге маленькие компании не имеющие штатных программистов страдали.
Почему типовые профили и роли доступа содержат возможность редактировать данные задним числом и при этом есть возможность привести данные в неконсистентное состояние? Причём тут конкретное внедрение? Это должно быть в коробке
Z
Почему типовые профили и роли доступа содержат возможность редактировать данные задним числом и при этом есть возможность привести данные в неконсистентное состояние? Причём тут конкретное внедрение? Это должно быть в коробке
в ут 10.3 не было профилей.
NG
в ут 10.3 не было профилей.
Да не важно. Там были функциональные роли
Z
Основная причина в доступности неоперативного проведения, я думаю.
Д
Во всех типовых ут есть.
Да, не сталкивался с этой ФО. Почитаю, там смотрю много всего вокруг накручено.
ПМ
Дмитрий
Не смотрел, а кто это и как поддерживает? [она в ЕРП 2.4 есть, или только в 2.5 или вовсе в УХ ] У нас то вся ерунда с утрясаниями и версиями в ДО, то есть на справочниках.
Там в типовых одна особенность аналитика шапки партнер, а не юрлицо. соответственно очень хорошо идет кейс когда нужно зафиксировать цены/скидки на общий обьем, а факт заказы могут быть на разных юрлиц партнера. И а типовых док ни на что не влияет нет движений. Только согласование (до) соответственно допиливать
Д
Основная причина в доступности неоперативного проведения, я думаю.
Проблема была в том, что ради экономии секунд при восстановлении последовательности вообще зарубили контроль в неоперативном проведении, а не в том, что можно провести вчерашний документ.
В
1Сину любят именно (в том числе) за возможность ввода/изменения задним числом. Это одна из основных плюшек.
N
1Сину любят именно (в том числе) за возможность ввода/изменения задним числом. Это одна из основных плюшек.
Которую в том числе можно запретить в пользовательском режиме
В
Которую в том числе можно запретить в пользовательском режиме
Хозяин - барин. Хуже когда эта возможность отсутствует в информационной системе, как таковая.
N
Хозяин - барин. Хуже когда эта возможность отсутствует в информационной системе, как таковая.
Я говорю что эта возможность не только есть, но она ещё и гибко настраивается, что является ещё большим плюсом
ИШ
Как с помощью СКД сгруппировать по ресурсам виды ДС? То есть на верхнем уровне доход, расход и разница а в них виды ДС.