измерения учтенных операций

[Alex_V]

Столкнулся со следующей проблемой:
(пример для cronusa)

1. создаю заказ покупки
2. присваиваю заказу измерение ПРОЕКТ=МЕРСЕДЕС (Заказ->Измерения)
3. Создаю строку заказа
4. присваиваю строке измерение ОТДЕЛ=ПРОДАЖА. В итоге в измерениях строки указаны 2 строчки:
ПРОЕКТ=МЕРСЕДЕС
ОТДЕЛ=ПРОДАЖА
6. учитываю заказ
7. смотрим финансовые опреации
Финансы->Регистры->Фин. операции
создано 3 операции: две дебетовые(одна из них по НДС), одна кредитовая.
8. теперь смотрим измерения по этим операциям (операция->измерения):
у дебетовых операций: два измерения (ОТДЕЛ и ПРОЕКТ) а у кредитовой только одно (ПРОЕКТ - измерение документа).
9. В итоге вся аналитика которая строится с помощью финансовых отчетов (у клиента используются как дебет так и кредит суммы) рушится - несоответствие дебетовых и кредитовых сумм

Кто нибудь сталкивался с такой проблемой? И как решали?

другая проблема, вытекающая из приведенной выше:
при учете заказа покупки с двумя строками (у каждой есть измерение ОТДЕЛ но со своим кодом) образуется 4 (2-НДС) дебетовые операции и ОДНА кредитовая. Естественно что кредитовая операция будет снова содержать только измерение присвоенное документу.

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

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

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

У кого какие соображения по этому поводу.

[Тимур]

1) Вы смотрели настройки приоритетности Измерений?
Пустое значение Измерения - это тоже значение.
2) Скажите, пожалуйста, если в двух строчках заказа на закупку будут разные значения "Отдел", то какое значение должно быть в шапке заказа? А ведь именно из нее берутся все значения измерений в кредит, когда вы учитываете заказ.
Если значения измерений в строках одинаково, то тогда зачем их вводить в строки? Вводите в шапку. И будет у Вас и в кредите и в дебите нужные значения.

[Alex_V]

Цитата:

Изначально опубликовано Тимур
1) Вы смотрели настройки приоритетности Измерений?
Пустое значение Измерения - это тоже значение.

приоритетность в данной проблеме не поможет и можно даже сказать - ни при чем.

Цитата:

2) Скажите, пожалуйста, если в двух строчках заказа на закупку будут разные значения "Отдел", то какое значение должно быть в шапке заказа? А ведь именно из нее берутся все значения измерений в кредит, когда вы учитываете заказ.
Если значения измерений в строках одинаково, то тогда зачем их вводить в строки? Вводите в шапку. И будет у Вас и в кредите и в дебите нужные значения.

см. вторую проблему из вопроса и возможные решения.

вопрос в том каким образом лучше исправить уже существующие (неподходящие для аналитики) наборы данных по измерениям касательно 1-ой и 2-ой проблем. И как лучше модифицировать учетную процедуру-чтобы это не повлекло за собой дальнейших проблем.

[Тимур]

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

[Scorpie]

Товарищ так и хочет. Только он жалуется что кредитовые операции не разбиваются пропорционально дебетовым. Т.е. если строки покупки мышек шли с измерением отдел (ИТ и БУХГ),а в шапке для поставщика указано измерение РЕГИОН=АЗИЯ, то ему хочется видеть кредит, не только с измерением АЗИЯ, но и разбитый пропорционально отделам...
По-моему проще поменять отчётность...

[Alex_V]

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

[Тимур]

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

[Консультант]

Действительно, отсутствие экономического образования часто превращается в самостоятельную экономическую теорию.

Так вот, в учете первичным элементом является операция со следующими параметрами: описание, дата, сумма. Все остальное - аналитика. И такие признаки, как дебетуемый и кредитуемый фин.счета - тоже аналитика, введенная в 1600 каком-то году Лукой Паччоли. Комбинация этих двух обязательных признаков получила название проводки. И это не является совковой или русской причудой, это - мировой стандарт. Изучайте Navision! Он придумывался отнюдь не для русских.

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

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

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

И никто никогда не будет переделывать методологию бухгалтерского учета в угоду одной корявенькой и редко там применяемой программке.

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

[Тимур]

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

Вам же советую почитать труды Я.Соколова на тему происхождения итальянской записи и о том, где она применяется, а также почему англо-саксонская стала мировым стандартом. Да хоть на том же www.buh.ru

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

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

Цитата:

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

Где эта общепринятая методология учета? Кем принята? Коминтерном? Или Советом крестьянских и солдатских депутатов?
Общепринятых техник учета нет. Есть национальные школы учета. Превалируют в мире англо-саксонская, и вовсе не по политическим причинам, а по причинам целесообразности (детали почерпните у Соколова).

Операция не исчезает. "Обрывки" связаны уникальной ссылкой. Если есть сомнения - то залезьте в таблицы и убедитесь.

Цитата:

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

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

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

[Консультант]

>Операция не исчезает. "Обрывки" связаны уникальной ссылкой. Если есть сомнения - то залезьте в таблицы и убедитесь.

Очень конструктивный подход. Только советую с таким подходом без охраны в бухгалтерию не входить.

Короче, ясно: Navision, сертифицированная для бухгалтерского учета программа, на самом деле ведет тайную революционную работу по свержению расово неполноценного русского бухучета.

Нам остается либо признать свою неполноценность перед лицом просвещенного Билла Гейтса и модератора Тимура, либо модифицировать систему в соответствии с действующей методологией учета. Уважаемый Тимур, считайте, что мы делаем и то, и другое.

[Тимур]

В каком месте Navision противоречит российским правилам ?

Уважаемый Консультант, где Ваши аргументы и факты? Вижу только эмоции:
"Только советую с таким подходом без охраны в бухгалтерию не входить". Не раз объяснял и доказывал устарелость советской техники учета лично и не бухгалтерам не одного предприятия (и в глубинке и в Москве).

Уникальная ссылка позволяет связать проводки, хоз. операцию и документ-основание. Если Вы не знаете, как пользоваться функционалом Navision, то стоит обратиться к документации.

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

P.S. Очень неконструктивно дискутируете.