Добрый день!

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

(87) менеджеры? ;-)

(88) менеджеры

а откуда менеджеры знают что на складе делается?

(90) ну можно по разному назвать, кладовщик или менеджер по закупкам, или просто менеджер

(91) прикольно...

у вас там склад - что ли кладовка на 40 квадратов?

(93) не знаю еще пока, знаю что пока справочно нужно видеть товар, где на какой полке

(94) да, исчерпывающее задание.
предложи им фоткать полку и прикреплять к карточке. точно как в задании "видеть товар где на какой полке".

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

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

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

(98) Тебе, конечно, решать. Желательно сразу иметь чёткое ТЗ, чтобы потом не было... Сейчас - как в сказке - Принеси то, не знамо что... дальше по тексту. Если клиент готов платить за своё же незнание, чего он в итоге хочет, то флаг тебе в руки - ты на коне.

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

(99) а что потом? просто понадобится доп. функционал за отдельную плату. так что все норм.

(0) Адресное хранение разным может быть. Давным давно сделал реквизит в справочнике и одну- две печатные формы поправил/дописал.Клиент доволен, больше ничего не потребовалось.Вот такой примитив может быть. А для полноценного учета нужна УТ.
(100) Нафиг не нужно, только запутаешь все.Лучше разберись, как по нескольким складам вести учёт адресный собираешься.

(100) Не вкурсе. Есть нерекомендуемые вендором решения типа Хранилища значения. И есть какое-то решение с типом значения Список значений на форме.

(102) Согласен по поводу (100). Чем неочевидней будет решение, тем больше тебя ждёт заморочек в будущем. Сам же потом будешь плеваться.

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

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

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

(107) можно и так

(105) В документах указывать ячейку бухгалтеру предложишь?Проклянут тебя)

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

(109) всю ветку не читал? буху это и не нужно. и речь не о печатных формах, а об экранных, например в ТЧ товары после номенклатуры добавить поле ячейка.

(108) Ну и ещё одну табл. часть с Ячейками, в которой будет реквизит Склада из Таб. части Склады.

+ печатная форма только для сборки нужна будет на складе

(112) да так наверно и сделаю

(111) Ну то есть для чтения, тогда норм.Но смотреть это скоро надоест. А печатная форма - это и есть то что просят обычно.

(115) ну так менеджерам нужно будет смотреть в т.ч. и в документах

(112) наверно все таки не ТЧ, а отдельными реквизитами сделаю, в отчеты и в документы из ТЧ типовыми средствами дополнительно поле не вытащить.

(101) это тебе так кажется.
если сразу не закладывать что справочное хранение дальше будет развиваться в полноценное - то потом переделать придётся ВСЁ. но это нестрашно. вполне возможно что со справочного самописного хранения Заказчик потом перепрыгнет на нормальную систему.

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

(106) у меня 50-50, и большие склады в проектах и в качестве хобби - всякие лавочники от 100 квадратов... примерно как у ТС.
просто у меня есть понимание - так как походил полностью всю цепочку ручками от самопалок до промышленной ситсемы. что имеет смысл делать, а что нет. и что все эти самописки - это просто адские велосипеды, которые имеет смысл делать только для лавочников, которые сегодня склад для озона, завтра шапки в ТЦ.

(118) тебе в (106) подсказали что это не тот случай. тут все проще. если нужно будет полноценное решение, то думаю нужно смотреть в сторону УТ.

(106) ясен пень, понятно. сам таких лепил вагон.
не надо в счете нихера указывать.
справочное хранение, РС типа склад-ячейка-товар.
и одна печатная форма ячейка-товар. Она же для размещения товара, она же для сборки товара.
в шапке печатной формы (поступление такойето, отгрузка такаято, всё).

(111) "а об экранных, например в ТЧ товары после номенклатуры добавить поле ячейка."
и нахера это нужно? да еще курочить типовую конфигу..
дополнительная команда на форму. по команде - открыть форму товар-шже сейчас лежит.
.
ТС, стукайся в скайп Zlopun.
даже покажу как это тупо работает.

