«Тест зелёный, а оборотка не сходится»: пять багов в 1С, которые легко пропустить без знания бухучёта

Документ провёлся. Ошибок в коде нет. Тест зелёный.

Открываю оборотно-сальдовую ведомость по 19-му счёту — и вижу, что часть НДС оказалась на 91-м. С точки зрения программы операция завершилась успешно. С точки зрения бухгалтера учёт уже разъехался.

Всем привет! Меня зовут Ольга Сумерина, я старший инженер по тестированию 1С в Ozon. Три года до этого я работала бухгалтером: считала амортизацию, контролировала расчёты с поставщиками, закрывала период.

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

Почему в 1С «всё работает» не значит «всё правильно»

Давайте честно: большинство тестировщиков 1С приходят из обычного IT-тестирования. Они умеют проверять кнопки, формы, вызовы API, интеграции и знают, что такое Jira, тест-кейсы, регресс. Но они вряд ли знают, что такое субконто, зачем нужен счёт 62 и что происходит с регистрами при закрытии месяца. В итоге конечный пользователь может сталкиваться с трудностями. Например, программа может быть технически идеальной, но если после проведения документа «Поступление товаров» НДС улетел не на 19-й счёт, а на 91-й — она бесполезна для бухгалтера.

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

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

1. Неверный учёт НДС

При проведении документа «Поступление товаров» с НДС 22% сумма налога должна быть ровно 22% от суммы без НДС и должна попасть на счёт 19 «НДС по приобретённым ценностям».

ОригиналКак это видел разработчик. Он проверил, что кнопка нажалась и документ провёлся. Ошибок в коде нет, всё зелёное.

Что нашла я. Я открыла оборотно-сальдовую ведомость по счёту 19 и увидела, что часть НДС почему-то ушла на 91-й счёт «Прочие доходы и расходы». Программист полез в код — оказалось, что перепутанная ставка НДС попала в условие, которое распределяет сумму по счетам, и сработала неверная ветка. То есть дело было в том, что из-за неверной ставки сработало не то условие распределения. Человек с бухгалтерским опытом, скорее всего, быстро заметит такое расхождение в ОСВ. При обычной технической проверке документа его легко пропустить, если отдельно не проверять сформированные проводки и отчётность.

Что советую тестировщику 1С. Не закрывайте задачу по зелёному «документ проведён». Возьмите за правило после проведения открывать движения документа и смотреть, на какие счета легли суммы, а потом сверять это с оборотно-сальдовой ведомостью по тем же счетам. Для НДС это счёт 19, значит если часть суммы ушла куда-то ещё, вы увидите это сразу. Такую проверку можно зашить в тест-кейс на каждый документ, который формирует проводки. Занимает пару минут, а ловит то, что можно не увидеть в коде.

Чтобы эффективнее ловить такие баги, добавьте к базовой проверке ещё несколько шагов:

• Проверяйте не только счёт, но и субконто — ошибка часто в том, что сумма легла на верный счёт, но с неверным аналитическим разрезом (контрагент, договор, статья).

• Сверяйте сумму НДС расчётно: ровно 22% от суммы без НДС. Эту арифметическую проверку можно формализовать в тест-кейс.

• Прогоняйте разные ставки — 22, 10, 0 и «без НДС». Баг со «съехавшей» ставкой часто проявляется не на одной, а на конкретной ставке.

2. Отрицательная себестоимость

При расчёте себестоимости вылезала отрицательная сумма.

Как это видел разработчик. Он полез в код расчёта себестоимости и не нашёл проблем. Казалось, всё выглядело идеально.

Что нашла я. Я сначала проверила учётную политику и настройки регистров. Оказалось, что метод списания себестоимости настроен неверно на уровне конфигурации при определённых условиях. То есть код работал, но с неправильными исходными данными.

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

Чтобы ловить такие баги надёжнее:

• Проверяйте метод списания себестоимости и алгоритм расчёта именно на граничных условиях: несколько складов, партии, отгрузка до поступления.

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

• Проверяйте перепроведение задним числом — тот же документ на корректной последовательности может дать другую цифру.

