Бланк строгой отчетности это: Бланки строгой отчетности (БСО) для ИП и ООО в 2020 году

Кто имеет право вести работу без применения кассы

Законодательство ограничивает круг организаций, которые имеют право работать без применения контрольно-кассовой техники, но при этом он все равно достаточно широк. В частности, осуществлять деятельность без использования кассы могут:

• индивидуальные предприниматели,
• предприятия, предоставляющие услуги населению
• компании, организующие питание в школах, торговлю в киосках, прием стеклотары, продажу непродуктовых товаров на рынках, выставках, ярмарках и т.п.

Если организация воспользовалась правом работы без контрольно-кассовой техники, она должна пользоваться бланками строгой отчетности.

Что это такое бланки и для чего они нужны

Под бланками строгой отчетности подразумеваются квитанции, которые удостоверяют факт принятия денежных средств от физических лиц. Каждый бланк всегда имеет два экземпляра:

• один после заполнения отдается клиенту,
• второй остается в организации.

Бланки актуальны только при наличных расчетах, при безналичных перечислениях использование таких бланков невозможно, как в отношениях между юридическими лицами.

По своей сути бланки являются альтернативой кассовому чеку. При этом использование бланков наиболее интересно небольшим компаниям, поскольку они позволяют экономить средства, которые затрачиваются на покупку и обслуживание контрольно-кассовой техники.

Бланки обычно покупаются в специализированных магазинах, разрабатываются организациями самостоятельно или печатаются в типографиях определенными тиражами. Все бланки входят в тираж в определенной хронологии, нумеруются и регистрируются в книге учета.

Что нужно заносить в книгу

В данный документ вносят всю информацию, касающуюся бланков, в том числе их прихода (покупных или распечатанных) и расхода (использованных по назначению или испорченных, недостоверных, списанных).

Представители некоторых организаций ошибочно полагают, что в книгу учета бланков надо вносить информацию по поступлению и расходу денежных средств, в том числе конкретных суммы. Это не так.

Сюда вписываются только данные о перемещениях бланков (получение в типографии, регистрация распечатанных внутренних шаблонов, выдача материально-ответственным работникам и т.д.) и их количестве.

А все, что касается денег, полученных при их использовании, вносится в другой документ – книгу учета доходов и расходов.

С какой периодичностью нужно менять книгу

Обычно книга учета бланков строгой отчетности имеет ограниченный срок действия – например, она может использоваться в течение года или определенного налогового периода.

Норма о сроке действия устанавливается в индивидуальном порядке директором предприятия.

После того, как текущая книга будет закрыта, создается новый документ.

Что будет, если обойтись без книги

Если компания применяет бланки строгой отчетности, то она в обязательном порядке должна вести и книгу их учета. Отсутствие этого документа в случае проверки налоговыми инспекторами может привести к крупным штрафным санкциям в отношении предприятия и должностных лиц – директора и главного бухгалтера.

Составление книги учета

Единой, обязательной к применению, формы книги учета бланков строгой отчетности на сегодняшний день не существует. Организации вправе разрабатывать ее самостоятельно или пользоваться унифицированным шаблоном, ранее рекомендованным к использованию (форма 0504045). Второй вариант хорош тем, что не нужно ломать голову над структурой и содержанием книги – все необходимые данные в неё уже включены.

Заполнение книги учёта бланков строгой отчетности

1. В документ по порядку вносятся:
   • дата открытия книги и закрытия (в нужное время),
   • наименование организации,
   • ее код по ОКПО,
   • название бланка (квитанция, товарный чек и т.п.),
   • условная цена за единицу в рублях,
   • номер счета, по которому проходят средства,
   • код формы.
2. Далее идет основная часть, в которой расположена таблица из нескольких столбцов и строк. В нее вписываются:
   • дата внесения данных,
   • от кого получены бланки или кому выданы (название организации или ФИО физического лица),
   • название документа, послужившим основанием для их принятия или выдачи.
3. Затем идут графы «приход» и «расход» — сюда вносится информация о бланках, поступивших в организацию, истраченных и списанных, а в завершение вписывается остаток.
4. Также в книге должно поставить свою подпись лицо, передавшее бланки или получившее их на руки.

Оформление книги

Книга учета бланков обычно содержит большое количество листов. Их нужно скреплять степлером или прочной суровой нитью и пронумеровывать, таким образом, чтобы получился журнал или брошюра.

Заверять документ при помощи печати или штампа нужно только в том случае, если применение штемпельных изделий закреплено в локальных нормативно-правовых актах фирмы.

Допустимы ли ошибки и исправления

При внесении сведений о бланках в книгу учета не рекомендуется допускать ошибки и исправления, а уж тем более нельзя вносить в форму заведомо ложную или недостоверную информацию.

Если при заполнении книги всё же были допущены какие-то неточности, их следует аккуратно зачеркнуть, внести скорректированные данные, написать фразу «исправленному верить», поставить печать организации, дату и подпись ответственного за ведение книги сотрудника.

Как и сколько времени хранить документ

В период действия книга должна находиться под рукой специалиста отдела бухгалтерии. После того, как в нее будет внесена последняя запись, ее необходимо хранить не менее пяти лет или период, установленный внутренними нормативными актами компании (но не меньше законодательно установленного срока).

Что относится к бланкам строгой отчетности

Подборка наиболее важных документов по запросу Что относится к бланкам строгой отчетности (нормативно–правовые акты, формы, статьи, консультации экспертов и многое другое).

Статьи, комментарии, ответы на вопросы: Что относится к бланкам строгой отчетности

Нормативные акты: Что относится к бланкам строгой отчетности

Все о бланках строгой отчетности (БСО)

Дата публикации: 01 декабря 2011.

Требования к бланкам строгой отчетности

Бланк строгой отчетности является первичным учетным документом, на основании которого оформляются операции с денежными средствами.

В соответствии с п. 1 ст. 2 Федерального закона от 22.05.03 №54-ФЗ «О применении контрольно-кассовой техники при осуществлении наличных денежных расчетов и (или) расчетов с использованием платежных карт» все организации при осуществлении наличных денежных расчетов или расчетов с использованием платежных карт при продаже товаров (работ, услуг) обязаны применять контрольно-кассовую технику (ККТ).

Однако это требование имеет ряд исключений. Организации и индивидуальные предприниматели могут осуществлять наличные денежные расчеты и (или) расчеты с использованием платежных карт без применения ККТ, в следующих случаях:

1. В силу специфики своей деятельности при осуществлении видов деятельности, указанных в п. 3 ст. 2 Закона №54-ФЗ, например таких как: продажа газет и журналов, проездных билетов и талонов в общественном транспорте, торговля в киосках мороженым и безалкогольными напитками в розлив и другие виды деятельности, перечень которых является закрытым.
2. В силу особенностей своего местонахождения. Организации и предприниматели, находящиеся в отдаленных или труднодоступных местностях, а также аптечные организации и обособленные подразделения, находящиеся в фельдшерских и фельдшерско-акушерских пунктах, расположенных в сельских поселениях, в которых отсутствуют аптечные организации.
3. При оказании услуг населению при условии выдачи ими соответствующих бланков строгой отчетности.
4. При осуществлении плательщиком ЕНВД деятельности, которая не подпадает под действие предыдущих пунктов, при условии выдачи по требованию покупателя (клиента) документа (товарного чека, квитанции или другого документа, подтверждающего прием денежных средств). Документ выдается в момент получения денежных средств и должен содержать реквизиты, установленные законом. К таким видам деятельности относится, например, розничная торговля, оказание услуг организациям по ремонту, техобслуживанию и мойке автотранспортных средств.

Порядок расчетов с использованием БСО

Организации или индивидуальные предприниматели, оказывающие услуги населению, вправе отказаться от применения ККТ, в этом случае они обязаны при расчете наличными денежными средствами выдавать бланки строгой отчетности (БСО). Принадлежность вида деятельности к услугам населению определяется в соответствии с Общероссийским классификатором услуг населению ОК 002-93 (ОКУН), утвержденным Постановлением Госстандарта России от 28.06.93 №163. Классификатор включает в себя следующие виды услуг:
01 – бытовые услуги;
02 – услуги пассажирского транспорта;
03 – услуги связи;
04 – жилищно-коммунальные услуги;
05 – услуги учреждений культуры;
06 – туристские и экскурсионные услуги;
07 – услуги физической культуры и спорта;
08 – медицинские, санаторные-оздоровительные, ветеринарные услуги;
09 – услуги правового характера, оказываемые нотариусами и адвокатами;
10 – услуги банков;
11 – услуги в системе образования;
12 – услуги торговли и общественного питания, услуги рынков;
80 – прочие услуги населению, к ним относятся: услуги по финансовому посредничеству, страхованию, услуги в области рекламы, по охране жилищ и пр.

Порядок утверждения форм бланков строгой отчетности, приравненных к кассовым чекам, порядок их учета, хранения и уничтожения установлен Положением об осуществлении наличных денежных расчетов и (или) расчетов с использованием платежных карт без применения контрольно-кассовой техники, утвержденным Постановлением Правительства РФ от 06.05.08 №359 (далее — Положение).

В отношении отдельных видов услуг БСО разрабатывают и утверждают федеральные органы исполнительной власти. Если форма бланка уже разработана и утверждена, то необходимо использовать именно ее. Если же формы нет, то  организации и индивидуальные предприниматели вправе самостоятельно разработать форму БСО, которая должна содержать все обязательные реквизиты.

К обязательным реквизитам бланков строгой отчетности относятся:

• наименование документа, шестизначный номер и серия;
• наименование и организационно-правовая форма организации,  Ф.И.О. индивидуального предпринимателя;
• место нахождения постоянно действующего исполнительного органа юридического лица, в случае его отсутствия  – иного органа или лица, имеющих право действовать от имени юридического лица без доверенности;
• ИНН организации или индивидуального предпринимателя, выдавших документ;
• вид услуги;
• стоимость услуги в денежном выражении;
• размер оплаты;
• дата осуществления расчета и составления документа;
• должность, Ф. И. О. лица, ответственного за совершение операции и правильность ее оформления, его личная подпись, печать организации;

Внешний вид бланка, форму, шрифт, цвет организация вправе определить самостоятельно, а также указать дополнительные реквизиты, характеризующие специфику оказываемой услуги, допускается и художественное оформление (Письма УФНС России по г. Москве от 12.07.09 №17-15/022192, от 02.03.09 №17-15/19792).

Особое внимание следует обратить на то, что БСО также является и первичным учетным документом, на основании которого оформляются операции с денежными средствами, в связи с этим он должен отвечать требованиям ст. 9 Закона от 21.11.96 №129-ФЗ. Бланки строгой отчетности должны заполняться четко и разборчиво, без исправлений. Испорченные бланки перечеркиваются  и прилагаются к книге учета бланков за тот день, в котором они были заполнены.

Изготовление БСО

Бланки строгой отчетности могут быть изготовлены двумя способами: типографским или с использованием автоматизированных систем.
На типографском бланке обязательно должны быть указаны сведения об изготовителе (наименование, ИНН, место нахождения, номер и год выполнения заказа, тираж). При заполнении бланка должно быть обеспечено оформление не менее одной копии бланка, либо он может иметь отрывные части.

Формирование бланков с использованием автоматизированной системы на данный момент времени представляет определенные сложности. Официальных разъяснений, что же считать такой системой, нет. В Положении указано, что автоматизированная система должна:

• иметь защиту от несанкционированного доступа;
• идентифицировать, фиксировать и сохранять все операции с БСО не менее 5 лет;
• сохранять номер и серию бланка.

По мнению контролирующих органов система должна отвечать требованиям, предъявляемым к ККТ. Компьютер не подходит для изготовления бланков, т.к. не обеспечивает защиту, фиксацию и хранение сведений о бланке. По вопросам применения автоматизированной системы изготовления бланков строгой отчетности Минфин рекомендует обращаться в Министерство промышленности и торговли (Письмо от 06.03.09 №03-01-15/2-96).

Хранение и учет БСО

Бланки строгой отчетности принимаются сотрудником, с которым заключен договор о полной материальной ответственности. Он занимается хранением, учетом и выдачей бланков, а также приемом от населения наличных денежных средств.
Поступившие бланки принимаются материально-ответственным лицом в присутствии комиссии, созданной руководителем организации, в день их поступления. Комиссия должна проверить соответствие фактического количества, серий, номеров с данными, указанными  в сопроводительных документах. По итогам проверки составляется акт приемки бланков строгой отчетности. Акт, утвержденный руководителем, будет являться основанием для принятия БСО к учету. Учет бланков ведется на счете 006 «Бланки строгой отчетности».
Ответственное лицо заносит приход в книгу учета бланков строгой отчетности. В этой книге бланки учитываются по наименованиям, сериям, номерам, местам хранения, с указанием даты их получения и выдачи, а также по количеству, стоимости и материально-ответственным лицам. Листы книги должны быть пронумерованы, прошнурованы, подписаны руководителем и главным бухгалтером и скреплены печатью.

