УНФ: партионный учет #715228

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

Партионный учет необходим для контроля за себестоимостью. люди умудряются проводить доки так, что себестоимость списания -600р, к примеру, ну или отрицательный остаток. Ну или купленное за 3,5 продать за 3,2. Планирую смотреть по партии входящие затраты и сравнивать со стоимостью списания (такой вот отчет об ошибках). Ошибочно проведенные доки перепроводятся.

1. Подбор и Партии в УНФ. Разработчики обещали в будущем прикрутить выбор партий в подборе. 2. Партионный учет в УНФ. Текущий партионный учет в УНФ не завязан на документы поступлений, как это было, например, в УТ 10.3. По-этому тут поле для рассуждений большое и что лучше/хуже сказать однозначно нельзя. Тем более стоит учесть, что собственно и  сам метод списания по FIFO в УНФ отличается от УТ 10.3, а расчет себестоимости тем более - см. РАУЗ и решение линейных уравнений. Подробнее читай профильную литературу. PS Если не правильно понял вопрос - сорри...

+2 из справки по УНФ "ВАЖНО! Партия номенклатуры не является аналогом документа оприходования запасов и не используется для определения стоимости списания товарно-материальных запасов методом FIFO."

Там партии больше используются при комиссионной торговле, для определения владельца партий. Так же типовые партии партии УНФ можно использовать, например, для серийных номеров. То есть в общем и целом, если грубо и на пальцах: партии в УНФ это дополнительный разрез аналитики и он не похож на УТ 10.3 и более раннее представление о партиях. PS Хорошо это или плохо не обсуждается.

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

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

Я не могу сказать правильно/неправильно, так как это вы можете узнать только по результатам написания, но думаю, что писать свой контур FIFO не совсем правильно (у меня такого опыта нет). Дать какой-то совет можно только после ВНИМАТЕЛЬНОГО изучения потребностей пользователя, возможно при текущей реализации можно решить все задачи пользователей. Почему так важно видеть себестоимость по документу поступления, разве не достаточно видеть рентабельность за период в целом? Посмотрите, может вам будет достаточно смотреть результаты по заказу - заказ в УНФ проходит как аналитика по регистрам учета себестоимости.

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

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

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

А понял не новую базу делаете а старую меняете. Так аналогично перенос в новую базу с заменой номенклатуры ну или в текущей сделайте замену.

Т.е. сначала проход по документам прихода и создаете на каждую номенклатуру новую подчиненную старой (да новая не по документу а по позиции в документе прихода) Т.е. партии это не документ а строка документа поступления. Бывает же что один товар приходит двумя строками в одном доке и по разной цене ))

УНФ. Красота форм. Совершенство функций. ))

+ Потом по документам расхода проход и меняете старую номенклатуру на новую подчиненную старой Только смотреть чтобы дата прихода была раньше даты расхода и главное товар был на остатках ))

Перепроведение задним числом отключается закрытием периода. >> Были правильно перепроведены... Что у вас является критерием: Правильно перепроведен документ/неправильно перепроведен документ? PS Начинаю убеждаться, что проблема не в партиях, а в учете. Не трогайте себестоимость (и новые реквизиты), потому что, например, документ "Закрытия месяца" (кстате, а они его делали?) может понять только избранный. Там алгоритм тяжелый на столько, шо все по окопам :)

Гурман! Но 1.5 в такси красивая :)

"Ну или купленное за 3,5 продать за 3,2." Проблема решается отнюдь не введением партионного учета - а контролем отпускных цен. Отпускные цены определятся не закупочными - а ситуацией на рынке. Глубоко убежден в том, что стремление "продавать строго с наценкой 20%" чревато 1. лишними сложностями в ценообразовании 2. упущенной прибылью и потерянными продажами. Ситуация №1. - Закупили сильно дешевле чем обычно. Если придерживаться стандартного процента наценки упускаем прибыль, ведь могли бы продать гораздо дороже!!! Ситуация №2. - Закупили дороже чем обычно. Если наценить стандартный процент цена продажи может оказаться неконкурентно способной по рынку и в результате мы вообще можем ничего не продать. Продавать все равно придется по рыночной цене, даже если это будет себе в убыток.

