В общем задача такая: При проведении дока задним числом фиксировать изменившиеся движения по регистрам, учавствующим в последовательности, а при восстановлении последовательности проводить только те документы, которые могут на нее повлиять.
Например:
1. Открыли док, изменили комментарий, или другое некритичное поле, нажали ок. Последовательность должна остаться на месте.
2. Открыли док по ИП Пупкин, изменили сумму взаиморасчетов, теперь у ИП Пупкин изменилась цепочка гашения долгов и нужно провести доки только по нему.
3. Открыли приходную накладную, изменили цену одной номенклатурной позиции. Теперь нужно перепровести только те документы, в которых учавствует партия этой приходной накладной по изменившейся номенклатуре.
и т.п.
.
Идея состоит в следующем.
1. Создаю справочник с тремя полями "Документ, Партия, Договор". Т.к. в основной последовательности партия и договор - ключевые измерения учавствующих в ней регистров.
2. Перед проведением дока задним числом запоминаю движения в глобальной ТЗ.
3. После проведения дока сравниваю новые движения с глобальной ТЗ и в случае несовпадения движений в справочник пишу документ и партию (договор), по которой изменились либо качественные, либо количественные показатели движения.
4. Создаем спец обработку по восстановлению ГП, которая:
а) Выбирает все документы, в движениях по которым присутствует одна из партий, либо один из договоров, указанных в форме списка справочника.
б) Перепроводит ТОЛЬКО эти документы, "пиная" ГП на перепроводимый документ и удаляя записи из справочника по перепроводимым документам.
в) Каждый перепроводимый документ также анализирует изменения своих движений и при необходимости дописывает эти изменения в справочник.
Где грабли?

Наши люди... без гемороя не могут...
.
P.S. гораздо проще ликвидировать зависимость от ГП, чем маяться по жизни с ней...

(1) Наши люди не могут дать идею. Уже наверное год прошел как ты это здесь говоришь.

(1) ВОПРОС: Задаю не помню какой раз.
.
Реализация -500
ПКО +5000
Реализация -6000
Итог:
Цепочка гашения:
Кредитный документ: Реализация -500 Долг Счет 62.1
 Документ Гашения: ПКО +500 Долг Счет 62.1
Кредитный документ: ПКО +4500 Аванс Счет 62.2
 Документ Гашения: Реализация -4500 Аванс Счет 62.2
Кредитный документ: Реализация -1500 Долг Счет 62.1
В итоге получаем долг по реализации на счете 62.1 в размере 1500.
.
Теперь задним числом поменяем сумму ПКО на 10000 Руб. Что получим после "Ликвидации зависимости от ГП"?

... кто-то что-то крикнул и тишина ...

Почему возникла потребность в таком решении?

(5) Потому что в заднем ... числе ковыряют. Причем от этого факта никак не избавиться. Распределенка по нескольким городам. Тут даже если с партиями извратиться, то со взаиморасчетами даже при проведении в ПБ на ТА все равно получиться "задним числом", т.к. есть клиенты, которые отгружаются в разных городах, а платят все в одну кучу, поэтому взаиморасчеты сводятся только в ЦБ. Доков, влияющих на последовательность больше 2000 в день. Всего доков (с заявками, сф) около 4500-5000 доков в день. Месяц можно по ночам неделю пересчитывать :)

(2) Как только Pit появился на Кубани, он сразу начал об этом говорить.
А на Кубани он давно :)

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

(7) Только где ответ на вопрос (3), который я уже больше года здесь задаю?
А то получается "Я при помощи напильника переделал самокат в велосипед, а есть ли у этого велосипеда педали, я вам не скажу".

(5) - Хех - наш бух подобный вопрос закрыл тем, что отменил 62.2 - щас все сыпется на 62.1(АП) - утверждается, что так ему удобней...

(0) Почитай про микропоследовательности, реализованные в У.А.У: www.kint.ru/k.pl?p=338

(10) - это не для (5), а для (3)

(0) а глобальную ТЗ обязательно?, если документ будет с ней работать то другой док сможет её поменять.

(10) YAndrey, хоть бы постеснялся, такой фигней хвастаться.

(14) Да я собственно не хвастаюсь... ;)

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

2(16) в в8 каждую последовательность можно еще разделить - одну по контрагентам, другую по номенклатуре, и для восстановления последовательности перепроводить только те документы, в которых есть этот контрагент или номенклатуру. И именно по этой причине документ "Строка БВ" сделан отдельным документом, а не строкой общей БВ. Но почему сами разработчики сказавши А не сказали Б - не понятно... может реализуют в следующих редакциях.

(11) Вроде красиво, только не понял вот что:
устанавливает по предыдущему документу итог ресурса «Токен» в 0.
Важно! Временный расчет итогов контрольного регистра не производится (то есть проведение документов прак-тически не замедляется).
.
А именно, как без расчета итогов можно найти "предыдущий" документ?
.
И еще момент: Для того, чтобы восстановить последовательность, необходимо сначала отменить проведение всех документов последовательности.
Это еще зачем?
.
Т.е. вроде в регистре хранить подобные данные красивее, только осталось разобраться, как.
Кстати, а где Pit?

"Теперь задним числом поменяем сумму ПКО на 10000 Руб. "...
.
А в табло от кассира не хо-хо? Кассир откуда эти деньги в кассе возьмет? Из кармана? Да после этого кассир повесит программера за eggs....
.
зы но даже в этом случае можно все нормально разрулить. Причем без всяких моих идей....

