Как налоговый юрист написал сервис для расчета пени по НДС с помощью LLM, не зная Python

[K0Jlya9]

Надо было использовать агентов для работы. Они буквально за тебя своими руками всё делают. Причем могут делать даже то чего от ллм не ожидаешь, бинарный файл редкого формата прочитать? Да легко.

[strannik96]

Спасибо! Попробую. Пока с агентами еще не работал.

[fedokanez]

Мой товарищ делал что-то подобное , когда еще все мы нет так активно использовали ИИ. Он там тоже считал пени, но правда девелоперный юрист . За основу он взял гугл шитс и там же скрипты использовал на гугл скриптс , практически тот же js. Правда пришлось провести ему уроки по js, с неделю где-то . Но за то он даже бота в тг сделал, который работал на вебхуках, считал пени и заполнял таблицу.

[strannik96]

Тоже хочу сделать бота. Хорошая идея. Вообще конечно долго возился, сотни запросов в gemini отправлял, что бы код поправить.

[BeLord]

У меня возникло несколько вопросов:

Первый вопрос по тестированию - как вы его проводили? Из опыта - то что скрипт правильно обработал пачку данных, еще не значит, что следующий раз он корректно посчитает другие данные.

Второй вопрос: вот сегодня нормативка одна, завтра другая, вы пробовали менять данные, к примеру сделать НДС 22% процента, изменить пени и проверить насколько корректно скрипт эти изменения отработает?

Вопрос три: вы проверяли корректность округления сумм, если да, то как?

[strannik96]

На первый вопрос, да сначала самостоятельно рассчитывал с помощью эксель и через калькулятор пени который в консультанте. Еще отдавал считать бухгалтеру. Про второй и третий вопрос не понял, в чем собственно вопрос? При чем здесь процент по НДС, калькулятор считает пени с суммы недоимки, а не с суммы процента по НДС, здесь важна ставка ЦБ, наличие моратория, и дни просрочки. Если нормативка изменится то поправлю код калькулятора и если вы заходили на сайт то видели, что там указана дата актуальности расчетов. Что нужно проверить в округлении сумм?

[BeLord]

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

Теперь по поводу второго вопроса. Я имел ввиду следующее - когда ключевая ставка 16% то в расчетах все просто. Если вы пользуетесь Экселем, то что 16%, что 13% для пользователя одно и тоже, Эксель сам "знает" как правильно взять любой процент. Если же вы сами пишете свой алгоритм расчета, то можно его написать так, что 16% он будет считать правильно, а 13% нет. Для этого и нужно тестирование, чтобы сразу недочеты кода исправить и потом, к этому не возвращаться.

[strannik96]

По округлению сумма НДС сразу приводится к копейкам, дальше дробление на 1/3 сделано так, что две доли округляются до копеек, а третья считается остатком, поэтому три доли всегда в сумме дают исходный НДС «копейка в копейку». Пени за каждый день считаются без округления “каждый день до 2 знаков”, и до копеек округляется только итоговая сумма в конце. Это исключает накопление копеечных искажений на длинных периодах.

Про процентную ставку. Я не давал ИИ задачу написать ставку только под 16%. Ставка берётся функцией get_key_rate(date)она ищет последнюю по дате ставку, которая действовала на конкретный день, и соответственно и считает пени исходя из действующей в день ставки.