1с

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

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

Представим себе человека и некоторую учетную систему. Для простоты, пусть это будет некий идеальный складской учет. Что-то на склад приходит, что-то уходит. Для каждой операции существует т.н. первичный документ. Данные первичных документов незамедлительно вводятся в базу. Задача человека организовать рациональный контроль за процессом, с целью не допустить расхождения между первичными документами и данными в учетной системе.
Человек принимает решение сверять каждый первичный документ с данными в системе. Но тут возникает проблема. Дело в том, что нельзя просто один раз сверить конкретный документ с данными системы. Потом отложить этот документ в сторону и забыть о нем навсегда. Данные в системе могут измениться и это потребует повторной сверки. А самое печальное заключается в том, что тот, кто изменил данные не обязательно будет гореть желанием сообщить вам об этом. Напротив, в его интересах будет чтобы никто никогда не узнал об изменении. Например, некто меняет в приходном документе "110 штук по цене 101 рубль" на "101 штука по цене 110 рублей". Присваивает себе 9 штук. И не без оснований надеется, что ни сверка с контрагентом (110х101=101х110), ни инвентаризация ничего не выявят. Вы можете создать сколь угодно изощренную систему прав доступа. И не менее изощренную систему логирования изменений. Результатом ваших усилий будет всего лишь возросшее у вас же чувство уверенности. И это ровно то, что полностью устраивает того, кто увел у вас 9 штук. Это хорошо, скажет он себе, что они так уверены. Пусть и дальше будут уверены так же. Или еще сильнее. Надо им еще пару идей подкинуть. Нет никакого другого способа отследить изменения, кроме как производить каждый раз сверку абсолютно всех документов. Раньше такое решение даже и не приходило никому в голову. Или, по крайней мере, не задерживалось там дольше микросекунд. Это представлялось очевидно невозможным. Но... как совершенно верно подметил один русский поэт: невозможное возможно.

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

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

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

Вернемся к процессу. Первая порция документов сверена и занесена в журнал. Далее происходит самое важное действие. Человек переписывает последний ключ в какое-нибудь секретное место (например на бумагу, это будет самый надежный вариант; если использовать SHA256, это займет не более 2 минут, я проверял). Теперь сеанс сверки можно считать завершенным.

Через некоторое время на складе происходит еще какое-то количество событий и появляются новые первичные документы. Человек приступает к следующему сеансу. Первым делом он сверяет последний ключ в журнале с тем, что у него хранится в секретном месте. Здесь происходит самое интересное. Сверяя некоторое, не очень большое, количество символов, человек визуально контролирует неограниченный объем данных. Убедившись в том, что ключи совпадают, человек далее проделывает следующее:

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

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

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

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

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

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

На этом простом примере я хотел показать, что технологии могут и должны быть гуманными. Не ограничивать человека, а напротив, открывать ему новые горизонты. Конечно, контроль данных - тема хотя и важная, но это далеко не все, что есть в учете. Я уверен, будут (или даже уже есть) и другие технологии, расширяющие возможности человека в области учета. Учет, как институт защиты интересов участников бизнеса, конечно же не умер. Просто он становится другим. Лучше и надежнее. При этом роль человека не уменьшается, а наоборот, по мере того, как растут возможности человека, растет и его роль в процессе.

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

Кейс 1: несколько карточек соответствуют 1 товару

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

Решение:

В личном кабинете маркетплейса, возьмем для примера Ozon, продавец заводит две позиции с разными артикулами чехол прозрачный для iPhone 7 и чехол прозрачный для iPhone 8. По факту это один товар, поскольку он подходит для обоих смартфонов.

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

Для этого в разделе "RDV:Товарный каталог", в "Управлении товарным предложением" нужно создать связку номенклатур. В этом документе отображается один товар в двух строках, артикул будет совпадать, но будут отличаться идентификаторы в личном кабинете и другие параметры, потому что на маркетплейсе одному товару соответствуют две карточки.

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

Кейс 2: составные товарами и промонаборы

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

Решение:

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

Как это можно отобразить в системе 1С? В личном кабинете создаются две позиции: велосипед двухколесный и колесо, по которому передаются остатки.

Данные процессы осуществляются в документе "Управление товарным предложением". В нем указаны позиции велосипеда и шины с различными идентификаторами. На каждую позицию устанавливается цена и передается вместе с остатком.

Если продавец хочет сделать сборку, то в RDV Маркет можно создать варианты комплектации в разделе - "Варианты комплектации номенклатуры". Например, "Велосипед черный сборный", который состоит из трех частей: каркаса, сидушки и двух шин. Мы создаем вариант комплекта с указанием комплектующих - именно это увидит кладовщик в момент сборки. На основании этой информации 1С высчитывает, сколько велосипедов можно собрать.

Далее в отчете "Остатки и доступность товаров для маркетплейсов" продавец может посмотреть детальнее информацию по заказу. Рассмотрим тот же пример - "Велосипед черный сборный", по которому есть остаток на складе 1 шт. При этом 1С пишет, что для заказа доступно 15 шт. Почему так происходит? Все просто - продавец может собрать велосипеды из 3х позиций (каркас, сидушка, шина). И поскольку в наличии есть еще 14 сидушек для велосипеда, то эти данные 1С учитывает и транслирует на маркетплейс цифру 15. Если будет продана отдельно составляющая, например, шина, то остаток пересчитается.

Таким образом, работник склада в АРМ кладовщика увидит, если заказ дополнительно потребует сборки. Для этого нужно перейти в задание на сборку - собрать и отгрузить товар.

Кейс 3: Упаковки и штучные товары

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

Решение:

Допустим, поставщик продает на Яндекс.Маркете корм для кошек Whiskas в пакетиках. У него есть артикул и цена. Кроме того, у продавца в наличии такой же товар, который поставляется упаковками, состоящими из 24 шт. У упаковки другая цена и артикул. На странице товара на маркетплейсе можно увидеть, что эти товары относятся к одной карточке. Несмотря на это, продавец может транслировать остатки и цены как за одну штуку, так и за упаковку.

Как это реализовано в RDV Маркет? В "Управлении товарным предложением" создается товарное предложение, с помощью которого настраивается обмен по ценам и остаткам. С точки зрения учета у продавца будет один товар влажный корм Whiskas. Разница заключается в том, что он представлен в упаковке по 24 шт. и по 1 шт. В документе отображается один товар в двух строках, артикул совпадает, но отличаются упаковка и идентификаторы в личном кабинете.

Стоимость упаковки в 1С вычисляется автоматически, но при необходимости цену можно изменить. Это можно сделать в разделе "Установка цен товаров": нажать на кнопку "Создать", выбрать нужный маркетплейс и установить цену за одну штуку и упаковку. После проведения документа информация сразу уйдет на маркетплейс.

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

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

И было сказано слово: "Маркировка!" И набежали тучи, и застили небо. И повис в воздухе вопрос: "Что делать?" И закралась надежда: "Авось пронесёт!"

Часть 1. Глаза боятся, а руки делают

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

1. Определить Владельца бизнес-процесса "Маркировка" - центр ответственности и Ключевого пользователя - центр компетенций по операциям маркировки товара/продукции.

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

4. Ввести в рабочую группу юриста компании, в задачи которого входит экспертиза нормативной документации по маркировке и отслеживание изменений в правовом поле.

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

6. Разработать план-график запуска процесса маркировки с учетом графика запуска маркировки в отрасли.

7. Сотруднику компании, имеющему право подписи документов без доверенности, пройти процедуру регистрации в личном кабинете "Честного знака" (далее ЛК ЧЗ) . Подключить тестовый ЛК ЧЗ.

8. Выпустить усиленную квалифицированную электронную подпись (УКЭП) с расширением "Маркировка" для Ключевого пользователя и подключить его в рабочий и тестовый ЛК ЧЗ с ролью "Администратор".

9. Выделить 25 - 40 часов Ключевому пользователю по маркировке на изучение нормативной документации, пользовательских инструкций, видео-инструкций и т.д..

10. Настроить интеграцию между тестовой средой ГИС МТ ("Честный знак") и тестовой учетной системой, используя стандартные механизмы.

11. Ключевому пользователю провести функциональное тестирование операций по маркировке. Результаты оформить Протоколом.

12. Разработать схему бизнес-процессов компании и встроить в неё операции по маркировке. Согласовать с участниками рабочей группы.

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

14. Сформировать пул задач на доработку учетной системы компании, в т.ч. по интеграции с ГИС МТ. В зависимости от имеющегося в распоряжении времени установить задачам первый или второй приоритет, разработать график реализации.

15. Выполнить доработки учетной системы в соответствии с задачами первого приоритета.

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

17. При наличии технических и производственных возможностей выполнить пилотный запуск процесса маркировки.

18. Подготовить инструкции для пользователей, при необходимости провести обучение. Подключить пользователей в рабочий ЛК ЧЗ, настроить УКЭПы в учетной системе.

19. Запустить процесс маркировки в эксплуатацию. Контролировать корректность проведения операций и передачи данных в "Честный знак".

20. Актуализировать задачи второго приоритета на доработку учетной системы. Выполнить доработки в соответствии с действующим в компании порядком ведения разработки программного обеспечения.

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

Часть 2. Спасение утопающих - дело рук самих утопающих

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

Не спасает ситуацию вариант массовой загрузки данных в ГИС МТ через csv-файл или xml-файл. Формат csv требует дополнительных действий пользователя: экранирование специальных символов, изменение настроек Windows, контроль разделителей и формата кодировки.

Вариант xml-файла, как способ перегрузки данных из учетной системы в ГИС МТ, не вызвал бы вопросов, если бы не формат вывода данных в ЛК Честный знак в виде строки. Например, документ Отгрузка в ЛК Честный знак предстанет перед грузоотправителем и грузополучателем в следующем виде.

Не существует в ЛК Честный знак и возможности экспортировать данные в файлы Excel или csv. Разве что выгрузка из Национального каталога отчета по карточкам товара, находящихся в статусе Опубликована.

Оптимальным вариантом взаимодействия с ГИС МТ является обмен данными через методы API. Для этого можно воспользоваться либо сторонними сервисами (Мой склад, Таском и т.д.), либо стандартными механизмами, встроенными в учетные системы, либо разработать функционал с нуля.

Часть 3. На 1С надейся, но сам не плошай

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

1. Различие в названиях объектов и реквизитов между 1С и ЛК Честный знак. Например, документ Ввод в оборот спрятан за названием Маркировка товаров ИС МП. В документации на сайте https://честныйзнак.рф используется сокращение ГИС МТ, а в 1С - ИС МП. Способ ввода в оборот Производство вне ЕАЭС в 1С называется Импорт и т.д.

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

3. Через сервис Обмен с ИС МП (обувь, одежда, табак) невозможно получить актуальный статус кода маркировки или списка кодов маркировки. Статус кода можно увидеть непосредственно в ЛК Честный знак.

4. Для того, чтобы узнать под каким номером упал документ в ГИС МТ, необходимо пройти квест по Протоколу обмена.

5.1С не запрашивает актуальный статус документов в ГИС МТ, поэтому в журналах присутствуют документы со статусом "ошибка", тогда как по факту в ЛК Честный знак пользователь видит статус обработан. Возможность изменить статус вручную не предусмотрена.

6. Через сервис Обмен с ИС МП (обувь, одежда, табак) невозможно создать Заказ на эмиссию со способом ввода в оборот Перемаркировка. Как следствие пользователю необходимо выпустить коды маркировки непосредственно из ЛК Честный знак. Документ Перемаркировка, который вводит коды в оборот, не только не предусматривает возможности ввода в оборот без указания предыдущего кода, но и реализован с ошибками. Требуется тестирование функционала и доработки.

7. Если в настройках Интеграция с ИС МП включены две товарные категории Обувь и Товары легкой промышленности и одежды, то при загрузке из ГИС МТ документов Приемка, в реквизите Вид продукции система проставит Обувь, при этом нет возможности внести изменения вручную.

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

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

В типовом функционале ERP существует ряд ограничений:

• Отсутствуют инструменты по инвентаризации ТМЦ в эксплуатации, что для крупных компаний является обязательной процедурой.

