Настроить аналитику по складам

Дата публикации 05.04.2021

Использован релиз 3.0.90

Чтобы вести учет номенклатуры (запасов) в программе в разрезе складов:

настройте аналитику по соответствующим счетам бухгалтерского учета в плане счетов (субконто «Склады» для счетов 08.04.1, 10, 21, 41, 42, 43);
добавьте новые элементы в справочник «Склады» (если в справочнике будет только один элемент, то поле «Склад» в документах отображаться не будет ).

Настройка аналитики счетов бухгалтерского учета в плане счетов:

Раздел: Главное — План счетов (или раздел: Администрирование — Параметры учета).
Перейдите по ссылке «Настройка плана счетов», затем по ссылке в поле «Учет запасов» (рис. 1).
В форме «Учет запасов» установите флажок «По складам (местам хранения)» и выберите один из двух вариантов учета:
- «По количеству». Этот вариант позволяет контролировать наличие запасов на разных складах в количественном выражении, а цена списания запасов будет определяться путем деления общей стоимости этой номенклатурной позиции на всех складах на ее общее количество. Проводки на перемещение запасов между складами будут формироваться только в количественном выражении.
- «По количеству и сумме». Этот вариант позволяет вести не только количественный, но и суммовой учет в разрезе складов. Цена списания запасов будет определяться по каждому складу отдельно.
Кнопка «Записать и закрыть».

Добавление новых складов в справочник «Склады»:

Раздел: Справочники – Склады.
Кнопка «Создать» (рис. 2).
Введите наименование склада и выберите тип склада.
Остальные поля заполните при необходимости.
По ссылке «Счета учета номенклатуры» можно установить счета учета номенклатуры по этому складу для автоматической подстановки в документы.

Смотрите также

Не пропускайте последние новости — подпишитесь
на бесплатную рассылку сайта:

десятки экспертов ежедневно мониторят изменения законодательства и судебную практику;
рассылка бесплатная, независимо от наличия договора 1С:ИТС;
ваш e-mail не передается третьим лицам;

Источник

Настроить аналитику по складам

Как в 1С настроить учет по складам? Настройка учета по складам в «1С:Бухгалтерии» (ред. 3.0).

Как в 1С настроить учет по складам? Настройка учета по складам в «1С:Бухгалтерии» (ред. 3.0). Создание склада в «1С:Бухгалтерии» (ред. 3.0). Настройка параметров учета.

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

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

Для настройки ведения учета МПЗ в разрезе складов необходимо сделать следующие настройки программы»1С:Бухгалтерии» (ред. 3.0):

настроить аналитику плана счетов (субконто «Склады» у счетов 08, 10, 41, и 43) — в форме «Параметры учета»;
добавить новые склады — в справочнике «Склады».
настроить план счетов:

Настраиваем аналитику плана счетов

Откроем раздел Администрирование. Затем выберем пункт меню Параметры учета.

Далее выбираем Настройка плана счетов

Затем редактируем учет запасов

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

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

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

Добавление склада

Переходим в меню Справочники. И далее выбираем подменю Склады.

Затем кликом по кнопке Создать

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

Подтверждаем нажатием на кнопку Записать и закрыть.

Если у Вас появились вопросы по статье или остались нерешенные проблемы обсудить их Вы можете на Форуме 1С Вопросы и ответы

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

О складских аналитиках и группах аналитик

Применимо к: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

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

Складские аналитики и группы складских аналитик.

Складские аналитики можно назначить группам складских аналитик.

Группа аналитик продуктов

Конфигурация

Цвет

Размер

Группа аналитик хранения

Сайт

Склад

Местоположение

Код палеты

Группа аналитик отслеживания

Номер партии

Серийный номер

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

Группы аналитик продукта

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

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

У продукта подтипа Продукт варианты отсутствуют. Продукты этого подтипа не связаны с группой аналитик продуктов.

Группы аналитик хранения и группы аналитик отслеживания

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

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

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

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

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

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

Добавьте группу аналитик хранения и группу аналитик отслеживания к существующему продукту.

