Доброго времени суток!

Итого, вроде бы разобравшись с возможностью запихнуть документ в конец секунды, вдруг выясняется, что этот конец секунды только в пределах этого типа документа! Так как у ссылки документа имеется префикс, который можно видеть если сделать ЗначениеВСтрокуВнутр:

Поступление: 303:bdb80025909995f011e5bba490e77305
Списание: 332:8bd10025909995f011e5b9462599600f
Корректировка долга: 240:ff540015178177f811e5ba9f0b14cba6

Итого: получается что невозможно сделать корректировку долга внутри одной секунды после документов Поступления и Списания.

ХЗрасчётный.Остатки(МоментВремени(Корретировка)) - не отображает остатков! На следующую секунду - остатки имеются!

Может, я неправильно ссылку понимаю, и по ЗначениеВСтрокуВнутр "ff540015178177f811e5ba9f0b14cba6" - это совсем не значение, по которому ссылки сортируются? Однако, штатная сортировка при выборке запросом - подтверждает, что ссылка выглядит именно так.

Где косяк?

+
Но ссылка по Регистратор в запросе выдаёт следующую последовательность:

332:8bd10025909995f011e5b9462599600f Списание
303:bdb80025909995f011e5bba490e77305 Поступление
240:ff540015178177f811e5ba9f0b14cba6 Корректировка долга

Т.е. - сортирует с неким трёхзначным префиксом.

Это ж все основы последовательности документов к чертям летят, не?

(1) а зачем пытаться сделать это в одну секунду?

"некий трёхзначный префикс" - это ид объекта метаданных.

Если нужна сквозная сортировка как в 7.7 по DATE_TIME_IDDOC - то переходи на 7.7 :)

(0) Тоже мне новость.
Момент времени = Дата + Ссылка.
Однако ссылки упорядочиваются только внутри объектов одного типа.
Последовательность ссылок объектов даже одного типа, полученных из разных источников происхождения (разных узлов РИБ) вообще непредсказуема.

То, что типовыми методами получит последовательность документов внутри одной секунды невозможно известно давно.

А вообще сама постановка задачи - упорядочить внутри одной секунды Поступление - Списание - Корректироку - какой-то маразм.

(5)+100500

(0) >Где косяк?

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

(1) три варианта:

- не делать эти 3 документа в 1 секунду
- создать в конфе еще документ Корректировка1, который будет вставать правильно.
- переписать проведение корректировки, чтобы она сама располагалась в начале секунды, но остатки брала на коней секунды.

(0) Граница()

(0) восьмерка не имеет штатных механизмов позволяющих оперировать документами внутри одной секунды....

наверно можно пробовать подбирать гуиды для новых и еще не записанных документов сравнивая их моменты что-бы все выстроилось все правильно...

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

(10) "граница дает возможность получить остатки на конкретный документ"

Что за ерунда?

Запрос.УстановитьПараметры("ГраницаОстатков",Новый Граница(Документ.Дата,ВидГраницы.Включая));

Причем тут момент времени?

(11) граница это дата+гуид+флаг, в общем это момент+флаг...

в любом случае ни граница ни момент автору не поможет

(0)> Итого: получается что невозможно сделать корректировку долга внутри одной секунды после документов Поступления и Списания.

А если в дереве матаданных подвинуть документ?

(13) не поможет, там тоже УИДы. Ты же не собираешься для таких целей пересоздавать документ

(14)  
332:8bd10025909995f011e5b9462599600f Списание
303:bdb80025909995f011e5bba490e77305 Поступление
240:ff540015178177f811e5ba9f0b14cba6 Корректировка долга

Пишут, что 332,   303, 240

"– это номер таблицы в sql базе или не в sql (для файлового режима) данных например _ReferenceN135 (в другой базе этот номер может быть другой, в разрезе баз они разные)"(С)

Это идентификатор метаданных в конфигурации. "Идентификатор" - потому, что не порядковый номер. И база тут совсем не причём. Ни разу.

Я один не понимаю всей вселенской проблемы автора, которая по моему мнению не стоит и выеденного яйца?

