Добрый день!

Жду от знающих людей совета. Кто такое видел или даже делал, не проходите мимо.

Есть в типовых обработках такая: "Пакетный ввод документов". Обработка позволяет, помимо прочего оформить продажу между внутренними организациями. Но делается это неоперативно, тоесть сначала ты продаешь от одной организации "в минус", а потом запускаешь обработку которая все эти минусы компенсирует, за счет того, что оформляет продажи с твоих же организаций на ту которая минусует.
Моя задача похожа, но мне нужно оперативное оформление документов. Я себе это представляю так: при проведении реализации происходит проверка на остатки, если остатков недостаточно, значит предлагать пользователю "подтянуть с другой организации". Далее оформляет реализация и поступление на секунду раньше текущей реализации и вуаля, все ровно встает по партиям и никаких тебе никого и ничего.

Прошу прощения много букав, но меньше не могу - непонятно сделается.

Может кто уже такое делал/видел/знает где взять? Ну или хотя бы идеи по реализации?

чем не устраивает неоперативный механизм?

вот насчет "все ровно встает по партиям" я бы не был так уверен. Отгадайте с одного раза есть ли в УТ10 в регистре ПартииТоваровНаСкладах измерение "Организация"?

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

"Ну или хотя бы идеи по реализации?"

Ну вот у меня есть идея: при проведении реализации происходит проверка на остатки, если остатков недостаточно, значит предлагать пользователю "подтянуть с другой организации". Далее оформляет реализация и поступление на секунду раньше текущей реализации и вуаля, все ровно встает по партиям!

(0) Я себе это представляю так: при проведении реализации происходит проверка на остатки, если остатков недостаточно, значит предлагать пользователю "подтянуть с другой организации".
- то есть ты предлагаешь в ПРОВЕДЕНИЕ воткнуть ВОПРОС и ждать ИНТЕРАКТИВНЫХ действий пользователея... а все остальные будут ждать пока он в проведении соизволит ответить на вопрос...?

Предлагать что-то пользователю, да еще и в момент проведения - это моветон..

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

система в (0) - если ее сделать по уму (в чем я из текста топикстартера сомневаюсь) - вполне работоспособная. Частные вопросы - "есть ли организация в регистре Товары Организаций" и т.п. - фигня... пусть это будет "передача товара" не по этому регистру, а по другим... ;-)

(1) Вопросом на вопрос отвечать не культурно
(2) У меня КА
(3) Дай угадаю ты наверное написал конфигурацию которая сама приносит тебе ежемесячно денюжку, предврительно перевязанную красной ленточкой, и не мучает тупых обезъян и так далее
(4) Ник оправдываешь?

(8) не получилось разобрать то, что хочешь донести. Сейчас думаю сделать таким образом:
интерактивно перед записью в форме реализации проверять остатки и если их недостаточно лезть по остаткам внутренних контрагентов (в КА есть типовой регистр для этих целей). Если у этих внутренних контрагентов есть достаточно товара, просить у пользователя разрешения "подтянуть с другой организации". Далее оформляет реализация(либо несколько с разных организаций) и поступление ((либо несколько с разных организаций)) на секунду раньше текущей реализации и вуаля, все ровно встает по партиям и никаких тебе никого и ничего.

вира

(1) Кстати говоря. Мой подходит предполагает исключить продажи "в минус". Что само собой уменьшит шансы >|<опоруких сотрудников запороть партии, остатки и прочее

ап

Это типа этого http://subsystems.ru/catalog/program=581/

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

Есть еще один модуль, там система фактически смотрит списанные партии (когда фирма продает партии другой) и может тоже делать доки.

(15) Может на примере попробуем представить, а то не могу себе представить зафига целый склад?
(16) а поподробнее ...

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

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

(14) Но все равно спасибо. Буду иметь в виду если что

(18) ну вообще идеально. не вижу проблем в реализации тогда.

(21) Тогда вот ещё вопросик из серии "33 регистра, 33 регистра и стакан ....": сначала я подумал о регистрах "Товары организаций", но вот проблема там цен нету. А партионный учет у меня разбит на три "ПартииТоваровНаСкладахУУ", "ПартииТоваровНаСкладахБУ" и "ПартииТоваровНаСкладахНУ". Какой брать? или их стыковать надо будет?

(18) [У нас на каждую организацию свой склад.]

Жесть. Впрочем для КА и УПП при многофирменном учете, это единственно правильное решение. Хоть и корявое.

+ (23) и для УУ это ништяк, где нет измерения "Организация"

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