Унифицированной формы книги учета бланков строгой отчетности не существует, поэтому организация или индивидуальный предприниматель самостоятельно разрабатывают и утверждают ее форму. За образец можно взять Книгу учета бланков строгой отчетности, приведенную в Приказе Минфина РФ от 15.12.10 №173н «Об утверждении форм первичных учетных документов и регистров бухгалтерского учета, применяемых органами государственной власти (государственными органами), органами местного самоуправления, органами управления государственными внебюджетными фондами, государственными академиями наук, государственными (муниципальными) учреждениями и Методических указаний по их применению».

Бланки строгой отчетности нужно хранить в металлических шкафах, сейфах, либо в специальных помещениях, исключающих их порчу, утерю и хищение. В конце каждого рабочего дня место хранения бланков должно быть опломбировано или опечатано.
Инвентаризацию бланков проводят одновременно с инвентаризацией наличных денежных средств в кассе.
Копии и корешки использованных и испорченных бланков должны хранится в систематизированном виде, в упакованных и опечатанных мешках не менее 5 лет. По окончании срока хранения, но не ранее месяца со дня последней инвентаризации, копии бланков уничтожаются. Для этого руководителем создается комиссия и составляется акт об уничтожении бланков. В акте в обязательном порядке указывается состав комиссии, дата и номер документа, которым назначена комиссия, период списания, перечень списываемых бланков с отражением их серий, номеров и причины списания. Испорченные бланки уничтожаются в аналогичном порядке.

Выдача бланков строгой отчетности — новый порядок работы 2020

Соглашение о конфиденциальности

и обработке персональных данных

1.Общие положения

1.1.Настоящее соглашение о конфиденциальности и обработке персональных данных (далее – Соглашение) принято свободно и своей волей, действует в отношении всей информации, которую ООО «Инсейлс Рус» и/или его аффилированные лица, включая все лица, входящие в одну группу с ООО «Инсейлс Рус» (в том числе ООО «ЕКАМ сервис»), могут получить о Пользователе во время использования им любого из сайтов, сервисов, служб, программ для ЭВМ, продуктов или услуг ООО «Инсейлс Рус» (далее – Сервисы) и в ходе исполнения ООО «Инсейлс Рус» любых соглашений и договоров с Пользователем. Согласие Пользователя с Соглашением, выраженное им в рамках отношений с одним из перечисленных лиц, распространяется на все остальные перечисленные лица.

1.2.Использование Сервисов означает согласие Пользователя с настоящим Соглашением и указанными в нем условиями; в случае несогласия с этими условиями Пользователь должен воздержаться от использования Сервисов.

1.3.Сторонами (далее – «Стороны) настоящего Соглашения являются:

«Инсейлс» – Общество с ограниченной ответственностью «Инсейлс Рус», ОГРН 1117746506514, ИНН 7714843760, КПП  771401001, зарегистрированное по адресу: 125319, г.Москва, ул.Академика Ильюшина, д.4, корп.1, офис 11 (далее — «Инсейлс»), с одной стороны, и

«Пользователь» –

либо физическое лицо, обладающее дееспособностью и признаваемое участником гражданских правоотношений в соответствии с законодательством Российской Федерации;

либо юридическое лицо, зарегистрированное в соответствии с законодательством государства, резидентом которого является такое лицо;

либо индивидуальный предприниматель, зарегистрированный в соответствии с законодательством государства, резидентом которого является такое лицо;

которое приняло условия настоящего Соглашения.

1.4.Для целей настоящего Соглашения Стороны определили, что конфиденциальная информация – это сведения любого характера (производственные, технические, экономические, организационные и другие), в том числе о результатах интеллектуальной деятельности, а также сведения о способах осуществления профессиональной деятельности (включая, но не ограничиваясь: информацию о продукции, работах и услугах; сведения о технологиях и научно-исследовательских работах; данные о технических системах и оборудовании, включая элементы программного обеспечения; деловые прогнозы и сведения о предполагаемых покупках; требования и спецификации конкретных партнеров и потенциальных партнеров; информацию, относящуюся к интеллектуальной собственности, а также планы и технологии, относящиеся ко всему перечисленному выше), сообщаемые одной стороной другой стороне в письменной и/или электронной форме, явно обозначенные Стороной как ее конфиденциальная информация.

1.5.Целью настоящего Соглашения является защита конфиденциальной информации, которой Стороны будут обмениваться в ходе переговоров, заключения договоров и исполнения обязательств, а равно любого иного взаимодействия (включая, но не ограничиваясь, консультирование, запрос и предоставление информации, и выполнение иных поручений).

2.Обязанности Сторон

2.1.Стороны соглашаются сохранять в тайне всю конфиденциальную информацию, полученную одной Стороной от другой Стороны при взаимодействии Сторон, не раскрывать, не разглашать, не обнародовать или иным способом не предоставлять такую информацию какой-либо третьей стороне без предварительного письменного разрешения другой Стороны, за исключением случаев, указанных в действующем законодательстве, когда предоставление такой информации является обязанностью Сторон.

2.2.Каждая из Сторон предпримет все необходимые меры для защиты конфиденциальной информации как минимум с применением тех же мер, которые Сторона применяет для защиты собственной конфиденциальной информации. Доступ к конфиденциальной информации предоставляется только тем сотрудникам каждой из Сторон, которым он обоснованно необходим для выполнения служебных обязанностей по исполнению настоящего Соглашения.

2.3.Обязательство по сохранению в тайне конфиденциальной информации действительно в пределах срока действия настоящего Соглашения, лицензионного договора на программы для ЭВМ от 01.12.2016г., договора присоединения к лицензионному договору на программы для ЭВМ, агентских и иных договоров и в течение пяти лет после прекращения их действия, если Сторонами отдельно не будет оговорено иное.

2.4.Не будут считаться нарушением настоящего Соглашения следующие случаи:

(а)если предоставленная информация стала общедоступной без нарушения обязательств одной из Сторон; 

(б)если предоставленная информация стала известна Стороне в результате ее собственных исследований, систематических наблюдений или иной деятельности, осуществленной без использования конфиденциальной информации, полученной от другой Стороны;

(в)если предоставленная информация правомерно получена от третьей стороны без обязательства о сохранении ее в тайне до ее предоставления одной из Сторон; 

(г)если информация предоставлена по письменному запросу органа государственной власти, иного государственного органа,  или органа местного самоуправления в целях выполнения их функций и ее раскрытие этим органам обязательно для Стороны. При этом Сторона должна незамедлительно известить другую Сторону о поступившем запросе;

