|
Контроль остатков на каждую дату | ☑ | ||
---|---|---|---|---|
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
|
У нас есть такой контроль: по кнопке "Провести неоперативно" контролируются остатки от документа "вперед" - пишется, на каком документе какой товар уходит в минус.
Но такое неоперативное проведение - исключение. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |