Заказчик сказал: «Подробность ответов не подтверждает техническую глубину».

Согласен. Вот как я это исправил.

Получил замечания по семи кейсам 1С:ERP/КА. Суть: ответы слишком категоричны, потому что не было информации о точном релизе, расширениях и настройках конкретной базы.

Это справедливо. И вот что я изменил. Главный принцип, который я теперь применяю: «Документ → движения регистров → проводки → результат отчёта». Не «вот кнопка», а «вот цепочка, которую надо проверить на копии базы».

Что переписал:

Кейс 1. Остатки на нескольких складах. Раньше: «группа складов в заказе». Теперь: разделяю анализ совокупного остатка и операционное обеспечение. Отчёт показывает остатки — но это не значит, что система автоматически учтёт их в потребности. Нужно проверить разрешённые склады-источники и способ обеспечения.

Кейс 2. Смена спецификации в запущенном заказе. Убрал «универсальные команды». Изменение спецификации в НСИ ≠ автоматическое изменение структуры заказа. Для незапущенной части — один способ, для начатого этапа — другой, с сохранением истории и себестоимости выполненной части.

Кейс 3. Новая технология для части партии. Убрал «есть команда разделения» как обязательную схему. Сначала фиксируем: какая часть произведена, какая в НЗП, на каком этапе меняется маршрут. Отдельная номенклатура полуфабриката — только если он становится самостоятельным объектом движения и калькуляции.

Кейс 4. Переназначение материалов между госконтрактами. Разделил переназначение и временное заимствование — это разные хозяйственные ситуации. Не обещаю типовую печатную форму без подтверждения в интерфейсе. Отдельно проверяю банковское сопровождение.

Кейс 5. Затраты на счёте 20. Убрал «изменить правило статьи расходов» как универсальный совет. Сначала классифицирую затраты: относятся к конкретному выпуску, к НЗП или к периоду. Ручную проводку Дт 43 Кт 20 не предлагаю без разбора партионного и регламентированного учёта.

Кейс 6. Инвентаризация 09, 19, МЦ. Уточнил: ИНВ-17 — это акт инвентаризации расчётов с покупателями и поставщиками, а не универсальный акт по 09 и 19. Для 09 — сверка временных разниц и расчёта отложенного налога. Для 19 — документы и регистры НДС.

Кейс 7. ТМЦ в эксплуатации. Развёл бухгалтерское и налоговое признание. 40 тыс. рублей — не универсальный порог ФСБУ для всех ТМЦ. Лимит закрепляется в учётной политике. Дату расхода нельзя выводить автоматически из бухгалтерской проводки.

Что я запрашиваю у заказчика до окончательного ответа: Полное имя конфигурации, релиз платформы, версия расширений. Демобазу или скриншоты с включёнными опциями по производству, складам, НЗП, ГОЗ, ТМЦ в эксплуатации. Тест на копии базы с фиксацией цепочки: документ → регистры → проводки → отчёт. Точные названия документов и статусов в конкретном релизе. Ожидаемый результат: типовой механизм, настройка или допустимая доработка.

Вывод, который я считаю главным: Техническая глубина — это не подробное описание меню. Это умение сказать: «вот что нужно проверить в вашей базе, прежде чем утверждать». Именно такое разграничение отличает аналитика от консультанта по функциональности. Готов к разбору ваших кейсов по 1С:ERP/КА, производству, ГОЗ, CRM и BI. Пишите в личку. #1С #ERP #БизнесАналитик #ГОЗ #ФСБУ #CRM #СистемныйАналитик Продолжение следует…