можно ли использовать новую методику контроля отрицательных остатков в 81 #573403

Можно ли использовать новую методику контроля отрицательных остатков в среде платформы 81. Хотелось бы аргументированный ответ..

Можно ли использовать новую методику контроля отрицательных остатков в среде платформы 81. Хотелось бы аргументированный ответ..

о чем это ты?

об этом:

про сначала двинули, потом получили минус, потом откатили транзакцию

именно!

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

в 8.1 движения вообще лучше делать на сервере

быстрее должно работать.. просто этот метод описан как метод для 82, но не объясняется почему.. может этот метод возможно применять и в 81?

а в 8.1 у документа есть свойство не менять модифицированные движения ?

нету вроде как..

может об этом стоит задуматься

Увидев этот метод в Радченко, подумал: "Ля, какая ересь. Провели, потом откатили -- это ж лишние телодвижения над базой, снижение производительности." А вот у Чистова прочитал: "Нет необходимости получать излишние данные (остатки) для проведения документа. Ведь мы чаще все же записываем документ с правильными цифрами и он проводится, чем документы которые уводят остатки в минус.", и чорд, а ведь верно.

Дело не только в том, что "мы чаще все же записываем документ с правильными цифрами и он проводится, чем документы которые уводят остатки в минус". Там еще выигрыш по времени действия установленных блокировок. Только от момента записи до окончания проведения. В случае классического способа проведения блокировки необходимо устанавливать раньше - перед/в момент чтением остатков.

задумался.. не вижу препятствий применять этот метод

но в новом способе остатки тоже считаются и тоже во время блокировки. в чем тут изюм?

Будешь дважды записывать наборы записей в регистры. Первый раз принудительно Движения.Записать. Второй раз - автоматически по окончании выполнения обработки проведения. В 8.2 при установке свойства "Записывать выбранные" по окончании обработки проведения будут записаны только те наборы записей, у которых свойство Записывать = Истина. Метод Записать коллекции Движения сбрасывает это свойство в значение Ложь, исключая таким образом повторную запись.

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

Попытка использования контроля отрицательных остатков при любых движениях - это плюс.

Блокировки устанавливаются одинаково, но в разное время: Классический метод: Установка блокировок Чтение остатков Формирование наборов с одновременной проверкой нехватки. Запись движений по окончании обработки проведения. Снятие блокировки Новый метод: Формирование наборов Запись движений !Тут устанавливается блокировка Чтение остатков Окончание обработки проведения Снятие блокировки. Как видно, во время формирования наборов записей (которое в некоторых случаях может быть не фига не быстрым) блокировки отсутствуют. Соответственно другие пользователи могут работать с этими же наборами по этим же измерениям.

А разве 8.1 анализирует Модифицированность набора?

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

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

а кто-то всё ещё считает себестоимость при проведении документов?

автоматический зачет аванса по документам взаиморасчетов, например?

Издеваешься?

ну может быть. у нас авансы к заказам привязаны, там особых проблем нет

И еще одно замечание. Учитывая все выше сказанное, и если исходить из того, что для проведения по регистру не нужны текущие данные регистра, то набор записей и в классическом методе проведения можно сформировать до чтения остатков (т.о. до начала блокировки, т.о. также сэкономить время формирования набора), при этом в запросе чтения остатков можно также учесть данные уже записанного документа и получать в выборку только отрицательные. Кстати сказать, на 77 прямыми запросами через 1сpp так и делали, уже давно.

Ура! Наконец то в этой ветке (ИМХО) копья по теме доломали и сожгли. Сколько их тут было прежде, не сосчитать...

это методика нужна для доков с возможностью оперативного проведения

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

Сначала ты подумал "ля, какая ересь". Потом ты подумал "Чорд, а ведь правильно".

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

где статья и причём тут параметры виртуальной таблицы ? о_О

полный бред, ни какого отношения к предмету топика

+ тем более проще приявязвать строки ТЧ к строкам движений по регистру

???

Вот 2 видео по теме: Может быть что то прояснит.

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

Судя по всему - если очень много строк - по новой методике будет выигрыш, если мало - пофиг

Вариант А) Перед проведением сняли остаток, посмотрели - не хватает - фиг вам... Вариант Б) Во время проведения - сняли остаток, попытались списать - не хватает - фиг вам... Вариант В) Во время проведения - списали?, после списания посмотрели остаток - не хватает - фиг вам... Какой из вариантов лучше? ИМХО А) - но его никогда не было в типовых - раньше Б), теперь В).

стоп-стоп! а чем А) от Б) отличается? способом сравнения двух чисел?

А как же экономия на записи? При старой методике запись наборов делается дважды: первый раз перед снятием остатков (удаление движений в 8.1) второй раз - по окончании обработки проведения. По новой методике - один единственный раз Движения.Записать. Запись на самом деле занимает дофига времени.

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