• Заведите эталонный набор данных с «правильной» себестоимостью и сверяйтесь с ним после изменений.

3. Дубли в книге продаж

После обновления конфигурации в книге продаж некоторые счета-фактуры стали дублироваться.

Как это видел разработчик. Разработчик проверил отчёт — у него всё было ок.

Что нашла я. Заметила, что дублирование возникает, только если документ был скорректирован после проведения. Дело оказалось не в человеке, а в типе данных: на чистой базе и новых документах баг не воспроизводился, а на реальной базе с историей проявился сразу.

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

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

Чтобы ловить такие баги ещё эффективнее:

• Создайте отдельный регрессионный набор с историей и закрытыми периодами и прогоняйте его после каждого обновления конфигурации.

• Проверяйте дубли не только в книге продаж, но и в смежных регистрах: книге покупок, журналах счетов-фактур. Такой баг редко локализуется в одном отчёте.

• Включите в регресс сценарий «изменить уже проведённый документ» — именно он провоцирует расхождение между регистрами и отчётностью.

4. Сторно не формирует корректных проводок

Сторно отменяет ранее проведённую операцию. В 1С оно часто формируется отдельным документом (например, «Операция: Сторно» или «Корректировка долга»).

С точки зрения кода здесь почти всегда «всё зелёное»: документ провёлся, сумма аннулировалась. Проблема в том, что настоящая проверка сторно — это не проведение, а сравнение всей цепочки движений до и после.

Как это видел разработчик. Сторнирующий документ успешно провёлся, сумма исходной операции была аннулирована, ошибок при проведении не возникло.

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

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

Что советую тестировщику 1С. Для сторно сохраняйте ОСВ до исходной операции, после неё и после сторнирования. После отмены операции проверьте каждый затронутый счёт и субконто. Если сторно должно полностью отменять хозяйственную операцию, итоговое состояние учёта должно соответствовать состоянию до неё.

Чтобы ловить такие баги эффективнее:

• Проверяйте сторно не только по счетам, но и по всем видам субконто: ошибка часто в том, что сумма отменена, но потерян аналитический разрез.

• Сверяйте результат по каждому закрытому периоду отдельно — сторно задним числом в закрытом периоде особенно часто «роняет» обороты.

5. Перенос остатков на начало периода

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

Как это видел разработчик. Перенос выполнен, документ «Операция» создан. Итоговая цифра по счетам сошлась, ошибок при проведении не возникло.

Что нашла я. Входящие остатки разложены по счетам неверно — например, всё легло на 60-й счёт без разбивки по договорам и субконто. Аналитика ломается на весь год. Итог по счёту при этом может сходиться, но каждый субконто в отдельности — нет. Бухгалтер, который потом сверяет карточку контрагента или акт сверки, видит пустые или перепутанные расшифровки — и вся дальнейшая работа с этим счётом идёт по неверным данным.

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

Чтобы ловить такие баги эффективнее:

• Сверяйте не только общий остаток по счёту, но и разрез по каждому виду субконто: договору, контрагенту, статье, складу.

• Прямую сверку делайте запросом: сравните развёрнутые остатки до переноса и после построчно, а не только контрольную сумму.

• Проверяйте счета, где субконто критично для дальнейшей работы, — например, 60, 62, 41, 76 и другие расчётные счета.

• Переносите и сверяйте остатки по каждому закрытому периоду отдельно — на больших объёмах историю часто теряют именно на границе периодов.

Почему такие баги легко пропустить

Я бы выделила несколько ключевых причин.

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

Тестировали на чистой базе и новых документах. Многие ошибки проявляются только на данных с историей: на закрытых периодах, корректировках, перепроведении задним числом. Поэтому тестовый контур, в котором нет базы с историей, может не поймать многих проблем.

В первую очередь искали ошибку в коде. При этом причина может находиться в данных и настройках вокруг него: в учётной политике, настройках регистров, последовательности операций. Код при этом отрабатывает ровно так, как написан, поэтому в нём и не получается найти источник проблемы.