(д)если информация предоставлена третьему лицу с согласия той Стороны, информация о которой передается.

2.5.Инсейлс не проверяет достоверность информации, предоставляемой Пользователем, и не имеет возможности оценивать его дееспособность.

2.6.Информация, которую Пользователь предоставляет Инсейлс при регистрации в Сервисах, не является персональными данными, как они определены в Федеральном законе РФ №152-ФЗ от 27.07.2006г. «О персональных данных».

2.7.Инсейлс имеет право вносить изменения в настоящее Соглашение. При внесении изменений в актуальной редакции указывается дата последнего обновления. Новая редакция Соглашения вступает в силу с момента ее размещения, если иное не предусмотрено новой редакцией Соглашения.

2.8.Принимая данное Соглашение Пользователь осознает и соглашается с тем, что Инсейлс может отправлять Пользователю персонализированные сообщения и информацию (включая, но не ограничиваясь) для повышения качества Сервисов, для разработки новых продуктов, для создания и отправки Пользователю персональных предложений, для информирования Пользователя об изменениях в Тарифных планах и обновлениях, для направления Пользователю маркетинговых материалов по тематике Сервисов, для защиты Сервисов и Пользователей и в других целях.

Пользователь имеет право отказаться от получения вышеуказанной информации, сообщив об этом письменно на адрес электронной почты Инсейлс — [email protected].

2.9.Принимая данное Соглашение, Пользователь осознает и соглашается с тем, что Сервисами Инсейлс для обеспечения работоспособности Сервисов в целом или их отдельных функций в частности могут использоваться файлы cookie, счетчики, иные технологии и Пользователь не имеет претензий к Инсейлс в связи с этим.

2.10.Пользователь осознает, что оборудование и программное обеспечение, используемые им для посещения сайтов в сети интернет могут обладать функцией запрещения операций с файлами cookie (для любых сайтов или для определенных сайтов), а также удаления ранее полученных файлов cookie.

Инсейлс вправе установить, что предоставление определенного Сервиса возможно лишь при условии, что прием и получение файлов cookie разрешены Пользователем.

2.11.Пользователь самостоятельно несет ответственность за безопасность выбранных им средств для доступа к учетной записи, а также самостоятельно обеспечивает их конфиденциальность. Пользователь самостоятельно несет ответственность за все действия (а также их последствия) в рамках или с использованием Сервисов под учетной записью Пользователя, включая случаи добровольной передачи Пользователем данных для доступа к учетной записи Пользователя третьим лицам на любых условиях (в том числе по договорам или соглашениям). При этом все действия в рамках или с использованием Сервисов под учетной записью Пользователя считаются произведенными самим Пользователем, за исключением случаев, когда Пользователь уведомил Инсейлс о несанкционированном доступе к Сервисам с использованием учетной записи Пользователя и/или о любом нарушении (подозрениях о нарушении) конфиденциальности своих средств доступа к учетной записи.

2.12.Пользователь обязан немедленно уведомить Инсейлс о любом случае несанкционированного (не разрешенного Пользователем) доступа к Сервисам с использованием учетной записи Пользователя и/или о любом нарушении (подозрениях о нарушении) конфиденциальности своих средств доступа к учетной записи. В целях безопасности, Пользователь обязан самостоятельно осуществлять безопасное завершение работы под своей учетной записью по окончании каждой сессии работы с Сервисами. Инсейлс не отвечает за возможную потерю или порчу данных, а также другие последствия любого характера, которые могут произойти из-за нарушения Пользователем положений этой части Соглашения.

3.Ответственность Сторон

3.1.Сторона, нарушившая предусмотренные Соглашением обязательства в отношении охраны конфиденциальной информации, переданной по Соглашению, обязана возместить по требованию пострадавшей Стороны реальный ущерб, причиненный таким нарушением условий Соглашения в соответствии с действующим законодательством Российской Федерации.

3.2.Возмещение ущерба не прекращают обязанности нарушившей Стороны по надлежащему исполнению обязательств по Соглашению.

4.Иные положения

4.1.Все уведомления, запросы, требования и иная корреспонденция в рамках настоящего Соглашения, в том числе включающие конфиденциальную информацию, должны оформляться в письменной форме и вручаться лично или через курьера, или направляться по электронной почте адресам, указанным в лицензионном договоре на программы для ЭВМ от 01.12.2016г., договоре присоединения к лицензионному договору на программы для ЭВМ и в настоящем Соглашении или другим адресам, которые могут быть в дальнейшем письменно указаны Стороной.

4.2.Если одно или несколько положений (условий) настоящего Соглашения являются либо становятся недействительными, то это не может служить причиной для прекращения действия других положений (условий).

4.3.К настоящему Соглашению и отношениям между Пользователем и Инсейлс, возникающим в связи с применением Соглашения, подлежит применению право Российской Федерации.

4.3.Все предложения или вопросы по поводу настоящего Соглашения Пользователь вправе направлять в Службу поддержки пользователей Инсейлс www.ekam.ru либо по почтовому адресу: 107078, г. Москва, ул. Новорязанская, 18, стр.11-12 БЦ «Stendhal» ООО «Инсейлс Рус».

Дата публикации: 01.12.2016г.

Полное наименование на русском языке:

Общество с ограниченной ответственностью «Инсейлс Рус»

Сокращенное наименование на русском языке:

ООО «Инсейлс Рус»

Наименование на английском языке:

InSales Rus Limited Liability Company (InSales Rus LLC)

Юридический адрес:

125319, г. Москва, ул. Академика Ильюшина, д. 4, корп.1, офис 11

Почтовый адрес:

107078, г. Москва, ул. Новорязанская, 18, стр.11-12, БЦ «Stendhal»

ИНН: 7714843760 КПП: 771401001

Банковские реквизиты:

Р/с 40702810600001004854

В ИНГ БАНК (ЕВРАЗИЯ) АО, г.Москва,
к/с 30101810500000000222, БИК 044525222

Электронная почта: [email protected]

Контактный телефон: +7(495)133-20-43

БСО (бланк строгой отчетности) — что это такое? Образцы для ИП и ООО при УСН и ЕНВД

Не все предприниматели обязаны использовать кассовый аппарат и платить за его обслуживание до 10 тысяч в год. Есть иной способ подтверждать факт приема наличных денег, и он будет особенно полезен малым предпринимателям. Подробнее о бланках строгой отчетности читайте в этой статье.

[box type=”download”] БСО (бланк строгой отчетности) – это в первую очередь документ, который, выступая альтернативой кассовому чеку, подтверждает факт приема денежных средств от населения.[/box]

