Запись текущих остатков на момент изменения документа #758594

Подкиньте идею. Постоянно лезут минуса, и чтобы понят кто-что изменил трачу много времени. Хочу замутить периодический регистр сведений, в который буду писать документ, товар, и остаток на текущую дату при изменении документа. И если будут минуса по остаткам можно быстро найти документ который изменили. Но вот как реализовать пока не придумал.

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

Запретить проведение неоперативно

Есть другие варианты?

версионирование

закрыть период

Отрубить руки

+ по колено

+ предварительно его прострелив

Версионирование включено. Если товар удалили с документа, как мне найти с какого?

отчет по версионированию?

Какой отчет? Поподробнее?

который ты напишешь же

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

Когда я был молод и у меня не было девушки, я тоже любил замутить что-нибудь этакое

Я делал математически точный контроль отрицательных остатков на УПП. Суть - не дает записать документ изменение/удаление которого создает отрицательные остатки. Кроме пользователя со специальным правом. Результат - нет отрицательных остатков в базе. т 89222015286 от 10000руб. Уменьшает затраты на администрирование больших баз и разбор кот виноват в 2 раза. Так как человек которому НАДО минуса бежит к Вам сразу с требованием немедленно помочь. Вместо того чтобы тихой сапой убивать ценность вашей работы.

В том числе неоперативное проведение. и редактирование прихода задним числом.

antonbl@mail.ru

Пиши в регистр факт превышения. Документ, товар, превышено.

Ага. пользователи удалят приход. а факта превышения в регистре не записано.

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

Я проверяю остатки на сейчас. Если не давать сейчас уходить в минус то не уйдет никогда. так как вся линия времени состоит из сейчас.

ты не прав

+2-2+4=4 (сейчас) теперь меняем первый приход +1-2+4=3 (сейчас всё хорошо, но был минус)

Можно придумать синтетический пример.

Можно прверять на 2 момента. на сейчас и на момент проведения документа. одновременно. но на момент проведения затратно по ресурсам. Ситуации что правят старый приход когда можно поправить последний противоречат логике менеджера по закупкам. Для въедливых и на момент внедрения можно делать двойную проверку.

Можно прверять на 2 момента. на сейчас и на момент проведения документа. одновременно. но на момент проведения затратно по ресурсам. Ситуации что правят старый приход когда можно поправить последний противоречат логике менеджера по закупкам. Для въедливых и на момент внедрения можно делать двойную проверку. В любом случае это ГОРАЗДО надежнее чем туманное "не давать проводить задним числом" - Это фактически означает что не давать корректировать ошибки пользователям.

когда торгуют "с колес", правят раннешний приход только в путь Да и не с колес бывает Остаток не только приход формирует, но и перемещение

Да и перемешенные со склада на склад и комплектация - раскомплектация. Все что влияет на остатки на складах. Все это работает. И не трепет нервы экономистам.

Реально уменьшает весь этот цирк с поиском крайнего в 2 раза. Так как крайний приходит сам к Вам в руки

Без всех этих извращений вот уже почти два года ни одного минуса в УТ

Можно порядок навести и чисто административными методами. Но Админстративка + программа надежнее а значит дешевле.

"математически точный контроль" - только проверка ВСЕХ последующих документов. Это нереально затратно, поэтому в типовых только оперативный контроль остатков. проверять 1-2-3-5 моментов - это лишь уменьшать вероятность появления минусов. Плохо - пытаться решать программными методами административные задачи.

Если вероятность уменьшается до гипотетической. Которую СИНТЕТИЧЕСКУЮ на СПОР создаст программист. Хорошо - замешать труд людей программой везде. Замешать дорогой труд еще выгоднее. Разбор и поиск виновных это дорогой труд. неважно программист это или экономист.

ТС не советую избавиться от причин возникновения минусов совсем Иначе через некоторое время может возникнуть вопрос его нужности )) А так запрет исправления (отмены проведения, перезапись с перепроведением) документа если в результате этого могут появиться минуса

Если ТС сидит только на корявках пользователей то да. Просто остатки на складах в красном сильно занижают ценность учетной системы в глазах директора. Фактически до бухгалтерской заморочки.

а зачем их показывать то?

Их же видно на остатках на складе на сейчас. -1 тонна шпал. Что это с точки зрения директора? Что это с точки зрения кладовщика?

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

По ПБУ не может. Так как приход на склад оформляется. Есть приход неотфактурованного товара. для товара без документов. Как с кладовщика мат ответсвенность спросить по программе если там минуса? Он скажет программа глючит (минус) -1 тонна не обнаружена при инвентаризации. И все шито крыто для него.

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

Конечно. Сдвигает момент поиска виновного на момент попытки ввода минуса.

И + какая себестоимость у -1 тонны? РАУЗ может очень зажечь на таких остатках. Проходили.

Не скрыть а вскрыть.

+ Можно в лог писать попытку уйти в минус. Для выяснения зачем.

Секрет Полишинеля: в транзакции записать документ и провести (если проведение) или отменить проведение документа; запросом получить остатки товаров документа, детализированные до регистраторов с момента документа до настоящего времени; если есть отрицательный остаток - отменить транзакцию и сообщить о проблеме. А теперь то, что спутает карты всем желающим контролировать всё и вся: распределенная база данных. Базы узлов автономны между сеансами обмена и что самое печальное - объект может быть изменён одновременно в нескольких узлах базы.

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

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

Предварительно - последняя актуальная, дркумент поступления потом делает корректирующую запись. РАУЗ для системы, где отрицательный остаток - это штатная ситуация, просто не вариант.

В РАУЗ Штатная если внутри месяца. А если на конец месяца то не штатная. Там если -1 тонна по мин цене +10 рублей. остатки. То конец месяца может в регистр написать умопомрачительные цифры.

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

это тебе надо на каждый документ движения анализировать остаток

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

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

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

Я без претензий к тебе, а токмо справедливости ради привёл абстрактный пример. На практике встречаются другие случаи, но не менее печальные. Например, когда бухгалтерия "сидит" в центральном узле и проводит документы по бухгалтерскому учету по мере их поступления в бухгалтерию. При этом порядок проведения документов отличается от порядка их добавления в базу и проведения по управленческому учету операторами складов, которые "сидят" в различных подчиненных узлах и используются перемещения между складами. Это та ещё шляпа :(

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

но это одна база.

Да

плохое решение Я его ещё на 7ке в бюджетке придумал

взлетит 100 % Только это не оптимально

Лучше не оптимальная работающая программа. Чем оптимальный бардак, люди друг на друга перекидывают косяки. А прогер сидит и говорит "это не оптимально".

а рауз ?

РАУЗ кушает минуса внутри месяца. А на конец месяца минуса если он давится. С большим хлопком. Закрытие месяца ИНОГДА рисует такие цифры что понятно даже финдиру что они неадекватные.

ты видел реализацию контроля остатков при проведения задним числом в ерп ?

чего там?

Нет. ЕРП2.0 не внерял. Только УПП. А что там?

Так что там в ЕРП?

Нет желания купить решение?

там проверяются изменения состояния регистра до проведения и в момент проведения