Ручная корреспонденция проводок

[ViV]

Добрый день!

Возникла такая ситуация :
Пользователь в одном журнале клиентских платежей создал две строки - одна сторно (по кредиту -0,1 коп) и соответственно правильная (в кредите 0,1 коп.).
При разноске Аксапта сказала, что не может автоматически установить корреспонденцию на эти проводки. Ок. Заходим в ручное сопоставление...
НО и там не удается их сопоставить - потому как у нас 3 дебетовых части и всего 1 кредитовая...
Как бороться с последствиями такой ситуации?

P.S. Альтернатива понятна - если разнести строки по разным журналам, то все хорошо...

[glibs]

Проблема не в журналах, а в номере документа ГК.

Я один раз программно пытался бороться с данной проблемой, локально победил, но результат в долгосрочной перспективе оказался неудачным (пришлось выкинуть).

Однако с тех пор в разноске документа ГК была реализована проверка, запрещающая в одном ваучере и сторно и несторно операции, если это не нереализованная КР по клиентам/поставщикам.

[ViV]

Цитата:

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

Однако с тех пор в разноске документа ГК была реализована проверка, запрещающая в одном ваучере и сторно и несторно операции, если это не нереализованная КР по клиентам/поставщикам.

Спасибо!
Видимо прийдется доделывать подобную проверку...

А если проводки так и останутся не сопоставленными - на что это повлияет?

[Михаил Андреев]

Цитата:

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

А если проводки так и останутся не сопоставленными - на что это повлияет?

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

[Yprit]

Цитата:

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

Однако с тех пор в разноске документа ГК была реализована проверка, запрещающая в одном ваучере и сторно и несторно операции, если это не нереализованная КР по клиентам/поставщикам.

glibs, а не могли бы Вы ткнуть носом в эту проверку? Что-то в четверке я ее не смог найти...

[glibs]

Цитата:

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

...
Я один раз программно пытался бороться... пришлось выкинуть... Однако с тех пор в разноске документа ГК была реализована проверка
...

Речь шла о кастомизации на проекте.

[IvanHARD]

Проводки не сопоставлются из-за того, что при наличии прямой и сторно проводки с одним ваучером в LedgerTrans слетают поля Correct, Credit и знак суммы в AmountCur/AmountMST

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

Аналогичная ситуация возникает при одновременной разноске положительных и отрицательных строк по заказам/закупкам.

Для общего журнала самое эффективное решение - добавление в в поле "Изменение номера" названий журналов еще одного значения "Уникальные номера". Это никак не сужает функционал, т.к. российская бухгалтерия все равно превращает в рудимент все остальные варианты присовения номера ГК.

[fed]

От себя добавлю, что действительно в 4ке (равно как и в 3ке) разваливается корреспонденция, если попытаться откорреспондировать две половинки проводки с разным режимом сторнирования (типа по 62 счету - стороно, а по 90ому - нормальная проводка). Но такого эффекта можно добиться только собственными силами - хорошенько попрограммировав В стандартной функциональности система не делает подобных попыток корреспонденции...

[glibs]

Цитата:

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

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

Неправда, в общем журнале ГК данный эффект воспроизводится без проблем без какого либо программирования.

Не нужно по себе других мерять. Серьезное перепрограммирование системы — не наш подход.

[fed]

Цитата:

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

Неправда, в общем журнале ГК данный эффект воспроизводится без проблем без какого либо программирования.

Гм. А ведь и вправду. Как-то я не привык многострочные проводки в общем журнале делать. Спасибо за информацию. Но тем не менее - в целом ситуации это не меняет. Корреспонденция ломается не от того что В ОДНОМ документе есть и стороно и обычные проводки, а от того что мы пытаемся в ОДНОЙ проводке скорреспондировать и сторно и обычную половинку проводки.

[Aleks_K]

Увы и ах, проблема жива и в 2009 АХ


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

З.Ы. Цель операции - перебросить сальдо между договорами без оборотов по счету ГК.

[gene]