(122) я по другому вижу, ячейка в карточке товара, + печ.форма на сборку из счета или реализации с этой ячейкой в ТЧ

(122) Ну вот и очередной велосипед для ТС обсудили)Можно расходиться, выходные же.

(112) имхо совершенно излишество. нафиг не надо. то есть вообще.
все простые потребности покрываются обычной формой Ячейка-Товар какой в ней лежит СЕЙЧАС.

(124) нахрена эта ячейка в ТЧ документа?

(123) там типовой настройкой формы, по кнопке еще - изменить форму и добавить этот реквизит

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

то что написано в ТЧ документа упомянуты ячейки = это тупо история. в простом варианте это нафиг не надо. Потому что через 5 минут на складе будет уже совсем другая история.

(129) если не указали - да и похер.
поступление. распчеатл "лист размещения" где указано (из РС) текущая раскладка товаров по ячейкам из поступления.
отдал бегунку. разложил товар по указанным ячейкам. если расклад отличается от распечатанного (ячейка заполнена ил итд) - внес ручкой пометку в лист размещения в какую ячейку положил товар.
Лист положил на стол оператору.
Оператор взял лист - открыл форму текущего положения товаров. Пробежался по листу, внес в форме изменения по факту.
все.
лист положил в архив/выкинул.
.
отгрузка.
распечатала тот же самы лист, только озаглавил его "лист сборки".
отдал на склад.
сборщиек прошел, собрал товар по ячейкам. если ячейка пустая/товара в ячейке - нет - отметил в листеюю
положил лист опеарторпу.
оператор внес изменения СОВЕРШЕННО Аналогично в форму текущего размещения товаров.
все.

(130) так заполняться будет не в ТЧ, а в самой карточке, в ТЧ только справочно

ладно пора наверно заканчивать

выходные все таки

(134) что, страшно?

(135) да нет, информацию получил, для начала. дальше видно будет

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

в саму карточку ТС видимо хочет запихнутьтолько исходя из легкости добавления в ТЧ документа.
это неправильная хрень. завтра понадобится к товару в ячейку впихнуть срок годноти, партию или еще что будет (_._).
а чтобы справочно показать - хватит отдельной формы "из РС", на развитие - это гораздо более кузявый вариант.
.

(138) это простое и удобное решение, на развитие есть варианты, допилить или перейти на УТ

будешь лист печатать - не делай как 1С. как дятел. делай чтобы складу было удобно.
условно: первая колонка = ЯЧЕЙКА, вторая колонка = КОЛИЧЕСТВО (сколько взять в отбор), третья колонка - АРТИКУЛ, четвертая колонка - ТОВАР, длина названий - разная. А то привыкли по типу "Товар-Количество-Ячейка". пока глазом доедешь до показателя количество/ячейка - глаз нафиг съедет на другую строчку.
Делай так (как я выше описал) - чтобы идентфикация товара (артикул/наименование) было максимально близко к ячейке/количеству. Плюс при печати обязательно сделай черезстрочку легким подкрашиванием фона, визуально будет легче персоналу. Не мельчи. не надо печатать 8 шрифтом. печтатй так чтобы на листе А4 (в одну строку) помещалось где-то 35-40 строк, может даже меньше, сам подберешь по величине шрифта.
между первой и второй колонкой м.б. еще колонка 1а, где перечислены ВСЕ ячейки, в которых на момент печати листа числился товар. В перовой колонке - ячейка отбора (рабочая ячейка или первая из списка ячеек), в 1а ячейке - все (ячейки резерва, прочие ячейки где числится товар).

Смотри ТОЛЬКО в сторону регистров сведений. Вариант с карточкой товара даже не рассматривай. Это не правильно. Со всех сторон.

(0) Простейше адресное в БП:

1. Складам сделать иерархию элементов и завести подчиненные склады-ячейки.
Можно даже комната-стеллаж-секция-ячейка или еще как
2. Доп.сведение у Номенклатуры - Основная ячейка для размещения
3. Разные автозаполнения для удобства

