В данный момент имеется производственное предприятие на Бухгалтерии 7.7, которое планирует внедрить адресный склад. Большинство места на складе занимает готовая продукция. Что-то дописывать на семерочной бухгалтерии большого смысла не вижу, на проводках много не сделаешь. Или может быть я ошибаюсь? Как вариант использовать связку УТ11+Бухгалтерия 7.7, но там придется писать обмен, чтобы в бухгалтерии формировались выпуски продукции. Может быть кто-то посоветует относительно недорогую WSM у которой налажен обмен с Бухгалтерией 7.7 ?

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

10 пользователей, отгрузок не много, 5-10 в сутки.

есть возможность ставить Ут11 в КлСерверном варианте? если в отгрузке больше 100 наименований и нет возможности позволить себе клсерверный вариант то 11 загнется на тормозах, можно связку ТиС + ваша бп, можно новую или вашу БП+УТ10, если есть сервер то можно и БП+ут11,

Клиент-серверный вариант вряд ли возможен, но в УТ 10 и ТиСе нет адресного склада. Как вариант еще перейти на Бухгалтерию 8 и там писать что-то для адресного хранения. Либо использовать WMS не на 1С.

(4) данных мало!
можно вообще тупо прикрутить миниWMS прямо к бухгалтерии.
Все зависит от задач...
.
если нужно тупо ускорить сборку и формирование заказов - могу пристегнуть прямо к бухии ячеечный/адресный учет... - для э того ничего особо навороченного не надо..
.
поподробнее смотреть здесь:
http://forums.kuban.ru/showthread.php?t=1391917
.
на данный момент работает 15 складских ТСД, общий  объем - порядка 8000 ячеек.

(3) типовая ТиС с докуруткой по ссылке - свободно тянет кучу заказов в день, заказы по 300-500-700 строк - в порядке вещей...

(4) прежде чем думать про "автоматизацию склада" - напиши вСЕ ЗАДАЧИ КОТОРЫЕ НУЖНО "автоматизировать"

Все достаточно просто, глобальных задач нет. Приходит материал, система по определенным правил должна присваивать ему адрес и распечатать этикетку с этим адресом.  Возможны различные упаковки.Продукция крупногабаритная, в одной ячейке хранится только один вид продукции. ТСД на первом этапе использовать не планируется. При перемещении или реализации, система подбирает ячейки из каких нужно взять продукцию согласно фифо и распечатывает комплектовочную ведомость для грузчика. Еще ряд отчетов по движению товаров в ячейках и заполненности склада, но это уже частности.
Была бы ТИС, то и вопросов не было бы, там дописать не так сложно, но есть только бухгалтерия.

Посмотрел сейчас внимательнее УТ 11, использовать её только как WMS не эффективно, там складские операции только на основании заказов делаются. Возможно проще  стоит перейти на Бухгалтерию 8 и дописать её.

Либо связка Кортес+текущая Бухгалтерия 7.7. Кто-нибудь работает так?

(8) " Возможны различные упаковки.Продукция крупногабаритная, в одной ячейке хранится только один вид продукции. ТСД на первом этапе использовать не планируется. "
Думаю, эксель подойдет.

(11) Это вряд ли) Но даже если так, то задачу клиенту нужно решить на 1С) За эксель мне денег никто не заплатит))

Жаль что в УПП такого функционала нет конечно пока :,(

(2) Ну и на кой ляд Вам тогда адресный склад? Работал в торговой конторе - даже при остатках в 2,5 тыс. наименований кладовщиков не особо напрягало искать товар. Точнее была некая адресация для товарных групп, но не жесткая, а носящая справочный характер - типа напольная плитка Grespor в третьей секции на стеллажах с 5 по 7.

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

функционал по типу (15) прикручивается хоть к типовой бухии, хоть к типовой ТиС за 1-2 дня; у меня весь ячеечно-адресный учет - всего три справояника и порядка 8-и обработок для складских NCL/ вам из этого моего набора - вообще одной обработки хватит.. ;-)

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

(15) У продукции не будет постоянного места, количественный учет в разрезе ячеек нужен однозначно. Так же нужен, разрез по упаковкам. Клиент хочет видеть в каждый момент времени на каком адресе что находится и в какой упаковке.  Прикручивать это все на субконто, не очень то и хочется. Тем более аппетит растет во время еды, в будущем и ТСД планируются.

