Имя: Пароль:
1C
 
Контроль остатков на каждую дату
,
0 Zixxx
 
19.01.15
18:04
Как правильнее сделать контроль остатков при проведении документа на каждую дату после даты проводимого документа.

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

Какие еще есть методы для этого, где и как реализовано? Бегать по табличкам отнимать и проверять не охота. Есть какой-нибудь простой механизм?
1 shuhard
 
19.01.15
18:06
(0)[получить конечные остатки на каждую секунду после даты документа]
а зачем на каждую - достаточно найти по ходу вперёд минимальный остаток и сравнить свои движения с ним
2 Fragster
 
гуру
19.01.15
18:13
в УТ 11, например, сначала записываются движения, а потом уже остатки проверяются...
3 Zixxx
 
19.01.15
18:18
(1) Как вариант, но хотелось бы просто запросом это поймать
(2) В каком событии они это отлавливают? Если провести документ после реализации, то при записи этот документ будет еще до реализации. Или также как и в (1)?
4 Leksus
 
19.01.15
18:38
В обработчике ОбработкаПРоведения() принудительно запишите нужные движения, а потом проверяйте остатки
5 GreyK
 
19.01.15
19:02
(2) Это серьёзно?
6 GreyK
 
19.01.15
19:03
(4) А почему нельзя наоборот!?
7 shuhard
 
19.01.15
19:03
(5) а в ERP работает алгоритм ТС-а:
просмотр движений вперёд и отказ распроведения при уходе партий в минус
8 Fragster
 
гуру
19.01.15
19:06
(5) а что в этом такого? наоборот, не надо очищать и записывать пустые движения в регистр для правильной работы контроля остатков. Нет косяков с порядком наложения блокировок, не надо доп. кода для управляемых блокировок и т.п.

например в УПП часто большую часть времени при перепроведении занимает именно отмена предыдущих движений. А ведь все равно потом они еще раз записываются.
9 Fragster
 
гуру
19.01.15
19:06
(7) просмотр вперед и запись перед контролем друг другу не противоречат
10 йопт
 
19.01.15
19:09
(0) чушь собачья...методически неверное решение
11 GreyK
 
19.01.15
19:10
(7) Это одна из причин отказа от ЕРП в России, зачем вначале делать движения, а потом разгребать последствия этих движений?
12 unregistered
 
19.01.15
19:10
(7) >> просмотр движений вперёд

И как они это реализовали (просто любопытно)?
13 Fragster
 
гуру
19.01.15
19:11
(11) куита
14 shuhard
 
19.01.15
19:12
(11) ты бредишь
(12) успешно
15 Fragster
 
гуру
19.01.15
19:12
(12)
Выбрать
   *
Из
   ТоварыНаСкладах.ОстаткиИОбороты(&МоментВремени,)
Где
  КоличествоОтстаток < 0
16 Fragster
 
гуру
19.01.15
19:12
КоличествоКонечныйОтстаток < 0
17 shuhard
 
19.01.15
19:13
(15) ничего после запятушки не забыл в запросе ?
18 Fragster
 
гуру
19.01.15
19:14
(17) много кнопок жать. Но да, параметры виртуальной таблицы с отбором по выполненным движениям должны присутствовать.
19 shuhard
 
19.01.15
19:15
(18) теплее =)
20 Fragster
 
гуру
19.01.15
19:16
(19) куда теплее-то?
21 GreyK
 
19.01.15
19:16
(17) Не тыкай на запрос, эта тема ещё Улю поднималась, ты такой не первый. То, что в стандарте это не реализовано, это заслуга Папика.
22 йопт
 
19.01.15
19:17
Тс говорит не о контроле отрицательных остатков на момент времени проводимого документа, а о расчёте остатков на немыслимое количество периодов: "получить конечные остатки на каждую секунду после даты документа". Это полный бред.
23 ILM
 
гуру
19.01.15
19:18
А есть еще и другой подход )))
Зачем проверять каждый раз при записи документа фиксирующего факт, можно проверять данные один раз в месяц перед расчетом себестоимости.
24 shuhard
 
19.01.15
19:18
(22) это реальность, реализованная в тиражном продукте,
повторить которую может любой мало-мальски грамотный кодер
25 shuhard
 
19.01.15
19:20
(21) с тех пор, как Улю опубликовал свою концепцию замены партий мир сильно изменился, во многом возможно и благодаря
ему

