Сабж.В отладчике выдает почти 90 % . А что если выгружать в ТЗ и там отсекать лишнее(по позиции дока) ? Это я про партии.
Это велосипед,неэффективно или кто-то уже делал ?

Отвечу вместо Телепат-Бота:
Посмотри вот тут решение по последовательностям
Книга знаний: Асинхронная работа с регистром остатков 1С: полезные алгоритмы

А тоже самое для v8.0

(1)Я уже читал,но ИМХО,моя идея попроще будет,да и без ВК.
(2)Странно,я когда по 8-ке готовился,то что-то не встречал такое.Правда сдавал по бухии.

up

(0) Это неэффективно. Очень..

(5)Ты делал ? Я пока просто заремил вызов гл.процедуры и влепил свою для партий и для остатков,другие регистры вообще  не рассчитую пока(заявки,взаиморасчеты и тд).Так летать стало.База ДБФ,справочников 40тыс номенклатуры,размер базы 800Мб.Ошибок пока не нашел(правда тестировал пока на одном доке).Пока не решил как с оборотными быть.

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

(7)По партиям-да.В (6)-ошибка(пока!) на счет регистра остатков.

"правда тестировал пока на одном доке" - док проводил на ТА или "задним чилом" тоже?

(8) А что значит "по партиям"?
А вообще, очень сомнительно все это..

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

Выкладывай - заценим. Или заматюкаем- не обессудь.

(9)Задним числом,на ТА неинтересно.Вроде работает,вечером если будет время,засяду за тестирование.Я же не говорю,что я реализовал это.Пока в стадии разработки.Просто думал,что кто-то такое делал и натыкался на грабли.
(11)Сщас...Особенно после твоего поста.И не тебе решать,засираю я или нет !
(12)Есть идея ? Говори.
В общем,пока кроме ромикса никто нифига не предложил,только выложить просят.
Я задал конкретный вопрос:реализовывал кто или нет и если реализовал как-то по другому,просьба рассказать идею.

У меня так работает. Все хорошо.
Единственно, что добавил - в регистр измерение, позицию поступления партии,
при выгрузке итогов отсекаю партии, поступившие позднее проводимого документа.

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

(13) Ну падалута :(
(14) Понятно, однако как определяешь что произойдет с ней потом?
Пусть позиция ранее позиции дока... что дальше? Если продашь/переместишь больше задним числом - это избавит от минуса однозначно до текущего момента?

(15)
Да. Избавит.

не могу понять. как это ускорит. что выгружать в ТЗ? регистр? запросом?

(16) Не верю :)
Тогда надо пробежаться по партии и посмотреть вплоть до каждого движения не вызывает ли оно минус
Иначе на ТА он моджет не возникнуть а где-то посередине - вполне
Чего-то недоговариваешь :)

(18)
Партия на то и партия, что по ней всегда ОДИН приход и много расходов.
Говоря математическим языком, функция количества остатка по партии не знакопеременна.
Соответственно, при принятом подходе, если на ТА остаток есть, то можно смело его списывать.

(19) В математичеком подходе согласен, в складском и бухгалтерском - нет


Движение  Остаток
+10         10
-4          6
-6          0
+5          5

Лезем, меняем расход

Движение  Остаток
+10         10
-5          5
-6         -1
+5          4



Что скажешь?

+(20) Упс, изиняюсь... приход будет по другой партии, однако возможны, например, возвраты в ЭТУ же партию

(20)
Что такое +5 в конце?
Речь не про остатки на складе, речь про партии.
У тебя что, на эту же партию еще раз делается приход?

(22) Ну в типовой по крайней мере возможна такая ситуация (возврат какой-то)

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

в общем все как всегда

(24) :)
Запости чего интересного

(21)
А вот для этого и есть дополнительное измерение в регистре - "Позиция поступления".
При возврате приходуется в эту же партию, но с ДРУГОЙ позицией поступления,
(позицией, когда был возврат)
и количество по партии не "схлопывается", те при выгрузке итогов появляется два итога по данной партии:
- первый с позицией поступления и без учета возврата.
- второй на количество возврата, и с позицией, когда возврат произошел.
Если возврат был позже проводимого документа, он "отсечется" по позиции.

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