Я понимаю, что склад небольшой и теоретически это все возможно и не нужно. Но раз клиент хочет, не отговаривать же его.
Мне вот интересно, с Бухгалтерией 7.7 есть ли стандартные обмены у Кортеса или 1С Логистики. Или это вручную писать придется?

(19) Именно отговаривать. Это и есть профессиональный подход - соизмерять потребности и стоимость решения задачи. Срубить бабла можно и на других задачах.

(18) В чем проблемы с субконто? Нафигачил забалансовых счетов и новых субконто и всё. Народ получает знакомые механихмы отчетности, переучивать никого не надо, новых лицензий не надо.

(18) > количественный учет в разрезе ячеек нужен однозначно.
- для чего? обоснуй!
.
> так же нужен, разрез по упаковкам.
- для чего? обоснуй!
если вести учет по тарности - каких коробок сколько распаковано/упаковано - накуа???? а затраты - существенные!
у меня, например, штуки-блоки-мастеркоробки (типа как матрешка) - в разрезе упаковок не веду, ибо поифг. если в блоке у меня 12 шт, то при необходимости собрать в заявку 10 штук сборщику выгоднее открыть блок 12 штук и извлечь оттуда 2 штук. если блоков нет - набирает поштучно. - такого подхода вполне хвататет чтобы не вести учет упаковок. достаточно придерживаться простых  правил - на рабочем месте должно быть не более одной раскрытой мастеркоробки/блока. отсюда количество упаковок с высокой точностью получаем чисто арифметически безо всякого допучета.

> Клиент хочет видеть в каждый момент времени на каком адресе что находится
- количественный учет для этого не нужен.
даже есоли какая-то хреновина у вас куча штук по количеству - в 99% она лежит так: места хранения забиты под завязку, на месте отбора - штучно-коробочно. для того, чтобы посчитать соотв. факта учету - количественный учет вряд ли поможет. количественный учет нужен для предварительного планирования и подпитки тех ячеек/тмц, которые будут собираться в ближайшее время. при вашем потоке заявок 10-15 штук - это нафиг не нужно...

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

(24) читал что выше написано?
вполне достаточно иметь такую инфу: в ячейке А1 лежит товар Т1 - для этого никакого коучета не надо. достаточно регистрировать факт наличия в ячейке товара. - сходи по приведенной выше мной ссылке - посмотри на скриншоты - прочистится в мозгах ;-)

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

(24) у продукции совсем необязательно должно быть "конкретное место" - сегодня Т1 в ячейке А1, а вчера лежал в А15. главное что нужно СТРОГО ЗНАТЬ НА СЕЙЧАС в какой ячейке какой товар лежит - все - я джумаю, что на 9%% это покорет ваши потребности

> Постоянной фасовки нет
- а вот это весьма плохо... приведет к существенному усложнению схемы учета.
хотя, если правильно извернуться - то все решаемо. каждая "новая" фасовка - отдельный ШК.

(24) Итит твою... ты это на существующие счета хотел повесить? :-) И потом закрывать месяц и сдавать баланс в разрезе упаковок и ячеек? :-)))
Кароче, Склифасовский, пусть клиент на бумажке нарисует подробно, как он с этими ячейками работать будет. Все бизнес процессы в разрезе пользователей, документов и отчётов. Запрограммировать по такому техзаданию раз плюнуть. Дольше будете с клиентом техзадание составлять.

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

(30) Делать на периодических реквизитах? Да тебя за такой совет расстрелять мало.

(31) с такой больной фантазией только к доктору :)

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

(30) дату в кортеже исключить за ненадобностью.
на Складе никого не интересует что было вчера - это вам не бухия.
.
достаточно регистрировать Товар Т1 положили в ячейку А1
событие - достатчоно тупо писать в "файл" (справочник) лога, типа Дата-Время-Событие".
.
разбор полетов по нахождению товаров в ячейках - весьма редко, и при надобности - что куда кКОГДА ложили/клали - выдергиваем из протокола размещения.

(34) а как предполагаете реализовать ...нужно взять продукцию согласно фифо