Существует определенный перечень видов деятельности, занимаясь которыми предприниматель или организация не обязаны предоставлять кассовый чек. Основное сходство этих видов состоит в том, что предприниматель или организация работают напрямую с населением. Самый часто встречающийся бланк строгой отчетности – это обычный проездной билет в автобусе.

Важно: оказываемые услуги должны быть в перечне ОКУН – Общероссийский классификатор услуг населения.

В этом случае предприниматель или организация не используют кассовый аппарат, экономя не более 15 тысяч в год. Сюда входит стоимость самого кассового аппарата и обязательного элемента – ЭКЛЗ (электронная контрольная лента защищенная). Основные расходы идут лишь на печать бланков строгой отчетности.

[box type=”download”] Если расчет осуществляется между организациями, БСО использовать нельзя. Единственное исключение сделано лишь для расчетов между индивидуальными предпринимателями. Такое решение принял Верховный арбитражный суд (Постановление Пленума ВАС РФ от 31.07.2003 №16).[/box]

Где применяют?

Встретить бланки строгой отчетности можно в разных местах. Часто, используются БСО в качестве товарного чека при покупке в магазине. На них оформляют проездные документы, билеты, талоны и путевки. В разных сферах экономики эти документы используют с разными целями.

Соответственно отличается и внешний вид бланков. Например, вид железнодорожного билета закрепило отдельное ведомство – Министерство транспорта России, а форму экскурсионной путевки – Министерство культуры.

Форма

Предприниматель имеет право самостоятельно разработать ту форму бланка, которая будет удовлетворять его запросы при ведении операционно-хозяйственной деятельности.

При этом он должен соблюдать определенный перечень инструкций:

• бланк должен иметь название, номер из 6 цифр и уникальную серию;
• если бланк принадлежит организации – на документе требуется указать наименование и организационно-правовую форму;
• если бланк принадлежит ИП – нужно указать на нем полные ФИО предпринимателя;
• место нахождения постоянно действующего исполнительного органа;
• индивидуальный налоговый номер организации или предпринимателя;
• вид услуги или название товара;
• стоимость единицы услуги или товара в денежном выражении;
• размер оплаты;
• дату осуществления расчета и составления документа;
• полные ФИО и должность человека, ответственного за совершение операции и правильность оформления, его личную подпись и печать;
• иные реквизиты, которые предприниматель или организация вправе нанести на документ;

Образцы для ИП и ООО

[box type=”download”] Скачать образец БСО для ИП в формате .doc (Word) [/box]

[box type=”download”] Скачать образец БСО для ООО в формате .xlsx (Word) [/box]

Где взять бланки?

Существуют различные способы изготовления бланков строгой отчетности, но наиболее широко распространен метод типографской печати. Выполнить заказ имеет право любая типография, но при этом она должна соблюсти ряд условий. Обязательно документ должен содержать основные сведения о компании, изготовившей бланк. Серию и номер каждого бланка типография проставляет самостоятельно.

Предприниматель или организация могут задать серию бланков самостоятельно, выбрав ту цифровую или буквенную комбинацию, которая удовлетворяет запросам компании. Если бланки заказываются в разных типографиях, то можно добавить букву типографии в серию бланка.

При этом следует придерживаться правила: новый заказ – новая серия. Это обеспечит абсолютную уникальность каждого бланка, где серия будет постоянно меняться, а номер бланка станет его порядковым номером.

Существует еще один вариант изготовления бланков. Их можно распечатать самостоятельно на специальном контрольно-кассовом аппарате. При этом регистрировать его в налоговой службе не нужно. Стоит понимать, что бланк строгой отчетности, изготовленный на бытовом принтере, не будет иметь силы.

Как заполнять?

1. Бланк требуется заполнять вручную, четко и разборчиво. Запрещено вносить исправления в документ, в этом случае он становится недействительным. Если была допущена ошибка при заполнении, то бланк перечеркивается. После этого документ нужно приложить к книге учета бланков.
2. При заполнении документа обязательно требуется создать не менее одной копии. Современные бланки имеют в своем составе два листа: один отрывной, который получает клиент, а второй, информация на который переносится методом копирования, остается в организации.

[box type=”download”] Бланки можно заполнять и с помощью специальной автоматизированной системы. Правда ее стоимость довольно высока и требования к ней весьма жесткие.[/box]

Программное обеспечение обязательно должно:

1. Иметь защиту от несанкционированного доступа.
2. Хранить все операции не менее пяти лет.
3. Сохранять уникальный номер и серию бланка.

Как вести учет?

Одно из важнейших требований, которое обязаны соблюдать предприниматели и организации, использующие бланки строгой отчетности, это их обязательный учет. Он осуществляется с помощью уникальных серий и номера каждого бланка. Все операции с бланками: поступление, списание, учет и прочее отражаются в специальной книге учета.

Унифицированной формы книги учета бланков строгой отчетности не существует. Предприниматель вправе самостоятельно разработать такую форму. Необходимо только, чтобы она объективно отражала все операции с бланками.

Копии бланков и корешки обязательно нужно хранить не менее 5 лет. После этого предприниматель и организация имеют право их утилизировать на основании специального акта об уничтожении.

БСО при УСН и ЕНВД

Зачастую бланки строгой отчетности используют предприниматели на упрощенной форме налогообложения. В этом случае определение налоговой базы осуществляется путем подсчета сумм, принятых наличным путем и с помощью электронных карт, которые отражены в кассовой книге и по копиям бланков.

Будьте готовы к тому, что представители налоговой инспекции во время камеральной проверки будут пересчитывать корешки и копии выписанных бланков. Если суммы по ним не совпадут с величиной выручки, проведенной по кассе, возникнут вопросы.

Предпринимателям, работающим на вмененной форме налогообложения (ЕНВД), в этом отношении намного проще, они платят фиксированный налог, вычисляемый по физическим показателям (площадь магазина, количество работников и т.д.). В этом случае бланки строгой отчетности помогают грамотно вести бухгалтерию. Также предприниматели предоставляют их по требованию покупателя.

Ответственность

Если предприниматель освобожден от применения контрольно-кассовой техники, но при этом не использует бланки строгой отчетности, он может быть привлечен к административной ответственности: штраф от 1 500 до 2 000 на граждан, от 3 000 до 4 000 на должностных лиц и в 10 раз больше – от 30 000 до 40 000 на юридических лиц.

Бланки строгой отчетности позволяют некоторым категориям предпринимателей и организация снизить расходы на приобретение, установку и обслуживание ККТ. При этом обязательно должны соблюдаться правила печати, заполнения и учета таких бланков.

Статья была полезна?

0,00 (оценок: 0)

