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

[Zuek]

В наличии следующая ситуация:

1.была закупка товара (100 кг) - сумма 100 р.
2. были расходы (много), в итоге все 100 кг были проданы
было принято решение уменьшить сумму закупки на 10 р
3. т.к. количества в наличии уже не было - создали фиктивную закупку на 100 кг и 90 р.
4. сторнировали первую закупку

в итоге родились проводки 41 - 60 (-100р), 41-41 (-10). Эти -10 р. записались в InventTrans.CostAmountOperation.

Почему создалась проводка на -10 р.? Я понимаю, что за эту проводку ответственнен счет "Потребление" и "Приход" из профиля разноски. Что касается потребления, то из руководства пользователя (по 3-ке) вычитал: "проводки по этому счету производятся параллельно со списанием товара и дебетованием счета поставщика. В РСБУ лишено смысла, целесообразно настроить таким же счетом, как и «приход».Полезна при использовании модели «Стандартная себестоимость» (когда покупали, стандартная себестоимость была 500 руб., при возврате – 520. Отклонение в 20 будет разнесено на этот счет)". Возможно первая закупка и не играет никакой роли в формировании такой проводки, но вот их "похожесть"... В Группе складских моделей - ФИФО. Есть подозрение, что в карточке номенклатуры была проставлена цена, может ли проводка родиться из-за этого? Выяснить точнее не удастся - операции происходили несколько месяцев назад.

Как с этим бороться? Я вижу 2 варианта: 1. Джобом (или еще каким способом) для данной закупки дебет 41-го счета заменить на какой-нибудь 9*. 2. "Выкосить" изначальный заказ и его сторно 3. скорректировать первый приход (если дело все-таки в сторнировании)

[glibs]

Какая у вас версия?

Как вы сторнировали закупку? Через немедленную поставку? Если нет, то делали ли маркировку?

Если задача была в корректировке себестоимости, то можно было воспользоваться коррекцией приходов в УЗ.

Вы уж извините, но "было принято решение уменьшить сумму закупки на 10 р" не очень поясняет стоящую перед вами задачу с т.з. учета.

Проводка формируется на разницу между скользящей средней себестоимостью номенклатуры на момент списания и указанной в строке сторно-закупки ценой.

[Zuek]

Цитата:

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

Какая у вас версия?

Как вы сторнировали закупку? Через немедленную поставку? Если нет, то делали ли маркировку?

Если задача была в корректировке себестоимости, то можно было воспользоваться коррекцией приходов в УЗ.

Вы уж извините, но "было принято решение уменьшить сумму закупки на 10 р" не очень поясняет стоящую перед вами задачу с т.з. учета.

Проводка формируется на разницу между скользящей средней себестоимостью номенклатуры на момент списания и указанной в строке сторно-закупки ценой.

Извиняюсь, не написал сразу.
DAX 4.0 SP1
Я закупку не сторировал - разбираюсь с ситуацией. В заказе на покупку были созданы минусовые строки (скорее всего через кредит-ноту), маркировки за "исходную" закупку нет и поставить не удастся - есть карантинные заказы.

Не используется коррекция - т.к. закупка осуществляется торговым домом с завода (в одном холдинге) и необходимо сохранять "идентичность" накладной из завода и закупочной в DAX. Решение было принято до меня, причина, как мне объяснили была в налоговой. Не нравилось им, что уж очень много корректировок себестоимостей

[Logger]

Денис Федотенко в своей статье рассматривал вопрос откуда берутся проводки 41-41
Denis Fedotenko: Себестоимость и закрытие склада

http://blogs.technet.com/denisfed/ar...23/705202.aspx

Цитата:

"Странные проводки" по возврату закупок.

Часто приходится слышать жалобы начинающих консультантов, на "странные проводки" по возврату закупки. Скажем что-то типа "Почему по закупке у нас прошли проводки Д 10 К 60 1400руб, а по возврату Д 10 К 60 -1400руб; Д10 К10 -200руб?. Откуда вторая проводка?".

Вот причина этой ситуации: В проводки по поставщику мы должны поставить сумму возврата (1400рублей). В тоже время, при отсутствии маркирования, и оценочная и истинная себестоимость списания у нас может отличаться от этих 1400 рублей (В нашем случае – оценочная себестоимость – 1200 рублей). Вот DAX и пытается побороть эту проблему следующим способом:

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

2. Складской счет дооценивается (или уценивается) на сумму разницы между мгновенной себестоимостью и суммой возврата, в корреспонденции со счетом потребления из настроек складских разносок. По какой-то непонятной причине, принято в это поле настройки разноски прописывать обычный складской счет, тот же самый что и в настройке счета прихода. Поэтому и появляется странная проводка Д 10 К 10.

Правильнее было бы прописывать в качестве счета потребления прописывать какой-нибудь рабочий счет типа 76.xxx. Тогда разноска возврата имела бы более понятный вид:

Д10 К60 -1400

Д76 К10 -200

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

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

[Zuek]

Спасибо большое! Причина стала ясна. А как это можно исправить? У меня сейчас получается по оборотно-сальдовой ведомости "-" на 41-м счете при нулевых остатках.

[Logger]

Цитата:

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

Спасибо большое! Причина стала ясна. А как это можно исправить? У меня сейчас получается по оборотно-сальдовой ведомости "-" на 41-м счете при нулевых остатках.

Для начала исправить настройку разносок, чтобы новых проводок неверных не образовалось.
А дальше...
Не знаю штатного решения.
Мы у себя сперва отменили закрытие склада и писали джобы которые правили главную книгу и счета в InventTransPosting (это обязательно, потому что там сохраняются счета на момент разноски, так что если сразу проводки 41.01.00 - 41.01.00 не вылезли, то могут позднее при закрытии склада появиться)

[Zuek]

Вопрос не совсем по теме - но очень связан с ней. Ситуация та же. Я попытался отмаркировать кредит-ноту закупки после разноски, с оригинальной закупкой. Из-за наличия карантинных заказов - это не удается. Как быть, если требуется прямая связь, чтобы не получилась ситуация, описанная в 1-м посте?

[glibs]

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

В вашей ситуации нужно с реального склада тащить номенклатуру на карантинный склад переносом со все той же маркировкой .

[Zuek]

Цитата:

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

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

В вашей ситуации нужно с реального склада тащить номенклатуру на карантинный склад переносом со все той же маркировкой .

Да уж... но, порой без него не обойтись... -(
Не совсем понял, как это предложенный вариант. Т.е. если у меня в наличии 0 кг, я делаю новую закупку (приход через карантин), затем делаю кредит-ноту (с карантинного склада), предварительно сделав перенос обратно на карантин?

[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

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

Почти все .