P.S. Использование "Управление небольшой фирмой" в "Крупной торговой компании" чревато большими сложностями в работе. Лучше переводите их на "Управление Торговлей"

Партионный учет не нужен. Какой функционал вы не смогли получить от контрольного примера на типовой конфигурации на этапе моделирования?

"Какой функционал вы не смогли получить от контрольного примера на типовой конфигурации на этапе моделирования?" Э... это Вы на каком языке и кому сказали? :)

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

с ценой именно так и решили. что устанавливается оптовая, и нельзя продавать ниже оптовой цены - - пять бухгалтеров, пять менеджеров, юрист, директор, зам.директора и куча народа на 5 крупных складах, с каждого проводится отгрузка. около 300-700 накладных в неделю. обороты миллионные. не решена проблема со стоимостью списания. после работы задним числом не перепроводят документы, и когда вручную проводишь документ, видно, что то, что списалось на 1000р, теперь списывается на 950р, потому что исправлена приходная накладная, или проведение другого документа отменили (раньше по времени который)

300-700 накладных в неделю и Небольшая Фирма ? )) Может все же лучше УТ? Причем 10.3 а не 11

нужно сделать отчет, где будет видно а)отрицательное количество - делается настройкой стандартного отчета отбором количество (кон.ост) < 0 б)отрицательная сумма - делается аналогично в)стоимость списания не равна стоимости прихода и сильно отличается - вот для этой задачи думаю добавит партию-документ

то есть по партии смотрю входящие затраты, рассчитываю примерную стоимость списания 1 шт

затем рассматриваю каждый расход по партии и считаю отклонение

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

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

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

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

выправим - и будет им счастье

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

недавно исправили

В УНФ нет такого понятия как последовательность документов. Контроль остатков тоже считается на актуальную дату, а не на момент документа. По сути себестоимость в сценарии до закрытия месяца и после - будет гарантировано меняться. PS Автоматизация хаоса - ведет к автоматизированному хаосу.

+100

мы пытаемся сначала выправить хаос, а потом автоматизировать

а так с - не спорю

параллельно с внедрением внутри компаний часто решаются проблемы

Пытались сделать запрет изменений задним числом? И как результат? Это же очень просто вставить условие если не новый то не проводить/отменять проведение и все ))

решение подбирали не мы, а какой-то франч до нас Вот за что я люблю продажных мененжеров из франчайзи :) Этим главное впарить. Имхо, УНФ имеет смысл только для небольшого ПРОИЗВОДСТВА, а для торговли ЛЮБОГО РАЗМЕРА она слабо приспособлена. Поди у них как раз проходила акция - кто из франчей продаст больше всех УНФок - тот получит iPad :)

Реальный случай. Наши менеджеры победили - в результате я имел богатый опыт внедрения УНФ :)

В УНФ не надо не чего вставлять. Там есть дата запрета редактирования (вообще подсистема БСП). + Есть настройка при закрытии месяца двигать дату автоматически. Считается, что после ЗМ данные окончательно рассчитаны и подтверждены (кажется называется - консистентны). Сложности: - в старых версиях УНФ в заказе в закрытом периоде недоступно изменение статусов - война с менегарами, потому что им очень нужно ходить в старый период (объяснения любые) - бухгалтера будут на стороне разрабов PS Может еще чего - даже не знаю.

накладная на товар приходит вовремя, а вот доп.расходы приходят поздно. запрет стоит (типовыми средствами в настройках прав пользователя выставили). допустим, 01/07 пришел товар. завели накладную. 05/07 половину отгрузили покупателю. 10/07 другую половину отгрузили на другой склад. 20/07 пришли документы от транспортной компании. затраты на перевозку садятся на другой товар, а по сути относятся к товару, поступившему 01/07.

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

поэтому прежде чем что-то продать, они спросят у тех, кому все это внедрять

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

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

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

надеюсь партиями решить этот момент