[Log1c]

Задача:
Пользователи захотели убрать вопрос в РеализацияТоваровИУслуг про "документ не может быть проведен оперативно т. к. дата ...".

Как решил делать:
Решил узнать о целесообразности действия: Конфигуратор -> Документы.РеализацияТоваровИУслуг - Движения -> ОперативноеПроведение = Запретить.
У нас всегда документы проводятся задним числом. В конце месяца по отчету "Остатки на складах" смотрятся минуса и "дергаются" Поставщики на предмет наших приходов.

Вопрос:
На что это повлияет?

1С:Предприятие 8.2.13.205 УТП для Украины 2.1

[endru]

Тема оперативного проведения и меня интересует.
Вот что примерно я понял (поправьте если не так).
1. Для постоянного контроля наличия нужно переделывать программу ( в принципе не сложно, переписать модули списания добавив МоментВремени)
2. По взаиморасчетам та же ситуация.
3. На больших базах возможны проблемы с блокировками из за этих переделок.

Так же непонятно зачем оперативное проведение в приходных - а если на основе этой приходной куча расходных уже введена.
У всех менять время?

[Log1c]

1. Для постоянного контроля наличия нужно переделывать программу ( в принципе не сложно, переписать модули списания добавив МоментВремени)

Зачем переделывать программу(тут я так понял вы имеете в виду конфигурацию)? контроля наличия чего?

Так же непонятно зачем оперативное проведение в приходных - а если на основе этой приходной куча расходных уже введена.
У всех менять время?

Зачем у расходных менять время? Если у вас идет приход и в тот же самый момент расход проводите приход всегда в начале дня(время).

Когда проводишь документ "оперативно" =) вместе с проведением происходит много проверок. Дата документа - меньше текущей, то документ невозможно провести оперативно . И при таком проведении "неоперативном" =) не происходит проверок.

[endru]

И при таком проведении "неоперативном" =) не происходит проверок.

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

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

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

Зачем у расходных менять время? Если у вас идет приход и в тот же самый момент расход проводите приход всегда в начале дня(время).

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

[Log1c]

В минусах партионного учета кто потом будет разбираться.

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

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

У меня была такая задача. Анализировался вид документа, время, что там за номенклатура, с какого на какой склад, ..., и потом в зависимости от этого проставлялся порядок документа(по порядку проставлялось время документа потом обработкой). Скажу честно, я её не доделал. Но человек который после меня подхватил идею: запретил ордерную систему и поотбивал некоторым пользователям руки. И я так понял у него получилось.

Вот пока такой механизм не сделали: сидели 2 человека и занимались тем, что переставляли время у документов, так чтобы не было минусов. Эти люди менялись через полгода - год(увольнялись т. к. работа была "тупая" и заменялись новыми).

[endru]

Вот пока такой механизм не сделали: сидели 2 человека и занимались тем, что переставляли время у документов, так чтобы не было минусов. Эти люди менялись через полгода - год(увольнялись т. к. работа была "тупая" и заменялись новыми).

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

[logist]

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

Log1c, однозначно фраза дня! Спасибо )
Это так по нашему..., поломать то что работало правильно, для того что бы работало удобно, потом разгребать ошибки удобной работы что бы результат учета был правильным ))

p.s. подобный бардак, от части, меня вынудил совсем не давно сменить работу.... А сложилось у нас очень весело: был вид деятельности по которому партионный учет не велся, захотели с нового года вести все как полагается, привели в порядок остатки на 1 января, все пучком, пока не наступил момент подсчета себестоимости за январь, оказалось что при вводе партионного учета не предусмотрели кучу всяких моментов. В итоге с конца февраля люди (не программисты, а бухгалтера и операторы) разгребают неверное проведение по партиям за январь, и дальше - тупо перепроводя документы другими датами, приходуя/списывая товары - с одной целью "АБЫ СОШЛОСЬ", в итоге в начале июня первый квартал кое-как разгребли, слава богу "разгребалы" каждый по своему выработал методику исправления ошибок и концу июля второй квартал был сведен ) Глубину глупости необдуманных действий разработчиков/программистов еще увеличивала необходимость обмена данными этой учетной системы с еще двумя - регл.учетом и системой первичной регистрации продаж. Т.к. все изменения в одной базе тянули необходимость изменений в других...
Но, самый апофиоз идиотизма наступил когда среди этого месива пришлось менять юр.лицо, и когда все товары продали с одного на другое, оказалось что в регл.учете продавца (ведется только суммовой учет складов по себестоимости) остались остатки, которых быть не должно,... и тут... [барабанная дробь] и вуаля - оказалось что начиная со ввода партионного учета - не верно считалась себестоимость, от части из-за недоработок разработчиков и из-за тупых исправлений последствий недоработок...
Так что... прежде чем что-то менять - подумайте тысячу, а лучше сто тысяч раз - стоит ли это делать, и стоит ли это делать так.

[endru]

Так что... прежде чем что-то менять - подумайте тысячу, а лучше сто тысяч раз - стоит ли это делать, и стоит ли это делать так.

Просто так запретить в конфигурации "Оперативное проведение" конечно можно, только

Вот пока такой механизм не сделали: сидели 2 человека и занимались тем, что переставляли время у документов, так чтобы не было минусов. Эти люди менялись через полгода - год(увольнялись т. к. работа была "тупая" и заменялись новыми).

сидеть будет не 2 человека а 4

[Log1c]

Log1c, однозначно фраза дня! Спасибо )
Это так по нашему..., поломать то что работало правильно, для того что бы работало удобно, потом разгребать ошибки удобной работы что бы результат учета был правильным ))

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

Я когда-то работал сначала пользователей, потом тестировщиком, потом разработчиком, потом что-то типа постановка ТЗ от Бухгалтеров к программистам, потом внедренцем.

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

Так вот что я этим хочу сказать, менять работу надо почаще =) узнаешь что такое другая шкура =)

Ушли далеко от темы: я думаю стоит поставить сделать: Конфигуратор -> Документы.РеализацияТоваровИУслуг - Движения -> ОперативноеПроведение = Запретить. (тут должен быть смайлик чертика, но его нет к сожалению)

Просто так запретить в конфигурации "Оперативное проведение" конечно можно, только

сидеть будет не 2 человека а 4

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

[endru]

Ну тогда расскажете через пару месяцев как полет.
Интересно будет всем я думаю.

[Vofka]

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

По хорошему - это запретить вообще проведение задним числом. Но 1С даёт нам такую возможность. И пользоваться ней необходимо на свой страх и риск!

А проверять что-то в неоперативном режиме - не представляет никакой логики:
1. На вчера, на начало дня есть 10 единиц остатков;
2. Сегодня их списали (продали, выбросили, подарили кому-то);
3. Сегодя проводим документ на списание этих же остатков но! задним числом.
Вопрос: и что нам даёт этот контроль?

1С нам даёт оооочень гибкий инструмент, в отличии от иностранных ЕРП систем. А понимаени и умение им пользоваться - это уже другой вопрос.

тут должен быть смайлик чертика, но его нет к сожалению