Валюта проводки по суммовым разницам

[Pavel]

Цитата:

Изначально опубликовано Гость
Неужели это мое пожелание противоречит логике?
Неужели так нельзя сделать?

Можно, только решение в системе выбрано не совсем правильно.

[EVGL]

Мнение бухгалтеров ценим По 62 задолженность по долларам никогда не будет равна нулю, если долларовый счет оплачивать рублевой оплатой. Какую бы валюту не приписывать перед нулем. Извините, но логике действительно противоречит.

[Гость]

Цитата:

Изначально опубликовано EVGL
Мнение бухгалтеров ценим По 62 задолженность по долларам никогда не будет равна нулю, если долларовый счет оплачивать рублевой оплатой. Какую бы валюту не приписывать перед нулем. Извините, но логике действительно противоречит.

Долларовый счет оплатили долларами...
Все равно не вижу в Главной книге по 62 счету по валюте USD нуля в рублевой оценке..
А вижу валюту рубли с нулевой валютной суммой и ненулевой рублевой оценкой.
Это такая аксапторадоксальная логика?

[EVGL]

Ага!
Доллары кроем долларами... Понимаю. Вариант: отключить функциональными ключами "российские" суммовые и курсовые разницы. Активизируется "западная" курсовая разница. В ней, кажется, оставляется оригинальная валюта накладной.
Только по ГК вторичная валюта, скорее всего, "разъедется": не умеют западные люди проводки без вторичной валюты делать.

Только вот вопрос: почему до этого речь шла о суммовой разнице? Доллары с долларами тоже дают суммовую разницу? Облагаемую НДС? Нужен совет бухгалтера.

[Pavel]

Цитата:

Изначально опубликовано Гость
Долларовый счет оплатили долларами...
Все равно не вижу в Главной книге по 62 счету по валюте USD нуля в рублевой оценке..
А вижу валюту рубли с нулевой валютной суммой и ненулевой рублевой оценкой.

По ГК в данном случае пройдут следующие операции:
Дата_____Валюта_____Курс______Сумма, дол.____Сумма, руб___Текст
2.12.02____USD______31.8________100___________3180_____Счет №1
3.12.02____USD______31.85_______-100__________-3185_____Оплата счета

В момент сопоставления задолжности и платежа в модуле покупателей или непосредственно пользователем будет запущена переоценка (для простоты на 3.12.02), которая создаст проводку:

3.12.02____USD_______-___________-_____________5______Переоценка вал.проводок

Таким образом и по 62 счету и по карточке покупателя суммы в рублях и долларах по счету и платежу "закроются".

[Гость]

Цитата:

Изначально опубликовано Pavel


В момент сопоставления задолжности и платежа в модуле покупателей или непосредственно пользователем будет запущена переоценка (для простоты на 3.12.02), которая создаст проводку:

3.12.02____USD_______-___________-_____________5______Переоценка вал.проводок

Вот и я так хочу!
А то у меня при сопоставлении делается проводка
3.12.02____RBL_______-___________-_____________5______Курсовая разница

[Pavel]

Цитата:

Изначально опубликовано Гость
Вот и я так хочу!
А то у меня при сопоставлении делается проводка
3.12.02____RBL_______-___________-_____________5______Курсовая разница

Эт к локализаторам. Полагаю, они "усовершенствовали" базовую функциональность.

[Гость]

Цитата:

Изначально опубликовано EVGL
Ага!
Доллары кроем долларами... Понимаю. Вариант: отключить функциональными ключами "российские" суммовые и курсовые разницы. Активизируется "западная" курсовая разница. В ней, кажется, оставляется оригинальная валюта накладной.
Только по ГК вторичная валюта, скорее всего, "разъедется": не умеют западные люди проводки без вторичной валюты делать.

Только вот вопрос: почему до этого речь шла о суммовой разнице? Доллары с долларами тоже дают суммовую разницу? Облагаемую НДС? Нужен совет бухгалтера.

Ну а если я У.Е. крою У.Е. - разве от этого что нибудь изменится?
Суммовые разницы это те же ОПЛАЧЕННЫЕ курсовые разницы - никакой разницы (каламбур ) для бухгалтера.
Про функциональные ключи и "российские" курсовые - это интересно, как бы это проверить?
Со всей рублевой оценки пришедшей на 62 счет валютной выручки нужно с 76 счета показать оплаченный НДС. Аксапта же НДС в USD на 76 счете у меня стандартно не переоценивает и списывает с 76 на 68 в неправильной сумме.

[Pavel]

Цитата:

Изначально опубликовано Гость
Про функциональные ключи и "российские" курсовые - это интересно, как бы это проверить?

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

Цитата:

Изначально опубликовано Гость
Со всей рублевой оценки пришедшей на 62 счет валютной выручки нужно с 76 счета показать оплаченный НДС. Аксапта же НДС в USD на 76 счете у меня стандартно не переоценивает и списывает с 76 на 68 в неправильной сумме.

Лучше отказаться и от использования валюты (У.Е.) и "решений". Все будет гораздо проще и надежней, если провести операции как рублевые:

Дата_____Валюта_____Сумма, руб___НДС___Фактура____Текст
2.12.02____-____________120_______20_______1________Фактура
3.12.02____-___________-144_________________-________Оплата
3.12.02____-____________24_________4_______2________Фактура по сум.разнице

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

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

[EVGL]

Убедительно. Подумаем над тем, чтобы сохранять валюту в "российской" курсовой разнице. Но все равно: мы лишь обсуждаем, как добиться красивой непротиворечивой картинки на экране.