(18) Это не ко мне. Можешь скачать демку УАУ и посмотреть код, если есть желание. Эта идея обсуждалась здесь же лет пять назад. Предложена автором статьи. WildHare (Никита Зайцев) нашел время, чтобы ее проверить (теоретически) и написать о результатах (в статье это есть), а Кинт - чтобы реализовать практически в УАУ.

(18)
"Важно! Временный расчет итогов контрольного регистра не производится (то есть проведение документов прак-тически не замедляется)."
.
а теперь включи мозги и подумай, к каким последствиям это приведет. Можно ведь и козленочкам стать...
.
(17) потому что не все так прозрачно в таких последовательностях...

(19) И опять ты притворился, что понял все буквально. Эээх "ликвидация зависимости от ГП" по Pit'у видимо, заключается в полном отказе от проведения "задним" числом. Мечта адинэсника, которую, Pit, видимо, воплотил таки в жизнь. В голове сразу картина нарисовалась: Загнал адинэсник буха в угол и битой его, да паяльником, да паяльником.
- Ты что, гад вытворяешь?"
- Ликвидиррую зависимость.... от ГП.

(0) Критикую:
1) А не получится ли так, что затраты чтобы определить
"только те документы, которые могут на нее повлиять"
будет соизмеримо с перепроведением всех документов.
2) Не получится ли так, что правильность определения "только тех документов" ты узнаешь от ГБ при сдаче годовой отчетности?

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

(23)
Да, тут еще усложняется тем, что перепроведя документ потенциально имеется возможность получить "новую" цепочку документов, о которой заранее и не предполагали.
(24)
Работающие примеры интересно есть?

Но самая главная проблема, имхо, это распределенность базы, в которой есть общие клиенты и общие склады (транзитные).

Делали на ТиС подобное по номенклатуре. Анализ изменений в ТЧ дока, анализ доков (от даты изменённого до конца) связанных с изменённой номенклатурой, их перепроведение.
Результаты - в принципе реализуемо, но всё равно вылезали косяки, т.е. что-то не учли. Ночью обязательное нормальное восстановление ГП.

2(25) Если это взаиморасчеты, и в документе строкаБВ - только один контрагент, как и в накладной - тогда нет такой возможности.
Но если это партии, где в одной приходной накладной одна номенклатура, а в расходной накладной наряду с элементом ТМЦ из этого прихода будут элементы ТМЦ из другого прихода - тогда да, количество перепроводимых документов может увеличиваться каскадно...

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

Кстати, pit, давным-давно ты писал, что знаешь как вытаскивать с ИТС
текст вместе с картинками в Ворд. Это все еще секрет?

http://www.softpoint.ru/products_id5.htm
ну может они это как то подругому реализовали не факт ... но я думаю что нада как то административно "ликвидировать зависимость от ГП" битой и паяльником...

2(25) Работающих примеров не видел. Более того, сейчас вот подумал - не догоняю эту схему :( При отменах проведения на итогах чехарда получится - и множественные итоги и минуса...
Непонятно, что делать при проводедении нового документа, если последовательность уже нарушена ранее. Не формировать никакие движения нельзя, а какие формировать - непонятно...

(30) так это давно секрет полишинеля...
.
(28) да, там будет именно каскадное увеличение. Пределы - от 1 документа до всех документов от ГП до ТА...
.
(26) с учетом УРИБ - м.б. полная... филе... короче...

(31)
"я думаю что нада как то административно "ликвидировать зависимость от ГП"
Что делать с распределенной базой? А именно одно и то же юр лицо (по которому проходят взаиморасчеты) отгружается с разных складов в разных базах. Когда доки приезжают в ЦБ, их последовательность становится автоматически нарушенной.
Да и без распределенной базы. Ну вот ошибся сотр - поставил в приходной накладной цену вместо 10 рублей тысячу. Ну сломали руки ему битой, не помогло, т.к. руководству по прежнему не нравится прибыль в 1234 процента в анализе продаж.
Про софтпоинт слышал. То что нужно перелопатить полконфы, я и не сомневался.

(fisher) Над этим размышляли неглупые люди. Когда догонишь - поднимешься на новую ступеньку :). В УАУ все работает - проверено.

(32) Вот из за отмены проведения я и переключился с регистров на справочник (раньше была идея основать на регистрах). Отменяем проведение - запись в справочнике остается. Только боюсь, что при таком документообороте справочник мой загнется.

(34) купи идею у меня... там меньше работы...
.

34 мы пытаемся ввести систему двойной записи, когда документ вводится одним человеком и проводится но потом за ним идет "администратор" (бух, кладовщик, диспетчер, менеджер) который все это оперативно проверяет... и пока тот не проверил закрыть период нельзя а период должен быть закрыт за последние 7 дней (в идеале 3), конечно все еще работает не очень ... но более менее просвет виден.. может получится... про распределенные базы сказать ни чего не могу...

(37) Ты так и не ответил на мой вопрос. Какой будет результат, чтобы я знал что покупать?

Предположим, имеем на складе 3 шт.,
делаем расход-1 1 шт, затем еще расход-2 2 шт.
Задним числом изменяем расход-1 на 2 шт.,
он записывает себя в твой справочник.
Запускаем спецобработку: перепроводится расход-1 (успешно).
ГП восстановлена?

2(35) Помоги подняться на новую ступеньку, о неглупый человек.
Скажи, какие движения по этой схеме должен сформировать при проведении НОВЫЙ документ, если имеются более ранние документы, нарушившие последовательность.

