круто.. и во всех табличках поле date_time_iddoc меняли ?
)

ssv02 писал(а) 26. Августа 2011 :: 12:28:


Это потому, что время документа записывается после всех изменений и в момент фиксирования транзакции, т.е. после окончания процедуры "ОбработкаПроведения()". Если есть какое то событие, которое вызывается после обработки проведения - тогда можно менять, но надо быть осторожным, потому что придеться менять во всех регистрах где есть быстрая обработка движений + константах + бух. операциях с соответствующим пересчетом итогов.

Какой-то хней маешься, имхо.
Цель в целом, какая ?

ЗЫ: помимо оперативного учета, есть еще бух учет - там тоже позицию дока (date_time_iddoc) нужно будет менять во всех табличках.

Eprst писал(а) 31. Августа 2011 :: 05:01:



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


Но тут недавно столкнулись с такой проблемой, что если документ относится только к бух контуру, то при его проведении в текущем числе (если он уже был ранее записан), док. проводится в том времени, в котором лежит. Таким образом если проводить док в том времени, в котором он лежит могут возникать ошибки с бухучетом, т.к. при проведении контролируется состояние определенных данных на бухучете, а, следовательно, возможность проведения документа. Объяснять все долго и муторно. Но если по аналогии с регистрами, то абстрактно есть партия товара, создали док. на списание и сохранили без проведения, создаем новый док. на списание и проводим, при этом списываем эту партию под 0. Затем открываем предыдущий док. и проводим: если провести его не по ТА, то контроль остатков даст наличие остатка и партия уйдет в минус, если док. проводится после ТА, то и контроль сработает и запретит списывать в минус.   Повторяю - это примерно абстрактное описание проблемы.

Так вот если док. имеет флаг оперативный учет, то в текущем дне он при проведении кладется в конец последовательности самим движком 1с, а если док не имеет флага оперативного учета (только бухгалтерский учет), то при проведении в текущем дне его время не меняется и он остается в том времени, в котором есть.

Попробовал применить ПослеЗакрытия() но по факту на данный момент времени объект еще заблокирован.

Может кто еще какую идею может подкинуть?

Идея по поводу контроля данных на момент документа и на ТА должна сработать, но она не очень подходит в данном случае. Там возникает несколько дополнительных ограничений и слишком много документов придется переделывать ОбработкуПроведения(). А так было бы просто добавить глобальную процедурку по перемещению документа в конец дня, а потом уже проведению документа. Но как это сделать из формы открытого документа при его закрытии и проведении никак придумать не могу.

Eprst писал(а) 31. Августа 2011 :: 11:54:

Если бы не было ошибок в БухУчете, то можно было бы и покласть.

ssv02 писал(а) 31. Августа 2011 :: 13:52:

Ну так и не пиши так, чтоб ошибки были.
Для бух компоненты всё равно, где у тебя документ в пределах дня.
Там нет партионки, где это важно. Там все останки на конец дня, как правило и по-средней.

Satans Claws писал(а) 01. Сентября 2011 :: 02:52:


Эта идея точно сработает и оставлена про запас как последний вариант. Скорее всего так и придется сделать. База за 100 гигов, но в принципе я придумал как все тормоза с обновлением обойти. Придется делать изменения на пустой БД, а в реальной данные ручками подправить. Там только правильно флаг в journ выставить напрямую в базе.