(17) написано же в (0): "Где косяк?"

(17) он хочет делать в 23:59:59 одновременно и поступление и отгрузку и удивляется почему у него момент времени поступления оказался больше чем момент времени реализации...

(14) (16)

Создал конфу и два документа. Забил по паре штук:

Документ1 000000001 от 01.10.2016 21:38:30 {"#",f6f3f5f4-918e-4603-86c7-1a4747ff99a8,10:9d9b94de806eef4811e687fddd608b6c}
Документ2 000000001 от 01.10.2016 21:38:30 {"#",62e88d1c-afdf-4f68-b883-4047f816483c,11:9d9b94de806eef4811e687fddd608b6e}

У первого документа ид 10 у второго 11

Поменял порядок документов в конфе, выгрузил конфигурацию через "Выгрузить конфигурацию в файлы", удалил документы, и загрузил обратно.

Документ1 000000001 от 01.10.2016 21:51:17 {"#",f6f3f5f4-918e-4603-86c7-1a4747ff99a8,22:9d9b94de806eef4811e687ffa1f35ff0}
Документ2 000000001 от 01.10.2016 21:51:32 {"#",62e88d1c-afdf-4f68-b883-4047f816483c,21:9d9b94de806eef4811e687ffa1f35ff1}

У Документа1 - код 22, у документа2 код 21.

При желании можно опрелить порядок документов в секунде, но только для тонких извращенцев.

(20) "Поменял порядок документов в конфе, выгрузил конфигурацию через "Выгрузить конфигурацию в файлы", удалил документы, и загрузил обратно." это и есть "пересоздать".

(21) В чем проблема? Выгружаешь данные в ХМЛ, пересоздаешь конфу. с документами в нужном тебе порядке, загружаешь данные из ХМЛ.

Конечно с УППшной базой под 20 гигов - я бы такое не стал делать, но с БП 3.0  в 500мб - почему бы и нет.

(19) Ну тоесть, у автора нет проблемы, есть вопрос. Ок.

(23) Автор отчаянно ищет косяк, понимаешь? Ну хочется ему. Остальной текст для прикрытия, чтоб не забанили.

(24) Поржал))

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

Однако... - однако.

**facepalm

Я правильно понял, что автора смущает то, что при подсовывании в запрос границы нет гарантии, что в эту границу попадут документы с той же датой?

Если да, то почему бы не подсовывть границу + 1 секунда с видом "Исключая" и отбросить ненужные виды документов?

(28) Так это ж 1С-овцы прописали, мне там не подкорректировать, у них в головах-то)

(28) Я-то именно так и делал, и вот... был неприятно удивлён, что закрывается корректировками не всё, что я вижу. Я в отчёте вижу а корректировка - не видит. Дорабатывал, передвигал за максимальную ссылку, а оно вононо как - с идентификатором типа документа.

(30) Что конкретно не видит коррективка?

(30) "а оно вононо как - с идентификатором типа документа" // С учетом (20) только не понял - сдвиг в дереве метаданных не изменяет "внутренний" порядок видов документов?

(31) Так в (0) написаны оба типа документов.
(32) Не пробовал, да и если так - изменение порядка должно приводить к чудесам при перепроведении, что должно быть уж совсем немыслимо

(33) Запрос, выполняемый в документе Корректировка, не видит остатки с учетом проведенных (в ту же секунду) ПТУ и Списания? В этом проблема?

(34) Да. Запрос заполнения. И запросы в проведении.

(35) Запрос.УстановитьПараметры("ГраницаОстатков",Новый Граница(Документ.Дата,ВидГраницы.Включая));

(36) Это включая всю дату+время. А в корректировке везде написано: включая всё внутри даты (и времени), но до документа.

(37) Не включая этот документ?

(37) Не включая движения по корректировки?

(37) Или: не включая и движения других документов, проведенных после корректировки?

(40) ты что! Если подумать и сформулировать, что нужно, всё становится слишком просто

(40) Да. Собираются итоги на МоментВремени(Корректировка)

