Откат ввода ОС в эксплуатацию

[BOAL]

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

У нас в аварийном порядке писалась функция распроведения по ОС.

К сожалению, локализованный модуль ОС имеет некую необратимость (или отсутсвие инструментов корректного сторнирования).
Надежнее тут все же сделать свой инструментарий, тк ошибочные вводы будут - пользователь, даже аккуратный может пасть жертвой неверной информации.

[gaenar]

Цитата:

Сообщение от BOAL

К сожалению, локализованный модуль ОС имеет некую необратимость (или отсутсвие инструментов корректного сторнирования).
Надежнее тут все же сделать свой инструментарий, тк ошибочные вводы будут - пользователь, даже аккуратный может пасть жертвой неверной информации.

Согласен. Методы разноски проводок по ОС настроены для прямолинейного движения (от ввода/купли - до закрытия/списания/продажи). Сторно делать очень непросто, особенно ввиду того, что отсутствует механизм просмотра предыстории по проводкам ОС. Довольно сложно отследить при сторно, в какой статус переводить и какие именно проводки сторнировать (анализ transов в этой ситуации даёт далеко не всю информацию)

[Pavel]

Цитата:

Сообщение от BOAL

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

У нас в аварийном порядке писалась функция распроведения по ОС.

К сожалению, локализованный модуль ОС имеет некую необратимость (или отсутсвие инструментов корректного сторнирования).

Мое личное мнение, что прямая связь между складом и ОС - одно из крайне неудачных решений в локализации. Видимо, был такой период "великих дел" (типа, «сибирские реки поворачивали вспять»), когда решили закупки завязать на ОС, двувалютную себестоимость на трансляцию и т.п.

Например, в том же конкорде достаточно ограничиться операцией корректировки первоначальной стоимости или переоценкой ОС.

[gaenar]

Цитата:

Сообщение от Pavel

Например, в том же конкорде достаточно ограничиться операцией корректировки первоначальной стоимости или переоценкой ОС.

а если подробнее, чем кроме геморроя со сторно, она неудачна?

А что если вам необходимо регулярно закупать ОСы для ваших внутренних нужд, закупку будет обрабатывать одна тётенька, а ОС вводить - другая?

[Pavel]

Цитата:

Сообщение от gaenar

а если подробнее, чем кроме геморроя со сторно, она неудачна?

А что если вам необходимо регулярно закупать ОСы для ваших внутренних нужд, закупку будет обрабатывать одна тётенька, а ОС вводить - другая?

У вас закупки товаров/услуг у поставщиков и учет ОС делает одна тетинька?

[Nick]

Цитата:

Сообщение от Pavel

У вас закупки товаров/услуг у поставщиков и учет ОС делает одна тетинька?

Есть и такое - Закупки ОС у поставщиков и их учет делает один бухгалтер
учет НДС - другой...

[Pavel]

Цитата:

Сообщение от Nick

Есть и такое - Закупки ОС у поставщиков и их учет делает один бухгалтер
учет НДС - другой...

В этом простейшем случае, разве что, только и работает (с указанными проблемами), а если все сложнее, то смысл данной разработки просто теряется. Функциональность модуля управления запасами и учет ОС начнут «разбегаться», когда возникнут всякие - разные жизненные ситуации (валютный учет, определение себестоимости по расходам номенклатуры, включение в первоначальную стоимость ОС дополнительных затрат, учет ОС по разным видам учета, внесение ОС как вклад в уставной капитал и пр.). Т.е. данная связка будет лишь помехой.