(26) Александр, молодец!
Пока придраться не могу, надо обдумать (т.к. туповат)

+(27) Хотелось бы еще услышать как там все у тебя...
Есть ли ГП?
Какой гимор в связи с правкой задним числом, есть ли он?
Есть ли производство? Как корректируете себестоимость которая неизвестна?

+26
То есть следует рассматривать партию не как элемент справочника партий, как заведено в типовых, а как некую сущность, для которой выполняются два основополагающих требования:
1. У нее всегда есть момент прихода.
2. С момента прихода для нее всегда происходит только расход.

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

(29) А позиция - это же получается позиция документа прихода?
Т.е. Дата_Тайм_ИдДок прямо целиком? Или может туда засунули ссылку на документ прихода?
А дата есть же в ТиС - убрали?

(28)
ГП есть. Надо восстанавливать. Применяемая метода 100% гарантирует, что ГП восстановится. Производства нет, простая оптовая торговля.
Основной гимор при ЗЧ - уменьшение прихода. Может не дать провести документ с уменьшенным приходом, тк часть или весь товар с этого поступления уже списался, хотя в-принципе, мог бы успешно списаться и из других приходов.
Приходится вначале распроводиь расход, уменьшать приход, снова проводить расход.

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

(32) Спасибки!
Вот именно, поэтому и спрашиваю, что даты мало
Т.е. как в 1сжорн?, а если ссылку на документ?

+32
Используется ПолучитьПозицию (то бишь практически date_time_iddoc), если просто ссылку на документ прихода, то возникает лишнее обращение к базе за получением положения документа.

(34) Точно, так и думал, все улеглось
Может предложу своим что-то такое ибо затрахало, спасибо

опять фигню порют...

(36) Запости чего интересного?

Ооооо.... В (35) еще один затраханный.... ну ничего... или заплатит или перетрахается раз ...цать и сам изобретет велосипед....

Началось :)

Понеслась .... Даю отмашку - начинайте....

(38) У нас сейчас административными мерами в основном борьба, но есть неприятные моменты. А партии нужны очень сильно
За что мне платить? Тебе за технологию?

(41) За идею... Как все построить...

(42) Наверное много денег? Много переделывать?

Ну, в-принципе, если не интересует абсолютная точность списания по ФИФО-ЛИФО,
по приведенной методе ГП восстанавливать не обязательно.

(43) karkarde([[[)pisem.net

(44) тож отпишись - дело есть... А то у меня вся почта рухнула...

запахло титанами 1са...

(30) А не могли бы Вы пояснить, как будет происходить списание партии, если задним числом перепроведут документ, по которому партия образовалась, и изменят его позицию? Расходы, уже сделанные по партии к моменту изменения партиеобразующего документа, ведь будут не по тому измерению Момент, по которому приход.

(0) Да, мы такое делали... работает гораздо быстрее...
можно сделать так, чтобы прозрачно работало и с регистром и с таблицей значений.

Короче фишка в том, что при перепроведении с даты а на дату Б остатки хранятся в памяти, очень убыстряет перепроведение.

(48) Это используется только для ночного перепроведения, или обыгрывается константой "Дата запрета редактирования"

(48) Это ко мне вопрос? :)
Я тоже об этом подумал, но пока то се - забыл спросить. Наверное просто так позиция не меняется, а поскольку есть последовательность - все равно перепроведется все по итогам

забудьте про позицию - она не нужна...

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

если охота полной прозрачности кода - можно втиснуться в модуль регистра...
и там такой код:
Если текущийрежим="ЭмуляцияРегистра" Тогда
  Вернутьитоги по ТЗ
Иначе
  Вернутьитоги по регистру
КонецЕсли

(53) гений - а если не один человек работает в базе? у меня была такая идея

(54) стрелок, ты военный? читай (50) или еще раз повторить?
Повторяю: ДАТА ЗАПРЕТА РЕДАКТИРОВАНИЯ

(54) у тебя такая идея была, а мы такую идею написали

+(47)и не только ими....

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

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

(58) стрелок....
Допустим нужно перепровести по партиям с даты А по Б
берутся остатки по партиям на дату А (все), заливаются в ТЗ.
Далее при последовательном проведении документов остатки читаются не из регистра, а из ТЗ, при записи движений соответсвенно поправляется ТЗ...

Не вникал, речь про это или нет, но шебуршит весьма быстро...

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

(61) гы... в 1С нет разделенных областей памяти между разными приложениями...

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

(61)(62)а в типа кеш-структуру на базе РС зафигачить?скорость упадет?

(64) ты как себе это представляешь? как по сетке доступ организовать?

и пит молчит как партизан. хоть бу зараза намёк дал на направление. вот же капитошка

(65)флажками куячить

(67) ты про морской семафор что ли? не все его знают

(68)в РС флаги выставить

(69) что такое РС? для меня это "персональный компьютер"

(66) Хрен вам...

(70)рег сведений

(71)нам хрен тебе пиздец...

(72) речь про 7.7 - забудь

(71) жлоб?

Если Пита переедет трамвай (тьху-тьху) - пепец всему, я ж говорю - надо успеть поделиться знаниями

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

(+77) доступ. нехай задавится ;))

