Да, неделя не очень большой срок. Большинство фирм вполне в состоянии позволить себе отправить всех в оплачиваемый отпуск на неделю. В нормальных условиях.
Но есть несколько нюансов.
Отпуск всех = остановка бизнеса. Т.е. остановка входящего денежного потока. Производство стоит, отгрузки стоят, продажи стоят. При этом исходящий поток остается без изменений — налоги, аренды и пр.
Плюс к этому добавляем снижение денежного потока в принципе на фоне пандемии, скачка доллара, нехватки товаров из-за закрытия границ, снижения покупательской способности населения и пр. Одни эти факторы могут убить бизенсс, в котором вы сейчас работаете.
У некоторых уже падение выручек на 85%.
Ну и тут еще как контрольный в голову — перекрыть и этот ручеек финансов на неделю.
В общем мое мнение — лучше сейчас помочь работодателю по мере возможности, чем потом искать нового. А учитывая сколько будет разорившихся компания и специалистов на рынке — искать возможно придется долго.
Про навязанность ЦРПТ — это отдельная тема для разговора. Здесь все-таки техническая часть обсуждается. И факт монополизма ЦРПТ не лишает вас возможности подать против них иск за нарушение условий договора.
Не исключено, что в ближайшее время доработают схему и будет как с ОФД. Инфраструктура едина — в случае ОФД все чеки в итоге сливаются в налоговую. А вот поставщики — разные.
Здесь могут сделать нечто аналогичное — коды смогут выпускать и спецоператоры (ЭДО, ОФД), но все операции с кодами будут храниться в мастер-системе ЦРПТ. На мой взгляд такая схема работы оптимальнее текущей.
На сколько я помню стоимость кода 50 коп., НДС это еще 10. Итого 60, а не 65.
Если вы не согласны с действиями ЦРПТ, то вы можете подать на них в суд.
Вы, как юридическое лицо, заключили договор с другим юридическим лицом (ЦРПТ).
Вы считаете, что требованин оплаты услуг вашим контрагентом противоречит действующему законодательству. Если контрагент с вами не согласен, то на мой взгляд вопрос должен решаться в судебном порядке.
Ну, вам виднее. Откройте csv файл экселем, а потом в csv же и сохраните. Повторите 10 000 раз на 100 разных компьютерах с разными версиями экселя, винды, разными настройками локализации, разными настройками одной и той же версии экселя.
После этого возвращайтесь и мы с вами снова обсудим эту тему. А пока ваша выборка не репрезентативна.
Самые частые проблемы это не потеря GS, а задвоение кавычек, потеря точек с запятой и появление точки с запятой в конце строки.
Лично мое мнение — один из самых больших плюсов маркировки — создание нац каталога. Когда бухгалтерские системы проведут с ним интеграцию, то это будет прямо прорыв при работе с первичкой. Когда номенклатурные справочники разных организаций начнут наконец-то совпадать.
Именно поэтому я всегда рекомендую забирать эти "волшебные" коды в csv формате из СУЗ.
Сейчас много софта, которые из этого csv вам хоть 500 раз распечатают повторно коды.
Сам одну такую программу написал и в массы выложил.
При этом црпт получает 50 копеек за каждый выпущенный код (это 12 р с каждого блока сигарет). А производители эти 50 копеек вшивают в себестоимость.
В итоге покупатель оплачивает все нововведения. Как и стоимость обновления оборудования.
Уж лучше бы бюджетные потратили. А то помимо НДС теперь и за КМ будет платить покупатель.
По идее часть этого функционала пытаются спихнуть на операторов ОФД и ЭДО.
Продал товар по накладной через ЭДО, данные сами ушли в ЦРПТ. Пробили чек на кассе — данные ушли в ЦРПТ от оператора ОФД.
Однако интеграция с ЦРПТ что для первых, что для вторых — еще то увлекательное приключение.
Схема работы следующая — при пробитии товара необходимо просканировать уникальный код товара. Он укладывается в чек и фискальную память (тег 1162). Далее передается в ОФД в составе чека.
ОФД обязано выявлять такие чеки и передавать их в ЦРПТ.
Сейчас ряд ОФД активно подумывает, а не брать ли с пользователей доп денюжку за передачу чеков в ЦРПТ.
Так же операторы ЭДО при обнаружении УПД с кодами маркировки обязаны передавать информацию в ЦРПТ. Так отслеживается смена владельца кода маркировки.
Как отслеживается текущее местонахождение кода — не знаю. Скорее всего уже WMS владельца должна отчитываться.
Скорее всего статья на хабре была моя :-) (StateMachine в протоколе РОСЭУ).
У нас логика перехода состояний документа в документообороте сейчас на ней сделана. Работой вполне довольны. Единственно что не сразу поняли — в экшны лучше по минимуму логики вкладывать и просто больше экшнов делать.
Удобно, что через пару замен в коде можно UML диаграмму получить. И наоборот — UML диаграмму легко в код перевести.
Кстати, в sendEvent можно отправить не только ивент, но и Message с ивентом. В хедерах которого можно протащить доп информацию и использовать ее в экшенах.
А так в целом — спасибо за более подробный разбор библиотеки. На мой взгляд стейт машина на много лучше, чем куча if/else и switch.
Тогда может просто не заводить тикеты? Нет тикетов — нет проблем…
Оставить формочку заведения тикетка, после нажатия кнопки «отправить» просто очищать ее и выводить надпись «Тикет создан». На телефон настроить автоответчик — «Мы вас любим, мы о вас заботимся, ожидайте». И никогда не отвечать. Сплошной рай для техподдержки.
Материал в первую очередь предназначен для сотрудников ИТ служб небольших компаний. Если компания переживает фазу роста, то ИТ отделу приходится приспосабливаться под новые реалии. Больше сотрудников, больше техники, больше всего… когда два посменных ИТ специалиста уже не справляются и начинает расти недовольство пользователей.
Как-то так.
А сервисные компании, как правило, заранее заботятся о пост продажном сопровождении. Т.к. это часть их бизнеса. И услуга сопровождения после продажи — отдельный источник дохода. Причем регулярного дохода.
Вашим конкурентам в комментарии к другой статье я уже подробно объяснил, чем мне не нравятся облачные решения по сервис-деску и почему я считаю область их применения достаточно узкой.
У вас цены, кстати, более приемлемые, чем у того конкурента :). Поэтому для малых организаций можно попробовать.
Конкретно в моем случае — защищенное соединение отменено. Внутренняя сеть должна быть изолированна от внешнего мира. Точка.
Я понимаю, что вы всячески продвигаете решение ServiceNow. Это реклама. Скорее всего вы сотрудник фирмы Техносерв. Учитывая как вы работаете с возражениями, то возможно даже из отдела продаж. Или маркетинга
В рекламируемом вами решении есть все недостатки облачного решения — компания должна постоянно платить поставщику. Ежемесячно. Увеличились потребности — увеличилась плата. Очень часто на больших объемах это банально не выгодно.
Даже в минимальной конфигурации предлагаемое вами решение стоит порядка 96 000 р в месяц. И да — в целях рекламы указывать цену без НДС на мой взгляд не самый лучший трюк.
Если идет установка on-premise — то покупатель помимо ежемесячной платы минимум в 96 000 р получает еще все затраты на поддержание оборудования. А у Техносерва это заявлено как одно из ключевых преимуществ — не нужно тратиться на инфраструктуру и за счет этого экономим.
За эти деньги можно позволить себе в штат отдельного программиста, который будет вылизывать имеющиеся опенсорсные решения и делать их интеграцию со всеми внутренними системами.
Не знаю на чем написано продвигаемое вами решение, но скорее всего код закрытый. Почти наверняка — хотите доработку, заплатите нам. За одну только интеграцию с AD этой замечательной системы разработчики хотят 45 000 р. Сколько захотят за допилку под конкретные нужды компании?
И один из очень больных вопросов облаков — надежность хранения корпоративных данных. Если пользователь пришлет запрос «у меня не открывается годовой фин отчет, помогите» — где гарантия, что этот самый отчет будет храниться только в облаке и никогда никуда не уйдет?
Лично мое мнение — облачные решения приемлемы либо для небольших компаний, пока нет больших объемов и особо не стоит вопрос сохранности корп данных. Либо для второстепенных для компании функций.
Если компания готова ежемесячно выделять 100 000 р. на софт, который нужен только ИТ отделу для его внутренних нужд… то мне кажется ИТ директор найдет этому бюджету иное применение, при наличии большого количества бесплатных/более дешевых/не SaaS аналогов.
В 1С ИТИЛ в нашем варианте это было два документа — перемещение со склада на рабочее место и документ списание. Каждое рабочее место — отдельный склад. Комплектацией/разукомплектацией занимались только для системников, когда кишки меняли.
Здесь вопрос к вам — зачем так сложно процессы настраивали? Система должна подстраиваться к процессам, а не процессы к системе.
Конкретно на текущем месте работы у нас внутренняя сеть. Практически полностью изолированная от интернета. Так что никакое облачное решение не приемлимо.
И третьи лица могут сколько угодно говорить о сохранности моих данных. Не верю. Если возникнет нужда — сольют данные. Либо вирусня стянет.
Я с недоверием отношусь к облачным системам в принципе. Не люблю отдавать корпоративные данные третьим лицам. И в защищенных сетях с ними особо не поработаешь.
Мне довелось плотно поработать с двумя системами — 1С Итил и OTRS 5.
OTRS понравился легкостью, скоростью, гибкостью. Достаточно простая интеграция, гибкие настройки, легкий интерфейс. Все в браузере. Есть напоминалки, алерты, удобно настраивать тригеры и т.д. Достаточно удобная база знаний.
Но вот что касается учета активов, хранения документов — беда-беда. Все весьма неудобно, неинтуитивно, много чего надо ручками заводить.
1С ИТИЛ — это 1С. А оно сильно именно учетом. Есть приходные документы, документы перемещения, печатные формы. Вплоть до интеграции с бухгалтерией. Но мы так далеко не пошли.
А вот с обработкой инцидентов в 1С было сложнее — достаточно много лишних действий приходилось делать.
Так что в ОТРС понравился блок управления инцидентами, в 1С ИТИЛе блок учета. При должном количестве времени и наличии программистов думаю и то и другое смогли бы довести до уровня «конфетки». Выбирая из них двоих все-таки остановился бы на 1С ИТИЛе. 1С-ников проще найти :).
С другими системами плотно не работал, сказать что-то трудно.
Эх, жалко я таки не перл программист, так и не удалось по вашей схеме задействовать.
Там еще xml конфиг пришлось править, чтобы в веб интерфейсе появилась возможность Invoker включить.
Но есть несколько нюансов.
Отпуск всех = остановка бизнеса. Т.е. остановка входящего денежного потока. Производство стоит, отгрузки стоят, продажи стоят. При этом исходящий поток остается без изменений — налоги, аренды и пр.
Плюс к этому добавляем снижение денежного потока в принципе на фоне пандемии, скачка доллара, нехватки товаров из-за закрытия границ, снижения покупательской способности населения и пр. Одни эти факторы могут убить бизенсс, в котором вы сейчас работаете.
У некоторых уже падение выручек на 85%.
Ну и тут еще как контрольный в голову — перекрыть и этот ручеек финансов на неделю.
В общем мое мнение — лучше сейчас помочь работодателю по мере возможности, чем потом искать нового. А учитывая сколько будет разорившихся компания и специалистов на рынке — искать возможно придется долго.
Не исключено, что в ближайшее время доработают схему и будет как с ОФД. Инфраструктура едина — в случае ОФД все чеки в итоге сливаются в налоговую. А вот поставщики — разные.
Здесь могут сделать нечто аналогичное — коды смогут выпускать и спецоператоры (ЭДО, ОФД), но все операции с кодами будут храниться в мастер-системе ЦРПТ. На мой взгляд такая схема работы оптимальнее текущей.
На сколько я помню стоимость кода 50 коп., НДС это еще 10. Итого 60, а не 65.
Если вы не согласны с действиями ЦРПТ, то вы можете подать на них в суд.
Вы, как юридическое лицо, заключили договор с другим юридическим лицом (ЦРПТ).
Вы считаете, что требованин оплаты услуг вашим контрагентом противоречит действующему законодательству. Если контрагент с вами не согласен, то на мой взгляд вопрос должен решаться в судебном порядке.
Они их по 10 р. штука продают. А маркировать так же обязаны
После этого возвращайтесь и мы с вами снова обсудим эту тему. А пока ваша выборка не репрезентативна.
Самые частые проблемы это не потеря GS, а задвоение кавычек, потеря точек с запятой и появление точки с запятой в конце строки.
Именно поэтому я всегда рекомендую забирать эти "волшебные" коды в csv формате из СУЗ.
Сейчас много софта, которые из этого csv вам хоть 500 раз распечатают повторно коды.
Сам одну такую программу написал и в массы выложил.
При этом црпт получает 50 копеек за каждый выпущенный код (это 12 р с каждого блока сигарет). А производители эти 50 копеек вшивают в себестоимость.
В итоге покупатель оплачивает все нововведения. Как и стоимость обновления оборудования.
Уж лучше бы бюджетные потратили. А то помимо НДС теперь и за КМ будет платить покупатель.
По идее часть этого функционала пытаются спихнуть на операторов ОФД и ЭДО.
Продал товар по накладной через ЭДО, данные сами ушли в ЦРПТ. Пробили чек на кассе — данные ушли в ЦРПТ от оператора ОФД.
Однако интеграция с ЦРПТ что для первых, что для вторых — еще то увлекательное приключение.
Схема работы следующая — при пробитии товара необходимо просканировать уникальный код товара. Он укладывается в чек и фискальную память (тег 1162). Далее передается в ОФД в составе чека.
ОФД обязано выявлять такие чеки и передавать их в ЦРПТ.
Сейчас ряд ОФД активно подумывает, а не брать ли с пользователей доп денюжку за передачу чеков в ЦРПТ.
Так же операторы ЭДО при обнаружении УПД с кодами маркировки обязаны передавать информацию в ЦРПТ. Так отслеживается смена владельца кода маркировки.
Как отслеживается текущее местонахождение кода — не знаю. Скорее всего уже WMS владельца должна отчитываться.
У нас логика перехода состояний документа в документообороте сейчас на ней сделана. Работой вполне довольны. Единственно что не сразу поняли — в экшны лучше по минимуму логики вкладывать и просто больше экшнов делать.
Удобно, что через пару замен в коде можно UML диаграмму получить. И наоборот — UML диаграмму легко в код перевести.
Кстати, в sendEvent можно отправить не только ивент, но и Message с ивентом. В хедерах которого можно протащить доп информацию и использовать ее в экшенах.
А так в целом — спасибо за более подробный разбор библиотеки. На мой взгляд стейт машина на много лучше, чем куча if/else и switch.
Оставить формочку заведения тикетка, после нажатия кнопки «отправить» просто очищать ее и выводить надпись «Тикет создан». На телефон настроить автоответчик — «Мы вас любим, мы о вас заботимся, ожидайте». И никогда не отвечать. Сплошной рай для техподдержки.
Как-то так.
А сервисные компании, как правило, заранее заботятся о пост продажном сопровождении. Т.к. это часть их бизнеса. И услуга сопровождения после продажи — отдельный источник дохода. Причем регулярного дохода.
Вашим конкурентам в комментарии к другой статье я уже подробно объяснил, чем мне не нравятся облачные решения по сервис-деску и почему я считаю область их применения достаточно узкой.
У вас цены, кстати, более приемлемые, чем у того конкурента :). Поэтому для малых организаций можно попробовать.
Я понимаю, что вы всячески продвигаете решение ServiceNow. Это реклама. Скорее всего вы сотрудник фирмы Техносерв. Учитывая как вы работаете с возражениями, то возможно даже из отдела продаж. Или маркетинга
В рекламируемом вами решении есть все недостатки облачного решения — компания должна постоянно платить поставщику. Ежемесячно. Увеличились потребности — увеличилась плата. Очень часто на больших объемах это банально не выгодно.
Даже в минимальной конфигурации предлагаемое вами решение стоит порядка 96 000 р в месяц. И да — в целях рекламы указывать цену без НДС на мой взгляд не самый лучший трюк.
Если идет установка on-premise — то покупатель помимо ежемесячной платы минимум в 96 000 р получает еще все затраты на поддержание оборудования. А у Техносерва это заявлено как одно из ключевых преимуществ — не нужно тратиться на инфраструктуру и за счет этого экономим.
За эти деньги можно позволить себе в штат отдельного программиста, который будет вылизывать имеющиеся опенсорсные решения и делать их интеграцию со всеми внутренними системами.
Не знаю на чем написано продвигаемое вами решение, но скорее всего код закрытый. Почти наверняка — хотите доработку, заплатите нам. За одну только интеграцию с AD этой замечательной системы разработчики хотят 45 000 р. Сколько захотят за допилку под конкретные нужды компании?
И один из очень больных вопросов облаков — надежность хранения корпоративных данных. Если пользователь пришлет запрос «у меня не открывается годовой фин отчет, помогите» — где гарантия, что этот самый отчет будет храниться только в облаке и никогда никуда не уйдет?
Лично мое мнение — облачные решения приемлемы либо для небольших компаний, пока нет больших объемов и особо не стоит вопрос сохранности корп данных. Либо для второстепенных для компании функций.
Если компания готова ежемесячно выделять 100 000 р. на софт, который нужен только ИТ отделу для его внутренних нужд… то мне кажется ИТ директор найдет этому бюджету иное применение, при наличии большого количества бесплатных/более дешевых/не SaaS аналогов.
В 1С ИТИЛ в нашем варианте это было два документа — перемещение со склада на рабочее место и документ списание. Каждое рабочее место — отдельный склад. Комплектацией/разукомплектацией занимались только для системников, когда кишки меняли.
Здесь вопрос к вам — зачем так сложно процессы настраивали? Система должна подстраиваться к процессам, а не процессы к системе.
Конкретно на текущем месте работы у нас внутренняя сеть. Практически полностью изолированная от интернета. Так что никакое облачное решение не приемлимо.
И третьи лица могут сколько угодно говорить о сохранности моих данных. Не верю. Если возникнет нужда — сольют данные. Либо вирусня стянет.
OTRS понравился легкостью, скоростью, гибкостью. Достаточно простая интеграция, гибкие настройки, легкий интерфейс. Все в браузере. Есть напоминалки, алерты, удобно настраивать тригеры и т.д. Достаточно удобная база знаний.
Но вот что касается учета активов, хранения документов — беда-беда. Все весьма неудобно, неинтуитивно, много чего надо ручками заводить.
1С ИТИЛ — это 1С. А оно сильно именно учетом. Есть приходные документы, документы перемещения, печатные формы. Вплоть до интеграции с бухгалтерией. Но мы так далеко не пошли.
А вот с обработкой инцидентов в 1С было сложнее — достаточно много лишних действий приходилось делать.
Так что в ОТРС понравился блок управления инцидентами, в 1С ИТИЛе блок учета. При должном количестве времени и наличии программистов думаю и то и другое смогли бы довести до уровня «конфетки». Выбирая из них двоих все-таки остановился бы на 1С ИТИЛе. 1С-ников проще найти :).
С другими системами плотно не работал, сказать что-то трудно.
Там еще xml конфиг пришлось править, чтобы в веб интерфейсе появилась возможность Invoker включить.