Cross-Ledger Exchange
Сверка расчётов между двумя учётными базами по машинно-проверяемому контракту.

Задача
Сверка расчётов с контрагентом шла через Excel: он выгружал файл, мы его разбирали. Оба найденных бага оказались не в логике сверки, а в самом канале. ИНН, сохранённый как число, терял ведущий ноль — 8 контрагентов из 129 молча выпадали из сверки. Числовой формат с неразрывным пробелом превращал суммы от тысячи в ноль. Каждый раз чинили конкретный случай, а класс ошибок оставался на месте.
Решение
Сменили канал вместо починки экземпляров. Обработка на стороне контрагента работает только на чтение и отдаёт данные структурированным JSON по опубликованной схеме; на нашей стороне приёмник сверяет их с учётом и выдаёт Excel-акт с классом и причиной каждого расхождения.
Контракт зафиксировали до первой строки рабочего кода: JSON Schema, валидатор из трёх слоёв (структура, точность десятичных, арифметика итогов) и набор негативных фикстур по правилу «один файл — один класс поломки». Побочный выигрыш: выгрузчик отдаёт идентификаторы объектов, а не наименования, — сопоставление перестало зависеть от того, одинаково ли контрагент назван в двух базах.
Результат
Контракт закрыт автотестами и прошёл код-ревью в две независимые полосы разными AI-движками. Полосы нашли разные дыры, и обе били в ту же цель — тихий пропуск: хвостовой перенос строки в ИНН проходил как валидное значение, а дубли ключей в JSON обходили проверку версии схемы. Оба класса закрыты до того, как контракт ушёл в работу.
Есть похожая задача?
Обсудить в Telegram