Разрабатываю приложение для учета торговли. Заказчик хочет чтобы была предусмотрена возможность печати нефискального чека максимально похожего на обычный (все мы понимаем зачем ;) ). То что он может понести ответственность, меня как программиста не должно волновать (его слова дословно).
Уважаемые форумчане. Как вы думаете, предусмотрена ли ответственность для разработчика ПО за то, что есть возможность продажи и НЕ отправки чека в ОФД? Или может прописать это отдельно в лицензионном соглашении?

Зингер
Разрабатываю приложение для учета торговли. Заказчик хочет чтобы была предусмотрена возможность печати нефискального чека максимально похожего на обычный (все мы понимаем зачем ;) ).

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

Вопрос, конечно, интересный.

Вряд ли заказчик захочет такое прописывать в лицензионной соглашении. Но... Можно, наверное, поступить вот как.

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

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

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

Чтобы на такое пойти, надо представить себе гипотетическую ситуацию. Идет судебный процесс, и судья или прокурор спрашивает: Вы осознавали, что вы делали? Вы понимали мотивы заказчика? и т.п.

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

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

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

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

Зингер

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

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

Пособничество вполне можно пришить при желании.

А это типа тестовый режим, без отправки.
А это вообще реализуемо технически?
Я бы такие дела никогда не делал на одном устройстве, мало ли дойдёт до экспертизы.
Отдельный термопринтер и отдельная софтина с возможностью коннекта к основной БД. Ну и штатный левый отчёт типа ценника. А у заказчика есть возможность добавлять новые. И это типа он уже сам нарисовал.

Taran
А это типа тестовый режим, без отправки.
А это вообще реализуемо технически?
Я бы такие дела никогда не делал на одном устройстве, мало ли дойдёт до экспертизы.
Отдельный термопринтер и отдельная софтина с возможностью коннекта к основной БД. Ну и штатный левый отчёт типа ценника. А у заказчика есть возможность добавлять новые. И это типа он уже сам нарисовал.

В том то и дело, что заказчик хочет чтобы при продаже появлялось диалоговое окно с выбором типа "ОФД" или "без ОФД". И в зависимости от этого печатался соответствующий чек. Технически это можно проделать, например с Атол, integration.atol.ru. То есть, всю ответственность он берет вроде бы как на себя.
Я тут гуглил, нарыл www.consultant.ru Там сказано, что в принципе Налоговый кодекс предусматривает продажу без ККТ. Таким образом, я полагаю может использоваться и не фискальный чек.

P.S. Конечно же напрягают слова про прокурора, адвоката, суды, пособничество и т.п. Далек я от этого. Не хватало еще на старости лет изучать УК. Тьфу-тьфу-тьфу

Я бы заменил фразы в диалоге на что-то другое. Реал/тест. Чтоб не явно было.
Ну и наверно в БД как-то будет учитываться тип чека?
Чтоб в отчетах потом и подсчете сумм учитывать?
А изымут если комп и бд?

И чуток идей насчёт черных дел.
Естественно юзер в прогу входит с именем и паролем.
Паролей два. Один покороче, второй длиннее.
При входе с первым паролем никаких чёрных дел и возможностей в проге не видно. А то мало ли, вдруг придётся/заставят работать под надзором.

Про тестовый режим - это правильная идея. Притом можно сделать в 2 вариантах. Первый вариант - "официальный". Печатается чек с пометкой "Тест". И второй режим по длинному паролю - там уже иначе кагбэ...

Taran
Я бы заменил фразы в диалоге на что-то другое. Реал/тест. Чтоб не явно было.

Хорошая идея.

Taran
Ну и наверно в БД как-то будет учитываться тип чека?
Чтоб в отчетах потом и подсчете сумм учитывать?

Безусловно.

Taran
А изымут если комп и бд?

БД в облаке у хостера.

Simple777
Про тестовый режим - это правильная идея. Притом можно сделать в 2 вариантах. Первый вариант - "официальный".

Да-да. Таким образом, продавец выставляя опцию Тест должен осознавать всю ответственность.

Simple777
Печатается чек с пометкой "Тест". И второй режим по длинному паролю - там уже иначе кагбэ...

Промолчу. Может Печатается, а может и ...

[attachment 32744 al.gif]

Зингер
БД в облаке у хостера

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

Simple777
Про тестовый режим - это правильная идея. Притом можно сделать в 2 вариантах. Первый вариант - "официальный". Печатается чек с пометкой "Тест". И второй режим по длинному паролю - там уже иначе кагбэ...

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



Исправлено 1 раз(а). Последнее : Taran, 31.01.20 19:28

Taran
А владелец кассы и разработчик софта вообще не в курсе про такую возможность.

[attachment 32746 bt.gif]

Была у меня похожая история, но она была совершена по халатности. В одной "конторе", один товарищ "нечаянно" на рабочую БД закинул тестовые изменения и в чеках о проведении операций в основании платежа были тестовые значения,одно из которых гласило - "взятка президенту ...". Ну и так получилось, что кассир напечатал клиенту такую вот бумажку с таким вот основанием платежа. Клиент сразу не заметил и ушел. А потом когда вернулся, был скандалиЩЕ. Скандал с клиентом, увольнение горе-товарища программиста, но инцидент как то замяли, до суда не довели. Т.е. повезло, что клиент (а это юр.лицо) заметил. если бы не заметил и подшил в свои бумажки, а потом к нему пришла налоговая или иной проверяющий орган, нашли бы такую платежку....трепались, что страшно представить что бы было....

Была еще одна история, в другой конторе, в бух.приложении велось 2 учета с печатью белых доков и "черных". Но это было организовано на двух разных серверах, главные бухи которые это делали, были партизаны. И когда приходила проверка, сервер с "черными" доками, отрубали. В общем всё было крайне конспиративно.

Зингер
Я тут гуглил, нарыл www.consultant.ru Там сказано, что в принципе Налоговый кодекс предусматривает продажу без ККТ. Таким образом, я полагаю может использоваться и не фискальный чек.

Всё таки лучше по точнее узнать, чтобы спать спокойнее.





Исправлено 10 раз(а). Последнее : Божья_коровка, 01.02.20 14:54

Вообще нужно с этим делом поспешать.
К Дню Победы ожидается большая амнистия.
Т.е. нужно успеть сесть раньше. ;)

Taran
Вообще нужно с этим делом поспешать.
К Дню Победы ожидается большая амнистия.
Т.е. нужно успеть сесть раньше. ;)

Позитивно мыслишь!

Ленок, ты ещё и мыслишь! Неистово плюсую (это п сильгй плюс, провеерю)

Зингер
Разрабатываю приложение для учета торговли. Заказчик хочет чтобы была предусмотрена возможность печати нефискального чека максимально похожего на обычный (все мы понимаем зачем ;) ). То что он может понести ответственность, меня как программиста не должно волновать (его слова дословно).
Уважаемые форумчане. Как вы думаете, предусмотрена ли ответственность для разработчика ПО за то, что есть возможность продажи и НЕ отправки чека в ОФД? Или может прописать это отдельно в лицензионном соглашении?

Фиксируете требования в письменном виде (не надо в соглашении), после акты о приемке - и все. Остальное - не ваше дело, вы работали в соответствии с ТЗ, правовая сторона вопроса - не ваш вопрос.