Поскольку ветка, где я излагал некоторую идею по этому поводу, утонула, создам еще одну специально для обсуждения определенной методики. Итак, повторю то, что писал в той ветке.

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

Поехали дальше.

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

Ну а теперь ложка дегтя.

Проблемы начинаются, когда мы задним числом вводим приходное движение. Для того, чтобы метод работал, на нужно все время поддерживать в актуальном состоянии принцип списания ЛИФО по измерению ДатаПрихода. Это значит, что при вставке задним числом нового приходного движения, часть расходов, имеющих более позднюю дату, должны изменить свои движения, перераспределить свои списания в соответствии с ДатаПрихода этого нового вставляемого прихода. И вот тут возникает трабла, поскольку найти все эти документы расхода и откорректировать их движения - это в общем случае не очень быстрое действо, которое может тормозить оперативную работу пользователей. И отложить на потом это нельзя, поскольку нужно поддерживать состояние регистра в актуальном состоянии...

А теперь продолжим.

Для выяснения некоторых вопросов бывает полезно брать остатки на 2 момента времени - на дату документа (который правим или вводим новый) и на ТА. Приведу 2 примера.

1. Вопрос о том, требует ли наша правка задним числом восстановления последовательности по данному набору измерений. Рассмотрим ввод задним числом нового расхода. Находим ту партию, которая должна списываться нашим документом согласно ФИФО. И смотрим - есть ли на остатках эта же партия в достаточном количестве на ТА. Если эта партия есть и на момент документа, и на ТА в количестве, указанном в этом документе, то восстановления последовательности не нужно, поскольку с момента документа до ТА не было перехода в списаниях с одной партии на другую.

одна фраза в (3)
"Для выяснения некоторых вопросов бывает полезно брать остатки на 2 момента времени - на дату документа (который правим или вводим новый) и на ТА. Приведу 2 примера."

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

дальше обсуждать бессмысленно

2. О той самой ложке дегтя. Вводим задним числом новый приход. Поскольку по ДатаПрихода у нас должен сохраняться принцип ЛИФО, то возможно часть расходных движений нужно перекинуть на этот новый приход. А именно те расходы, которые идут в промежутке от этого нового вводимого прихода до следующего приходного движения (которое уже было в базе). Определить - требуется ли такое перераспределение, можно анализируя остатки партий на момент этого вводимого нами прихода и на ТА. Надеюсь, сами сообразите как. Если нет, объясню...

(5) не дольше, чем стандартный контроль остатков в типовых...

а надо - быстро....

(8) намек понял. Буду продумывать дальше...

смысл городить всю систему контроля в онлайте - есть только тогда, когда это - быстро....

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

думай... на самом деле все твои рассуждения уже дают основу решения - только правильно сложить надо...

(12) да я и чувствую, что "истина где-то рядом". :)

(2) а если пользюку ругнуться на то, что нельзя такое вставить? типа давай сам распроводи?
PS. мне кажется не кошерно менять движения, без ведома...
пользователь должен отвечать за свои вставки задним числом, а не систем

ЗЫ. а я что пропустил ветку? Пошел читать

(14) ну, видишь ли, приходное движение всегда безопасно с точки зрения возможности восстановления последовательности. Это дополнительные расходы не всегда возможны. Ты ведь не заставляешь пользователя рспроводить все документы в стандартном механизме, чтобы он потом мог восстановить последовательность.;)
Вообще говоря, так можно и всю систему парализовать. А разгребать каждый раз все равно будет программист...

(15) да там почти все - бред. Можешь конечно перечитать, если время есть...

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

+(18) здесь единственно, нужно определить ...
нарушает ли ввод задним числом последовательность или нет, что бы лишний раз панику не разводить.

(17) я так по названию темы и подумал, даже заходить не стал.

(19) и если нарушает, то просто запрещать? Боюсь, что за такие механизмы меня повесят за еггс...

(21) я думаю нужно просто сообщить в каких документах нарушается последовательность  ... а дальше на выбор:
- либо нарушаем последовательность списания
- либо распроводим руками мешающие нам документы.

права ессно на такую операцию только у избранных.

(21) а ты объясни гл. бух всю соль .. если она у тебя толковая, то я думаю она скажет, что пусть пользователи распроводят.
у тебя что ввод задним числом ежедневная операция?

