Укрсклад. Нужно решение:торговля "кусковым"товаром. оптимальный учет остатков

[olexander1989]

Ситуация следующая:
Допустим торговля идет тканью, кабелем или  другим товаром, что при продаже "режется".
По приходной накладной я получил 3 позиции  товара по 100м. каждая.
по 100м, я вряд ли продам - записываю как 100 единиц по 1м.
итого у меня на остатке 300м.
Но допустим я продал 60м. от первого , второго и третьего куска.
300-60*3=120м.
Приходит клиент и говорит, дай цельный кусок 80м.
На остатке есть. а в жизни только 3 по 40.
Как грамотно учитывать движение товара в таком случае?
...
Если реализации в программе нет.
Кто может взяться?

[TheOK]

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

[Valerikkon]

Я бы поступил следующим образом:
после названия артикула и цвета ткани указывал номер рулона
бла-бла-бла-1
бла-бла-бла-2
потом делал расход от соответствующего рулона.
Гемморой еще тот, но зато реально можно увидеть сколько в каком рулоне осталось.
Ну и следить при приходе каким номером обзывать.

Удачи.

[TheOK]

Поверьте, на предприятии, которое занимается производством, предложенный вариант только добавит проблем. Если предприятие занимается продажей "кускового" материала то даже ведение в MS Excel было бы куда проще чем мучатся таким образом. А на предприятии, которое занимается производством, много делается через автоматическую выписку производства или ручную (что так же бывает). Но чаще о том, какая, допустим, ткань задействована в изготовлении товара знает только один человек, который комплектует данный товар как тип комплекта "производство".
Способов "извращаться" с ведением подобного рода товара очень много... но не думаю, что они стоят того, чтобы о них здесь писать, в любом случае все сведется к "ручному" способу учета.

[Yurakha]

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

А че тут сложного ?
У нас тоже есть такой товар , приходуется товар "побухтово" или "порулонно" , в поле примечание можно написать изначальное количество метров в бухте , рулоне. Создаются группы одинакового кабеля или ткани. Таким образом имеем много групп , а в них подгрупп. Потом человек , который формирует комплект , выписывает сколько и какой конкретно ткани ему нужно для производства и передает на склад. Кладовщик все отрезает соответственно накладной и т.д. Никакой путаницы и получается нормальный учет. Да это непросто , человеческий фактор ... - возникает пересорт , иногда в бухте или рулоне больше/меньше , чем изначально заявлено , для этого помогает внесение остатков или списание. Просто нужно приучить людей к культуре производства и все будет ок. На мой взгляд вручную это делать намного ненадежнее и дольше.
У нас например в основном товар , который находится в упаковках , но может продаваться как упаковками , так и не кратно упаковок , кроме того оди и тот же товар может отличаться по году выпуска , производителю и еще по многим прочим параметрам
в том числе и разной нормой упаковки , это еще хуже , чем кусковой. Тем не менее имеем огромное количество групп , подгрупп , придумали свою сортировку , короче справляемся , и программа в этом очень помогает.
Вот поэтому я и пристаю к admin , с группировкой товара в документах. У нас есть товар (один и тот-же) , который занесен в базу по несколько записей , доходит до двадцати , например несколько начатых упаковок с остатком -  55 , 152 , 315 шт.... , а клиенту нужно 1000шт. Если выписывать несколькими строчками , то и в документах эти строчки повторяются , причем совершенно одинаковые записи и по одной продажной цене. Приходится для каждой такой группы товара иметь одну запись товара "фантома" с таким же названием , который выписывается для документов одной строкой , его количество в базе постоянно в минусе , зато имеем одну запись в документе 1000шт. Потом реальные количества перемещаем на другой склад , а потом из этого склада формируем фиктивные накладные , которые участвуют в отчетах. Ну в общем тихий ужас  , а вы говорите "извращаться". Так что все познается в сравнении. Ну счета и расходные накладные уже победили с помощью admin , надеюсь он еще посодействует с налоговой , то можно сказать огромный кусок глупой работы отпадет.  
P.S. Да , забыл написать - для склада , шаблон накладных содержит колонки , в которых вся доп. информация о товаре , группе , подгруппе , чтобы было видно конкретно от каких бухт или рулонов нужно отрезать. А для клиента выдается обычная накладная , где эта вся внутренняя информация скрыта.            

[TheOK]

