Цикл производство

Мы производим и продаем текстильные детские товары. Осваиваю ваш сервис. Функции производства, хотя бы в самом простом варианте не хватает.

Павел, здравствуйте. Расскажите, пожалуйста, какие именно у вас требования к функционалу "Производство"? То есть, если вас не затруднит, опишите основные бизнес-процессы и документы, которыми вы их закрываете.

Оххх...

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

2) Документ.Заказ покупателя (покупатель возжелал того, чего нет в наличии, но мы возможно можем произвести!)

3) Документ.Заказ на производство (может создаваться на основании заказа покупателя, а может и самостоятельно. В этом документе производится резерв комплектующих из спецификаций на складах)

4) Документ. Заказ поставщику (можно создать на основании заказа на производство, которых не хватает)

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

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

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

Далее уже как обычно - Расходная накладная и счет-фактура.

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

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

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

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

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

Кстати еще очень важно - но чего я пока в 1Ске не понял как сделать - это генерить стоимость производства каждой единицы.

Т.е. у нас в заказе 9 кабелей, у 2х стоимость прозводства 150 рублей, у других по 100 - в итоге цикл должен будет обойтись в 1000 рублей. Пока я не вижу как эту цифру обойти - поэтому учет этой штуки в виде отдельного джоблиста веду в Excel-е (да да 21 век блин)

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

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

Елена.

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

Кстати вот чего НЕТ ВОООБЩЕ НИ У КОГО - это учет бухт... Это ооочень сложный момент. И еще сложнее учесть его при производстве. Определенные аспекты реализовать толково впринципе невозможно.

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

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

Что мешает ввести 2 типа учета товара с нужными коэффициентами?

У нас например, продается светодиодная лента бухтой по 5 метров, а учет ведется метражом.

По умолчанию на продажу стоит "упаковка" и в ней стоит 5.

Бухта кабеля UTP 305 метров... так что все реально...

Принимая 2 бухты кабеля, мы принимаем 610 метров...

Принимая 2 упаковки светодиодной ленты - получаем 10 метров...

Понятно, что все в нашем мире относительно, но если приложить мозг - то все можно сделать...

А вот что реально не хватает - так это гарантийного листа.

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

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

Геннадий, спасибо за ваш комментарий. Павел в свое время имел в виду несколько другую проблему, когда на одной бухте остается обрезок в 5 м кабеля, на другой - в 3 м, а на складе по отчету числится 8 метров. То есть кабель длиной 8 м продать невозможно, т.к. по факту имеется 2 обрезка разной длины. И узнать из отчетов мы это никак не можем.

Что касается серийных номеров, то реализация данного функционала в наших планах на этот год.

Что мешает вести учет в упаковках?

Только коэффициент относительно полной упаковки будет 0,2 для светодиодной ленты и 0,003278689 для бухты UTP кабеля.

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

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

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

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

2. ... единицы измерения?

3. ... адрес места хранения?

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

Это очень упростило бы внутреннюю структуризацию и учет при больших объемах номенклатуры.

5. Почему в заказ покупателя нельзя осуществлять подбор по коду и артикулу?

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

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

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

7. Почему нет свойства "Описание" у продукта?

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

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

8. Крайне желательно иметь предварительный просмотр фото не внутри товара, а прямо в каталоге...

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

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

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

Исправляйте эти косяки как можно быстрее...

Те, что я описал с 1 по 5 вообще решаются за 1-2 дня неспешного ковыряния в коде.

С 6 по 8 - работы на пару недель максимум.

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

Я же как то умудряюсь производить и риализовывать!!!

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

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

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

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

Алексей - ооочень не рекомендую в этом случае идти от закупки!

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

А закупку делать от производства, но никак не наоборот. Имхо.

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

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

Здравствуйте, Рита.

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