gifts2017

Технические проблемы взрывного роста компании

Опубликовал Роман Царенко (R.Tsarenko) в раздел Управление - Техническое задание

Хочу рассказать об очень интересном проекте, с которым мы недавно столкнулись. В этом проекте необходимо было сделать огромный объем работы за очень короткий промежуток времени, поэтому мы его условно назвали «Марафон со спринтерской скоростью».

Специфика проекта

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

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

Этот проект было необходимо реализовать за три с небольшим месяца. Условно его можно было разбить на три части.

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

Описание текущего состояния учета перед началом проекта

Положение в начале проекта было довольно веселое. Это был яркий пример «зоопарка систем»:

  • Основная база была – УПП (больше 700 ГБ на тот момент). Она очень активно использовалась, в ней многое делалось;
  • Также использовалась периферийная база в виде Розницы – это была распределенная база, у каждого магазина стояла своя файловая версия, и все это между собой каким-то образом обменивалось (всего получалось почти 500 баз);
  • И еще там использовался целый ряд различных систем для других сервисов, включая базу для интернет-магазина и т.д.

И все это нужно было приводить в порядок.

Введение учета по характеристикам

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

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

  • А проблема была в том, что при таком объеме работы бухгалтерам показалось не очень интересным вводить в документы в 10 раз больше строк, и они, мягко говоря, против этого протестовали. Это – первый момент.
  • А второй момент выходит из первого, потому что когда поступление делается на основной склад, и бухгалтеры не готовы заводить товары по размерам, то возникает вопрос – каким образом эти размеры должны появиться?

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

Начали «растаскивать букет на части» путем изменения механизмов проведения. В чем это заключалось?

  • По сути, для регистра бухгалтерских партий характеристики не проводились вообще никогда – там всегда проводилась только номенклатура (и при приходах, и прирасходах).
  • А для управленческих партий это выглядело несколько иначе. В справочник складов был добавлен реквизит и, в зависимости от того, включен он или не включен, проверялось:
    • Если реквизит включен, то для этого склада характеристики проводились;
    • А если он не включен, то не проводились.
  • Интересная ситуация возникала тогда, когда производилось перемещение между разноименными складами, на одном из которых характеристик не было, а на другом –были. Для того чтобы разрешать такие ситуации, пришлось прилично «похимичить» в партионном модуле, но мы аккуратно «скальпелем все обрезали», и стало проводиться довольно красиво.
    При оформлении перемещения между такими складами характеристики указывались в любом случае:
    • Если перемещалось на склад «без характеристик», то они указывались для того, чтобы все корректно списывалось,
    • А если перемещалось на склад «с характеристиками», то они указывались для того, чтобы товары правильно приходовались (чтобы этим потом можно было как-то еще управлять).

В принципе, задача была реализована, и это уже стало серьезным «толчком» вперед.

Однако возникал вопрос по поводу «бесшовного перехода» регионов на учет по характеристикам. Что помогло в его решении:

  • Первое – это ориентир на наличие дополнительного реквизита в складах.
  • А все остальное было решено с помощью центральной базы РИБ, которая использовалась и до этого. В частности, от нее решили не отказываться в пользу «бесшовности», как в случае с характеристиками, так и при переходе на онлайн-учет, о котором я скажу позже. Переход на онлайн-учет у нас тоже происходил не сразу, заказчику нужно было дать время, потому что перевести на новую архитектуру 500 магазинов за один день было практически нереально – я таких алгоритмов не знаю. Тем более с той структурой организаций, которая была у заказчика, это невозможно. Поэтому мы решили от центральной базы не отказываться, и это тоже серьезно помогло.

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

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

Решив эту проблему, мы переключились на следующую.

Разработка архитектуры системы и баз данных

Следующее решение можно назвать «облачным». Если коротко, то мы создали у заказчика свое личное «облако», которым он может управлять. Это решение состояло из:

  • IT инфраструктуры;
  • Самой структуры;
  • И выбора СУБД для нее.

