Бухгалтерская операция 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
"

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

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

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

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

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

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

[Zuek]

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

[Geo]

Ах вот в чем дело А я-то думал, голову ломал, что за проводки 41-41 Оказывается, это просто было "так настроено"
В моем опыте, этот счет "потребления" настраивался как технический субсчет 10-ки (у нас товаров не было, закупались только МПЗ). В регламенте закрытия периода было предусмотрено, что перед закрытием склада нужно разбираться вручную с сальдо этого счета (выяснять, откуда оно вообще взялось,конкретно по операциям и документам), и, если до конца разобрать его не получилось, - то просто списывать сальдо на прибыли/убытки, или куда там еще бухгалтер посчитает нужным.

Цитата:

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

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

А Вы не работали с Navision? Вот уж где сторнирование - жопа так жопа По сранению с АХ, по крайней мере. Сначала сторнируй расход, потом все перемещения по цепочке, и потом только приход. И нигде не ошибись, потому что привязку операций после разноски уже не поправишь. Красота! Удобство!
Лично мне чем в первую очередь понравилась Аксапта - так это как раз легкостью сторнирования закупок (через немедленное получение). Есть архитектурные провалы, да; но "на круг" получается на порядок легче.

[Logger]

Цитата:

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

Лично мне чем в первую очередь понравилась Аксапта - так это как раз легкостью сторнирования закупок (через немедленное получение). Есть архитектурные провалы, да; но "на круг" получается на порядок легче.

И это вы называете легкостью сторнирования ?
Вот уж воистину, все в мире относительно

[Geo]

Цитата:

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

И это вы называете легкостью сторнирования ?
Вот уж воистину, все в мире относительно

А чего же сложного (если нет карантина)? Прямо в строке покупки указываем в поле "Немедленное получение" количество с минусом, и разносим. Не надо делать новый документ, не надо ничего копировать, не надо вручную связывать строки прихода и расхода. Надо помнить, что нельзя потом заново "купить" эту же строку с другой ценой (даже стоит, думаю, программно закрыть такую возможность, если по строке есть отмена). Вот и всё.

[glibs]

Цитата:

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

...
Прямо в строке покупки указываем в поле "Немедленное получение" количество с минусом, и разносим.
...

Не ошибиться с датой. А то начнется сторно на сторно.

Цитата:

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

...
нельзя потом заново "купить" эту же строку с другой ценой
...

Ага.

Цитата:

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

...
даже стоит, думаю, программно закрыть такую возможность, если по строке есть отмена
...

А если была частичная поставка и нужно допоставлять?

Кстати, цены и скидки могут слететь программно при изменении количества в строке.

IMHO — не надо так делать. Проверка нужна. Тут согласен. Но более интеллектуальная. С учетом и финансовых аналитик, и накладных расходов, и валют, и даты разноски, и еще кучи всего. Ограничение гибкости — это плохо.

Не нужно агитировать за поделки в стиле локализаторов а-ля: "Тут мы сделали как в 1С, тут не сделали, т.к. в 1С такого нет, а тут не сделали, потому-что про это не знали/забыли (ненужное вычеркнуть)".

Вы вот тоже мыслите заложенными в 1С категориями (Закупка = документ).

Цитата:

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

...
Вот и всё.
...

Почти все .