сначала РАУЗ-ом в УПП
теперь сочетанием РАУЗ и партий в ERP и УТ 11
26 GreyK
 
19.01.15
19:33
(25) Партии в 7.7 - это непобедимая вещь. Там много недостатков, но если - бы сразу ввели проверку на остатки в приходах ТМЦ, то проблемы убавились в геометрической прогрессии.
27 shuhard
 
19.01.15
19:36
(26) а при чем здесь 7.7, нет такой платформы
28 ILM
 
гуру
19.01.15
19:36
7.7 не попадалась мне уже года 4-е
29 Злопчинский
 
19.01.15
19:37
Решение задачи, описанное в (0) - явно избыточное
для начала достаточно понять, от точки документа до сейчас - не уходят ли остатки в минус.

Для этого не надо проверять после каждого документа остатки - это расчет временных итогов и весьма ресуросоемко.

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

Но это требует доработок конфиги.
У меня так построен например, партионный учет ГТД
30 Злопчинский
 
19.01.15
19:38
(7) тупое трудозатратное решение
.
а ну да: стоимость рецепта - как озвучивал Пит - 800 баков.
.
в прицнипе, на форуме это уже обсасывалось
.
УТ11, насколько я представляю, не позволяет решить такую задачу "чисто"
31 Злопчинский
 
19.01.15
19:40
Вариант (1) мне представляется тоже вполне рабочим, хз правда скольо ресурса отожрет, но имхо это менее зтартано чем менять конфигу
32 Злопчинский
 
19.01.15
19:41
(5) было заявлено, что такой вариант занимает меньше времени, чем расчет "проведения" и отказ от проведения если не удается "провести".
33 Fragster
 
гуру
19.01.15
19:44
34 Злопчинский
 
19.01.15
19:45
(25) что-то яне помню, чтобы Пит публиковал открыто свою концепцию. И там в основном шла речь о проблемах "пересчета" списанных себестоимостей.

РАУЗ и УТ11 нивелируют проблему отрицательных остатков, просто считая что если в минус ушло в одном периоде - то это ничегшо страшного (вроде так?). Что счиать "одним" периодом - отдельный вопрос. То есть по сути, решение УТ11 - "грязное" и вообщем не решает проблему контроля отричуательных остатков
35 shuhard
 
19.01.15
19:45
(29)
(30)
(31)
(32)
ох уж мне эти сказочники
36 Злопчинский
 
19.01.15
19:47
(33) хз.. я мало понимаю в снеговике,
но то что япомню декларировалось почему сначала проводим а потом смотрим остатки, при минусе - откатываемся - это то, что такой вариант быстрее по времени, чем проводить распределение-списание партий-остатков алгоритмом...
37 GreyK
 
19.01.15
19:48
(32) Что-то у вас не складывается, вначале надо изменить остатки по регистру, а потом проверять эти остатки по регистру.
Не проще-ли по старому дедовскому способу вначале подумать, а потом делать?
38 Злопчинский
 
19.01.15
19:50
(35) сам ты сказочник ;-)
по восьмерки и предал то что слышал ;-)
.
а решение контроля минусов на всем протяжении от измененного документа до сейчас - в рабочем варианте опубликованном я не видел в открытом доступе. Но у мну на клюшках такой вариант работает и ошибку ухода в минус диагностирует практически мгновенно

Вариант (1) вполне может быть, но сколько такой запрос будет работать? - ведь минимальный остаток надо найти, а не просто мгновенно получить
39 Злопчинский
 
19.01.15
19:51
(37) хз, я ж написал..
я этим богомерзким снеговиком с его извратами - пока не пользуюсь... ;-)
40 Эмбеддер
 
19.01.15
19:53
(37) я в самописке на 7-ке давно такое делал, коллеги оценили удобство - так проще проверять остатки
41 GreyK
 
19.01.15
19:59
(38) Ну и какой приход может создать кучку движений проверки после его проведения!? Летает запрос как пчёлка и не даёт изменять локументы задним числом.
42 hhhh
 
19.01.15
19:59
(37) старый дедовский способ очень тормозной, ну его нафиг, дебильный он.
43 unregistered
 
19.01.15
19:59
(14) (15) С периодичностью по регистратору?
Неужели это достаточно быстро работает?...
44 GreyK
 
19.01.15
20:01
(42) У тебя метод не от того деда.
45 Злопчинский
 
