Переход с устаревшей платформы 1С:Предприятие 7.7 на современную 1С:Бухгалтерия 8 (редакция 3.0) — это отличный повод провести полную ревизию старых доработок. Очень часто в базах-источниках прошлых поколений встречаются архитектурные решения, которые в современных реалиях платформы 1С:Предприятие 8.3 не просто избыточны, но и вредны. Типичный пример такой доработки — добавление собственного субконто (например, справочника Кассы) на счет 50.01 («Касса организации») для разделения учета по торговым точкам или филиалам.
В этой статье мы подробно разберем технические и методологические нюансы этой задачи. Выясним, почему прямое копирование логики «семерки» в новую систему может привести к серьезным проблемам с регламентированной отчетностью, кассовой книгой и обновлениями, а также рассмотрим несколько красивых, стандартных альтернативных вариантов решения без изменения метаданных конфигурации.
Для начала проанализируем техническую сторону вопроса, которую затронул автор темы. В программе «1С:Бухгалтерия 8» действительно реализована возможность создавать новые субсчета и привязывать к ним субконто в пользовательском режиме (через меню Главное — План счетов). Однако здесь мы сразу сталкиваемся с жестким ограничением платформы.
Чтобы назначить субконто для счета, тип этого субконто должен быть предварительно зарегистрирован в специальном объекте метаданных — Плане видов характеристик (ПВХ) ВидыСубконтоХозрасчетные. В пользовательском режиме мы можем выбирать субконто только из тех видов, которые уже предопределены разработчиками фирмы «1С» (например, Контрагенты, Номенклатура, Статьи движения денежных средств и т.д.).
Если нам требуется использовать в качестве субконто собственный, нетиповой справочник Кассы, то сделать это исключительно в режиме 1С:Предприятие (без изменения метаданных в конфигураторе) не удастся. Платформа просто не позволит сопоставить наш справочник со счетом учета, так как его типа нет в ПВХ.
Что касается использования механизма расширений (Extensions) для обхода этой проблемы, то здесь разработчик столкнется с необходимостью заимствования самого ПВХ ВидыСубконтоХозрасчетные и добавления в него нового типа. Поскольку этот объект тесно связан со множеством других механизмов конфигурации, такое расширение станет крайне «тяжелым» и может вызывать критические ошибки при последующих обновлениях типовой базы поставщика.
Если программист все же принимает решение пойти по пути кастомизации и добавляет новое субконто в конфигураторе, возникает вопрос: как заполнять эту аналитику при проведении документов? Ведь стандартные документы (например, Поступление наличных или Выдача наличных) ничего не знают о нашем новом субконто и не будут заполнять его автоматически.
В таком случае придется вмешиваться в модули проведения документов. Рассмотрим схематичный пример кода, который обычно используется для программного заполнения субконто в проводках регистра бухгалтерии при проведении:
// Пример заполнения субконто в обработчике проведения документа
Проводка = Движения.Хозрасчетный.Добавить();
Проводка.СчетДт = ПланыСчетов.Хозрасчетный.Касса;
Проводка.СчетКт = ПланыСчетов.Хозрасчетный.РасчетыСПоставщиками;
Проводка.Сумма = Объект.СуммаДокумента;
// Установка субконто дебета (наша касса)
НовоеСубконто = ПланыВидовХарактеристик.ВидыСубконтоХозрасчетные.НайтиПоНаименованию("Кассы");
Если ЗначениеЗаполнено(НовоеСубконто) Тогда
Проводка.СубконтоДт[НовоеСубконто] = Объект.КассаОтправитель;
КонецЕсли;
Очевидно, что такой подход требует постоянной поддержки кода. При каждом обновлении конфигурации разработчику придется вручную объединять модули проведения кассовых и платежных документов, что многократно увеличивает стоимость владения системой.
Теперь обратимся к более важной проблеме — методологии бухгалтерского учета. На форуме часто звучит мнение, что «дополнительное субконто никак не влияет на итоги, и баланс все равно сойдется». Давайте проанализируем эту ситуацию глубже и выясним, почему это опасное заблуждение.
Во-первых, автоматическое заполнение Бухгалтерского баланса. Само по себе добавление аналитического разреза (субконто) действительно не искажает сальдо по синтетическому счету 50 в целом. Однако, если бухгалтер для обхода ограничений решит пойти по пути создания новых субсчетов (например, 50.01.1, 50.01.2) в пользовательском режиме, эти счета по умолчанию не попадут в правила заполнения регламентированных отчетов. Программа просто «не увидит» новые субсчета при автоматическом сборе баланса, и бухгалтеру придется настраивать правила вручную, что крайне ненадежно.
Во-вторых, формирование отчета «Кассовая книга». Это самая критичная точка преткновения. Согласно законодательству, кассовая книга предприятия должна быть единой (за исключением обособленных подразделений). В типовой программе «1С:Бухгалтерия ПРОФ» алгоритм формирования кассовой книги жестко завязан на счет 50.01 и не предусматривает никаких фильтров по субконто. Даже если вы добавите субконто Кассы на счет 50.01, стандартный отчет все равно соберет все данные в одну общую кассовую книгу. Сформировать отдельные книги по торговым точкам стандартными средствами не получится — придется полностью переписывать сложнейший отчет «Кассовая книга», что приведет к колоссальным трудозатратам при обновлениях.
Чтобы избежать «говнокода» и сохранить конфигурацию на полной поддержке поставщика, рассмотрим три проверенных архитектурных решения.
Если организация крупная и имеет обособленные подразделения (магазины, офисы, филиалы), у каждого из которых должна быть своя касса и своя кассовая книга, то самым правильным решением будет использование версии 1С:Бухгалтерия КОРП.
В этой версии по умолчанию включен разделитель учета Подразделение практически на всех счетах (включая счет 50). Программа из коробки поддерживает ведение отдельных кассовых книг по обособленным подразделениям без написания единой строки кода. Это полностью закрывает потребность видеть остатки и движения в разрезе подразделений через стандартную Оборотно-сальдовую ведомость (ОСВ).
Если мы имеем дело с розничными торговыми точками (где установлены онлайн-кассы ККМ):
50.02 («Операционная касса»).50.02 используется справочник Склады (где каждая торговая точка представлена как склад с типом «Розничный магазин»).50.01) стандартным документом Поступление наличных с видом операции «Внутреннее перемещение».Этот подход позволяет детально видеть остатки по каждой торговой точке в ОСВ по счету 50.02, при этом центральная касса (50.01) остается «чистой» и полностью соответствует требованиям законодательства для ведения единой кассовой книги.
Современный стандарт автоматизации на платформе «1С:Предприятие 8» категорически не рекомендует превращать бухгалтерскую базу в хранилище детальной оперативной информации.
Для детального учета продаж, кассовых смен, чеков ККМ и работы десятков продавцов следует использовать специализированные решения:
1С:Розница1С:Управление нашей фирмой (УНФ)1С:Управление торговлейВ этих программах реализован мощный и удобный функционал ведения операционных касс. В бухгалтерскую же базу («1С:Бухгалтерия») данные должны выгружаться в свернутом виде (например, один документ Отчет о розничных продажах за день). Бухгалтеру не нужно видеть в ОСВ каждую отдельную кассу — вся оперативная аналитика доступна в управленческой базе, а регламентированная база остается легкой, быстрой и полностью типовой.
Подводя итог, отметим: переход с 7.7 на 8.3 — это уникальный шанс избавить учет от костылей прошлого. Откажитесь от практики добавления нетиповых субконто на денежные счета и используйте заложенные разработчиками механизмы, чтобы сделать работу системы надежной и простой в сопровождении.