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

Кто что думает  по этому поводу

А если ты сначала записываешь документ (не проводишь!), потом записываешь и проводишь другой документ. Насколько правильные остатки будут в первом документе?

Nick писал(а) 10. Декабря 2008 :: 06:03:

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

Nick писал(а) 10. Декабря 2008 :: 06:16:


нет наоборот первый док не записывать если ушли в минус.

возникает только одна проблема если док не проведен Призаписи() еще неизвестно
будем или нет мы проводить документ.

Nick писал(а) 10. Декабря 2008 :: 06:29:

ты что-то путаешь речь идет о ПриЗаписи() при итерактивном
изменении документа.
ИХМО если мы по каким-то причинам меняем документы из обработок то всю ответсвенность за данные берет сама обработка ( тот  кто ее писал)и уже не надо ничего проверять и как правило в этом случае
либо через параметр либо через переменную гл модуля в
Док.Провести()
отключают проверку на отрицательные остатки.

Nick писал(а) 10. Декабря 2008 :: 06:37:

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

у меня везде наоборот везде стоит
ПриЗаписиПерепроводить(1);

Всё я сдаюсь .

Z1 писал(а) 10. Декабря 2008 :: 06:49:

Я там ещё кое-что дописал.
А вообще мы что обсуждаем? Общий случай или организацию учёта в отдельно взятой фирме? ИМХО, как у тебя - не везде.

Я говорю про НОВЫЙ документ, у которого в процессе проведения лезут косяки.

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

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

Т.е. всё-таки ошибочный документ записать можно, но у него будет какой-то флагЕстьОшибка=1. Так?

И что ты подразумеваешь под "своей блокировкой" в ПриЗаписи?

JohnyDeath писал(а) 10. Декабря 2008 :: 07:56:

sql блокировка.

Nick писал(а) 10. Декабря 2008 :: 08:03:

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

Цитата:

Это что такое?

JohnyDeath писал(а) 10. Декабря 2008 :: 08:09:

и блокировать не таблицу а только "конфликтующие сессии"
хп sp_getapplock и в ней выбрать конкретный склад.

Nick писал(а) 10. Декабря 2008 :: 08:28:

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

Пока документ не проведен, но записан - считать его неправильным.
Кстати, при записи документа так же открывается "дорогая транзакция".

Z1 писал(а) 10. Декабря 2008 :: 08:58:

а куда она делась?

Может быть я повторяюсь но: Какой смысл в твоей схеме оставлять блокировку в модуле документа?

Z1 писал(а) 10. Декабря 2008 :: 09:04:

Ты это проверил или на каких-то других основаниях сказал?

Nick писал(а) 10. Декабря 2008 :: 09:17:

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

Z1 писал(а) 10. Декабря 2008 :: 09:21:


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

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

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

Z1 писал(а) 10. Декабря 2008 :: 08:58:

Перечитал еще раз. Есть мнение, что мы друг друга не поняли.
При заходе в процедуру ПриЗаписи() конечно же нет еще транзакции, она открывается при записи документа.

По поводу УРБД - всем переферийным базам выделяем свои склады с которыми они работают, проблему с минусами почти решает.

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

Время есть, можно пообсуждать

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

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

В динамике:
0. Нажали кнопку Провести (#Записать #Провести);
1. Запись документа;
1.1. Попали в ПриЗаписи();
1.2. Проверили свободный остаток (при помощи пользовательской блокировки) - хватает;
1.3. Вышли из ПриЗаписи();
1.4. Открывается неявная транзакция;
1.5. Записывается документ;
1.6. Фиксируется неявная транзакция;
2. Проведение документа;
2.1. Открывается неявная транзакция;
2.2. Попали в ОбработкаПроведения();
2.3. Выполнили движения регистров на основании данных табличной части документа;
2.4. Вышли из ОбработкаПроведения();
2.5. Фиксируется неявная транзакция;

Для твоей концепции узким местом будет огромный промежуток времени между 1.6 и 2.1:
- документ записался, транзакция зафиксировалась, все блокировки сняты (здесь закончился п. 1.6);
- здесь попадаем в промежуток времени, когда другие пользователи (при интенсивной работе) могут вклиниться (т.е. между 1.6 и 2.1) со своими проверками в ПриЗаписи();
- начался п. 2.1 ...
- ...
- ...

Про "дорогие транзакции": в нашей работе (1с) они редко, когда являются дорогими. Объемы изменяемых данных при записи/проведении документов незначительные. В случае отката транзакции все не очень страшно. А вот когда нужно откатить транзакцию с таблицы в 40 с лишним лямов строк, то вот это "дорогая транзакция"  

spock писал(а) 11. Декабря 2008 :: 06:29:

У нас 20 складов и значит для моей конфигурации это будет хорошо

Опять же если где то разрешено работать задним числом с документами меняющие складские остатки то и изменение приходных накладных ( в приходе уменьшили количество со 100
до 10 ) может привести к минусам остатков - все ли поверяют такую ситуацию ?

Z1 писал(а) 11. Декабря 2008 :: 06:53:

COMMIT TRAN

spock писал(а) 11. Декабря 2008 :: 06:56:


Так как раз фиксируется явная транзакция, а под неявными обычно подразумевают транзакции в которые оборачиваются любые операторы SQL типа insert, update

Цитата:

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

Вы мне опять мозг разрушаете **crazy**

spock писал(а) 11. Декабря 2008 :: 06:56:

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

Как на эту ситуацию влияет оператор в форме документа
ПриЗаписиПерепроводить(1);
и на кнопке Ок стоит всегда
#Записать провести
тогда логично делать фиксацию транзакции только после проведения.

spock писал(а) 11. Декабря 2008 :: 07:03:

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

проверю но я уверен почти на все 100% что стоит один commit
для

ПриЗаписиПерепроводить(1); 

Просто может уже кто-то проверил и точно знает.
Хотя такие тонкие материи знать и помнить - нереально.

Nick писал(а) 11. Декабря 2008 :: 07:17:

проверю но я уверен почти на все 100% что стоит один commit
для

ПриЗаписиПерепроводить(1); 

Просто может уже кто-то проверил и точно знает.
Хотя такие тонкие материи знать и помнить - нереально.

Nick писал(а) 11. Декабря 2008 :: 07:00:

Так фиксируется любая транзакция.

1с открывает транзакции не явно/explicit (т.е. не BEGIN TRAN), а неявно/implicit (т.е. SET IMPLICIT_TRANSACTIONS).

spock писал(а) 11. Декабря 2008 :: 07:24:


Уболтал .

Nick писал(а) 11. Декабря 2008 :: 07:30:

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

эта, я за вами не успеваю

Nick писал(а) 11. Декабря 2008 :: 07:01:

Nick может обоснуешь этот пост.

Z1 писал(а) 11. Декабря 2008 :: 07:49:

Имхо, это настолько важный вопрос, что он включен в учётную политику организации