Я правильно понимаю, что такая ошибка возникает когда слишком много документов с временем 23.59.59?

(0) Нет. Что значит "разместить после ТА"? Поменять время у уже проведенного документа?
После ТА нельзя провести документ, если между ТА и позицией документа есть проведенные документы с оперативным учетом. Такие документы обычно в журнале имеют синюю галку вместо красной.

(1) ТА установлена на 23.59.59 текущего дня, и в середине дня начинает выскакивать ошибка, приходится переносить ТА на следующий день.

(2) Внимательно, раз 100 читай (2).

(0) +(1) Или серую галку, точно не помню - с семеркой уже несколько лет не работаю. Синяя галка вроде у проведенных неоперативных документов - расчетных, бухгалтерских и не принадлежащих ни одному виду учета.

(0) Вроде бы 10000 документов можно в одной секунде хранить.

(1) В начала дня ТА стоит 23.59.59 документы вводят текущим днем.

Как может "между ТА и позицией документа"?

ТА - это не время, это позиция. Это DateTimeIDDoc. 23.59.59 тут вообще никаким боком, ибо влезет в эту секунду еще чемодан документов.

(0) давай начнем с того, сколько у тебя документов с временем 23:59:59?
второй вопрос: зачем они все с этим временем?

(6) А почему в начале дня стоит конец дня?

(8) Если интересен реальный ответ, то пожалста, менеджер в центр базе сделал документ и зафигачил ему такое время . Документ ушел в периферийки. там документы начали создаваться в этом времени. В каждом из объектов - их может и не так много, из 50-ти объектов 200 доков прилетит и все, планку в 10000 уже пробиваем.
Почему в центр. базе документ с таким временем - опять же, пример. Вчера вечером сделали док, который надо будет запустить сегодня, сохранили его, дата встала в 23:59:59, потом сегодня ему дату поправили и провели, остальные документы от этого и пошли отталкиваться...

(10) Чушь какая-то. На кой ляд менеджеру вручную время двигать? Да еще в семерке, где для этого нужно дополнительные действия предпринимать. Какие-то сказки Вы нам рассказываете. Причина в чем-то другом.

(11) Ну, например: Я вчера создаю в конце дня документ и его сохраняю, какое будет время у этого документа? Потом какой-нибудь робот ночью автоматом проводит такие документы, и устанавливает ТА на это время уже на сегодня. С утра все пришедшие начинают вводить новые документы уже после ТА. Несколько раз такой сценарий повторить - и все документы уже начнут создаваться в 23:59:59.
З.Ы. Сам пару раз с такой фигней разбирался. Но случается такое в обычной практике, все же, крайне редко. Хотя какими-нибудь тупыми обработками можно каждый день такой геморрой себе иметь.
(0) Я бы посоветовал с утра хотя бы один день помониторить - как меняется время в документах и почему и найти источник такого сдвига. Далее по выявленным фактам принимать решения.

(10) согласен с (11) - это чушь...
пригласи специалиста - и все будем нормально приходить из ЦБ в ПБ и проводиться нормальным временем....

(12) зачем робот устанавливает на это-же время? что ему мешает установить правильное время?

(12) "Я вчера создаю в конце дня документ и его сохраняю, какое будет время у этого документа?"
- время конца дня. Это в общем случае не обязано быть 23:59:59. "Конец дня" во вчерашнем дне (задним числом) - это последний проведенный документ во вчерашнем дне.
Итого: незачет.

(12) "Потом какой-нибудь робот ночью автоматом проводит такие документы, и устанавливает ТА на это время уже на сегодня."
- бредовый поток сознания. Если в заднем числе есть записанный но непроведенный документ. то при его проведении в заднем числе дата документ никоим образом сама в новое число не перескочит.
Итого: незачет*2
.
Если робот переносит непроведенный документ на текущий день посредством изменения даты непроведенного документа и при этом не устанавливает время на текущее актуальное - кривые руки программера. что при этом возможно впринципе - прогнозировать бесмысленно, все зависит от фантазий криворукого программиста.

(15) Уважаемый, я это прекрасно понимаю. И если прочитать внимательно текст в (15) то там есть строчка "Несколько раз такой сценарий повторить - и все документы уже начнут создаваться в 23:59:59.". Т.е. в первый раз документы пошли с 17:00 с утра валиться, и закончат, например, на 20:00, на второй раз - уже с 20:00 до 23:00 лягут, а в третий раз - в то самое 23:59. Но может так и не быть, т.к. все зависит от источника проблемы.
(16) Вот тебе близкий к реальному пример: Менеджер в пятницу с утра получает задание - чтобы с субботы товар Х продавался по цене У. Для этого фигачит документ "Установка цен" и ставит ему время на 23:00, чтобы сейчас все продавалось по текущей цене, а на следующий день уже пошла новая цена. Фиговый вариант? Угу, но вполне возможный!
И именно потому, что "все зависит от фантазий криворукого программиста." я и написал, что "Я бы посоветовал с утра хотя бы один день помониторить - как меняется время в документах и почему и найти источник такого сдвига. Далее по выявленным фактам принимать решения.". Т.к. я лично не знаю - что там и как работает у (0), а наворотить можно тонну всяких глупостей.

С искренним Уважением...

(17) "Для этого фигачит документ "Установка цен" и ставит ему время на 23:00, чтобы сейчас все продавалось по текущей цене, а на следующий день уже пошла новая цена"

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