Во-первых, у нас возник довольно серьезный вопрос относительно того, использовать чисто «железную» реализацию или все-таки использовать виртуализацию?

  • От виртуализации мы практически сразу отказались – в основном, из-за нестабильности работы на ней программного лицензирования на больших объемах. Она вроде бы работает, но как только что-то меняется в характеристиках сервера, все сразу ломается и рассыпается. А это – серьезное ограничение.  Даже на сегодняшний день, хотя мы и проводили на эту тему уже немало испытаний, мы все равно еще не смогли реализовать такую схему. Хотя попытки ведутся до сих пор.
  • Поэтому мы использовали «железную» реализацию.

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

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

Еще один интересный момент – это выбор между PostgreSQL и MS SQL.

Когда объем данных  вырастает, соблазн использовать для их хранения бесплатную СУБД становится довольно большим. Однако что может этому помешать?

  • Во-первых, специалистов по PostgreSQL практически не найти, по крайней мере, за Уралом – это я могу точно сказать. И, если возникают какие-то проблемы, то время от их возникновения до решения становится довольно большим. А постоянно вызывать для подключения к этим вопросам кого-то из Москвы – это не вариант.
  • Во-вторых, на тот момент в PostgreSQL были серьезные проблемы с RLS (разделением доступа на уровне записей). Иначе говоря, включаем RLS – все, PostgreSQL ложится, и с этим ничего нельзя сделать – падение производительности настолько большое, что становится просто невозможно работать. Это ограничение на тот момент тоже сыграло свою роль.

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

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

Информация об актуальных остатках товаров в целом по сети

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

Как это происходило раньше? При поступлении заказа в интернет-магазин его сотрудник начинал прозванивать все магазины региона (если не сети) и узнавать, есть ли у них вещь такого-то размера – можете себе представить, сколько времени это занимало. Конечно, эту проблему надо было решать.

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

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

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

Переделка интерфейсов на управляемые формы и переход на 8.3

Следующая «веселая» вещь заключалась в том, что у нас использовалась Розница 1.0 на обычных формах. И получалось, что та архитектура, которую мы придумали для заказчика, конечно, замечательная, но как с этим теперь работать? Представьте себе терминальный доступ для 500 магазинов – это весьма сомнительное решение, к тому же администрировать его очень непросто.

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

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

В платформенном механизме 1С этот функционал уже был заложен, но в 8.2 он не отрабатывал вообще, а в 8.3 все работало превосходно.

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

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

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

Реализация работы в офлайне

Было еще одно интересное решение – это реализация работы магазинов в офлайне.

При переводе учета из файловых баз в «облако» наличие постоянного доступа к данным для каких-то видов деятельности не всегда критично (например, если вы ведете бухгалтерию в стартапе и доступ к базе вам нужен раз в месяц). Но когда вы ведете в базе продажи и оперативную деятельность, это становится очень критично. Тем более что заказчик сказал: «ребята, ваше решение с нашим облаком – это здорово, но что мы будем делать, если у нас пропадет интернет (а в некоторых регионах связь не очень стабильная и может пропадать)?»

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

  • Там были реализованы почти такие же интерфейсы, как и в основной базе.
  • Но была очень интересная особенность: все было на примитивных типах данных (по сути дела, на строках). Этого было вполне достаточно, потому что:
    • Когда мы считываем шрихкод, он конвертируется в строку, которая соответствует конкретной номенклатуре или характеристике,
    • Цены вводились вручную по ценнику
    • Магазин всегда можно использовать текущий – с этим никаких проблем не было.
  • При этом, конечно,было ограничение в видах продаж: нельзя было продавать по эквайринговым терминалам, в кредит и т.д. Но этого в принципе нельзя было сделать и в предыдущей схеме при отсутствии интернета, поэтому это никого особо не беспокоило.

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

  • Фактически, когда мы запускали офлайновую базу и проводили первый чек, на диске в скрытой папке формировался файл с данными. С одной стороны, это было рискованно, потому что пользователь мог этот файл найти и удалить, но у нас ведь смысл был не в том, чтобы защититься от какой-то хакерской атаки или случайного удаления, поэтому такое решение оказалось достаточно стабильным, и проблем с этим до сих пор нет.
  • А когда интернет снова появлялся и мы открывали онлайн-базу заново, осуществлялась проверка, и если этот файл был на диске, мы в рабочее место кассира зайти не могли: была надпись «извините, но перед началом работы необходимо обеспечить обмен».
  • Пользователь нажимал соседнюю кнопку, запускал обмен и, если он проходил успешно и все данные были распознаны, этот файл пропадал, и разрешалась дальнейшая работа.

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