(33) все зависит от частнойтей.
Товар размещается по такому алгоритму:
1. в первую очередь пихаем сколько влезет в "рабочую" ячейку товара (откуда отбор)
2. оставшееся - кида ем неполсрдедственно в чейку хранения над рабочей ячейкой товара
3. если над рабочей ячейкой товара нет свободных ячеек - кидаем в ближайшую свободную.
.
все.
такой алгоритм позволяет размещать товары безо всякого планирования и прочей мутотени.
.
но! все зависит от частнойтсей.

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

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

http://s017.radikal.ru/i401/1110/e4/28649d9d512b.jpg

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

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

http://s012.radikal.ru/i319/1111/d1/e04322dc3b1d.jpg

(41) это опять же частности - если складские площади не повзволяют lzk одного товара (разных сроков) выделять НЕСКОЛЬКО ЯЧЕЕК ОТБОРА - то систем  сразу немножко усложнится..

вот вам пожалуйста: ответ на вопрос: где лежит конкретный това?
http://s019.radikal.ru/i615/1203/4a/7acdc57c121d.png

у мну тупо сделано: жмакаешь сканером по ячейке - показывает какие товары числяться в ячейке; жмакаешь по товару - показывает в каких ячейках числится товар..

(40) Главная задача сделать складской учет максимально прозрачным. Как я понимаю, вариант, где не известно какое именно количество лежит в ячейке, клиента не устроит. Он видел текущую реализацию в нашей УПП и попросил сделать нечто похожее у него. Хотя нужно обговорить конечно. Спасибо, за информацию.

+к этому - отсутсвие количественного учета по ячейкам позволяет более "свободно" делать подбор товара - кончился товар в ячейке отбора - сборщик тупо может взять блок из ячейки хранения, которая находится над ячейкой отбора.. а если количественный учет - вот так навскидку - фиг вам...
.
хотя и при количественном можно.
.
но у меян например, количественный не прижился - ну не нужен он мну.. - начсклад прсоит - дай количественный учет по ячейкам - начинаю выпытывать ДЛЯ ЧЕГО? что это улучшит? - в ответ невнятное мычание.. Пока не будет веских причин - хрен будет какой количественный учет

(46) странный клиент - сам сидит на Бух 7.7. а хочет полноценную WMS.
пусть сначала посмотрит скоко это стоит так хотелки быстро свернуться к справочнику :)

(46) > сделать складской учет максимально прозрачным.
- фраза ни о чем.
.
> где не известно какое именно количество лежит в ячейке, клиента не устроит
.
озвучьтен, что конкретно получит клиент/для чего ему нужно знать количество товара в каждой ячейке?
.
вообщем без внятного описания что есть сейчас на складе и чято нужно - разговор смысла не имеет.
.
обращаю ваше внимание, что от клиента надо добиться чтобы он не говорил КАК И ЧТО ДЕЛАТЬ, а что хочет получить и зачем - отсюда выбирать методы/пути решения.
.
если клиент будет оперировать фразами типа "сделать складской учет максимально прозрачным." или "где не известно какое именно количество лежит в ячейке, клиента не устроит. " - внедрение пойдет тяжело и клиент получит систему которая нахрен ему не сдалась...

(48) так самое интересное что простенький ВМС на раз прикрутится к бухии - потому что это апсолютно независимый разрез учета..

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

(46) ...Он видел текущую реализацию в нашей УПП и попросил сделать нечто похожее у него - так поставьте ему УПП :)

(51) ну, у меня сейчас то что раньше делали 18-22 человека - не особо напрягаясь делают 12-14 человек, можно было бы еще меньше, но загрузка склада не удается размазать равномерно по рабочему времени...

(53) как бы у тебя на структуру данных глянуть? :-)

(54) тривиально там все до безобразия! но если хочешь - то давай мыло - скину тим - залезешь посмотрешь - скажешь - ну я думал тут что-то интересное...
[email protected]

(48) Учитывая то что на новый склад было потрачено N-миллионов, то пара сотен тысяч на программную доработку будет приемлемым вариантом)) Поэтому и думаю на счет отдельного WMS решения. Чтобы все хотелки с запасом были решены.

(56) пара сотен это даже много, обычно укладываются в одну сотку k$ :)

(55) мой ник на мэйл.ру
отправил пустышку.

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

(58) ушло, можно скайпом еще - может проще будет - там же можно рабочий стол показать вроде
скапй Zlopun