(77) Неэтично, как-то по одинэсовски :(

(79) от него никто не просит реализации - просто идея, намёк, толчок... что нибудь по теме кроме его "дятлы"!!!!! хоть два слова

тем более что я точно не пересекусь с ним по бизнесу

была бы людская цена - нет вопросов. но 500 бакинских за кота в мешке - увольте. КЗК нужен был и цена устраивает - купил

(80)Тебе не хватит ни идеи ни толчка, имхо...

(83) ЛОЛ!!!!!

(79) завтра отпишусь...

Согласен, lol.

Согласен участвовать во взносах - меня и 20 уе не задавит... ;-)
тока давайте потом все кто концессионеры будем как Пит тоже жабиться ;-)
опять же - есть опасения, что фигня будет... а может и не фигня - но придется переписать стока всего (отчетов, проведений и прочего), что оставить стандартную ГП - дешевле выйдет... тем более если административно все поставлено более-менее нормально и взад катастрофично не лазят...
Опять же - есть кто, кому Пит продал/сделал по своему "алгоритму" - кто подтвердить может?

на эту тему анекдот:
- два клана мафии, воюют, бойцы гибнут, урон бизнесу.
решили замириться. как? а вот у одного дона - сын, а у второго - дочь.
решили их заженить.
ок! заженили.
хрен войне, да здравствует мир! торговля идет, бизнес растет. все ок.
приходит дочь к своему дону-отцу.
- Папа!
- ????
- меня муж в попу имеет, раньше очко было с рубль, теперь как 5 рублей ;-(
- ну вот! мы что, из-за 4-х рублей войну начинать будем?

(87) мне кажется что таких, кому пит продал здесь нет. почему - не знаю. может потому что никому не надо ;))

А мне кажется, что они стреляются от осознания что их развели как кроликов...

(89) Ну вообще то слишком много пропала старожилов.... Львёнок например... где делся? Рупор затих....

(87) Самое прикольное - в типовой ТиС для России переписывать надо очень мало...

Отчеты трогать вообще не надо....

(91) ну так сдай фишку.... эксклюзив ты уже собрал наверняка... нам крохи остались....

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

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

Короче все хня. Обычная типовая - Партии там в доках есть. Единственное что нужно чтобы партии заполнялись в доках. Контроль там стоит. При работе задним числом воще никуа не будет. Нужно переработать чтобы при выборе товара срабатывала обработка которая заполнит нужную партию в док (обработка фоновая, как раз она просчитает свободные партии конкретной строки на документ, отсечет списанные после - тоже легко сделать и заполнит партию в док). Можно сделать групповую обработку по заполнению партий в ТЧ по нажатии кнопки или при записи.
При этом проводится все будет ништяк (при перепроводках и прочих ньюансах) плюс минусов никаких.
У самого подобный аглорит работает семь лет и не жужжит. пару-тройка минусов при перепровоедении за месяц. Ито отчеты все отслеживают выдают.