Цитата:

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

Увы и ах, проблема жива и в 2009 АХ
Решается только программированием? Птичку "Коррекция" снимать нельзя (если снять, тогда разбросит по разным окнам), т.к. в т.ч. по ней связываюсь с проводкой клиента при построении отчета.

З.Ы. Цель операции - перебросить сальдо между договорами без оборотов по счету ГК.

Скажите, пожалуйста, а какой результат вы ожидаете увидеть при выполнении такой операции? Ведь вы пытаетесь создать две дебетовых проводки ГК. И как именно система должна их скорреспондировать?

В данной ситуации, ИМХО, единственное решение - использование некоего транзитного счета ГК. Тогда все нормально работает, включая проставление галок "Коррекция" везде, где надо (скриншоты - AX2009 SP1 RU-6 GLS EE).

[mazzy]

только программированием.
локализаторы "забыли" про галочку коррекция.

[fed]

С точки зрения российской бухгалтерской традиции, не вижу никакого экономического смысла в "проводке с двумя дебетами". Более того, не вижу никакого экономического смысла в подобной проводке и с точки зрения западной учетной традиции. Так что не надо ничего менять, корреспонденция неплохо работает, и на моей практике, всех клиентов устраивала.
Единственное что можно было бы сделать - это добавить в момент корреспондирования проверку, которая выдавала бы явное сообщение типа "Попытка корреспондировать сторно по счету xx.yy и не-сторно по счету qq.pp". А то сейчас сообщение достаточно неинформативное выдается, если из за багов в собственном коде нечаянно попытался скорреспондировать сторно и не сторно, тяжело бывает понять сразу, почему корреспонденция развалилась.

[mazzy]

Цитата:

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

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

Гы...

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

в буржуйской традиции таких извратов Дт,-Дт (Кт, -Кт) действительно не делают по нескольким причинам:
1. если проводка важна для управленческого учета, что ее надо по смыслу отображать в финансовом учете - то ее просто отображают. accruals, начисление авансовой задолженности и т.п. За accruals российского бухгалтера расстреляют, потому что у проводки нет документарного обоснования
2. в буржуинии не используют анализ счета. они просто для каждого типа операции вводят свой субсчет и делают закрывающие проводки между субсчетами. В этом случае вполне достаточно trial balance (наш аналог - оборотка)
3. если есть необходимость отразить в проводках что-то, не относящееся к фин.учету, то в Аксапте есть layers (слои). Слои также не учитываются в алгоритме корреспонденции, поэтому использование слоев при включенной корреспонденции приводит к жутким побочным эффектам

Цитата:

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

А то сейчас сообщение достаточно неинформативное выдается

Согласен.

[gene]

Спасибо за пример. Изучим. Возможно, на основе этого действительно можно построить работающую модификацию корреспонденции.
Несколько вопросов:
1. Для скольких клиентов вы реализовали подобную модификацию?
2. Сколько из п.1 ведут бухгалтерский учет в Аксапте и пользуются такими операциями в бухгалтерском учете?
3. Можете ли вы зарегистрировать эту ошибку в поддержке MS или предложение через MSConnect, с тем, чтобы плодами исправления могли пользоваться все клиенты MS? Потребуется реальный бизнес-кейс и обоснование необходимости и правильности такого подхода с точки зрения законодательства.

[mazzy]

Цитата:

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

Спасибо за пример. Изучим. Возможно, на основе этого действительно можно построить работающую модификацию корреспонденции.
Несколько вопросов:
1. Для скольких клиентов вы реализовали подобную модификацию?

у четырех последних.
но я бы постеснялся назвать это модификацией.

Цитата:

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

2. Сколько из п.1 ведут бухгалтерский учет в Аксапте и пользуются такими операциями в бухгалтерском учете?

тут надо разделить.
пользовались этой фичей все - все вели финансовый учет.
бухгалтерский учет в аксапте ведут текущие. остальных я обычно убеждал на экспорт в ЛПБ (любимую программу бухгалтера).