У нас например в основном товар , который находится в упаковках , но может продаваться как упаковками , так и не кратно упаковок , кроме того оди и тот же товар может отличаться по году выпуска , производителю и еще по многим прочим параметрам
в том числе и разной нормой упаковки , это еще хуже , чем кусковой. Тем не менее имеем огромное количество групп , подгрупп , придумали свою сортировку , короче справляемся , и программа в этом очень помогает.
Вот поэтому я и пристаю к admin , с группировкой товара в документах. У нас есть товар (один и тот-же) , который занесен в базу по несколько записей , доходит до двадцати , например несколько начатых упаковок с остатком -  55 , 152 , 315 шт.... , а клиенту нужно 1000шт....

То, о чем вы говорите, называется перепаковка товара, если я вас правильно понял. Очень вам сочувствую в связи с тем, что вы мучаетесь подобным образом. В некоторых программных продуктах такая функция присутствует... Вам же, возможно стоило бы заменить все ваши "извращения" (не побоюсь этого слова, т.к. оно очень хорошо отображает весь процесс, который вам приходится проходить) на создание новой позиции товара например "Упаковка погремушек 1000 шт" и сделать документ на производство данного товара (в него, легко добавятся весь одинаковый товар, который вы разбили на части). Или использовать тип комплекта: комплект. Но, думаю, что это отдельная тема.
То, что вы предлагаете, можно сказать, и есть ручное ведение(ручное, не значит писать ручками или карандашем) учета товара (с б`ольшим успехом можно вести кол-во остатков в одном документе Excel, где указаны куски существующего товара и № приходных накладных+порядковый номер в накладной для однозначной идентификации, например, рулона, на который предварительно необходимо наклеить стикер с вышеуказанными данными). Никакой автоматизации. Я мог бы описать насколько это неудобно (подозреваю, что позже придется, т.к. уверен что ниже, кто -то заявит, что это делать очень просто). Но в любом случае, т.к. программа не поддерживает учет кускового материала (это, думаю, тот же партионный учет товара, где помимо цены, срока хранения и др. учитывается еще и метраж (кол-во)), сложно прийти решению, которое можно будет назвать оптимальным.
На ваши слова "А что тут сложного?", отвечу:
ничего сложного нету, просто очень долго+ увеличивается кол-во ошибок в учете товара.
З.Ы. Возможно я не прав, критикуя способ Yurakha, т.к. он предложил способ ведения кускового материала, что вполне соответствует теме поста, если он кому-то подойдет, хорошо. Но на моем предприятии он не подходит.

[Yurakha]

Во-первых , я совсем не считаю ваш пост критикой , это нормальное обсуждение.
То что мы сейчас занимаемся извращением , это да , есть такой момент. Но если решить до конца вопрос с группировкой "одинакового" товара в документах , то это будет огромный шаг вперед и практически нормальная работа.
Я понимаю , что ручное ведение не значит с бумагой и ручкой , но на мой взгляд имея такой мощный интегрированный инструмент , как Укрсклад , вести доп. учет еще и в Ехсеl , совсем не выход из положения.
У нас только торговля , это конечно проще чем производство , но с точки зрения автоматизации рабочего места и учета - разница небольшая. Я например не знаю как в других программных продуктах это может быть реализовано ,
может просто не сталкивался и поэтому не могу понять самого построения такого учета в части касающейся кусочного или погонного или как у нас товара в упаковках. Если вы знаете подскажите , даже интересно.
Может можно назвать нашу деятельность и перепаковкой , об этом никогда не задумывался. Мы покупаем товар у поставщика , который отпускает , только от упаковки. Например если определенный вид "погремушек" у поставщика поставляется упаковкой по 1000шт , а на следующий месяц эти же погремушки могут быть фасованы по 1500шт. , то мы так и покупаем и приходуем отдельной записью в базе , хотя это один и тот же товар. А продаем оптом и мелким оптом , т.е. не кратно упаковок , например покупателю нужно 1200шт. Как в таком случае правильно вести учет и все остальное имея Укрсклад с его нынешними возможностями ?
Я ранее неоднократно упоминал , что мы раньше пользовались программой устаревшей , написаной под DOS , эту прогу писал нам один человек под наши требования и там как раз группировка в документах была и особого дискомфорта мы не ощущали при такой организации учета. Но время не стоит на месте и пришлось искать альтернативу. Лучшим вариантом по многим причинам был выбран Укрсклад.  
 

[Al]

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

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

[Yurakha]

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

[Al]

Нет, я не про группировку. Я вчера пока лазил по форуму и видел как минимум два готовых решения, если склероз не изменяет то со счетом и с накладной. В печатной форме группировка делается довольно просто, я в курсе.

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

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