Учет недопоставок в 1С8 УТ #359482

Ситуация какая, необходимо иметь управленческий учет по недопоставкам. Как было в 1С 7.7 самописной конфе : Документ "Поставка" - бумажки(план) Документ "Приходная накладная" - факт, так вот здесь может выявится недопоставка и соответственно делался на основании документ "Корректировка поставки" со статусами поставки  в строках ТЧ "выставлено" - когда мы отправили Торг-2 на согласование поставщику, "признано" когда получили согласие о признании недопоставки и соответствующие движения по регистрам Есть ли возможность в типовой УТ 8.1 сделать аналогичные манипуляции вместе с отчетами ?

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

+ и Ведомость по заказам поставщикам. Короче - учите матчасть.

Не то, 1. нельзя автоматом сделать Заказ поставщику на основании Поступления (не суть) 2. мне не то надо, зачем мне делать заказ поставщику товара, который мне  недопоставили - это обычный заказ ,а не претензия

Переведи п.2 на русский язык.

Ты заводишь ЗаказПоставщику. этим намерение фиксируется - от него получить что-то. На основании ЗаказПоставщику заводишь ПТиУ. а отчетом будешь смотреть - скольно намеревались%сколькоПолучилиПоФакту.

ппц. ЖЕСТЬ!

есть план ,есть факт - ДЛЯ КРУПНЫХ КОМПАНИЙ вот по плану Документ допустим "Виртуальная поставка" от 01.08.08.(то есть допустим документы на руках сопроводительные или вообщем не суть) Далее делаем документ "Поступление товаров и услуг" - реальное поступление, да или одним документом это делать , не суть главное на руках документы на одно количество, по факту - другое. Хочется своеобразный CRM по правильным коиентам иметь

если связка без заказа поставщику вначале ?

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

Батенька, не нужно гнуть пальцы с КРУПНЫМИ предприятиями. Уверяю, что многие их присутствующих работают с такими объемами, что бюджет вашего КРУПНОГО предприятия равен бюджету их ИТ-отдела. При этом они не растопыривают пальцы и не считают себя пупами Земли. На ваши виртуальные поставки нужно виртуальные приходы для получения виртуальной прибыли и соответственно виртуальной зарплаты программеру. Вам не "своеобразный CRM" иметь нужно, а нужно иметь нормальное понимание процесса. Иначе процесс будет иметь вас. А посему - откинем пальцы и начнем думать. Для начала - недопоставка является разницей между заказанным и полученным фактически товаром. Отсюда для получения информации о недопоставке нужно знать ассортимент и количество заказанного товара и ассортимент и количество полученного для их последующего сравнения и определения этой разницы. Заказанное количество в УТ отражается заказами поставщику. Полученное - поступлением товаров и услуг. Разница между ними и есть недопоставка. Недопоставка закрывается либо корректировкой, либо закрытием заказа (последний прозрачнее, в нем можно указать причину закрытия и анализировать ее отчетами). Строить отчеты по неким виртуальным данным ни одна известная мне система не умеет.

Согласен, с крупными предприятиями загнул, но все равно есть смысл, так как мы закупаем очень много и проблем с недопоставками предостаточно. Это все понятно, но все равно немного не то, мне необходим претензионный(статусы например "Выставлена претензия поставщику", "Признание претензии поставщиком" здесь два варианта товаром или деньгами додадут, "Отказ от признания претензии поставщиком") блок с учетом недопоставок. По моему в был уклон на это. С заказом поставщику я могу играться и корректировать его, а где учет по статусам недопоставок-претензий. Пример : Наша фирма Ф купила у контрагента К товар 100 штук,оплатила его. Допустим сначала сделали "Заказ поставщику" на 100 шт. Далее оформляем "Поступление товаров" на 90 штук. Далее необходимо вести учет недопоставленного товара по претензиям и что делать - да ничего, получается просто анализировать корректировки заказа поставщику и то без необходимой аналитики, естественно попытка подогнать типовую конфу под этот бизнес-процесс не увенчается успехом.

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

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

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