Вконтакте Facebook Twitter Лента RSS

Личная карточка работника в 1с где распечатать. Самые важные изменения этой весны

Аналоги аналогов и их аналоги

Казалось бы, зачем убийце убивать
убийцу убийцы?!... но Донцову уже
было не остановить..(с) Интернет

Введение

Все мы знаем, что такое аналоги: взаимозаменяемые товары, с похожими ключевыми свойствами. Однако задача учета аналогов не является тривиальной по своей сути. Во-первых, аналоги не всегда являются взаимозаменяемыми. Помните уроки истории:Вассал моего вассала — не мой вассал. Например, есть два вида обшивки - обычная и влагостойкая. Можно сказать, что влагостойкая является аналогом для обычной, но не наоборот! Таким образом, если покупателю потребуется мебель с обычной обшивкой, которой вдруг не окажется на складе, ее можно будет заменить на влагостойкую.

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

Аналоги можно использовать в нескольких целях (в зависимости от требований заказчика):

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

· после заполнения документа предоставлять возможность воспользоваться распределением недостающих позиций по аналогам;

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

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

Именно поэтому в типовых конфигурациях на платформе «1С:Предприятие 8» задача учета аналогов не автоматизирована. Исключением является конфигурация «1С:Управление производственным предприятием 8», где в одном из производственных документов можно вызывать форму подбора аналогов для материалов.

Постановка задачи

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

Рассматриваем максимально абстрактный пример, поскольку, если разбирать задачу на реальных примерах, например, из пищевого производства - для прочих отраслей это подсознательно означает «это все не про нас». Будем развивать абстрактное мышление.

Рис. 1. Аналоги, задаваемые пользователем

Система должна достроить связи: для красного маркера, аналогами являются и оранжевый и желтый (см. рис. 2, синие стрелки).

Рис. 2. Полная взаимозаменяемость номенклатуры

Аналоги будем использовать для автоматической подстановки при списании, в случае нехватки выбранных товаров. Например, на складе есть 10 красных, желтых и оранжевых маркеров. При попытке списать (переместить в производство, продать) 25 красных маркеров должно списаться 10 красных, 10 оранжевых и 5 желтых, либо 10 красных, 10 желтых и 5 оранжевых. Последовательность списания аналогов должна определяться приоритетом.

Цель статьи - показать механизмы работы с взаимозаменяемыми аналогами. Данный вариант использования аналогов выбран по причине простоты реализации.

В этой статье не хотелось углубляться математику: теорию графов и так далее. Рассмотрим решение задачи в информационной системе «1С:Предприятие 8».

Варианты решения

Вариант жестокий

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

Вариант прямолинейный

Первое что приходит в голову - нужно для начала описать основные пары аналогов, а потом их как-то обрабатывать. Например, пары для маркеров - «Красный-Оранжевый» и «Оранжевый-Желтый». Давайте пойдем по этому пути. Аналоги удобно описать в регистре сведений с двумя измерениями «Номенклатура» и «Аналог», и двумя ресурсами: количество исходной номенклатуры и количество аналога. Самое сложное сделать обработку этих данных - достроить все отсутствующие связи. Для этого нужно для каждого товара определить список его аналогов, и для каждого аналога определить список его аналогов и так далее.Налицо рекурсивный процесс. Но самое неприятное, что для каждого аналога нужно вычислять остатки, а это запрос к базе данных. И, как известно, запрос к БД в цикле (а любую рекурсию можно преобразовать в цикл) негативно сказывается на производительности системы.

Кроме этого в данном варианте нужно следить за тем, чтобы не образовалось кольцо аналогов. Например, пары «Красный - Оранжевый», «Оранжевый - Желтый» «Желтый - Красный». Если подобные данные введет пользователь, то этот алгоритм зациклится.

Вариант правильный

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

Рис. 3. Кластеры аналогов

Таким образом, прежде чем браться за решение задачи нужно разработать структуру базы данных.

Приведем шаги по реализации задачи.