(22) указывать документы - это уже вряд ли возможно. Это уже движения анализировать надо - долгий процесс. Сам факт нарушения можно отследить достаточно быстро, а вот найти эти документы - уже долго...

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

(25)  ИМХО возврат товаров от покупателя и приход это всегда индивидуальна ...
у меня допустим возврат всегда идет задним числом и это всегда брак ;)

*(26) возврат товаров от покупателя и приход задним числом это всегда индивидуально и универсальное решение здесь не придумаешь.

и вообще если у тебя не было прихода, то ты не имеешь права его продавать !.

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

(28) тогда у тебя это последовательность только для себестоимости ... а не предписанная законом...

(28) И зачем тогда последовательность, лепите партии налету, запросом.

(29) почему это?

(31) ну если у тебя допустим ГТД, что ты тогда отдовал покупателю?

(32) да, я помню про эту проблему. Но пока отложил ее на край сознания...

А если не вести партионный учет в том виде, в котором его предлагает 1с? А данные по партиям рассчитывать, когда это надо (момент вычисления себестоимости, например) а отчеты по себестоимости формируются уже по закрытым периодам по расчитанным данным

отлучусь ненадолго...

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

у вас там в ростове небывалый урожай на идеи по партионнуму учету

(37) выполняем план за всех...

(36) За работу задним числом в закрытых периодах нужно делать лоботамию без наркоза (по крайней мере, если заметят соотв. органы, что у организации меняется себестоимость продукции в течение года (т.е. в течение года за один и тот же месяц получаются разные данные), то это просто "полный вперед" => посадят всех несущих ответственность)

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

Но такой подход противоречит стандартному подходу, предлагаемому 1С.

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

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

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

Позволю себе процитировать товарища а лю 427 : "Никакого секрета нет. Как правильно сказал <33> Вы должны четко разделять понятие "партионный учет" и "определение себестоимости".
 Суть метода - отказ определения партий списания в момент проведения. В 99% случаев в момент проведения партии списываются не правильно (ГП стоит не там), поэтому в этом списании нет никакого смысла.
 Если вам в какой-то момент надо определить доступные партии товара, или посчитать отчет с себестоимостью, то просто делаете виртуальное списание в момент формирования отчета. Это конечно тормозит отчет, но поверьте не существенно. Эти замечания касаются случая "определения себестоимости". А случай "партионного учета" неплохо реализован в ТИС, это когда вы явно указываете партию товара.
<161> Конечно партионный учет в бухгалтерии - ЗЛО. А в управленческом учете чаще всего не нужен"

ИМХО, в таком методе есть один минус: отчеты строятся слишком долго, если каждый отчет будет рассчитывать все данные с нуля. А если результат периодически сохранять, тогда производительность можно существенно повысить. Но чтобы сохранить промежуточный результат, требуется обеспечить неизменность тех данных, на основе которых он получен

(41) ну в прошлой ветке Коллайдер развлекался... вандал.

(43) Коллайдер и есть Пит...

(44) гы... он ник отобрал, прикольно

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

(46) давно известный подход ... нечего интересного.
(42) это не метод Пита.

(42) а вообще, наверное это неплохо должно работать в сочетании с идеей типа той, что в первых постах озвучена...

+
ЗЫ. честно говоря надоело одно и тоже по кругу обсуждать.

(47) само по себе действительно не интересно. Но это вполне может быть элементом мозаики. Т.е. правильная организация регистров и анализ инфы в сочетании с этой идеей может быть более продуктивным...

(42) Списание партий и определение себестоимости в конце периода - лет 12-15 назад сделано в БЭСТе.... повторено пару лет назад в УПП, при этом решение в УПП подано как супер-пупер-инновация...

(49) ну, я ведь создал ветку не для обсуждения всего, что связано с партионным учетом. Я опсиал конкрентую идею, с конкретной проблемой в реализации. По-моему раньше никто не описывал этого в таком виде. Поэтому и пытаюсь направить развитие мысли в четко определенном направлении...

(42)
"ИМХО, в таком методе есть один минус: отчеты строятся слишком долго, если каждый отчет будет рассчитывать все данные с нуля. А если результат периодически сохранять, тогда производительность можно существенно повысить. Но чтобы сохранить промежуточный результат, требуется обеспечить неизменность тех данных, на основе которых он получен"