(40) У меня задним числом расход-1 на 2 шт. не изменишь. Сработает контроль отрицательных остатков по документам после проводимого.

(33) "так это давно секрет полишинеля..."
это я тоже давно у тебя читал :)

(41) :) Это твой путь...

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

(39) продолжайте героическую борьбу ... Мы за вас выпьем...

(45) :) WildHare тоже в свое время написал, что при массовом проведении доков задним числом эффективность данной системы будет под вопросом.

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

(48) Pit'овское решение - частное, это уже можно не обсуждать.
То, что если при этом оно подойдет в большинстве случаев (опять же со слов Пита (= неуловимый Джо) - ну и славненько. В общем случае - не катит (хотя оставляю за собой пути к отступлению... на всяк случай... вдруг чего не понимаю...)

(42) Ok, тогда так: на складе партия-1 1 шт. и партия-2 2 шт.,
Расход-1 2 шт.
списывает по фифо 1 шт из партии-1 и 1 шт. из партии-2.
Расход-2 1 шт
списывает 1 шт из партии-2.
Юзер исправляет ошибку: приход партия-1 надо 2 шт, приход партия-2 1 шт.
Какие документы надо перепровести?
Если контроль остатков сработает и здесь, как юзеру исправить ошибку?

(46) Странный народ. Купи у меня вещь, а какую, не скажу.

(50) Контроль остатков до партий не опускается, поэтому не сработает. Минуса на партиях и так выправятся восстановлением ГП.
Перепровести надо обе расходки.

(to pit) Покупаю.

(52) Как это определить? По номенклатуре?

(48) предлагай цену...
P.S. я излагал большую часть решения. Кому надо - сделали выводы и теперь в ус не дуют...
.
(49) решение достаточно общее... И - не единственное.
.
(50) это уже двойная ошибка. И возможен не единственный путь ее исправления...

(55) "P.S. я излагал большую часть решения" - к сожаленнию не участвовал при этом. Можно повторить? Глядишь и я куплю, если в цене сойдемся.

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

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

(57) Может их вообще не "проводить", а разбивать партии на момент вывода отчета по партиям или другого.

(56) Сложилось мнение, что Пит просто не различает смысл слов "решение" (которое от него пока и не просят) и "результат". Наверное поэтому до сих пор он не может ответить на мой простецкий вопрос, думает, что я у него решение украсть хочу :) Либо там результат ни к черту, что аж признаться стыдно :).

(58) Че захотел! Он не скажет даже, что получится в результате. Просто он говорит, что будет бело и пушисто. Купи, не пожалеешь.

(57) например, корректировка/сторно...

(61) для (57)

(62) И прибыль в анализе продаж в 1000% - как у Лени Голубкова!

(59) Именно так и делают учетные программы без ГП.
Можно записывать в регистры информацию которая от ГП не зависит.
Например количество товаров, или сумма взаиморасчетов с контрагентами.
Товар по партиям разбивается во время построения отчетов и при закрытии периода. Аналогично определяются авансы/оплата контрагентов.
Вот и весь секрет.;)

2(64) если отчет по продажам такое показывает следовательно была продажа, следовательно он показывает верные данные

(65) А если товар импортный да еще и подакцизный?
Копии сертификатов и ГТД клиентам тоже при закрытии периода выдавать?

а зачем объяснять? ты все равно не купишь... Ты уже решил...
.
P.S. а "решение" простое - при проведении (создании, корректировке) задним числом документ либо проводится (при этом нет красноты по партиям), либо не проводится (ибо в случае проведения возникнет краснота по партиям/остаткам). Решение работает с 01.01.2002 года...

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

2(69) раз используется может быть есть смысл перенять?

(67) А сейчас ты как делаешь?
Девочка ошиблась при поступлении товара вбила не тот ГТД.
Реализовал товар, покупателю ты дал неверный ГТД.
Ой, девочка исправила ГТД.
Ты восстаналиваешь последовательность, ГТД реализации изменилась, посылаешь по почте новый ГТД.
Правильно?

(68) Как вносить исправления, если "в случае проведения возникнет краснота... "?

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

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

(71) Да. Но только в случае ошибки.
А какую ГТД выдают "учетные программы без ГП"?
100% от фонаря? После закрытия периода всем рассылаем новые ГТД?
PS
Я просто интересуюсь, не видел в реальной работе программ без ГП или ее аналогов.

(66) Иза того, что в цену прихода девочка недобила нолик - гендир видит на порядки завышенную маржу, на основании чего принимает решение увеличить оборот именно этого товара. Это правильно? Нет, это не правильно.
(68) На таком велике катаюсь давно. Только для другой цели - не выйти в минус пономенклатурно, а не попартийно. Потому как на складе инвентаризируют количество товара, а не его количество в партии. Со склада отгружают товар, а не его партии. Потому и не куплю, потому как не подходит. Да, и если это будет сделано в разрезе партий, никакую корректировку вообще сделать нельзя будет. Кстати, а что будет с суммами? По ним тоже контроль стоит?
(72) Ни-как.

"насколько я знаю метод сторно/корректировка (то есть запрет редактирования проведенных операций) используется в аксапте, навижене, галактике и т.д." - из (69)
Вот и решение. Зачем велосипеды изобретать? Задним числом вводить - эта очинь плоха! С точки зрения бухгалтерского учета и аудита! Представьте себе, чтоб раньше, когда не было 1С, в ведомостях (книгах) брали и резинкой стирали одну запись или дописывали между строк другие записи и т.п. - как бы эти книги выглядили? Чтоб этого не делать - придумали метод "красного сторно"!