1. Прежде всего, потребуется справочник, описывающий кластеры. Реквизитов в этом справочнике не требуется, достаточно наименования. Называть кластеры можно по-разному, «Кластер 1», «Кластер 2» или «One », «Two ». Следует учитывать, что кластеры создаются системой автоматически, поэтому осмысленные такие названия, как «Столы офисные», «Мебель плетеная» и т.д. вряд ли возможны. Можно применить интересный ход - в наименовании отображать названия товаров, входящих в кластер. То есть название кластера может выглядеть так «Табуретка на 4х ножках; Табуретка на 3х ножках; Табуретка на любителя (на одной ножке)». Такой подход будет удобен для пользователя: можно сразу представить какая номенклатура входит в кластер. Но следует помнить, что длина наименования в справочнике ограничена 150 символами, поэтому название может содержать лишь некоторые элементы, входящие в кластер.

2. Создать объект, описывающий состав кластера (кластеры не должны пересекаться по товарам). Это, конечно же, регистр сведений. Какова будет его структура? Вспомним замечательное свойство регистра сведений - контроль уникальности записейпо всем измерениям и периоду. Поэтому структура должна быть следующей: измерение - номенклатура, ресурс - кластер.

3. Документ, позволяющий определять аналоги. Именно этот документ будет определять (а в случае необходимости и создавать) кластер для пары «номенклатура-аналог». Также нужно учесть, что кластеры могут укрупняться. Например, есть пара аналогов маркеров «Синий - Фиолетовый» они задаются в своем кластере. Также существует кластер маркеров «Красный - Оранжевый - Желтый». Если завести еще одну пару аналогов «Фиолетовый - Оранжевый», то и синий маркер будет аналогом для красного.

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

Действительно, представленный алгоритм может показаться простым для реализации в платформе «1С:Предприятие 8». Но здесь есть подводный камень, который замечают не все разработчики.

Представим, что в документе списываются следующие маркеры:

· красный, 10 шт.

· желтый 10 шт.

На остатках числятся маркеры:

· красный, 5 шт.

· желтый 5 шт.

· оранжевый 9 шт.

В этом случае при обработке первой строки система спишет 5 шт. красных маркеров и 5 шт. оранжевых. И, теперь, главное при обработке второй строки запроса нужно учесть, что оранжевых маркеров осталось всего 4 штуки! То есть, нужно динамически отслеживать уже списанные остатки. Также нужно учитывать, что в приведенном примере желтый маркер является аналогом красного. Значит, может возникнуть ситуация, когда товар, который списывается в текущей строке, уже был списан ранее!

Приоритеты аналогов

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

Для учета приоритетов необходимо ввести понятие веса.

Вес = Приоритет * К покрытия , где

Приоритет -определяется пользователем

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

Заключение

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

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

С уважением к вам, Евгений Гилев.

to Senya

Не совсем верное опеределение, я бы сформулировал несколько иначе:
"В штатном режиме аналоги используются только для заполнения списания (правильнее - отнесения) материалов из НЗП на выпуск готовой продукции/наработку в полуавтоматическом режиме для документов "Отчет производства за смену".

Вообще, работу с фактом в УПП я бы поделил на два режима:

1. Нормативное списание
2. Списание по факту

1-й вариант подразумевает изначально выполненую близко к идеальной предпроизводственную подготовку, т. е. - имеем весь набор спецификаций и задел на складе, полностью покрывающий дефицит до старта производства, по этим спецификациям без использования аналогов. В этом случае, мы формируем НЗП "Требованиями-накладными" и затем этот самый, сформированный НЗП относим на готовую продукцию документами "Отчет производства за смену". При таком, нормативном списании, прямой зависимости между документам производственного учета нет. Мы формируем корзину, а затем дербаним ее.

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

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

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

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

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

Возможно, кому-то пригодится краткий обзор доступных на рынке Украины систем:


Bookkeeper SaaS

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

Первый месяц работы бесплатен, затем 295 грн. в месяц.

Сервис Буккипер постоянно развивается и постепенно наращивает функционал.

Обновления выходят, как минимум, еженедельно.

Видим, что буквально на дату публикации обзора (13/09/18) есть свежее обновление:


Функциональность стандартная для ведения бухгалтерского учета в Украине:

  • Покупки (Входящий счет, Приходная накладная, Возвраты);
  • Продажи (Расходная накладная, Прайс-листы, Остатки);
  • Запасы (Списание, Инвентаризация, Производство);
  • Бухгалтерия (Банк и Касса, Валютные операции);
  • Персонал (Зарплата и кадры, отчеты);
  • НДС (Налоговые накладные, Корректировки, Декларация по НДС);
  • Отчетность (Единый налог, НДС, ЕСВ, НДФЛ и прочие);
  • Реализована возможность отправки налоговых отчетов через программу Соната.

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

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


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


Зато онлайн доступна документация, правда, к сожалению, тоже пока без визуализации форм:


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

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


OpenERP

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

Система начала развиваться усилиями Fabien Pinckaers в 2000 году. Вскоре Tiny ERP начала внедряться на рынке публичных торгов.

Вплоть до конца 2004 года Fabien Pinckaers совмещал в одном лице и разработчика, и менеджера, и дистрибьютора компании Tiny. В сентябре 2004 года (когда он закончил свои исследования), другие программисты были привлечены к развитию и дистрибуции Tiny ERP.

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

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

Каждые 4-6 месяцев выходит стабильная версия, каждый месяц версия для разработчиков. В июне 2007 в версии 4.1.1 появился «веб-клиент», позволяющий с помощью обычного браузера использовать все возможности системы.

В июле 2008 года платформой для организации работы сообщества OpenERP становится Launchpad, а сама система становится более открытой для переводчиков и разработчиков. Также в 2008 году пишется первая версия книги OpenERP, заменяющая документацию системы. С 2009 года OpenERP представлена в составе пакетов Ubuntu и Debian.

Технические особенности

  • Язык программирования Python
  • Взаимодействие сервер-клиент реализовано на протоколе XML-RPC
  • Серверная часть, в качестве СУБД использует PostgreSQL
  • Клиенты на основе GTK
  • Веб-клиент на основе Ajax
  • Разработан веб-клиент для работы с помощью мобильных устройств (пока доступ через него только на чтение)
  • Модульная структура
  • Бухгалтерия
  • Учет активов
  • Бюджет
  • Управление персоналом - HRM
  • Продукция (товары)
  • Производство
  • Продажи
  • Закупки
  • Управление складом
  • SCRUM - управление проектами для разработки ПО
  • Заказ обедов в офис
  • Управление проектами

Принципы работы Tria

Платформа Tria создавалась по образу и подобию самого распространенного на просторах бывшего СССР программного продукта - 1С:Підприємство. Так же, как и 1С:Підприємство, готовое решение состоит из двух частей - платформы (запускаемого приложения) и базы данных.

Сравнение с 1С:Підприємство или немного истории

Система Tria родилась не на пустом месте. Сначала разработчики занимались созданием нестандартных решений на базе 1С:Підприємство 7.7. В результате последовательных изысканий родился механизм хозяйственных операций.

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

Как результат, получили следующие плюсы:

  • Логику работы документов можно менять “на лету”, при этом остальные пользователи продолжают работать в базе.
  • Значительно упростился и ускорился процесс вноса изменений в конфигурацию, а следовательно, значительно снизилась стоимость сопровождения. То, что программист делает в 1С:Підприємство за день, в ТРИА можно сделать за час.
  • Значительно снизился уровень требований к настройщику/внедренцу ТРИА. Люди, не умеющие программировать, сами настраивали проводки, меняли коренным образом логику работы программы. Сместился акцент в требованиях к внедренцам: в первую очередь специалисты должны знать предметную область, понимать методологию работы, а уже затем быть специалистами в ТРИА.

Естественно, что Tria получилась идеологически похожа на 1С:Підприємство. Те же справочники иерархической структуры, документы, журналы документов, регистры. Пока нет плана счетов и периодических реквизитов – планируется со временем. По сути, перед вами нечто похожее на компоненту “Оперативный учет” или “торговля” в 1С:Підприємство.

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

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