(25) (23) (24) Остановитесь пожалуйста. Ну или хотя бы притормозите. Давайте сначала мой вопрос решим, а потом я к Вашей дискуссии сам с радостью присоединюсь. Не хочется тему менять, мой вопрос ещё открыт

(25) Правильно, ибо по другому никак. Иначе УУ в топку.

В УТ11 это реализовано

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

Один фиг отчеты/подборы смотрят не документы, а регистры. А значит все там будет хорошо

(28)(29) И кто будет регистратором в регистрах, приходующих товар? Я так думаю, эти регистры отрыгнут записи без регистратора, а регистратора не будет до вечера

Короче так: буду брать все из ПартииТоваровНаСкладахНУ. Почему то он мне всех милее и роднее. И пусть меня остановит кирпич если я нарушаю методологию учета и вселенский баланс материи и антиматерии

(31) Ни где же ты мой кирпич? Я то думал, что сейчас буду доставать противокирпичный зонт, ан нет. А вокруг тишина

(30) Т.е. кто? Реализация которая списывает товар

У тебя есть реализации на ЗАО "Малые дети" по организации ИП Серый Волк на 3 палки колбасы, которая числится на фирме ООО "3 поросята"

В реальности тебе нужна
1. Документ реализация по фирме ООО, которая спишет 3 палки колбасы со склада ООО
2. Документ поступления по ИП, которые оприходуют на 3 палки колбасы на склад ИП
3. Документ реализация на ЗАО, которая продаст эту колбасу малым детям

Я предлагаю оформить это в два этапа
В течении дня, если товар нужно продать с ИП, а он числится на ООО, то программа дополнительно в реализации на клиента делает движения по регистру остатки на складе (или как там у тебя) перемещая товар со склада ООО на склад ИП (в данном случае нам не нужно как правильно со стороны бухучета, мы хотим проще для УУ. А вот для УУ это просто передача товара не более того). Плюс запишем в РС сведения о нашем перемещении товара с регистратором этот документ, (Организация, Номенклатура, Количество)

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

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

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

(35) Звучит грозно, только вот мотивация страдает. Так и хочется спросить: "а то чё?".

(34) Ну вроде тоже схема рабочая, но:
1. Если криворукий оператор выбирает не ту позиция (номенклатура/характеристика/серия/бог зачет что ещё) программа даст ему её списать.
Да для этого можно сделать проверку на наличие на других складах/организациях и запрещать если товара нигде нет. Но это геморой когда у тебя появляется вторая реализация, и надо теперь проверить реальные остатки на складе и состыковать их с мнимыми остатками (гыгы iостатки) которые нагенерили предшествующие реализации.

2. Уж очень меня смущает схема в которой надо перепроводить доки. Эстетика страдает. Пятая точка подсказывает что это неоправданный риск

3. Конечно не надо забывать про то, что пользователю захочется взять да и распровести/удалить реализацию, по которой уже была оформлена продажа. И тут вообще бубен-данс!!

вира

ап

(37)
1. Не понял, у тебя товар по организации ООО списывает документ реализация по ИП, Естественно списание не безусловное, а если товара хватает на ООО. У тебя НЕТ мнимых остаток, они у тебя всегда реальные. Разница только в регистраторе, т.е. в документе который сделал движения

2. Это же 8-ка, можешь не перепроводить весь документ, а редактировать проводки существующего, или организовать механизм проведения только по определенным регистрам

3. Ничего не будет, у тебя регистратор реализация по ИП, если её сниму с проведения, то он и отменит все проводки по ООО

(36) не забудь отписаться по результатам работы =)

(41) отписываюсь.

1. Добавил своё регистр (в дополнении к типовому "СобственныеКонтрагенты"), в котором указываю какая организация какой может продавать. Это сделал для того, чтобы система не предлагала пользователю делать продажи, в которых мы потом потеряем на НДС. Регистр из двух измерений Источник и Приемник (тип: Справочник.Организации).

2. Пришлось из формы перетащить механизм в событие "ПередЗаписью" в модуле объекта (ибо в форме списка и выбора реализаций есть кнопки "провести" и "отменить проведение").

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

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

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

(42) Вопросы в модуле проведения?

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

(42) Результаты этих перемещений лучше смотреть по истечении определенного времени, например через месяц. Там видно будет как работает эта дописка - результат как и было запланировано или в базе начинается хаос. =)

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

(45) Я не могу только понять. Есть конкретные опасения чего-то конкретного? Или это скепсис? (46)

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

