Комментарии 133
Гуд бай, 1С?
Осталось совсем чуть-чуть: прикрутить расчет налогов по разным СНО, расчет ЗП, интеграцию с банк-клиентами, формирование документов по различным формам ... и обучить тысячу бухгалтеров
Обучить бухгалтеров чему? Русскому языку?
А Вы когда-нибудь пробовали у бухгалтеров какие-нибудь нововведения внедрить? Это люди со специфическим мышлением (большинство из них). Они как трамваи, хорошо едут там, где проложен путь.
Бухгалтер это тупой бот работающий на налоговую за счет предпринимателя.
Когда это осознаешь, нервных срывов резко уменьшается.
Бухгалтер это тупой бот работающий на налоговую за счет предпринимателя.
В шею гнать таких бухгалтеров.
И кто тогда будет работать? У них функция такая, их так учат, такой работы от них требуют, как нибудь иначе они не могут.
Вы просто, видимо, работали с аутсорсерами-недоучками, а не с настоящими бухгалтерами, задача которых - пройти меж струйками по серой зоне законодательства, выкружив максимум экономии на налогах при минимуме рисков для организации.
это обычно или экономисты, или бухгалтер-аудитор. Пытался взять бухгалтера на ввод первички (копипаст).
"Сколько лет вы работали бухгалтером?"
"20 лет сидела на 51 счёте"
"Можете работать с первичными документами?"
"Если научите, то за 60 000 р. в месяц я смогу, наверное это делать, а отчёты сдавать - не могу, это ответственность, мне она не нужна"
В итоге бот в объёме 300 строк, висящий на VPS за 200 р. в месяц делает то, что делал бы бухгалтер + ещё по пути "сидит на 51 счёте".
А толпы вот таких бухгалтеров, раздувающих щёки, с "опытом в 20 лет" продолжают сидеть и искать работу. Учиться они не хотят.
Обычно, такие профи сидят в оутсорсинговых компаниях, которые берут на обслуживание всю бухгалтерию + предоставляют юридические услуги + кадровый учёт (бумаги, а не работу с людьми).
Специализация, одним словом, и комплексное обслуживание.
Столкнулся. Был удивлен такой проработанности схем.
Сейчас, как, не знаю, но уверен, что стало ещё серьёзней.
Это Вы не понимаете суть работы бухгалтерии, от слова совсем.
Если формулировать эту работу IT-шными терминами, то бухгалтерия - это документарная модель всего предприятия. Каждый объект, каждая хозяйственная операция имеет своё отражение в соответствующих документах.
Зачем такая модель нужна? В основном для трёх целей:
Налоговый учёт: по документам рассчитывается, какие налоги должно оплатить предприятие. Оптимизация налогов, если бухгалтер такое умеет - это полезно, но это бонус. А вот рассчитать всё правильно и по закону, чтоб потом не прилетело нежданчиков - это основная задача бухгалтера.
Управленческий учёт: по доеументарной модели можно построить любые отчёты для директора или собственника. Тут работа бухгалтерии пересекается с работой финансового управления (это разные подразделения), но смысл у них общий: управляющий должен понимать - сколько у него сейчас чего есть, сколько он должен, сколько должны ему и когда, видеть все финансовые потоки.
Бухгалтерский учёт: бывает нужен по закону для некоторых компаний, а также может потребоваться для аудиторов или, скажем, банка для выдачи кредита.
Вот у хорошего бухгалтера всё перечисленное всегда схвачено, любой факт подтверждён документами, которые можно показать. Так что нет, не на налоговую он работает - это всё очень даже в интересах предпринимателя, просто не все предприниматели это понимают.
Да, это так. В идеальном мире, идеальном предприятии. Но так уж получилось, что правила устанавливает государство. 1 и 3 пункты как раз про это.
И только 2-ой пункт, "управленческий учёт", полезен бизнесу. В мелком бизнесе делается одним и тем же бухгалтером. Но более опытные предприниматели вам расскажет, что ничего не понимает о бизнесе, что печется только о бумажках, т.к. за формальные ошибки им может прилететь от налоговой (из за этого они всегда нервные).
В нормальном бизнесе, управленческий учёт доверяют финансистам. Потому что 1, 3 пункты идут в разрез с 2, одно другому мешает.
Я не раз видел перепалки бухгалтера с босом из за разного понимания что нужно бизнесу. Весь коллектив боится заходить в бухгалтерию, особенно если надо туда занести какую то бумажку.
Бизнесу такое вредит. Это можно купировать, но не исправить, так как функции бухгалтера навязаны государством.
Ну это можно и на IT экстраполировать же.
Видел я такую бухгалтерию, видел и айтишников, которые со всеми разговаривали через губу и делали вид, что они самые умные и всё предприятие существует исключительно для них. И да, к таким айтишникам тоже не хотели подходить. И перепалки тоже видел, когда айтишники требовали купить новые сервера, а боссы не понимали, зачем эти траты.
Такое поведение не делает чести ни боссам, ни айтишникам, ни бухгалтерам. В первую очередь - потому что чаще всего свидетельствует о непрофессионализме (да, непрофессиональные предприниматели тоже бывают и многие из тех боссов, что раздували щёки и спорили с бухгалтерией, в итоге закрыли свои бизнесы в глубоком минусе). И требовать, чтобы бухгалтер подогнал отчётность под цифры, которые хочет предприниматель - это такой же бред, как требовать от айтишника, чтобы он взломал сайт конкурентов. Естественно, ни один уважающий себя айтишник или бухгалтер с таким боссом работать не будет - не в этом ли секрет "бухгалтерии, в которую все боялись зайти"?
Нормальный IT-специалист, как и нормальный бухгалтер, в первую очередь защищает интересы компании и предпринимателя (иногда - от него самого, если тот делает откровенный бред). Как врач не станет выписывать пациенту лекарства на основании того, что "я лучше знаю, что мне пить", так и хороший бухгалтер или IT-специалист в первую очередь заинтересованы профессионально выполнять свою работу, и для компании это обычно полезно (но часто собственник этого не видит). И если собственник не прислушивается к мнению своих специалистов - чаще всего кончается это не очень хорошо: в сервере накрываются диски, а бэкапов нет, потому что собственник не выделил денег; а налоговая доначисляет нцать миллионов и тащит предпринимателя на допрос и в суд, где тот имеет бледный вид.
Да, бухгалтера тоже люди. Они желают компании процветания. Они нервные не из за характера, как у условного заносчивого программиста, а из за требований закона. Особенно в конце отчетного периода, дедлайна, которого не возможно сместить, как это получается у программистов. Совместит нужды бизнеса и требования налоговой, это очень нервный квест.
Любой управленческий учёт базируется на бухгалтерском факте. Вы конечно можете например вести какое-то сальдо по счету без аналитической разбивки, но в конечном итоге у вас даже с управленческой разметкой данных итог должен замэпится на сальдо.
Бухгалтерия появилась не от государства, и нужна она не только ему, а в стейкхолдерам.
Как раз обычно бухгалтерский и налоговый учёт выделают в отдельные блоки
Я верю в автора, завтра он прикрутит команды "Сдай отчетность", "Оптимизируй НДС", "Пройди выездную налоговую проверку" и пр. и бухгалтеры станут не нужны.
Спасибо за доверие! )))
"Я конечно дико извиняюсь" (C), а "сидеть кто будет" (C)?
Пока человеческое общество не выработало подходов к наказанию комп. систем (читай "ИИ")...
А причем здесь "сидеть"? Вот, скажем, ведет человек складской учет с помощью ручки и бумажки. Никто ведь не ставит вопрос: можно ли посадить ручку и бумажку. Или ведет учет с помощью Excel. И опять никто не ставит вопрос: можно ли посадить Excel. А как появляется AI, так сразу вопрос: можно ли его посадить. Вот откуда это?
Предположу, что имеется в виду, что чем менее детерминированны алгоритмы обработки информации, тем меньше людей писанётся на должность, которая отвечает за отчетность перед государством (обычно это гендир и главбух). Если ведем отчетность в условном экселе, то бухгалтер при желании может разобраться, откуда какая цифра взялась. А если у нас итоговые цифры выдаёт какая-то шайтан-машина с "ахалай-махалай" под капотом, и поди пойми как оно там работает, то сразу выясняется, что отвечать за её результат собственной шкурой дураков нет.
Наоборот.
LLM используется только для того, чтобы понять человека. А дальше работает все та же "машина", что и раньше. С одним существенным отличием. Теперь у нас есть человекопониматель, и поэтому "машина" может быть относительно простой и прозрачной.
Кто сейчас ведет учет в Excel? Все (ну почти) ведут в 1С. Вы думаете, в 1С бухгалтер может понять откуда взялась та или иная цифра?! Там специалист-сеньор в большинстве случаев разведет руками. Что вы от меня хотите? Реверс-инжиниринг? Миллион есть? Нет, до свидания!
А вот мой подход как раз дает возможность бухгалтеру разобраться, откуда взялась та или иная цифра, просто задавая вопросы на человеческом языке
А вот мой подход как раз дает возможность бухгалтеру разобраться, откуда взялась та или иная цифра, просто задавая вопросы на человеческом языке
Бухгалтеру чтобы понять откуда взялась какая цифра, нужна оборотно-сальдовая ведомость, карточка счета и пр., а не ответы на вопросы на человеческом языке.
Апельсины ушло 120, ой 130. Отмени последний ввод. Замок или замок? Кто ответственный за операцию? Итд итп.
Думаете, будут проблемы с отменой последнего ввода? Какие?
Давайте начнем со складского учета
Техкарты - это базис складского учёта. Или у Вас кондитер будет на каждую булочку будет вручную списывать 30г муки, 5г изюма, 1 яйцо?
А ещё для складского учёта нужно учитывать не только поступления, а поставки в целом. Приехала машина, привезла 50 позиций общим весом полтонны. "Кладовщик" будет это всё руками или голосом в бота заносить?
(открою секрет - сейчас УПД чаще всего ведётся в электронном виде и загружаться в систему будет одной кнопкой).
А с поставками тоже бывает веселье: сегодня купили 100кг муки "Селяночка" по 100 рублей у поставщика А, завтра у поставщика А муки не оказалось и пришлось покупать "Белонежную" у поставщика Б, но уже по 120 рублей: в итоге на складе 200 кг муки - но разной. Какую и в каком порядке Вы будете списывать?
И так далее и так далее.
А мне вот лично встречалось именно кондитерское производство, у которого была совершенно конкретная "боль". Количественный учет на складе сырья. А то, о чем вы говорите, у них "не болело"
Тогда это - просто маленький велосипед, для очень узкой ЦА.
Для 1с - вообще не конкурент
Согласен. Приглашаю вас взглянуть на "большой" велосипед 1 октября
Насколько я помню у 1с есть микро типовые решения как раз для таких клиентов, там конечно нет ИИ ввода, но зато там есть другие полезные вещи, а стоят эти решения как раз столько же сколько работа программиста по написанию бота из статьи
Зачем нанимать программиста для написания бота? Бот уже написан
на каждую булочку будет вручную списывать 30г муки, 5г изюма, 1 яйцо?
Это проблема технолога или пекаря. А если ушло 35г когда должно 30г - проблема предпринимателя. И замес, вообще то идет сразу на партию.
Приехала машина, привезла 50 позиций общим весом полтонны.
Да, разложить по полочкам - обязанность кладовщика.
Какую и в каком порядке Вы будете списывать?
FIFO. Бухгалтера в этом муху съело. Для маленькой пекарни не очень важны всякие заморочки. Булочки продаются по рыночной цене, а не по закупочной составляющих. Главное следить за прибылью.
Любопытно узнать о деталях реализации: как именно заставить LLM вызвать скрипты с параметрами?
1) Сложность. Вы показываете 2 элементарных операции на одном виде учета и на одном показателе (только количественный учет). Эта сложность пишется новичками, пришедшими на недельные курсы по 1с. Реальные рабочие конфигурации у 1с, думаю, раз в 1000 сложнее. Как вы собираетесь перейти от одного к другому?
2) Скорость работы. Скорость операций у LLM крайне низкая (по сравнению с оптимизированными для этого структурами хранения в 1с и кодом). Учет часто из себя представляет причинно-следственные связи между операциями по времени (каждая следующая использует предыдущие как исходные данные), поэтому при исправлениях важно актуализировать и все операции, начиная с исправленной до текущего момента. В терминах 1с это перепроведение. Возьмем для примера 1 тысячу операций и необходимость их перепровести. На сколько порядков ваша модель будет медленнее относительного того же на 1с?
1) Типовые конфигурации, да, в 1000 (а может и более) раз сложнее. Только эта сложность в 99% случаев излишня. То, что я вам здесь демонстрирую это реально рабочий сервис. Кому-то потребуется что-то посложнее? Ну напишите еще пару функции, в дополнение к этим трем. А если вы напишите еще 100 функций, то вы обеспечите пользователям практически все, что им нужно. Причем ваша разработка будет все еще неизмеримо проще, чем самая простая типовая конфигурация
2) Так "шустрит" не LLM. "Шустрят" ваши функции. LLM всего лишь "соображает" чего хочет пользователь и выдает сигнатуру функции. Потом эта функция выполняется на сервере. В моем примере это Python + MySQL. Это работает быстрее любой 1С
Так вы просто хотите замену экранных форм на текстовый ввод со свободным языком? Тогда это не отменяет 1с (и в целом может совмещаться с движком 1с).
Но в общем случае будет неудобно. Сейчас вы этого не замечаете, опять же, из-за крайне заниженной сложности. У вас по сути в тексте операции лишь 3 реквизита (вид движения, товар, количество). Сделайте аналог формы, где есть поля шапки, есть пару табличных частей, где в каждой строке табличной части несколько полей с текстовыми данными. Я бы посмотрел, как LLM разберется, где какие данные без дополнительной разметки.
Будете делать 1 текст на 1 документ? Тогда потеряете интерактивность ввода - и вы никак не поможете пользователю с заполнением коррелирующих полей (одно поле ограничивает список значений другого, например). Будете делать 1 текст на каждую строку/поле? Тогда ваш документ растянется по вертикали на много-много экранов, потеряется компактность данных, что добавит ошибок у операторов ввода.
Зачем все это? Пользователь говорит, что ему надо и получает что ему надо. Без всяких табличных частей, коррелированных полей и прочих "чудес". Это все остается в прошлом
Для удобства работы пользователя, которое влияет на число ошибок. Вот чуть ниже в треде вы сами же пришли к необходимости "задавать уточняющий вопрос" - это тоже относится к интерактивному вводу.
Собственно, список проблем - он не о языковых моделях конкретно, он вообще о текстовом вводе. Ровно те же проблемы у меня были при попытке сделать интерфейс к документам 1с в телеграм боте: очень низкая компактность отображения и очень ограниченная интерактивность. Поэтому простые документы (у меня были финансовые доки) - да, возможно. А вот сложные: вроде поступления, реализации, производственных - очень неудобно.
А теперь представьте, что человек вообще не напрягает глаза, только говорит
Так у вас тоже человек напрягает глаза: читает обратную связь - "что поняла модель" на каждой операции ввода, причем в ее собственном представлении о структуре информации.
Если вы предлагаете совсем без обратной связи - только говорить в черный ящик - то систему сразу можно выкидывать, т.к. никто не знает, что она неправильно разберет.
крахмал картофельный приход 100
крахмал кукурузный приход 75
сколько крахмала сейчас?
какой ответ будет?
второй пример
крахмал картофельный приход 100
крахмал кукурузный приход 75
крахмал расход 70
сколько крахмала сейчас?
какой ответ будет?
Попробуйте сами
https://t.me/awpdemo_bot
Автор видимо не знает что такое складской учёт от слова совсем. Добавь банальный учёт по партиям фифо фер и т.д. а дальше приходите как реализуете
Сделайте пожалуйста на гоогл скрипте !
Интересно, каков образ целевого пользователя этой программы?
Привычно когда интерфейс фиксирует: когда, кто, кому, откуда, куда, что и с каким сроком хранения и качеством да по какой цене, с каким налогом, маркой из ЧЗ, ответстветный за прием, передачу и бла-бла-бла.🙂
Вы сейчас переходите к деталям. Кому-то ничего из перечисленного вами не нужно. Кому-то нужна половина. Кому-то все и плюс еще что-то свое. Как угодить всем? Да очень просто. Пользователь говорит: "а теперь я хочу учитывать срок хранения." А ему в ответ: "да, дорогой, базу поменяли, можешь теперь сроки хранения указывать." И все опять же голосом, обычным человеческим языком
Бухгалтер и зав складом интересуются кто сидеть будет.
Никто не будет. В самом крайнем случае можно будет свалить все на Дурова )))
А так можно было?? (ц) ;)
он же теперь калькулятор
Ваш ответ на вопрос вдохновил - можно прикрутить опцию "timemashin" к Вашей складской системе - пользователь в телеграмм пишет куда хочет переместиться, а простейший скрипт на python, через специальное оборудование, перемещает пользователя в запрашиваемое время.
Приходите завтра, у нас инвентаризация.
Великолепная история о том как сделать складской учёт максимально сложным и чудовищным способом. Не насилуйте сервер нейросетями там где это не требуется. Это буквально самый неэффективный (с точки зрения ресурсов ПК и сложности обработки входа/выхода, галлюцинаций и пр.) способ обработки чего либо. Почему не сделать кнопки? А как множественный ввод сделать, обработку накладных. Может её сделать с помощью трансформеров типа Image To Text?) Не буду перечислять сложность интеграций других фишек типа функций конфигурации ЗУП и т. п.
Вы просто решаете проблему, которая в ИП решается Excel и Google Disk, а в больших прикинь 1С!
Буквально статья о том как термоядерным реактором обогревать жилые помещения ещё и в летний период.
Хорошая мысль. И верное направление).
Пока выглядит как иллюстрация фразы "микроскопом гвозди заколачивать" ведь на ai уйдёт куда больше ресурсов чем на систему схожей сложности на другом движке а результат может быть неожиданным.
Нет, вы ошибаетесь. На AI уйдет значительно меньше ресурсов, чем уходит сейчас.
Возьмем зарплату 1С-ника по нижней планке. Скажем, 100 тысяч рублей. Сейчас за эти деньги можно обработать 100 тысяч запросов. 1 рубль за запрос. Это несколько завышенная оценка. Есть модели, у которых стоимость обработки одного запроса около 10 копеек. Если в компании работает 100 человек, то на каждого придется по тысяче запросов в месяц, т.е. примерно по 50 в день. Этого за глаза хватит. 100 сотрудников, это пусть и небольшая компания, но все же она не может позволить себе простаивать из-за того, что 1С-ник заболел или ушел в отпуск. Значит, нужно 2 1С-ника. А к ним еще и начальник, иначе они работать не будут. И это все еще обычный режим, рутина. А если потребуется что-то модернизировать в учете? Вот и считайте затраты
Погонщиков AI тоже нужно не менее 2 шт. И начальника, иначе они работать не будут ;)
Зачем? Что они будут делать по вашему?
Что они будут делать по вашему?
Отвечать за корректность работы системы. И сидеть, да, если что-то не так. Ну вот когда на складе оказалось -5 кроссовок - это чья зона ответственности?
Недостача на складе это зона ответственности материально-ответственного лица. Например, кладовщика. И это никак не зависит от техники ведения учета: на бумажке, в Excel или с помощью ИИ
Очень даже зависит. В 1С накосячить сложно. Там база данных подперта тысячами проверок и ограничений, шаблоны решения типовых задач уже вколочены. А магия ИИ это конечно красиво.. Но -5 кроссовков это fail. Где оно ещё ошибётся и зачем кладовщику подрабатывать бета-тестировщиком?
В 1С тоже можно получить -5 кроссовок.
Отрицательные остатки, это вообще отдельный большой разговор. Не будем его здесь разворачивать
Поинт в том, что в классической учетной системе есть возможность раскрутить всю цепочку назад и найти почему сейчас по бумагам -5, а по факту 0. Или почему по бумагам 5, а по факту 0. А в случае LLM, это наврядли можно будет сделать адекватно или идемпотентно, с какого-нибудь понедельника LLM начнет считать, что теперь кеды со шнурками на толстой подошве это тоже кроссовки и вы про это даже не узнаете.
Даже если эта программа, когда либо будет считать налоги, прибыль и т.д.,то и то не верю в практическое применение. Даже сервисы предоставляемые банками по ведению бух учета обычно для усн6% мало кто использует даже на услугах.
Если простой складской учет, то проще посмотреть на полку, склад и прикинуть остаток хватит или нет. Чем говорить
И не корректно представлена роль 1с-ника.
Для ведения стандартного и даже сложного учета программист не нужен. Все решатеся типовой конфигурацией. Из опыта минимуи 80% организаций ведут учет в типовой 1с. Многие даже обновляют сами. Сейчас вообще многие стали на аренду 1с в облаке переходить, даже железо не надо содержать.
100 сотрудников это не совсем маленькое предприятие.
Давайте определимся с понятием 1С-ник... Если вы имеете ввиду программиста, то совсем не обязательно держать его в штате. Задач именно по программированию в таких организациях не очень много и они обычно не требуются очень срочно. Если вы имеете ввиду администратора БД, который разбирается с данными, то да, вы правы, для подобной организации он уже нужен. Правда в основном он нужен в момент закрытия месяца, поэтому можно обойтись и одним.
Представляете какой перечень номенклатурных позиций на данном предприятии? Какая оборачиваемость товаров?
"Есть модели, у которых стоимость обработки одного запроса около 10 копеек " Прикиньте стоимость обработки 1 накладной с 50 товарами в табличной части с количеством, ценами, характеристиками. А таких накладных не одна в день....
Я верю в ИИ, но данный автор по моему не понимает зачем нужна 1С. Самая главная цель 1С это получение данных необходимых для бизнеса. Самое простое это получение остатков со склада в виде таблицы хотя бы. Этого я тут не вижу. Про более сложные я вообще не говорю. Автор как будто делает учёт ради учёта. Ваш ИИ будет способен выстроить большой и сложный отчет. Хватит у вас навыков, чтобы научить его этому. По вашей логике даже ИИ не нужен, нужна только таблица в EXCEL с правильно настроенными макросами. Самое смешное, что для реализации складского количественного учёта есть давно уже типовые конфигурации. Вы говорите, что каждый запрос стоит 10 копеек. Зачем предприятию это нужно, если есть какая-нибудь УНФ за 30 тысяч, где все это есть бесплатно. Им не нужно нанимать программиста для этого. Причем там защита от дурака будет получше чем у вас. Возможно в будущем ИИ и заменит 1С, но точно не от вас) Все потому что вы не понимаете саму суть Enterprise приложении. Надеюсь я ошибаюсь, но у меня сложилось такое впечатление.
На мой взгляд, вы ошибаетесь дважды.
Ошибка номер один, получить таблицу от этого бота можно. Если бы вы прежде, чем писать хотя бы открыли этого бота и прочитали приветственную надпись (это, кстати, ваша ошибка номер ноль), вы бы увидели там: "...Если надо узнать что-то другое, например, что активнее всего расходовалось за какой-либо период времени, тоже просто спросите в произвольной форме. "
Но это не главное. Ваша ошибка номер два в том, что вы считаете, что людям нужны таблицы. Зачем? Чтобы что? Разве человеческий мозг может обработать таблицу? Людям не нужны таблицы. Они достались им из позапрошлой (бумажной) эпохи. Людям нужен конкретный ответ на конкретный вопрос. Здесь и сейчас. Сколько сахара на складе - вот столько-то.
Людям нужны ответы на самые разные вопросы
По какой цене Петров продавал мне сахар в прошлом году, и по какой цене мы его покупали в среднем в прошлом году? Чтобы выяснить резонно ли у Петрова брать сахар
Кто принимал партию муки на 100кг которой в итоге через 2 дня на складе 90кг
Как все наши изделия продаются по количеству, по сумме, по разнице суммы и себестоимости, с разбивкой по месяцам
Если вы начнёте все это внедрять в бота, вы получите переусложне́нный продукт к которому надо будет прикладывать инструкцию "что спросить у бога из машины". И с каждой новой фичей трудность отражения в боте одной операции будет только расти
А надо ещё отменять операции, если пользователь ошибся, причем не только последнюю но и иногда операцию за 2 недели назад (как было бы хорошо их нумеровать и где-то показывать пользователю список с номерами)
Имхо - ИИ для ввода это хорошо, но это хорошо как дополнение к существующим системам (например зарегистрировать простейший документ списания остатка как в примере но отразить его в условной 1С как документ, видимый пользователю в дальнейшем), или заполнить ТЧ документа перечислив кого/что туда добавить
И все эти бесконечные вопросы прекрасно сводятся к одному: "какой надо написать запрос, чтобы получить такую-то информацию". И вся "переусложненность" в итоге выливается в создание всего лишь одной функции: ВыполнитьЗапрос()
Нет, не к одному. Чтобы можно было написать запрос, нужно чтобы в базе были эти данные. Чтобы в базе была информация, её туда надо вводить. Чем больше информации нужно вводить для одной операции, тем труднее её ввести через бота и тем больше вероятность ошибки (как пользователя так и бота).
С чего вы взяли, что труднее? Вы пробовали?
Потому что одно дело операция "апельсины -120" а другое дело операция "на точке Х выкинули просрочку на дату Y, а именно апельсины 120 кг, ананасы 150 кг, помидоры 170 шт. , отвечал Петров", и соответственно вместо "апельсины +120" будет "на точку X Сидоров привез нам в момент Y апельсины 3 Большие Коробки, помидоры 170 шт, апельсины годны от даты Z1, помидоры от Z2, отвечал за всё Бабуинов". И бот должен всю эту информацию подаваемую в произвольном порядке как то интерпретировать, в т.ч понять что Большие Коробки надо еще в кг пересчитать, а пользователь должен интуитивно видеть, что бот всё понял правильно. И это мы даже ещё про суммы не говорим, всё в рамках количественного учета
Вы думаете, это все нереально? Почему? Вы много экспериментировали с большими языковыми моделями?
Как мне кажется, у вас перед глазами 1С. А надо смотреть на реальный процесс. На склад приходит товар. Кладовщик его по-любому принимает попозиционно. Каждую позицию внимательно смотрит. Сколько там на самом деле. Пересчитывает. И вот тут было бы более чем уместно фиксировать обработку каждой позиции. Сказать в смартфон "пришло того-то столько-то" это самое удобное для кладовщика. Удобнее не придумаешь.
Труднее <> Нереально. Но чем дальше в лес, тем толще партизаны. Формочка умеет подсказать, что апельсины у нас считаются только в Больших Коробках или в кг, причем ДО того как пользователь ввел единицу. Вполне может часть полей заполнить за юзера исходя из заполненных ранее (но с возможностью их отредактировать). Может давать кучу доп. подсказок, например что Сидоров нам никогда в жизни помидоры не возил, может мы чего и напутали. Если это всё реализовать пытаться в рамках текстового бота, то у нас одна операция будет отображаться длииинным долгим диалогом, где пользователь к концу уже забудет с чего он там начинал. Да и ценность ввода через ИИ существенно теряется если мы всё равно "по вешкам" идём.
Ну ладно, сколько сахара на складе вы ответили. А сможет ваш бот ответить, сколько нужно заказать сахара на следующий месяц, чтобы обеспечить потребности?
Насчет того, что таблицы это прошлый век это тоже смешно. Во-первых спросите себя в каком виде ваша система хранит данные. Неужели в таблицах базы данных? Во-вторых таблица очень удобный способ получения информации. Представьте вы начальник пекарни. И вы думаете завтра нам нужно приготовить условные 100 булочек. Надо посмотреть, хватает ли на складе продуктов. Как вы думаете будет удобнее спрашивать про каждую позицию, и платить за 10 копеек за каждый запрос? Или просто посмотреть таблицу и увидеть, сколько нужно дозаказать по всем позициям. Я уже не говорю про то что типовая 1С без вмешательства программиста сама сформирует документы для заказа недостающих продуктов.
а потом отключили телеграм...
а че телеграм? берите уж сразу электричество (и воду для надежности)
Отключат openai, неизбежно...
Есть Yandex, (Сбер, не то чтобы есть, но хочет есть, может и подтянется еще), есть МТС вроде как (пока не было времени проверить). Есть китайцы. Да и OpenAI сейчас не единственный в своем роде, кроме него есть Google и Anthropic. Это очень конкурентный рынок. Если кого и отключат, то не сомневайтесь, найдутся желающие принять ваши денежки
На хабре в конце августа была статья про "силу терминала или почему всем нужно уметь работать через командную строку" (https://habr.com/ru/companies/timeweb/articles/834738/). В ней как раз обсуждалось удобство использование командной строки, а не запутанный графический интерфейс с множеством функций и специфической группировкой(тот же 1с ). В общем итоге использование командной строки намного быстрее, чем GUI. А как раз для данного случая микро бизнеса, внедрить и поддерживать подобный учет гораздо удобнее, чем использование компьютера на рабочем месте.
Выглядит красиво, вижу что для мебельной мастерской очень даже подойдет, омобенно, когда нужно физически подсчитать, без привязки к бухгалтераким осиаткам
Видимо пока языковая модель не совсем подходит, либо нужно уточнение. Но вопрос в другом, можно ли настроить чтобы при поиске товара Яйца, модель найдя несколько совпадений по наименованию - задавала вопрос уточнение ?
Спасибо за подсказку! Да, это уже обсуждали здесь выше. В рабочем сервисе, я собираюсь добавить ветку уточнения.
но почему списались красные то?
А это особенность LLM. Она не может развести ручками и сказать: "ну я не знаю, что делать". Ей сказали работать, она работает и по любому выдаст вам результат. В данном случае красные яйца подходят, значит берем их
тогда вернемся к вопросу https://habr.com/ru/articles/839968/comments/#comment_27236824
А это особенность LLM. Она не может развести ручками и сказать: "ну я не знаю, что делать"
Зря. Делать что попало - плохо. 1С-ника за это лупят сцаными тапками ;) А этот ваш LLM не может решить, что яйца Фаберже тоже в принципе яйца, и их списать? ;)
Лишь бы не яички. Ибо яйцо и яичко - это две концептуальные разницы.
Плохо или хорошо, в данном случае вопрос спорный. Исполнительность LLM ценное качество
Исполнительность LLM ценное качество
двое-из-ларца.жпг - отличная иллюстрация ;)
Если бизнес-логика в 1С работает не так как ожидается - специально назначенный человек вносит исправление, и больше этот баг не повторяется. Что делать, если AI-магия делает не то что ожидается?
То же, что и в обычном человеческом общении. Если вас не поняли, постарайтесь переформулировать другими словами
НЯП нас не поняли и сделали как то по своему. Как понять, правильно ли нас поняли? Перекрестные проверки на каждом шагу?
Я не понимаю, какую проблему вы описываете? Вы не могли бы конкретизировать? На примере объяснить
Пролистайте выше, до красно-синих яиц ;)
В данном случае красные яйца подходят, значит берем их
Если это разные SKU - не подходят.
Что значит разные SKU?
Пользователь сказал "яйцо куриное". Ему предложили красное. Если он имел ввиду синее, он скажет "яйцо куриное синее". Вот и все. В человеческом общении так часто бывает. Тебя с первого раза не поняли. Ты выразился точнее и вопрос решен. Где вы увидели проблему?
Что значит разные SKU?
Одни закуплены по одной цене, другое по другой, например. Если бы bash, к примеру, по нажатию TAB не выводил список подходящих файлов, а сразу выбирал первый попавшийся.. дальше объяснять? ;)
Думаю, это все же вопрос пользовательского опыта. Да, есть сложившаяся культура взаимодействия с вычислительными устройствами. На мой взгляд, она зашла в тупик. Я понимаю, что вам нравятся списки. Но список, это неестественно. Если в нем больше трех позиций, он уже начинает насиловать мозг. Я убежден, что для человека будет гораздо комфортнее просто сказать, что ему нужно и получить, что ему нужно. И пусть иногда ему придется уточнять, все равно это будет для него комфортнее.
Вдумайтесь как следует в ситуацию с красно-синими яйцами. Человек оприходует "яйцо куриное красное", потом оприходует "яйцо куриное синее". Потом, через какое-то время, он пытается выполнить операцию, не указывая цвет яйца. Вот тут вопрос. Он что, не видит какого цвета яйцо? Здесь только два ответа.
Первый. Видит, просто забыл сказать. Увидев ответ сервиса, скорректирует свой запрос.
Второй. Видит, но ему пофиг. Он решил отказаться от идеи вести учет яиц по цветам. А сервис не грузит ему мозг, реагирует наиболее адекватным способом на ситуацию. Ну не прекрасно ли?
Я понимаю, что вам нравятся списки.
Ну, как сказать.. Приходится;). Одна из базовых структур данных. Спрашивают ;)
А складской учёт это сплошные списки, и не из 2 позиций.
Он что, не видит какого цвета яйцо?
Конечно не видит. Он видит буквы на экране и на бумаге. Он может просто ошибаться. Это человек. Ему может быть пофиг, потому что ему нужен результат прямо сейчас, и результат ему предоставлен, и не повода не доверять машине, она же не ошибается.
А сервис не грузит ему мозг, реагирует наиболее адекватным способом на ситуацию.
Адекватный способ - при неоднозначностях переспрашивать, а не принимать решение самостоятельно. См автопополнение в bash например.
Публикации
Складской учет без складской программы