по крайней мере в БЭСТе расчет делается при закрытии месяца. И закрытие месяца в БЭСТе очень жесткое - все, ракета улетела и править просто нельзя...

(52) я про (42) год назад мы это уже обсуждали, странно что ты этого не помнишь

(51) в УПП сейчас 2 решения и не одно из них не похоже на (42)
первое это обычное развитие 7го .. списание по факту + корректировка регл. документом
2е очень похоже результат нашего прошлогоднего обсуждения.

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

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

Вообще неплохо бы определиться с ответами на след. вопрос:
- Нужна ли нам оперативная себестоимость, если нужна, то зачем?
- Нужен ли нам партионный учет. Если нужен, то есть ли он реальный на складе или он просто виртуальный для целей себестоимости.
- Чем обусловлена работа задним числом.

хм

+(56) если мы будем обсуждать сферического коня в вакууме, то получим аналог бредового решения от 1С.

(57) и ты к нам решила присоединиться?

тоже поклюю

(0) Делал нечто подобное на 7.7
Измерение ДатаПрихода лишнее - дату можно брать прямо из партии..
Из плюсов 1) работает на порядок (!) быстрее, 2) регулярное восстановление последовательности  можно забыть как страшный сон.
Из минусов
1) последовательность списания партий может быть нарушена. Решается либо учетой политикой  "а хр.. найдут!", либо все же препроведениями перед закрытием периода.
2) Иногда возникает ситуация когда на момент списания партия есть, а не списывается патаму что уже списана позже. Придется приучить пользователя смотреть списания после текущего, это непросто...
3) В 8-ке мне показалось проще перепроводить все списания при измении задним числом прихода, благо это теперь можно.

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

(61) партионный можно вести без складов, для фирмы в целом.

(61) да, наверное. У нас партии от складов отдельно.

(62) не имеет значения. Имеется в виду произвольный набор измерений. Можно это считать одним измерением многомерного пространства и рисовать плоский график - время/количество, имея в виду изменения по набору конкретных значений измерений, сколько бы их ни было...

(61) А если партия -- сам документ прихода? Тогда естественным путем оператор не оприходует один и тот же товар несколько раз одной партией

(63) для изложенной идеи тоже не имеет значения. Прорблему можно рассматривать в общем виде...

(64) ну я так в частности, а то человека запутаешь. Ессно измерение лучше ... и запрос легче и прозрачнее.

(65) можно так. Просто требование списания по ФИФО относятся к внешним для нас приходам, а движение прихода (которое в этом случае создаст нам новую партию) может быть внутренним документом (перемещение, корректировка серий/характеристк и т.д.)

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

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

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

(69) Имхается мне что ты себя запутаешь абстрактыми рассуждениями ;-)

(71) поперемещай товар между складами туда -обратно и твоя проверка с фильтром по дате прихода (документа партии) не будет работать корректно именно поэтому и вводиться новое измерение "Дата прихода(пуступления)".

(73) Склады отдельно от партий =  при перемещении между складами регистр партии вообще не трогаем.

(73) абсолютно точно.
(70) я сейчас не веду речь о том, какой набор стандартных измерений используется. В 8 есть склад, в 7 МОЛ. Можно вести или не вести учет в разрезе организации (т.е. иметь ее измерением), можно вести или нет серии и характеристики. Так вот возьми стандартный набор измерений любой из этих конф и считай весь этот набор одним измерением многомерного пространства. И по значению в этом измерении у тебя есть только приходы и расходы во времени. Все.

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

(74) читаем (75). Неважен набор измерний. Важно, чтобы по этому набору каждый приход создавал новую партию, чтоб после этого она только монотонно убывала...

Кому -нибудь кроме Терва принцип идеи ясен? Или я слишком сложно изъясняюсь?

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

(78) Читаем (72) ;-).
А если серьезно, то идея вполне рабочая. (60) +- полученые на практике.

(76) Кстати, всплывает нюанс: реализуем товар по ЛИФО. Далее покупатель нам его возращает:
а) если мы "отмотаем" ленту партий назад и найдем нужную, тогда возврат портит нам картину монотонного убывания ункции
б) если мы создаем партию, тогда может быть такое, что эта партия будет реализована тогда, когда будут реализованы другие партии с датой возврата (но ведь эта партия намного старше). Если идет реализация чего-либо без сроков годности -- ладно. Иначе, можем продать просроченный товар