Насчет НДС - неверно (это не к вам, Павел). У вас - курсовая разница. НДС с нее не взимается. На 76 счете ведется учет НДС по отгрузке, а не по оплате. В момент оплаты переносится на 68 счет без какой-либо переоценки. Переоценка имеет место только при суммовой разнице, а ее здесь нет. Если суммовая разница есть, то проводка НДС 76-68 все равно идет на исходную сумму в рублях без переоценки. Переоценка (НДС с сумовой разницы) пройдет сразу на 68 счет, минуя счет 76.

[Гость]

Цитата:

Изначально опубликовано EVGL
Убедительно. Подумаем над тем, чтобы сохранять валюту в "российской" курсовой разнице. Но все равно: мы лишь обсуждаем, как добиться красивой непротиворечивой картинки на экране.

Насчет НДС - неверно (это не к вам, Павел). У вас - курсовая разница. НДС с нее не взимается. На 76 счете ведется учет НДС по отгрузке, а не по оплате. В момент оплаты переносится на 68 счет без какой-либо переоценки. Переоценка имеет место только при суммовой разнице, а ее здесь нет. Если суммовая разница есть, то проводка НДС 76-68 все равно идет на исходную сумму в рублях без переоценки. Переоценка (НДС с сумовой разницы) пройдет сразу на 68 счет, минуя счет 76.

1) Еще раз повторюсь: для бухгалтера этот вопрос - не "красивость", а имманентно присущий ему способ существования. И Главная Книга - не хранилище побочных продуктов деятельности модулей , а документ, предъявляемый налоговому инспектору.
2) Для PAVEL: В остальном (кроме обсуждаемого вопроса) учет в АКСАПТЕ в У.Е. меня более-менее устраивает. Отказаться от У.Е. по многим причинам я не могу. Вопрос о том, сколько именно У.Е. заплатил клиент действительно решает оператор, а не программа , когда вводит выписку банка и проставляет курс зачисления рублей. Остальное делает программа.
3) Насчет проводки 76-68. В своем примере я говорил об учете в USD - т.е. о валютном учете, который специальном образом регулируется Минфином. В частности, все проводки в USD, а на 76 счете тоже отражаен НДС в USD (этот факт тоже надо "мотивировать"?) делаются по курсу ЦБ на дату выполнения проводки. Поэтому проводку 76-68 в таком случае неправильно делать в исходной сумме.

[Гость]

Цитата:

Изначально опубликовано EVGL
... Подумаем над тем, чтобы сохранять валюту в "российской" курсовой разнице...

Большое спасибо от имени всех бухгалтеров!
Если что-то получится, пожалуйста, проинформируйте меня, буду очень благодарен.

[Pavel]

Привет,

Цитата:

Изначально опубликовано Гость
2) Для PAVEL: В остальном (кроме обсуждаемого вопроса) учет в АКСАПТЕ в У.Е. меня более-менее устраивает. Отказаться от У.Е. по многим причинам я не могу. Вопрос о том, сколько именно У.Е. заплатил клиент действительно решает оператор, а не программа , когда вводит выписку банка и проставляет курс зачисления рублей. Остальное делает программа.

Итоги:
"-"
- обработка предоплат
- книга покупок
- выделение НДС с суммовой разницы
- некорректная работа переоценки, если проводки не будут вовремя сопоставлены
- "несходимость" отчетов
"+"
- уход от ручного учета суммовых разниц за счет использования функциональности переоценки валюты (фактически обработка курсовой разницы)

Мы тоже почти в течение года использовали для учета У.Е. валюту. В результате возникли большие проблемы с выверкой дебиторской задолжности. При большом количестве бизнес ситуаций и транзакций за год система генерит колоссальное количество ошибок в автоматических проводках. Ручная выверка и исправление этих ошибок - цена за такую «автоматизацию» учета суммовых разниц.
На следующий год пришлось доработать функциональность конкретно под учет суммовых разниц.

С уважением.

[Гость]

Pavel,

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

[Pavel]

Цитата:

Изначально опубликовано Гость
а без такого представления у меня нет альтернативы автоматизации. Ведь, как известно, свобода - осознанная необходимость

"а опыт - сын ошибок трудных"
Только не совсем понятно, зачем принимать лекарство, которое одну болезнь лечит и еще само добавляет пять новых.

[Гость]

Знал бы заранее клиническую картину последствий, глядишь и избежал бы заражения Аксаптой. А теперь приходится решать: сразу умереть здоровым без квартального отчета или пожить еще недолеченным аудиторами.
...
P.S. "Женись! Попадется хорошая - станешь счастливым, плохая - философом. Не знаю что лучше..."

[Pavel]

Цитата:

Изначально опубликовано Гость
"Женись! Попадется хорошая - станешь счастливым, плохая - философом. Не знаю что лучше..."

Склонность к философии уже "налицо".
Правда ERP систем состоит в том, что они не прощают ошибок. Каждая неверная настройка и решение приводят к лавинообразному росту трудозатрат на исправление введенной информации. В такой ситуации проще учет суммовых разниц вести параллельно в Excel.

[Гость]

В такой ситуации проще учет суммовых разниц вести параллельно в Excel. [/QUOTE]

Вот я и думаю... может надо было сразу все в Excel?

[Pavel]

Цитата:

Изначально опубликовано Гость
[B]Вот я и думаю... может надо было сразу все в Excel?

Эт, точно... (товарищ Сухов)