Незначительные расхождения в основной валюте

[petr]

Добрый день. Возник вот такой вопрос.
Создаем накладную в валюте (EUR). Основгая валюта (RUR) Получаем следующие проводки по счетам
19 -2,93 EUR -100,31 РУБ
60 -19,18 EUR -656,63 РУБ
91 16,25 EUR 556,33 РУБ
-----------------------------------------------
0,00 EUR -0,01 РУБ

Оставшиеся 0,01 РУБ разносятся на забалансовый системный счет "Незначительные расхождения в основной валюте проводкой:
60 / ХХ-Z07 0,01 РУБ.

Стандартная функциональность Аксапты. Тут все работает правильно.


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

Заранее всем благодарен.

[MironovI]

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

[petr]

Большое спасибо за ваш ответ.
Но у наших бухгалтеров другой подход. Они не хотят закрывать счета ХХ-Z07 в конце года, а хотят вообще не иметь проводок на эти счета в течении года при любых операциях в системе.
Поэтому еще 2 вопроса.
1. Корректна ли такая постановка вопроса, т.е. ведение учета в нескольких валютах и отсутствие проводок по незначительному расхождению в основной валюте?
2. Можно ли такое настроить в системе?

[ppson]

Это действительно глубоковстроенная фича система, которая кидает несбалансированные копейки в первой/второй валюте на системные счета.
Что бы избавиться от этой фичи вам придеться хорошо попрограмировать (

[petr]

А куда девать эту копейку и по какому принципу?

[ppson]

У бухгалтеров поинтересуйтесь

[petr]

Не, я то хочу без модификации в рамках логики системы. Как я понял есть такая логика, как бы стандартная. Система при наличии таких несбалансированных копеек переносит их на системный счет, в нашем случае ХХ-Z07. Затем, в конце фин. года бухгалтера кидают эти суммы на соответствующие счета, тем самым обнуляя системные.
А можно ли настроить (не доработать) систему на работу подругому принципу, например по такому:
Система не делает проводок на ХХ-Z07, а вместо них как-то другим способом убирает эту копейку. И будет ли такой подход правильным и логичным с точки зрения правил и логики бухг. и управленческого учета?

[EVGL]

Цитата:

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

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

Нельзя.
См. \Classes\LedgerVoucherObject\postRoundingDifferencesPerDate

[petr]

А если доработать то насколько реально это сделать? Может у кого-то были подобные проекты? Какова была их трудоемкость?

[EVGL]

Суть в том, что нет способа найти, какая из проводок "неправильная". В вашем примере человек интуитивно определяет первую проводку, как "неправильную", исходя лишь из того, что в последних двух первый разряд копеек совпадает. Но алгоритма по такому принципу не построить. В таких случаях лишнюю копейку пристраивают к первой попавшейся записи, как вариант - к проводке с наибольшей суммой, чтобы относительная ошибка была меньше. Для этого придется перепрограммировать указанный метод. Работы на 1-1,5 дня.

[MironovI]

Проблема тут даж не столько куда пристроить мне кажется, а в том что бух-проводки балансировать перестанут, что с этим делать будете?

[EVGL]

Цитата:

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

Проблема тут даж не столько куда пристроить мне кажется, а в том что бух-проводки балансировать перестанут, что с этим делать будете?

Не понял. Указанный метод как раз и определяет, на сколько копеек проводки не балансируют. Эта суммарная разница разносится отдельной проводкой. Никто не запрещает просуммировать или отнять эту разницу с одной из существующих проводок (речь идет, разумеется о корректировке первичной валюты проводки).

[MironovI]

Цитата:

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

Не понял. Указанный метод как раз и определяет, на сколько копеек проводки не балансируют. Эта суммарная разница разносится отдельной проводкой. Никто не запрещает просуммировать или отнять эту разницу с одной из существующих проводок (речь идет, разумеется о корректировке первичной валюты проводки).

Я в механизме LedgerBond еще натыкался на эти проверки, сейчас просто не вспомню хде.. А вообще мне эта ситуация очень напоминает историю когда два месяца бухи искали потерянную копейку на которую не шел баланс, а потом оказалось что он не идет на миллион по дебету и миллион+1 копейка по кредиту

[petr]

Все понятно. Будем разбираться.

[petr]

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

[EVGL]

Цитата:

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

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

Класс LedgerVoucherObject едва ли знает, в каком контексте он вызван. Можно, конечно, детализировать контекст операции по параметру SysModule или LedgerTransType. В такой постановке задача решается за час.

[ppson]

Цитата:

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

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

Ну эта проблема решаема вообще очень просто :-)
заведите отдельный субсчет балансового счета (76) на который будут падать эти разницы.

[petr]

Итак, можно напрогроммировать несколько вариантов.
1. Искать проводку с наибольшей суммой (или по какому-либо другому принципу) и отнимать от нее эту копейку. Тогда искажается соответствие Валютная сумма * Курс на дату проводки = Сумма в осн. валюте.
2. Настроить системный счет для расхождений в осн. валюте на субсчет балансового счета (например 76*)
3. Выбирать необходимый сист. счет при разноске в зависимости от типа проводимой операции.

Всем спасибо. Может есть еще какие-либо другие варианты. А мы пока будем выбирать из этих трех.