Остатки на
Запрос.УстановитьПараметры("ГраницаОстатков",Новый Граница(Документ.Дата,ВидГраницы.Исключая));

минус движения, где:
Период>=&ДокументДата
И Регистратор<=ДокументСсылка

или

Период>=&ДокументДата
И Регистратор<ДокументСсылка (Тут уж как вам надо)

(43) Не пойму, как мне это поможет разместить новую корректировку после всех существующих в базе документов в последней секунде квартала?

(44) Никак не поможет, так как у тебя каша в голове.

(45) Каша в голове, как раз - у вас.

Попробуй вместо даты подставить момент времени:
Запрос.УстановитьПараметры("ГраницаОстатков",Новый Граница(Документ.МоментВремени(), ВидГраницы.Исключая));

И вообще сравни моменты времени у документов в эту секунду. У момента времени есть метод Сравнить()

Вот только помоему управлять размещением документов по оси времени в этой секунде ты не сможешь. Поэтому смысла нет.

(47) В Границе тоже этот номер "таблицы/типа данных" присутствует.

Можно смотреть вечно на то как горит огонь, течет вода и как 1с-ки фапают на последовательность документов.

(50) Тогда уж (теперь уж): е*у*ся с последовательностью...

(51) Я решу твою проблему за ммм, 15 минут :-)

Но, как пел великий Оффспринг:

I won't pay, I won't pay ya, no way
(now now) Why don't you get a job
Say no way, say no way ya, no way
(now now) Why don't you get a job

(53) Чессно говоря, я ничерта не понял:

"Я не заплачу, я не заплачу я, нет пути
(сейчас) почему бы тебе не устроиться на работу
Сама, ни я, ни
(сейчас) почему бы тебе не устроиться на работу"

Но, думаю, если бы существовало какое-то решение - его бы уже нашёл многоуважаемый All. А так, из надёжных решений - только отодвигать все документы на секунду назад, чтобы вставить корректировку последним документом квартала.

(54) решение есть в области методологии учета.
Хотя и техническое можно при желании найти, но нужно четко понимать нафига оно тебе.

(54) http://www.amalgama-lab.com/songs/o/offspring/why_don_t_you_get_a_job.html

(56) А, спасибо! (53) - Толсто! (или тонко))

(55) И что говорит методология учёта в данной ситуации? Сделайте проводки вручную ОперациейБУХ ? Или заполнить операции автомагически по принципу движений Корректировки?
Логично, но более "нагружено", нежели отодвинуть все документы на секунду взад в сложившейся ситуации.

(57) методологии вообще чхать на последовательность документов, главное остатки на конец отчетного периода, а последовательно это технические заморочки...
как вариант нормально реализованный в 1С это РАУЗ, но можно было сделать и иначе

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

+(59) Не понимаю, почему бы в процедуре проведения не вызывать процедуру заполнения документа нужным образом и просто не проводить его. Какая потом разница, встал он последним в этой секунде или не встал?

+(60) Одно из возможных объяснений - бизнес-логика завязана на какой-нибудь алгоритм типа "взять сумму остатка всех регистраторов перед регистратором вида "Корректировка"", но это кажется тупиковым путем (сам себе яму роешь)

(59) Да не то что массовое перепроведение... Тут массово: открыл документ, посмотрел, какой он заполненный весь и "ОК", закройся... и это не лечится. Да и исправлять типовую конфу - это последний метод, несмотря, на то что он много проще решает задачу.
(61) А особой бизнес-логики никакой, просто корректировка (как пример) должна закрывать все имеющиеся остатки, а не только по тем документам, у которых идентификатор типа меньше, чем у корректировки.

(62) "корректировка (как пример) должна закрывать все имеющиеся остатки, а не только по тем документам, у которых идентификатор типа меньше, чем у корректировки" // Ну так и замечательно: получай остатки на конец периода (граница - включая) и вычитай ненужные остатки.
"исправлять типовую конфу - это последний метод" // А в какой это типовой и при каком сценарии наблюдается нежелательное поведение (неправильные проводки или что)?