https://events.webinar.ru/KORUSlogistics/1527673226?utm_source=tg-logistved&utm_medium=post&utm_campaign=web-26.01

Какие люди и без охраны?

Жаль никто так и не спросил - сколько СКЮ на складе. Какая точность адресации нужна. И какой запрос у бизнеса - знать где или где и сколько.

Заведите каждую ячейку отдельным виртуальным складом и извращайтесь ) При поступление товара - поступление + распределение по ячейкам. При реализации - сборка с ячеек на один склад + реализация. Перемещение между ячейками - обычное перемещение. И доработок не надо )

(145) А это не имеет значения для неавтоматического примитивного адресного склада.И детализация ячеек выбирается из требования помещения , то есть по месту.
(146) Ну да ,добавить ещё велосипедов и треша БП))Жги ))Так сейчас дойдёте до изменения плана счетов и забалансового учёта в ячейках.

(147)Как раз вообще ничего не надо менять.

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

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

+ это по одному реальному складу, а их будет несколько.

Самое главное при написании велосипеда - не превратить его в тачку с квадратными колёсами )

(150) ну, если в день отгружается строк 10 товара... то количество ячеек-полок по барабану.
.
а так, конечно, вручную с большим товарооборотом (не с количеством ячеек!) тяжко работать.

бухия делает счет/заявку.
сосем потребность на отгрузку в ТСД.
проходим с ТСД по ячейкам, жмакаем ячейки-количества, автогенерится перемещение/иное по соотв.складу-ячейке.
профит ;-)

(152) ну, тут все проще. не нам ее толкать ;-)
у ТС главное заблуждение что это можносделать удаленно. Можно. Но непросто. Это не 2+2 сложить. Это надо пинать всех адскими люлями чтобы делали то, что должны делать. а им - менеджерам )они там на складе оказываеься что-то делать будут ;-) - это все до одного места.

Нигде не написано сколько будет стеллажей, полок и ячеек. А если не по 10, а по 3 ? Если люди в бухгалтерии ведут бизнес, то можно предположить, что он весьма несложный и неогромный. Эти стеллажи, полки и ячейки все равно придется как то заводить, сущность никуда не денется.  Проблема не в том, что складов будет много, а том, что это будет кастрированный учет. Но вряд ли полноценное ячеистое хранение стоит вообще делать в БП. А так то на свете много чего существует. Есть люди, которые под каждый приход новую карточку товара заводят, реализуя тем самым свой партионный учет ) И отказываться от этого не хотят
А 2 склада по 10*10*5 - это всего лишь 1000 виртуальных складов ) сущий пустяк ) Организуйте их в иерархию и чем хуже стеллажей и полок ?))

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

(155) Так и нигде и не написано, что хотят знать сколько товара в каждой ячейке лежит, пусть там даже 3 ячейки на 3 полках.Нет такой задачи у ТС.Зачем же тогда такое загромождение?

(157 в чем загромождение?) если не знать где что лежит, тогда что это за ячеистое хранение ? - и наконец, Вы то что предлагаете ?

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

(158) В (102) я описал работающий пример адресного хранения.Где то за полчаса сработано.Еше на 7.7.До сих пор работают и ничего им больше не надо.
Потому что если у вас один товар не хранится в сотне разбросанных по складу ячеек, сколько в ячейке товара - никому не нужно.Его столько, сколько товара на складе.

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

(147) В том то и дело что не понятно какой склад.
примитивный или нет.
  
Одно дело если у нас распределительный склад 10 000 м2 на 100 000 - 1 000 000 СКЮ.
Другое дело если у нас обычный склад сырья на котором всего 2 000 -3 000 СКЮ, но каждый новый грузчик/кладовщик (а там текучка иногда весьма высокая) собирает заявку на перемещение на производство по полдня - потому что ищет по складу каждое наименование по полчаса.
  
В первом случае - однозначно нужно городить ВМС, во втором случае - достаточно привязать к номенклатуре реквизит - адрес хранения и вывести его на печатные формы прихода ( что бы знать куда размещать) и расхода (что бы знать откуда брать).