(to pit) Расскажи секрет Полишинеля.

(77) Да, всё это хорошо, только раньше задач таких не было - дать босу дневной отчет о продажах с прибылью или отгрузить товар с нормальной ГТД сегодня, а не когда месяц закроется. ГТД в счет-фактурах ввели не позже 4 лет назад, и попробуй провезти товар без них, любой мент тебя за одно место возьмет, да ещё посмотрит не старые (дадено задание от траспортников не больше 1 года) ли ты их использушь.
И объемы торговли тоже не те были.

(75) "А какую ГТД выдают "учетные программы без ГП"?
100% от фонаря? После закрытия периода всем рассылаем новые ГТД?"
Просто ГТД берется не из регистров, а из расчетов. Координально ничего не меняется.

(67) и эта проблема решается попутно...
    Ибо меня не только затр...ло перепроведение, но и плыли ГТД по товару при работе задним числом и перепроведении... а товар имеет небухгалтерскую отчетность именно по ГТД...
    Акциза не было, но его тоже можно воткнуть... аналогично ГТД...
.
(64) прибыль в отчете - РЕАЛЬНАЯ. При работе задним числом... и без перепроведения. Это просто следствие этого решения.

(81) Так все-таки как вносить исправления, если "в случае проведения возникнет краснота..."? Сторно? Тогда чем такая система лучше простого запрета работать задним числом?

(82) Дык контролируй красноту, кто тебе мешает?

2(pit) Без перепроведения будет уже не ФИФО а нечто другое. Ввели, допустим, в конце месяца приход товара в начало месяца. Продажи по этой партии пойдут только со следующего месяца.

+(84) Но это фигня. А что в твоей системе происходит при отмене проведения партиеобразующего документа?

по поводу исправлений...
при отсутствии ГП все ошибки надо классифицировать... Часть из них можно просто исправить, исправив документы, а насчет второй части надо разбираться...
Примеры
 - пришло 1000 шт товара, реально забили 500, и стоимость 500. Тогда можно просто исправить приход...
 - реально пришло 1000 шт товара, забили 2000, и стоимость 2000. Если на момент обнаружения ошибки продано не более 1000 - можно просто исправить приход... Если более 1000 - надо разбираться, ведь товар реально отгружен (клиент то не дурак, брать воздух). Значит, надо смотреть - скорее всего пересорт - а это уже отдельная песня.
.
примерно такие же действия с себестоиомстью, с поступлением затрат на товар после начала продаж...
   Примеры грубые, схематичные...
.
ПКО - исправлять недопустимо, ибо это - реальные действия и ошибка должна быть найдена кассиром в тот же день - касса то не сойдется...
.
P.S. (78) в составе ОФИСА есть абсолютно легальное средство - Microsoft Document Image (MDI)... Научись им пользоваться...
.
(77) такой метод используется, но только в бух и только после сдачи баланса - чтобы не исправлять...
.
(73) у меня это было следствием примененного решения - когда система не пускает, значит, чтото делается неверно... Сами научились...

(79) Так что, Аксапту с САПом уже отменили? :)
-----
Хорошо и качественно можно автоматизировать только "правильные" задачи (типа, шахматы, расчет полетов на Луну - где есть логичные и строгие правила). Автомизация хаоса только увеличивает хаос (энтропия, понимаешь ли). По-этому, сначала процессы, потом их автоматизация.
А отчет боссу каждый день - для ларька представляю, а для более-менее крупной организации - сомневаюсь.
Вот алгоритм, который предложен в (0), красивый и сложный, но что будет, если где-то ошибка, что-то не предусмотрено. Как по мне, или исскуственный интеллект, который может корректно обрабатывать нетиповые ситуации, или "упрощение-укрощение" процессов.

(86)
"ПКО - исправлять недопустимо, ибо это - реальные действия и ошибка должна быть найдена кассиром в тот же день - касса то не сойдется..."
Урра! Урра! И до меня очередь дошла!
Кассир обнаруживает и исправляет ошибку через три секунды после того, как создал документ. А оператор, редиска, успел за это время отписать реализацию. Разве это исправление не "задним" числом? Еще раз говорю, при чем тут ПКО не ПКО? Пусть это будет корректировка долга, пусть это будет возврат и т.д. и т.п. Суть не в этом.

сваливаю... час Ч наступает...
.
если кто действительно хочет - мыло знаете сами...
насчет "расскажи идею" отвечать не буду

(88) если кассир принял 100 руб, а ПКО выписал на 1000 руб и выдал клиенту корешок приходного ордера - кассир свободен... Через 3 минуты кассир уже НЕ ДОКАЖЕТ, что получил только 100 руб...
.
P.S. увы, не все клиенты добросовестные... поэтому невнимательные кассиры долго не работают...

2(89) "Должна быть у pit'а какая-то загадка" :)
Может быть, pit - это женщина? Слишком много интриги и самолюбования :)
ИМХО, никакой панацеи нет. Схема применима далеко не везде и не всегда из-за ряда ограничений. Большинство ошибок в партиеобразующих документах - критичны и требуют перепроведения.

(90) Не через три минуты, а через три секунды. И корешок он не успел еще распечатать. Опять ты про биту и паяльник. Не то, не то.

(90) Кассир выбрал контрагента-тезку (обычное дело).
Через пару недель исправил - на кассовой книге и остатке это никак не отразится.