В системе в принципе нет возможности сформировать документы для проведения инвентаризации ТМЦ в эксплуатации. Из-за этого бухгалтеру приходится формировать ведомости в xls, из-за чего растет вероятность ошибок, а также увеличивается время на подготовку необходимой информации.

• Нет единого отчета, который бы аккумулировал в себе все сводные данные по учету спецодежды.

Количественные и суммовые данные разбросаны по нескольким отчетам. Например, чтобы получить информацию о количестве и стоимости ТМЦ в эксплуатации, нужно сформировать ОСВ (оборотно-сальдовую ведомость) по счету и типовой отчет "ТМЦ в эксплуатации", а затем сопоставить данные отчета в единый. При больших объемах данных такой процесс, естественно, усложняет работу пользователям и влияет на рост количества ошибок.

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

• Не отражается движение спецодежды по счетам МЦ и 10.11 в рамках одного месяца, если она была передана в эксплуатацию в этом же месяце.

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

Ограничение типового функционала 1С:ERP заключается в данном случае в том, что по счетам МЦ и 10.11 не будет отображаться движение спецодежды в том же месяце, в котором произошла передача и было сделано списание или перемещение. Пользователи не смогут получить полные сведения по эксплуатации одежды в апреле, в котором она и была передана, данные будут отображены только в мае. Такой формат противоречит полноте отображения данных.

• Расчет остаточной стоимости ТМЦ, стоимость которых была погашена при передаче в эксплуатацию.

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

Сейчас в типовой системе 1С:ERP вся спецодежда и спецоснастка (согласно ФСБУ 5), которая передается в эксплуатацию, списывается на расходы сразу, независимо от срока службы. Проблема заключается в том, что при полном списании, когда не учитывается реальный срок службы спецодежды (в учете 2021 в системе не заложены такие документы), нельзя автоматически рассчитать остаточную стоимость, которая важна для формирования возврата средств за спецодежду и финансового результата при реализации.

Может ли автоматизация процессов в 1С решить насущные проблемы учета?

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

Рассматривая данные цели в разрезе учета спецодежды в 1С:ERP, для их достижения необходима автоматизация учета ТМЦ. Для решения вопроса оперативности, полноты и достоверности данных о ТМЦ в эксплуатации был разработан отчет "ТМЦ в эксплуатации" на базе типового отчета 1С:ERP.

Данный отчет позволяет:

• увидеть суммовые и количественные показатели в одном отчете, в разрезе всей необходимой аналитики;

• работать без ограничений по отражению ТМЦ, срок службы у которых закончился. В отчете отражаются все ТМЦ, числящиеся в учете, но с помощью настроек пользователь может сам установить отбор, показывать ему такие ТМЦ или нет;

• увидеть суммовые показатели по перемещениям и списаниям ТМЦ в том периоде, в котором они отражены по документам, независимо от даты передачи их в эксплуатацию;

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

Важный момент: отчет подключается к 1С как внешний инструмент и не рушит текущие процессы системы, в которой работает компания.

Разбираемся с инвентаризацией

Чуть выше мы говорили о том, что 1С:ERP в принципе нет документов по инвентаризации. Но данный процесс нельзя обходить стороной. Удачной альтернативой ручному труду будет является проведение доработки самой системы 1С, учитывая нюансы самой компании, так как тут все индивидуально.

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

Документ "Инвентаризационная ведомость для ТМЦ в эксплуатации" заполняется автоматически по данным забалансового счета МЦ по сумме и количеству с учетом данных оперативного контура, что позволяет получать актуальные данные после проведения документов перемещения и списания, независимо от формирования проводок в БУ. При этом в документе есть возможность формирования печатных форм ИНВ-3 и ИНВЕ-19.

Автоматическое заполнение реквизитов в документах по учету ТМЦ в эксплуатации

В рамках разработки отчета были доработаны механизмы, позволяющие автоматизировать:

• заполнение стоимости ТМЦ при возврате из эксплуатации, если на момент возврата не вышел срок службы или в принципе есть остаточная стоимость на счете 10.11;

• заполнение реквизитов Физическое лицо получатель при перемещении.

Разумеется, можно рассматривать альтернативные решения автоматизации. Например, если компания будет формировать оборотку, а затем загружать заполненный excel-файл в свою систему. Но учитывая объемы работ, с уверенностью можно сказать, что такой способ повлияет на рост количества ошибок.

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

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

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

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

Поглядим, чему же программисты могут научиться у каменщика дяди Толи.

Исходная на стройке

На стройке работали три каменщика Костя, Рустам и дядя Толя. Косте было лет 25, Рустаму под 40, дяде Толе 50-60 (видимо, поэтому к его имени добавили уважительное дядя). Я, и еще человек 15 студентов и школьников, были разнорабочими принеси, подай, иди дальше, не мешай.

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

А теперь немного прервёмся и посмотрим, как дела у программистов.

Исходная на проекте

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

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

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

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

А теперь вернёмся на стройку и поглядим, как дела у дяди Толи и его друзей.

Процесс на стройке

Костя и Рустам посмеивались над дядей Толей, потому что он всё делал не по уму просто брал и фигачил. На любом растворе, из любого кирпича. Костя и Рустам требовали качественных материалов.

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

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

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

Так и работали. Дядя Толя шёл примерно с той же скоростью, что Костя и Рустам вместе. Начальство не проявляло к работе дяди Толи никакого интереса. За Костей и Рустамом присматривали. Но, увы, не досмотрели.

А пока вернёмся к программистам и разработчикам.

Процесс на проекте

Программисты работали от проблемы. Сказали пользователям пишите, звоните, если чё не получается, будем вместе разбираться и решать. Когда их спросили, почему они не смотрят на систему в целом, те ответили чего на неё смотреть, она точно рабочая, мы её много раз внедряли. Это ж 1С:ERP. Там не всё гладко, но почти всё точно работает.

Им сказали проведите обучение всех пользователей. Программисты сказали нафига? Чтобы денег побольше содрать? Итак проект на волоске висит, зачем усугублять. Просто прошлись по пользователям, поспрашивали, посмотрели, и обучили по месту тех, кто был совсем ни в зуб ногой. Таких, кстати, менее четверти оказалось.

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

Разработчики с аналитиками взяли месяц на анализ доработок, выполненных предыдущими чертями. Чего они там анализировали им одним известно. Но счет выставили на 3 человекомесяца нетрудно догадаться, что анализировали в шесть глаз. В итоге пришли к неутешительному выводу все доработки надо переделывать, с нуля. Анализ, проектирование, разработка, тестирование, опытная эксплуатация.

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

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

Выход предложили программисты. Сказали разрабам: вы там пока думайте и разрабатывайте, а мы уберём самые гнусные косяки в поделке предыдущих чертей. А когда закончите перекинем данные. На том и порешили.

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

Но вернёмся на стройку.

Результат на стройке

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

Оставить-то они оставили. У дяди Толи всё, как задумано в проектной документации. У Кости и Рустама дырки под окна получились на разной высоте, с разницей примерно в полметра. И одно окно было смещено на метр в сторону.

Дядя Толя смеялся. Мы, разнорабочие, смеялись. Костя и Рустам махали руками и что-то громко кричали. Но прораб кричал громче, и некоторые слова даже можно процитировать. Например, зато, ***, кирпичи у вас только целые, и раствор, ***, свежий!.

А что у программистов с разработчиками?

Результат на проекте

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

Но пользователи ничего не решают на проекте. Через три месяца проснулись разработчики и аналитики, выкатили своё Детище примерно ту же функциональность, только написанную с нуля. Ну и акт на 9 человекомесяцев. А счет на оплату не давали, потому что работы были предоплачены. И пришло время начальству клиента что-то решать.

Что может решить руководитель проекта со стороны заказчика, если он подписал в оплату счет на 9 человекомесяцев? Тут и к бабке не ходи. Он решил внедрять результат работы разработчиков и аналитиков. Несмотря на то, что поделка чертей уже была доведена до ума и устраивала пользователей.

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

Через две недели разработчики с аналитиками сбежали, как предыдущие черти. Кто в срочный отпуск, кто сказался больным или очень-очень занятым. Заказчик был в ступоре одно не работает, второе работает, но использовать нельзя (РПЗ запрещает).

Дело быстро дошло выше РПЗ до директора. Тот, не долго думая, повелел остановить все работы. И начались длинные разбирательства за что оплатили 9 человекомесяцев, почему разработчики с аналитиками сбежали, что они там в ТЗ написали, кто подписывал и т.д.

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

Чем закончилось на стройке

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

Исправлял, естественно, дядя Толя. Костю и Рустама выгнали в тот же день.

А чем закончилось на проекте?

Чем закончилось на проекте

Директор собрал Большое Совещание. Со стороны подрядчика приехали программисты (разработчики с аналитиками, как мы помним, сбежали). Директор кричал и ругался, требовал объяснения и решения.

Когда проорался, программисты спросили так тебе объяснение или решение надо? Тот немного опешил, но сказал и то, и другое. Программисты спросили а в каком порядке? Сначала решение, потом объяснение.

Программисты и говорят есть быстро и бесплатно, есть долго и дорого. Что выбираешь? Директор выбрал быстро и бесплатно. Программисты сказали выкинуть то, что сделали разработчики с аналитиками, и пользоваться предыдущей версией доработки.

Директор опешил чё, говорит, так можно было? И пристально посмотрел на РПЗ. Тот начал что-то тараторить, но директор его грубо прервал.

Через пару дней всё заколосилось. Правда, разборки про 9 человекомесяцев идут до сих пор.

Извлечь максимум из новостей в интернете

Навеяно статьей Почему я по-прежнему пользуюсь RSS

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

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

Будут следующие части:

1. Часть 1:

• Какую информацию я вообще потребляю через новости;

• Чтение программами (rss-агрегаторами) - что использую лично я;

• Форматы RSS и Atom, как их можно обрабатывать программами на локальном компьютере;

2. Часть 2:

• Автоматизаторы (zapier, ifttt);

3. Часть 3:

• Как я автоматизировал доставку аудио-подкастов на свой плеер.

Часть 1

Какую информацию я вообще потребляю с помощью новостей

Раньше, когда я много времени проводил в метро по пути на работу и обратно, то загружал новости в свой планшет и потом, уже без интернета спокойно читал то, что было интересно (не все помнят, но интернет в метро был не всегда!). Например, баш и ЖЖ поставляют контент в формате RSS. Новости со всего мира от лента.ру есть в формате RSS. Поговаривают, что в древние времена и твиттер можно было читать через ленту новостей в формате RSS! Но потом пришли жадные менеджеры и сказали, что так они не получат много денег, поэтому RSS исчез из твиттера.

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

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

Чтение программами (rss-агрегаторами)

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

В какой-то момент пришлось удалить читалку новостей с планшета, т.к. это сильно мешало сну - в постели чтение новостей перед сном могло занимать до часа. Но это уже другая история.

Для десктопа я раньше использовал RSS Owl:

А потом с удивлением открыл для себя продукт от JetBrains: OMEA Reader:

Функционал у продукта JetBrains просто космический, поэтому как только я на него перешёл, то уже и не уходил:

• можно ставить комментарии к новостям

• можно фильтровать новости и по отборам назначать тэги, выделять цветом или выдавать оповещения на экране

• иерархическая группировка лент новостей

• и многое-многое другое.

Форматы RSS и Atom, как их можно обрабатывать программами на локальном компьютере

Новости, по сути - это простой xml-файл. Есть формат RSS (очень старый формат, непонятно кто его поддерживает и будет ли он развиваться). Мне он не очень нравится:

• из-за формата дат - <pubDate>Sun, 28 May 2017 09:00:00 GMT</pubDate>, что затрудняло для меня автоматическую обработку

• из-за того, что непонятна спецификация RSS, (во всяком случае я нашёл несколько разных вариантов). Расскажу про особенности его обработки дальше. Тем не менее, это самый узнаваемый и устоявшийся формат, известный всем.

На замену RSS фирма Google придумала свой формат - Atom, и вроде бы даже поддерживает его.

Файлы из интернета, в том числе и новости, можно читать с помощью curl, wget и (почему-бы и нет?) с помощью Power-shell.

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

Curl:

chcp 65001    curl ^    --header "user-agent: cURL automated task" ^    --output "%TEMP%\updates.xml" ^    "https://news.webits.1c.ru/news/Updates/atom"