Оптимизация работы

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

Поэтому нам пришлось оптимизировать этот механизм. Это происходило в несколько этапов:

  • Первый этаппереход на 8.3. Смысл в следующем: когда мы, работая на 8.3, отключаем режим совместимости, у нас появляется возможность использовать для MS SQL уровень изоляции READ COMMITTED SNAPSHOT, и это очень серьезно решает проблему блокировок. В частности, когда мы начинаем восстанавливать партии с использованием стандартных партионных модулей, и в этот момент у нас одновременно работают пользователи (а именно так это и происходило у заказчика, причем от этого нельзя было отказаться), данный уровень изоляции очень спасает.
  • Еще одним важным моментом было использование типовой обработки проведения по партиям. По некоторым причинам заказчик ее не использовал:
    • Во-первых,в модулях было сделано немало доработок, но именно в модулях документов, а не в партионном модуле, поэтому если бы мы использовали типовую обработку, то у нас те данные, которые записаны в проводках и в документах, могли бы не совпасть. А это, собственно, проблема.
    • Во-вторых, типовая обработка не отрабатывает моменты, когда возникают блокировки – в этих случаях она просто заканчивает свою работу.
    • И третий, довольно важный момент – это логирование. Потому что когда у вас в течение 30-40 часов что-то восстанавливается, и при этом происходит какой-то системный сбой, то вам бы не хотелось начинать все сначала. Поэтому заказчик выставил требование, чтобы можно было использовать хотя бы какие-то данные, которые обработка на этот момент успела создать, хотя бы в залогированном виде. Чтобы можно было сразу что-то решать и не ждать, когда в следующий раз на следующих выходных эта обработка снова будет запущена. Это было необходимым требованием.

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

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

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

Заключение

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

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

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2016 DEVELOPER.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Caponid V (caponid) 26.09.16 15:07
Можно более подробно о
Исключили из проведения некоторые измерения, которые не участвуют.

2. Геннадий Николаев (genayo) 27.09.16 08:08
Интересно, на складах адресное хранение внедрили?
3. Евгений Сергеев (sev@snail.ru) 27.09.16 14:58
Я правильно понимаю, что сейчас архитектура системы выглядит следующим образом.
Есть основная база УПП, есть 40 баз для регионов с которыми в режиме тонкого клиента работает допиленная Розница 1.0(500 магазинов)
Между УПП и 40-а базами регионов раз в сутки передаются данные. Верно?
4. Петр Самчук (Frogger1971) 28.09.16 09:47
так и не понял, как у вас характеристики "появлются" из ниоткуда
5. Марат Хафизов (Painted) 28.09.16 10:27
когда мы, работая на 8.3, отключаем режим совместимости, у нас появляется возможность использовать для MS SQL уровень изоляции READ COMMITTED SNAPSHOT
Что запрещает в 8.2 использовать уровень изоляции READ COMMITTED SNAPSHOT?
6. Имя Фамилия (neyasytyf) 28.09.16 13:13
Где-то, что-то сделали, как-то работает, такой вывод после прочтения.
7. Denis Lebedev (dlebedev8) 29.09.16 11:12
8. Denis Lebedev (dlebedev8) 29.09.16 11:14
(5) Painted, лицензия 1С, если память не изменяет.

Мне вот интересно, как перевели УПП на 8.3 без режима совместимости? Сколько часов ушло на ловлю блох из-за, прямо скажем, хреновой совместимости старого кода с новой платформой?

