Научное сообщество совсем не из-за этого негодует. И в целом оно не против ИИ. Да и лин не 10к агентов делали, и разобрать это не проблема. Это больше похоже на кражу
Покажи реально решённую именно ИИ задачу по математике, а не ту, где он знал решение после обучения. Таких нет, вообще. И самое громкое что было - последний случай, где обученный новому методу ИИ смог перебором подобрать нужный вариант.
И этот случай с Навье Стоксом первый. И, чсх, при этом всё первенство в том, что они воспользовались новым методом, о котором ещё никто не знал. Т.е. опять таки не было сделано ничего нового. Что по прочим? Выявил более высокую точность? Ну да. Как? Перебором. Т.е. никакой новой мысли из этого не было вынесено. И так по каждой. Предсказания в научных работах у них как были около 0, так и остались. Потому как ИИ на данный момент не способен оценить ни значимость работы, ни её перспективность успешной реализации.
Стагнации? Нет. Но концептуальный порог ИИ не перешагнул. И пока что никаких предпосылок к этому нет, он остаётся всё так же сложным фильтром, который обрабатывает инфу очень быстро, но не думает, а только рефлексирует
По научным задачам ИИ показывает около 0 эффективность. Т.е. сам ничего выявить, предсказать, создать - не может. Но очень высокую эффективность в перелопачивании данных, как помощник, по уже известным лекалам. ИИ учат делать что-то и после этого он делает на много быстрее человека, но ровно так как научили. А новое он не может делать. Это уже измеряли. Только толку нет измерять значения около 0 на уровне погрешности. Да и сам процесс такого измерения сложен.
PS: это прямой ответ почему сингулярность в текущем виде невозможна
Прям манифест луддитов) По каждому пункту есть что сказать. Особенно о современном, например, самосборный вебкит примерно 18 года... И особенно не ноют заказчики, коим надо платить за очередной обнову на новую версию. И ведь не так уж и сложно перевести на что-то современное хотя бы тот же конфигуратор. Коим в компаниях пользуются в основном чтобы ctrl-v нажать. Ну хоть чтоб упростить жизнь тем же внедренцам
Это та вещь, которая в целом то не должна делаться ручками бухгалтера. Автоматизация в этом не совсем уж сложная задача. Сложность в разы больше при разноске документов
Про маркировку и относительное - не понятно к чему ты. Это никак не влияет на мною сказанное, если учёт единиц, то проблемы нет.
сейчас активно впихивают
Ключевое - сейчас.
В целом разговор зашёл в тупик. Ты говоришь одно и то же, просто не понимаешь как такое может быть. Я же вижу одни и те же аргументы, ничего нового
Так и зачем оно надо? Если у тебя есть информация по движению каждой единицы товара, то это и не нужно. Себестоимость в этом случае рассчитывается именно из первичных данных, указание по расчёту в алгоритме. А промежуточные документы в этом случае не нужны.
Не путаю. Бухгалтерия - именно аналитика в разрезе хозяйственной деятельности предприятия в изначальном смысле. Включает в себя фин учёт, и многое другое. Но именно для ведения этой хоз.деятельности, а не для налоговой. А по факту большая часть 1С - налоги. Да, если брать ERP - там много иного. Но не отменяет направленности - для ведения бизнеса нужны доработки, все документы для удобства налоговой. А задачи бизнеса и учёта для государства не сходятся
Мы получаем все данные. И отслеживаем их в ~ реалтайме. Т.е. ввести аналитики можно в любой момент по потребности. А отслеживать реальное положение. И узнать что тебе нужно так же. Но данные должны быть полными и актуально связанными. Вся необходимая информация есть в БД и алгоритме. Вдаваться в подробности сильно не буду. Но ты сам наверняка сможешь составить алгоритм по 1 вещи движущейся как 1 купи-продай товар в WB/озоне, если подумаешь.
И тут весь вопрос, а зачем тебе промежуточные документы? Например, ты хочешь посчитать ЗП по сменам в подразделении, где каждый работает по некоторой ставке и разное кол-во часов, надбавок и прочих свистоперделок. Обычно это как-то делят, например, считают промежуточный итог за месяц по подразделению, потом уже сводят и тп. Но это всё не нужно, если ты можешь сразу считать конечный результат по любым метрикам.
" Бизнесу совершенно не нужна какая-то аналитика, которая требует дополнительных денежных средств" Аналитика = бухгалтерия в изначальном смысле. Это сейчас бухгалтерия в РФ во многом превратилась в первую очередь в инструмент для налоговой. А, ну и бизнесу очень даже нужна "какая-то аналитика", даже за очень большие деньги. Далеко не всем, конечно)
" покажите, что не будет различаться налог на прибыль... " Возврат к изначальному - ты указываешь для доказательства сделать то, что я как раз и говорю делать не надо. Бухгалтерия для налогов в РФ, а не для бизнеса. И эта система поддерживает сама себя, требуя то, что не нужно. Это скорее бюрократия, чем бухгалтерия. Но речь как раз о том, что она излишня. Вполне можно считать иначе, более верно, точно, что в конечном итоге лучше для экономики как в целом, так и для всех групп участников
PS: В РФ, вроде как, тоже можно учёт по единицам делать, а не по среднему или FIFO. Что забавно, в как бы жёсткой США LIFO разрешён
Так в чём проблема? Это вычисляемые и кешируемые данные по первичным документам. Т.е. можно посчитать за любой прошедший период напрямую, с хранимой точностью(например, секундной)
Так только из-за ОНА/ОНО ...
Так в том и дело, что по сути одно и то же кучей разных способов, когда можно взять сырые данные и из них получать точно те, которые нужны. Не используя практики многовековой давности, которые делали то же самое, потому что у них не было ДВС компьютера
Так Вы углубитесь в аргументацию ...
Если уйти от налоговых и прочих требований, то смысл этого в аналитике. В таком случае лучше всего реалтайм-система, т.к. точно даёт возможность отследить все изменения, в т.ч. привязывать к показателям управления. Тут вариантов нет - точные данные не зависят от скачков цен, инфляции и прочих факторов, которые влияют в прочих методах. Можно отслеживать и отдельные товары в партиях, и партии FIFO/LIFO плох либо налоговой, либо компании. Дают самое большое отклонение в аналитике. Невозможно точно определять эффективность при сильных изменениях Средневзвешенное лучше в общей аналитике, меньше отклонение. Сложнее отслеживать партии. Для потоковой продажи(не знаю, металл, гвозди и прочее такое) минусы вроде не существенны. Стандартная это выдумать и по ней считать? Вообще не вижу смысла, кроме как до старта прикинуть стоит ли вообще заниматься этим.
Можно так же совмещать, например, при покупках партиями по 1 принципу, а продажу в розницу весом по средневзвешенной по 1 партии
Ну так это всё данные в БД, которые вычислимы полностью день в день. Там может быть всё, включая даже амортизацию за этот день. И всё это можно делать с первичных документов. В процессе, правда, придётся использовать вычисляемые поля для оптимизации вычислений при больших объёмах.
" Нужно привязать к каждой строке инвойса все закупки и логистические расходы по каждой партии или иногда единице товара транзакционно " Внутренние операции не нужны. Это вычисляемо так же из первичных. Но можно сделать кеш данных В целом же, о том и речь. Сейчас это всё вычисляемо, не очень тяжёло даже. В маркетплейсах, кмк, так и делают. И во всём крупном ритейле внутренняя так.
А вот когда идут внешние действия - уже другое. Налоговая сейчас фактически говорит как делать, в т.ч. мешает изменить бухгалтерию в более современный вид. И вот компании для бухпроводок, налоговой, делают на 1С, ну и на торговых единицах для отчётов у них так. Сейчас ещё вспоминаю, что у крупных компаний порой 2-5 бухгалтерий ведутся... 1 из них - отчётность. Другая - внутренняя бухгалтерия для себя, ещё одна - для иностранного аудита была. Ну и чёрная и для головной организации.
До VSCode им далеко... Это ближе к нотпаду с плагинами. Постарее версии вообще не отличались от нотпада с плагинами. А старые и не дотягивали до нотпада без плагинов. А вот 1С:EDT примерно как VSCode, т.к. он на базе Eclipse
Ну вот для каждой единицы товара может быть своя цена себестоимости. Как с привязкой к отдельному товару, так и без неё. Самый прямой пример - закупили товар за N, + вычисляемые факторы, как скадские расходы хранения на единицу в период + погрузка/разгрузка + продажа. Вычисляемые можно делать в моменте, например за каждый день, считая даже заменяющих сотрудников выходящих в этот день работать за отдельный прайс.
Дальше можно просто эту себестоимость умножать в любом виде, хоть FIFO, хоть для LIFO, хоть среднюю(так и в БД проще хранить даже), хоть сначала дорогие или сначала дешёвые. А можно вообще по конкретному проданному товару, что для реально полезной отчётности решает кучу проблем. Причём, считать именно по FIFO/LIFO, наоборот, крайне малополезно с практической точки зрения(не буду углубляться почему).
В этом плане я действительно понимаю @digrobot И таких устаревших норм полно. Если и дальше рассуждать, выгрузку некоторых обобщённых данных с копией БД куда проще сделать, чем тьму отчётов. Т.е. в плане трудозатрат программистов это на много дешевле и проще. Примерно такая же ситуация с заполнением данных и вычислениями в целом - на много дешевле заполнять фактами из реальной жизни напрямую.
При том, что в БД и транзакционно-событийной модели можно найти всё, и посчитать всё за любой период, причём простым способом. А данные всегда идут чуть ли не в реальном времени.
PS: вспомнил отдельную радость - упоротое банковское округление. А всё для того, чтобы сошлось +- одинаково, но никогда не точно! Хотя компьютеру вот вообще всё равно, он одинаково быстро считает и астрономические числа
Я видел такое и несколько пунктов это может убрать сразу, а часть агентами проверки и повторной генерации, но остальные останутся. Кроме того, есть ещё несколько пунктов, которые тут не указаны вообще. И цена таких дополнительных проверок-правок какая? Я не раз уже видел как цена разработки при проверке и доработке агентами с другими агентами за агентами растёт на столько быстро, что выходит дороже сеньора(5к+)
Останутся такие пункты:
отсутствие проверок граничных условий и edge cases;
избыточная сложность — ИИ часто генерирует «универсальное» решение там, где нужно простое;
отсутствие или формальные тесты, которые не покрывают реальные сценарии;
Так же могу сказать, что есть и другие проблемы ИИ, в которых стабильный результат вообще выходит, и его не оценить простым способом или проверкой агентом: 1) Добавление и изменение существующей логики часто приводит к дублированию, а то и цикличным правкам. Чем больше условий, тем больше шанс. 2) Архитектуру не делают нормально, если не указать конкретно. Проблемное место становится нагромождением дублирующейся логики, переходов, вызовов функций. 3) Логика в целом строится по верхнему уровню. Быстроисполнимый и маложрущий код не выходит вообще - сейчас это слишком сложная задача для ИИ. В простых тестах ещё может найти готовое решение, но даже поменять его - нет. С цепочкой агентов цена улетает в космос, а результат при высокой сложности так же плох. 4) Математика и формулы при изменениях, отхода от стандарта - очень плохо. Валидировать значения так же не выходит, т.к. ИИ не редко ошибается одинаково
Если увеличивать критичность агентов проверки в этих случаях, то растёт ложноположительное срабатывание. Поэтому снова выходит дешевле сеньор, чем агенты. Даже не считая того, что с ИИ тут и так работает сеньор
В некотором роде, джуна можно воспринимать как крутой ИИ. Да в целом так любого разраба можно воспринимать. Им дают задачу - они её делают. Сеньоры/лиды могут и уточнить что-то, многое уже знают из контекста, могут передать задачу мидлам, мидлы могут соотнести с проектмо и наваять. Где задачи попроще, те можно передать джунам, они их поделят на меньшие, запросят у ИИ и адаптируют к проекту Только ИИ-джун обучается долговременно и более сложным концепция, а ИИ нет - он как работал изначально, так и работает. Промт для ИИ, что процессы для ИИ-джуна)
Научное сообщество совсем не из-за этого негодует. И в целом оно не против ИИ. Да и лин не 10к агентов делали, и разобрать это не проблема. Это больше похоже на кражу
Покажи реально решённую именно ИИ задачу по математике, а не ту, где он знал решение после обучения. Таких нет, вообще. И самое громкое что было - последний случай, где обученный новому методу ИИ смог перебором подобрать нужный вариант.
И этот случай с Навье Стоксом первый. И, чсх, при этом всё первенство в том, что они воспользовались новым методом, о котором ещё никто не знал. Т.е. опять таки не было сделано ничего нового.
Что по прочим? Выявил более высокую точность? Ну да. Как? Перебором. Т.е. никакой новой мысли из этого не было вынесено. И так по каждой. Предсказания в научных работах у них как были около 0, так и остались. Потому как ИИ на данный момент не способен оценить ни значимость работы, ни её перспективность успешной реализации.
Стагнации? Нет. Но концептуальный порог ИИ не перешагнул. И пока что никаких предпосылок к этому нет, он остаётся всё так же сложным фильтром, который обрабатывает инфу очень быстро, но не думает, а только рефлексирует
По научным задачам ИИ показывает около 0 эффективность. Т.е. сам ничего выявить, предсказать, создать - не может. Но очень высокую эффективность в перелопачивании данных, как помощник, по уже известным лекалам. ИИ учат делать что-то и после этого он делает на много быстрее человека, но ровно так как научили. А новое он не может делать.
Это уже измеряли. Только толку нет измерять значения около 0 на уровне погрешности. Да и сам процесс такого измерения сложен.
PS: это прямой ответ почему сингулярность в текущем виде невозможна
Вот весь этот список в конце и есть качество кода. Которое зависит от того, как написан код
Прям манифест луддитов) По каждому пункту есть что сказать. Особенно о современном, например, самосборный вебкит примерно 18 года... И особенно не ноют заказчики, коим надо платить за очередной обнову на новую версию. И ведь не так уж и сложно перевести на что-то современное хотя бы тот же конфигуратор. Коим в компаниях пользуются в основном чтобы ctrl-v нажать. Ну хоть чтоб упростить жизнь тем же внедренцам
Так уже есть такие боты
Это та вещь, которая в целом то не должна делаться ручками бухгалтера. Автоматизация в этом не совсем уж сложная задача. Сложность в разы больше при разноске документов
Про маркировку и относительное - не понятно к чему ты. Это никак не влияет на мною сказанное, если учёт единиц, то проблемы нет.
Ключевое - сейчас.
В целом разговор зашёл в тупик. Ты говоришь одно и то же, просто не понимаешь как такое может быть. Я же вижу одни и те же аргументы, ничего нового
Так и зачем оно надо? Если у тебя есть информация по движению каждой единицы товара, то это и не нужно. Себестоимость в этом случае рассчитывается именно из первичных данных, указание по расчёту в алгоритме. А промежуточные документы в этом случае не нужны.
Не путаю. Бухгалтерия - именно аналитика в разрезе хозяйственной деятельности предприятия в изначальном смысле. Включает в себя фин учёт, и многое другое. Но именно для ведения этой хоз.деятельности, а не для налоговой. А по факту большая часть 1С - налоги. Да, если брать ERP - там много иного. Но не отменяет направленности - для ведения бизнеса нужны доработки, все документы для удобства налоговой. А задачи бизнеса и учёта для государства не сходятся
Мы получаем все данные. И отслеживаем их в ~ реалтайме. Т.е. ввести аналитики можно в любой момент по потребности. А отслеживать реальное положение. И узнать что тебе нужно так же. Но данные должны быть полными и актуально связанными. Вся необходимая информация есть в БД и алгоритме. Вдаваться в подробности сильно не буду. Но ты сам наверняка сможешь составить алгоритм по 1 вещи движущейся как 1 купи-продай товар в WB/озоне, если подумаешь.
И тут весь вопрос, а зачем тебе промежуточные документы? Например, ты хочешь посчитать ЗП по сменам в подразделении, где каждый работает по некоторой ставке и разное кол-во часов, надбавок и прочих свистоперделок. Обычно это как-то делят, например, считают промежуточный итог за месяц по подразделению, потом уже сводят и тп. Но это всё не нужно, если ты можешь сразу считать конечный результат по любым метрикам.
" Бизнесу совершенно не нужна какая-то аналитика, которая требует дополнительных денежных средств"
Аналитика = бухгалтерия в изначальном смысле. Это сейчас бухгалтерия в РФ во многом превратилась в первую очередь в инструмент для налоговой.
А, ну и бизнесу очень даже нужна "какая-то аналитика", даже за очень большие деньги. Далеко не всем, конечно)
" покажите, что не будет различаться налог на прибыль... "
Возврат к изначальному - ты указываешь для доказательства сделать то, что я как раз и говорю делать не надо. Бухгалтерия для налогов в РФ, а не для бизнеса. И эта система поддерживает сама себя, требуя то, что не нужно. Это скорее бюрократия, чем бухгалтерия. Но речь как раз о том, что она излишня. Вполне можно считать иначе, более верно, точно, что в конечном итоге лучше для экономики как в целом, так и для всех групп участников
PS: В РФ, вроде как, тоже можно учёт по единицам делать, а не по среднему или FIFO. Что забавно, в как бы жёсткой США LIFO разрешён
Так в чём проблема? Это вычисляемые и кешируемые данные по первичным документам. Т.е. можно посчитать за любой прошедший период напрямую, с хранимой точностью(например, секундной)
Так в том и дело, что по сути одно и то же кучей разных способов, когда можно взять сырые данные и из них получать точно те, которые нужны. Не используя практики многовековой давности, которые делали то же самое, потому что у них не было
ДВСкомпьютераЕсли уйти от налоговых и прочих требований, то смысл этого в аналитике. В таком случае лучше всего реалтайм-система, т.к. точно даёт возможность отследить все изменения, в т.ч. привязывать к показателям управления. Тут вариантов нет - точные данные не зависят от скачков цен, инфляции и прочих факторов, которые влияют в прочих методах. Можно отслеживать и отдельные товары в партиях, и партии
FIFO/LIFO плох либо налоговой, либо компании. Дают самое большое отклонение в аналитике. Невозможно точно определять эффективность при сильных изменениях
Средневзвешенное лучше в общей аналитике, меньше отклонение. Сложнее отслеживать партии. Для потоковой продажи(не знаю, металл, гвозди и прочее такое) минусы вроде не существенны.
Стандартная это выдумать и по ней считать? Вообще не вижу смысла, кроме как до старта прикинуть стоит ли вообще заниматься этим.
Можно так же совмещать, например, при покупках партиями по 1 принципу, а продажу в розницу весом по средневзвешенной по 1 партии
А заставить это что по твоему? Ткнуть дуло в спину и отправить работать или быть убитым - тоже выбор. Но это именно что и есть заставить
Ну так это всё данные в БД, которые вычислимы полностью день в день. Там может быть всё, включая даже амортизацию за этот день. И всё это можно делать с первичных документов. В процессе, правда, придётся использовать вычисляемые поля для оптимизации вычислений при больших объёмах.
" Нужно привязать к каждой строке инвойса все закупки и логистические расходы по каждой партии или иногда единице товара транзакционно "
Внутренние операции не нужны. Это вычисляемо так же из первичных. Но можно сделать кеш данных
В целом же, о том и речь. Сейчас это всё вычисляемо, не очень тяжёло даже. В маркетплейсах, кмк, так и делают. И во всём крупном ритейле внутренняя так.
А вот когда идут внешние действия - уже другое. Налоговая сейчас фактически говорит как делать, в т.ч. мешает изменить бухгалтерию в более современный вид. И вот компании для бухпроводок, налоговой, делают на 1С, ну и на торговых единицах для отчётов у них так. Сейчас ещё вспоминаю, что у крупных компаний порой 2-5 бухгалтерий ведутся... 1 из них - отчётность. Другая - внутренняя бухгалтерия для себя, ещё одна - для иностранного аудита была. Ну и чёрная и для головной организации.
Надеюсь тут половина сарказм) Минимум
Вся система для " Но извращений никто не отменял". Движение прогресса с 1C возможно только таким образом, это да
До VSCode им далеко... Это ближе к нотпаду с плагинами. Постарее версии вообще не отличались от нотпада с плагинами. А старые и не дотягивали до нотпада без плагинов.
А вот 1С:EDT примерно как VSCode, т.к. он на базе Eclipse
Ну вот для каждой единицы товара может быть своя цена себестоимости. Как с привязкой к отдельному товару, так и без неё. Самый прямой пример - закупили товар за N, + вычисляемые факторы, как скадские расходы хранения на единицу в период + погрузка/разгрузка + продажа. Вычисляемые можно делать в моменте, например за каждый день, считая даже заменяющих сотрудников выходящих в этот день работать за отдельный прайс.
Дальше можно просто эту себестоимость умножать в любом виде, хоть FIFO, хоть для LIFO, хоть среднюю(так и в БД проще хранить даже), хоть сначала дорогие или сначала дешёвые. А можно вообще по конкретному проданному товару, что для реально полезной отчётности решает кучу проблем.
Причём, считать именно по FIFO/LIFO, наоборот, крайне малополезно с практической точки зрения(не буду углубляться почему).
В этом плане я действительно понимаю @digrobot
И таких устаревших норм полно.
Если и дальше рассуждать, выгрузку некоторых обобщённых данных с копией БД куда проще сделать, чем тьму отчётов. Т.е. в плане трудозатрат программистов это на много дешевле и проще. Примерно такая же ситуация с заполнением данных и вычислениями в целом - на много дешевле заполнять фактами из реальной жизни напрямую.
При том, что в БД и транзакционно-событийной модели можно найти всё, и посчитать всё за любой период, причём простым способом. А данные всегда идут чуть ли не в реальном времени.
PS: вспомнил отдельную радость - упоротое банковское округление. А всё для того, чтобы сошлось +- одинаково, но никогда не точно! Хотя компьютеру вот вообще всё равно, он одинаково быстро считает и астрономические числа
Это ссылка с хешем. Он генерится каждый N времени заново. И это как раз нормальное явление
Кто бы пояснил почему там всё равно дороже, чем в стиме. И не только в РФ регионе
Закон сохранения сложности напрмую вытекает из Колмогоровской. Эмпирическое я опустил, т.к. оно вполне может быть и математически обоснованным
Я видел такое и несколько пунктов это может убрать сразу, а часть агентами проверки и повторной генерации, но остальные останутся. Кроме того, есть ещё несколько пунктов, которые тут не указаны вообще. И цена таких дополнительных проверок-правок какая? Я не раз уже видел как цена разработки при проверке и доработке агентами с другими агентами за агентами растёт на столько быстро, что выходит дороже сеньора(5к+)
Останутся такие пункты:
отсутствие проверок граничных условий и edge cases;
избыточная сложность — ИИ часто генерирует «универсальное» решение там, где нужно простое;
отсутствие или формальные тесты, которые не покрывают реальные сценарии;
Так же могу сказать, что есть и другие проблемы ИИ, в которых стабильный результат вообще выходит, и его не оценить простым способом или проверкой агентом:
1) Добавление и изменение существующей логики часто приводит к дублированию, а то и цикличным правкам. Чем больше условий, тем больше шанс.
2) Архитектуру не делают нормально, если не указать конкретно. Проблемное место становится нагромождением дублирующейся логики, переходов, вызовов функций.
3) Логика в целом строится по верхнему уровню. Быстроисполнимый и маложрущий код не выходит вообще - сейчас это слишком сложная задача для ИИ. В простых тестах ещё может найти готовое решение, но даже поменять его - нет. С цепочкой агентов цена улетает в космос, а результат при высокой сложности так же плох.
4) Математика и формулы при изменениях, отхода от стандарта - очень плохо. Валидировать значения так же не выходит, т.к. ИИ не редко ошибается одинаково
Если увеличивать критичность агентов проверки в этих случаях, то растёт ложноположительное срабатывание. Поэтому снова выходит дешевле сеньор, чем агенты. Даже не считая того, что с ИИ тут и так работает сеньор
В некотором роде, джуна можно воспринимать как крутой ИИ. Да в целом так любого разраба можно воспринимать.
Им дают задачу - они её делают. Сеньоры/лиды могут и уточнить что-то, многое уже знают из контекста, могут передать задачу мидлам, мидлы могут соотнести с проектмо и наваять. Где задачи попроще, те можно передать джунам, они их поделят на меньшие, запросят у ИИ и адаптируют к проекту
Только ИИ-джун обучается долговременно и более сложным концепция, а ИИ нет - он как работал изначально, так и работает. Промт для ИИ, что процессы для ИИ-джуна)