Если на компьютере включен Антивирус Касперского, то можно получить ошибку curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - Функция отзыва не смогла произвести проверку отзыва для сертификата. Я просто отключил антивирус на 5 минут.

Файл записывается без BOM, что может вызвать проблемы с дальнейшей обработкой. Наверное это как-то настроено на сервере.

Power-shell:

# file: Get-News-001.ps1  Clear-Host    $webClient = New-Object Net.WebClient  $webClient.UseDefaultCredentials = $true  $webClient.Proxy.Credentials = $webClient.Credentials  $webClient.Headers.Add("user-agent", "PowerShell automated task")    # Подозреваю, что из-за того, что данные передаются без BOM, то получение данных  # через DownloadString с последующим выводом выдаст на экран кракозябры.  # Поэтому в явном виде преобразуем в UTF8  $newsData = $webClient.DownloadData("https://news.webits.1c.ru/news/Updates/atom")    Write-Host ([System.Text.Encoding]::UTF8).GetString($newsData)

Не забываем, что в power-shell надо включить возможность запуска неподписанных макросов. Это делается или в настройках вашей IDE, или прямо в командной строке, параметром -ExecutionPolicy=RemoteSigned

powershell -file "Get-News-001.ps1" -ExecutionPolicy=RemoteSigned

Что нам это даст? Пока ничего интересного. Но так как новости - это структурированный текст в формате xml, почему-бы не обработать его? Например, найти новость по значению какой-нибудь категории?

Найдём в новостях от 1С новости со значениями категорий Вид новости обновления=Публикация новой версии и Продукт=Комплексная автоматизация

Пример кода:

# file: Get-News-002.ps1Clear-Host# Настройки отбора, в виде массива$CategoryProducts = @(    # "Продукт=1С:Библиотека стандартных подсистем", # Заполнить!    "Продукт=Комплексная автоматизация" # Заполнить!)$CategoryNewsTypes = @(    "Вид новости обновлений=Публикация новой версии")$webClient = New-Object Net.WebClient$webClient.UseDefaultCredentials = $true$webClient.Proxy.Credentials = $webClient.Credentials$webClient.Headers.Add("user-agent", "PowerShell automated task")# Т.к. данные без BOM, то лучше явно преобразовать.$newsData = $webClient.DownloadData("https://news.webits.1c.ru/news/Updates/atom")[xml]$news = ([System.Text.Encoding]::UTF8).GetString($newsData)#[xml]$news = Get-Content -Encoding UTF8 -LiteralPath "$($env:TEMP)\updates.xml"for($c1=0;$c1 -lt $news.feed.entry.Count;$c1++){    # Получим новость    $entry = $news.feed.entry[$c1]    $ProductName    = ""    $bFoundProduct  = $false    $bFoundNewsType = $false    for($c2=0;$c2 -lt $entry.category.Count;$c2++){        # Получим и проверим категории новости        $CategoryProducts | ForEach-Object {            if($entry.category[$c2].term -eq $_){                $ProductName = $entry.category[$c2].term                $bFoundProduct = $true            }        }        $CategoryNewsTypes | ForEach-Object {            if($entry.category[$c2].term -eq $_){                $bFoundNewsType = $true            }        }    }    if ($bFoundProduct -and $bFoundNewsType) {        Write-Host ("Найдена подходящая новость. УИН: {0}, Заголовок: {1}" -f ($entry.id, $entry.title))    }}

Уже интереснее. А что мы можем сделать, если нашли нужную категорию? Например, можно самому себе отправить письмо.

Напишем код сразу так, чтобы письмо о выходе новости не отправлялось несколько раз - в отдельном файлике будем хранить entry.id - уникальный идентификатор новости и дату отправки.

# file: Get-News-003.ps1Clear-Host# Файл с информацией об отправленных email.$sendedEmailsPath = "$($env:TEMP)\sended.csv" # Заполнить!if(Test-Path $sendedEmailsPath){    # Файл существует} else {    # Файла не существует - создать пустой файл    Add-Content -LiteralPath $sendedEmailsPath -Encoding UTF8 -Force -Value ""}$sendedEmails = Get-Content -LiteralPath $sendedEmailsPath -Encoding UTF8 -Force# Настройки почты$CurrentDate        = Get-Date $CurrentDate_String = Get-Date -Format "yyyy-MM-dd HH:mm:ss"$From               = "news_center_tester@mail.ru" # Заполнить!$To                 = "old-coder-75@mail.ru" # Заполнить!$EncodingUTF8       = [System.Text.Encoding]::UTF8$UserName           = "news_center_tester" # Заполнить!$Password           = "*****" # Заполнить!$Credential         = New-Object -TypeName System.Management.Automation.PSCredential($UserName, (ConvertTo-SecureString $Password -AsPlainText -Force))$SMTPServer         = "smtp.mail.ru" # Заполнить!$SMTPPort           = 587 # Заполнить!# Настройки отбора, в виде массива$CategoryProducts = @(    # "Продукт=1С:Библиотека стандартных подсистем", # Заполнить!    "Продукт=Комплексная автоматизация" # Заполнить!)$CategoryNewsTypes = @(    "Вид новости обновлений=Публикация новой версии")$webClient = New-Object Net.WebClient$webClient.UseDefaultCredentials = $true$webClient.Proxy.Credentials = $webClient.Credentials$webClient.Headers.Add("user-agent", "PowerShell automated task")$newsData = $webClient.DownloadData("https://news.webits.1c.ru/news/Updates/atom")[xml]$news = ([System.Text.Encoding]::UTF8).GetString($newsData)#[xml]$news = Get-Content -Encoding UTF8 -LiteralPath "$($env:TEMP)\updates.xml"for($c1=0;$c1 -lt $news.feed.entry.Count;$c1++){    # Получим новость    $entry = $news.feed.entry[$c1]    $ProductName    = ""    $bFoundProduct  = $false    $bFoundNewsType = $false    for($c2=0;$c2 -lt $entry.category.Count;$c2++){        # Получим и проверим категории новости        $CategoryProducts | ForEach-Object {            if($entry.category[$c2].term -eq $_){                $ProductName = $entry.category[$c2].term                $bFoundProduct = $true            }        }        $CategoryNewsTypes | ForEach-Object {            if($entry.category[$c2].term -eq $_){                $bFoundNewsType = $true            }        }    }    if ($bFoundProduct -and $bFoundNewsType) {           Write-Host ("Найдена подходящая новость. УИН: {0}, Заголовок: {1}" -f ($entry.id, $entry.title))        # Проверим, была ли информация уже отправлена по email?        # Информация об отправке email хранится по каждому id новости в лог-файле $sendedEmailsPath.        $bEmailWasSent = $false        foreach ($sendedEmail in $sendedEmails) {            if ( $sendedEmail.StartsWith($entry.id) ) {                $bEmailWasSent = $true                break            }        }        # По этой новости ещё не создавался email.        if ($bEmailWasSent -eq $false){            Write-Host "По подходящей новости отправляем емейл..."            # Отправить почту            $Subject = $entry.title            $Body = "<h1>Выход новой версии</h1>" + `                "<p>" + `                $entry.summary."#cdata-section" + `                "</p>"            Send-MailMessage `                -From $From `                -To $To `                -Body $Body `                -BodyAsHtml `                -Credential $Credential `                -Encoding $EncodingUTF8 `                -SmtpServer $SMTPServer `                -Subject $Subject `                -Priority High `                -UseSsl `                -Port $SMTPPort `                -Verbose                            # Записать в лог, чтобы повторно не отправлять почту по этой новости            $LogString = $entry.id + ";" + $CurrentDate_String + ";"            Add-Content -LiteralPath $sendedEmailsPath -Encoding UTF8 -Force -Value $LogString        } else {               Write-Host "По подходящей новости уже был отправлен емейл."        }    }}

Хм. Не хочется вызывать скрипт ручками. Было бы неплохо это вызывать регулярно, например каждые 2 часа. Настроим "Планировщик заданий". В окне запуска (Win+R) вызовем "taskschd.msc".

Добавим новое расписание:

Настроим частоту запуска каждые 4 часа (триггер):

Добавим запуск скрипта (Действие):

Путь к программе powershell.exe надо указывать полный. И в аргументах - или полный путь к скрипту в параметре -file, или заполнить Рабочая папка.

Немного тюнинга - не люблю всплывающие окна. А при выполнении задания по расписанию, каждые 4 часа вылезает на весь экран окно выполнения скрипта. Можно запускать код power-shell через SilentCMD или CreateProcessHidden. Правда, на последнюю ругается антивирус, но не сильно.

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

Что ж, надеюсь, что информация оказалась полезной.
С интересом почитаю комментарии.

Остальные главы постараюсь в ближайшее время выложить.

Что такое iDempiere?

iDempiere ERP/CRM - это бесплатное ПО с открытым исходным кодом. Имеет функционал Tier II ERP, CRM, SCM, POS, Promotion, Campaign management и, в принципе, много чего ещё.

Важно понимать, это не просто бизнес-приложение - это Java платформа/конструктор для low-code разработки разных, ориентированных на работу с базой данных, бизнес-приложений c web интерфейсом. Во времена, когда многие пытаются построить бизнес-приложение с нуля, хорошо помнить о том, что существуют подобные фреймворки, основанные на принципах ООП, с миллионами строк проверенного кода, "активным словарём данных", который позволяет управлять сущностями, правилами проверки, окнами, таблицами, форматами и другими настройками приложения, не прибегая к кодированию вообще или же применяя небольшие, в несколько строк, инъекции кода.

Входит в широко известное за рубежом семейство "...piere" - Compiere, Adempiere, Open Bravo, Metafresh. Отличается от одних из них полным отсутствием pay wall, от других - модульной (плагинной) архитектурой (менять функциональность системы можно на лету, обновляя тот или иной плагин OSGi).

Каждый год на Хэллоуин сообщество проекта выпускает обновлённую версию. Осенью 2020 года вышла версия 8.2.

"Кривая обучения команды по iDempiere ERP/CRM была пройдена ранее, на предыдущих проектах. За нашими плечами есть проект на промышленном предприятии: 500 активных пользователей в день, база около 500 Гб, 100-400 млн. запросов к базе в сутки."

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

iDempiere работает с PostgresSQL >=9.6 или Oracle 11G/12C. Даёт кластеризацию серверов приложений и балансировку нагрузки с помощью HAProxy и Hazelcast. Имеет write to Master & report from hot replicas, два движка автоматизации бизнес-процессов ("строгий" бизнес-процесс и бизнес-процесс для кейс-менеджмента) и мн. др. фичи, делающие её вполне пригодной для большой индустрии.

Данный "панегирик" не что иное, как благодарность данной системе в режиме word of mouth за её возможности, которыми уже не раз приходилось пользоваться, в полном соответствии с философией open source и sharing.

"300 магазинов разбросаны на площади 450 тысяч км. кв., что примерно равно площади Испании. Объезжать их все, даже на моноколесе, - дороговато."

В чем состояла задача в данном проекте?

В 300 магазинах, которые работают по франшизе бренда и в которых сложился разношёрстный ИТ-ландшафт различных POS-систем и зачастую нет постоянного айтишника, развернуть программу лояльности, которая максимально соответствует пользовательской истории Заказчика (бренда), работает мгновенно и готова к omnichannel. Часть этой пользовательской истории мы написали и переписали вместе с Заказчиком.

Вот чем в процессе этой дискуссии мы озаботились.

Почему программы лояльности вызывают скепсис у покупателя?

Еcли верить большим дядям типа Forrester, этот скепсис есть во всем развитом мире, а не только у нас. 60-70% всех покупателей являются членами хотя бы одной программы лояльности. Но быть членом это одно, а реально пользоваться - это другое. Как минимум 50% "участников" среднестатистической программы лояльности ею не пользуются. Если коротко и только о главном, то вот почему:

• Проблемы бренда:

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

  • Если customer experience в физическом магазине бренда сильно хромает: нужного товара нет, продавец о товаре ничего рассказать не может, в магазине плохо пахнет, за разменом посылают в соседнюю лавку и т.д. Другими словами, если базовые запросы покупателя при общении с брендом не удовлетворены, то программа лояльности будет уместна, как на корове седло. Лучше уж сфокусироваться на улучшениях в торговой точке.

