В процессе работы с конфигурацией 1С:Управление нашей фирмой (УНФ), особенно в версиях ветки 1.6 (например, 1.6.23.96), пользователи и разработчики часто сталкиваются с необъяснимым поведением системы. Речь идет о возникновении «космических» сумм в курсовых разницах при оплате со счета или получении миллиардных значений себестоимости при закрытии месяца. В этой статье мы разберем механизмы возникновения этих ошибок, проанализируем ситуацию с технической точки зрения и определим алгоритм действий для их исправления.
Рассмотрим ситуацию: при проведении документа Расход со счета система внезапно начисляет огромные курсовые разницы, которые не поддаются логическому объяснению. Однако, если документ отменить и провести заново, проблема исчезает, и цифры приходят в норму. Проанализируем, почему это происходит.
В 1С:УНФ расчет курсовых разниц реализован в режиме «онлайн» непосредственно в момент проведения платежного документа. В отличие от тяжелых систем (как 1С:ERP), где переоценка валюты обычно выносится в регламентные операции конца месяца, здесь система пытается актуализировать состояние расчетов сразу. Основная причина «глюка» кроется в механизме работы с регистрами Расчеты с поставщиками и Расчеты с покупателями.
Выясним техническую причину: при первом проведении документа (особенно если он вводится оперативно) система может некорректно захватывать текущие остатки по регистрам. Если в ту же секунду или в ту же транзакцию попадают другие движения, алгоритм расчета валютной суммы и рублевого эквивалента может «подцепить» остаток, который уже был изменен этим же документом или параллельной операцией. В результате возникает математическая ошибка деления или умножения на некорректный коэффициент, что и порождает «дикие» разницы.
Ситуация, когда документ Закрытие месяца рисует астрономическую себестоимость, часто связана с нарушением последовательности документов в пределах одной секунды (обычно это 23:59:59). Разберем по шагам, как это работает в УНФ.
Представим, что у нас есть два документа в конце дня:
Если оба документа записаны на время 23:59:59, то порядок их проведения для системы может быть произвольным (зависеть от внутреннего идентификатора ссылки GUID). Если «Закрытие» срабатывает раньше, чем «Распределение», оно видит пустую базу распределения. В коде некоторых релизов (включая 1.6.23) отсутствовала жесткая проверка на «деление на ноль» при распределении косвенных затрат на малую базу. В результате в регистр Запасы и затраты записываются корректирующие записи с гигантскими суммами.
Поскольку проблема часто решается простым перепроведением, мы можем сделать вывод, что дело в «грязных» остатках или нарушенной последовательности. Рассмотрим основные рекомендации для стабилизации учета.
1. Соблюдение строгой временной последовательности. Проанализируем порядок документов в конце дня. Чтобы избежать конфликтов при расчете себестоимости, рекомендуется разносить регламентные операции по секундам:
Начисление налогов — 23:59:57;Распределение затрат — 23:59:58;Закрытие месяца — 23:59:59.2. Метод «полной очистки». Если вы столкнулись с «дикими» суммами, недостаточно просто нажать кнопку «Провести». Рекомендуется сначала отменить проведение документа, убедиться, что движения в регистрах Расчеты с поставщиками или Запасы и затраты исчезли, и только после этого провести документ заново. Это заставляет платформу полностью пересчитать итоги регистров с нуля, исключая влияние старых записей.
3. Групповое перепроведение. Для устранения накопившихся ошибок во взаиморасчетах, которые могут быть незаметны на первый взгляд, полезно использовать типовую обработку «Групповое перепроведение документов». Это восстановит правильную цепочку зачетов авансов и переоценок валюты.
Если мы заглянем внутрь модулей, отвечающих за проведение платежей, мы увидим работу с таблицами остатков. Рассмотрим упрощенный пример того, как система может ошибаться при получении данных:
// Пример логики, которая может приводить к ошибке
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| Остатки.СуммаВалютнаяОстаток КАК ВалОст,
| Остатки.СуммаОстаток КАК РубОст
|ИЗ
| РегистрНакопления.РасчетыСПоставщиками.Остатки(&МоментВремени, ...) КАК Остатки";
// Если &МоментВремени включает движения текущего документа,
// расчет курса будет неверным.
Если РезультатЗапроса.ВалОст <> 0 Тогда
КурсДляПересчета = РезультатЗапроса.РубОст / РезультатЗапроса.ВалОст;
КонецЕсли;
В новых патчах 1С:УНФ разработчики добавили более жесткие проверки на соответствие валюты договора и валюты платежа, а также оптимизировали получение остатков «до» записи документа. Если вы используете старый релиз (вроде 1.6.23.96), рекомендуется проверить наличие расширений или патчей от вендора, исправляющих работу регистра Запасы и затраты.
Проанализировав ситуацию, мы видим, что «глюки» УНФ с огромными суммами — это следствие оперативного учета в условиях высокой плотности документов.
Основные выводы:
Взаиморасчеты. Копеечные остатки в валюте при нулевом рублевом остатке (или наоборот) являются катализатором «диких» разниц при следующей оплате. Используйте помощник корректировки взаиморасчетов для закрытия таких «хвостов».Подобный подход позволит вам минимизировать ошибки в учете и избежать паники при виде миллиардных сумм в отчетах.