Все потоки

Если у вашей компании на ОСНО входящий НДС превышает начисленный, вы фактически беспроцентно кредитуете бюджет: деньги заморожены, вместо того чтобы работать в обороте. Возмещение возвращает их на счет. Разберем механику системно: где возникает право на возврат, какой порядок выбрать под свою ситуацию и как пройти камеральную проверку без потерь. Речь не про «схемы», а про штатную процедуру для бизнеса на общей системе.

Технически НДС — это поток. Весь входящий налог из счетов-фактур поставщиков идет в книгу покупок, весь исходящий с вашей реализации — в книгу продаж, а разница за квартал подлежит уплате. Когда вход превышает выход, образуется отрицательное сальдо, которое можно вернуть. Но бизнес опасается заявлять возмещение. Дело не в самой камеральной проверке: ее проходят все декларации. Дело в том, что возврат — это расход бюджета, и налоговая обязана убедиться в его обоснованности. При возмещении она проверяет отчет не только автоматикой (АСК НДС-2 ищет разрывы по цепочке), но и вручную, и запрашивает много документов. Задача не в том, чтобы искать лазейки, а в том, чтобы заранее закрыть слабые места: счета-фактуры, реальность сделок и раздельный учет. Покажем, где эти места искать и как их усилить.

Привет! Я — Мария, руководитель направления автоматизации процессов управленческого учета, бюджетирования и контроля расходов.

На проектах регулярно сталкиваюсь с тем, что в организации автоматизировали согласование заявок на расходы, но вопросы о свободных лимитах, обязательствах и план-факте по-прежнему приходится решать вручную.

Со стороны это выглядит странно: автоматизация есть, а полноценного бюджетного контроля нет.

В этой статье я хочу посмотреть на проблему с архитектурной точки зрения. Разберем жизненный цикл бюджетного лимита и пять типовых разрывов процесса, которые чаще всего становятся причиной возврата к Excel-сверкам, ручному план-факту и спорам о доступном бюджете уже после внедрения.

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

Статья призвана познакомить читателя с тем, как биологические механизмы могут применяться при разработке искусственных нейронных сетей для создания сильного искусственного интеллекта (AGI).

История Maersk началась еще в 1886 году, когда жена капитана Петера Мёллера внезапно тяжело заболела. В отчаянии мужчина начал молиться со всей силой, и в конце своей молитвы он попросил у Бога какой-то знак, чтобы появилось какое-то доказательство того, что его молитва услышана. И тогда посреди неба, полностью погребенного под густыми тучами, сквозь тьму внезапно пробилась одна яркая звезда.

Эта статья является продолжением цикла статей. В предыдущей статье мы узнали как организован модуль спутниковой связи Satellite и как его установить в симулятор NS-3. В этой же мы познакомимся с наиболее употребляемыми классами симулятора NS-3, без знания которых в моделировании не обойтись

Пользователь столкнулся с ошибкой в вашей программе. Трекер ошибок ее зафиксировал. Стек-трейс показывает место сбоя. Но что делал пользователь за несколько секунд до этого? Какие запросы выполнялись? На каком шаге сценарий пошёл не так?

Для ответа на эти вопросы в трекерах ошибок используются Breadcrumbs — цепочка событий, предшествующих ошибке. Разберём, как они работают в Хоуке и как помогают быстрее расследовать сбои в приложениях.

Есть такая городская байка: если угадать правильную скорость, то можно проехать десяток светофоров подряд и ни разу не остановиться, поймав «зелёную волну». Водители из разных городов охотятся за этим ощущением десятилетиями. А мы взяли щепотку данных, немного технологической магии, дизайна и превратили эту байку в работающую фичу в навигаторе 2ГИС. 

Меня зовут Даня. Я продуктовый дизайнер команды Транспорт и сейчас расскажу, как мы собирали зелёную волну: от первого скетча до запуска.