• Проблемы самой программы лояльности:

  • Правила участия и получения бенефитов замороченные

  • А награда находит покупателя не сразу, а только потом - отсутствует instant gratification.

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

"Тут и объяснять ничего не надо - каждой программе лояльности нужен BI и всё тут. Для нашего проекта мы опять решили использовать open source - Metabase. Заказчику понравилось"

Какие принципы программы лояльности мы с заказчиком в итоге сформулировали?

Возможно, вам это всё покажется прописными истинами, но всё же.

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

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

В центре программы лояльности - покупатель

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

Вознаграждение покупателя должно быть практически мгновенным

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

Регистрация в программе лояльности за секунды. И никаких ФИО, пожалуйста!

Понятно, что бумажные анкеты, которые "завтра обработают в офисе" это безнадёжный олдскул. Зарегистрироваться твоему покупателю в твоей программе лояльности должно быть не сложнее, чем послать 1 СМС. Ещё лучше, если это в два клика сделает продавец прямо в магазине. И, боже мой, конечно, не надо спрашивать Имя-Фамилию-Отчество! Спроси "Как к Вам можно обращаться?". Если хочет покупатель быть Василисой Прекрасной, Darth Vader или Zaya, пусть будет, мы не на пограничном контроле. Твоя задача - максимально снизить боль покупателя при регистрации, и дать возможность покупателю быть тем, кем он хочет, это лояльно по отношению к нему. Удивительно, но сколько же людей из сферы маркетинга порываются мыслить терминами "ФИО"!

Максимальная прозрачность для покупателя условий программы лояльности и его статуса в ней

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

Заранее планируй multichannel и работу множества разных акций одновременно

Даже если онлайн-магазина у тебя ещё нет, всё равно архитектуру и логику своего offer engine закладывай под

• многоканальность (физический магазин, онлайн-магазин, приложение, бот в Телеграме и т.д.)

• каждая торговая точка - потенциально отдельный канал (позитивно аукнется, например, при открытиях новых магазинов или при региональных промо)

• сосуществование множества акций одновременно (в т.ч. "противоречащих" друг другу)

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

Скорость и надёжность, само собой

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

Подарочные карты

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

FIFO для баллов программы лояльности

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

Анализируй это!

Тут и объяснять ничего не надо - каждой программе лояльности нужен BI и всё тут. Для нашего проекта мы опять решили использовать open source - Metabase. Заказчик остался доволен.

Итак, проблемы проекта

1. 300 магазинов разбросаны на площади 450 тысяч км. кв., что примерно равно площади Испании. Объезжать их все, даже на моноколесе, - дороговато.

2. Да, магазины работают по франшизе, но исторически сложилось, что каждый предприниматель использует POS систему, выбранную по своему усмотрению (уже была; брат/сват уже использует и хвалит и т.д.) 99.9% всех рассматриваемых предпринимателей используют 1С разных версий и конфигураций. Затевать проект по переводу всех на один единственно правильный вариант POS, перестройке работы и переобучению всех сотрудников этой многоликой Испании, да еще в условиях пандемии, заказчик посчитал слишком дорогим по времени, а значит, по деньгам.

3. ИТ-экспертиза в этих магазинах имеет преходящий характер. Или приходящий.

4. НСИ только частично синхронизирована.

5. Период полного развёртывания программы лояльности во всех магазинах был определён как 6-9 месяцев от начала до конца.

"Штатные возможности iDempiere ERP/CRM для предметной области retail & promotion были полностью в нашем распоряжении..."

Сильные стороны, или почему всё получилось

1. Практически все магазины имели на начало проекта стабильный интернет, достаточный для работы веб-сервисов. А те, что не имели, могли легко и дёшево его получить.

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

3. Кривая обучения команды по iDempiere ERP/CRM была пройдена ранее, на предыдущих проектах. За нашими плечами есть проект на промышленном предприятии: 500 активных пользователей в день, база около 500 Гб, 100-400 млн. запросов к базе в сутки.

4. Штатные возможности iDempiere ERP/CRM для предметной области retail & promotion были полностью в нашем распоряжении:

   1. Вкладка Контрагент и её разные подчиненные вкладки (Контакты, Адреса, Сферы интересов, и ещё пара десятков других) и их готовая логика;

   2. Вкладка Промоакция и её подчиненные вкладки (Условия срабатывания, Распределение количества, Вознаграждение для покупателя, Строка промоакции и др.) и их готовая логика;

   3. Вкладка Группы Промоакций;

   4. Вкладка Рекламные кампании;

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

   1. Сильный буржуйско-бухгалтерский функционал по GL (General ledger - Главная книга) и учёту дебиторки/кредиторки;

   2. Работа со множеством валют в учёте (баллы - это просто ещё одна валюта, пока что с курсом 1:1 к рублю);

   3. Встроенный Report Cubeи таблица Fact_Acct_Summary, хранящая балансы финансовых транзакций (отличная от таблиц, содержащих движения);

   4. Кластеризация серверов приложений и балансировка нагрузки с помощью HAProxy;

   5. Поддержка REST web servicesдля обмена через JSON формат;

   6. Schedulers - Планировщики. Штатный функционал iDempiere, RPA процессы, которые запускаются по расписанию или, с небольшой модификацией, по событию, на отдельном служебном сервере приложений и делают своё дело. У вас могут быть сотни планировщиков, если это надо. В нашем случае планировщики проводят начисления бонусов по всем необходимым таблицам движения, еженощно сжигают устаревшие бонусы по методу FIFO, отслеживают и исправляют экзотические, проблемные транзакции (возврат приходит раньше продажи, например, из-за того, что моргнул интернет в магазине).

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

   8. Write to master database, report from hot replicasстандартная настройка, позволяющая отправлять все отчёты, включая автоматические, на одну или множество горячих реплик вашей базы данных;

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

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

Как в итоге всё работает?

1. В программе лояльности активировано уже 800'000 покупателей.

2. 99.9% из 300 магазинов имеют ту POS, которую имели до проекта.

3. Для магазинов был и написан, и описан минимально необходимый REST API, который и даёт почти мгновенную синхронизацию с централизованной программой лояльности.

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

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

6. В зависимости от сценария поведения покупателя (только начислять баллы или начислять-списывать) на одну продажу приходится до 3х транзакций обмена данными. Они занимают в среднем 50, 200 и 200 миллисекунд соответственно.

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

Я уже ранееписал о том, что придумал движок, который позволяет работать с не 1С SQL-базой из клиентов, которыми являются базовые конфигурации 1С:Деньги. Думаю, это классное решение для небольших частных или малотиражных конфигураций! Я назвал его Базовый Учет или Базуха (Базовый Учет Хозяйства).

Решение дешево. 1С:Деньги на каждое рабочее место обойдется в 300 рублей. Сравните с лицензией на 1С, которая стоит 13.000 рублей + 5.000 рублей за каждое дополнительное место.

Так, например, лицензия на 10 пользователей для Базухи обойдется в 3.000 рублей, а для 1С в 28.000 рублей, т.е. по 2.800 рублей на каждого пользователя! Экономия в 10 раз!

Решениелучше чем 1С по производительности в эконом-сегменте. В дешевых 1С используется файловая база, которая работает медленно, т.к. нет посредника в виде SQL-сервера, который обеспечивает быстрое извлечение данных.

Чтобы получить сервер SQL, нужно заплатить достаточно большую сумму. Сервер 1С на 5 подключений стоит 14.000, а на большее количество подключений 86.400 (32-разрядный сервер за 50.400 не рассматриваем, его покупка не имеет смысла). Поэтому в нашем примере на 10 пользователей для нормальной производительности стоимость одного рабочего места уже получается 11.440 (учтена стоимость лицензии на сервер 1С).

Почему-то 1С не предлагает решения, где не используется сервер 1С, а используется только SQL-сервер. Базуха как раз использует такой подход. Он медленнее, чем трехзвенка с сервером 1С (потому что нельзя исполнять код на сервере), но быстрее, чем файловая база 1С (потому что можно исполнять SQL-запросы).

Однако,справедливости ради, следует сказать, что если многопользовательский доступ к файловой базе будет реализован через веб-сервер, то производительность будет сопоставима с Базухой. Веб-сервер является как бы сервером приложений, но у Базухи есть SQL-сервер. Так что сопоставимо. Причем Базуха лучше масштабируется на количество пользователей больше 10, а файловая даже через веб-сервер начинает на таких масштабах задыхаться, т.к. у нее нет SQL-сервера.

Решениеиспользует код и архитектуру 1С. Это важно, потому что поддерживать его может любой программист 1С, потратив буквально пару часов на освоение документации по платформе Базухи. Кроме того, можно использовать все выразительные средства 1С в разработке таблицы значений, МХЛ-файлы, богатые средства 1С для интеграции. Да и пользователю привычен знакомый интерфейс 1с.

Решениеболее свободно чем 1С. Для разработки можно использовать любые модели данных, а не только придуманные 1С прикладные объекты (регистры, планы счетов, планы обмена и т.п.). Можно использовать свои инструменты для разработки, можно делать абстракции кода, выполняя не код, а схемы кода, собственные иерархии данных.

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

Для кого предназначена Базуха?

Понятно, что конфигурация только начинается, поэтому не может конкурировать с такими монстрами, как УТ, БП, ERP, в которых вложено много труда и ресурсов. Но она и не предназначена для этого. Известно, что 1С предлагает максимально быстрый и удобный инструмент для разработки приложений баз данных. Но, к сожалению, лицензионная политика не позволяет его использовать для мелких, небольших решений.

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

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

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

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

Лицензионная чистота

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

Но на всякий случай я обратился и в 1С (lic@1c.ru). Там тоже не нашли возражений против моей схемы, после долгих и муторных споров со стороны 1С было вынесено решение:

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

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

Вот текст лицензии на базовые версии 1С:

Как устроена Базуха?

Каждому пользователю устанавливается базовая программа 1С:Деньги.

В базе пользователя администратором запускается обработка, которая подготавливает базу к начальному запуску:

1. Создает два пользователя admin (с паролем) и user (без пароля). admin имеет административные права, user полные.

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

3. Добавляет основную обработку по работе с SQL базой данных.

4. Выполняет первоначальную синхронизацию с SQL базой данных.

5. Прописывает на рабочий стол ярлык для запуска 1С:Деньги под пользователем user с открытием списка дополнительных внешних обработок.

Окно запуска 1С:Базухи для пользователя выглядит так:

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

При запуске обработки Рабочий стол пользователь вводит логин и пароль для доступа к SQL-базе. И начинает работу в этой базе добавляет/изменяет/просматривает данные и отчеты.

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

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

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

Формы списка не поддерживают динамическое считывание данных, считывают данные порциями, постранично.

Отчеты выглядят как типовые 1С-отчеты, можно использовать даже систему компоновки данных (СКД).

Печатные формы документов программируются также на 1С и выводятся в табличные документы MXL.

Модули объектов (справочников и документов) хранятся в дополнительных обработках.

Особенности реализации Базухи

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

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

В качествесерверапланируется использовать любой SQL-сервер, желательно бесплатный. В начале My-SQL, потому что его проще приобрести пользователю (обычно предоставляются при покупке хостинга). И администрировать его практически не нужно. Далее, можно посмотреть в сторону Postgree.

Ранее делился тем, как мы решаем проблему отсутствия UI\UX дизайна в 1С с помощью Java Script и React.js. Сегодня обсудим роль и влияние дизайна на скорость разработки и внедрений мобильных приложений на 1С.

Для чего вообще заниматься дизайном, если и так все хорошо на рынке ИТ, спрос велик, работы валом и т.д.?

Три ключевые причины:

1. Снизить себестоимость, за счет многократных доработок\переделок, когда Заказчик (внутренний\внешний) видит продукт, только после разработки, а не ДО разработки, когда может хоть как-то повлиять.

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

3. Ускорить внедрение разработанного ПО и снизить нагрузку на техническую поддержку, как свою, так и Заказчика.

Технология разработки, когда до начала программирования, быстро, просто и дешево дизайнишь прототип (MVP), в online обсуждаешь, согласовываешь и сдаешь заказчику, после чего начинаешь кодить зарекомендовала себя на все 100%.

