Добрый день!

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

(0) а цель какая?

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

шо опять ?

(0) а чё не в ЗиУПе ?

(2) угораешь? ))))

(5) нормальная таска. почему нет то?

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

Ордерный ячеистый склад в бухгалтерии
а так-то да бушка все стерпит

(8) по ссылке 404 Не Найдено

(9) конец ссылки поправь

(9) потому, что ссылка криво вставлена
Ордерный ячеистый склад в бухгалтерии

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

(12) Все реально, только не всегда это оптимальный путь. В расширении можно много, что нагородить, и свой учет по ячейкам и перемещения по ним и т.д.

(13) так это параллельный учет будет со своими документами и отчетами, тогда уж УТ ставить

(14) или акселот какой-нить

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

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

(16) (17) а если на забалансовом счете учитывать, обработку проведения дописать к приходным и расходным документам, в документах доп.реквизит "Место хранения", и смотреть по ОСВ ?

(17) справочно то примерно понятно как сделать

(19) главная проблема - это в документе указывать вместо

шайба - 30 кг 300 руб


а тут придется
шайба - 0.96 кг ххх руб
шайба - 2.04 кг ххх руб


как ты думаешь бухгалтер будет доволен?

(12) какая проблема? Нормально всё работает. Если по бумаге работать - да, будет чуток неудобно. Если мп/мк для ТСД запилить - покроет 80-90% ваших проблем с адресным складом, Коль вас устраивает 1сБух

(7) у вас несколько реальных Физических складов, разделённых удалённо?
Проблем вообщем тоже нет со справочным, даже если несколько, складов

(0) Забалансовый счет и развлекайтесь как хотите.

(22) да несколько складов удаленных

(23) т.е реально на забалансовом ?

(23) весь учёт скорее всего у ТС ведут бухи. При оргштатной структуре и обязанностям без изменений ничего они кроме простейшего справочного хранения не потянут. А оно, скорее всего закроет их основные потребности.
.
Если нужно что-то более серьёзное исключительно для склада то проще бух+WMS какую-нить простейший стандартный проект

(25) нахрена? Что вам не будет хватать при справочном хранении?
Количественный учёт имеет смысл если на складе постоянно бегают больше 3человек. Да и то, смотреть надо...

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

(28) Помимо поступления, нужно ведь и перемещать товар по местам хранения и списывать с мест хранения.

(29) обработка расхождений, излишки-недостачи, годовые инвентаризации..))

(29) + доработать складские документы, перемещение, списание, оприходование

хорошо бы автору описать суть происходящего в конторе, что мы тут гадаем?

(31) а раз это у вас бух, то желательно все это дело в расширении сделать, так как обновлять часто придется типовую.

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

(33) расширение на любителя, предпочитаю новые объекты в основную конфу добавлять

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

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

(36) на складах что лежит? штуки, килограммы, метры? как на складах учет ведется, руками?

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

(39) если только не чуланы со швабрами

(39) (40) Смотря что называть складом) Может там просто несколько комнат офисных, а может ангар многоуровневый в несколько гектар)

(41) ну и говорю, что залу конкретика нужна, чтобы что то дельное подстказат, так сказат)

вот что не удобно в типовой бух, так это то что характеристик не хватает, можно наверное было характеристиками обойтись

(41)  склад не большой, а вообще я сам не видел, подробностей сколько кв.м. и др. не знаю

(44) пятнично)

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

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

(46) согласен, нужна доп. информация

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

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

(36) остатки по вкладам у вас штатно в бухии. А на какой полке - хватит справочного хранения.

(30) это все и при справочном хранении работает.

(44) понятно. Куроводству всралось в одно место сделать "красиво"?

(52) В справочном, это типа в номенклатуре хранить адрес ячейки?

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

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

А еще есть темы по мультисборке и т.д. Тоже неизвестно, насколько это нужно будет ТС.

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

(58) какие виртуальные? В них будут виртуальный товар? Виртуальные только ячейки расхождений обычно. А всё остальное - реальное. В т. Ч. И ячейки отгрузки и приемки. А возврат - это та же приёмка с доп контролем при необходимомти

А так как выше написали - пофиг всё что здесь понаписали. Пока конкретики не будет. А с учётом что у ТС опыта по складу практически ноль - он и вопросы от заказчика не вытянет правильные.
.
Скорее в его на повестке дня всего две проблемы у заказчика
- ускорить сборку
- знать что где лежит

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

