Здравствуйте! Я делаю сервис верификации фискальных чеков. Столкнулся с личной болью: пришлось в суде доказывать, что чек не поддельный. Обычная бумажка ничего не значит. Сервис проверки чеков, который есть у ФНС ещё хуже, чем любые другие аналогичные сервисы. Они просто теряют на половине пути часть данных.
Сейчас я заключил договор с ФНС, у меня есть прямой доступ к полным сырым данным чеков (JSON). Условия договора: я предоставляю бесплатный публичный доступ к своему сервису. Данные есть, а макета нет.
Задача: разместить весь этот массив (100+ служебных ключей, узлы, вложенные массивы товаров) на стандартном листе А4. Листов может быть несколько, но формат узкой чековой ленты или ветки (tree view) не годится — будет 10 страниц пустоты. Нужна плотная, технически точная, но читаемая вёрстка. Документ должен выглядеть как серьёзный аналитический отчет, где сохранены оригинальные ключи. Главное: сохранить вообще все ключи/значения. Также непонятно, как быть с переводом ключей/значений на русский язык: отдельно предоставлять словарь или же дублировать перевод прямо в отчёте.
Пример массива данных: https://pastebin.com/82x6JG4n
Попытка сверстать: https://dialora.github.io/receipt/
Встречали ли вы удачные патерны или концепты для вывода таких тяжелых массивов на А4? Как бы вы подошли к организации этого пространства?
Роман!
Мне кажется, что речь идёт о том, чтобы задизайнить таблицу, — так, чтобы её было удобно читать и можно было быстро понять, и чтобы при этом она занимала поменьше места. В общем, вела себя как всякая хорошая таблица.
Я не знаю, как происходит работа с таким документом, но предположу, исходя из задачи разместить всё на А4, что читает эти листы живой человек.
Также я не разбираюсь досконально в природе этих данных и связях между разными ячейками. Поэтому я не буду пытаться перепридумывать структуру документа, разве что что‑то мне покажется совсем уж очевидным (само собой, я могу допустить ошибки в процессе). При этом не могу не сказать, что обычно, чтобы сделать действительно хорошую таблицу, нужно вникнуть в природу данных.
Вооружившись Кодексом, чтобы редактировать сразу код и видеть эффект от изменений на всём документе, я попробую привести в порядок то, что получилось у вас, — на сколько хватит дневного лимита.
Первым делом уберём заливки и все лишние внутренние отступы у ячеек. Учитывая длину документа и количество ячеек, они съедают просто неимоверное количество места. Смотрите, из‑за нижнего края уже выглянула третья позиция:
Уберём все вертикальные линейки, в них нет никакого толка:
Уберём бесполезные не сообщающие новой информации синие заголовки:
Пришло время успокоить линейки. Приведём их к одной толщине и сделаем легче. В этом месте Кодексу понадобилось итераций пять, чтобы разобраться со всеми линейками:
Уберём бесполезные и съедающие по целой строке заголовки позиций. Чтобы каждая позиция явно отделялась от другой, сделаем верхнюю линейку у каждой более насыщенной:
Данные о поставщике, коде маркировки и что там ещё ниже в каждой позиции переупакуем в двухколончатую таблицу. Во‑первых, так лучше уместятся длиннющие лейблы. Во‑вторых, так проще читать сверху вниз:
Причешем лейблы. Избавимся от скобок, технические идентификаторы (ключи?) напишем бледнее:
По поводу повторения человеческих расшифровок в каждой позиции и ячейке. Мне кажется, по умолчанию правильнее дублировать их везде. Раз за разом сверяться с легендой, а потом искать место, на котором остановился, — такое себе удовольствие. Разве что с этими документами будут работать ребята, которые и так знают ключи назубок, — тогда можно попробовать убрать человеческие расшифровки.
Чуть‑чуть сократим лейблы, чтобы сделать некоторые ячейки однострочными и выиграть больше места:
Уберём лишние линейки и подожмём отступы между строками внутри блоков:
Уберём разделительные линейки и в ячейках, в которых лейбл стоит над значением:
О, вот и четвёртая позиция показалась!
В этом месте Кодекс предательски доел свой дневной лимит. Продолжим в следующем совете: причешем шапку и посмотрим, как ещё можно повысить компактность и читаемость блоков позиций.
А пока приглашаю рассказать в комментариях, какие смысловые ошибки я допустил.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ФНС разрабатывает сервис для хранения электронных чеков | 0 | 0 | 24-02-2021 |
| 2 | Серия документа В российских документах с незапамятных времен существует супер-пупер-архаичное ... | 0 | 8.6 | 04-09-2026 |
| 3 | Топ провалов ФНС: что службе так и не удалось реализовать | 0 | 7.23 | 22-09-2026 |
| 4 | Проверка контрагентов для главбуха: регламент, досье контрагента и чек-лист перед оплатой | 0 | 9.91 | 17-08-2026 |
| 5 | Облачные чеки для интернет-магазина: логика и контроль | 0 | 12.27 | 18-08-2026 |
| 6 | Контрольные суммы ИНН, ОГРН и СНИЛС: разбираем алгоритмы и пишем валидатор на Python | 0 | 8.26 | 16-06-2026 |
| 7 | Счет на ИП, а заплатило физлицо: нужно ли пробивать чек | 0 | 6.84 | 20-08-2026 |
| 8 | Борис Титов предложил ФНС внедрить "светофор" для проверки надежности контрагентов | 0 | 0 | 08-06-2023 |
| 9 | Может ли ИП на УСН с ПСН не пробивать чеки при оказании услуг дошкольного образования | 0 | 5.63 | 17-08-2026 |