(87) "Так что, Аксапту с САПом уже отменили?" - Не отменили скорее всего. Лично мне их правда не довелось постречать. Просто они все такие чистенькие и классно работающие, но вот только потом пользователи вручную часть задач ведут. Стоит ли на это равняться.

+94 pit, он хитрый человек - его система работает отлично, а то что пользователь (или вся фирма) гемороится, так это не его дело.

2(0) От идеи веет холодком...
Посмотри реализацию этого дела в восьмерке

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

(0)
Дело - нужное. Наверно, мало у кого руки доходили сделать именно корректную частичную последовательность. У меня - не доходили.
В принципе, я думаю, что знаю как реализовать, и достаточно надежно. Попробую изложить (мысли вслух).
Для этого нужно:
- реализовать аналог регистров сведений (ищи базу знаний c hare.ru) на оборотном регистре без измерений.
в нем псевдоизмерения = критичные реквизиты, например:
:: Имя_Последовательности (ПартииТоваров)
:: Объект_Последовательности (Товар)
Создать 2 регистра: "рсОбщаяПоследовательность" и "рсНарушеннаяПоследовательность".
- при проведении документов:
в общую последовательность писать себя _всегда_.
по критичным признакам проверяются последние записи на поз-ю документа в регистре сведений (РС) нарушенной послед-ти.
Если запись уже есть - то документ пишет себя в РС нарушенной по любому.
Для вариантов, когда записей еще нет:
а) если проведение НЕ групповое (т.е. могли изменить), то
-- если позиция документа >= позиции ТА то запись в РС нарушенной не производится.
-- если позиция документа < позиции ТА то запись в РС производится в зависимости от проверки, есть ли в общей послед-ти выборка по критичным реквизитам.
б) если проведение групповое (а записей ранее него в РС нарушений нет) - то в РС нарушений запись не идет.
При этом надо предусмотреть обработку доп. параметра при проведении документов, для того, чтобы можно было программно изменить и перепровести документы с записью в эту последовательность.
Вышло очень сумбурно, но надеюсь, смысл понятен.
Думаю, что сделать это не так сложно
Ресурсоемкость - не проверял :) Но думаю, что она очень большой быть не должна.
P.S.
В системы ПИТа - не верю. Вернее, верю, что частично проблему можно решить его подходом. Но 100% - нельзя. Хотя бы потому, что у него идет проверка "можно или нельзя" провести задним числом. Думаю, что у большинства есть ситуации, когда "нельзя, но нужно".
P.P.S.
Для многих случаев все же более корректным будет вариант со сторно, корректировками и т.п. Например, задачи с себестоимостью -- механизмы отфактуровок и распределением затрат на себестоимость проданных/списанных партий в том периоде, когда эти затраты поступили в учетную систему - мне кажутся более предпочтительными.

Вдогонку - пояснения и дополнения к (98):
Вкратце о реализации регистров сведений (кто не найдет архивы харе.ру) - это оборотный регистр без измерений и ресурсов, у него есть только реквизиты = "псевдо-измерения" и "псевдо-ресурсы". У измерений включен отбор. Работа производится через "УстановитьЗначениеФильтра" и "ВыбратьДвижения/Получить движение". Фактически однократное действие "Получить движение" дает первое/последнее значение на дату.
Вместо "рсОбщаяПоследовательность" можно сделать графу отбора по реквизиту движений документа. Но думаю, что это будет более накладно для базы.
Для SQL версии при реализации "псевдо-регистра сведений" надо сделать фиктивный ресурс. Пускай даже "число,1".

2(98) А нафига два регистра сведений? Можно тогда и одним обойтись.
При обычном проведении док делает запись в регистре сведений. При восстановлении последовательности - не делает :)
ГП определяется самой ранней записью в регистре сведений.

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

(+101)
Только по графе отбора надо будет отдельно выборку документов получать по каждому значению. А в регистре - можно по списку отобрать.

Восстановление последовательности:
- по регистру "нарушенной" выбираем объекты, по которым последовательность нарушена
- по этим объектам фильтруем регистр полной последовательности (или графу отбора) и выбираем документы для перепроведения
- в режиме "восстановление последовательности" перепроведим отобранные документы.

(84) "Ввели, допустим, в конце месяца приход товара в начало месяца. Продажи по этой партии пойдут только со следующего месяца."
.
Если партии вести не от регистров, то ничего подобного не случится. Партии будут списываться как тебе угодно FIFO, LIFO, по средней.
В открытом периоде делаться это будет отчетом. А когда период закрываешь, делаются итоговые записи и партии списываются как надо. ;)
(85) "А что в твоей системе происходит при отмене проведения партиеобразующего документа?"
Если жестко, то можно контролировать отстатки по последующим документам реализации.
Если мягко, то отрицательные остатки будут видны в тех же отчетах, и можно запретить закрывать период.
.
Есть как минимум два подхода:
1. (ИМНО изобретение 1С) Основные вычисления делает документ, результаты пишутся в регистры, бух счета. Отчеты строятся по регистрам.
 Достоинства: Быстрое построение отчета. Мнимая гибкость, возможность исправлять документы в прошлых периодах, с последующим востановлением ГП.
