Обновление касс к 1 сентября 2025 года. Что нужно знать
1 сентября давно уже стало одной из традиционных дат для внедрения различных изменений. В этом году изменения касаются касс ККМ и затрагивают практически каждое торговое предприятие.
Информации по этой теме в сети много, но не вся она, скажем мягко, соответствует действительности. Информационные ресурсы наперегонки стращают нас о необходимости обновляться, обновляться и еще раз обновляться. Но на самом деле не все так страшно.
Изменения касаются сразу нескольких, независимых друг от друга областей регулирования, поэтому исходить будем из того, чем занимается организация на самом деле. В качестве товароучетных систем будем рассматривать программы от 1С и кассы производства АТОЛ, однако и в других сочетаниях все будет плюс-минус также.
🔹 Если вы не торгуете маркированным товаром и не ведете дистанционную торговлю, то единственным изменением для вас будут новые требования к бумажному чеку. Новых печатных реквизитов там не вводится, а все нововведения касаются размеров шрифта и QR-кода. Поэтому достаточно просто обновить прошивку кассы до актуальной – 5.16.0 у АТОЛ.
🔹 Если вы работаете с маркированным товаром, то вы теперь обязаны передавать теги 1011 Часовая зона и 2040 Номер ФД кассового чека (чека коррекции). Эти чеки передаются только в отчет о реализации маркированного товара в ОФД вы их не найдете.
Казалось бы, тут неминуемо обновление, но не будем спешить, если изучить последние релизы типовых конфигураций 1С, то мы не найдем там специфичного кода, отвечающего за заполнение этих тегов, равно как интеграционная компонента остается версии 10.10.6.0.
Поэтому, если у вас все остальные требования по работе с маркированным товаром соблюдены – то можете остаться на текущем релизе, заодно избежав обновления платформы до 8.3.27.
В этом случае вам потребуется обновить прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0, после чего ККТ начнет самостоятельно передавать часовой пояс и номер ФД (который формируется ФН внутри ККТ и товароучетное по для этого не требуется).
Для контроля зайдите в личный кабинет Честного знака, скачайте чек в формате JSON и найдите в нем строки:
▫️ receiptDocumentNumber – тег 2040 Номер ФД кассового чека
▫️ timeZone – тег 1011 Часовая зона
Обычно они идут рядом по порядку. Также проконтролируйте наличие строки:
▫️ hasIncorrectCodes – тег 2107 Результаты проверки маркированных товаров
Он также передается самой ККТ и не требует дополнительных настроек.
🔹 Если вы занимаетесь торговлей в сети интернет, то для вас обязательными станут теги:
▫️ тег 1125 - Признак расчета в Интернет
▫️ тег 1187 – Адрес сайта (место расчетов)
▫️ тег 1008 – Контактные данные покупателя (телефон или e-mail)
В этом случае также обновляем прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0.
А вот с обновлением товароучетного ПО есть варианты. Мы не работаем с этой областью и точно сказать не можем что и в каком объеме формируется или не формируется в текущих версиях. Но, в общем и целом, доработки несложные и есть смысл задуматься о их реализации при помощи расширения если обновлять конфигурацию вы по каким-либо причинам не хотите.
Если дополнительно к этому вы продаете маркированный товар, то проконтролируйте наличие тегов из предыдущего пункта.
🔹 А как быть с тегами 1234 – 1238 и 1082? А никак! На текущий момент ФНС не утвердила точный порядок заполнения реквизита сведения обо всех оплатах по чеку безналичнымим (тег 1234). Поэтому, до появления приказа, можем эти теги не заполнять и не передавать.
Скажем больше, в настоящий момент попытка передачи этого тега руками приводит во многих ОФД к ошибке – неизвестный тег. Поэтому не бежим впереди паровоза, а спокойно ждем очередных сроков.
1 сентября давно уже стало одной из традиционных дат для внедрения различных изменений. В этом году изменения касаются касс ККМ и затрагивают практически каждое торговое предприятие.
Информации по этой теме в сети много, но не вся она, скажем мягко, соответствует действительности. Информационные ресурсы наперегонки стращают нас о необходимости обновляться, обновляться и еще раз обновляться. Но на самом деле не все так страшно.
Изменения касаются сразу нескольких, независимых друг от друга областей регулирования, поэтому исходить будем из того, чем занимается организация на самом деле. В качестве товароучетных систем будем рассматривать программы от 1С и кассы производства АТОЛ, однако и в других сочетаниях все будет плюс-минус также.
🔹 Если вы не торгуете маркированным товаром и не ведете дистанционную торговлю, то единственным изменением для вас будут новые требования к бумажному чеку. Новых печатных реквизитов там не вводится, а все нововведения касаются размеров шрифта и QR-кода. Поэтому достаточно просто обновить прошивку кассы до актуальной – 5.16.0 у АТОЛ.
🔹 Если вы работаете с маркированным товаром, то вы теперь обязаны передавать теги 1011 Часовая зона и 2040 Номер ФД кассового чека (чека коррекции). Эти чеки передаются только в отчет о реализации маркированного товара в ОФД вы их не найдете.
Казалось бы, тут неминуемо обновление, но не будем спешить, если изучить последние релизы типовых конфигураций 1С, то мы не найдем там специфичного кода, отвечающего за заполнение этих тегов, равно как интеграционная компонента остается версии 10.10.6.0.
Поэтому, если у вас все остальные требования по работе с маркированным товаром соблюдены – то можете остаться на текущем релизе, заодно избежав обновления платформы до 8.3.27.
В этом случае вам потребуется обновить прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0, после чего ККТ начнет самостоятельно передавать часовой пояс и номер ФД (который формируется ФН внутри ККТ и товароучетное по для этого не требуется).
Для контроля зайдите в личный кабинет Честного знака, скачайте чек в формате JSON и найдите в нем строки:
▫️ receiptDocumentNumber – тег 2040 Номер ФД кассового чека
▫️ timeZone – тег 1011 Часовая зона
Обычно они идут рядом по порядку. Также проконтролируйте наличие строки:
▫️ hasIncorrectCodes – тег 2107 Результаты проверки маркированных товаров
Он также передается самой ККТ и не требует дополнительных настроек.
🔹 Если вы занимаетесь торговлей в сети интернет, то для вас обязательными станут теги:
▫️ тег 1125 - Признак расчета в Интернет
▫️ тег 1187 – Адрес сайта (место расчетов)
▫️ тег 1008 – Контактные данные покупателя (телефон или e-mail)
В этом случае также обновляем прошивку и драйвер ККТ до последних версий: 5.16.0 и 10.10.7.0.
А вот с обновлением товароучетного ПО есть варианты. Мы не работаем с этой областью и точно сказать не можем что и в каком объеме формируется или не формируется в текущих версиях. Но, в общем и целом, доработки несложные и есть смысл задуматься о их реализации при помощи расширения если обновлять конфигурацию вы по каким-либо причинам не хотите.
Если дополнительно к этому вы продаете маркированный товар, то проконтролируйте наличие тегов из предыдущего пункта.
🔹 А как быть с тегами 1234 – 1238 и 1082? А никак! На текущий момент ФНС не утвердила точный порядок заполнения реквизита сведения обо всех оплатах по чеку безналичнымим (тег 1234). Поэтому, до появления приказа, можем эти теги не заполнять и не передавать.
Скажем больше, в настоящий момент попытка передачи этого тега руками приводит во многих ОФД к ошибке – неизвестный тег. Поэтому не бежим впереди паровоза, а спокойно ждем очередных сроков.
👍21❤3
Эталонная модель OSI
Продолжаем рассматривать модель OSI и переходим к самым интересным, верхним уровням.
🔹 Уровень 5 – сеансовый. Отвечает за установку, управление и завершение сеансов связи между приложениями. Также обеспечивает синхронизацию и управление диалогом и восстановление сеанса в случае его обрыва.
Казалось бы, достаточно просто, но отдельных протоколов сеансового уровня придется поискать днем с огнем. Обычно здесь мы можем увидеть самые различные протоколы, традиционно считаемые протоколами иных уровней.
Это прикладные RDP, SMB, SIP, RPC, канальный PPP и использующие его PPTP или L2TP. Также здесь может оказаться TLS или даже НТТP, хотя у последнего сессии «ненастоящие».
Почему так? Потому что OSI – это абстракция, а реальные протоколы – это реальные протоколы, которые работают по-своему и без оглядки на эту модель. Поэтому здесь очень многое зависит от контекста и угла, под которым мы рассматриваем данный вопрос.
В целом – если протокол занимается созданием, управлением и завершением сеансов – то этот протокол работает на сеансовом уровне OSI.
🔹 Уровень 6 – представления. Отвечает за преобразование данных, получаемых с самого верхнего уровня L7 или предоставляемых ему. Сюда относится преобразование форматов, сжатие, кодирование и шифрование, если оно не связано с защитой передаваемых данных на сетевом или транспортном уровне.
Кодируем видео с рабочего стола для конференции – это L6, звук – тоже сюда же. Сжатие на лету HTTP-содержимого – тоже к нам. И в качестве протоколов шестого уровня у нас полноценно выступают алгоритмы сжатия и медиакодеки.
А вот с шифрованием все очень не просто. Описание шестого уровня содержит оговорку, что шифрование считается работающим на L6 только если шифруются данные самого приложения и это не связано с защитой канала передачи данных.
А вот тут начинаются еще более веселые приключения. Например, приложение, прежде чем отправить некий протокольный блок данных, который, скажем содержит данные о начисленной зарплате решает его зашифровать. Это шестой уровень, однозначно.
А вот если оно отправило этот блок как есть через защищенный канал IPsec или TLS, то это ни разу ни шестой, а третий или четвертый.
И тут снова всплывает контекст и угол обзора. Вот берем, например, классический HTTPS, не касаясь его современных вариаций.
Если посмотреть под углом, что в TLS заворачивается только HTTP содержимое и ничего больше, то можно отправить TLS на шестой уровень.
А если вспомним, что перед тем, как начать заворачивать HTTP-содержимое TLS установил соединение (уровень 5 – сеансовый) и предоставляет HTTP-защищенный канал, то он становится протоколом транспортного уровня.
А если… И таких если может быть очень много. Поэтому всегда помним, что OSI – это эталонная модель, помогающая понять принцип сетевого взаимодействия, но красиво наложить на нее современные протоколы не получится, это действо сродни натягивания совы на глобус.
🔹 Уровень 7 – прикладной, он же уровень приложений. Обеспечивает взаимодействие с сетью приложений операционной системы. И позволяет им общаться через сеть «понятным» языком.
Сюда относятся все протоколы, с которыми работают конечные приложения: браузер, почтовый клиент, сетевой плеер, клиент удаленного доступа. Это HTTP, FTP, SMTP, POP3, IMAP, RDP, SMB и т.д. и т.п.
Но здесь тоже далеко не все так просто, тот же RDP или SMB кроме всего прочего еще устанавливает и управляет сеансами, занимается кодированием и преобразованием данных от приложения, т.е. равномерно распределяет свои функции между L5 -L7.
Точно также, как и на предыдущих уровнях достаточно сложно выделить протоколы именно прикладного уровня, каждый из них может быть свободно представлен на нескольких уровнях, что модель OSI не запрещает.
Что касается самой модели и ее стройности, то на этих уровнях она сильно страдает. Но это удел любой теоретической абстракции. В тоже время OSI надо знать и понимать, так как по ее образу и подобию построены многие иные модели, которые как раз используются в реальной жизни.
Продолжаем рассматривать модель OSI и переходим к самым интересным, верхним уровням.
🔹 Уровень 5 – сеансовый. Отвечает за установку, управление и завершение сеансов связи между приложениями. Также обеспечивает синхронизацию и управление диалогом и восстановление сеанса в случае его обрыва.
Казалось бы, достаточно просто, но отдельных протоколов сеансового уровня придется поискать днем с огнем. Обычно здесь мы можем увидеть самые различные протоколы, традиционно считаемые протоколами иных уровней.
Это прикладные RDP, SMB, SIP, RPC, канальный PPP и использующие его PPTP или L2TP. Также здесь может оказаться TLS или даже НТТP, хотя у последнего сессии «ненастоящие».
Почему так? Потому что OSI – это абстракция, а реальные протоколы – это реальные протоколы, которые работают по-своему и без оглядки на эту модель. Поэтому здесь очень многое зависит от контекста и угла, под которым мы рассматриваем данный вопрос.
В целом – если протокол занимается созданием, управлением и завершением сеансов – то этот протокол работает на сеансовом уровне OSI.
🔹 Уровень 6 – представления. Отвечает за преобразование данных, получаемых с самого верхнего уровня L7 или предоставляемых ему. Сюда относится преобразование форматов, сжатие, кодирование и шифрование, если оно не связано с защитой передаваемых данных на сетевом или транспортном уровне.
Кодируем видео с рабочего стола для конференции – это L6, звук – тоже сюда же. Сжатие на лету HTTP-содержимого – тоже к нам. И в качестве протоколов шестого уровня у нас полноценно выступают алгоритмы сжатия и медиакодеки.
А вот с шифрованием все очень не просто. Описание шестого уровня содержит оговорку, что шифрование считается работающим на L6 только если шифруются данные самого приложения и это не связано с защитой канала передачи данных.
А вот тут начинаются еще более веселые приключения. Например, приложение, прежде чем отправить некий протокольный блок данных, который, скажем содержит данные о начисленной зарплате решает его зашифровать. Это шестой уровень, однозначно.
А вот если оно отправило этот блок как есть через защищенный канал IPsec или TLS, то это ни разу ни шестой, а третий или четвертый.
И тут снова всплывает контекст и угол обзора. Вот берем, например, классический HTTPS, не касаясь его современных вариаций.
Если посмотреть под углом, что в TLS заворачивается только HTTP содержимое и ничего больше, то можно отправить TLS на шестой уровень.
А если вспомним, что перед тем, как начать заворачивать HTTP-содержимое TLS установил соединение (уровень 5 – сеансовый) и предоставляет HTTP-защищенный канал, то он становится протоколом транспортного уровня.
А если… И таких если может быть очень много. Поэтому всегда помним, что OSI – это эталонная модель, помогающая понять принцип сетевого взаимодействия, но красиво наложить на нее современные протоколы не получится, это действо сродни натягивания совы на глобус.
🔹 Уровень 7 – прикладной, он же уровень приложений. Обеспечивает взаимодействие с сетью приложений операционной системы. И позволяет им общаться через сеть «понятным» языком.
Сюда относятся все протоколы, с которыми работают конечные приложения: браузер, почтовый клиент, сетевой плеер, клиент удаленного доступа. Это HTTP, FTP, SMTP, POP3, IMAP, RDP, SMB и т.д. и т.п.
Но здесь тоже далеко не все так просто, тот же RDP или SMB кроме всего прочего еще устанавливает и управляет сеансами, занимается кодированием и преобразованием данных от приложения, т.е. равномерно распределяет свои функции между L5 -L7.
Точно также, как и на предыдущих уровнях достаточно сложно выделить протоколы именно прикладного уровня, каждый из них может быть свободно представлен на нескольких уровнях, что модель OSI не запрещает.
Что касается самой модели и ее стройности, то на этих уровнях она сильно страдает. Но это удел любой теоретической абстракции. В тоже время OSI надо знать и понимать, так как по ее образу и подобию построены многие иные модели, которые как раз используются в реальной жизни.
👍16🤮1