Конфигурация - незначительно дописанная ТиС 9.2. Есть ли возможность в модуле проведения определить первый раз проводится документ или нет?
Можно конечно добавить реквизит документа типа "Новый", при ВводеНового() присваивать 1, а при проведении 0, но не хочется замусоривать ИБ. Может можно как-то иначе, что предложите?

В модуле проведения доступен метод Проведен(). При перепроведении возвращает 1, при проведении впервые - 0.

(0) зачем?

(1) А если предварительно документ сделали непроведенным, то метод вернет 0, а док уже не новый.

И что? Смысл метода по сути определить, есть ли у документа движения или нет. Может тебе лучше проверку на новый тогда делать?(3)

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

(4) проверку на новый в модуле проведения - это как?

Пока пробую следующее: в модуле формы создаю переменную "Новый", при ВводеНового() присваиваю 1. При записи документа если Новый=1 очищаю значение ЮрЛицо. В модуле проведения проверяю ЮрЛицо на пустое значение и далее по схеме "если пользователю можно" заполняю реквизит и провожу, иначе до свидания.

(7) (1) + ограничение на дату и нифига более не надо

(5) при открытии делай кнопку "Ок" - не доступной

(8) ещё раз по сути задачи - запретить после момента "Ч" текущего дня проведение НОВЫХ документов ("Заявки покупателей"), созданных на дату ТекущийДень + 1. Заявки, к сожалению, проводятся будущими датами.

(9) классная мысль!

9 обработкой проведут.


общий реквизит Счетчикпроведений.
в модуле проведения делай всегда +1.

(3) а нефиг его распроводить! Логично?

(7) можно еще три раза поменять склад. Сменить валюту на монгольские тугрики. А потом -на корейские воны.

В чём проблема - в заявке делаем поле шапки "проведена" - записываем туда "Y" в момент первого проведения и знаем, что если там есть "Y", то документ уже один раз проводился.
Так как пользователь может сохранить документ без проведения, а потом открыть его и провести - тогда документ уже явно будет не новый.

(15) Проблема в экономии. Я тоже не люблю реквизиты добавлять, но если надо так надо...
Можно сделать одну символьную переменную и через битмаску хранить там несколько состояний, но 100% потом потребуют отчет, который будет жутко тормозить.
ИМХО Лучше замусорить базу (хотя и не хочется) дополнением реквизита как сказано в (0).
З.Ы. не сильно то и замусорит...

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

(17) Конечно, у них они давно в управляемых формах копаются.
А тут людям работать надо - им некогда новшества изучать.

Лучше добавить набор реквизитов. Автор, редактор, ДатаСоздания, ДатаРедактирования. И полномочия новые от них можно завязать, и пользователям показать, и отчетик диагностический сделать...

(19) зачем так много?
Если есть подсистема логирования изменений (а у всех приличных людей, работающих на клюшках, она есть) - то там уже есть и момент создания, и моменты редактирований, и авторы соответсвующих действий.
если есть подсистема ролей (а она тоже есть у доброй половины клюшечников) - то полномочия явно уже определены.
остается прикрутить бизнес-процессы (состояние документов, и разрешенные для ролей переходы между состоянияями)

(18) тут сложный вопрос. Нужно ли _бизнесу_ "изучение новшеств в лице управляемых форм"? Даст ли это отдачу, и когда? сколько это будет стоить?
Сколько будет стоить "оставание" на текущей ИС, и чем это грозит в дальнейшем?
Ну и т.д.

(18) глупость какая-то.... при чем тут "управляемые формы" в принципе?

(20) > зачем так много?
У меня для скорости аналитики (20000+ документов в месяц), совместимости и простоты реализации (РБД, SQL/DBF, местами довольно тонкие и негарантированные каналы).
А ТСу для простоты. Если задаёт такие вопросы, скорее всего о подсистемах логгирования и ролей речи не идёт.

(10) Объясни менеджерам что в ЗаявкеПокупателя есть поле "ДатаОтгрузки" и не надо проводить заявки будущими датами.

Желание проводить документы будущими датами должно иметь вполне рациональное объяснение. Если такового нет - автор дятел, креатив не в тему.

(24) никакой необходимости проводить документы будущими датами нет. Ты это прекрасно знаешь и без меня.

(23) тююю 20 тыс документов в месяц - много, чтоль? у меня 130 было. до 7 в день

(26) Само по себе 20000 не много. А вот когда за несколько последних месяцев вдруг захотели анализировать, где документ оформился в "одно касание" текущей датой и больше не редактировался, а где разновсяческими задними числами создавался и редактировался - собирать и анализировать самодельные журналы изменений с учетом РБД+SQL/DBF уже не так быстро и просто.
Плюс, такой набор реквизитов даёт возможность быстро пользователю показывать "мои документы (по автору/редактору)", "историю документов (по автору/редактору и дате создания/редактирования)".
Конечно, хранение только последнего "редактора" накладывает свои ограничения на возможные отборы в журналах.

(27) да лехко!
функция каунт() на то и дана...

(28) А оно особо надо связываться, когда периферийки то SQL, то DBF? Местами просто двойной объём кода возникает, что бы твой каунт() через разные места заюзывать...

(29) не столь и много таких мест.