Отчётность сдана, период в Бухгалтерии закрыт — а через пару дней что-то поехало. Обычно за этим стоит одно: в УНФ кто-то задним числом поправил документ, и правка добралась до Бухгалтерии обменом. Если у вас стоит дата запрета загрузки, до Бухгалтерии она не доедет — но повиснет в специальном месте, и с ней придётся что-то решать.
Документ повис в «Непринятые по дате запрета» — что теперь
У вас три варианта.
Игнорировать — самый простой путь, но и самый рискованный: данные между УНФ и Бухгалтерией расходятся, и это расхождение никуда не денется само.
Вернуть изменение в УНФ на текущий период и после этого игнорировать в Бухгалтерии — например, если менеджер задним числом поправил сумму в реализации, попросить его вместо этого оформить корректировку реализации текущей датой. Тогда история в обеих базах остаётся чистой, а изменение всё равно попадает в учёт.
Принять изменение и пересдать отчётность — если правка действительно значима и её нельзя оформить иначе.
Есть отдельный технический нюанс: если в УНФ задним числом внесли совершенно новый документ, которого в Бухгалтерии раньше не было вообще, после принятия он придёт «заготовкой» — без счетов учёта, непроведённый. Это особенность того, как работает механизм принятия задержанных изменений, и документ просто нужно дозаполнить руками, прежде чем он встанет на своё место.
Не всякая проблема обмена — это одно и то же
Когда что-то «не пришло» или «пришло не так», легко свалить всё в одну кучу — «обмен сломался». За этим обычно стоит один из четырёх довольно разных сценариев.
Ошибка эксплуатации — кто-то в УНФ провёл документ в неправильном порядке, например, провёл реализацию раньше, чем разнёс оплату по заказу. Лечится обучением того, кто вносит документы.
Ошибка совместной работы — менеджер и бухгалтер одновременно правили один и тот же документ, не согласовав друг с другом. Лечится регламентом: кто и в какой момент имеет право трогать документ.
Ошибка самого обмена — правило обмена устарело, например, после обновления одной из программ. Это уже техническая история, и её место — у специалиста.
Неподдерживаемый сценарий — операция, которую программа в принципе не умеет корректно перенести между системами. Здесь бесполезно искать, что «сломалось»: ничего не сломано, для этого случая просто нужен обходной путь.
Различать эти четыре сценария полезно заранее — иначе легко потратить час на поиск несуществующей поломки там, где нужно было просто перестроить процесс.
Когда «нет в другой базе» — это норма
Один пример, с которым я регулярно сталкиваюсь: заказ-наряд, отменённый в УНФ, по правилам обмена может вообще не попадать в Бухгалтерию — ни при каких условиях, независимо от того, когда его отменили. Отсутствие такого документа в Бухгалтерии — это именно то, как обмен и должен работать для отменённых заказов, само по себе не сигнал беды. Прежде чем поднимать тревогу по конкретному «пропавшему» документу, полезно на секунду спросить: а должен ли он там быть вообще, по правилам, которые для него настроены.
Практическое правило
Перед тем как разбираться с расхождением, задайте себе один вопрос: это конкретный документ с конкретной, разовой причиной — или системная вещь, которая будет повторяться снова и снова, пока не поправить сам процесс или правило. Первое разбирается точечно и быстро. Второе требует один раз сесть и разобраться в первопричине — но именно так расхождения перестают возвращаться каждый месяц.