У самого УТ 10.3 работает на платформе 8.3, но в режиме совместимости из-за проблем с коллизиями имен некоторых функций или переменных (и это только то, что сразу бросается в глаза).
9. Александр Крынецкий (echo77) 29.09.16 19:43
(4) Frogger1971, ответ здесь:
При оформлении перемещения между такими складами характеристики указывались в любом случае:
Если перемещалось на склад «без характеристик», то они указывались для того, чтобы все корректно списывалось,
А если перемещалось на склад «с характеристиками», то они указывались для того, чтобы товары правильно приходовались (чтобы этим потом можно было как-то еще управлять).
10. Denis Lebedev (dlebedev8) 30.09.16 07:28
Любопытно еще, как решили проблему корректности остатков, при таком "гибридном" подходе к характеристикам номенклатуры. Но это, я так понимаю, они выяснят еще не скоро, после парочки масштабных ревизий.
11. Евгений Евгений (leasing) 02.10.16 10:54
(6) neyasytyf, Если статья и вызывает недоверие- то это целиком заслуга автора. .
Поэтическое название - марафон со спринтерской скоростью. Естественно, что в реальной жизни так не бывает. Потому и читается как фантазия на заданную тему, а не отчет по реально выполненным работам. Объем обозначен, но нет же ни одной даты нет, ни одного периода - день, неделя, месяц, квартал, год, десятилетие? Может это было марафон с черепашьей скоростью? А был ли марафон?
12. Виктория Дорохина (vikad) 02.10.16 16:57
(11) leasing, последний абзац первого раздела:
Этот проект было необходимо реализовать за три с небольшим месяца
13. Евгений Евгений (leasing) 03.10.16 11:39
(12) vikad, да это указание налицо. Но полной ясности нет. "Она шла несколько позже, но о ней я тоже расскажу. Эта часть также была необходимым элементом общей системы." Вот эту фразу как Вы понимаете? Я понял, что оптимизация началась после первых 2-х этапов, длившихся более трех месяцев.
А если принять во внимание "Заказчик остался доволен, и сейчас происходит дальнейшее развитие системы, уже немного в другом ключе." ? То получается что работы еще идут и как это увязывается со "марафонским спринтом или спринтерским марафоном"? И потом, а сколько человек в забеге было - человеко -месяцев потрачено сколько? 100 человек работало, или 10, или 1? Это ведь тоже существенно. И вот когда обнародуют эти цифры, тогда и выводы можно сделать про спринт и марафон.
У меня материал вызвал не то что недоверие, а сомнение зачем это было рассказано. Вернее недорассказано.
14. г. Казань Рустем Гумеров (Rustig) 02.11.16 00:35
(13) некоторые фишки все же подробно описаны. я для себя много чего почерпнул. Из описания предположу что в проекте участвовало минимум 8 человек: директор (он же 1с-ник с большим опытом), грамотный сисадмин, один специалист уровня эксперт 1с по технологическим внедрениям, два консультанта, два программиста, секретарь. Плюс со стороны Заказчика имелись "умные" пользователи 1с - постановщики задач, которые прочувствовали, что из 1с можно "запилить" все, что угодно для общего блага.
15. г. Казань Рустем Гумеров (Rustig) 02.11.16 00:36
(0) спасибо за статью, доклад не видел, статья понравилась
16. Роман Царенко (R.Tsarenko) 10.11.16 11:19
(4) Frogger1971, Характеристики появляются из ТСД, которым прощелкиваются штрихкоды. Штрихкоды новые и наклеены с учетом характеристик. Откуда не возьмись они не возникают. Когда происходит перемещение на магазин, они все покоробочно прощелкиваются. Ответил на вопрос?
17. Роман Царенко (R.Tsarenko) 10.11.16 11:20
(14) Rustig, Спасибо! Для того и делался доклад, а потом и статья.
18. борян петров (TODD22) 10.11.16 11:23
А не подскажите у вас в магазинах базы файловые?
Каким образом выполняется обновление РИБ узлов?
19. Роман Царенко (R.Tsarenko) 10.11.16 11:39
(3) sev@snail.ru, Не совсем. Есть еще Центральный узел РИБа Розницы с которым существовали многие обмены до проекта и многие остались после. Если я не ошибаюсь Центральный узел Розницы и по сей день является большим собирателем, только с гораздо меньшим количеством баз. УПП не оперативная и не около оперативная база, а итоговый потребитель данных. Многие данные тянутся с Центрального узла Розницы.
20. Роман Царенко (R.Tsarenko) 10.11.16 11:46
(13) leasing, Евгений, я боюсь я вам и в комментарии ясность не внесу. Вы не ставите вопрос, чтобы узнать, вы ставите вопрос чтобы осудить. Статья написана по живому выступлению, для которого и готовился текст и слайды и все остальное. Спросите, что вас интересует и я вам отвечу.
21. Роман Царенко (R.Tsarenko) 10.11.16 14:23
(18) TODD22, Нет, базы все на сервере крутятся. Продавцы по тонкому клиенту заходят. Обновление РИБ узлов части чего? Это не очевидный момент совсем. Если в части конфигурации то все просто, через РИБ и обновляются в регламентное время. А если вопрос про остатки, то там все намного сложнее. Спросите конкретнее.
22. борян петров (TODD22) 10.11.16 14:35
(21)В части конфигурации. У меня базы файловые. Попробовал сделать регламентным заданием, но увы не получилось. Нашёл на ИС публикацию. Запускается рег задание, выгоняет пользователей, формируется батник, запускается и должно по идеи выполнится обновление.
Из 40 узлов отработало в 4-5 узлах.
Причины разные. Не завершились сеансы, зависли. Запустилось фоновое задание.... и тд.