2. (с этим подходом хорошо знакомы Фоксники и Клиперники) Документ это просто запись в базе данных. Который может, но не обязан, делать записи в других таблицах (если хотите в оборотных регистрах), таких как "материалы на складах", "взаиморасчеты", "касса" и т.д.
Основная вычислительная нагрузка ложится на отчеты и на обработку закрытия периода. Т.е. именно отчеты вычисляют себестоимость, определяют вид оплаты аванс/оплата, распределяют по партиям. Обработка закрытия периода делает итоговые записи в таблицах (если угодно в регистрах) и закрывает период.
Достоинства: Быстрое "проведение" документов, не зависит от ГП.
Недостатки: Долгое формирование отчетов. Если вдруг приспичит что-то изменить в закрытом периоде, то его открывают, делают необходимые изменения, запускают обработку закрытия периода. Но обычно достаточно сказать "незя" и желание что либо изменять в закрытом периоде отпадает ;)

Как раз занимаюсь похожей проблемой. Только не с товарами, а с кассой и банком (в этой конфе в одном регистре). Из-за того, что сведения о платежах приходят с задержкой на 1-4 дня (филиал иностранной конторы), то пользователю разрешено работать задним числом. Периодически бывает, что пропускают документы, путают расчетные счета или не в тот период пытаются документ вставить. При исправлениях ошибок задним числом не учитывают проведенных документов после исправления. Чтобы уменьшить число ошибок набросал внешнюю обработку, лежит тут: http://topanov.ru/temp/chkchain.ert - не до конца отлаженная, но принцип понятен. При попытке записать "не правильный" документ обработка выдаёт сообщение и, по запросу пользователя, оборотку, в которой показано "узкое место", в котором сальдо по кассе будет кредитовое, если провести такой документ.
P.S. Как встроить в конфигурацию - написано в описании обработки.

(98) Мне регистр тоже больше нравится. Но вот что делать со снятием документа с проведения?

(98) Об УРИБ вообще всю голову сломал.

В общем я пришел к выводу, что один раз делать полное проведение новой порции данных, приехавших в ЦБ все равно придется. Как ни извращайся. Потому как отгрузки совершаются в периферийных базах, а оплаты по банку идут в ЦБ. С вероятностью 80% документ реализации "не впишется" в последовательность, а ради 20% документов распространять такой анализ на все документы будет малоэффективно

(106) напрмер, проверяй при снятии. Если это приход, то можно проверить наличие движений по партиям этого прихода. Если корректировка допустима - ее можно делать. Если нет - тут решение должно остаться за человеком (ибо нужен анализ того, ПОЧЕМУ возникла такая ситуация - а это уже вне рамок системы).
.
(98) не верить - твое право... Я же не заставляю...
"идет проверка "можно или нельзя" провести задним числом. Думаю, что у большинства есть ситуации, когда "нельзя, но нужно".
   Можно реализовать и этот подход (например, товар пришел 20 числа, а клиенту нужна РН строго не позже 15...). Можно реализовать и такое - вся реализация этого займет 5-7 строк кода, причем себестоимость списания будет ПРАВИЛЬНОЙ...
   Рассматривались разные варианты реакции - просто реализованы наиболее подходящие... Сделать же можно много чего...
.
(104)
"Есть как минимум два подхода:...."
.
На самом деле есть как минимум три подхода:
.
1. ГП - изобретение 1С. Проверки делаются только на момент документа (неважно, ТА ли это или заднее число). Все косяки вылазят позже, в момент восстановления ГП... Отчеты строятся по регистрам.
.
 Достоинства: Быстрое проведение. Быстрое построение отчета. Мнимая гибкость, фиктивная возможность исправлять документы в прошлых периодах, с последующим востановлением ГП.
.
2. подход Фокса и Клипера. Полное описание - см (104).
Основная вычислительная нагрузка ложится на отчеты и на обработку закрытия периода. Т.е. именно отчеты вычисляют себестоимость, определяют вид оплаты аванс/оплата, распределяют по партиям. Обработка закрытия периода делает итоговые записи в таблицах (если угодно в регистрах) и закрывает период.
.
Достоинства: Быстрое "проведение" документов, не зависит от ГП.
Недостатки: Долгое формирование отчетов.
.
    Данный подход ("распределение" отчетом) не позволяет реализовать требования по сериям, ГТД, заводским номерам и т.д. Их просто нельзя изменять после выдачи клиенту...
.
3. Подход с полной проверкой. В момент проведения документа делать не только проверки на момент документа, но и проверки всего интервала от документа, вводимого задним числом, до последнего документа системы... С организацией требуемой реакции (не проводить, или предложить иной вариант, или сделать реакцию как надо)...
   Основная сложность данного подхода - организация БЫСТРОЙ проверки ПЕРИОДА, ибо если проверка тормозит работу - система будет признана неработающей... ГП при такой проверке просто не нужна...

Ну вот pit и подитожил все способы. У меня в (105) реализован третий способ. (Кстати, вызов проверки надо еще вставить и в "ПриОтменеПроведенияДокумента()"). Тормознутость зависит напрямую от "задности" числа документа и грубости ошибки. Чем "заднее" число и менее грубая ошибка, тем дольше будет идти проверка. Мало того, эта проверка должна быть отключаемой в полномочиях пользователя, например.

(110) К сожалению, большая часть юзеров запросит эти полномочия, и получится, что Вы наработались забесплатно :(

(108) т.к. документы вводятся в 2(и более) базах - надо как минимум перепровести документы оплаты. Ибо проведение в одной базе может слегка не видеть документов, введенных в другой...
.
P.S. в твоем случае я бы делал свой обмен на уровне документов с проведением документов в ЦБ...

(+109) Еще варианты
1+3 и 2+3
ИМНО 2+3 более симпатичен.
Честно говоря, в таком случае больших проблем с ГТД не вижу.
Может быть потому, что не сталкивался :)

(110)
"Тормознутость зависит напрямую от "задности" числа документа и грубости ошибки. Чем "заднее" число и менее грубая ошибка, тем дольше будет идти проверка."
.
у тебя переборный алгоритм, который зависит от длительности периода. на самом деле проверка м.б. выполнена быстро и за одинаковое время при "заднем числе" 1 неделя, 1 месяц или 1 год....
P.S. я же сказал - основная сложность в организации именно быстрой проверки... вне зависимости от длительности и количества документов

(113) И чему будешь верить в вариантах 1+3 или 2+3, если результаты разные? Тогда уж и перепроведение необходимых документов при формировании отчета можно будет организовать.
(111) Вместо прав эта категория пользователей получит люлей. Потому что при выборе между скоростью, удобством и правильность ввода данных всегда выбираестя последнее.
 Третий способ направлен на то, чтобы минимизировать искажения в регистре, по которому строятся отчеты. Поэтому логичнее будет способ 1+3.

(112) И как максимум документы задолженности, если документы оплаты создали аванс. В общем случае - это все документы.
Восстановление ГП итак делается в ЦБ.
Решил разбить процесс на две части.
1. Выборочное проведение документов до точки Х.
2. Полное проведение документов от точки Х до ТА.
Положение точки Х определяется последним документом последнего полного проведения. Т.е. выборочное проведение распространяется не на весь период, а только на тот, который ранее уже пересчитывался. Точку Х фиксируем в константе, которую видят ПБ. В случае, если корректируемый документ ранее точки Х, изменения по движениям фиксируем (справочник, Регистр, не важно), иначе изменения не фиксируем, зная, что его в любом случае нужно проводить. После заливки в ЦБ получаем:
.
ГП 01.05.2006 (ее сбил корректируемый в ПБ документ)
Константа 05.05.2006 (дата до которой в последний раз восстанавливали ГП).
И записи в справочнике, которые сделали документы от 01 по 05.
.
По этим записям выборочно проводим документы до 05 числа, дальше восстанавливаем ГП в обычном режиме сдвигая константу в соответствии с ГП.

(111) каждого лысого ежика посадим на свой шесток... и пусть каркают...
.
(113) реализован вариант 3 в чистом виде... Контора теперь вспоминает партионный учет в ТиС как страшный сон...

А мне нравится, что учет в 1С через ж...
1. Чувствуешь себя умным.
2. Денюжки.

(118) но есть в нем и светлые.... маленькие такие... точечки...

(119) ты имеешь в виду глистов? ;))

(120) ЛОЛ!!.... теперь буду спрашивать у админов - глистов выгнал?

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

.......... ноу комментс....

(106) что мешает при снятии документа с проведении "допровести" соседний c ним документ последовательности?
(109)
>> С организацией требуемой реакции
>> (не проводить, или предложить иной вариант,
>> или сделать реакцию как надо)...
Понимаешь, речь и идет о том "как надо". Не проводить - это в общем случае то же самое, что и запрет работы задним числом, но только "не всегда". Этот вариант не обсуждается, ибо ИМХО там, где можно запретить заднее число - это надо сделать. Вопрос - как.
Ты же все уши прожужжал о "своем способе", считая что все намеки и пояснения сделал. Но я (и многие другие) не обнаружили в твоих речах в принципе возможного способа решения известных проблем. В лучшем случае - "частные" случаи. Но, думаю, частные решения известны и другим. А общие подходы - это первые 2, описанные тобой. Ну и, естественно, отказ от заднего числа (замена на сторно+корректировки).
Частных я тебе накидать могу на ходу. Но общим решением они не являются.
Хочешь еще один? Для изменения, например, цены прихода 2 месяца назад и фифо с точностью до дня надо использовать служебный документ "Корректировка себестоимости проведения", который за каждый день последний. В случае правки задним числом определяются изменения, которые пройдут после по товару (можно опять отбор использовать) до ТА, строится матрица изменений ФИФО по товару по дням, пишется в эти служебные документы и допроводится.
И это - ЧАСТНОЕ решение. Оно не претендует на звание РЕШЕНИЯ. Но вполне в данном случае работоспособно.
А насчет покупки идеи... Рекламируешь ее - ты. Но цену не назначаешь, и свойства не раскрываешь ... мол, цена только в приват. Это расходится с моим представлением о товаре, который я хочу купить. Интересно, много ли было покупателей?

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

(124)
Мешает то, что может оказаться так, что потребуется провести десятки, сотни или тысячи документов, чтобы расставить флажки "микропоследовательностей" и юзер так и не дождется окончания процесса.
Пример простой:
Приходная Накладная №1
Сто позиций по 100 штук
Приходная Накладная №2
Сто позиций по 1000 штук
Реализация №1
Все позиции по 1 штуке
...
Реализация №100
Все позиции по 1 штуке
Остаток для удаления ПН№1 достаточный. Но для удаления нужно расставить флажки на сто реализаций.

(126) Не надо на 100. Надо определить следующий документ основной последовательности (или графы отбора)
и (до)провести его "с записью в последовательность".

Такие проблемы надо решать в комплексе: организационно и программно. Универсального решения здесь не существует. У меня делается так: до 10 числа каждого месяца проверяется и сводится предыдущий месяц, проверяются первичные документы, проверяются и восстанавливаются последовательности и цепочки документов, делается полное перепроведение. После этого для обычных пользователей ставится дата запрета редактирования. То есть обычным клеркам можно делать исправления задним числом (в объеме из прав, разумеется), но с проверкой при записи документа, как описано в (105). На 100% это не спасает, но значительно уменьшает количество ошибок.