Более того, был опыт, когда задизайнили идею надстройки\расширения к типовой конфигурации, запустили рассылку по внутренней базе и получили тут-же лиды = $!

Как тебе такое Илон Маск? Зерокодинг воплати!

В мобилке тема UI и UX дизайна, прототипирования, MVP стоит ещё острее чем в десктопе. Так, года два назад, обратился в ряд компаний с ТЗ на мобильное приложение и все мне предложили примерно следующий порядок реализации проекта:

Этап 1. Исследование и составление ТЗ

Сбор и формализация требований;

Разработка и проектирование прототипа приложения;

Разработка и проектирование UX/UI интерфейсов ключевых экранов приложения;

Подготовка ТЗ с описанием принципа работы функционала.

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

2.1. Разработка серверной части:

2.2. Разработка клиентской части:

.

2.3. Тестирование и отладка:

..

2.4. Публикация мобильного приложения в Store:

.

Этап 3. Передача исходных материалов проекта.

Попробовал, и понял на сколько круто, быстро, удобно! Во-первых, был впечатлен конкретным дизайнером в конкретной компании, звали Олеся. Понимала мои запросы с полуслова, сама предлагала кучу классных дизайн-решений, у меня слюнки текли и хотелось уже быстрее дождаться разработки и получить долгожданный прототип. Во-вторых, я участвовал сам в создании своего детища, сам решал, как будут называться кнопки, что будет в результате их нажатия и т.д., конечно 80-90% решений было за Олесей, но те 10% влияния, что я оказывал были ценны для меня. В-третьих, мы были на одной волне с разработчиками, ведь уже не только куча текста было написано, но и был кликабельный прототип, ожидание и реальность сошлись на много быстрее и четче!

Создавая мобильные приложения на платформе 1С, приходится сразу кодить\конфигурировать. Продвинутые компании юзают не привычный 1С-му глазу Axure или Figma, долго настраивают, готовят UI Kitы и только после этого дизайнят интерфейс 1С, как из конфигуратора. Все это долго.. нудно и посильно не всем с коробки, короче "Такси - сел и поехал" не получается ;-)

В итоге, имея положительный опыт и наработки по десктопным форма, начали делать мобильные формы.

Технологии и архитектура уже известные:

Frontend

В основе лежит Single Page Application подход и фреймворк React.

ru.reactjs.org

Для реализации UI конструктора форм возьмем Material UI.

material-ui.com/ru

Сетка для проектирования форм и реализации колонок будет взята тоже из Material, но потребует настройки.

material-ui.com/ru/components/grid

Примеры реализации аналогичной идеи Drag&Drop создания макета из элементов:

github.com/chriskitson/react-drag-drop-layout-builder
github.com/kiho/react-form-builder
github.com/saravananangu/react-drag-drop-form-builde

Backend
На первом этапе достаточно использовать serverless подход и взять Google Firebase за основу.

В дальнейшем начнем разработку собственного backend-приложения на Node.js.

Архитектура:

Что пока получается:

На этот прототип понадобилось 10 минут:

Оказалось, что реализовывать инструмент прототипирования мобильной платформы 1С в разы сложнее десктопа, ведь логика элементов мобильных форм 1С платформы куда сложнее чем десктоп, так же есть особенности растягивания элементов по размеру экрана и т.д. и т.п. Пока тестируем на внутренних проектах и на ряде клиентов, но в целом, технология так же себя оправдывает: разработка и сдача работ заказчику увеличивается минимум на 25-30%, но есть одно НО: нужно выращивать компетенции дизайнера внутри, привлекать консультантов внешних, из мира web и мобильной разработки, в итоге появляются внутренние 1С:Дизайнеры ;-)

Всем успешных проектов, мира и добра!

Я верю: придёт великий день, и какой-нибудь могучий законодатель обяжет программистов 1С указывать на этикетке состав оказываемой услуги. С продуктами питания вроде получилось не всё гладко, конечно, но отличить колбасу точно не из мяса от возможно, из мяса уже получается.

Пока же у услуги доработка 1С под требования заказчика весьма и весьма мутный состав. Давайте возьмём лупу и прочитаем то, что написано мелким шрифтом.

Обучение стажёров

Ну, это прям на поверхности лежит и известно всем. Однако, упомяну.

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

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

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

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

Самая дурацкая затея покупать работу такого стажёра без предварительной оценки (сколько получится, столько получится). Получится много, при негарантированном результате. Обычно такой способ оценки работ используется, если надо разобраться, проанализировать или проверить, есть ли ошибки - в общем там, где от забора до обеда.

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

Комфорт Марины

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

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

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

Любой человек, когда его посылают, испытывает дискомфорт, и Марина не исключение. Поэтому она идёт к условному Никите, с которым танцевала на корпоративе и вместе ездит в маршрутке. Никита парень хороший, и специалист неплохой, но совсем в другой области. Например, по кассам, сканерам ШК, ЕГАИС и МДЛП. А Марина принесла задачу по планированию производства. Брать? Конечно. Не смотреть же в эти мокрые от слёз глаза. Да и учиться надо не век же ползать под столом у кассиров.

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

Если присмотреться к внутренней кухне франча, то подобных парочек, тройничков, foursome, а то и group *** обнаружится очень много. Всё бы ничего, но платит за эти оргии клиент. И неплохо бы этот ингредиент на упаковочке напечатать.

НДС

Это налог, только не на добавленную стоимость, а на дармоедов-специалистов. Одно из новшеств последних лет.

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

Программировать не умеет вообще. Ответить без подготовки на вопрос по программе (как это делает консультант) тоже не может. Умеет тыкаться в программе и, вроде как, писать ТЗ для программистов.

Собственно, этим дармоеды и живут. Клиенту нужно разобраться в странном поведении программы или доработать её дармоед тут как тут. Он проведёт анализ, соберёт требования, оформит результаты встречи, может анкету какую заполнит, потом напишет ТЗ и включит свои услуги в стоимость. Постарается, по возможности, выделить их отдельной строкой и попросит оплатить до исполнения работы программистом. Ну так, на всякий случай.

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

Так что, если вы, как клиент, общаетесь с кем-то, кроме менеджера и программиста, можно предположить, что вам накинули НДС. Процент там, увы, далеко не 20.

Вакуум

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

Когда вы заказываете любую услугу по доработке или обслуживанию ПО 1С, будьте уверены на 99% - кто-то такое уже делал, причём в том франче, в который вы обратились. Но купите вы реализацию с нуля. И не потому, что так решили хитрозадые программисты 1С. Просто они понятия не имеют, что делают соседи и смежники.

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

Так что, в состав ингредиентов можно смело вносить каждый раз как в первый раз.

Маринад

Задачи, которые решают программисты 1С, частенько маринуются. Это специализированный процесс, призванный несколько увеличить стоимость итогового решения.

Например, обратился клиент за час до окончания рабочего дня. Так получилось, что нашёлся специалист, и решил задачу минут за 55 минут. Звонить, сдавать? Нафига. Оставляем до утра. И не говорим клиенту.

Если сдать сразу, то большее, на что можно рассчитывать 1 закрытый час. Если подождать до утра, то маринованная задача будет стоить уже 2, а то и 4 часа вопрос лишь в правильной подаче.

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

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

Текучка и ротация

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

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

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

А клиент ведь что частенько заказывает: доработку доработки. Он может об этом даже не подозревать, ведь текучка не только во франче есть человек видит программу, и хочет её улучшить. А кто там эту формочку рисовал, 1С или Никита ему параллельно.

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

Колобок

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

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

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

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

До лисы докатится далеко не каждый колобок.

Отсутствие опыта к эксплуатации

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

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

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

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

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

Тут я короче не знаю

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

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

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

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

В эту яму скатываются и нормальные спецы какой смысл быть белой вороной, выставлять 15 минут за поиск информации, если можно продать 4 часа за анализ, моделирование и общение с разработчиками?

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

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

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

Лень клиента

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

И тут имеет значение целый ряд факторов.

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

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

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

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

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

Что там в-шестых, в-седьмых и в-остальных, думаю, сами допишете.

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

Чё думаете?

Я верю: придёт великий день, и какой-нибудь могучий законодатель обяжет программистов 1С указывать на этикетке состав оказываемой услуги. С продуктами питания вроде получилось не всё гладко, конечно, но отличить колбасу точно не из мяса от возможно, из мяса уже получается.

Пока же у услуги доработка 1С под требования заказчика весьма и весьма мутный состав. Давайте возьмём лупу и прочитаем то, что написано мелким шрифтом.

Обучение стажёров

Ну, это прям на поверхности лежит и известно всем. Однако, упомяну.

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

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

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

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

Самая дурацкая затея покупать работу такого стажёра без предварительной оценки (сколько получится, столько получится). Получится много, при негарантированном результате. Обычно такой способ оценки работ используется, если надо разобраться, проанализировать или проверить, есть ли ошибки - в общем там, где от забора до обеда.

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

Комфорт Марины

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

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

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

Любой человек, когда его посылают, испытывает дискомфорт, и Марина не исключение. Поэтому она идёт к условному Никите, с которым танцевала на корпоративе и вместе ездит в маршрутке. Никита парень хороший, и специалист неплохой, но совсем в другой области. Например, по кассам, сканерам ШК, ЕГАИС и МДЛП. А Марина принесла задачу по планированию производства. Брать? Конечно. Не смотреть же в эти мокрые от слёз глаза. Да и учиться надо не век же ползать под столом у кассиров.

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

Если присмотреться к внутренней кухне франча, то подобных парочек, тройничков, foursome, а то и group *** обнаружится очень много. Всё бы ничего, но платит за эти оргии клиент. И неплохо бы этот ингредиент на упаковочке напечатать.

НДС

Это налог, только не на добавленную стоимость, а на дармоедов-специалистов. Одно из новшеств последних лет.

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

Программировать не умеет вообще. Ответить без подготовки на вопрос по программе (как это делает консультант) тоже не может. Умеет тыкаться в программе и, вроде как, писать ТЗ для программистов.

Собственно, этим дармоеды и живут. Клиенту нужно разобраться в странном поведении программы или доработать её дармоед тут как тут. Он проведёт анализ, соберёт требования, оформит результаты встречи, может анкету какую заполнит, потом напишет ТЗ и включит свои услуги в стоимость. Постарается, по возможности, выделить их отдельной строкой и попросит оплатить до исполнения работы программистом. Ну так, на всякий случай.

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

Так что, если вы, как клиент, общаетесь с кем-то, кроме менеджера и программиста, можно предположить, что вам накинули НДС. Процент там, увы, далеко не 20.

Вакуум

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

Когда вы заказываете любую услугу по доработке или обслуживанию ПО 1С, будьте уверены на 99% - кто-то такое уже делал, причём в том франче, в который вы обратились. Но купите вы реализацию с нуля. И не потому, что так решили хитрозадые программисты 1С. Просто они понятия не имеют, что делают соседи и смежники.

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

Так что, в состав ингредиентов можно смело вносить каждый раз как в первый раз.

Маринад

Задачи, которые решают программисты 1С, частенько маринуются. Это специализированный процесс, призванный несколько увеличить стоимость итогового решения.

Например, обратился клиент за час до окончания рабочего дня. Так получилось, что нашёлся специалист, и решил задачу минут за 55 минут. Звонить, сдавать? Нафига. Оставляем до утра. И не говорим клиенту.

Если сдать сразу, то большее, на что можно рассчитывать 1 закрытый час. Если подождать до утра, то маринованная задача будет стоить уже 2, а то и 4 часа вопрос лишь в правильной подаче.

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

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

Текучка и ротация

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

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

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

А клиент ведь что частенько заказывает: доработку доработки. Он может об этом даже не подозревать, ведь текучка не только во франче есть человек видит программу, и хочет её улучшить. А кто там эту формочку рисовал, 1С или Никита ему параллельно.

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

Колобок

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

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

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

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

До лисы докатится далеко не каждый колобок.

Отсутствие опыта к эксплуатации

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

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

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

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

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

Тут я короче не знаю

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

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

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

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

В эту яму скатываются и нормальные спецы какой смысл быть белой вороной, выставлять 15 минут за поиск информации, если можно продать 4 часа за анализ, моделирование и общение с разработчиками?

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

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

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

Лень клиента

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

