Никому не нужный ликбез про 1С (14 стр)

war_zes
> есть ли возможность из других языков делать запросы в 1С именно его средствами?

Есть, конечно. Если платформа стоит на машине, то в системе регистрируется COM-Объект (Automation) Connector с помощью которого можно подключиться к базе и получить на руки весь комплекс программных объектов 1С как если бы выполнялся код на 1С (но без UI, что называется режимом внешнего соединения): https://v8.1c.ru/platforma/vneshnee-soedinenie/

Шок, трепет!
Язык программирования 1С обзавёлся диалектом со статической типизацией!!!
Я об этом узнал только вот прямо сейчас: https://v8.1c.ru/platforma/1s-predpriyatie-element/

=A=L=X=
> Итак, приходят бухгалтера из-за одной ссаной копейки
Мда, на что жизнь уходит

1Man1
> Мда, на что жизнь уходит

Когда з/п капает я всё им прощаю.

=A=L=X=
Копейка говоришь... Я как-то накосячил и сумма на несколько штук не сходилась :)

innuendo
> Я как-то накосячил и сумма на несколько штук не сходилась :)

Лол, у меня только пару месяцев назад был прикольный глюк где можно даже сказать мне помогли навыки игродела!

Таинственное дело Иван Иваныча: управленческий отчёт по фирме вывел по расчёту зарплаты оборот в сотни триллионов рублей за месяц.
(оборот тут в том смысле что в плюс идёт задолженность фирмы перед работниками по зарплате в результате их деятельности, а в минус - погашение этого долга документами выплаты зарплаты)
И вот оборот в сотни триллионов!
Начали разбираться - сперва управленцы сами сузили круг подозреваемых до одного магазина, а потом до одного конкретного сотрудника в этом магазине - вот по нему одному конкретному Иван-Иванычу возник стотриллионный оборот.
Отдел поддержки никаких криминальных движений в регистрах не выявил.
Who do you gonna call? Сектор эксплуатации!!!

Так вот оказалось там был задействована та же схема вычислений, что с копейкой - несколько строк с суммами распределялись по статьям В ПРОПОРЦИИ от того насколько в них большие суммы.
Стандартный алгоритм - сперва считаем сумму всех сумм, а потом выходим на ДОЛЮ каждой через текущая_сумма/сумма_всех_сумм.
Так вот в этом конкретном случае у Иван Иваныча после вычисления всех НДС и приходов-расходов получалось, что сумма_всех_сумм сравнялась с...
0,00000000001 рубля!
И ОН НАЧАЛ ДЕЛИТЬ.
При этом всё честно сделал - если аккуратно возникшие астрономические суммы просуммировать, то всё идеально - Иван Иваныч получил за свою работу честные там 20300 премии согласно окладу.
Но оно порвало оборот всей Российской Федерации на два. :D

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

