Клиент к казначейской базе

Всё что угодно можно делать разными способами. В данном случае разными инструментами. Естественно хочется побыстрее, попроще но чтобы работало. Побыстрее и попроще особо важно когда есть вероятность того что много чего надо будет быстро менять (а тут именно так).
Строго говоря, не имеет значения на чём писать клиента. Быстродействие – задача сервера и программиста, который делал базу (индексы хотя бы должны быть).
С другой стороны есть… правила хорошего тона. Лучше работать с базой через представления (VIEW) и хранимые процедуры (Stored Procedure). Это позволяет работать с информацией ещё быстрее. К казначейской базе я их прицепить не могу. Могу к созданной своей (которая уже будет обращаться к казначейской). Этот вариант был бы изначально более сложный (не просто копировать нового клиента на диск, но и подключать свою базу к серверу, например).
Выбранный вариант – отправка серверу сгенерированных клиентом SQL строк в расчёте на его быстродействие. Я стараюсь так не делать. Причина немного смешная.  Году, что ли, в  2003-м офисная база была переведена с Access-а (и SQL обращений к нему) на SQL-Server и хранимые процедуры. Большой и тяжёлый отчёт вместо 5 минут начал делаться за секунды.
Машины с тех пор стали мощнее, да и сервер это всё-таки сервер. К тому же так работает и 1С (со всеми базами) и, подозреваю, само «Казначейство» (т.е его стандартная клиентская программа).
С ограничением всё-таки столкнулась позавчера. Не могу отправить на сервер длинную строку запроса. Обойду это как-нибудь))).
Что касается экранных названий.. то это не поможет… пока. Я всё-таки это быстренько для себя делала потому предпочла делать так. С другой стороны содержимое колонки и так позволяет понять что это. Написано там «CVR» или «Код вида расхода» не так важно для того, что знает, какие коды для чего используются.
Проблема в другом. Вот, например, кусок таблицы:

Вам не станет легче от замены названия «CCS_FULL» на «код целевой статьи», а любой, кто с этим имеет дело знает, что из всех кодов только целевая статься такая длинная. И что код раздела (в данном случае «0701» принято писать перед целевой статьёй.
У меня, кстати, сверху вот такие удобные списки с наименованиями:

… потому что я их тоже не помню.
А плохо тут то, что реально это не просто запись документа а вполне себе бухгалтерская проводка. Потому тут те самые два CVR-а (кода вида расходов). Для учреждения это «119» -  налоги на зарплату, а для пусть комитета финансов (который перечислил эту сумму для выплаты) это «611» - передача денег другому учреждению.
Проводка тут Дебет Учреждение->Расход зарплата Кредит Город->Межбюджетный трансферт.
Нет такой проводки. Чтобы всё было логично, её придумать надо. Есть чистая бухгалтерия, но её просто не хватает когда много объектов по разным отраслям. Приходится придумывать эту «отраслевую» надстройку. Потому что какой-нибудь купленный компьютер это не только закупка оборудования по бухгалтерскому счёту это ещё расход на отрасль «рестораны» или «магазины», например. Это тоже надо учитывать. Бюджетные коды (которые не бухгалтерские!) придуманы именно для этого.  Но если к ним не привязать бухгалтерский метод двойной записи (метод я не план счетов!) то будет тяжело вытаскивать информацию. И объяснять что-то сложно. И названия не помогут, потому что я для себя представляю, что мне надо просуммировать это, это и это, вычесть это, а результат должен примерно совпасть с суммой вот этого. Вся информация вытаскивается но это всё тяжело потому что логической надстройки нет. У меня последняя офисная база называлась «kassa_m» т.е модернизированная. Предыдущий вариант и бы чистой бухгалтерией к которой под вдохновение прикручивались какие-то справочники -классификаторы, или вообще программы с жесткой привязкой что к какую ячейку отчёта засовывать.
Это всё собираемо. Я, повторюсь, вижу по строке что там скорее всего происходило, Но наружу это объяснить сложно. В рамках надстройки проще названия придумывать. А для того кто с этим работает это не очень-то и надо))).
Когда первые учетные программы начали появляться можно было встретить всякие генераторы документов (накладных, платёжных поручений и т.д). При простом учете и не надо никакой бухгалтерии. В платёжном поручении есть только реквизиты получателя, т.е половина бухгалтерской проводки. А половина и так понятна, это расчётный счёт конторы. Т.е проводку написать можно, главное чтобы сумма по платёжкам быстро считалась. Точно также в любом документе можно увидеть проводку. Договор, например, это вид планирования, т.е все варианты планирования в двойную запись укладываются. Я не хочу что-то плести беспредметно, а беспредметно будет чуть позже.
Пока это особо не мешает (а мне помогает), а потом легко поменять.
 А для понятности тут другое нужно, заголовки не помогут.
p/s
Ещё есть ощущение что они в программу, рассчитанную на другой вариант работы засунули нечто новое. Прикрутили и оно работает, но с названиями, по крайней мере внутренними там несколько странно. Если их брать совсем плохо будет.