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

ps:
Мне бы хотяб чтоб количество в минус не уходило...Т.е. точная себестоимость не особо нужна. Валовку можно подсчитать потом, восстановлением последовательности (шеф на это согласен)...
Спасибо за советы.

Вот вопрос в том и стоит. Как сделать нормальный нетормозной контроль остатков при проведении задним числом...

(0) А если сделать документ или обработку "Закрытие" с периодом в день, неделю или месяц (как удобнее), и в нем выбирать список документов, которые нельзя редактировать.

(2)Можно чуть подробнее алгоритм... Чета ничего не понял...

Нужно вообще запретить перепроведение Документов задним числом?

А, Вы про это :(... я бы сам рад, но это невозможно...

Тогда не пойму, что именно нужно!?

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

(0) Можно проверять и в неоперативном режиме... хотя это не есть гуд.

(8)Это почти ничего не даст. Это и так есть у меня. И это гуд.

Я, конечно, не уверен, но: а что, если при проведении, а точнее перед формированием записей в регистры, получать остатки на последний документ ИБ по нужным позициям и, если нет нужного количества, т.е. того, которое поставил пользователь, выдать соответствующее предупреждение и отменить проведение.

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

Я такое делал в 7-ке комплексной, но работало медленно, да.
В 8-ке наверное можно быстрее сделать - выбрать обороты по регистру, соединить с таблицей документа, полученную таблицу посчитать. Хотя - не знаю, может не получится, в УТ не копался.

(11)Не, тоже долго... там можно успеть сигарету выкурить...

(0) изучай
Ну что, продолжим про парт. учет долбить?

(12) можно быстро сделать, но у меня так руки и не дошли воплотиь...

(14)А какую методу Вы за основу взяли ? Прочел ветки. Что использовать ? Контроль минимумов или анализировать остатки на дату документа и ТА ? Догнать блин пока не могу...

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

Именно так и можно только делать. Я по каждой позиции высчитываю на каждый день остатки чтобы по каждой позиции найти минимальные запериод от даты документа до конца периода. По-моему это можно сделать одним запросом к к виртуальной таблице Остатки

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

(16) а юзеры пусть покурят пока...

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

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

(20) и что, будет контроль не только на дату документа, но и ухода в минуса от документа до ТА?

(17)А не долго ли это будет ?
А если учет МПЗ ведется по средней ?

Так ты купил эту методу  "у лю 427" ?

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

+24 собственно, наверное достаточно остатков вообще только на ТА, если они есть, то и на момент редактируемого документа будут. Проверь этот момент, я не уверен. Тогда вообще очень быстро все будет...

Кстати, что за конфа у тебя вообще?

УТ.

(27) идею понял вообще?

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

(29) интересно, а налоговики за такие вольности по шапке не надают? Как себестоимость списывать, если есть моменты, когда продажа идет в минуса?

(30) У него УТ, а ты ему про ТА рассказываешь.

Вот здесь еще почитал. http://abelov.com/kuban/169830.html Там п.15 интересен.
Вот это вообще не понял:
>>наверное достаточно остатков вообще только на ТА, если они есть, то и на момент редактируемого документа будут.
Как же они точно будут ? Они могут быть могут не быть...
Нужно как то именно обороты от даты документа до ТА смотреть...

(31)Да это понятно все...

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

(32) значит не понял. :(
(31) не имеет значения. Понятие конечно упразднили в 8, но суть осталась та же. Остатки на момент оперативного проведения расчитаны..

(34) ясно, надо будет глянуть...

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

все не осилил, тема - боян, обсасывалась 1000 раз.

моя идея:
новый регист в котором в измерение Номенклатура, Партия (и так далее) и ресурс ДатаЗапрета, КоличествоЗапрета

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

(29) этот механизм есть и в УТ, называеться поступление по ордерам, только гемор страшный

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

(39) это не то
(40) долбанешься такой регистр закрывать по этому измерению

(41.2) да нет, думаю, это не сложно.

Не, я понял эту методу...тут это же разжевано: v8: Оперативный контроль остатков (242 пост)

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

(42)Еще раз. При партионном учете:
1.Берем начальные остатки партий и оборот по расходу партий на ТА, но только тех, у которых дата меньше даты редактируемого документа.
2.Если начальные остатки партии минус оборот по расходу этой партии больше или равен количеству, которое пользователь вбивает в документе задним числом, то все нормально, даем проводить. Иначе посылаем.
Так ?

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

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

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

(46) теперь въехал?
Любой анализ оборотов с момента документа до ТА обречен на тормоза. А вот остатки на конкретный момент времени, тем более на ТА, когда уже все и так расчитано, будет происходить мгновенно....

Да. Получается, при ЛЮБОМ приходе товара нужно делать новую партию ?

При любом движении Приход...

(50, 51) да.

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

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

Прочел все твои ветки + еще с кубани. Там "у лю 427" про свою методу упоминает... Это она и есть ?

Хотелось бы его критику послушать...

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

Еще я прочитал "у лю 427", что вроде как не обязательно делать новую партию при возврате или перемещении, но работать будет медленнее...что скажешь ? Это как так делать ?

(58) я ж говорю, я не продумывал все технические нюансы, только принципиальную идею. Еще эти нюансы будут связаны с конкретной конфой. Например в 7 ТиС для партий используется справочник, а в 8 УТ документ оприходования...

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


P.S. такое решение есть внедренное. На 7-ке. Работает. Самописька....

(59)
"Например в 7 ТиС для партий используется справочник, а в 8 УТ документ оприходования..."

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

Про контроль промежуточных итогов ясно. От этого почти сразу отказались.

В УТ партией является документ основания. Это так.
Но в регистре партий добавилось измерений:
-качество(про упаковку)
-серия(это про срок реализации и ГТД)
В чем гемор если для контроля за минусами, я буду при движении "приход" всегда создавать новую партию ?

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

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

Увеличение кол-ва измерений - это просто втыкание дополнительных тормозов...

P.S. правильный контроль остатков автоматически даст правильную себестоимость

>>P.S. правильный контроль остатков автоматически даст правильную себестоимость
Блин, вот и мне так кажется... что еще можно придумать, кроме создания новых партий ? Тут и с себестоимостью все нормально будет...
Не хотите подсказать, так хоть где это реализаванно скажите ? В какой программе ?

Впервые это сделано мной при добавлении парт учета в типовую бухию
Но известны и другие реализации с другими подходами и принципами - я не одинок в поисках...

А если партионки нет, то вообще никак, да ? (Разворачивание движений я не рассматриваю впринцыпе...)

Еще мне не дает покоя пост 262...(про можно не делать новую партию)
v8: Оперативный контроль остатков

(0) не сразу догнал, что хочешь, но может наподобие вот этого сработает?:

текстЗапроса = "
  ВЫБРАТЬ Регистратор, Номенклатура, КоличествоОстаток
  ИЗ РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты(&Дата1,&Дата2,РЕГИСТРАТОР,,Номенклатура В (&СпНоменклатуры))
  ГДЕ КоличествоРасход > 0 //учитывает те документы, что списывают...
"

ПАРМЕТРЫ: Дата1 - дата док-а, редактируемого задним числом
Дата2 - рабочаяДата()
СпНоменклатуры - список номенклатуры из документа, который меняют задним числом...

А дальше - пробежать по таблице и если КоличествоОстаток < 0, то ругаться благим матом...

Можно еще эту таблицу объединить с аналогичной из Регистра ТоварыОрганизаций

+(69) Думаю, этот методо будет быстро проходить... хотя, надо пробовать...

(70) фигня

Приход +10
Расход -10
            <-- сюда добавим Расход -10, твоя проверка это позволит
Приход +10

+(71) + блокировка таблицы на 20 минут (это у меня так) и жесткий посыл сервака в даун...

(71) хорошо, сначала переберем все документы Реализация, а потом для них сформируем эту таблицу (по связи)...

(72) ну нихрена себе... 8-[   ]

(74) а че ты хотел... Елозить .опой по гвоздям небезопасно....

(75) Пит вот скажи когда ты состаришься станешь сентиментальный - выдашь наконец свою идею партионного или нет ? )

(76) готов продать хоть сейчас...


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

(77) Ответ из той же эпохи ))

(77) Сколько?

пиши - договоримся...

(80) куда? ???_???@???_??.???  ??????????????

karkarde@pisem.net

Книга знаний: Альтернатива партионному учету

Может сдесь есть полезное.

(72) ну и к какому решению склоняешься? Определился уже?

Да. Буду делать новую партию при движении "приход". Думаю, если делать новую партию, то минусы будет контролировать просто...Во всяком случае не вижу мест где возможно попадалово. Если не так, поправь :)

(85) если хочешь, кинь потом посмотреть как сделал. Может посоветую\покритикую как лучше...

(85) Все так. Единственный момент, который тут есть,- это то, что таблица такого регистра будет еще больше, чем обычная таблица партий, которая сама по себе обычно самая большая в базе. Но логарифмическая зависимость скорости получения результата от объема таблицы позволяет надеяться, что это не критично...

(81) ответил...