И тут имеет значение целый ряд факторов.

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

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

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

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

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

Что там в-шестых, в-седьмых и в-остальных, думаю, сами допишете.

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

Чё думаете?

Предисловие

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

Очищаем рабочий стол от лишних ярлыков

Создадим Групповую политику с названием "Очистить рабочий стол" и свяжем ее с подразделением в котором расположены пользователи нашего сервера

Зададим параметры политики > Конфигурация пользователя > политики > административные шаблоны > Меню Пуск и панель задач там находим Скрыть общие группы программ в меню "Пуск"

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

Размещаем на рабочем столе пользователя необходимые ярлыки приложений

Создадим Групповую политику с названием "Публикация ярлыков" и свяжем ее с подразделением в котором расположены пользователи нашего сервера

Зададим параметры политики > Конфигурация пользователя > политики > Настройка > Конфигурация Windows > Ярлыки > ПКМ создать > ярлык

Заполняем открывшуюся форму, Данные можно скопировать с существующего ярлыка, нажав по нему ПКМ и выбрав свойства, в поле "Размещение" выбираем Рабочий стол

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

Очищаем содержимое Меню ПУСК и задаем начальный макет

Создадим Групповую политику с названием "Настройка Меню Пуск" и свяжем ее с подразделением в котором расположены пользователи нашего сервера

Зададим параметры политики > Конфигурация пользователя > политики > административные шаблоны > Меню Пуск и панель задач > выбираем "Очистка списка недавно использовавшихся программ для новых пользователей" и переводим параметр в состояние Включена

Там же находим политику макет начального экрана, так же ее включим и укажем путь где мы в дальнейшем разместим файл макета

Создадим макет

Заходим на наш сервер под локальным администратором и настройте вручную нужный вид макета начального экрана, после чего запускаем PowerShell под правами администратора и выполняем команду Export-StartLayout -Path d:\123.xml где в параметре path указываем путь который мы задали ранее в политике

В результате мы имеем полностью готовые к работе рабочие места для сотрудников компании

Оптимизация 1С

Включаем высокую производительность

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

идем Пуск > панель управления > оборудование > электропитание > выбираем высокая производительность

Отключаем DFSS для нормальной работы 1С

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями) чтобы повысить производительность 1С:Преприятие 8 в ряде случаев. На момент написания заметки платформа может неудачно взаимодействовать с Dynamic Fair Share Scheduling. Одним из таких признаков может быть долгое открытие конфигуратора в терминальном сервере. Предположительно эта служба Dynamic Fair Share Scheduling думает что 1С:Предприятие потенциально окажет негативное влияния сессией текущего пользователя, захватившего большое количество вычислительных ресурсов, на сессии других пользователей. Служба старается предотвратить чрезмерное использования например дисков одним пользователем, пытаясь организовать равномерное распределение дисковых операций I/O между сессиями.

Чтобы выключить балансировку ресурсов надо выполнить следующие шаги:

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

(gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices").enabledfss

1 включено, 0 выключено.

Если получаем 0, то дополнительно действий не требуется.

Шаг второй. Если предыдущий шаг вернул 1, то продолжаем. После чего открываем реестр windows (regedit) и меняем в следующих ветках некоторые значения:*1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System параметр EnableCpuQuota на 0.

2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk параметр EnableFairShare на 0. Этот параметр особенно сильно влияет.

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

Для этого выполним команды

Set-Itemproperty -Path Registry::"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System\" -name EnableCpuQuota -Value 0  

Set-Itemproperty -Path Registry::"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk\" -name EnableFairShare -Value 0

после чего проверим

Get-Itemproperty -Path Registry::"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System\" -name EnableCpuQuota

Get-Itemproperty -Path Registry::"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk\" -name EnableFairShare 

Результатом должен вернуться 0

Это 2 основных пункта которые влияют на производительность 1с, осталось нам научиться понимать где узкое горлышко производительности

Мониторинг Загрузки сервера

в работе сервера с 1с как показала практика основным показателем является средняя длина очереди диска и загрузка ЦП

Смотрим очередь диска

Заходим Управление компьютером > Производительность > Средства наблюдения > Системный монитор > Добавить > выбираем "Физический диск" > средняя длина очереди диска > выбираем диск на котором лежат базы
Нормальным режимом работы является очередь не превышающая значения 1, все что выше уже будут заметны подтормаживания, при значениях выше 2.5 работа в 1 с становится не комфортной.

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

Формирование списка баз 1С, для пользователей

Будем использовать уже заезженный метод формирования списка на основе NTFS прав, но внедрим немного своего

первым делом определимся с местом где будут лежать файлы запуска БД 1С и укажем путь до этого места, пусть это будет d:\access\1cestart.cfg

Откроем файл C:\ProgramData\1C\1CEStart\1cestart.cfg

и добавим в конец файла строку "CommonCfgLocation=d:\access\1cestart.cfg" после чего сохраним

Далее нам необходимо скачать powershell script отсюда

на 160 строке указываем путь до расположения файловых баз 1с

на 163 задаем путь до подразделения домена в котором будут лежать у вас группы безопасности доступа к БД

после чего можем запустить скрипт и создать каталог для нашей базы 1С, После чего останется только положить БД в данный каталог и добавить пользователей в группу доступа 1с

На этом настройку терминального сервера 1с, можно считать законченно, как итог мы имеем сервер готовый к приему клиентов

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

Дебиторская задолженность (далее встатье ДЗ) это долги юрлиц ифизлиц предприятию. Чем быстрее можно добиться ихпогашения, тем она более ликвидна.

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

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

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

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

Как образуется задолженность

Вариантов возникновения много, приводим самые распространенные.

Состороны контрагентов:

• когда компания платит аванс поставщику или подрядчику;

• когда покупатель (вего роли может выступать филиал или дочерняя организация) сначала получает товар или услугу, аплатит потом;

• когда контрагент наносит ущерб компании икомпенсирует его несразу (например, если логистическая компания повреждает товары при транспортировке).

Состороны госструктур:

• при переплате налога;

• при вычете входного НДС (приобретая товары вцелях осуществления операций, облагаемых НДС, налогоплательщик имеет право навычет (ст.171 и172НК РФ));

• при социальных выплатах, которые возмещает ФСС (например, когда сумма выплаченных сотруднику пособий превысила страховые взносы или когда покрываются расходы напредупредительные меры (до20% сумм взносов запредыдущий год можно потратить наних)).

Состороны сотрудников иучастников предприятия:

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

• когда работодатель выдает сотруднику заем;

• когда участник общества задерживает платеж вуставный капитал.

Как посчитать ликвидность

Ликвидность ДЗможно оценить спомощью коэффициента ееоборачиваемости или спомощью периода ееоборота.

1. Коэффициент считают как отношение выручки кдебиторке запериод времени:

Коб.дз = ДР/ ДЗср,

где:

• Коб.дз коэффициент оборачиваемости Д;

• ДР доход компании отреализации продуктов или услуг запериод времени (обычно загод, квартал или месяц);

• ДЗср средняя дебиторская задолженность заэтотже период, т.е. суммаДЗ наначало иконец периода/2.

Тоесть расчет побалансу будет выглядеть так:

Коб.дз = 2110/ (1230на начало периода 1230на конец периода) х0,5

2. Период оборота равенДЗ наконец периода, умноженной наколичество дней расчетного периода иделенной надоход:

Поб.дз = ДЗкп хП/ ДР,

где:

• ДЗкп задолженность наконец периода;

• П период, выраженный вколичестве дней;

• ДР доход компании отреализации продуктов или услуг заэтоже период.

Тоесть расчет побалансу будет выглядеть так:

Поб.дз = 1230на конец периода хП/ 2110

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

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

Оценка качества задолженности

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

Поотношению ксроку погашения:

• Срочная или нормальная (срок погашения еще ненаступил).

• Просроченная, может также подразделяться накатегории подлительности просрочки вднях. Например: до30, от31до60, от61до90, более 90.

Более мелкое деление помогает оценить риски невозврата: чем дольше дебитор задерживает оплату, тем меньше шансов, что онпогасит долг. Срок исковой давности повзысканию просроченной задолженности ограничен, составляет три года (ст. 196ГК РФ). Отсчет начинается сдаты, когда организация узнала онеуплате (например, день, следующий заднем платежа подоговору.

Если задолженность регулируется договором, вкотором неуказан срок возврата, тосрок давности надо начинать отсчитывать через 30дней после предъявления требования вернуть долг, ипри этом оннедолжен быть больше 10лет смомента возникновения долга (п. 2ст. 200ГК РФ).

Повероятности возврата:

• Надежная: непросроченная либо подтвержденная надежным контрагентом или обеспеченная гарантией.

• Сомнительная: та, которую могут непогасить вообще или вполном размере. Обычно это просроченная инеобеспеченная залогом, поручительством или банковской гарантией (п. 1ст. 266НК РФ), нодаже если компания изкаких-либо источников узнает офинансовых трудностях контрагента, его долг тоже стоит считать сомнительным. Поистечении срока взыскания становится безнадежной.

• Безнадежная: та, которую нельзя взыскать. Может быть просроченной систекшим сроком исковой давности, или признанной таковой порешению суда (например, при банкротстве дебитора, когда оставшиеся средства достались кредиторам предыдущей очереди), или относиться корганизации, которая уже ликвидирована (п. 2ст. 266НК РФ). Исключение для третьего случая долгИП: ондаже после исключения изреестра отвечает пообязательствам своим имуществом (ст. 24ГК РФ), если суд непризнал его банкротом.

Повеличине срока погашения:

• Краткосрочная или текущая (вбалансе относится кбыстро реализуемым активам, группаА2): погашение планируется втечение года (можно также отдельно выделить долги, которые будут оплачены втечение квартала имесяца).

• Долгосрочная (вбалансе относится кмедленно реализуемым активам, группаА3): погашение ожидается более чем через 12месяцев. Когда срок возврата долгосрочного долга становится меньше, чем 1год, онпереходит вкатегорию краткосрочных.

Степень ликвидности также можно оценить нетолько поформуле, ноиспомощью ручной группировки:

• ДЗсосроком погашения до30дней высоколиквидная.

• Безнадежная неликвидная.

• Остальная среднеликвидная.

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

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

Как анализировать

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

Например, сравнивать:

• размерДЗ собщим объемом текущих активов;

• темпы ростаДЗ стемпами роста дохода;

• размер исрок оборачиваемостиДЗ саналогичными параметрами кредиторской задолженности;

• фактическую оборачиваемостьДЗ сожидаемой (согласно договорам).

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

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

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

Как повысить качество иликвидность

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

Действовать можно понескольким фронтам:

• Предупреждать риски (детальная проработка договоров, условий сотрудничества).

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

• Анализировать результаты.

• Корректировать кредитную политику.

Как можно работать срисками

1.Прописать вдоговоре

• неустойки (штрафы, пени), возможность удержания имущества должника идругие карательные меры вслучае неуплаты;

• особые условия перехода права собственности напродукт: переход только вмомент оплаты (чтобы при банкротстве контрагента можно было вернуть неоплаченное имсвое имущество);

• правила корректировки условий сотрудничества (цен/ гарантийных сроков/ сроков отсрочки платежей ит.п.) вслучае изменения условий рынка;

• возможность расторжения договора водностороннем порядке вслучае неисполнения второй стороной условий этого договора;

2. Создать резервный фонд насумму сомнительных долгов;

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

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

Как получать платежи всрок ивозвращать сомнительные долги

• Назначать ответственных засоблюдение контрагентами сроков оплаты.

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

• Ежемесячно сверять взаиморасчеты.

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

• Регулярно требовать провести просроченные платежи.

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

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

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

1. Регулярно анализируйте иранжируйте дебиторов (можно методом ABC-анализа), работайте сдолговыми реестрами, ищите причины появления просрочек, признаки добросовестных инедобросовестных контрагентов.

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

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

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

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

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

В прошлом я и сам работал с программными продуктами 1С, и меня, как и многих пользователей и разработчиков, мучили вопросы:

1. Почему программные решения всегда такие недоработанные?

2. Почему любое программное решение от 1С необходимо регулярно обновлять?

3. Почему 1С не предлагает программные продукты, которые бы закрывали определенную нишу?

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

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

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

Ситуация на рынке CRM-систем в России

Лично для себя я нашел ответы на описанные выше вопросы только тогда, когда начал работать с различными CRM-системами. Ко мне нередко обращаются люди с вопросом Какую CRM вы посоветуете. Обычно я задаю им встречный вопрос А чем вы сейчас пользуетесь? И очень часто слышу, что текущая CRM это АМО, Битрикс, а на будущее они всерьез изучают 1С CRM. Впрочем, были и обратные ситуации, когда люди сейчас пользуются 1С CRM, а рассматривают возможность перехода на АМО или Мегаплан.

В итоге я выяснил, что в любом обсуждении внедрения CRM с нуля или выбора CRM на замену текущей фигурируют 5 самых популярных решений:

1. АМО CRM;

2. 1С CRM;

3. Битрикс CRM;

4. Мой склад (там также есть CRM-система);

5. Мегаплан.

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

Все эти программные решения принадлежат одной компании!

В результате возникает такая ситуация. Пользователь покупает лицензию, например, 1С CRM, какое-то время пользуется, но ему что-то не нравится. И он переходит на Битрикс. Также покупает лицензию, пользуется, через время также испытывает недовольство, и уходит на Мегаплан.

В этом процессе задействованы три стороны:

1. вендор, разработчики (1С),

2. консультанты и программисты, которые непосредственно внедряют систему,

3. пользователи.

Давайте разберемся, кто при этом оказывается в выигрыше?

На место кружков поставьте себе логотипы программных продуктов

Пользователи

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

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

Консультанты

Консультанты и программисты находятся в лучшем положении в сравнении с пользователем. Тем не менее, из личного опыта я знаю, что и здесь все не настолько хорошо, как могло бы показаться. Я работал с этими CRM-системами, и очень часто недостатки выявлялись уже на этапе внедрения. Соответственно, проект не мог быть завершен на 100%, и вознаграждение специалисты получали также не в полном объеме.

Вендор

А теперь изучим эту ситуацию с точки зрения вендора. В случае реальной конкуренции разработчики при смене пользователем CRM-системы теряют потенциальную прибыль, так как покупатель перестает оплачивать лицензии. Но если вспомнить, что все эти программные решения принадлежат одному владельцу, получается, что вендор ничего не теряет. А нередко при смене пользователем CRM-системы даже получает дополнительную прибыль.

Таким образом, единственная сторона, которая всегда в выигрыше в описанной выше ситуации 1С.

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

Причем тут линейка продуктов 1С?

Давайте рассмотрим типичную ситуацию в России и некоторых других постсоветских странах:

1. Компания покупает 1С Бухгалтерию, так как это решение самое популярное и привычное бухгалтерам.

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

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

4. Возможно, компания также внедряет собственное производство, и тогда они покупают 1С УНФ. В некоторых случаях УНФ оказывается недостаточно удобной. И тогда ее меняют на какие-то отраслевые решения или ЕРП.

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

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

Кому это выгодно?

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

Ситуация аналогична рассмотренному выше случаю со сменой CRM-систем.

Особенности работы компании 1С

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

• Во-первых, программный продукт много раз продают одному клиенту. Пока пользователь не попробует пользоваться, он не понимает, насколько выбранный продукт соответствует его потребностям. А если выбранное решение оказалось неудачным, он снова платит деньги компании 1С.

• Во-вторых, компания 1С не занимается методологической проработкой программных продуктов. Т.е. пользователю сложно понять, какой именно продукт будет соответствовать особенностям его деятельности. Самый яркий пример это УНФ (Управление нашей фирмой) или 1C Комплексное Управление. Эти две конфигурации во многом пересекаются по своему функционалу и возможностям. А ведь еще есть, например, 1С Управление торговлей. Бывает крайне сложно понять, какой из продуктов подойдет для конкретного случая.

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

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

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

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

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

Почему компания 1С не взлетает на новых рынках

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

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

Нельзя просто взять и интегрировать сайт с 1С. (с) Народное творчество.

Цель написания поста изложить всю информацию по теме человеческим языком.

Интеграция сайта на 1С-Битрикс: Управление сайтом и 1С неисчерпаемый источник вопросов и проблем. На сайте идей для Битрикс в соответствующем разделе 16 страниц, на форуме про это больше 23 000 сообщений. В форме обращения в техподдержку Битрикса есть даже отдельный тип заявки Обмен с 1С.

Считается, что интеграция 1С и сайта на Битриксе должна работать из коробки. Самые простые функции действительно можно запустить за час-два. А вот на доработку обмена можно потратить и 10, и 100 часов.

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

В данной статье будет рассмотрена общая теория обмена между двумя IT-системами и два стандартных обмена между 1С и сайтом на 1С-Битрикс: обмен товарами и обмен справочниками.

Немного теории

Интеграция обмен информацией между двумя IT-системами. Иногда называют просто обмен. Определяется форматом данных, протоколом (стандартом) передачи данных, алгоритмом работы

Формат = как выглядят данные (например, XML, YML, JSON, CSV).

Протокол = как данные оказываются в другом месте (например, HTTP, SIP, SMTP, FTP).

Алгоритм = что при этом происходит. Представляется блок-схемой или диаграммой UML Activity.

Примеры интеграций:

1. обмен товарами между самописной учетной системой и сайтом (протокол FTP, формат CSV);

2. парсинг курсов валюты с сайта ЦБ РФ (протокол HTTP, формат XML);

3. интеграция сайта с Яндекс.Маркет (протокол HTTP, формат YML).

Процедуру обмена можно разделить на 3 части:

1. Экспорт данных из системы А в требуемый формат

2. Передача данных

3. Импорт данных требуемого формата в систему Б.

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

И еще одно важное уточнение. 1С в зависимости от контекста, это может быть компания-легенда ООО 1С, их разработка 1С:Предприятие или конкретная конфигурация (например, 1С: Управление торговлей или 1С:ERP Управление предприятием) с установленным модулем обмена с сайтом . В мире веб-разработки имеется в виду как раз последнее определение. В статье будет действовать аналогичное соглашение. Так же и с сайтом на платформе 1С-Битрикс: Управление сайтом обычно это просто Битрикс.

Резюме

Интеграция обмен данными между двумя системами.

Формат как выглядят данные.

Протокол как передаются данные.

1С софт.

Битрикс сайт.

Краткость сестра.

Стандартные возможности обмена 1С и Битрикса

Из коробки (без доработок программиста) работают 4 типа обмена:

1. товары из 1С на сайт (тип catalog);

2. справочники из 1С на сайт (тип reference);

3. пользователей/контрагентов из 1С на сайт (тип sale);

4. заказы (тип sale):

   1. из 1С на сайт;

   2. из сайта в 1С.

Протокол

Все взаимодействия между 1С и Битриксом проводятся по HTTP, синхронно. Т.о. 1С подобна браузеру, она открывает специальную страницу, отправляет данные (методами POST и GET) и получает текстовый ответ. Есть даже способ имитировать выгрузку из 1С браузером (и мы часто используем этот трюк во время разработки и отладки). Подробнее про отладку мы рассказали в предыдущей статье Типовые ошибки интеграции между 1С и 1С-Битрикс.

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

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

Формат

Данные передаются в двух форматах.

Первый формат текстовый для ответов сайта на запросы из 1С. Сайт выводит в первой строке ответа success, если завершил некую процедуру, progress, если продолжает ее выполнять и error или failure, если была ошибка. В последующих строках могут быть дополнительные данные (зависит от каждого конкретного запроса).

Второй формат CommerceML 2 . Основан на XML, в этом формате передаются товары, предложения, цены, склады, заказы и контрагенты (пользователи+платежные профили).

Алгоритм

Подготовка к обмену

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

Авторизация

Любой обмен начинается с авторизации 1С на сайте методом Basic access. В случае успеха сайт выводит success, имя и значение Cookie (которую будет проверять во всех последующих запросах), id сессии и прочие параметры (зависят от type типа обмена).

Возможные ошибки

Запрос настроек сайта

На этом шаге 1С узнает важные для обмена настройки сайта. Управление этими параметрами на сайте происходит на странице Интеграция с 1С в панели управления сайтом.

Получив эти параметры, 1С начинает формирование данных для передачи на сайт. Если zip=yes, то все файлы будут переданы как zip-архив. Иначе каждый выгружается по отдельности. Желательно включать всегда.

Возможные ошибки

Обмен товарами (1С -> Битрикс)

Данный тип обмена (type=catalog) используется для создания и обновления на сайте следующих сущностей:

• инфоблок товаров;

• UF-поля разделов в этом инфоблоке;

• свойства элементов в этом инфоблоке;

• инфоблок SKU;

• типы цен;

• склады;

• разделы в инфоблоке товаров;

• элементы в инфоблоке товаров (товары);

• цены товаров;

• наличие товаров по складам.

При обмене товарами 1С формирует XML-файлы, передает их на сайт и контролирует их обработку сайтом. 1С может передать 4 вида файлов:

В файлах с префиксом import_ разделы каталога, товары, свойства товаров.

В файлах с префиксом offers_ SKU.

В файлах с префиксом prices_ цены товаров и предложений.

В файлах с префиксом rests_ остатки товаров и предложений по складам.

На шаге авторизации в случае успеха сервер вернет дополнительный параметр timestamp (текущее время). 1С сохранит timestamp и передаст на сайт на последнем шаге обмена товарами.

Шаг 1. Передача файла (повторяющийся)

Шаг может выполняется несколько раз. Каждый файл выгружается частями не более file_limit байт (см. предыдущий шаг) в бинарном виде через сырой POST-запрос. Сайт создает файл, если его нет. Имя файла берет из GET-параметра filename и дописывает в него переданный контент. Так продолжается до тех пор, пока 1С не передаст все части этого файла.

Возможные ошибки

Шаг 2. Основной

Этот шаг особенный. Файл уже целиком загружен на сайт и Битрикс готов его обработать. Его обработка может состоять из 11 более мелких операций, о которых 1С ничего не знает. Поэтому в параметре GET приходит mode=import (один и тот же запрос!), но сайт выполняет совершенно разные операции. Текущий прогресс Битрикс сохраняет в сессии в переменной $_SESSION[BX_CML2_IMPORT][NS]. Например, узел STEP в этом массиве отвечает как раз за номер внутренней операции импорта.

Шаг 2.1 Распаковка архива (повторяющийся, необязательный)

Шаг исполняется, только если 1С передала файл в формате ZIP. Распаковка происходит в той же директории, где лежат все файлы обмена товарами (по умолчанию /upload/1c_catalog/). Эта операция не нумеруется внутри Битрикса (значение STEP в сессии не изменяется).

Возможные ошибки

Шаг 2.2 Удаление временных таблиц

Работать напрямую с файлом XML (тем более, если он большой) неудобно и неэффективно. Поэтому все данные прочитываются во временную таблицу b_xml_tree. На этом подготовительном шаге таблица b_xml_tree, если она существует, удаляется.

Шаг 2.3 Создание временных таблиц

Таблица b_xml_tree создается. Если объявлена PHP константа BX_XML_CREATE_INDEXES_IMMEDIATELY, таблица сразу же индексируется. В конце этого шага Битрикс испускает событие OnBeforeCatalogImport1C .

Возможные ошибки

Шаг 2.4 Загрузка файла во временную таблицу (повторяющийся)

Битрикс шаг за шагом начинает читать переданный из 1С файл, добавляя записи в таблицу b_xml_tree. Чтобы избежать проблем с временем исполнения, процесс происходит пошагово. Управление продолжительностью шага происходит на странице Интеграция с 1С в панели управления сайтом.

Возможные ошибки

Шаг 2.5 Индексация временных таблиц

Для повышения скорости работы импорта таблица b_xml_tree индексируется после прочтения файла.

Возможные ошибки

Шаг 2.6 Импорт метаданных

На этом шаге создаются или обновляются следующие данные:

1. Инфоблоки товаров и SKU

2. Служебные свойства каталога (с префиксом CML2_: CML2_BAR_CODE, CML2_ARTICLE, CML2_ATTRIBUTES)

3. Торговый каталог

4. Свойства инфоблоков

5. UF-поля разделов инфоблоков

6. Типы цен

7. Склады

8. Единицы измерения

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

Возможные ошибки

Шаг 2.7 Импорт разделов каталога

На этом шаге в инфоблоке создаются и обновляются все разделы каталога, которые были в XML файле. Сопоставление разделов из XML-файла и в БД происходит по XML_ID.

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

Для экономии ресурсов сервера добавление разделов происходит без пересчета дерева (речь о полях LEFT_MARGIN и RIGHT_MARGIN).

Возможные ошибки

Так как импорт разделов не пошаговый, при обмене большом дереве разделов на сайте может возникать ошибка превышения времени исполнения. Решения три.

1. Увеличить время исполнения на странице Интеграция с 1С и в настройках сервера (nginx).

2. Доработать 1С, чтобы ошибки на этом этапе игнорировались пока не будет получен ответ progress.

3. Повторить всю выгрузку несколько раз.

Объясним, как поможет повтор шага или всей выгрузки. Допустим, в XML-файле и на сайте 20001 раздел. Пусть за один проход Битрикс успевает импортировать только 10000 разделов.

Битрикс каждый раз обрабатывает столько разделов, сколько успевает. При повторении выгрузки первые 10000 разделов он пропустит (обновит только TIMESTAMP_X) и обновит еще 10000 разделов, пока не наступил тайм-аут. И только на 3-ей выгрузке из 1С шаг будет завершен корректно.

Шаг 2.8 Пересчет дерева разделов

На этом шаге Битрикс выполняет две задачи:

1. Удаление/деактивация разделов (в старых версиях модуля обмена в 1С)

2. Перестройка дерева разделов

В старых версиях 1С отличить полную выгрузку от частичной просто: при частичной в узле Классификатор был атрибут СодержитТолькоИзменения="true", при полной его не было.

В 2019 году 1С всегда выгружает этот атрибут. Если этого атрибута нет, Битрикс мог (и до сих пор может, просто этот код не используется) удалить, деактивировать старые разделы (или пропустить их). На выбор влиял параметр на странице Интеграция с 1С. Сейчас эта настройка уже ни на что не влияет и ни деактивации, ни удаления не происходит.

Также на этом шаге пересчитываются служебные поля LEFT_MARGIN и RIGHT_MARGIN всех разделов.

Шаг 2.9 Импорт товаров (повторяющийся)

На этом шаге в инфоблоке создаются и обновляются все товары, которые были в XML файле. Сопоставление товаров в файле товарам на сайте происходит по полю XML_ID.

Если на сайте нет товара с XML_ID из файла, он создается. Если есть, то выполняется сравнение полей из XML файла с аналогичными полями в БД.

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

При импорте товара заполняется поле TMP_ID. Значение для этого поля хранится в узле <НомерВерсии>. Если узла нет Битрикс вычисляет контрольную сумму от всей информации о товаре из XML файла.

Возможные ошибки

Шаг 2.10 Деактивация/удаление товаров (повторяющийся)

На этом шаге раньше (как и на шаге 2.8 Пересчет дерева разделов ) Битрикс проводил чистку товаров. Чистка товаров происходила только если в узле Классификатор XML файла не было пометки СодержитТолькоИзменения="true" (старый формат выгрузки). Есть аналогичная настройка для выбора, что делать с товарами.

В 2019 году на этом шаге ничего не происходит.

Шаг 2.11 Завершение импорта

Служебный шаг. Обработки данных нет, только испускается событие OnSuccessCatalogImport1C .

Шаг 3. Деактивация старых данных

На этом шаге в 2019 году Битрикс деактивирует все товары и разделы каталога, не затронутые в текущей сессии. Для этого время последнего изменения сравнивается с timestamp, который передает 1С время начала текущей сессии, полученное на шаге авторизации.

Напомним, что эти настройки в панели управления сайта сейчас ни на что не влияют (всегда происходит деактивация):

Этот шаг будет выполнен, только если современная 1С делает полную выгрузку. Для выгрузки изменений и в старых версиях 1С этого шага нет.

Шаг 4. Завершение импорта

Служебный шаг. Обработки данных нет, только испускается недокументированное событие модуля catalog OnCompleteCatalogImport1C. Аргументы обработчика аналогичны обработчикам события OnSuccessCatalogImport1C , возвращаемого значения нет.

Обмен справочниками (1С -> Битрикс)

Данный тип обмена (type=reference) используется для создания и обновления на сайте HL-блоков. Этот тип намного короче чем обмен товарами и повторяет многие из его шагов.

Часто обмен справочниками простой и быстрый способ расширить стандартные функции обмена.

Шаг 1. Передача файла (повторяющийся)

см. аналогичный шаг обмена товарами , (отличается только mode, в данном типе обмена mode=reference).

Шаг 2. Основной

Шаг 2.1 Распаковка архива (повторяющийся, необязательный)

см. аналогичный шаг обмена товарами .

Шаг 2.2 Подготовка справочника

На этом шаге Битрикс создает HL-блок (если не существует) и все UF-поля. В начале шага испускается событие модуля catalog OnBeforeCatalogImportHL. Событие недокументированное, в обработчики передаются массив параметров компонента и путь к XML-файлу. Обработчик может вызвать ошибку и вернуть произвольное сообщение.

Важно знать следующие особенности импорта справочников:

• 1С не может удалить справочник или поле, только создать;

• 1С может создать только поля следующих типов: Строка, Булево, Дата, Число;

• все поля, создаваемые 1С будут одиночными, необязательными, скрытыми в фильтре, показанными и редактируемыми в таблице;

• Битрикс автоматически создает поля: UF_NAME, UF_XML_ID, UF_VERSION, UF_DESCRIPTION.

Возможные ошибки

Расшифровка кодов ошибок.

Шаг 2.3 Импорт элементов (повторяющийся)

На этом шаге Битрикс импортирует все элементы HL-блока.

Если выгрузка была полной, Битрикс удаляет все элементы HL-блока, у которых значение поля UF_VERSION не начинается с <ID текущей сессии> + #

В конце шага Битрикс испускает событие модуля catalog OnSuccessCatalogImportHL. Аргументы массив параметров компонента и путь к файлу.

Возможные ошибки

Аналогичны ошибкам на предыдущем шаге.

Формат файлов

Формат файла обмена товарами

Формат файла обмена предложениями

Формат файла обмена ценами товаров и предложений

Формат файла обмена остатками товаров и предложений

Формат файла обмена справочниками

Поясним некоторые места этого XML.

• Узел <Ид>

  • Значение становится названием сущности (после транслитерации).

  • С префиксом b_ становится названием таблицы (после транслитерации).

• Узел <Наименование> Не используется. Вообще. Но если узла не будет в файле, Битрикс выдаст ошибку (sic!)

• Каждый <Реквизит> описывается тремя узлами:

  • <Ид>

    • Значение становится XML ID поля

    • С префиксом UF_ становится кодом поля

  • <Наименование>

    • Значение становится названием UF-поля.

  • <ТипЗначений>

    • 4 допустимых значения: Строка, Булево, Дата, Число

• Каждый <ЭлементСправочника> описывается полями:

• <Ид>

  • Становится значением поля UF_XML_ID

• <НомерВерсии>

  • C префиксом <ID текущей сессии> + # становится значением поля UF_VERSION

• <ЗначенияРеквизитов>

  • Реквизит Код

    • Становится значением поля UF_NAME

  • Реквизит Наименование

    • Становится значением поля UF_DESCRIPTION

  • Реквизит ПометкаУдаления

    • Не используется

  • Прочие реквизиты

    • Поля типа Дата представлены в формате YYYY-MM-DD HH:MI:SS.

    • Поля типа Булево представлены строками true или false (или пустой строкой).

Как дорабатывать обмен?

Все запросы (при стандартном обмене) 1С присылает на служебную страницу /bitrix/admin/1c_exchange.php. Но если заглянуть в файл, выяснится что вся логика скрыта в недрах модуля Торговый каталог в файле /bitrix/modules/sale/admin/1c_exchange.php. Эти страницу нельзя изменять, но можно скопировать (обычно мы копируем в /bitrix/admin/1c_exchange_custom.php) и изменить адрес в 1С.

На этой странице, в зависимости от переданных GET-параметров (совсем как комплексные компоненты в режиме не-ЧПУ) подключаются разные простые компоненты. Компоненты без шаблонов.

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

Существует 3 принципиально разных способа доработать обмен с 1С:

1. Не трогать стандартный обмен, использовать обработчики событий.

2. Кастомизировать файлы обмена на стороне сайта и доработать по требованиям

3. Выгружать нужные данные как справочники и обрабатывать самостоятельно.

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

Второй способ реализуется так:

1. Создать собственную страницу обмена. Обычно это /bitrix/admin/1c_exchange_custom.php.

2. На эту страницу перенести код из /bitrix/modules/sale/admin/1c_exchange.php.

3. Кастомизировать нужный компонент обмена и заменить вызов системного компонента на вызов собственного (например, bitrix:catalog.import.1c на intervolga:catalog.import.1c) на новой странице обмена.

4. Может понадобиться изменение логики класса. Используйте наследование (например, класс \Intervolga\Custom\Exchange\Cml может быть наследником \CIBlockCMLImport и переопределять метод ImportElements).

После правок на сайте нужно изменить параметр Адрес сайта и путь до скрипта обмена в 1С. Имя пользователя и пароль одинаковые как для стандартного обмена, так и для доработанного.

Третий способ(через справочники) подходит, если у нужной сущности 1С совсем нет аналога на сайте или по каким-то причинам стандартный импорт совсем не годится. У модуля highloadblock есть все необходимые события (создание, редактирование, удаление) и для ненагруженных проектов это достаточно неплохое решение.

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

Отладка обмена отдельный больной вопрос. Обычно решается логированием всех происходящих в недрах Битрикса процессов. В ИНТЕРВОЛГЕ разработали свою систему логирования обмена, которая представляет весь процесс в виде диаграммы Гантта. На ней сразу видно, если идут одновременно 2 обмена или 1С не дожидается ответа и начинает слать новые запросы.

Заключение

Часто самой сложной задачей в процессе разработки является именно интеграция с 1С. Отчетливое понимание происходящих в Битриксе процессов необходимо для серьезных проектов.

Автор статьи: Анатолий Ерофеев.

Среди программистов 1С очень популярна тема убийцы 1С, в частности и потому что на 1С очень удобно разрабатывать небольшие карманные приложения с базой данных, но лицензия начинаетсяот 13.000 рублей, поэтому такие маленькие приложения никто не купит:

Поэтому есть запрос на такой же инструмент разработки приложений, как 1С, но дешевле. Бесплатно, недорого или за процент от продаж софта.

До сих пор такой убийца не найден, к сожалению.

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

Убивающее решение может заключаться в том, что разворачивается SQL-база, клиенты с которой работают в базовых, дешевых, версиях 1С.

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

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

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

Технически такая схема вполне реализуема. И ее преимущество не только в 20-кратной экономии затрат на лицензии. Такая реализация плавный способ перейти с 1С на нормальную SQL-базу, постепенно 1С-функции можно переписать на не проприетарную платформу.

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

Что скажете? Можно ли убить 1С средствами самой 1С?

Идея подобного решения возникла из практики. Сейчас в России широко внедряется маркировка товаров и некоторые отечественные дилеры стали отправлять поставщикам список марок с их штрих-кодами в графическом виде в MXL-файлах. Это файлы 1С, похожие на Excel.

Одному из производителей товаров, расположенным не в России, потребовалось обрабатывать эти MXL-файлы сортировать, вырезать необходимые участки, нумеровать этикетки.

Естественно, в их стране про 1С ничего не знали. Покупать 1С им тоже не очень хотелось. Предложение взлома было мною отвергнуто. Я уже хотел предложить им облачные решения, вроде Fresh, но потом вдруг вспомнил про 1С:Деньги. И проблема поставщика была решена за 600 рублей! Они просто запускали внешнюю обработку, которая сортировала с необходимыми отборами исходный большой файл марок в MXL или PDF.

Так что, как видно хотя бы на этом примере, базовое решение 1С позволило избавиться от необходимости стрелять из 13.000 рублевой пушки по воробьям!

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

В конечном итоге, рано или поздно, движок 1С перепишут конкуренты и она останется только в нише 1С:Бухгалтерии. И будет горько сожалеть об упущенных возможностях.