Конфигурации, предлагаемые в ТРИА, содержат весь опыт успешного ведения бизнеса наших клиентов. Они получают не только программу, но и постоянные рекомендации и предложения по увеличению прибыльности их компаний. Мы гордимся достижениями наших клиентов, что за 4 года использования ТРИА в Луганской области ни один из клиентов не прекратил свой бизнес, а наоборот, несмотря на кризис, они успешно развиваются.

Технические характеристики Tria

Для нормальной работы Tria достаточно Pentium 150, 32 мегабайта оперативной памяти, 15 мегабайт дискового пространства. Чем больше размер базы данных и объемы вводимой информации, тем большей мощности требуется компьютер, на котором размещена БД.

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

В качестве хранилища данных используется бесплатный SQL-сервер Firebird (существуют версии сервера как под Windows, так и под бесплатные операционные системы (Linux, FreeBSD).

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

Оценка 3.22 из 5 на основе 23 оценок

Please enable JavaScript to view the

Описание технологии производства в программе 1С:УПП производится в объекте "Технологическая карта". В ней нормируется технология изготовления по конкретной спецификации.

Технологическая карта задается не на изделие, а на процедуру выполнения конкретной спецификации!

Технологическая карта в 1С:УПП - это расшифровка, из каких процедур, из каких операций состоит процесс производства по некоторой спецификации.

Рассмотрим, например, такую схему производства: из Трубки и Кабеля мы через промежуточный полуфабрикат "Каркас" и материала «Абажур» собираем продукцию "Торшер".

Рисунок 1 – Полная схема производства

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

Рисунок 2 – Схема производства по спецификациям и технологическим картам

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

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

Рисунок 3 – Технологическая карта

Поля "Подразделение" и "Состояние" необязательны к заполнению.

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

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

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

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

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

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

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

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

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

Связь технологических карт со спецификациями в 1С:УПП осуществляется через регистр сведений "Технологические карты спецификаций номенклатуры":

Рисунок 4 – Связь спецификаций и технологических карт.

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

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

  • Для каждой входящей номенклатуры – на какой операции в технологической карте она поглощается.
  • Для каждой производимой номенклатуры – результатом какой операции она является.

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

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

Аналоги

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

Аналоги задаются в регистре сведений "Аналоги номенклатуры"(интерфейс "Производство" - Номенклатура – Аналоги номенклатуры). Обязательно указание следующих реквизитов:

·"Номенклатура" – номенклатура, которая будет заменяться аналогом, возможно дополнительное указание характеристики

·"Вид аналога" – комплектующая или узел

·"Аналог" – номенклатура или номенклатурный узел, на который будет производиться замена, для номенклатуры возможно также указание характеристики

·"Количество" и "Единица" – количество и единица измерения номенклатуры, подлежащей замене

·"Количество аналога" и "Единица" – количество и единица измерения аналога, на который будет выполняться замена.

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

Аналоги используются для подбора комплектующих, которые были использованы при производстве продукции в документы выпуска продукции. Например, "Отчет производства за смену" (при заполнении вкладки "Материалы" в режиме "Заполнить с подбором аналогов").

Рисунок 5 – Подбор материалов и аналогов

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

Для комплектующих и аналогов справочно выводится следующая информация:

·"№ операции" – номер технологической операции, на которую подаются материалы согласно технологической карте производства (видна только если используется посменное планирование)

·"Норматив" – нормативное потребление комплектующих по данным спецификации

·"Единица" – единица измерения количества комплектующих

·"Свободный остаток на складе" – количество комплектующих или аналогов, которое есть в свободном остатке на складе

·"Свободный остаток в НЗП" – количество комплектующих или аналогов, которое есть в свободном остатке в незавершенном производстве, показывается только для той номенклатуры, для которой в справочнике "Номенклатура" включен признак необходимости ведения оперативных остатков материалов в НЗП

·"Приоритет" – приоритет использования аналогов, который задан в регистре сведений "Аналоги номенклатуры"

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

Спасибо!

© 2024 Новогодний портал. Елки. Вязание. Поздравления. Сценарии. Игрушки. Подарки. Шары