(91) а что, в российской ТиС не реализован механизм "средневзвешенной"? неужели еще что-то дописывать надо??? )))))

(95) при списании по ФИФО будешь строки в документах двоить-троить?

+(95) сама фишка в том что как раз при выборе товара осуществялется подборпо конкретной свободной партии. При проведении считай уже все правильно. Типовой механизм отработает все успешно и минусов не будет.

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

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

(99) просто не проведет и всё. а как ты хотел проводить без остатка ?

(100) так у тебя всё равно остатки по партиям получать надо...

(101) А это называется "учёт по партиям" и он применяется относительно редко. 75 % сидят на ФИФО.

(99) причем там даже модули проведения корректировать не нужно.
1) Нужно поставить запрет проведения доков без заполненной партии.
2) при выборе реализовать фоновую процедуру установки партии в тч (работает и глазом не моргнешь). если нужной партии нет выдавать сообщение.
Ну и собственно по мелочам.

(103) а кто тебе мешает подбирать нужную партию по фифо ?

(104) не удобно это..... у тебя получится что в разных строках разные себестоимости могут быть..... хотя как костыль конечно можно..... но всё равно остатки по партиям получать надо - опять расчёт регистров... по ФИФО в этом случае проще будет сделать....

(105) а если я её по фифо получаю то накой мне делить строки? не врублюсь тогда

Короче самый действующий способ. А вот насчет ФИФО ты расскажи кому нить другому. В УТ тотже самый можно сказать метод по конкретной партии ведется и без этого никуда. Те же серийники и характеристики - это совершенно не фифо.
Так что и по семерке таже хня в три счета делается.

(106) да у меня расчитывается в обработке итог, но этот итог по конкретному, товару, фирме и т.д. тоесть много фильтров. партии выбираются глазом не моргнешь. К тому же не забывай этот расчет не в момент проведения (не влияет на транзакцию), да и к тому же ничтожно мал. Это тебе не по всей ТЧ документа итоги расчитывать.

(108) давай ты мне про партионный учёт тоже не будешь расказывать. и вообще никто никому не будет рассказывать. Если в УТ нельзя отключить посерийный учёт то это херовая программа. а то что ты предложил - это учёт по партиям. неудобная штука доставшаяся в наследство от совковой бухгалтерии....

(109) Стоп. не в момент проведения - а когда?

интересно - расчитать 100 раз итоги или расчитать 1 раз с фильтров по 100 товарам - что быстрее будет?

Даже групповые обработки работают долю секунды. Например когда насчет счета выписывается расходная накладная - по кнопке или автоматически происходит расчет по всей ТЧ нужных партий - перезаполнение ТЧ ну и собственно все. Элементарно, просто, может даже тупо - но совершенно действенно !!
Два - три минуса за месяц - неплохой результат.

(112) млять, да у тебя миллиарды запросов возникают каждый момент в базу ну и что с этого. САМОЕ важное - ЧТО НЕТ никаких доп расчетов в МОМЕНТ проведения. Не увеличивается транзакция. вот что главное.

(114) ответь на три вопроса
1. юзеру нужно поменять количество в накладной - что он делает?
2. где ты расчитываешь какие партии тебе нужны?
3. 1 запрос с фильтром по 100 товарам реально работает дольше чем 100 запросов по одному товару?

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

и ещё пример из жизни

Товар 1
Остатки :
Парт 1 - 100 шт
Парт 2 - 200 шт
Парт 3 - 300 шт

нужно продать 420 штук

что происходит при проведении ручном, групповом, как поменять 420 на 450?

(116) посерийный учёт нужен в 2-3 % - торговля лекарствами, мобюильниками, техникой бытовой. больше - не нужен

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

(115) ну и пусть меняет в пределах партии.
обработка которая вызывается в процедуре ПриНачалеВыбораЗначения на элементе ТЧ "Номенклатура". Она при открытии просчитывает все и выдает окно списка партий со сводными количествами (если это не нужно то можно сделать без открытия окошка а автоматическое проставление). При изменении количества тоже можно сделать просчет. Все это будет работать очень быстро.
3) да гораздо быстрее а ты что не знал ?

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

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

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

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

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

