mikejum Jul 30 2013 at 08:33

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

6 min

10K

Comments 23

drtitoff Jul 30 2013 at 08:53

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

mikejum Jul 30 2013 at 08:58

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

datacompboy Jul 30 2013 at 09:03

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

mikejum Jul 30 2013 at 09:09

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

datacompboy Jul 30 2013 at 09:14

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

mikejum Jul 30 2013 at 09:17

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

mayorovp Jul 30 2013 at 14:43

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

mikejum Jul 30 2013 at 15:39

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

Propheta13 Jul 30 2013 at 15:57

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

mikejum Jul 30 2013 at 16:00

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

icoz Jul 30 2013 at 23:20

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

Flyd Jul 30 2013 at 09:56

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

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

mikejum Jul 30 2013 at 09:59

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

Asmody Jul 30 2013 at 12:18

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

badun1 Jul 30 2013 at 11:21

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

UFO landed and left these words here

mikejum Jul 30 2013 at 16:43

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

UFO landed and left these words here

mikejum Jul 30 2013 at 17:18

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

mayorovp Jul 30 2013 at 18:31

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

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

mikejum Jul 30 2013 at 18:42

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

mayorovp Jul 30 2013 at 19:05

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

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

mikejum Jul 30 2013 at 19:34

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