(18): внимание, вопрос!
какое значение на конкретную дату будет выдаваться методом период.реквизитов "Получить" - если на эту дату значения были установлены вручную и несколькими документами (методом "УстановитьРеквизитСправочника" ?... )))))

(18) если периодика изменяется документом - в поле TIME пишется время документа. поэтому  есть возможность получать периодику на момент времени.

(20): не-а. разве что прямыми запросами или сначала выбирать, а потом ещё потом пере-сортировывать.
1с-ина в таких случаях выдает в качестве значения на дату - установленное последним документом - но не по хронологии (по которой можно двигать документы туда-сюда), а в порядке их создания (т. в порядке возрастания Id). и соответствующий порядок - в методах выборки значений такой периодики.

(21) дык индекс-то (ID, OBJID, DATE, TIME, DOCID, ROW_ID) - c с чего он по docid'ам будет сортировать?

(+21) а установленное вручную пишется без времени и оказывается первым, а получить - выдает последнее....

(23) ну можно писать цены в оборотный регистр накопления и оттуда обратным перебором получить последнее.

(0) Основная причина возникновения такой ошибки, в правах документа снятая галка "проведение задним числом" (нижняя).
Ну и конечно много документов на 23:59:59

Чтоб документы не попадали на 23:59:59
Можно выстроить документы за день с шагом в одну секунду.
Процедура ПриОткрытии()
  Если ДатаДок>ПолучитьДатуТА() Тогда
    АвтовремяКонецДня();
  Иначе
    АвтовремяПослеТА();
  КонецЕсли;
  ПроводитьпослеТА(1,-1);
...
Процедура ПриЗаписи()
  Если ДатаДок>ПолучитьДатуТА() Тогда
    АвтовремяКонецДня();
  Иначе
    АвтовремяПослеТА();
  КонецЕсли;
...
Ну и как я написал выше, у всех документов проверить наличие нижней галки в правах.

Чтоб не писать в каждом документе, можно написать в глобальнике, в двух процедурах -
глПроверкаРазрешенияРедактирования
глМожноЗаписатьДокумент

(11) Причина в другом. Это достаточно распространенный глюк семерки. И причина в правах. Когда время 23:59:59 - возникает ситуация что все документы попадают в одно время. И при этом может получиться так, что текущий проводимый документ попадает в не последнюю позицию.
При этом из-за глюка 1С (вроде только в случае запрета проведения задним числом, во всяком случае проверка прав во всех документах и проставление галки - проблему убирает) возникает ситуация (0)
Документ проводится, но со странного цвета галкой, и после этого, при попытке проведения новых документов получаем (0)

Хрень какая-то

(29) Странно что ты не в курсе, есть даже обработки исправляющие этот глюк - изменяющие время документов чтоб можно было продолжить работу. И он, глюк, и обработки легко гуглятся. Только вот причина (25) не гуглится, хотя вроде я давно и неоднократно о причине на мисте писал.

(29) Чисто теоретически - полностью согласен. Однако ж когда сам пару раз в такое вляпаешься, то...

(17) В УстановитьРеквизитСправочника() можно задать конкретную дату. Так что документ ты можешь провести сегодняшней датой, а цена будет действовать с любой указанной.

(30) ты умный, шо капец! ;-) Я серьезно ;-)
.
по факту у меня почти все работают с запретом проведения документа задним числом. И на такую ситуевину, как ты описал в (28), В ДНЕ, СООТВЕТСТВУЮЩЕМ ТА - у меня в принципе документы не могуть попасть в 23.59.59. А в 23.59.59 в ЗАДНЕМ ПРОШЛОМ ДНЕ если попадут документы - то это некритично, такой ситуевины как в (28) - не возникнет.
.
Поэтому, наскольо я поянл из твоих пояснения - мне одно непонятно - как надо умудрится чтобы 23.59.59 - СООТВЕТСТВОВАЛО ТА? - это либо прог что-то программит-делает, либо хрень какая-тою.

(33) Вполне достаточно чтоб работали, создавали документы, текущим временем. Либо чтоб было много документов.
У нас вечером, после 20:00 почти 10000 документов заводится в системе (заявки + реализации). Ну и не меньше до 20:00
Если между документами 10 секунд - уже гарантированно налетаешь на 23:59, даже если ни один документ не создается текущим временем. Ну и если есть документы текущим временем и работа круглосуточная, то налетишь на 23:59:59 и при малом количестве документов.

То есть чтоб этого не произошло, нужно
1. Чтоб ни один документ не создавался текущим временем.
2. Чтоб между документами по возможности была  одна секунда.
Это делает вышеприведенный код.

(34) Там есть переписаны механизмы "быстрой продажи". Которая создает фиктивные документы по продаже одной фирмы другой, а в конце дня эти фиктивные документы объединяются. Два функционала для розницы и для опта.

Раньше работало нормально, потом почему-то перестало.

Сделал тупо устанавливая время документа на часы 23, минуты = текущие часы, секунды текшие минуты.

Т.е. допустим текущее время 15:21:17 у документов устанавливается время 23:15:21.

(35) После этого начались проблемы, или этим решил проблемы?

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

(36) > или этим решил проблемы?

решились

Почему возникли проблемы - не понятно.

(37) Программный код, если он только не формирует документы в ПРОШЛЫХ ДНЯХ относительно ТА, не должен в текущем дне ставить документы НЕРЕАЛЬНЫМ временем. если генерятся документы сегодняшние - ну и проводи их текущим реальным временем - какие проблемы...?