Бухгалтерская операция 41.01.00 - 41.01.00

[glibs]

Порой я начинал думать, что его проще организовать вручную переносами чем тем, что есть.

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

Сейчас попробуем секретным оружием...

А ну вот уже... полюбуйтесь... зарегистрировать товар можно. А отменить регистрацию (ну ошиблись)... в сад.

Так вот. Хотел попробовать один из своих любимых трюков — виртуальные остатки называется — сделать журнал складских проводок на необходимое к возврату количество, зарегистрировать, но не разнести, сторнировать (чтобы потом оприходовать как нужно, отменить регистрацию и убрать журнал как будто и не было — следов не остается)... вылезла бага какая-то. Вроде даже и не русская. Ну или фича...

"
Cannot create a record in Dimension history for documents (InventReportDimHistory). Type: None, .
The record already exists.
Operation canceled
"

Сегодня явно не мой день .

Но даже если сторнировать... она же снова потянет номенклатуру на карантин...

Вы представляете чем друг в друга начнут швырять кладовщик и бухгалтер от такого учета?

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

И вообще в буржуйской Аксапте сторнирование — одна из самых больших методологических... жоп .

Ведь есть же коррекция проводок в модуле Проекты... могут же...