(80) да я то ясно понимаю смысл того, что говорю. :) Мне просто надоедает спорить о том, ведем ли мы этот учет по складу, Молу или еще чему-нибудь. Хочется наконец самой идеей заняться... Так как ты на практике это используешь, если у тебя функция остатка не монотонна? В этом случае данные на ТА тебе ничего не могут дать....

(81)  "отмотать" без вариантов.
"монотоннаое убывание функции" это лишь слова,  скрок реализации, даже если нет срока годности реальность.

(81), (83) Хотя есть вариант создания новой партии, но с датой, узнанной после "отмотки"

(81) погоди. По измерению ДокументПоступления у нас идет списание по ФИФО (как того и требует учетная политика). Это по нашему служебному измерению (ДатаПрихода например) списание идет по ЛИФО. И любой возврат, перемещение и что угодно еще (любое приходное движение) будет создвать по этому измерению новую партию. Именно для того, чтобы обеспечить дальнейшую монотонность. Без нее ничего работать не будет...

+85 Т.е. мы не отматываем назад и не ищем нужную, а создаем новую с текущим ДатаПрихода...

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

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

(87) Функция остатка имеет начальное значение, отличное от нуля. И не возрастает

А вот пара простых вопросов:
1.можно запросом вытянуть все сочетания документ x номенклатура где нарушен принцип фифо?
2.с измерением последовательности по номенклатуре слабо написать восстановление движений по регистру с учетом фильтра по списку номенклатуры партий без проведения документа?

(88) а возвраты???
(87) для меня базовая идея проста как мычание - остатки проверяем на ТА и гарантируем что после любого списания минусов _на ТА_ не будет. Исправление поступлений проверяем отдельно. Сосбвенно все. Результат см выше.

(91) вот и я тебя спрашиваю "а возвраты"? Если ты их пихаешь в ту же партию, что была, то на ТА инфа бесполезна. Ради этого я и говорю про еще 1 измерение ДатаПрихода, поскольку именно из-за возвратов например ДокументаПоступления с его датой недостаточно. Именно поэтому и надо создать новую партию с тем же ДокументПоступления, но новой ДатаПрихода...

(90) г... вопросы.

(90)
1. непросто
2. В 7-ке нельзя было провести другой документ из обработки проведения, в  8-ке мне тоже кажется что такой подход лучше. Правда я всеж перепровожу док полностью.

+92 грустно мне...

(94) полное проведение может быть намного дольше чем проведение только по одному регистру

(95) вот и я о том же, каждый год одно и тоже ... вообще удивляюсь как pit за 10 лет не удавился еще.

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

(97) он великодушный. Считает достаточным дятлами всех называть. Исключительно добрый человек, а ведь мог бы и пулемет достать... :)))

сотка Ваще проще модернизировать процедуру восстановления последовательности чем городить инновационные схемы

(100) ты можешь гарантировать успех восстановления при произвольной работе задним числом?

(92) Да, согласен, есть и такая проблема... видимо поэтому в типовых оно и сделано по-другому.
(97) а кто такой pit?

Понятно что последовательность может быть восстановлена в любом случае. Важно чтобы процедура восстановления выполняла только действия которые действительно необходимы а не тупо проводила все документы с какойто даты.

(103) фигасе...

(102) .2  в (5) pit
(103) обычно последовательность с первого раза не восстанавливается никогда ...
(104) +1

(102) пит, он же улю 427, он же а лю 427, он же теперь коллайдер...

(104) и все же .. как БЫСТРО проверить, нарушает ли приход последовательность?
(106) коллайдер по неволе, он долго под него косил вот и остался без ника ;)

(107) быстро, в смысле по инфе только на ТА, пока не знаю продумывать надо. По остаткам на 2 момента времени - легко...

(108) и в догонку, при распроведении прихода, нужно тоже проверять была ли уже списана партия или нет.

(105) чо документы не проводятся :)))

(109) это тоже контролировать можно. Равно как и контроль неухода в минуса...

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

(111) можно, в принципе алгоритм должен быть такой же как у реализации, только партия конкретная проверяется на возможность списания...
остается только контроль ввода прихода задним числом, если бы удалось реализовать БЫСТРЫЙ алгоритм (22) мне бы этого для счастья хватило бы.