Щелкните Управление сведениями о продукте > Обычный > Продукты > Все продукты и шаблоны продукции.

Выберите продукт, а затем на панели операций в группе Настроить щелкните Группы аналитики.

В поле Группа аналитик хранения выберите группу аналитик хранения для продукта. В поле Группа аналитик отслеживания выберите группу аналитик отслеживания.

Определение группы аналитик хранения и группы аналитик отслеживания при создании выпущенного продукта

Щелкните Управление сведениями о продукте > Обычный > Используемые продукты.

В разделе Панель операций в группе Создать щелкните Продукт.

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

В поле Группа аналитик хранения выберите группу аналитик хранения для выпущенного продукта. В поле Группа аналитик отслеживания выберите группу аналитик отслеживания.

Изменение группы аналитик продукта для шаблона продукта

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

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

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

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

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

Изменение группы аналитик хранения и группы аналитик отслеживания для продукта

Если для продукта существуют проводки, группу аналитик хранения и группу аналитик отслеживания изменить нельзя. Однако если продукт не используется в проводках, применяются следующие правила.

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

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

Удалите настройку группы аналитик хранилища и группы аналитик отслеживания для общего экземпляра или экземпляров продукта.

Удалите настройку группы аналитик хранилища и группы аналитик отслеживания для выпущенного экземпляра или экземпляров продукта.

Выберите новую группу аналитик хранения и новую группу аналитик отслеживания для общего экземпляра продукта.

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

Источник

DIY: как мы автоматизируем мониторинг склада

Под управлением Х5 находится 43 распределительных центра и 4 029 собственных грузовых автомобиля, они обеспечивают бесперебойную поставку продуктов в 15 752 магазина. В статье поделюсь опытом создания с нуля интерактивной системы мониторинга событий склада. Информация будет полезна логистам торговых компаний с несколькими десятками распределительных центров, управляющих широким товарным ассортиментом.

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

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

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

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

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

После оценки объёма работ, который необходимо выполнить для построения новой системы, было решено разбить проект на несколько этапов:

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

На первом этапе система должна собирать со всех WMS комплекса подготовленные срезы оперативных данных. Чтение происходит практически в режиме реального времени (интервалы менее 5 минут). Фишка в том, что данные необходимо получать из СУБД нескольких десятков складов при развёртывании системы на всю сеть. Полученные оперативные данные обрабатываются логикой ядра системы для вычисления отклонений от запланированных показателей и подсчёта статистики. Обработанные таким образом данные необходимо отобразить на планшете менеджера или на информационном табло склада в виде понятных графиков и диаграмм.

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

Общая архитектура системы получилась как на рисунке.

Каждая инстанция WMS определена как хост для системы мониторинга. Сбор метрик выполняется центральным сервером в сети ЦОД через запуск скрипта с подготовленным SQL запросом. В случае необходимости мониторинга системы, которая не рекомендует прямой доступ к БД (например, SAP EWM) для получения показателей можно использовать вызовы скриптом документированных API функций или написать несложную программу на python/vbascript.

В сети склада разворачивается инстанция Zabbix proxy для распределения нагрузки с основного сервера. Через Proxy обеспечивается работа со всеми локальными инстанциями WMS. При очередном запросе параметров сервером Zabbix на хосте с Zabbix proxy выполняется скрипт для запроса метрик из БД WMS.

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

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

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

Настройки

Установка и настройка основных компонентов системы (SQLcl, Zabbix, Grafana) описана в разных источниках и здесь не будем повторяться. Использование SQLcl вместо SQLplus связано с тем, что SQLcl (интерфейс командной строки СУБД Oracle, написанный на java) не требует дополнительной установки Oracle Client и работает «из коробки».

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

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

Система мониторинга Zabbix предоставляет несколько вариантов сбора метрик контролируемой системы. Это возможно сделать как непосредственным опросом контролируемых хостов, так и более продвинутым методом отправки данных на сервер через zabbix_sender хоста, включая методы настройки параметров низкоуровнего обнаружения (low-level discovery). Для решения нашей задачи вполне подходит метод прямого опроса хостов центральным сервером, т.к. это позволяет получить полный контроль за последовательностью получения метрик и обеспечивает использование одного пакета настроек/скриптов без необходимости распространять их на каждый контролируемый хост.

