В статье «Что должно быть в счёте на оплату, а чего быть не должно» мы разбирали содержимое счёта. По результатам той работы возникло желание оформить счёт стильно, ибо стандартный вариант бухгалтерских программ вроде 1С какой-то страшный.
А ещё в нём целых два номера счёта, что выглядит странно. Один из них всё же корреспондентский счёт. Конечно, посвященные знают, но документ должен быть корректным даже для тех, кто сталкивается с оплатой в первый раз.
Почему HTML
Некоторые компании, которым приходится рассылать сотни тысяч счетов или квитанций бьются за размер файла PDF. У них важен каждый байт. Например, FastReports очень гордится тем, что их PDF на 14-25 % меньше, чем PDF сформированный стандартными средствами.
У нас счетов не сотни тысяч, а на два порядка меньше. Но и тысячи счетов разослать по электронной почте с большими прикреплёнными файлами задача непростая. HTML формат позволяет рассылать существенно быстрее, так как размер письма меньше.
У HTML есть один недостаток — в нём может быть javascript, а javascript может быть потенциально опасным. Однако, это вопрос уже к фильтрам и антивирусному программному обеспечению. HTML-документу не помешал бы атрибут отключающий javascript. Или отдельный формат htmlcss, который гарантирует, что никакой javascript в файле исполняться не будет.
Плюсы HTML-формата:
- Легко генерится, верстается, внесение правок менее трудоёмкое, чем в PDF.
- Файл имеет меньший размер, чем PDF.
- Для просмотра не нужен Adobe Reader, а подойдёт любой браузер.
- Почтовые программы легко отображают HTML, сразу видно что пришло.
- Нет проблем с выделением и копированием данных. В PDF иногда бывают.
Сторонники PDF скажут, что PDF — это стандарт, что не такой уж он и большой, и Adobe Reader можно легко установить, и PDF много где отображается в preview-режиме, например, в тех же браузерах и почтовых программах, и даже можно научиться вносить в шаблоны PDF правки также быстро как HTML-шаблоны, а можно и HTML конвертировать в PDF. Очень даже может быть, как говорил профессор Преображенский, но не нравится мне PDF, а нравится HTML. Кстати, с конвертацией документов из HTML в PDF не сложилось у нас. Там пустая страница в конце в ряде случаев вылетала.
Если уж очень надо в PDF
Если ваши контрагенты или контролирующие органы все-таки просят счет именно в PDF формате, то в данном случае получателю достаточно через меню печати выбрать в принтере «Сохранить как PDF». Никаких дополнительных программ для этого не нужно.
Или, как вариант, существует масса библиотек конвертации HTML в PDF. И такой процесс существенно проще, чем изначально генерить документ в PDF.
HTML и печать формата А4
По умолчанию счёт и так распечатается нормально, главное, чтобы его ширина была 100 %. У нас ещё и высота 100 %. Небольшой тюнинг версии для печати желательно сделать.
Если нужно, чтобы на экране счёт выглядел приблизительно как на печати, то используйте стили:
Однако, это ни к чему в общем случае. Всё больше компаний переходят на электронный документооборот, и никакой реальной необходимости распечатывать счёт нет. Ну если где-то старпёры коллекционируют до сих пор визирующие подписи на счетах, то правильнее пересмотреть свои бизнес-процессы.
При печати следует отключить фон, дабы не расходовать зря чернила:
Дополнительно, как вариант, можно на печати установить шрифт с засечками. Считалось, что на бумаге удобнее и быстрее читается шрифт с засечками. Лично мне тоже удобнее с засечками. Однако, исследования не подтверждают разницы.
HTML и ЭЦП (УКЭП)
HTML-файл можно подписать откреплённой усиленной квалифицированной подписью точно также, как и PDF. И точно так же он будет в соответствии с 63-ФЗ равнозначен счёту с собственноручной подписью. А проверить подпись можно на ГосУслугах.
Красивый счёт
Мы несколько дней согласовывали детали, упрощали, оптимизировали, на базе разных вариантов делали один. В результате получилось вот так.
На бумаге будет принимать такой вид.
Если у вас интересный счёт, то кидайте образец в комментарии.
Комментарии
23Абсолютный бред разница в 20 кб в пользу пдф. Автор пдф в особой правке не нуждается, если и бывает нужно подправить дату или цифру. Не все умеют править и это с одной стороны хорошо. А вот ты вышли многостраничный договор в хтмл. Ты отправляешь документ в пдф зная, что у тебя его ни кто не подправит, что бы не доказывать было так, а не так
Прямо как в истории с мужиком из Воронежа и Тинькофф Банком лет с 10 назад, когда он просто сел, перепечатал договор с бумажного варианта, но уже со своими условиями, а позже пошёл судиться с банком, т.к. там не глядя приняли чужой вариант договора.
Формат файла сам по себе не защита от умышленной правки. Разве что минимальная защита от дурака. Использование электронных подписей и ЭДО помогают защищаться от "потайных" правок.
Применение pdf лишь даёт значительно большие шансы, что документ и на компьютере, и при печати будет отображаться так, как задумывалось автором. С учётом визуальной простоты большинства счетов и их сферы применения вряд ли такая точность сильно нужна.
В Вашем счете очень много орфографических и логических ошибок, начиная от "акцептирования" оферты и заканчивая тем, что КПП записан где-то отдельно от ИНН.
Оплачивать такой счет сложнее, чем счет 1с (при всей его безобразности), потому что реквизиты у вас разбросаны по всему документу в разных местах.
Назначение платежа вы сделали удобным для сея и неудобным для всех остальных, а это значит, что его будут постоянно пытаться поменять.
В общем, ?
Допусти, совершенно не важно где написан КПП в счете, потому что в платежке он не указывается в данном случае. Акцепт оферты написан нормально, читаемо. Все реально важные реквизиты (ИНН, БИК, р.с.) находятся рядом и легко читаемы. Мне лично нравится, и кажется удобным.
в ПП КПП всегда указывается, если это ООО, и его нужно проверять, возможно что у организации это обособка, и тогда его нужно править
При перечислении денежных средств другим юридическим лицам КПП (реквизит 102 и 103) указывать не обязательно. (Положение ЦБ РФ от 19.06. 2012 №383-П)
???
Стараюсь всегда указывать то КПП, который указал поставщик в своем счете. Дабы не создавать ему каких-либо проблем.
Как раз этим и можно создать, если контргент по какой-то причине сменил этот самый КПП после выставления счета и платежка тогда зависнет, а если не указывать, все пройдет, как "по маслу". Для платежей в бюджет КПП необходим, а юрикам, физикам и ипешникам, я считаю совершенно лишним и в своих счетах не указываем этот реквизит совсем.
Если платежка зависнет по указанным контрагентом реквизитам - это будет вина именно контрагента и никак иначе.
Ну, и к чему эти лишние разборки? Можно и время сэкономить на вбивании ненужного реквизита и не искать виноватых. Одни плюсы, я считаю. )
Неужели полагаете, что я настолько трудолюбивый? ;-) Один раз завел КПП контрагента и дальше про него можно забыть. Пока контрагент сам не уведомит о смене КПП.
Вот, уж чего не знаю, того не знаю. Может быть, это какой-то фетиш. ))
Извините.
Если рассуждать логически, то для платежей в бюджет достаточно указывать КПП плательщика.
Поле КПП получателя вообще не нужно получается.
Согласно Положения ЦБ РФ для платежей в бюджет поле КПП заполняется обязательно.
А, если рассуждать логически, то какая такая надобность в этом КПП для юр. лиц, я не понимаю. Может кто знает, поможет разобраться.
Наименование получателя тоже не указывается?
Получатель указывается. Откуда возник вопрос?
Наименование получателя в примере, приведенном в статье, тоже указано отдельно от ИНН.
Так делать можно, но не нужно называть это достижением - это нифига не удобно. Как и наименование банка отдельно от БИК - почему бы нет, но не называйте это эргономичным, пожалуйста.
В данном случае сгруппировано то, что реально нужно. У меня контрагент полностью заполняется при заполнении ИНН, и название банка и к.с. подтягивается по БИК. Поэтому Важно ИНН, БИК и р.с. все остальное, просто чтобы было "на всякий случай, просто сверить", какой-то функциональности в этих данных нет, для меня лично. Лично для Вас не назову это эргономичным, но это не захламляет внимание.
Я согласна с Вами в том, что назначение платежа не удобно. Мне не нравится латиница, потому что не удобно менять регистры. Вообще, использование латинских символов в префиксах, индексах и пр. замедляет работу очень.
А еще, я понял так, что вы не смогли разобраться с использованием библиотеки для создания pdf и поэтому, чтобы не париться, решили использовать html.
Это нормальное решение для MVP, но гордиться совершенно нечем.