Ищу какой нибудь способ обновлять большое количество узлов.
23. Роман Царенко (R.Tsarenko) 10.11.16 14:42
(10) dlebedev8, Зачем же так пессимистично? Просто не очевидно из статьи, что характеристика это не стволовая аналитика всего учета, как это классически принято по аналогии с номенклатурой. Сущность существенно модифицирована. Важно понять, что для финансовых расчетов характеристикой можно пренебречь (Стоимость одинаковая). Это исключительно управленческая аналитика решающая одну конкретную оперативную задачу. В данном случае знать размеры, которые хранятся в магазине и других магазинах региона. Эта задача полностью решена. Также среди неочевидного, это как делать перемещения. В докладе я об этом говорил, если мне память не изменяет. Суть вот в чем для формирования перемещений была создана спец обработка в которой совмещалось все что было выгружено с ТСД( кладовщикам нет разницы, они щелкают все коробки) после формирования прихода на склад региона с теми перемещениями которые были оформлены на виртуальный склад региона. Это сопоставлялось и сразу формировались перемещения с учетом характеристик. Отклонения также обрабатывались. Формировались и документы списания и оприходования. Если интересно подробнее, я опишу.
24. Роман Царенко (R.Tsarenko) 11.11.16 08:32
(22) TODD22, Мы на самом деле, в том числе с этим и боролись. Когда базы файловые и не понятно на каком железе с какой доступностью расположены(компы где расположены базы, могут просто быть выключены и вы это никак жестко не ограничите), у вас и будут такие проблемы. Мы потому и создавали "по факту облако" на серверах заказчика, чтобы это можно было адекватно администрировать и обмены производить по регламенту. К слову сказать, до проекта, пока базы были файловыми продавцы приходя в магазин, должны были сначала запустить обмен. Это не панацея далеко, об этом тоже не редко забывали, обмен мог сразу не пройти, и это никого особо не волновало и т.д. Это издержки такой архитектуры.
25. борян петров (TODD22) 11.11.16 09:09
(24) Да вот это и пытаюсь побороть.
У меня до этого всё работало на самописной базе. Там проблем с обновлением не возникало. Потому что не было обработчиков выполняющихся после запуска предприятия. И если база не ломалась, то обновление проходило нормально.

А вот с типовой Розницей проблема. Её нужно после обновления конфигурации запустить под правами админа, что бы выполнились обработчики.
Нашёл тут несколько решений на ИС. Буду эксперементировать.
Нет возможности перенести базы в облака. С интернетом в магазинах могут быть проблемы. А магазины маленькие и держать там сервер то же не получится....
26. Олег Дмитров (baracuda) 11.11.16 09:17
Спасибо, очень познавательно. Мы тут с сетью на 5 точек мучаемся, а вы такое запустили. Хорошо потрудились ребята.
Бывалый77; +1 Ответить
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа