Pull to refresh

Comments 12

Только не стоит забывать, что регистры накоплений - это очень частный случай наследования. В случае, если агрегирующая функция будет не простая сумма/максимум/минимум, а более сложная, то эти регистры уже не подойдут. В более сложных случаях в 1С все равно придется все делать ручками.
Да, есть еще регистры сведений (где, по сути, реализовано получение последнего значения на дату), но это тоже еще один частный случай.

Регистры сведений - это отдельная, большая и интересная тема

Регистры накопления как минимум двух видов бывают: регистры остатков и регистры оборотов. Во втором случае остатков нет.

Да, верно. Не стал вдаваться в технические детали. Подумал, что описание концепции и техническое описание все-таки разные вещи

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

Задолго до того, как словосочетания low code и zero code стали популярными, платформа 1С: Предприятие уже предлагала нечто подобное и стала популярной, в том числе, и поэтому.


И эта концепция провалилась. Я припоминаю такие мнения во времена 7.7 — «каждый бухгалтер сможет написать себе автоматизацию». Так вот, бухгалтер не смог, а у программистов при этом пришлось отобрать массу производительных решений в угоду упрощения (например, одной из первых идей было то, что выбирать данные мы будем только через ORM, а он в 1с еще и не умеет в связи. дальше это развивалось в язык запросов 7.7 и только в самом конце с внешней компонентов 1cpp все пришло к нормальной производительности). Имхо, это и вызвало смерть платформы, т.к. она не могла обработать увеличение нагрузки.
Платформа 8 выбросила этот принцип про бухгалтеров и уже была заточена на программистов.

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

Генеративные модели не из воздуха берут контент. Это усредненный уровень всего, что написано по теме в интернете. Этакий средний программист. Добавим плюсом к этому устаревание информации (вполне может оказаться, что кода для старых версий платформ/бсп больше, чем для новых, а обратная совместимость соблюдается совсем не всегда).
Так что результат этих моделей будет ниже среднего. Они смогут конкуренцию только джунам составить.

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

Из моего опыта пользователь чаще всего хочет вспомогательный инструмент для какого-то своего процесса и это очень далеко от «просто получить остаток товара на складе». Обычно это объединяет данные из нескольких разных участков учета, причем довольно не однотипным образом (как пример: кто-то частичную оплату хочет считать как признак «оплачено», кто-то нет, кому-то частичность подавай как отдельный признак).
Я пока что не видел от нейросетей ничего сложного. Что в copilote ими генерят довольно простые куски классов/кода; что у вас в публикации на инфостарте о гпт3 — запросы простейшие.

Можно ли теоретически выпросить у нейросети целый инструмент, но по простейшим кусочкам? Теоретически да, если каждую каждую ячейку отчета считать независимой — и под нее спрашивать нейросеть. Но в итоге вы получите сотни запросов в цикле. Это и будет уровень джуна с частым использованием O(n^2) ради упрощения. Такие системы, к сожалению, крайне быстро проходят предел количества данных.

Поживём, увидим. Лично я сейчас вижу запрос на простоту. А точнее на то, чтобы простое оставалось простым, а не превращалось в сложное на пустом месте.

Не понятно зачем статья и для кого? Чтобы просто сказать вот такая штука существует и написать об этом 10% от имеющейся информации? Как будто написано чтобы вставить последний рекламный абзац

Sign up to leave a comment.