ЯОФ – язык отчетных форм

[@drtitoff]

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

[@mikejum]

Для решения Вашей задачи нужен специализированный ЯРЗК (Язык Расшифровки Зарплатных Корешков).

[@datacompboy]

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

[@mikejum]

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

[@datacompboy]

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

[@mikejum]

… или объяснить программисту, что такое развернутое сальдо.

[@mayorovp]

А что в нем сложного?

[@mikejum]

Вот и я думаю — что?

[@Propheta13]

Оно еще и развёрнутое бывает?

[@mikejum]

Свернутое-развернутое, начальное-конечное, входящее-исходящее, активное-пассивное, дебетовое-кредитовое. Возможно, я что-то упустил.

[@icoz]

Прям считалочка…

[@Flyd]

>>Насколько данные языки пригодны для использования в качестве универсального языка отчетных форм, не знаю в силу слабого знакомства с ними.

В 1С для построения отчетов есть система компоновки данных (СКД). Позволяет создавать сложные отчеты чаще всего в режиме конструктора, но есть возможность и программного создания.
howknow1c.ru/programmirovanie-1c/skd-1s.html

[@mikejum]

Спасибо за ссылку. Посмотрел, приму к сведению.

[@Asmody]

Уж если давать ссылки, то на первоисточник:
Система компоновки данных v8.1c.ru/overview/Term_000000093.htm
Пример разработки отчета в системе компоновки данных v8.1c.ru/overview/dcs_sample_report.htm

[@badun1]

На самом деле затронут весьма интересный вопрос. По специфике работы, сталкиваюсь с подобным около 2-х лет. К сожалению, ни стандартизированого языка, ни методологии, ни даже industry standard'а я не нашел. ERP имеют свою структуру данных(транзакции), DWH сохраняют аггрегированные состояния, OLAP добавляет логику консолидации. Но все это не подходит для неструктурированной отчетности. Лучшее, что на данный момент придумано — Excel. Бухгалтеры и финансисты думают екселем.
А если требование — построить систему корпоративной отчетности для фоомирования неструктурированных отчетов(100+ страниц), все становится интереснее.
На данные момент пока лучше всего себя показала связка ERP->DWH->OLAP->openquery->sql(star schema) -> report.
И да, модели данных для таких отчетов — смерть для Кимбала и Инмона.

[@mikejum]

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

[@mikejum]

Софт — это софт, а язык — язык. В существовании подобного софта я не сомневался, а насчет языка не понял. Если преобразования, выполняемые с базой, можно записать в виде вербального кода высокого уровня, тогда язык существует. Остается вопрос: насколько он будет понятен бухгалтеру? а если непонятен, нельзя ли придумать что-то попонятней? а когда станет совсем понятно, нельзя ли использовать данный язык в нормативных актах по бухгалтерскому учету? Хотя последний вопрос не к программистам, разумеется.

[@mayorovp]

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

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

[@mikejum]

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

[@mayorovp]

названия свойств и измерителей в разных базах будут разными

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

[@mikejum]

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