=A=L=X=
ОБЭП вызывали ? :(

=A=L=X=
> Когда з/п капает я всё им прощаю
А как же ощущение нужности, полезности своего дела?
Или ты, как ассасин, достиг осознания, что ничто не истинно, все бессмысленно?

> выходим на ДОЛЮ каждой через текущая_сумма/сумма_всех_сумм
Так как же доля получилась больше суммы всех сумм? Косяк в алгоритме

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

1Man1
> А как же ощущение нужности, полезности своего дела?

А в чём ты тут увидел проблему?
Группа компаний 20+ тысяч сотрудников.
Их всех надо принимать на работу, оплачивать больничные, рассчитывать зарплату.
Интеграция феноменальная.
В момент приёма на работу в программе ЗУП она создаёт пользователя и в зависимости от занимаемой должности и типа рабочего места создаёт учетку в Active Directory и десятке других программ, включая, например WebTutor где сотрудники проходят обучение сообразно своей должности. При увольнении - удаляет/деактивирует учётки.
Автоматически проводится цикл сбора документов с подписями - например, при приближении отпуска сотрудника его начальнику в программе Документооборот или Единое окно приходит задача на подписание приказа на отпуск, он прикладывает скан документа в программу, только после одобрения отдела кадров процесс сдвигается дальше, автоматически создаются документы на отпуск и так далее.
Человек не вышел на работу - программа автоматически ставит ему прогул из-за отсутствия его лица на камерах в магазине в день когда он должен был быть на смене. Днём позже в автоматическом обмене с Социальным Фондом России (СФР) приходит входящее сообщение, что сотрудник открыл больничный лист в прикреплённой поликлинике - программа вводит документ БольничныйЛист который перебьёт документ ОтсутствиеПоНевыясненнойПричине и сделает всё по закону. Начисления начисляться, фонды пополнятся средствами, человек не уйдёт обиженным.

Где здесь отсутствие полезности?
Штат в 20 кадровиков тянет 20+ тысяч сотрудников.

1Man1
> Так как же доля получилась больше суммы всех сумм? Косяк в алгоритме

Это потому что приход-расход, суммы могут быть как + так и -.
Косяк в алгоритме был - это отсутствие eps. Было сравнение на строгий ноль в предположении, что приход-расход если минусы тянут вниз должен сойтись в ноль.
Но из-за того, что суммы перед этот протаскивались через такие вещи как вычисления процентов (НДФЛ), то могут появиться циклические дроби 0,333... и поехало.
Случай на самом деле всплыл в первый раз за лет десять работы без осечек.
Вот конкретно у Иван Иваныча все эти суммы и НДФЛ так выпали, что сумма сошлась не в 0, а в 0,000000000001.
А если бы стала 0, то алгоритм переключился бы на равнодолевое раскидывание сумм.

=A=L=X=
> Где здесь отсутствие полезности?
Я про поиск одной копейки
> Вот конкретно у Иван Иваныча все эти суммы и НДФЛ так выпали, что сумма сошлась не в 0, а в 0,000000000001
А делимое какое? Должно же тоже стремится к 0. И странно, что в делителе сумма <1 копейки

1Man1
> Я про поиск одной копейки

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

> А делимое какое? Должно же тоже стремится к 0. И странно, что в делителе сумма <1 копейки

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

Сегодня поговорим про представления.

В стандартных моделях SQL есть VIEW - заранее составленные запросы которые можно дёргать как будто это таблицы, но они на самом деле превратятся в запросы. Главная мысль в том, что поменяв текст запроса VIEW мы сразу отразим изменения на весь код который делает обращения к VIEW не меняя сам код. Очень хорошая концепция.
Однако... в базовой модели 1С никакого аналога VIEW - просто нет, отсутствует как класс.
А ведь это БД-ориентированный продукт и неужели у приложения которое вращается вокруг СУБД не возникает потребности чего то типа View из классики?

Конечно же да! И наиболее полно эти желания и стремления фирмой 1С реализованы в её классическом продукте Зарплата и Управление Персоналом (сокращённо - ЗУП).

По аналогии с английским термином "View" этот механизм назван "Представления", но реализация совсем иная.

Имхо нижеследующее может быть весьма полезно всех архитекторам приложений с БД. Потому что такой приём я видел только в 1С: ЗУП и хотя наверняка он переизобретался много раз и много где существует, но не все об этом знают.

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

VIEW из оригинального SQL были решением части такой проблемы.
Но в 1С: ЗУП программисты изобрели нечто что я бы назвал "расширением концепции VIEW". И это тут называется "представления".

Суть можно описать так - мы задаёмся тем, что у нас есть некие "абстрактные источники данных" - например есть в программе и очень всё вокруг них вращается "сотрудники". И с сотрудниками появляется абстрактный источник данных "информация о сотруднике на момент времени X".
Например - это его дата рождения (неизменяемая информация) или его ФИО (потенциально изменяемая информация - фамилия женщины традиционно может измениться после свадьбы) или статус инвалидности (до 2020 года сотрудник мог быть не инвалидом, а после стал), ученая степень, число детей, бла-бла-бла. Я думаю вы уже понимаете, что тут может быть дохрена самых разных таблиц которые где то статично, где то исторично отражают информацию.
А нам нужен только финальный итог на дату X - что там у сотрудника в его данных на дату X?

И вот тут 1С придумали представления - это когда ты в запрос вводишь особо обозначенную ВРЕМЕННУЮ таблицу где прописываешь сотрудников, даты среза и поля которые хочешь получить - вот эти вот такие типа сколько у него детей или какая у него ученая степень - обозначаешь что именно.
А далее пропускаешь текст запроса через программно написанную 1С-никами функцию из модуля ОбщиеИсточникиДанных - ЗаменитьПредставленияВЗапросе.
И эта функция - это плагино-ориентированная феерия - она начинает искать в запросе то что выглядит как запрос к представлениям - далее по принципу плагинов начинает обращаться к источникам данных для конкретных представлений (данные о сотрудниках это одно представление, а данные об организациях это другое представление и т.п.) и самое главное - анализируя те колонки что мы хотим извлечь динамически конструирует реальный запрос к БД который опрашивает только нужные таблицы. Только те таблицы которые нужны для извлечения данных в запрошенные колонки.
И вуаля - всё готово и если таблицы стоящие за данными в представлении поменялись, то нужно только поправить модули генерирующие представления (а это по типу плагинов устроено).

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

ВЫБРАТЬ
  ДАТАВРЕМЯ(1, 1, 1) КАК Период,
  ЗНАЧЕНИЕ(Справочник.Сотрудники.ПустаяСсылка) КАК Сотрудник,
  "" КАК ТелефонДомашнийПредставление,
  ЗНАЧЕНИЕ(Справочник.ГрафикиРаботыСотрудников.ПустаяСсылка) КАК ГрафикРаботы
ПОМЕСТИТЬ Представления_КадровыеДанныеСотрудников
ИЗ
  ВТСотрудникиПериоды КАК СотрудникиПериоды

, то когда мы пропустим текст запроса через ОбщиеИсточникиДанных.ЗаменитьПредставленияВЗапросе(ТекстЗапроса), то везде в тексте где встречается конструкция "ПОМЕСТИТЬ Представления_" будут произведены преобразования и дополнения чтобы в результате временная таблица с таким именем оказалась насыщена запрашиваемым в колонках данными - и только ими!

Это великолепно!
Ничего лишнего - исключительно что запросил, то и будет включено в запрос и только так как ты запросил.
Если все возможные для сотрудника поддерживаемые в данный момент в ЗУП колонки запросить, то получится запрос с текстом на 100500 строк - так много самых разнообразных таблиц хранит данные относящиеся к сотруднику.
Но всё это сделано в плагинном стиле, поэтому реальные запросы обращаются только к порядка 20 таблиц в среднем.