Политика безопасности контента, уровень 3

2. Framework

2.1. Инфраструктура

В этом документе для определения синтаксиса используется грамматика ABNF, как определено в [RFC5234]. Он также полагается на расширение #rule ABNF, определенное в разделе 7 [RFC7230], с модификацией, в которой OWS заменяется на optional-ascii-whitespace. То есть #rule , используемое в этом документ определяется как:

 1 # element => element * (optional-ascii-whitespace "," optional-ascii-whitespace элемент)
 

и для n> = 1 и m> 1:

  #  element => element  *  (optional-ascii-whitespace "," optional-ascii-whitespace элемент)
 

Данный документ зависит от стандарта Infra Standard по ряду основополагающих концепций, используемых в его алгоритмы и проза [ИНФРА].

Следующие определения используются для улучшения читаемости других определений в этом документе.

  необязательный-ascii-whitespace  = * (% x09 /% x0A /% x0C /% x0D /% x20)
  required-ascii-whitespace  = 1 * (% x09 /% x0A /% x0C /% x0D /% x20)
; Эти продукты соответствуют определению пробелов ASCII из стандарта INFRA.
 

2.2. Политики

Политика определяет разрешенные и ограниченное поведение, и может применяться к Document , WorkerGlobalScope или WorkletGlobalScope , как описано в §4.2.2 Инициализируйте список CSP глобального объекта и в §4.2.1 Инициализируйте список CSP документа.

Каждая политика имеет связанный набор директив , который является упорядоченным набор директив, определяющих последствия применения политики.

С каждой политикой связано расположение , которое либо « принудительно применять » или « сообщать ».

Каждая политика имеет связанный источник , который является либо « заголовок » или « мета «.

К одному ресурсу можно применить несколько политик, которые собираются в список политик, известный как список CSP .

Список CSP, если он содержит политику, источником которой является « заголовок ».

Сериализованный код CSP — это строка ASCII, состоящая из разделенных точкой с запятой серия сериализованных директив, соответствующих следующей грамматике ABNF [RFC5234]:

  сериализованная политика  =
    сериализованная-директива * (необязательная-ascii-whitespace ";" [необязательная-сериализованная-директива-ascii-пробела])
 

Сериализованный список CSP — это строка ASCII, состоящая из разделенных запятыми серия сериализованных CSP, придерживающихся следующей грамматики ABNF [RFC5234]:

  список сериализованных политик  = 1 # сериализованных политик
                    ; Правило '#' определено в разделе 7 RFC 7230.
                    ; но он включает указанные модификации
                    ; в разделе 2.1 этого документа.
 

2.2.1. Разбор сериализованного CSP

Чтобы проанализировать сериализованный CSP , учитывая сериализованный CSP (, сериализованный ), источник (, источник ) и расположение (, расположение ), выполните следующие шаги.

Этот алгоритм возвращает объект политики безопасности содержимого. Если сериализован, не может быть проанализирован, набор директив объекта будет пустым.

1. Пусть политика будет новой политикой с пустым набором директив, источником , источником и расположением , расположением .

2. Для каждого токена , возвращенного путем строгого разделения сериализованных на символ U + 003B SEMICOLON (; ):

   1. Удаляет начальные и конечные пробелы ASCII из маркера .

   2. Если токен — пустая строка, продолжить.

   3. Пусть имя директивы будет результатом сбора последовательности кодовых точек из токена , которые не являются пробелами ASCII.

   4. Установить имя директивы как результат выполнения строчной буквы ASCII в имени директивы .

      Примечание. Имена директив не чувствительны к регистру, то есть: script-SRC 'none' и ScRiPt-sRc 'none' эквивалентны.

   5. Если набор директив policy содержит директиву с именем имя директивы , продолжить.

      Примечание. В этом случае пользовательский агент ДОЛЖЕН уведомить разработчиков, что дубликат директива была проигнорирована.Например, может потребоваться консольное предупреждение.

   6. Пусть значение директивы будет результатом разделения токена на Пробел ASCII.

   7. Пусть директива будет новой директивой, имя которой — , имя директивы , а значение — , значение директивы .

   8. Приложение директива — policy Набор директив .

3. Возврат полис .

2.2.2. Разбор сериализованного списка CSP

Чтобы проанализировать сериализованный список CSP , учитывая сериализованный список CSP ( список ), источник ( источник ) и расположение ( расположение ), выполните следующее шаги.

Этот алгоритм возвращает список объектов политики безопасности содержимого. Если список не может быть проанализирован, возвращенный список будет пустым.

1. Пусть политик будет пустым списком.

2. Для каждого токена , возвращенного путем разделения списка на запятую:

   1. Пусть политика будет результатом синтаксического анализа токена с источником , источник , и удаления расположения .

   2. Если набор директив policy пуст, продолжить.

   3. Приложение политики до политики .

3. Возврат полисов .

2.3. Директивы

Каждая политика содержит упорядоченный набор из директив (его набор директив), каждая из которых управляет определенным поведением. Директивы определенные в этом документе, подробно описаны в §6 Директив политики безопасности контента.

Каждая директива представляет собой пару имя / значение . Имя это непустая строка, а значение представляет собой набор непустых строк.Значение МОЖЕТ быть пустым.

Сериализованная директива — это строка ASCII, состоящая из одного или нескольких токены с разделителями-пробелами и соблюдение следующего ABNF [RFC5234]:

  сериализованная-директива  = имя-директивы [обязательное-значение-директивы-ascii-whitespace]
  имя-директивы  = 1 * (АЛЬФА / ЦИФРА / "-")
  значение-директивы  = * (required-ascii-whitespace / (% x21-% x2B /% x2D-% x3A /% x3C-% x7E))
                       ; Значения директив могут содержать пробелы и символы VCHAR,
                       ; без учета ";" и ",".Вторая половина определения
                       ; выше представляет все символы VCHAR (% x21-% x7E)
                       ; без ";" и "," (% x3B и% x2C соответственно)

; ALPHA, DIGIT и VCHAR определены в Приложении B.1 к RFC 5234.
 

имеют ряд связанных алгоритмов:

1. Проверка перед запросом , которая принимает запрос и политику в качестве аргумента и выполняется во время §4.1.3. Следует ли блокировать запрос политикой безопасности контента ?.Этот алгоритм возвращает « Разрешено », если иначе указано.

2. Проверка после запроса , которая принимает запрос, ответ и политику в качестве аргументов, и выполняется во время §4.1.4. Если ответ на запрос блокируется Контентом Политика безопасности?. Этот алгоритм возвращает « Разрешено », если не указано иное.

