Всем привет! Не уверен, что пишу в правильный раздел, но я уже устал пытаться понять причину возникновения проблем, а похожей обсуждаемой темы не нашел.

Исходные данные: ИБ на базе бух 7.7 в формате SQL (2005), размер около 5-6 Гб, сильно переделанная на прямые запросы - в основном отчеты конечно, но также используются классы прямых бух.запросов при проведении документов. Запись данных в базу через прямые запросы почти не используется. Ну и еще из вероятно важного - юзеры частенько жалуются на тормоза при проведении больших объемов документов.

Проблема: периодически появляются "невидимые" документы, в подавляющем большинстве случаев - ручные операции, которые есть в базе, проведены, остатки в стандартных отчетах обычно правильные, но мои отчеты с прямыми запросами их не видят. Выяснение причины проблемы на одном конкретном примере показало что происходит - класс AccountsRecordset в условиях соединения для получения вида документа использует такое условие:

INNER JOIN _1SJOURN AS _1SJOURN_vt WITH (NOLOCK) ON (_1SENTRY_vt.DATE_TIME_DOCID = _1SJOURN_vt.DATE_TIME_IDDOC) 

Формально условие конечно правильное, но именно оно отсекает у меня нужные ручные операции, которые почему-то периодически меняют свое время... Это случается крайне редко, но в базе у меня есть такие операции, которые не только старые (2006 года), но и периодически возникают новые.

Вот такой простейший запрос выдает мне список таких операций:

select
   o.date_time_docid dto,
   j.date_time_iddoc dtj,
   o.docid [Документ $Документ],
   j.iddocdef Документ_вид

from _1SOPER o (NOLOCK)
   inner join _1SJOURN j (NOLOCK) ON j.iddoc = o.docid

where (j.date_time_iddoc <> o.date_time_docid)

order by o.date_time_docid 

И возвращает вот такой пример:

dto	dtj	Документ
20100601EAGG40  8RG9	20100601EAEAY8  8RG9	Операция 07722 (01.06.10)

Т.е. получается, что в журнале документов данный документ (ручная операция) имеет одно время, а в списке операций - другое... Почему такое происходит я не знаю, но примерно могу догадаться, проанализировав значение времени:

20100601EAEAY8 = 01.06.2010 23:59:59
20100601EAGG40 = 01.06.2010 23:59:59 + 10 секунд

Получается, что в журнале документов время правильное, т.к. оно не может быть больше 23:59:59, а вот в операции хранится неверное значение date_time_docid и откуда оно берется непонятно. Может быть пользователи пытаются сдвинуть время документа вперед на стандартный интервал +10 секунд? Или 1С это делает сама?
Кстати, если найти эту операцию, открыть и нажать "ОК", т.е. "перепровести", то проблема исчезает... Как-то раз при пересчете бух.итогов мне это вылилось в проблему на всю ночь - 1Ска пыталась вставить разные записи в таблицу _1SCRDOC с нарушением уникальности индекса по ID документа...

В общем вопрос такой - кто-нибудь с таким сталкивался? Не знаете причины возникновения и как исправить? Конечно самое простое - переделать класс AccountsRecordset и заменить условие соединение по DATE_TIME_DOCID на соединение просто по DOCID, но это не очень правильный вариант решения проблемы...

В конец дня документ ставят и всё..

Eprst писал(а) 10. Августа 2010 :: 07:33:

Один фиг позиция должна быть одинаковой.

Shtyr
Конкретно с этим не сталкивался, но документы в 23:59:59 в большом количестве часто приводят к неожиданным следствиям. Правильнее, IMHO, не допускать возникновения этой ситуации. Если это невозможно - прописать регламентное задание с командой UPDATE, исправляющей эту ошибку.

Ну или закрыть глаза на проблему и исправить AccountsRecordset, слегка выпав из индекса.

berezdetsky писал(а) 10. Августа 2010 :: 07:52:
А как можно этого не допустить? Запретить юзерам это на словах? Запретить ставить документы в конец дня? Примерный анализ показал, что все так и есть примерно - большинство глючных доков приходятся на самые нагруженные даты - начало и конец месяца, когда массово выставляются всякие начисления и закрытия. 1С ведь сама по умолчанию обрезает половину доступного времени суток, заранее предлагая новому документу время 12:00:00...

berezdetsky писал(а) 10. Августа 2010 :: 07:52:
Да, я тоже думал, что скорее всего придется так решать проблему, но боюсь залезать своими кривыми ручками в бух.подсистему 1С Хотя в бух.итогах вроде бы не фигурирует позиция документа, а только дата... может и не так страшно... получается нужно подправить только те таблицы, которые я уже описал в последнем запросе.
А влезать внутрь чужого отлично работающего класса не хочется тем более  

Столкнулся с этой же проблемой (http://www.1cpp.ru/forum/YaBB.pl?num=1181817217/224#219).

Поскольку тут ни причины возникновения, ни методов решения толком не указано, придется устроить небольшой некропостинг.

Итак, причины:
Причина ровно одна - запись нового документа в режиме "в конец дня" при наличии в этом дне документов со временем >= 23:59:50. (в посте по ссылке я немного неверно написал - при изменении времени существующих ошибка не наблюдается).
С "большим количеством документов в 23:59:59" никак не связано. Достаточно одного, и даже чуть раньше, чем 59:59.
Операция нового документа получает время последний_документ_в_дне + 10 секунд (т.е. от 23:60:00 до 23:60:09)
Ошибка возникает в таблице _1SOper и дальше мигрирует по остальным таблицам бух. подсистемы.

Теперь, как лечить.
Лучше всего лечить триггером.
Только обнаружился один нюанс:
Если мы документ записываем (меняем время) из формы - запись в таблицы _1SJourn и _1SOper идет в одной последовательности.
Если мы меняем время через журнал - данные в эти таблицы записываются в обратной последовательности.
Да, они (разработчики платформы) чудные люди на букву М.

Но из-за этого, вместо использования таблицы _1SJourn, триггер вынужден выглядеть вот так:

CREATE TRIGGER dbo.ВыправитьВремяОперации ON  dbo._1SOPER AFTER INSERT,UPDATE
AS
BEGIN
	SET NOCOUNT ON;
	DECLARE @Время_23_59_59 char(6)
	SET @Время_23_59_59 = 'EAEAY8'

	UPDATE _1SOPER
	SET Date_Time_DOCID = Left(O.DATE_TIME_DOCID, 8) + @Время_23_59_59 + Substring(O.DATE_TIME_DOCID, 15, 9)
	FROM _1SOPER O
		Inner Join Inserted i on i.DocId = O.DocId
	WHERE
	    substring(i.DATE_TIME_DOCID, 9, 6) > @Время_23_59_59
END 

Из прочих приколов:
При проведении документов в таблицу _1SEntry (и подобные) Date_Time_DocID пишется ровно то, что записано в _1SOper.
Однако, штатный объект БухгалтерскиеИтоги это реквизит для отборов по периоду не использует - видимо, всегда джойнят журнал и фильтруют по позиции из журнала.
Спрашивается тогда - нафига он вообще нужен, этот реквизит?