1С++ Логика проведения по регистру, унинификация классом? #203730

В проведении документа по регистру есть своя четкая логика.По крайней мере для общих случаев остаточных регистров.Если так, то есть вариант сделать класс, который может унифицировать данную процедуру.Не хочется в очередной раз велосипед изобретать.......Есть ли у кого наработки/мысли/схемы?http://www.1cpp.ru/forum/YaBB.pl?num=1154087132

Наверное значительная часть 1С-ников всетаки исповедует процедурное программирование/мышление, а не объектное....И вопрос в этом случае не к месту.

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

ну например проверить дату запрета редактирования

Не предлагаю напрягаться, но логика есть, приведу здесь измышления.- набор типов движений четок: начисление/списание/регистрация- логика зависимости типа движения документа константно зависима.(потенциально)Вырисовываются условные области задачи:- Условия знака проведения (иерархичные, 3 уровня детализации, расписывать не буду);- Ресурсы проведения: итоги какого-то расчета, от которого зависит проведение;- Данные проведения: таблица данных, исходя из которой надо делать движения;- Ключи - условия сцепки "Ресурсов проведения" и "Данных проведения"- Опорный ресурс(ресурсы) - количество списываемого- Пропорциональные ресурсы: думаю объяснять не надо,- Пропорциональные реквизиты....ИМХО похоже на бред )ЗЫ: Философия - способ усложнить себе жизнь в попытке её упрощения )))

А не проще начать с оборотных регистров?

Представляешь себе только партионный учет?А если взаиморасчеты, например? Может не уложиться тудаИ выйдет ли проще?

Конечно проще.Просто я лентяй и мне надоело каждый раз писать эту эту задачу...Хочу найти логику и сделать унив. механизм....

Ну из 22 регистров в моей конфе 12 точно под такую гребенку расчесать можно. И это вобщем-то нормальный показатель...

не игня это все.....

Фигня, работать будет медленнее, чем штатные средства. Ибо давным давно домазано, что выигрыша от записи в регистр напрямую нет - это раз. И два - интерепретатор 1С добавит свои тормоза.

+10 "Универсальное не может быть хорошим" (с)

2А про прямую запись данных ни кто и не говорил, доказатель....

Оно может быть хорошим, но с разумными приростом сложности и потерей производительности. Если плата за повторное использование кода становится очень высокой, то лучше от нее отказаться. Если уж браться за подобную задачу, то не факт вообще, что целесообразно использовать регистры 1с, а не построить свои модели для учета остатков. А иначе получится "как корове седло"