(109) (111)
При распроведении прихода в предложенной схеме достаточно посмотреть, чтобы по партиям, созданным этим документом на ТА были нулевые, неотрицательные остатки.

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

(114) ну, в 8 дата включает в себя время. А в 7 измерение может содержать не дату, а ссылку на приходный документ или служебный справочник. Не суть....

(114) ты лучше объясни как обойти (2)...

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

(117) ты немного не в теме. Речь шла об уходе в минуса при восстановлении последовательности (нераспределеннны партии)...

я такие фиксирую в доп регистр

(119) я тоже. И что дальше?

э последовательность восстановлена ... с учетом недостатков :)))

(121) с учетом недостатков - это сильно. Может тогда вообще нафиг восстанавливать? :)

хотя конечно строго говоря последовательность не является восстановленной но косяки пользователей автоматической процедурой все равно не обработать

(118) кстати в v7: Кстати, а разгадали секрет метода У ЛЮ - 2? orefkov озвучил интересную проблемку:
"Метода работает хорошо, единственный минус - иногда неоправдано не разрешит уменьшить задним числом количество в приходе, так как вся эта партия уже списана, хотя при полном перепроведении доков расхода они бы могли списаться с других партий."

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

Хотя, при перепроведении идет сначала распроведение, может быть действительно не даст распровести....

(126) кстати почитай еще здесь v8: v8: Нашел суперрешение проведения задним числом

(127) надо будет перчитать. Давненько это было. Наверняка я там даже участвовал..

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

(128) вот кстати оттуда интересная мысль:

"  Темный Эльф
91 - 12.10.06 - 22:53
Как можно быстро получить список документов, в которых участвует партия? Или, в общем случае, ТМЦ? Может вести регистр сведений или периодический реквизит по ТМЦ и партии? Тогда мы быстро получим искомое без запроса по датам, который (по крайней мере в 7.7) выполняется через перебор таблиц и притормаживает."

(129) дошло наконец? как это сделать быстро? вот в чем соль;)

теперь вам придется без меня трахаться - этот мелко распальцованный Асмоди сорвался в псих и забанил меня до 2019 года...

Так что ждем срока открытия секретов партионного учета...


Всем привет....

(131) До 2019 - это конечно долго. Может скостит немного за хорошее поведение? Годик скажем? :)))

(131) так можно из-под другого ника постить... правда могут не узнать, но так даже и интереснее

(131) Будут ходить легенды про человека, который и вправду знает метод Пита :)

Иэх, опять самому думать придется...

Так вроде решили уже эту проблему давно ?
Оперативное:
При проведении накладной смотрим остатки по партиям, если есть то списываем.
Задним числом:
Смотрим остатки партий на дату заднего проведения. Если есть остатки тех партий на текущий момент(значит они не проданы), то все ок и проводим.
Да, и при возвратах нужно делать новые партии.

(136) убей себя.

(10) быстро - это конечно можно. А у тебя регистр при этом вообще в 0 закрывается? Наверное каким-нибудь регламентным документом?

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

(139) тук-тук? ....
туки-туки?

(92) (102) Кстати, в свое время было не нада - давно это было, а сейчас, наверное, и решал бы проблему таким доп измерением (ДатаПрихода). Причем само списание оставил как есть - т.е. фифо по датам доков поставок, а доп измерение исключительно для контроля косяка с возвратами\перемещениями.
Так и не понял зачем тебе лифо по ДатаПрихода и вообще монотонность убывания остатка по партии. Ну да, есть у нас партия, потом нет - продали, потом снова есть - вернули... нам же важно знать сколько времени прошло с момента поставки.

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

А что скажут Иммортал и Злобней фей? Не думали над идеей?

Мда. Начиная с (3) действительно мусор. Протупил я. Теперь мысль такая.

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

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

(144) Раздели количественный и списание себестоимости как два самостоятельных процесса. Или веди себестомость единицы продукции. Так будешь долго вызывать восстановление последовательности как магамэйджик

(146) Считай, что на момент списании партии ее себестоимость не определена вследствии того, что не разведены допустим допрасходы, которые поступают с задержкой 3 дня. Как тогда ты правильно спишешь с/с? Задача типо )

(145, 146) видишь ли, в той постановке задачи, которую я озвучил, вопросы себестоимости вообще не были затронуты. Речь шла о принципе списания ФИФО для партий прихода...