(48) Это больше не на опасение похоже а на панику. Ты за все это время ни одного аргумента не привел

(49)Вот мои конкретные опасения:

1)у тебя через некоторое время бухи взвоют. Документооборот увеличился  в три раза =)

2)твой механизм начнет часто ошибаться с ценами в следствии кривой партионки.

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

(49) есть подозрения что ты еще догадался ставить галочку "упр учет" в этих документах. А это еще более усложнит и запутает ситуацию.

(50) все три пункта ниочем

(52) время покажет.

(50)
1) Продажи между организациями - это неизбежный элемент работы. мы без него не сможем, а вот мой механизм его упрощает. Документооборот при этом такой, какой был бы и без механизма.
2) Мой механизм не призван поправить ситуацию с корректировкой задними числами. Он предназначен для оперативного учет внутренних продаж между организациями. Если бы ты оформлял документы "руками", у тебя вылезли бы такие же ошибки, что и в случае с моим механизмом.
3) см.п.2

(54) Какой опреативный учет....? Это прежде всего делается для бухии. Если это не для бухии то тогда он тебе вообще для чего?

(54) он вообще не понимает, зачем с ним спорить? )

(56) результат будет такой как я говорю. Полный хаос в базе через месяц =)

(56) Думал, мож до сотки дожмем :)

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

ЗЫ: кстати обработка, которую ты хвалишь не всем подходит

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

(60) опять слова без оснований

(50) Все-таки интересно, у вас РТУ не корректируются вообще что ли?! Если корректируются документом корректировки, то как вы протаскиваете его в другую организацию, а если не корректируются вообще, то чем же вы торгуете, раз такая благодать?

(62) а смысл делать корректировки между своими организациями?

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

(64) скажи человеку в (60) что все работает, у него пиника и хаос :)

(65) Плохому танцору, как известно... :))

(66) Скинь конфу, посмотрю как и что вы там сделали.

(67) Какую конфу? Возьми УТ или БП типовую.

+(68) А, пардон, перепутал ветку с Организовать 5 мест с доступом к одной базе 1С

(67) С чего бы мне кидать наши доработки тебе? Или ты хочешь купить?

(68) Конфу которую "Недавно сделали одному клиенту чуть в другом виде, сейчас делаем другому в том виде, в котором ты написал.". Хотел посмотреть на твое решение. Возможно у тебя лучшее решение вопроса. Вроде ты опытный прог.  Обмен опытом полезен, у нас же тут сообщество.

(71) Могу на словах написать.
Товар у организации 1.
Продажа от организации 2.
В продаже от организации 2 доделываем опциональное автоматическое формирование документов приход на организацию 2 и реализацию от организации 1.
При изменении продажи от организации 2 ессно меняем и те два документа.
Те два документа менять вручную запрещено.
Дата, проведенность и помеченность на удаление ессно синхронизируются.
Не смог записаться один из двух документов, основная продажа также не записывается.

+(72) Единственный нюанс, на что делать перепродажу, на полный набор или на нехватающий.

(73) Все зависит от способа учета. Если учет по заказам тогда надо смотреть поступление было под этот заказ или без заказа вообще (свободный остаток). Если остаток не свободный - тогда берем все целиком с этого склада/организации, и если этого мало, скребем по сусекам дальше.

(72) Вот нормальная идея полной синхронизации этих документов и запрет их редактирования внутренних перемещений, советую ТС взять на вооружение.

(75) Вот спасибо за совет =)
только я уже и так это сделал давно, распроведение выходной реализации, распроводит все внутренние реализации, поступления, СФ полученные и СФ выданные. Пометка на удаление - аналогично

(76) я ж говорю не догнал ))

(77) но товарищ явно в (54) писал что изменения задним числом его механизм не обрабатывает.

(78) в (54) человек отвечал на твои глупые доводы по поводу работы задним числом

(78) ты слишком много ходишь на совещания, это плохо сказывается..

(79) Можешь ты свой механизм внутренних покажешь раз считаешь меня глупцом?

