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

[gene]

Цитата:

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

соответствие может быть установлено между двумя кредитами или между двумя дебитами, как в данной ветке
граф останется двудольным.

Тогда в исходной цитате вообще не нужны слова "дебет" и "кредит". Соответствие устанавливается просто во множестве всех записей по счетам ГК внутри одной операции. Единственная цель - чтобы сходились сумма дебетовых записей и сумма кредитовых. Чем номер ваучера, как признак соответствия, не устраивает?

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

Цитата:

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

работаем же

Ну то есть исправлением пары строк не закончится. Оборотные отчеты, ГФО, да просто форма отображения операций ГК. И бог знает где еще вылезут последствия, что одна из скорреспондированных проводок имеет признак "коррекция", а другая - нет...
И все же - зачем вообще тогда мучать российскую корреспонденцию? Почему не отказаться от нее вовсе? Ведь, грубо говоря, регламентированные формы не требуют корреспонденции один к одному. "Шахматка", анализ счета и т.п. - это рабочие отчеты, от которых можно отказаться или модифицировать под международную запись.

[fed]

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

[mazzy]

Цитата:

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

Тогда в исходной цитате вообще не нужны слова "дебет" и "кредит". Соответствие устанавливается просто во множестве всех записей по счетам ГК внутри одной операции. Единственная цель - чтобы сходились сумма дебетовых записей и сумма кредитовых.

ага. да, так лучше:

Цитата:

корреспонденция = между суммами в одной операции установлено соответствие (возможно n:n, причем граф соответствий обязан быть двудольным, однако нет никакий оснований, что признаки Дт и Кт ВСЕГДА являются признаками разбиения.)

Цитата:

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

Чем номер ваучера, как признак соответствия, не устраивает?

Не понял.
Ваучер = Номер операции = признак, одинаковый для всех записей в операции
Корреспонденция = это соответствие между записями внутри одной операции.

как ваучер может быть признаком соответствия?

Цитата:

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

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

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

Цитата:

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

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

нормально. для них важны обороты и анализ счетов.
проводки Дт,-Дт или Кт,-Кт как раз не меняют ни оборотов.
и анализ корректируют как надо

Цитата:

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

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

Дык, "локализаторы"... извините за использование сборного термина... сводят Дт,Кт к +-
В большинстве своем корректно учитывая галочку коррекция (сторно).
Но иногда бывают промашки.

Цитата:

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

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

регламентированные отчеты очень сильно используют корреспонденцию.
без корреспонденции регламентированные отчеты можно построить если только следовать другому соглашению международной аксапты: раличать счета дебета и кредита.

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

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

[mazzy]

Цитата:

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

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

Гы...

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

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

Цитата:

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

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

Согласен.

[mazzy]

выделю свою мысль:

Цитата:

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

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

только подумайте - это возможно.
можно делать проводки Дт, -Дт. например, Дт 62.1, -Дт 62.2. В целом по 62 оборот не изменится. Задолженность по клиенту не изменится. А запись о событии - есть.

[mazzy]

Цитата:

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

Я попытаюсь ночером найти эти несколько строк, которые надо поправить, чтобы получить корреспонденцию в более общем случае, чем сейчас.

приложил проект для ax2009
по-моему только эти два метода в двух классах.

краткое пояснение к патчу (fast-and-dirty programming, минимизировать проблемы при дальнейших апдейтах):

• сама корреспонденция работает с абсолютным значением суммы (хорошо видно на втором скриншоте) и с переменной crediting. Про correction внутри классов забыто.
• поэтому убираем полностью упоминание correction при инициализации и в определении дебетовой и кредитовой стороны.

как надо бы сделать по-хорошему:

• убрать нафих безумный abs и безумный sign (например, см. метод LedgerBondTransObject_RU\addBondAmounts)
• убрать безумный LedgerBondAmountSide_RU (например, см. метод LedgerBondServer_RU\splitTrans)
• просто всегда складывать положительные и отрицательные суммы согласно определению из этого сообщения

но переделка "по-хорошему" приведет к тотальному рефакторингу классов семейства LedgerBond. Я не могу себе позволить сделать такое на клиентах - для них это сильно затруднит дальнейшие апгрейды. Поэтому у клиентов делается минимальный вариант изменений.

[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

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

[gene]

Цитата:

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

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

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

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

[propeller]

Не отрабатывает ручная корреспонденция для проводок с типом разноски "Допустимое расхождение во втор. валюте". Проверка затыкается на том что "сумма в валюте" равно нулю.
Что посоветуете в таком случае?
Спасибо.

[Alexanderis.ua]

Попробовал смоделировать.
У меня получилось, если сначала точечно (<->) откорреспондировать проводки с расхождением, а потом уже все остальные (<<->>).

Причины не выяснял - главное что работает

[propeller]

Цитата:

Сообщение от Alexanderis.ua

Попробовал смоделировать.
У меня получилось, если сначала точечно (<->) откорреспондировать проводки с расхождением, а потом уже все остальные (<<->>).

Причины не выяснял - главное что работает

Точечно та же ошибка, когда корреспондируешь две проводки с 0 в поле "сумма в валюте"

[Alexanderis.ua]

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

Если корреспонденция дергается только для пары проводок и в обеих есть сумма только во вторичной валюте, то выполняется совершенно другой метод.
У Вас никаких кастомизаций нет на классах Bond_RU?

[propeller]

Цитата:

Сообщение от Alexanderis.ua

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

Если корреспонденция дергается только для пары проводок и в обеих есть сумма только во вторичной валюте, то выполняется совершенно другой метод.
У Вас никаких кастомизаций нет на классах Bond_RU?

Ваша подсказка навела на мысль, что мы не правильно выбрали пары проводок для сопоставления Спасибо.