19.01.15
20:01
(41) приход или расход - не суть важно. важно что если документ делает задним числом уменьшение остатков товара на объекте учета - то надо проверять...
46 Злопчинский
 
19.01.15
20:02
(41) ну если работает быстро - то и хорошо.. хотя сомневаюсь, что это действительно оптимальное решение по скрости получения нужного результата - это же надо выдрать все остатки, которые получаются после каждого документа, двигающего остаток...
47 GreyK
 
19.01.15
20:03
(45) Представь ситуацию изменения прихода в минус.
48 unregistered
 
19.01.15
20:04
+ к (43) Хотя, наверное, если проверять только критичные  позиции - те, количество которых уменьшилось по сравнению с предыдущим проведением (увеличили/добавили количество в расходном документе или уменьшили/убрали количество в приходном документе), то наверное будет работать относительно быстро.
49 йопт
 
19.01.15
20:04
(43) я тоже в шоке...остатки и обороты тяжёлая виртуальная таблица, это ж сколько времени документ будет перепроводиться...а если данных много...и где гарантия что минус возник именно вследствие этого документа?
50 hhhh
 
19.01.15
20:10
(44) давай рассуждать логически: старый метод всегда пишет в регистр 2 раза. Новый метод пишет 2 раза, только если получился отрицательный остаток. На практике 98% случаев всё с остатками нормально, в 2% остаток отрицательный. ТО есть в 98% документов новый метод пишет в регистр за один раз.
51 йопт
 
19.01.15
20:13
В ветке речь не про старый и новый метод контроля остатков, эта тема баян уже давно, а про расчёт отрицательных остатков в будущем, которые возможно возникнут после перепроведения документа...
52 GreyK
 
19.01.15
20:14
(50) Запись регистра создает движения регистра. Проверка на отрицательные остатки ничего не создаёт. Что-же будет работать быстрее!?
53 Fragster
 
гуру
19.01.15
20:22
(49) проверить запросто. а гарантия - невозможность возникновения минуса из-за контроля :)

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

все от практики.
54 Fragster
 
гуру
19.01.15
20:22
(52) -> (33)
55 hhhh
 
19.01.15
20:25
(52) очистка+проверка. пишет в регистр.
56 GreyK
 
19.01.15
20:28
(54) Ну и зачем менять регистр, потом отменять регистр, если и без этого легко делается?
57 GreyK
 
19.01.15
20:31
(55) Я думал только в отчеты бухгалтеров, а вон оно как оказывается :)
58 Злопчинский
 
19.01.15
22:21
(47) запросто
59 Злопчинский
 
19.01.15
22:25
с другой стороны трудно представить изменение поступления которое приведет к минусам остатков -такие минуса могут быть только виртуальными то есть непорождаются физическим изменением остатков
Например учетное перемещение товаров между своими фирмами физический остаток товара не уйдет в минус а учетный может запросто
60 Злопчинский
 
19.01.15
22:30
Не
Все равно мне кажется что вариант в (1) будет достаточно тяжелый
Могу конечно и ошибаться
61 floody
 
20.01.15
01:48
И все равно склоняюсь к тому, что контролировать какие-либо остатки при неоперативном проведении - фигня и хрень.
62 unregistered
 
20.01.15
08:18
(61) >>  контролировать какие-либо остатки при неоперативном проведении - фигня и хрень.

Всё зависит от конкретного бизнес-процесса.
Где-то наоборот - принято правило, что при оперативном проведении (здесь и сейчас) контролировать остаток в учете не надо, т.к. если товар физически есть на складе (на прилавке), то его надо продать (списать), а уже потом при неоперативном перепроведении пусть менеджеры/кладовщики разбираются почему произошло расхождение фактических данных с данными учета (надо делать контроль отрицательных остатков).
63 vde69
 
20.01.15
08:42
я себе сделал контроль по другому, на основании последовательности и автоматичкому востановлени. ее. в случае ухода в минус документ пишестя в отдельный регистр и отсылается администратору учета для разгребания.

система нормально работает на текущем месте 1 год, аналогичная система работает в другом месте уже 5...
64 Зеленый пень
 
20.01.15
09:29
У нас есть такой контроль: по кнопке "Провести неоперативно" контролируются остатки от документа "вперед" - пишется, на каком документе какой товар уходит в минус.
Но такое неоперативное проведение - исключение.