(0) Лет 5 назад заморачивался с подобным механизмом, еще на ТиС. Тут есть множество подводных камней, которые сразу не видны.
Во-первых, если операторов больше одного, то появляется шанс получить неактуальные остатки при проверке и он повышается с количеством операторов. Всё же остатки надо проверять при проведении, не спрашивая пользователя.
Во-вторых, сдвинутое на секунду время совсем не панацея, особенно когда пользователей больше 1. Все движения по переброске товаров надо формировать при проведении, причем движения по переброске должны быть помечены соответствующим признаком. А если нужно распечатать бумажки по внутренним продажам - сделать отдельные печатные формы, которые печатают только нужные движения, либо печатать пакет документов.
Ну и чтобы окончательно отговорить от этой несуразной задачи (переброски в оперативном режиме) - все пользователи грешат заведением и изменением документов задним числом, при таком раскладе очень высок шанс получить ситуацию, когда вчера документ имел одни движения (которые сформированы на основе актуальных в то время остатков), а сегодня (после ввода другого документа задним числом) документ уже имеет другие движения или вообще не проводится. И кто будет разбираться в таких ситуациях?

Вывод - используйте типовые средства, велосипед уже изобретен. Если не верите - поработайте по такой схеме, посмотрите на ужасающий хаос и предвкушайте всеобщую инвентаризацию)

еще один "гений"

(83) Почитал ветку - Hans всё правильно пишет. Не взлетит.

Прочел все и решил все таки вставить свои 5 копеек. Лично я придерживаюсь мнения, что не взлетит. Все свои соображения я быстро не распишу. Но расскажу некоторые моменты которые реализованы в УТ 11.
Механизм интер-кампаний там есть, основная его суть в том, что документы перемещения между внутренними организациями нифига не оперативный. Более того, есть упрощенный вариант ввода документов передач сводно, за период. Возможно конечно это реализовано исключительно, потому как в УТ 11 используется РАУЗ, а возможно и по каким то другим соображениям.

(82) Всё взлетает! Сколько бы раз задом не перепроводили, восстановление последовательности бы не делали - количество товара в фирме от этого не меняется.

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

(86) Зачем ты с ним споришь?
Он просто говорит, что он не смог, у него не взлетело.
Он же не говорит, что другие не смогут.

(82) (85) А я склоняюсь к (86). Списать товары задним числом не получиться если их там на этот момент нет. Если же распровести продажу (чтобы распровелись и внутренние продажи и остатки вернулись), сделать списание этих товаров, а потом опять провести продажу, то при проверке остатков система сругнется и запретит Вам такой финт. С точки зрения документов и остатков все будет ровно, и пользователям будет все видно и понятно: как говориться утром деньги - вечером стулья ...

(88) ...
Может конечно произойти ситуация, когда будут распроводиться приходные документы на первую в цепочке организацию, ну или например доп.расходы привяжутся позже (хотя это не так страшно если остатки ещё не нулевые, тогда расходы накрутятся на на эти остатки). Но тут я уже писал в (54). Никто от такого не застрахован в каком угодно учете, с механизмом "оперативного подкладывания" и без него. Цель этого механизма - не сделать идеальный учет, в котором не будет дыр сделанных задним числом и прочих непотребств. Цель - упростить механическую работу сотрудников, выписывающих документы. Бонус механизма - снижения уровня человеческого фактора и как следствие снижения количества ошибок в учете.

Простое перемещение уже предлагали?
Какие продажи между своими? Только по себестоимости же вроде должно

(90) А как ты потом в налоговой будешь рассказывать, откуда у твоего юр.лица с непроизводственным ОКВЭДом взялся весь этот товар, которым оно наторговало? Перемещение это документ для перемещения внутри одной организации. Между организациями перемещение не имеет силы

(42) Ещё небольшое  дополнение. Механизьм я разрезал и поместил по другим событиям. Основную часть, где происходит проверка и генерация документов в самое начало ОбработкиПроведения (это сделано для того, чтобы мой код мог обратиться к БД и увидеть что пытаются продать в текущей реализации, в момент когда оператор не записывая документ, проводит его. Ту часть которая распроводит другие доки - поместил в "ОбработкаУдаленияПроведения", а ту которая обрабатывает пометку удаления в "ПередЗаписью".

(92) >> в самое начало ОбработкиПроведения (это сделано для того, чтобы мой код мог обратиться к БД и увидеть что пытаются продать в текущей реализации, в момент когда оператор не записывая документ, проводит его.


По твоей схеме тебе нужно это было пихать в подписку на событие "При проведении". Как ты вычисляешь что нужно сгенерировать если это у тебя в начале обработки проведения? Оттуда у тебя и запросы в километр длинной! =))) Тебе в подписке "Обработка проведения" нужно было смотреть образуется ли отрицательный остаток после продажи или нет по регистру "Товары организаций". И спрашивать у манагера не нужно откуда брать товар. У тебя есть регистр с приоритетами.