можно сформулировать так: анализами/оборотками и корреспонденцией пользователи все. при этом российский бухгалтерский учет вели не все.

Цитата:

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

3. Можете ли вы зарегистрировать эту ошибку в поддержке MS или предложение через MSConnect, с тем, чтобы плодами исправления могли пользоваться все клиенты MS? Потребуется реальный бизнес-кейс и обоснование необходимости и правильности такого подхода с точки зрения законодательства.

Могу.
Но если честно, то меня так заколебали требования поддержки по поводу reprostep's, просьб дать пример, просьб уточненить и т.п. причем всегда писал примерно так, как и здесь... а потом ввели и платную подписку и любое предложение сперва начинают трактовать как вопрос... примерно как и вы здесь ... что... в общем я давно не занимаюсь регистрацией чего бы то ни было в поддержке MS.

Про connect. Я вижу бету ax2009. не вижу беты ax2012 (только TAP). не вижу connect'а к текущей версии ax. Буду признателен, если дадите ссылку.

[mazzy]

Цитата:

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

Возможно, на основе этого действительно можно построить работающую модификацию корреспонденции.

Да, и еще.

Будете модифицировать/рефакторить, сделайте так, чтобы корреспонденция не ломала Layers/Слои. Очень удобная фича, но сейчас
ею пользоваться нельзя из-за проблем с корреспонденцией.

Layers/Слои в наших организациях в основном используется для ведения управленческого учета на тех же счетах, что и бухгалтерский.

Спасибо.

[gene]

Цитата:

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

Да, и еще.

Будете модифицировать/рефакторить, сделайте так, чтобы корреспонденция не ломала Layers/Слои. Очень удобная фича, но сейчас
ею пользоваться нельзя из-за проблем с корреспонденцией.

Layers/Слои в наших организациях в основном используется для ведения управленческого учета на тех же счетах, что и бухгалтерский.

Спасибо.

Добрый день!

Чтобы прояснить свою позицию: на данный момент ни я, ни мои коллеги, с кем я обсудил эту тему, не можем считать такое изменение в корреспонденции обоснованным с точки зрения правил бухучета. В управленческом учете - возможно, но мы-то локализуем в первую очередь именно для официального бухучета, а здесь - пока неясность, и можно придумать еще много разных возражений против подобного способа записи в бухучете... Тем не менее, я попробую запросить у наших консультантов по бухучету обоснование возможности или невозможности такого способа записи.
По поводу зарегистрировать ошибку - я, пожалуй, погорячился, это действительно вряд ли имеет смысл. Хотя бы потому, что имеется простой workaround - используйте промежуточный счет, и получите более-менее требуемый результат.
Правильный путь - зарегистрировать предложение в MSConnect, причем чем больше будет таких запросов - тем больше вероятность их реализации. Насколько я знаю, это бесплатно, да и формальные требования к описанию запроса заметно попроще.
По поводу подсоединения к коннекту, ссылок и т.п. сейчас напишу в личку, чтобы не засорять тему.

Про Posting layers - отдельная тема, я поконсультируюсь с разработчиками, что мы можем сделать в 6-ке. Для исправления этого в 5-ке однозначно нужен запрос в поддержку, и тут, как мне кажется, все заметно проще, чем с хитрой корреспонденцией, описанной выше, - присутствует явная легко воспроизводимая ошибка, которая дожна быть исправлена.

Спасибо,
Евгений.

[mazzy]

Цитата:

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

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

Угу. Позиция понятна.
Только опять "локализация бухучета" излишне ограничивает функциональность.

то, что локализация "в первую очередь" направлена на бухучет, не должно ограничивать возможности функционала, если возможности не противоречат бухучету

а то получается примерно как в мультике "подтягивая вершки, запарываем корешки"
http://www.youtube.com/watch?v=PkxC70w86_g#t=4m14s

См. также: ОПРОС: Каков процент внедрений Аксапты с бух учетом - в общем числе проектов внедрений Аксапты