В качестве «подопытных» для отладки и настройки системы используем рабочие таблицы WMS для управления приёмкой:

ТС на приёмке, все, которые прибыли: Все ТС со статусами за период «- 72 часа от текущего времени» — идентификатор SQL запроса: getCars.
История всех статусов ТС: Статусы всех ТС с приходом за 72 часа — идентификатор SQL запроса: carsHistory.
Запланированные ТС на приемку: Статусы всех ТС с приходом в статусе «Запланирована», интервал времени «- 24 часа» и «+24 часа» от текущего времени — идентификатор SQL запроса: carsIn.

Итак, после того как мы определились с набором метрик работы склада, подготовим SQL запросы к базе данных WMS. Для выполнения запросов желательно использовать не основную БД, а её «горячую» копию — standby.

Подключаемся к standby СУБД Oracle для получения данных. IP адрес для подключения к тестовой базе 192.168.1.106. Параметры подключения сохраняем на сервере Zabbix в TNSNames.ORA рабочей папки SQLcl:

Это позволит нам запускать SQL запросы к каждому хосту через EZconnect, указав только логин/пароль и имя БД:

Подготовленные SQL запросы сохраняем в рабочей папке на сервере Zabbix:

и разрешаем доступ пользователю zabbix нашего сервера:

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

Готовим основной скрипт, назовём его wh_Metrics.sh, для вызова SQL запроса к БД, сохранения результатов и возврата технической метрики с показателями успешности получения данных:

Готовый файл со скриптом размещаем в папке для размещения внешних скриптов в соответствии с установками конфигурации Zabbix-proxy (по умолчанию — /usr/local/share/zabbix/externalscripts).

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

Результат вызова SQL запроса сохраняется в файле вида mon_base_id_main.log, где base_id = идентификатор БД, полученный в качестве параметра скрипта. Разделение файла результата по идентификаторам баз данных предусмотрено на случай запросов от сервера одновременно к нескольким БД. Запрос возвращает отсортированный двумерный массив значений.

Следующий скрипт, назовём его getMetrica.sh, нужен для получения из файла с результатом запроса заданной метрики:

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

На каждом узле БД установлен и настроен Zabbix-агент.

На основном сервере определяем все сервера с Zabbix-прокси. Для настроек переходим по следующему пути:

Администрирование → Прокси → Создать прокси

Определяем контролируемые хосты:

Настройка → Узлы сети → Создать узел сети

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

Указываем группу для узла, а также IP-адрес или DNS-имя узла с БД.

Создаём метрики и указываем их свойства:

Настройки → Узлы → ’имя узла’ → Элементы данных>Создать элемент данных

1) Создаём основную метрику для запроса всех параметров из БД

Задаём имя элемента данных, указываем тип “Внешняя проверка”. В поле “Ключ” определяем скрипт, которому в качестве параметров передаём имя БД Oracle, название sql-запроса, логин и пароль для подключения к БД. Устанавливаем интервал обновления запроса 5 минут (300 секунд).

2) Создаём остальные метрики для каждого статуса ТС. Значения этих метрик будут формироваться на основании результата проверки основной метрики.

Задаём имя элемента данных, указываем тип “Внешняя проверка”. В поле “Ключ” определяем скрипт, которому в качестве параметров передаём имя БД Oracle и код статуса, значение которого хотим отслеживать. Устанавливаем интервал обновления запроса на 10 секунд больше, чем основной метрики (310 секунд), чтобы результаты успели записаться в файл.

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

Настройки → Узлы → ’имя узла’ → Элементы данных → Подфильтр “Внешние проверки”. Отмечаем нужную проверку и нажимаем “Активировать”.

Далее активируем остальные метрики одной операцией, выделив их все вместе:

Теперь Zabbix начал собирать бизнес-метрики складов.

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

Источник