v7: склад в табличной части документа. Плюсы и минусы. #302196

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

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

счас я не очень понял что-то... что за склад?

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

+1

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

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

реализовывается в общем без особых проблем, какая связь с 1С++ не совсем понятно

аха... заодно переиписать пол торговли..

надо же как то время убивать :))

ну я понимаю что это легко сделать, про связь с 1с++ я просто неправильно тему озвучил и я просто спрашиваю кто реализовывал с какими проблемами столкнулся. какие плюсы от этого переписывать полторговли не буду да и не придецца. гы у меня комплексная...

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

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

...и накладную "резать" по каждому кладовщику...

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

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

вот и прошу совета кто сталкивался с таким решением поделиться опытом...

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

ну вот я те и говорю, мы так работаем, я это реализовывал, что конкретно интересует?

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

работа в принципе НИЧЕМ особым не отличается, нафига там чего то вычленять, в регистры же у тебя нормально пишутся движения по каждому складу.

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

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

да именно так

причем один и тот же товар (элемент справочнка номенклатура) может быть на разных складах и себестоимость соответсвтенно привязана к молу то есть у одного МОЛ она по 3 р у другого 4 у третьего 5 и т.д.

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

что?

хотел сказать то

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

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

+28 пусть не забудут перепрошить его на СОМ интерфейс, обычно делается считыванием нескольких служебных ШК. если это так (а не джампер, к примеру), то обязательно имей картинки на касссе, а то бывает отваливается периодически у них память о типе шнурка...

Да честно говоря, надоело повторяться...  Ты разберись с фактами, и то, что документ фиксирует факт. действие. Ну чесслово, обсуждается регулярно. Пределать конфу - легко. но _фактически_ ты поступаешь неверно - ты смешиваешь разные факты (разные действия) в одном документе. ПОищи поиском, или подыми ветку вечером - работы привалило... :-(

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

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

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

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

А представь ситуацию, док выписан, а покупатель не забрал со склада с какого нить. Кто то должен отвечать за док. И следить, что если выписано - то и забрано.

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

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

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

+ Если склады находятся на одной территори.

Нормальное решение - склад в ТЧ. А вот автовыбор в момент проведения - оч плохо.

думаю не очень хорошо с себестоимостью получится при средних ценах

+40 автовыбор склада в момент проведения - это полный писец базе. Сливай воду, туши свет...

Ну здесь надо подумать. Хотя на мой взгляд должно быть все нормально.Смотря еще как у них политика партий настроена FIFO,LIFO или сред.себ.

Все там нормально. В 8 в типовой реализации склад есть и в шапке и в ТЧ. Доработок в конфе минимум. Все движения будут корректными. Если продуманы печатные формы для кладовщиков и главное удобный механизм выбора склада, то все путем. НО НИ В КОЕМ СЛУЧАЕ НЕ ДЕЛАЙ АВТОВЫБОР СКЛАДОВ В МОМЕНТ ПРОВЕДЕНИЯ. За такое надо руки прогам отрывать.

партионного учета нет во первых дарова во вторых про автовыбор в момент прведения никто не говорит в подборе при вводе кол-ва организован список складов (снизу добавлена табличка) при клике на строку со складом в док вставляется тот склад с которого указано то есть манагеры руками выбирают склад с которого отпуск производится и при нехватке там нужного кол-ва предложит либо разбить с разных складо либо ПРЕДЛОЖИТ выбрать тот склад на котором хватает

>>>За такое надо руки прогам отрывать эт точно. поди туда не знаю куда принеси то не знаю что получится

привет. Тогда нормально. Я просто виде уже как в агониях умирала одна база после таких доработок, как у Анахримед...

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

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

а у нас так не прокатит надо что б манагер руками мог выбирать сам откуда списывать

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

а будет лучче сли товар спишется со склада №1 а его по приказу дира в первую очередь надо опустошать со склада 2

так расставь приоритеты складов и списывай по очереди

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

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

просто пипец. Нет слов...

(+54) пошлет скажет у меня по б умажкам вот так иди копай прогу... ну я конечно не знаю может у вас специфика такая что можно так списывать но нам не подходит. я не хаю твое решение. просто нам оно не подойдет а реализовать конечно можно и так и с приоритетами и автосписание. вон в типовой ПУБ тоже есть автосписание со складов.

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

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

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

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

перемещения это хорошо. Но ты ушел от ответа. У тебя в принципе не бывает никаких исправлений задним числом?

они запрещены на програмном уровне

+ исправить можно только до 10 числа месяца следующего за отчетным и то не править доки по реализации, а сделать перемещения с других складов

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

Запрещены всем правам или только большинству ?и ВСЕ ошибки оформления документов ты можешь корректировать вводом новых документов сегодняшней датой?

новую реализацию нужно кому-то выписывать и если есть кому то почему бы нет + есть еще один прикол товар не только собственный, но и комиссионный

внутренние перемещения - это ладно. Не бывает ошибок, когда оформлены с ошибками  документы поступления или продажи товара?

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

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

ассортимент 12 000 наименований, документооборот около 100 реализаций в день, складов около 10

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

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

100 реализаций в день это небольшой документооборот. Ты мне скажи, как ты поступаешь, если обнаруживается ошибка количества товара например в документе ПоступлениеТМЦ.

реальные документы по поступлению ТМЦ и так приходят в основном с опозданием, но их можно править когда угодно

одна с/ф на несколько реализаций? что-то не верится в такой подход. И как потом формируются книги продаж/покупок при такой доработке?

когда угодно? и после этого не восстанавливается ГП? И ты говоришь про то, что в базе нет бардака? Откуда такая уверенность?

+77 и что у тебя с себестоимостью, если поступления правятся задним числом как угодно, а ГП не восстанавлиывается?

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

а себестоимость откуда берешь?

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

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

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

а откуда берешь себестоимость (я про РРН не слышал ничего)

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

НОрмально формируются.   жуть. Работать оно наверное работает, но вот в то, что оно считает правильно- я не верю. ТОчнее, оно будет считать правильно в интегральном интервале "от начала времен до полной реализации", но конкретно за период будет нечто невообразимое..

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

Это для розницы пойдет. (85.2) Это как в рознице с 42-м счетом

все покидаю ваше обсуждение я всего лишь указал на минусы в таком подходе

тебя обидели? Реально интересно как такое может летать 4 года без проблем. Поделись опытом.

(86.1)  нормально формируются без доработки механизма книг? Или туда тоже придется залазить?

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

ты двигаешь _одним_движением_ деньги многих кладовщиков.

и? в чем проблема пока не вижу...

ЧТо-то дорабатывал, но там мелочь. Даже не помню.

ну и что? Главное, что можно потом отследить - кто и откуда что-то двинул. Какая разница одним движением иили несколькими?

к слову сказать в 8 склад в ТЧ - штатный механизм...

В том, что докуменгти фиксирует движение товара _с_одного_подотчета_. Кто ответсвенный за документ? (вот представь, защел шеф к вам в отдел, кинул мешок денег на стол, ведомость, и сказал - вот зарплата, разбирайте... Сколько в мешке денег было, сколько кто взял, расписался-не расписался.... ) Я тебе еще раз повторяю - программно это реализуется очень и очень легко. Ошибка методическая.