(124) про партии - не надо. не стоит тебе опускаться до моего уровня..... не напрягайся


прикольно это слышать когда я сам происзводство на регистрах писал с нуля и торговлю полностью для реальной конторы ;))))

ну да бог с ним - не понимаю - не надо.... мнение своё высказал

+(124) по резервам таже хня еще и хуже может возникнуть. И что ты думаешь по тому же самому алгоритму работает и не жужжит. Точно также а еще и хуже может быть - перемещается товар 100 штук - по 7 различным резервам разных покупателей. Шо ты думаешь тут делать ? ))) гы.. ладно.

Маньяк врет. Его идея 7 лет работать не может. Так как стала возможна только в 9 редакции ТиС. А это года 4. В остальном он близок к решению на 95%. Причем без Пита.

(127) а кто тебе сказал что я тис использовал ? Это я сейчас расписал реализацию под современную ТИС. Мы же все это делали на друвнючей 2 комплексной. сами. когда еще ни там ни в тис вообще партий и понятия партия в типовых не было.

Самое смешное - что в наших ТиС это реализовано давно и штатно ;)))) так что - идея никакая ;)))) если это близко к решению пита то я за такое решение и пяти гривен не дам ;))

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

(129) (130) господа, имхо, вы отклонились от темы ветки. Речь ведь не шла об отказе от понятий "партия", "последовательность" и т.д. Речь шла о механизмах реализации данного велосипеда?????????
З.Ы. Не пинайтесь только сильно - после работы и уже отдыхаю :)))))

Причем метод действительно действенен.
1) проведение. Нет никаких дополнительных расчетов - проблема транзакций.
2) нет сдвигов уже проведенных результатов.
3) нет минусов.
4) процедура происходит фоново в режиме оформления операции.
Метод просто незаменим при условии ведения учета в тех же типовых 7.7 по свойставам партий (например по цветам, серийным номерам, сертификатам и т.п.) которые требуют явного указания признака партии.

(132)
1 - да;
2 - нет;
3 - нет;
4 - да.
Обьясни, пжл, как отработает твой алгоритм, если тупо уберут приход, по которому уже были расходы???

5) доработки не являются глобальными. не требуется переписывать алгоритмы и т.д.
6) Применителен к другим ситуациям - например когда есть перемещения резервов между складами. Или например когда приходуется товар и его нужно распределить по заказам покупателей. Гораздо проще реализовать функкцию подбора при занесении строки чем потом клацать по отдельному полю и искать нужный документ заказа.
Прыгает обычная табличка которая высвечивает ИТОГИ по конкретной позиции со списком заказов по этому товару.

(133) а если тупо снести полбазы то что будет ?

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

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

(137) определение партии ДО момента проведения глупость. ты ещё этого не понял? Чтобудет если пока ты формируешь документ партию выбранную тобой для товара в первой строке уже спишут другим документом другой пользователь?

твоё решение - для однопользовательской ТиС в сельском ларьке

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

+(136) и насколько я понял, ветка была об оптимизации работы регистров остатков. Несомненно в каких-то условиях (видимо тебе повезло с административным порядком на предприятии) твой алгоритм является оптимизацией. Теперь осталось рассмотреть вопрос оптимизации работы алгоритма определения парти именно при проведении документа.

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

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

(138) Андрей, давай без наездов - это не политика :)))

(140) а что там определять ? когда партия выбрана в документе то при проведении по ней установлен фильтр. В типовой это по типовому заложено. Это еще больше оптимизирует проведение.

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

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

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

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

(146) Ты описал ФИФО с отображением процесса списания по партиям в ТЧ документа. .больше никакой смысловой нагрузки это не несёт. а неудобств - масса.

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

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

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

(152)мля,а мир не меняется.Если у человека есть авторитет,то либезишь перед ним,а если ник малоизвестный,то можно и обоср..ть.Разве не так ?
Я же еще в (0) написал,что может быть это и "велосипед",не могу же я все знать что у кого-то реализовано.
Но ведь работает.
...........
В общем,спасибо тем , кто не стал сразу сходу обс..ть как (152), а начал вникать в проблему и делиться опытом.Пока доделываю,шлифую,пробую.

Одно слово - специалисты )))

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

(154) Не понял из (0) - откуда и в какой момент времени ты собираешься заполнять ТЗ. Регистры то для выгрузки их состояния в ТЗ все равно надо расчитывать...

(157)
Нет, если регистры не рассчитывать, то они выгрузятся по состоянию на ТА.

(158) Это понятно. Но нам ведь надо на момент проведения дока и для тех, которые задним числом? Чем нам помогут остатки на ТА?

(48)
Ну, с приходами контроль строится так:
1. По измерению "ПозицияПоступления" ставим галку "Отбор итогов"
2. В конце проведения/отмены проведения делаем
СтатусВозврата(глКонтрольИтоговПартий(Контекст));
3. Имеем такую функцию

Функция глКонтрольИтоговПартий(Конт) Экспорт
   регКонтроль = СоздатьОбъект("Регистры");
   регКонтроль = регКонтроль.ПартииТоваров;
   тзКонтроль = СоздатьОбъект("ТаблицаЗначений");
   регКонтроль.УстановитьЗначениеФильтра("ПозицияПоступления", Конт.ПолучитьПозицию());
   регКонтроль.ВыгрузитьИтоги(тзКонтроль);
   
   тчДока = СоздатьОбъект("ТаблицаЗначений");
   Конт.ВыгрузитьТабличнуюЧасть(тчДока, "Товар, Количество");

   ВсеХорошо = 1;
   тзКонтроль.ВыбратьСтроки();
   Пока тзКонтроль.ПолучитьСтроку() = 1 Цикл
       Если тзКонтроль.Количество<0 Тогда
           КолВДоке = 0;
           поз = 0;
           Если тчДока.НайтиЗначение(тзКонтроль.Товар, поз, "Товар")=1 Тогда
               КолВДоке = тчДока.ПолучитьЗначение(поз, "Количество");
           КонецЕсли;
           Сообщить("Товар "+тзКонтроль.Товар + " из этого поступления уже продан в количестве "+(КолВДоке - тзКонтроль.Количество), "!!!");
           ВсеХорошо = 0;
       КонецЕсли;
   КонецЦикла;
   Возврат ВсеХорошо;
КонецФункции    // глКонтрольИтоговПартий

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

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

(161) смотря какая специфика.

(162) Специфика - одновременная работа нескольких менеджеров. Чем их больше и плотнее документооборот - тем больше будет риск таких коллизий...

(163) не значю чо там будет, у нас работает все на ура.

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

(165) При чем здесь задним числом. Коллизии будут возникать как раз при штатной работе менеджеров, не задним числом.

(166) ты гонишь. при штатной работе какие нафик могут быть проблемы если доки проводятся по ТА и нет никаких расчетов вообще
.

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

+160
Сорри, писал текст функции по памяти. Реально там еще небольшой момент
Функция глКонтрольИтоговПартий(Конт, фРаспроводим) Экспорт
   регКонтроль = СоздатьОбъект("Регистры");
   регКонтроль = регКонтроль.ПартииТоваров;
   тзКонтроль = СоздатьОбъект("ТаблицаЗначений");
   регКонтроль.УстановитьЗначениеФильтра("ПозицияПоступления", Конт.ПолучитьПозицию());
   регКонтроль.ВыгрузитьИтоги(тзКонтроль);
   
   Если фРаспроводим=0 Тогда
       тчДока = СоздатьОбъект("ТаблицаЗначений");
       Конт.ВыгрузитьТабличнуюЧасть(тчДока, "Товар, Количество");
   КонецЕсли;

   ВсеХорошо = 1;
   тзКонтроль.ВыбратьСтроки();
   Пока тзКонтроль.ПолучитьСтроку() = 1 Цикл
       Если тзКонтроль.Количество<0 Тогда
           КолВДоке = 0;
           Если фРаспроводим = 0 Тогда
               поз = 0;
               Если тчДока.НайтиЗначение(тзКонтроль.Товар, поз, "Товар")=1 Тогда
                   КолВДоке = тчДока.ПолучитьЗначение(поз, "Количество");
               КонецЕсли;
           КонецЕсли;
           Сообщить("Товар "+тзКонтроль.Товар + " из этого поступления уже продан в количестве "+(КолВДоке - тзКонтроль.Количество), "!!!");
           ВсеХорошо = 0;
       КонецЕсли;
   КонецЦикла;
   Возврат ВсеХорошо;