+148 и если все-таки удастся решить задачу в этой постановке, то и вопрос себестоимости будет решен автоматически...

(148) почему именно проверять на дату ТА? Ведь все остальные даты между датой прихода и датой ТА тоже надо проверить. Там тоже могут возникнуть минусы.

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

(150)не тупи...
зы. еще один. пора уже записывать.

Блин. Вы вообще читаете идеи, которые описаны???

(153) кому это нужно? он читать то умеют?

Однако нада делать закрытое обсуждение

(155) ну дык я все надеюсь, что кто-то вникнув что-то умное скажет. Идея то не доведена до ума. Как обходить сложности пока не ясно...

(147) в типовой УТ если допрасходы относятся на уже списанную партию, то стоимость списания корректируется.

(157) кстати, а может правда (158) ? концом месяца спец. документом такие косяки корректировать в куче и не париться?

(159) это принцип другой. Никак не отменяет по сути принципа последовательности. Я хочу пройти до конца вполне определенную идею. В случае успеха это действительно буде лучший вариант, поскольку без всяких восстановлений ГП позволит на любой момент времени иметь актуальную инфу...

(159) не выходит. нада поддерживать монотонность функции остатка оперативно.

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

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

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

(162) Ты немного путаешься имхо между ФИФО, партиями и списание. Смысл партий (если они не несут информационную нагрузку - например номер рулона кавролина со своей погонной длиной или дату выпуска лекарства) только в способе списания СТОИМОСТИ. Больше они не нужны. Если у тебя количество списано верно - без уходов в минус, то все парционные списания повлияют лишь на сумму деб остатка СТОИМОСТИ на 41-м. А это можно сделать и в конце месяца. И "восстановление" партий представляет из себя не проведение всех тяжелых товарных документв, а заполнение и проведение одного документа. Понимаешь о чем я?

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

(165) + В принципе если есть традиция "плотно" закрывать периоды, то и списание количества можно делать по средневзвешеной - т.е. уходы в минусы не страшны если итог положительный на конец периода. Но это не готично, хотя избавляет от кучи гимороев со временем документов )

(165)>> И "восстановление" партий представляет из себя не проведение всех тяжелых товарных документв, а заполнение и проведение одного документа.

Хрен редьки не слаще. Суть одна и та же...

(167) Ну здорова! перепроведи месяц в УПП - восстановление парционного. Сколько по времени? Суток трое-четверо - при том, чт ос базой никто не может работать (это до отложенного проведения)

(165) Ага, ты о производстве ;-). В торговлеоч любят оперативно считать наценку.
и очень не любят "закрывать" периоды.

(168) +21 регистр в каком-то доке насчитал

(169) В торговле любят делать скидки клиентам, когда имеют процент с оборота а не прибыли, а потом кричать что программа не работает когда продали ниже с/с )

(169) Обходится легко! максимум себестомости единицы ставится как планка для продажников. А пофиг что пришло дешевле - я что буду следить какую партию продаете.)

(172) Вообще бухучет для с/х рулит - все котловым за год!

(172) ага, только вот планка по разному молжет ставится... +10% от цены покупки например. Вот только не надо про "правильную" организацию процеса продаж, автоматизацию хаоса... если бы всегда автоматизировать порядок, так и (0) не нужен.

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

Что, не выходит у уральских Данил каменный цветок?

(174) можно вместо скидок использовать уменьшение наценки на базовую стоимость. Тгда ниже с/с точно не продадут никогда...

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

Как я могу сказать... ждите 2019 года. Освобожусь - отвечу.

асмодея, мелкого беса, в ад нужно...

(179) Забей на это. Вспоминать об этой мелкой шелухе - моветон..

(174) скажи тогда пусть на складе разберут товар по партиям покупки. Ответ начсклада и будет ответом продажникам. Наценка считается от базовой себестомости, а не себестоимости партии

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

кстати, идея в (144) не всегда позволяет по инфе на ТА дать ответ о необходимости перераспределения партий. Есть все-таки ситуации, когда для ответа на этот вопрос нужен еще и остаток на момент документа...

(184) Зачем остаток на дату документа, если есть данные на ТА в разрезе дат прихода? этого достаточно.

(185) есть ситуации, когда недостаточно...