3. Проверка ответа , которая принимает запрос, ответ и политику в качестве аргументов, и выполняется в §4.1.4 Если ответ на запрос блокируется Контентом Политика безопасности?. Этот алгоритм возвращает « Разрешено », если не указано иное.

4. Встроенная проверка , которая принимает элемент a строка типа, политика и исходная строка в качестве аргументов, и выполняется во время §4.2.4. Следует ли блокировать поведение встроенного типа элемента политикой безопасности контента? и во время §4.2.5 Если запрос навигации типа из источника в целевом блоке Политикой безопасности контента? для javascript: запросов.Этот алгоритм возвращает « Разрешено », если не указано иное.

5. Инициализация , которая принимает Document или глобальный объект, ответ и политику в качестве аргументов. Этот алгоритм выполняется во время §4.2.1 Инициализация списка CSP документа, и не действует, если не указано иное.

6. Предварительная навигационная проверка , которая принимает запрос, строку типа навигации (« form-submission » или « other »), два контекста просмотра и политика в качестве аргументов, и выполняется в §4.2.5 Следует ли блокировать запрос навигации типа из источника в цель Политикой безопасности контента ?. Он возвращается « Разрешено », если не указано иное.

7. Проверка ответа навигации , которая принимает запрос, строку типа навигации (« form-submission » или « other »), ответ, два контекста просмотра, строка типа проверки (« источник » или « ответ ») и политику в качестве аргументов, и выполняется во время §4.2.6 Должен ли ответ навигации на запрос навигации типа из источника в цели быть заблокированным политикой безопасности контента ?. Он возвращает « Разрешено », если не указано иное.

2.3.1. Списки источников

Значения многих директив состоят из списков источников : наборы строк, которые идентифицируют контент, который может быть извлечен и потенциально встроен или выполнен. Каждая строка представляет один из следующих типов источника выражение :

1. Ключевые слова, такие как 'none' и 'self' (которые ничего не соответствуют, а текущий Источник URL соответственно)

2. Сериализованные URL-адреса, например https: // example.com / path / to / file.js (соответствует определенному файлу) или https://example.com/ (соответствует всему в этом источнике)

3. Схемы, такие как https: (что соответствует любому ресурсу, имеющему по указанной схеме)

4. Хосты, такие как example.com (соответствует любому ресурсу на хост, независимо от схемы) или * .example.com (который соответствует любому ресурсу на субдоменах хоста (и любому из поддомены его поддоменов и тд))

5. одноразовых номеров, например 'nonce-ch5hvvbHDpv7xCSvXCs3BrNggHdTzxUA' (что может соответствовать определенные элементы на странице)

6. Дайджесты, например 'sha256-abcd... ' (может соответствовать определенным элементов на странице)

Сериализованный исходный список — это строка ASCII, состоящая из серия исходных выражений, разделенных пробелами, в соответствии со следующей грамматикой ABNF [RFC5234]:

  сериализованный-исходный-список  = (исходное-выражение * (требуемый-ascii-whitespace исходное-выражение)) / « 'нет' »
  исходное-выражение  = источник-схемы / источник-хоста / источник-ключевого слова
                         / nonce-источник / хэш-источник

; Схемы: "https:" / "custom-scheme:" / "другое.индивидуальная схема: "
  схема-источник  = схема-часть ":"

; Хосты: "example.com" / "* .example.com" / "https: //*.example.com: 12 / путь / к / file.js"
  источник-хоста  = [часть-схемы ": //"] часть-хоста [":" часть-порта] [часть-пути]
  схема-деталь  = схема
              ; Схема определена в разделе 3.1 RFC 3986.
  host-part  = "*" / ["*." ] 1 * host-char * ("." 1 * host-char)
  host-char  = АЛЬФА / ЦИФРА / "-"
  часть порта  = 1 * ЦИФРА / "*"
  часть пути  = абсолютный путь (но не включая ";" или ",")
              ; path-absolute определен в разделе 3.3 RFC 3986.

; Ключевые слова:
  keyword-source  = " 'self' " / " 'unsafe-inline' " / " 'unsafe-eval' "
                 / " 'strict-dynamic' " / " 'unsafe-hashes' " /
                 / " 'образец отчета' " / " 'unsafe-allow-redirects' "

ПРОБЛЕМА: Bikeshed  unsafe-allow-redirects .

; Одноразовые номера: 'nonce- [сюда идет одноразовый номер]'
  nonce-source  = "'nonce-" значение base64 "'"
  base64-value  = 1 * (АЛЬФА / ЦИФРА / "+" / "/" / "-" / "_") * 2 ("=")

; Дайджесты: 'sha256- [дайджест здесь]'
  hash-source  = "'" алгоритм хеширования "-" значение base64 "'"
  хэш-алгоритм  = "sha256" / "sha384" / "sha512"
 

Продукция host-char намеренно содержит только ASCII символы; интернационализированные доменные имена нельзя вводить напрямую как часть сериализованного CSP, но вместо этого ДОЛЖЕН быть закодирован Punycode [RFC3492].Например, домен üüüüüü.de ДОЛЖЕН быть представлен как xn--tdaaaaaa.de .

Примечание. Хотя IP-адрес соответствует приведенной выше грамматике, только 127.0.0.1 фактически будет соответствовать URL-адресу при использовании в источнике выражение (см. §6.6.2.5 Соответствует ли URL-адрес исходному списку в источнике с количеством перенаправлений? для подробностей). Охрана свойства IP-адресов являются подозрительными, и авторам следует предпочесть имена хостов как только возможно.

Примечание. Грамматика значений base64 допускает кодирование как base64, так и base64url.Эти кодировки считаются эквивалентными, когда обработка значений хеш-источника. Однако одноразовые номера — это строгие строковые совпадения: мы используем грамматику со значениями base64 для ограничения доступных символов, и уменьшить сложность для оператора на стороне сервера (кодировки и т. д.), но пользовательский агент на самом деле не заботится ни о каком базовом значении, и при этом он не выполняет никакого декодирования значения nonce-source.

2.4. Нарушения

Нарушение представляет собой действие или ресурс, противоречащий набор объектов политики, связанных с глобальным объектом.

Каждое нарушение имеет глобальный объект , который — это глобальный объект, политика которого была нарушена.

Каждое нарушение имеет URL-адрес , который является URL-адресом его глобального объекта.

Каждое нарушение имеет статус , который является неотрицательное целое число, представляющее код состояния HTTP ресурса для которой был создан глобальный объект.

Каждое нарушение имеет ресурс , который либо null , « inline », « eval » или URL .Он представляет собой ресурс который нарушил политику.