Она умерла в воскресенье вечером, и никто не услышал ни звука. Детективная история о том, как поставить прослушку на собственное приложение: Prometheus, Grafana, Micrometer, алерты, SLO. Все улики в комплекте, демо-проект прилагается. Совпадения с вашим продакшеном не случайны.

В большинстве бизнес-сценариев LLM перестала быть просто чат-ботом. Современные модели становятся частью агентских систем: у них есть инструменты, доступ к файлам, терминалу, браузеру, базам данных. Они не только отвечают на вопросы, но и выполняют действия.

В этой статье (ее первой части) разберём среду изолированного исполнения кода: песочницу (sandbox).

Представим ситуацию: пользователь загружает Excel-файл, просит проанализировать таблицу, найти аномалии и на основе анализа создать PowerPoint-презентацию. В чистом виде LLM не умеет читать файлы, строить графики и создавать презентации. Однако может написать код, который всё это сделает.

И тут появляется вопрос: где этот код запускать?

Генерируемый агентом код может быть ошибочным или, в случае с промпт инъекцией, намеренно опасным. Поэтому для безопасного исполнения кода агенту нужна песочница или изолированная среда.

В этой статье разберём:
- основные риски исполнения кода в неизолированной среде;
- что такое песочница и её ограничения;
- какие бывают подходы к реализации песочницы;
- вариант логики работы агента с песочницей.

Мне было интересно проверить GigaChat/GigaCode не в обычном чате, а в нормальной агентной среде разработки. То есть не “ответь на вопрос”, а вот это всё: tools, function calling, streaming, MCP-инструменты, история диалога и работа внутри реального проекта.

Для проверки я подключил GigaChat к OpenCode через TypeScript-плагин. Простой текстовый запрос завёлся быстро, а дальше началось самое интересное: OpenAI-like API оказался похожим на совместимый агентный протокол только снаружи. Внутри пришлось собирать отдельный слой совместимости.

Чем больше задач берёт на себя агент, тем чаще он упирается не в качество модели, а в контекстное окно: туда нужно уместить инструкции, историю диалога, схемы инструментов и всё, что эти инструменты возвращают. Я считаю, что токен-оптимизация агентов — то, как мы расходуем это окно — станет одним из ключевых направлений ближайших лет, наравне с выбором модели и качеством промпта.

В этой статье я хочу поделиться личным опытом внедрения API-first подхода в автотестировании Java-приложений. Речь пойдет не о теории тестовой пирамиды, а о практической архитектуре автотестов, которая сложилась в нескольких фреймворках с разным уровнем сложности и балансом между API, UI и E2E.

Мы пересмотрели распределение проверок между API, UI и E2E, вынесли основную массу бизнес-сценариев на API-уровень и оставили UI там, где он действительно дает ценность: в пользовательских сценариях, отображении данных, работе форм и критичных сквозных проверках.

Наверное не существует в мире технической поддержки, которая бы среди прочего не занималась спасением данных клиентов. Не минула участь сия и нас в Postgres Professional. Однако особенность спасения битых данных в СУБД заключается в том, что сломаться может сразу на двух уровнях: физическом и логическом. Первое, это когда что-то случилось с физическим файлом внутри которого лежат данные, а второе это когда файл цел, но внутри него каша без смысла. Поэтому сегодня мы поговорим о том как понять что в вашей базе что-то пошло не так, как понять почему, как оценить ущерб и минимизировать его. А в конце, бонусом, обсудим как не стать героем подобных статей.

Если вы руководитель, вы наверняка знаете это чувство: голова забита планами, KPI, сроками, бюджетами, а где-то на периферии теплится мысль, что самое важное в работе — это всё-таки люди: ваши сотрудники, клиенты да и вы сами. Книги про менеджмент часто бывают сухими, как песок в пустыне, или, наоборот, слишком вдохновляющими, что после прочтения хочется, но непонятно, с чего начать.

Мы собрали пять книг, которые подходят к делу по-человечески. В них нет высокомерных лекций и скучных инструкций, и они напоминают: хороший руководитель не давит, а договаривается. Не приказывает, а объясняет. И не боится признавать ошибки — ни свои, ни чужие.