(62) В чем проблема использовать просто конец периода? А не Документ.Моментвремени.

(63) "// Ну так и замечательно: получай остатки на конец периода (граница - включая) и вычитай ненужные остатки.
"

мы это уже проходили, но автор ниасилил.

(65) Это вы никак тему не можете осилить, всё о своём, на своей волне. Создайте свою тему и решайте там задачу создания документа запросом, о Боже)

(63) В (0) описано.
(64) Нет проблемы, но КорректировкаДолга писана 1С-ом, а не мной, а 1С вряд ли будет срочно менять поведение документа. И я типовое поведение исправлять не буду, когда есть альтернативные решения.

(66) В (0) не написано, что за конфа.

(66) КорректировкаДолга в УПП технический документ. Он как бы не очень был рекомендован для использования. Там много нюансов как его правильно нужно заполнять.

(67) Ой, да.. Бух 2.

Честно прочитал (0), но в деталях ни фига не ясно: что не так с документом "Корректировка долга", а вернее с его алгоритмом проведения (изи какой-нибудь команды заполнения)?

(62) >открыл документ, посмотрел, какой он заполненный весь и "ОК", закройся... и это не лечится.

Еще как лечится. Запрет неоперативного проведения называется.

(70) А какие нужны детали к "Итого: получается что невозможно сделать корректировку долга внутри одной секунды после документов Поступления и Списания." ?
Его алгоритм проведения и заполнения не подразумевают, что в одной секунде с корректировкой будут ещё документы. Вот и всё.

Кажется, я понял, какую задачу решает ТС. Он хочет своей корректировкой скрыть косяки бухов в учете. Что ж, удачи. Потом придет плакаться, что его крайним сделали.

(71) И как же тогда проводить документы прошлого квартала? Создавать новые, изменять существующие?

(73) А, понятно. Вы стремительный? Выводы впереди анализа?

(74) Бухам с головой можно разрешить.

(75) Приходится. Ты же не объясняешь толком, исходную проблему скрываешь.

Так, а если документ новый, то он все остатки выгребет?
Если да, то мб проще новый документ заводить?

(77) При перепроведении - документ уже перестанет быть новым, т.е. - потеряет документы текущей секунды.

(78) Так табличные части же не обновляются при перепроведении. Создал документ - заполнил, провёл - спишь спокойно.

(72) Хм-хм, ну погоди: в случае с новым документом он при первом проведении работает правильно (формирует нужные проводки)?
При втором проведении его проводки изменятся что ли?

(80) (79) Да, изменяет проводки из-за того, что перестаёт видеть остатки, которые закрывает. И делает движения, устанавливая в субконто себя, вместо указанного к закрытию документа. Вы, в общем, в курсе, что делает Корректировка долга?

(81) В курсе.
Ты хочешь сказать, что при перепроведении она меняет свои табличные части? Т.к. документ расчетов указывается в ТЧ, которые должны перезаполняться только при нажатии кнопок "Заполнить" из формы документы, либо вручную. В общем, что-то мне не верится.

(82) там скорей всего есть режим "авто", при котором 3-е субконто заполняется автоматически из остатков при проведении.

(82) фейспалм... Не табличные части, а движения меняет!
А в табличной части указывается что зачесть... И вот если на момент проведения суммы по "что зачесть" на остатках документ не увидит, зачтёт сумму по себе любимому, а не по указанному в ТЧ документу.

(84) Чет ты не договариваешь, либо сам не в курсе)
http://i.imgur.com/aDn8Zp8.png

Разумеется, никакой задолженности у Алхимова нет. Но сумма списалась целиком

Видимо, понял, о чем ты. У нас просто взаиморасчеты не ведуться по документам расчетов.

Но всё равно проблема непонятна. Сумма же заполняется один раз, и при первом проведении списывается нормально. Так если ты потом добавишь в эту секунду ещё один документ, остатки изменятся, но при перепроведении корректировки её проводки поменятся не должны. А если бы они менялись, то как раз бы вылезал косяк - часть суммы списалась бы на последний документ, а предыдущие не закрылись бы полностью