КонецФункции    // глКонтрольИтоговПартий

(169) А твоя идея насчет момента документа - очень интересная. Жаль - сейчас нет времени как следует разобраться и продумать ее...

(160) А не надо ли еще и

регКонтроль.Актуальность(1)

выполнять?

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

(170)
Да там в-принципе все ситуации можно в столбик на бумаге смоделировать.

(160) писец. это же тормознутый алгоритм. а де фильтр по номенклатуре ?

+(174) И ГОРДАЗДО быстрее бежать по табличной части дока - делать фильтрацию регистра по конкретному товару и сравнивать сводный остаток.

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

(174) Маня, не позорься.

(154) Офигеть, не пори чушь
Просто надо описать человеческим языком свой подход, чтобы было понятно
Разве говорил по какому принципу отсекаешь и т.п.?
Это не было ни здесь ни на Кубани
Учись излагать мысли
И подход Саши надо обдумать - применим ли он к нам будет

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

(179) Тупишь. Остатки на ТА покажут "-", если приход меньше расхода.

(180) Это ты тупишь... покажут ПОСЛЕ проведения, а надо бы не давать проводить документ

(179) и (181)
Допустим был приход 5 шт, продано 5.
Меняем приход на 4.

Уже после

рег.Количество=4;
рег.ДвижениеПриходВыполнить();

выгрузка итогов по данной позиции поступления выдаст -1, при проведении.

(182) Угу, я просто думал сначала делать проверку
ЗЫ. Короче забраковал идею "идеолог" :)

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

Наверное пора мне в отпуск :(
И Плюшкина обидел :(

(184) А что с резервами? Если принять, что постановка ТМЦ в резерв - "приход", снятие с резерва или реализация - "расход", то технология (169) может быть применима и здесь. ИМХО.

(183)
Ну, дело ваше.
Идеолог чем нибудь мативировал "забраковку" ?

(187) Что потом "хрен разберешься", "что-нибудь забудешь" и вообще так неправильно идеологически - надо на момент дока брать
Я тут нахомутал немного с прямыми запросами пока привык к их конфиге - боятся наверное новшеств :)

В принципе тут есть неудобства в плане изменения всех последующих расходов если что - однако все равно же что-то менять надо :)

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

Имхо вообще 1С со своим временным расчетом подложила здоровую свинью.

(189) а ты им не пользуйся...

А Пит так и не пришел, хотя обещал, ну да еще не вечер.

Упс, пришел таки, пока писал пост его не было

(192) Долго же ты пост писал. :)))

Я последние посты читал :)

(190)
Так я то не пользуюсь как раз...

Вот и настали свободные дни...
По партиям без проблем,а вот по РегиструОстатков как ? Или же сделать,чтобы вообще не проверялись остатки,а из партий возвращался результат(можно проводить или нельзя) ?

(196) Для регистра "Остатки ТМЦ" (если речь о ТиС) принцип тот же самый. В нашей конфигурации мы вообще от него избавились, перенеся измерение "Склад" в регистр ""Партии", здорово уменьшив время проведения документов.

(197)Если отказаться от ОстаткиТМЦ,то переделывать дофига :(( Там же еще и учет по розничным ценам есть.

Плюшкина продолжает плющить....

(кто на 200?)

200

ипать я крут

Тук-тук...

(202)
Что-то до тебя письма не доходят...

(196) Ну дык расскажи - как сделал.

Пипец, такую бадягу замутили из такой отсебятины :-!