Если вы хоть раз обсуждали «правильную» архитектуру мессенджера, вы знаете, что разговор всегда скатывается в два полюса, и оба плохие.

Полюс первый: чистый P2P. Никаких серверов, клиенты говорят напрямую. Звучит красиво ровно до первого практического вопроса. Собеседник офлайн, а вы хотите написать ему сейчас. Куда уйдёт сообщение? В никуда, ждите, пока он включит телефон одновременно с вами. NAT, симметричные файрволы, спящий Android, который убивает фоновые сокеты. P2P горит на неудобстве.

Полюс второй: сервер. Удобно, офлайн-доставка есть, пуши есть. И ровно одна коробка, в которой лежат личности всех, граф контактов всех, очереди всех. Эту коробку можно заблокировать по сети, можно изъять физически, можно прийти к оператору с предписанием. Серверные мессенджеры горят на сервере.

Один из наших пользователей в бете сформулировал это лучше, чем мы в любой презентации: обсуждение альтернатив всегда имело два полюса. Либо ищем инфраструктуру как в Matrix, где все сидят по своим загонам и не пишут друг другу. Либо сидим без офлайн-сообщений как в P2P. Либо вообще не можем подключиться, потому что мосты для обхода блокировок съела моль.

Мы делаем RCQ, мессенджер в духе старой аськи, но на современной крипте. И последние месяцы мы потратили на то, чтобы найти выход из этого треугольника. Ниже модель, к которой мы пришли, и, что важнее, места, где она пока спотыкается. Это не готовый протокол, это дизайн и первые слои. Но он внутренне непротиворечив, и спор о двух полюсах он закрывает.

Сегодня Пикабушник под ником @apokhmel подарил мне мою мечту - оригинальную консоль GBA SP. Для тех, кто не в курсе - это легендарная портативка, вышедшая в далёком 2003 году и являющаяся раскладной версией оригинального GBA, куда добавили подсветку дисплея. Сначала ламповую, а затем и светодиодную!

Сертификат комплаенса — мёртвая бумага: через два часа хотфикс делает сертифицированный хеш недействительным, и никто не замечает. UVS заменяет «доверьтесь нам» на то, что любой пересчитает сам: deriveTier выводит тир из улик, а не из бейджа. drand + двойной RFC-3161-якорь + WASM-движок, собираемый на лету. Демо живые — попробуй сломать.

В ИБ и IT до сих пор рассказывают сказку про «рынок кандидата». На практике вами торгуются алгоритмы, скрытые критерии и корпоративная шизофрения. Разбираю по опыту своему и гостьи подкаста, HR‑эксперта Екатерины Днепровской, как устроен этот цирк и как в нём выживать именно технарю и безопаснику.

На сегодняшний день сфера ИТ в России — это огромная индустрия, где работают сотни тысяч специалистов. Официально государство признало значимость этой профессии еще в 2009 году, когда был учрежден День программиста (Указ Президента РФ № 1034).

Но даже тогда эта формулировка сужала всю индустрию до одной специальности. Ведь работа ИТ-систем — это заслуга не только программистов. Здесь одинаково важны системное администрирование, администрирование сетей, информационная безопасность техподдержка, и другие специальности. За прошедшие годы разрыв между формулировкой в законе и реальностью только увеличился. Думаю пора расширить статус праздника, переименовав его в День специалиста информационных технологий.

Каждый раз, когда нужно обновить аватарку на Линке, HeadHunter или во внутреннем Битриксе компании, в мире плачет один digital-специалист. Потому что варианта обычно два. Либо ты судорожно ищешь в телефоне фотку с чьей-то свадьбы, где ты в костюме, и пытаешься криво обрезать чужое плечо из кадра. Либо сдаешься, отдаешь 10 тысяч за час в фотостудии и на выходе получаешь пластиковый, скованный портрет с натянутой улыбкой «успешного успеха». Привет, 2010-е.