Комментарии 57
Ох плюсую в карму
как же надоело везде бороться с проприетарными форматами документов которые на двух рядом стоящих тачках могут открыться по разному, ну что мешает всем перейти на odf и html… ладно я молчу про создание доков в latex, бухи и секретарши просто не осилят… но тут уж проще некуда..
pdf - открытый формат
Pdf разрабатывался как раз как формат обеспечивающий повторяемость вывода. Odf и html больше про семантическую разметку текста - вывод подстраивается под возможности каждого конкретного устройства. То, что pdf в некотором ПО отображается абы как - обратная сторона открытости - не все, кто берутся за реализацию, осиливают довести дело до конца. С тем же успехом можно криво реализовать рендеринг html и odf, это не проблема формата.
да, pdf открыт, но реализуют его всё таки все по разному, а что там касательно подписи и шифрования… лучше бы ничего не было…
а вот doc/x и xls/x уже столько крови выпили… сил нет. благо на текущей работе это уже не мои проблемы.
А требования налоговой в некоторых местах юзать tiff да ещё с каким нибудь однобитным монохромом, да уложившись в вес в 0 килобайт… ухх, как вспомню так тошнит..
В HTML счет конечно выглядит по красивее, но в распечатанном виде и вертикальной ориентации много пустого места с лева.
А если ещё и добавить колонки : ЕД. + КОЛ-ВО + ЦЕНА то наименование растянется строк на 10?
Если добавите колонки, то тогда распечатывать следует с альбомной ориентацией.
Но правильнее перестать распечатывать.
Сейчас распечатал, у меня не так чтобы много. Пустое место тоже должно быть, чтобы глаз отдыхал.
Не соглашусь. У Вас с избытком пустого места очень сжатая таблица с перечнем наименований. Глаз должен считывать информацию, а не выискивать ее. А представьте бланк на несколько десятков/сотен наименований? В этом плане в 1С достаточно оптимально все сделано (хотя можно и поиграть с шрифтами).
Если ваш html-счет расползется на 2-3 страницы, то левое поле становится лишним. К тому же левое поле уменьшает пространство счета и для просмотра на маленьком экране наверняка потребуется масштабирование.
Переход с PDF - поддерживаю! Откуда он вообще вылез? Вдруг в один прекрасный день все везде стали пользоваться этим PDF, любить и не представлять жизнь без него. Хотя формат сложный, бинарный, проприетарный, имеет разные несовместимые версии, не гарантирует одинаковое отображение у разных клиентов и всё в таком духе.
Иногда хочется спросить, что надо сделать, чтобы твой "сложный, бинарный, проприетарный" формат стали внезапно использовать во всём мире? В бане у рептилоидов кукарекнуть? (шутка, если что).
Сам недавно сделал своим пользователям HTML-формат документов на замену PDF. Один день писали в тех. поддержку с вопросами, но им там всё разъяснили и больше вопросов нет. Работать с HTML вместо PDF - возможно и правильно.
Ошибка в тексте
Сохранить как DPF
Пишу в комментариях, потому что не отрабатывает Ctrl-Enter. И что самое странное, не получается отправить и в диалоге.
Html?! - нужно идти дальше! Сразу делать xml
Вы опустили момент с кбк. Шапка образец заполнения все таки структурирует это дело, и получается меньше ошибок.
Вы опустили момент с кбк
Надеюсь, что автор не "забыл", а именно специально даже не предусматривал ничего для поддержки КБК.
Вот забавная заметка от Леонида Каганова на тему КБК и прочей ерунды.
Собственно, СБП первый шаг в этом направлении.
Другой вопрос, что наши чинуши чеховские человеки в футляре. Они не могут разрешить автомобильные номера произвольные. Ведь кто-то же зарегит PTN PNH и режим сразу рухнет.
Согласен, мне кажется, люди, которые получают платёж, больше нашего должны знать, по каким статьям проводить деньги. Написал и понял, что это невозможно. Как физлицо меня это тоже удивляет, но если смотреть с другой стороны без этой информации сложно. Нужно сортировать деньги по способу получения и целям.
но если смотреть с другой стороны без этой информации сложно
Ну конечно сложно. Я бы даже сказал, нет ни одного пути обойтись без КБК и ОКТМО.
А ещё, чтобы упростить жизнь телефонным компаниям и сотовым операторам, надо сделать так:
Представим, что все телефонные номера состоят из 100 цифр. А на вопли о том, как их сложно набирать, выбегают умники и начинают рассказывать что:
40 цифр нужны, чтобы закодировать страну, область, город, улицу и дом, где физически расположен данный телефонный номер (и пусть многие номера теперь мобильные, но традиция осталась, поэтому для мобильных абонентов мы вписываем прописку владельца);
20 цифр — тип телефонного аппарата, модель, производитель и год выпуска (это очень важно: например, можно узнать, поддерживает аппарат тональный набор или нет!);
5 цифр означают тип линии: стационарный, мобильный, спутниковый (это ж разные вещи, понимать надо!);
6 цифр — код владельца (физическое лицо, юридическое, госучреждение);
3 цифры — свойства линии: одноканальная, многоканальная (это очень важно знать телефонистам для быстрого поиска обрыва провода);
10 цифр — стоимость минуты звонка для звонящего, если звонок платный (дико важно!);
11 цифр — основание, по которому взымается плата за звонок (нужно для налоговой);
5 цифр — контрольные, нужны чтобы не ошибиться при наборе;
18 цифр — индекс телефонного провайдера или мобильного оператора (включая его ИНН);
все остальное — номер абонента;
А после этого всплывает такой телефон как Thuraya X5-Touch
Он может быть куплен на организацию (по логичным причинам)
тип линии — вы забыли еще региональный спутниковый (работает не по всей земле), у X5 кстати 2 слота под симки (второй под обычную GSM)
стоимость звонка — зависит от тарифного плана… у звонящего
основания взимания платы — так это к оператору звонящего
ИНН — как быть если это иностранцы?
Кстати а как быть если симка может быть переставлена (той же Thuraya симку можно в GSM аппарат воткнуть, она в роуминг свалится)
Кстати а в случае с производителем — кто производитель айфонов в данном случае? Apple или Foxconn?
длят
118 цифр получается... а номер абонента куда?
Я, Каганов Леонид Александрович, лицевой счет 771534525261, логин личного кабинета adsl-771534525261, IP 215.79.121.14, выдан 26.11.2008 в 14:21:01, использующий ноутбук ASUS EEE-701 серийный номер AX123-13284, MAC-адрес 0051EB2DA168, куплен в «М-Дитрикс» 11.04.2008, прошу разрешить мне (однократно, многократно, транзитом — нужное подчеркнуть) в период с 26.11.2008 по 26.12.2008 посетить сайт www.razgovor.org, IP 66.242.20.102, выдан 27.05.2007 в 12:01:23 по 27.05.2010 12:01:23. С правилами посещения интернет-сайтов ознакомлен.
В 2021 не смешно :( Особенно последняя фраза.
Корсчёт вы имели в виду? Он по БИК автоматический у нас определяется. Для бюрократов указан в нижнем левом углу. Ну и сейчас мобильные банки умеют реквизиты грузить через QR-код. Там к.с. тоже указан.
Для этого есть hash md5, а ещё лучше цифровая подпись.
Но странно, что они не боятся подделки бумажных документов. Печать в любом ларьке можно заказать. Подпись тоже подделывается.
Но странно, что они не боятся подделки бумажных документов. Печать в любом ларьке можно заказать. Подпись тоже подделывается.
Это всё возможно, но требует хоть каких-то усилий. Изменение же файла в редактируемом формате (типа HTML или DOC) никаких усилий не требует
А дальше интересно.
Вай вай, мы оплатили, деньги вам не придут, но мы будем колупать вам мозги целый месяц.
Новый счет выглядит интереснее. Важно, что добавлен QR-код - такой функционал поможет тем, кто бизнес ведет, так скажем, в движении.
Согласен c автором. С HTML в данном случае удобнее, чем в PDF.
Легко генерится, верстается, внесение правок менее трудоёмкое, чем в HTML.
Счета бывают и на 100 и на 1000 позиций. Будете повторять левый блок на каждом листе счета?
При отсутствии договора, счет - это обязательный документ, его заменяющий, и ФНС требует чтобы в бумажном виде он хранился 5 лет. Так что проблемы с экономией места на бумаге выше, чем со свистелками и отдыхом для глаз.
Также, при отсутствии договора, в счете необходимо указывать реквизиты(ИНН, КПП, юрадрес) как поставщика, так и покупателя. Так что ваш вариант без реквизитов клиента не отвечает требованиям ФНС.
Сейчас некоторые компании умудряются превращать свой счет в рекламный проспект, где мЕста для продвижения товаров и услуг намного больше, чем значимой информации - вот это реально неприятно. Хранить это надо клиенту, но не поставщику.
В целом по статье - идёте по тонкому льду. Если каждая компания будет создавать свой вариант счета, то получится зоопарк в худшем его проявлении. Сейчас, при сложившейся форме как на первом скрине статьи, любой бухгалтер понимает где искать нужную информацию и к чему она относится. В Вашем же счете времени на распознание требуется на порядок больше
Про обязательный документ счёт и требование налоговой дайте ссылку на закон. Счёт не является никаким обязательным документов по закону!
Если же у вас 100 позиций, то HTML+CSS умеет творить чудеса. Обращайтесь.
Про то что необходимо указывать в счёте ссылку на закон опять. Пока это ваши фантазии.
В нашем случае бухгалтеру нужно мозги прокачать и:
- либо руками найти и скопипастить из счёта реквизиты;
- либо QR-код загрузить;
- либо 1С скормить доступ к электронной почте, куда прилетает наше письмо и 1С загрузит реквизиты из XML.
Странная у Вас логика - в статье упоминаете компании с "сотнями тысяч счетов", это воспринимается как рекомендации к повторению, а в комментарии только за себя отвечаете...
Счет является обязательным если он выступает в качестве договора. Вы(или Ваш коллега) это сами пишете в статье по ссылке в начале этой статьи. Именно в нем вы определяете основные условия сделки - сроки, стоимость, перечень товаров или услуг. А Статья 434 ГК РФ подтверждает, что договор может быть заключен в любой форме, вплоть до электронной переписки.
В то же время 402-ФЗ "О бухучете" устанавливает, что первичные документы должны оформляться в утвержденном виде и определяет сроки их хранения - в большинстве случаев, 5 лет. При ЭДО требований к печати по умолчанию нет, но при проверках все равно придется подключать к работе принтер. Также огорчает тот факт, что пока слишком мало компаний внедряют электронный документооборот - при разовых сделках проще распечатать документы, чем заморачиваться подключением партнера к системе
По моему опыту, торговые компании по счетам без договоров работают в 90-95% случаев.
Про вторую сторону сделки соглашусь - в случае, когда клиент не подписывает документ, а акцептирует его другим способом, его имя и реквизиты указывать не обязательно. Но в этом случае вы создаете оферту, оплатить которую может любой партнер, получив при этом условия лишь для конкретного клиента. Если вас это не пугает, то для других компаний это может быть принципиально. Именно поэтому счета выставляются с указанием реквизитов второй стороны.
Ну и по поводу прокачать мозги бухгалтеру - при большом количестве (хотя бы просто сотни, без "тысяч") счетов, от него требуются другие навыки, нежели поиск необходимых данных во множестве различных форм, цветов, шрифтов выставляемых компании счетов.
В целом непонятно, откуда возникло желание что-то менять в достаточно отлаженном и стабильно работающем документе.
В бизнесе надо выделяться. Пробовать. Плюс хочется красиво. Отсюда и желание.
В обоих моих сообщениях есть условный оператор - ЕСЛИ нет договора, ТО счет обязателен.
Цитата из Вышей статьи:
"5. Счёт может быть совмещён с договором или актом. А может быть всё в одном: договор-счёт-акт."
Вы же не будете спорить, что Договор - это первичный документ?
ИМХО, выделяться лучше действительно в бизнесе, а не в раскрашенных документах.
В вашей предыдущей статье есть абзац "Счета, которые взрывают мозг". Как бы Ваша текущая статья не добавила 9й пункт в этот перечень...
Ну вообще выставленный счет на оплату является по сути офертой.
И если потребитель "акцептует" данную оферту (т.е. совершит оплату по данному счету), то договор считается заключенным (даже при фактическом отсутствии подписанного договора).
Что автоматически приравняет этот счет на оплату к договору, который должен храниться (ЕМНИП) 5 лет со дня выполнения договорных отношений.
Ст. 432, 433, 434, 438 ГК РФ
Показывать счет в html довольно удобная вещь, обладает своими преимуществами. Однако в вашем примере "красивым" назвать это сложно.
- Так не понятно, но есть ощущение что цена выравнена по левой стороне. Это достаточно грубая ошибка: цены всегда выравниваются по правой границе, причем ровно по точке, так гораздо проще сравнивать.
- Итого должно быть в той же колонке, а не где получится, потому что сразу видно и легко подсчитать. Сейчас его откровенно нужно искать глазами
- Что будет если одна услуга будет заказана дважды? А если какая-то услуга будет скидкой? Как-то откровенно не хватает столбцов.
- Отсутствие отступов и бесполезная зебра в таблице, все это только усложняет чтение. В общем, есть же правила формирования красивых и читаемых таблиц.
Теперь немного не про таблицу.
- Я буду вам очень благодарен за пустую трату чернил на ваш огромный плотный логотип, да. Еще и в цвете. Можно и по-скромнее быть.
- Слева пустота, а сама таблица пытается влезть в очень узкое место. Я бы поместил данные в шапку, а таблицу бы растянул на всю ширину. И это примерно как люди ожидают увидеть страницу. Заодно уберет проблемы с несколькими страницами: на дополнительных страницах будет только полезная таблица, а не бесполезная пустота.
- На странице три даты и все в разном формате.
- Как будет выглядеть заказчик "НИИ им. Орджаникидзке двух Орденов Ленина и Ордена Красной звезды университет Московский Авиационный Институт".
- Всем плевать, но в России официально кавычки это "« »".
- Ну и просто визуально несбалансированно, одна часть страницы очень тяжелая, сомнительное выравнивание в левой части, в общем, есть куда развивать.
2. У нас не везде расшифровка есть. Таблицы может не быть. И я сторонник её вообще выкинуть. Толку от неё там ноль в нашем случае.
3. Будет две строки. Скидки каждый может выводить под себя, если они нужны.
4. Так такой задачи нет. Читать нужно не таблицу, а реквизиты слева. Справа только назначение и сумма.
1. Мы призываем перестать печатать вообще.
2. Каждый волен задизайнить себе свой вариант. Мы идём в направлении отмены таблицы с детализацией.
3. Так задумано. Именно, чтобы можно было автоматически парсить пользовательские назначения платежа с ошибками. Можно распознать где дата счёта, а где дата договора. Третья там не дата, а период.
4. Отлично. Проверил.
5. Скажите это банкам, которые далеко не все данный формат кавычек пропускают.
6. Есть. Это не первая и не последняя версия. По результатам публикаций ценные замечания вносим.
Спасибо! Продолжу свою мысль:
Это все нужно начинать с целей: зачем это вообще кому-то нужно (не html, а выписка как таковая). Я вижу цели (но могу в них глубоко заблуждаться):
- Очевидная: передать клиенту реквизиты и сумму, которую он должен заплатить. Для этого можно вообще не заморачиваться, а это крупным шрифтом и напечатать.
- Прозаичная: подтверждение клиенту что вы будуте ему оказывать эти конкретно услуги, за которые он платит (я понимаю, что есть договор для этого, но см. пункты дальше).
- Юридическое оправдание со стороны клиента чтобы он показал "мы оплатили вот эти услуги, бла бла бла" (клиент мог показать в суде что было оплачено)
- Чтобы вы могли в суде показать что конкретно оплачено
- Чтобы клиент мог показать бумажку по бухгалтерии за что они заплатили при проверке. К слову, платить тоже бухгалтерия будет.
Пункты 2 и 4 в данном случае означают, что этот документ может быть рано или поздно отправлен на печать. Скорее всего рано и потом будет сложен в стопку расходов.
Пункт один требует наличие детализированной таблицы, с помощью которой отдел разработки или кто там будет отображать бухгалтерии за что они конкретно они там будут платить и бухгалтерия 99% развернет их, если не будет расшифровки. Еще может использоваться бухгалтерией для решения в будущем подъема / срезания капитала отдела. Ну и так далее. Это я к тому, что вряд ли получится выкинуть и бумажный вариант, и таблицу. Более того, стремление к какой-то непонятной внутренней красоте с убиранием полезной и удобной информации как по мне просто показатель непонимания как это будет использоваться. Попросту говоря, это приводит к усложнению работы бухгалтерии на стороне клиента. А с учетом того, что кроме этой, собственно, бухгалтерии и аудиторам, которые в эту бухгалтерию ходят, эта вещь вообще мало кому уперлась, это просто некрасиво.
Да, я могу заблуждаться и может оказаться что таблица действительно с расшифровкой никому не нужна. Но что-то мне подсказывает, что если вы её уберете, она перестанет казаться никому не нужной.
Так задумано. Именно, чтобы можно было автоматически парсить пользовательские назначения платежа с ошибками
Это обязательно породит кучу путаницы вокруг "что из этого день, а что месяц". Пишите в timestamp, чего уж мелочиться :)
Есть принятые стандарты (типографии, в данном случае), и если есть техническая возможность следовать им, почему нет? Именно такие мелочи делают ощущение несерьезности к подходу. Пока по верстке, разным форматам, кавычкам, отступам, вертикальному гриду и прочему складывается ощущение что это делал джун разработчик и дизайнера никто даже проверить не просил. И, тем более, никто не носил это в свою же бухгалтерию, послушать что они скажут.
Шаг ли это вреперд по сравнению со стандартными формами? Мне кажется, что нет, и что это огромный прыжок назад: все привыкли к стандартным формам, и пусть они некрасивые, они делалить теми и для тех, кто их будет читать и кто привык к ним, и изменять это в сторону красивого очень супер сложно. Это как если бы человек без навыков программирования пришел рисовать мне как должна выглядеть IDE.
Вот пример: где я живу, тут всегда одинаковые счета-фактуры. Я всегда знаю что в нижнем правом углу есть банкгиро код, слева от него ОКР номер, сумма под табличкой справа. Если кто присылает в другом формате — ставит меня в тупик. Даже если это будет супер красиво, мне нужно будет искать глазами где что и как и будет бесить, пусть листок будет самым красивым в мире с позолотой.
P.S. Только что подумал, что довольно вероятным использованием является подшивание в папку и пролистывание разных фактур для быстрого поиска по счету оплаты с целью "за что мы заплатили 100500 рублей". Теперь попробуйте распечатать свою форму, сшить её как принято в России (за левый корешок, там еще, к слову, в вашем логотипе дырку сделают хах), и быстро найти счет?
P.P.S. Хорошо, похоже кавычки победили, на елочки все забили.
Помню во времена лимитированных тарифов был у меня тариф на 70 Мб у Мегафона. И решил я посмотреть выписку по счету за последние пол года кажется. Прилетела HTML на полтора метра у которого в каждой строчке была копипаста одного и того же стиля на все сколько-то там сотен строчек. Так что HTML тоже далеко не панацея если в штате нет оптимизаторов.
PDF это стандарт? Ну видимо стандарт это интересный значит "стандарт".
Бизнес-договор (Как ИП) с одним из операторов сотовой связи. Счет приходит.
Нечитаемый штатными средствами (Preview.app) macOS.
На вопрос "какого и куда собственно платить?" ответ был что ну поставьте Adobe Acrobat Reader. Правда также сказали что можно взять номер л/с и оплатить по нему.
Интересно, если пойти на принцип и сказать что пришлите читаемое, тогда оплачу (а Acrobat'а нет и не будет потому что лицензия не понравилась) то что бы было? -:)
PDF - программа для PDF Viewer-а, HTML - программа для браузера, PS - программа для принтера, ASCII - программа для терминала (ну и для принтера, он тоже терминал).
Ни одно из них не идеально для получения идентичной A4 на всех клиентах.
Chromium одинаково хорошо показывает как PDF так и HTML (зависит от того как сверстали). Если не устраивает функциональность или жирность имеющегося генератора счетов и все разработчики в команде full-stack-developers, то конечно проще перефигачить на технологии, которой все умеют пользоваться. Но это не значит, что PDF - говно.
Как мне кажется, стандартный счёт 1с куда как более читабелен чем ваш вариант.
клонтитулы всё портят...
PDF развивался как стандарт, когда HTML браузеры рендерили кто в лес, а кто по дрова и знать как у клиента будет выглядеть в его IE6 твой HTML было никак невозможно. Вот тогда и начали продвигать PDF, который по стандарту должен выглядеть у всех одинаково и что немаловажно, одинаково и на экране и на печати, чего HTML не гарантирует совсем.
А сейчас я работаю над новой no-code платформой, думал предусмотреть там генерацию pdf по такому же принципу, вместо корявых и устаревших офисных форматов, пожалуй, стоит всё-таки начать с HTML. Спасибо, что навели на эту мысль. HTML для печати я как-то даже не рассматривал, а зря, наверно.
Счёт может быть красивым и в HTML, а не в PDF