По логике вещей - у ТС второй случай, но  предложений напилить УТ или ВМС на ветке более чем достаточно, и при этом никто даже не спрашивает о потребностях бизнеса.

З.Ы. И да устриц ел - ровно 2 года назад ко мне пришли с таким же вопросом и сметой на внедрение ВМС на складе сырья на 7 лямов. В итоге за 8 ч/ч им допилили карточку номенклатуры (добавили табличную часть что бы можно было указать для ходового сырья несколько адресов хранения) и вывели их через запятую в печатные формы прихода и расхода.
До сих пор все счастливы как слоны и про ВМС никто не вспоминает.

(162) да фиг его знает...
во многом еще зависит что ожидают получить собственники/руководители.
часто на небольшом складе (где вполне что-то из простого по этой ветке хватило бы или адресное УТ) ставят WMS в качестве пилотного проекта с прицелом на дальнейшее развитие или на "клонирование" на своих же других складах. часто на маленьких складах с небольшим персоналом все "в загоне", тупо просто некому заняться тривиальнейшим наведением порядка/выстраиванием процессов, ошиваются какие-то 1Сники-отсосеры, которым надо каждый чих разжевать что сделать и еще как рассказать на что тоже нет ресурса у заказчика - тогда руководители или кто-то из толкачей в фирме берут WMS, где тупо в рамках проекта исполнители по WMS наводят хотя бы какой-то порядок в базовом варианте (потому что иначе никак) и все счастливы. да еще варианты для небольших складов. Иногда откровенно удивляешься - зачем ЗДЕСЬ понадобился WMS? Делаеться проект и все счастливы - заказчик получил то что хочет, Исполнитель заработал денег.

А так - везде всё одинаково. Разброд и шатание. Болото.

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

(165)Где то роботов и в банках внедряют
А ячейка в карточке это уже совсем неинтересно. Если уж делать. то делать более менее приличное.

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

(0) Ты это читал? Ордерный ячеистый склад в бухгалтерии

(0) Для УПП делал на отдельном регистре, вовсех документа пришлось прописывать отражение по нему + контроль заполнения.

(168) -> (11)

(170) Если читал, в чем у тебя вопрос по существу. Задай его, я отвечу. Я делал такое, в той ссылке и указал.

(171) пока реквизитом "место хранения" в справочнике + пара ПФ на приемку и сборку

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

(173) Тогда на счете учета нужны еще сам ТМЦ, склад. Я от такого отказался, мне нужен был еще сам документ резерва, по которому оный ставится.

(174) можно сделать клон "41.01" третьим субконто сделать "Ячейку", сейчас резервы на виртуальных складах. т.е при перемещении на склад резерва можно тмц и ячейку тоже переместить

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

(167) "Это и есть понятие "справочно".
в моем понимании - это где товар лежит сейчас. сам факт наличия товара в ячейке. Без количества.

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

(178) "Нужны документы делающие движения по ячейкам"
не нужны. достаточно просто фиксации. это можно делать простой обработкой, где в ячейки добавлять/убирать товар. это можно и без регистра, как у ТС хочет - прямо в карточке товара. "Любое движение товара на складе должно отражать ячейку в этом случае." - зачем если история движения не нужна?

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

(175) Не завязывайся на БУ. Это вообще дорога не туда. Опять же во всех отношениях.

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

(181) опять же, это самое простое решение с минимумом доработок.

(183) так галактеко волнуетсо! сделал ты уже или нет? пищит ли от счастья заказчик? захотел ли вдруг еще чего?!

(184) сделал, потом отпишусь, нужно время по тестить

Как говорится, сюжет захватывающий, многосерийный. Не обижайся, но все заинтересанты - в предвкушении развязки. Поп-корна хватит на всех.

(186) да нормально у ТС будет.
Но если у ТС кск у слуги народа:
- пи..Ят и пИ..ят!
То тогда попкорном точно надо запасаться.