Каждое нарушение имеет реферер , что соответствует либо null , либо URL . Он представляет собой реферер ресурса, политика которого было нарушено.

Каждое нарушение имеет политику , которая является политикой, которая была нарушена.

Каждое нарушение имеет позицию , которая представляет собой диспозицию политики, которая была нарушена.

Каждое нарушение имеет действующую директиву , которая представляет собой непустую строку, представляющую директиву, чья правоприменение вызвало нарушение.

Каждое нарушение имеет исходный файл , который либо null , либо URL .

Каждое нарушение имеет номер строки , который неотрицательное целое число.

Каждое нарушение имеет номер столбца , который — целое неотрицательное число.

Каждое нарушение имеет элемент , который является либо null , либо элементом.

Каждое нарушение имеет образец , которая представляет собой строку.Это пустая строка, если не указано иное.

Примечание. В выборку нарушения будут включены первые 40 символы встроенного скрипта, обработчика событий или стиля, вызвавшие нарушение. Нарушения взятые из внешнего файла, образец не включается в отчет о нарушении.

2.4.1. Создайте объект нарушения для global , policy и директивы

Для глобального объекта ( global ), политики ( policy ) и строки (, директива ) следующий алгоритм создает новый объект нарушения и заполняет его начальным набором данных:

1. Пусть нарушение будет новым нарушением, глобальный объект — глобальный , политика — , политика , действующая директива — , директива , а ресурс — , null .

2. Если пользовательский агент в данный момент выполняет сценарий и может извлечь исходный код URL файла, номер строки и номер столбца из глобального , установить нарушение Исходный файл , строка номер и номер столбца соответственно.

   Это где-то указано? Я ничего не видел это выглядело полезным в [ECMA262].

   Примечание. Агенты пользователя должны убедиться, что исходный файл является URL-адресом, запрошенным страницу, предварительно перенаправляет.Если это невозможно, пользовательские агенты должны сократить URL до происхождение, чтобы избежать непреднамеренной утечки.

3. Если global является объектом Window , установите реферер нарушения на global ’s document ’ s referrer .

4. Установить статус нарушения на код статуса HTTP для ресурса, связанного с нарушением глобальных объект.

   Как именно мы получаем код состояния? На самом деле мы его не храним в любом месте.

5. Возврат нарушение .

2.4.2. Создайте объект нарушения для запроса и политики .

По запросу (, запрос ), политика (, политика ), следующий алгоритм создает новый объект нарушения, и заполняет его начальным набором данных:

1. Пусть директива будет результатом выполнения §6.7.1 Получите действующую директиву для запроса на запрос .

2. Пусть нарушение будет результатом выполнения §2.4.1. Создайте объект нарушения для глобального, политики и директивы по запросу глобального объекта клиента , политики и директивы .

3. Установить нарушение ресурса на URL запроса .

   Примечание. Мы используем запрос URL , а не его текущий URL, поскольку последний может содержать информацию о целях перенаправления, к которым страница НЕ ДОЛЖНА быть предоставлена.

4. Возврат нарушение .

3. Доставка полиса

Сервер МОЖЕТ объявить политику для определенного ресурса. представление через поле заголовка ответа HTTP, значение которого представляет собой сериализованный CSP. Этот механизм подробно описан в §3.1 Поле заголовка HTTP-ответа Content-Security-Policy и §3.2 Поле заголовка HTTP-ответа Content-Security-Policy-Report-Only, а также интеграция с Fetch а HTML описан в §4.1 Интеграция с Fetch и §4.2 Интеграция с HTML.

Политика также может быть объявлена ​​встроенной в документ HTML с помощью атрибута http-Equ элемента meta , как описано в §3.3 Элемент.

Поле заголовка ответа HTTP является предпочтительным механизмом для доставки политики с сервера на клиент. Значение заголовка представлено следующим ABNF [RFC5234]:

 Content-Security-Policy = 1 # сериализованная-политика
                    ; Правило '#' определено в разделе 7 RFC 7230.
                    ; но он включает указанные модификации
                    ; в разделе 2.1 этого документа.
 

: сценарий-src «сам»;
                         отчет для csp-отчетности-конечной точки
 

Сервер МОЖЕТ отправлять другое поле заголовка Content-Security-Policy значения с разными представлениями одного и того же ресурса.

Серверу НЕ СЛЕДУЕТ отправлять более одного поля заголовка ответа HTTP с именем « Content-Security-Policy » с заданным ресурсом представление.

Когда пользовательский агент получает поле заголовка Content-Security-Policy , он ДОЛЖЕН анализировать и применять каждый сериализованный CSP, который он содержит, как описано в §4.1 Интеграция с Fetch, §4.2 Интеграция с HTML.

Поле заголовка ответа HTTP позволяет веб-разработчикам экспериментировать с политиками путем мониторинга (но не применяя) свои эффекты. Значение заголовка представлено следующим ABNF [RFC5234]:

 Content-Security-Policy-Report-Only = 1 # сериализованная-политика
                    ; Правило '#' определено в разделе 7 RFC 7230.
                    ; но он включает указанные модификации
                    ; в разделе 2.1 этого документа.
 

Это поле заголовка позволяет разработчикам объединить свою политику безопасности в итеративным способом, развертывая политику только для отчетов на основе их лучших оценка поведения их сайта, отслеживание сообщений о нарушениях, а затем переходят к принудительной политике, как только они убедятся в этом поведении.

: сценарий-src «сам»;
                                     отчет для csp-отчетности-конечной точки
 

Сервер МОЖЕТ отправлять разные значения поля заголовка Content-Security-Policy-Report-Only с разными представлениями одного и того же ресурс.

Серверу НЕ СЛЕДУЕТ отправлять более одного поля заголовка ответа HTTP с именем « Content-Security-Policy-Report-Only » с заданным ресурсом представление.

Когда пользовательский агент получает заголовок Content-Security-Policy-Report-Only поле, он ДОЛЖЕН анализировать и контролировать каждый сериализованный CSP, который он содержит, как описано в §4.1 Интеграция с Fetch и §4.2 Интеграция с HTML.

Примечание. Заголовок не поддерживается внутри мета-элемента .

3.3. Элемент

A Документ может предоставлять политику через один или несколько элементов мета HTML чьи http-Equiv атрибуты являются совпадением без учета регистра ASCII для строки « Content-Security-Policy ». Например:

Подробную информацию о реализации можно найти в политике безопасности содержимого HTML. state http-Equiv инструкции обработки [HTML].

Примечание. Заголовок - , не поддерживается внутри

Служба проверки разметки W3C