(60) ... Обычно с этого начинается. Ну и заказчик начинает строить дальше проекты по собору Парижской Богоматери с бюджетом на шалашиа Разливе.

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

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

(63) ну да, я и имел в виду безразмерные ячейки)

(63) (64) Только вот как это учитывать при справочном ведении адресного хранения?

(66) хз. надо смотреть что заказчику надо.
в справочном хранении не имеет смысла делать сложно. по сути ячейки приемки, отгрузки и аналогичное - транзитные, товар в них долго не находится, надо ли учитывать товар в них именно как месторасположения товара, потом придется усложнять концепцию движения/перемещения по этим транзитным ячейкам.... Справочное хранение имеет смысл организовывать только ДЛЯ ХРАНЕНИЯ. А учет и обработку в транзитных зонах/ячейках - тут смотреть по реальным потребностям "проэкта".
.
как выше написали в самом простом варианте я бы вообще никакого движения/перемещения по ячейкам при справочном хранении не регистрировал вообще. Достаточно просто фиксировать где товар находится, куда положили/откуда взяли. Куда положили/отуда взяли - это почти всегда для разборок косяков по сотрудникам. У себя вел простой лог типа "Иванов из ячейки А1 взял товар Т2", "Сидоров разместил Товар5 в ячейку Б8". Необходимость в анализе таких логов у меня была практически нулевая за 5 лет работы со справочным хранением. И делал я такое логгирование скорее "шоб було"... ;-) на всякий случай, опыт показал - что не пригодилось практически.

и я бы не делал в карточке товара реквизит "Ячейка". сделал бы это отдельным РС или справочником (как правильнее в снеговике), типа
ячейка-товар-датаВремя-Сотрудник
ДатаВремя - последнее когда сотрудник делал с ячейкой что-либо. Сотрудник - кто последний обращался в ячейку.
датавремя и сотрудник - "шоб було", не сильно думал...

мне когда делал справочное хранение в клюшках - хватило 2 справочника и куча обработок.
на ИС описывал.
ТС может посмотреть, вдруг что полезное почерпнет https://infostart.ru/1c/articles/338893/

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

У нас бухгалтер не то что WMS, номенклатуру не желала видеть в полном ассортименте у себя в конфе. Подавай ей только 2 товара - Товар с 10% ставкой и с 20. Пришлось т.н. промежуточную БП рисовать, которую бы смотрел кто угодно, но не она.

(71) там для менеджеров в основном.

(72) Экономист базу сопровождала.

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

Это всё называется одним выражением: "Бизнес по-русски", когда один очень известный ритейлер в нашем городке придумал как ему оптимизировать расходы на документообороте и переключил свои хотелки из EDI в ЭДО. Я случайно заглянул в один из его Гипер-, Мега- Сараев в это время - полки были уставлены туалетной бумагой, хлеба не купить. Народ метался в недоумении.

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

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

(77) Тема известная. Обычно по такому сценарию события и разворачиваюся. Тут просто вовремя должно было быть принято волевое решение с вытекающими последствиями.

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

(78) пока обновляется норм. а вот если выйдет новая редакция, как это было с переходом с 2.0 на 3.0, вот это будет по сложнее.

(77) бухам ваши ячейки нахер не сдались. Поэтому если с ячейамити кто и будет работать - то только склад.
можно и в карточку товара ячеку занести. только сразу подумать что будет если товар в нескольких ячейках лежит и надо отделять ячейки отбора и ячейки резервного хранения. И как несколько ячеек хранить. Типа ",а1,б2,в3," и потом во всяких отчетах и обработках парсить туда обратно.
.
адресное хранение вполне можно в бухию встроить. только не надо его мешать в бух.контур. сделать практически отдельной подсистемой и все...

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

+ нужно простое решения для начала, а дальше видно будет

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

хотя как отсосеру - пофиг. сказали сделать - сделал. а что и как - да и пофиг...

отсосер = аутсорсер
чтобы без этого всякого...

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

(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) да нормально у ТС будет.
Но если у ТС кск у слуги народа:
- пи..Ят и пИ..ят!
То тогда попкорном точно надо запасаться.