Во всех трёх случаях помогает один принцип — после проверки самого действия посмотреть ещё на шаг дальше: что изменилось в учёте и соответствует ли этот результат ожидаемому.

Чек-лист: что проверять тестировщику 1С, если в задаче есть учёт

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

• После проведения документа открыть движения и посмотреть корреспонденцию счетов, суммы и субконто, а не только сообщение об успешном проведении.

• Свериться с ОСВ по всем затронутым счетам: то, что видно в движениях документа, должно сходиться с оборотами и остатками.

• Проверить учётную политику и настройки регистров до того, как идти в код. Если цифра странная, а код чистый — почти всегда дело здесь.

• Ввести в документ дату из прошлого закрытого периода и посмотреть, что программа на это скажет.

• Отредактировать уже проведённый документ и посмотреть, что станет с регистрами.

• Ввести отрицательное количество и неправильную ставку НДС.

• После обновления конфигурации прогнать регресс на документах с историей: с корректировками, сторно, перепроведением.

Советы бухгалтерам, которые хотят уйти в тестирование 1С

Когда я работала в 1С:Бухгалтерии 8.3, постоянно находила странности: то в отчёте по реализации сумма дублируется, то в оборотно-сальдовой ведомости остаток прыгает как угорелый. Вызов айтишника сводился к фразе: «Перезагрузи базу». Никто не мог объяснить, почему вот это поле вдруг стало красным, а при расчёте себестоимости вылезла отрицательная сумма.

Идея перейти в тестирование не была спонтанной. В какой-то момент я поняла несколько вещей:

1. Бухгалтер тоже постоянно ищет ошибки. Только в документах и учёте, а тестировщик — в программе. Скилл один и тот же: внимание к деталям и то самое радостное «Ага, нашла!».

2. Я уже знала предметную область. Например, большинство джуниоров-тестировщиков 1С могут не иметь представления, чем отличается ПБУ 18/02 от старого ПБУ 18/02 (да, оно поменялось). А я была на «той» стороне и уже знала.

3. Больше всего мне нравилось разбираться, почему что-то работает не так. Сверка актов казалась мне менее увлекательной — это скорее рутина. А вот книга продаж и покупок давала больше разнообразия. Интересно было и экспериментировать с необычными сценариями, например с отрицательным количеством или закрытыми периодами.

Бонус: Советы начинающим, которые хотят уйти в тестирование 1С

Если вы работаете бухгалтером и думаете о переходе в тестирование 1С, у вас уже есть важная база — понимание учёта и того, каким должен быть результат операции. Это сильно помогает при проверке проводок, регистров, отчётности и сложных сценариев с историей.

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

Когда понимаешь, какой результат должен получить бухгалтер, проще заметить момент, в котором система начинает вести себя неправильно, и дальше уже разбираться в технической причине.

Мне в переходе больше всего помогло именно знание предметной области, но так же важно:

1. Знание конфигуратора — чтобы посмотреть структуру метаданных, реквизиты, связи между объектами.
2. Режим отладки и журнал регистрации — чтобы понять, что происходило в момент возникновения ошибки.
3. Запросы 1С — для анализа данных в регистрах и справочниках и других объектах информационной базы. Для этого потребуется освоить простые запросы, далее по мере необходимости можно пройти дополнительное обучение для построения более сложных запросов. Например, курс «Запросы в 1С 8.3, с нуля — до уровня Специалист по платформе» на сайте курсы-по-1с.рф.
4. Vanessa Automation — бесплатная и удобная вещь для автоматизации тестов. 
5. Знание баг-трекинговых систем.
6. Понимание Git (хотя бы команд pull, commit, push) для эффективного взаимодействия с командой и автоматизации тестирования.
7. Умение работать с файлами XML и JSON, которое пригодится при тестировании интеграций.
8. Навыки работы с 1С:Предприятие 8.3 на уровне продвинутого пользователя.

Из софт-скиллов:

1. Не бояться задавать вопросы и показаться глупым.
2. Не бояться просить помощи коллег, особенно на начальном этапе.
3. Усидчивость, внимательность к деталям.
4. Умение планировать время.