(127) Как это не надо? У нас ведь по каждому товару своя "микропоследовательность". Удаляя ПН №1 мы нарушаем 100 микропоследовательностей. Я, наверное, неправильно написал в 126. Читай так:
Приходная Накладная №1
Сто позиций по 100 штук
Приходная Накладная №2
Сто позиций по 1000 штук
Реализация №1
1 штука ТОВАР_1
...
Реализация №100
1 штука ТОВАР_100
.
Т.е. в разных документах реализации разные товары.

(124) не обнаружил решения? И не обнаружишь. В чистом виде я не его не показывал...
.
Ибо оно настолько простое, что даже не смешно, как его не реализовали... раньше...
.
P.S. не надо порождать лишних сущностей там, где это не нужно...

(130) Ты бы уж сразу в мелкософт обратился. Если бы им такие перспективы на Аксапту, они б тебе ручку то позолотили, да похлеще чем здесь :)
Да, кстати, уже 130 постов, а на мой вопрос ты так и не ответил. Нестыковочка-с.

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

(130)
"Ибо оно настолько простое, что даже не смешно, как его не реализовали... раньше..."
.
Чессгря твои слова похожи на анекдот.
- Сенсация! Сенсация! ПОЛНОСТЬЮ решена проблема с волосами на ногах у женщин!
- ?!?!?! Как? Как?
- Пусть растут!
.
Так и у тебя - все вопросы, как уже сказал 124 ты сводишь на частные случаи и в итоге - на запрет (в общем случае) корректировок документов.

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

(132)
О "частых вмешательствах" никто и не говорит. В результате сверки с покупателем в конце месяца выяснилось, что вышла ошибочка и в реализацию вместо ИП Мухамедзияров подставили ИП Мухемедзияров. Нужно ПРОСТО поменять клиента в реализации. А в сверке с поставщиком - что на достаточно ходовую позицию перепутали цену в приходе. Нужно поправить всего два документа... Согласись, на те 30-50 тыс. реализаций, что делаются в течение месяца, это мизерные ошибки. Зато чего они стоят...

(129) Еще раз: не надо.
Есть:
1)"основная" последовательность - определяет "цепочку" по товарам/контрагентам/...
2)"сбойная" - фактически означает набор сбойных точек в основной.
Востанавливаем по набору документов из основной от точки из сбойной.
В случае "единичного" проведения/отмены проведения документа, находящегося на точке сбоя - надо просто переместить эту точку следом по последовательности.
 

(136) Ну и на какой конкретно документ ты бы переместил точку сбоя? У меня это либо ПН №1, которую мы удаляем, либо все реализации от номера 1 до номера 100.

(137)
По каждому товару определил бы след. документ по основной последовательности.
И на каждый из них вписал бы признак сбоя в реестр.
Т.е.
--------------
Прих. накл 1
Товар1//след док = РН1
Товар2//след. док = РН3
Товар3//след. док = РН1
---------
При удалении допроводятся:
РН1: Записи в регистр
1.Послед. = "Партии";Объект = "Товар1";Документ = "РН1"
2.Послед. = "Партии";Объект = "Товар3";Документ = "РН1"
РН3: Записи в регистр
1.Послед. = "Партии";Объект = "Товар2";Документ = "РН3"
Ремарка: восстановление последовательности начинается со сбойного документа.

(130) "Ибо оно настолько простое, что даже не смешно, как его не реализовали... раньше...".
Yoppp, я понял кто такой Пит!!! Это великий Ферма воскрес!!!

(139) Этак мы скоро дойдем до "Политбюро расстрелять и мавзолей в зеленый цвер покрасить"....

Конечно много разных советов , некоторые интересные
но года три назад их разных обработок сваял
свою обработку - применял раз 15-20 в разных фирмах
все работает корректно
http://1c.proclub.ru/modules/mydownloads/personal.php?cid=5&lid=2994

(139) желаешь увидеть сказанное в реалиях? созванивайся - и смотри...

(142) Как твоя система обработает ситуацию, описанную в (3)?
Включая НДС с авансов, формирование книг покупок и продаж.
(вместо "ПКО" читай "взаимозачет").

(143) Да никак она у него не отработает, что не понял еще? :) Ибо там все настолько просто...
Ща Пит скажет: "Купи, увидишь" :)
Или жди вопросов.
А зачем тебе корректировать взаимозачет?
А не проще ли оторвать руки буху?
Может сделать сторно?
И т.п.

(144) работает как положено и заявлено...
излагать не буду (сопрешь бесплатно) и лень впустую писать - ты все равно не купишь...

(145) Т. е. просто запретит изменять документ? Тогда да, не куплю :)

Game over.... Press any key to continue...
.
P.S. я где то сказал про запрет?

(147)
Ну, 19, например.
Как насчет УРБД?

(pit) А я готов купить твою идею. Серьезно. Я не раз видел на этом форуме как ты на нее ссылаешься, вот только описания точно нигде не видел, хотя ты говоришь, что не раз ее рассказывал. Может хоть намекнешь, где есть ссылки на нее? Насчет цены... Это сложный вопрос. Ты должен назначать, раз предлагаешь купить. Я могу предложить, ну 50 баксов, например. Обсудим? Только я мыла твоего не знаю.

karkarde()pisem.net
но мне надо еще оформить это как нормальное описание...