Перед началом обработки роведния старые движения документа

пишутся только модифицированные наборы! В 8.2 у документа тоже есть такой способ записи движений, он как раз и остался от 8.1 и 8.0

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

и чего?

в 8.1 и 8.0 движения писались дважды: первый раз - пустые наборы второй раз - модифицированые

см.

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

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

пустые наборы пишутся перед началом обработки проведения если у документа стоит признак Удалять движения автоматически. Это тут причем?

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

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

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

Да, я предлагаю так. Но, во первых - вы правы по поводу "сто питсот раз" (хотя и это решаемо), во вторых - в платформе 1С это невозможно...

Ты издеваешься? Почему надо по сто раз тебе одно и то же рассказывать? При оперативном проведении по старой методе тебе придется записать пустой набор принудительно, чтобы получить остатки БЕЗ учета старых движений документа. А потом еще раз по окончании обработки проведения.

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

+ к Конечно при неоперативном проведении (остатки на МоментВремени) старые движения можно и не удалять, записывая пустые наборы.

Еще раз: при необходимости расчета себестоимости новый метод использовать невозможно. Так что и обсуждать нечего. Новый метод используется там, где нужно ТОЛЬКО контролировать остаток.

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

Не, это тут совсем ни при чем... Давайте отвлечемся... У вас в саду на яблоне висят пять яблок. Пришел чел и говорит: А) продай мне три яблока Б) продай мне шесть яблок Ваши действия?

в порядке поступления. первому три, второму два (если захочет)

и вообще, есть отдел маркетинга и рекламы, вот пусть они и объяснят челу, почему ему нужно именно пять яблок

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

Не, не так. Чел один, запросов (вариантов) два... 1) Сказал продам, пошел в сад, сорвал яблочки, отдал 2) Сорвал яблочки, если три продал, если пять - не хватает 3) Пошел в сад, посмотрел сколько яблок.... далее алгоритм понятен 4) Продал, взял деньги.... шесть нет, отдал деньги ну или .... Вот как бы вы действаовли с точки зрения автоматизации?

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

Вроде кто то писал что будут проблемы. Типа в 8.2 раз записал и все, автоматом при проведении не запишутся, а в 8.1 будет полюбому еще раз записано(хотя в документации сказано что только модифицированные наборы должны записаться)

Мне твоя логика понятна. Но остается один вопрос. Предположим, я, еще до того как дал согласие на продажу яблок, проверил их наличие. Яблок хватает. Ок. После этого иду рвать яблоки с дерева, прихожу - а яблок осталось два (какая-то падла сорвала их, пока я давал добро на продажу). И что?

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

Обнеси заборчиком дерево на время пока бегать будишь

+ к

Еще один. Ну при чем тут модифицированность? В 8.1 запись делается в любом случае дважды - первый раз (перед обработкой проведения или в самой обработке если НеУдалятьДвиженияАвтоматически) пустые наборы, второй раз - по окончании обработки проведения вновь сформированные. В 8.2 - пустые наборы не записываются. Старые движения живы, пока не запишутся новые.

Установить блокировку вне транзакции?

Вариант перед я вообще не рассматривал, тогда трижды от начала проведения, первый для очищения, второй для проверки, третий автоматом

Почему вне? в Транзакции при проведении

т.е. в 8.2 не надо очищать движения регистров перед перепроведением документа  с вариантом "НеУдалятьДвиженияАвтоматически"?

а нафига? сами удаляться когда ты туда новые наборы писать будешь.

а откуда такая уверенность то туда будут записаны новые данные?

>> надо еще учесть возможные текущие движения А старые движения Пушкин учитывать будет?

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

Для это дятел-программист должен написать Движения.МойЧудоРегистр.Записывать = Истина;

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

+100500 Вот и я о том же в .

Они ж к дереву не смогут подойти, даже остатков не прочитают, в чем проблема то?

Проблема в том, что ты ветку не прочитал. агитирует 1С за проверку движений ДО начала транзакции. Когда ни каких блокировок еще нет. Лично я - против.

да Snovy не прав, это было ясно с самого 1го его поста

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

в пункте 2 вместо "обработке УДАЛЕНИЯ проведения" надо просто в "обработке проведения" И весь профит от нового метода коту под хвост. Но формально его использовать можно. А толку?...

если у регистра "МойЧудоРегистр" были движения а при перепроведении документа модифицированности это регистра не произошло то данный регистр сам обнулится, так?

ты не прав, там все правильно написано

Я уже устал для тебя повторять. Там не правильно написано.

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

ясно, пасиб.

и что? В 8.1 у коллекции движений нет метода Записать, поэтому там мы будем записывать сам набор записей, даже если туда ничего не добавлялось он запишется, тем самым очистит старые движения.

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

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

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

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