Проверка остатков после проведения #705252

Здравствуйте уважаемые. У меня такой вопрос. Сейчас есть новое веение то что. После проведения документа проверять отрицательные остатки на момент времени. Я не совсем понимаю зачем?. Радченко считает что так будет правильно особо не объясняя почему. Мой знакомый главный бухгалтер говорит об об обратно то что Нужно вообще сделать колонку остатков и до проведения выдавать ошибку об отрицательных остатках. Как вы считаете как лучше и почему?

ключевое слово - блокировки.

В смысле?

вот тебе ещё ключевых слов: новая методика проведения документов 1с

Ясно. Спс.

-- Мой знакомый главный бухгалтер говорит об об обратно то что Нужно вообще сделать колонку остатков Бух пепелит напалмом, чо. Вообще, тема сомнительная. 1С-методолог считает, что непроведение из-за нехватки остатков случается много реже, успешное проведение. Потом, чтобы взять понять - хватает ли остатков для документа, надо вычислить остатки - НА МОМЕНТ документа. А это дорого. А можно документ провести,  и типа взять результат с итогов, что дешевше. Намного. Правда возникает еще куча вопросов, типа изменений задним числом и прочая и прочая... Какие-то методологи и УТ11 придумали - чем их там кормят?? Мое мнение - вообще не проверять на остатки - глупости всё это.

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

"Радченко считает что так будет правильно особо не объясняя почему" ой, не гоните, уважаемый.. все всё прекрасно объясняют, и Радченко, и Гилев, и Чистов... просто видимо вы не хотите читать и понимать

iamnub Полностью с вами солидарен. Я думал  я один такой по незнанию. А оказывается мои знание еще Огого..

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

+ блокировки ближе к концу транзакции возникают

И возникает эта проверка не после проведения, а после записи движений в регистр.

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

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

Чисто 1С-овская фича, применяемая только при такой же 1С-овской фиче - "оперативном проведении". Я не знаю, что это за контора, где продаваны фигачат двадцать заказов в секунду и где (внимание) при такой работе расчет остатков на складе имел бы значение и смысл. Всю жизнь жили без "новых методик" - и еще проживем. Главное понимать - что подходов и методологий - множество, следовать им или нет - личный выбор каждого. А то Радченко сказал - всё, мессия пришел.

Методика применима далеко не всегда, но если есть возможность сделать по ней - надо применять ее.

почему ближе то? если по старой методике: Чтение+ПроверкаОстатков, Запись то по новому: Запись,Чтение+ПроверкаОстатков те же действия в разном порядке при этом блокировка накладывается при первом действии в обоих случаех

по старой методике: проверка старых движений, удаление старых движений и только потом Чтение+ПроверкаОстатков, Запись . То есть там реально были тормоза и блокировки.

При сдаче на сертификат, если не используешь новую методику - изнасилуют в извр. форме.

> проверка старых движений это что за проверка?

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

такие проверки есть в типовых в старой методике?

Где-то я их видел, но не помню, где.

конечно есть и они занимают времени побольше, чем три остальных этапа

и где такое можно увидеть?

это к

в обраьотке проведения прям сначала.

имею ввиду в какой конфигурации

во всех

Прям за живое задел)    MadJhey Тоесть при здаче экзаменов лучше использовать новую методику? Учту СПС.

я спрашивал про "по старой методике: проверка старых движений" но уже увидел в УПП

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

подниму

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

ну так для этого на момент проверки остатков удаляются движения текущего документа в старой методике. либо автоматически, либо кодом Все таки вопрос другой назрел: для НОВОГО документа, который не имеет движений такая методика имеет преимущества?

да

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

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

почему всей таблицы? кодом - если установлено НеУдалятьАвтоматически или Удалять..ПриОтменеПроведения

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

я говорю про автоматически

почему вся таблица то?

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

При автомате вся таблица.

ну так это можно воткнуть и в старой методике

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

откуда такая инфа? если у нас кластерный индекс РН начинается с Период + Регистратор + ..

Минимум при записи пустого набора.

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

да

кончайте загонять

бууууу, страшно? )))

страшно за вас и ваше будущее)

Профайлером посмотри диапазон блокировок при записи пустого набора.

я проверял на базе MS SQL Server 2005

2008 та же история.

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

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

про отсутствие соединений соглашусь а чем так нулы плохи?

Их еще обработать надо, а именно вставить isnull

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

это понятно чем это плохо?

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

думаю, что на isnull время меряется наносекундами

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

ну честно сам не проверял, но где-то читал что тратится прилично. Ну проверить же не сложно =)

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

коллеги, каким образом запись пустого набора блокирует весь регистр? у меня не воспроизводится

Эскалация, не всегда бывает

эскалация - это интересная тема, заблокирует легко и весь регистр только коллеги, как то уверенно ее обошли выше в дискуссии

заморочился, замерил isnull Создал таблицу и заполнил ее только значениями null create table #t (a int) while 1=1 insert into #t values(null) всего 4.2 млн записей сделал 2 запроса: выборку без isnull и с ним навскидку увидел увеличение duration на 100 микросекунд, это 0.0001 секунд, это на 4.2 млн записей вывода напрашиваются такие, что isnull не затратен скрины профайлера (внизу с isnull)

4 миллиона - это детский размер. Возьмите хотя бы 4 миллиарда.И блокировки вы здесь не учли.

ну если в контексте проверки остатков реализации то вполне себе размер)

а почему остатки берутся не оперативные?