Что имеется: дистрибьюторская компания, продажи ведутся со склада. Система - УТП.
Рабочий процесс: с КПК агентов в базе формируется документ реализации. Оператор его проводит и, распечатав, передает на сборку на склад. Доставка должна происходить минимум на следующий день, максимум через 2 силами компании. Вечером каждого дня формируются НН на все документы реализации этого дня. Корректировки можно вводить в течении 5 дней с дня создания, потом период закрывается.
Описание проблемы: По разным причинам в реальности клиент с момента формирования заказа в базе до момента его получения может ждать доставку около недели. Однако, как мы помним, документ реализации создан в день заявки, т.е., отчет по дебиторке покажет на момент получения товара недельную задолженность, хотя по договоренности мы , например, даем 2 недели отсрочки.
В качестве варианта решения предлагали перепроводить документ реализации. Однако, при таком подходе НН будет выписана ранее, чем сам документ, а если и его перепроводить, то нарушится порядок нумерации... Да и в 5 дней не всегда можно вписаться...
Предложен был и вариант с резервом, но невнимательный менеджер может провести его дважды, контроля в программе нет - потом все это разгребать желания нет никакого...
Что посоветуете или как это делается у вас?

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

Вы очень остроумны, возможно с присущим вам юмором вы скажете еще откуда этот отчет возьмет дату реальной доставки?

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

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


В договоре есть реквизит - держать резерв без оплаты (к-во дней). В "Закрытии заказов покупателей" можно подобрать просроченные заказы. Менеджер закрывает заказы раз в сутки (просроченные, неоплаченные, ошибочно введенные). Или повесить на регламентное задание.

Повторное проведение реализации резерв не удвоит. ЕЕ мы должны распечатать и доставить клиенту с товаром - т.е. ДО отгрузки.
Если есть отказ клиента при доставке, то производится возврат с выпиской корректировки к НН или исправление если менее 5 дней. Если полностью отказ - то полный возврат.

С резервом свои прелести - 1С раскидывает резерв по размещению на все склады где есть остатки этой позиции. У нас 1 склад на 1 город, отгрузка 1 клиента с более чем 1 склада не предусмотрена.
Теперь представим. что в КПК не свежие остатки - торговый забыл обновить и вывел не корректные кол-ва в документ Заказ покупателя.
Оператор жмет Заполнить и провести с целью зарезервировать, дабы в день доставки распечатать док-Вы Реализации на основании. Но остатки не корректные - факт меньше чем в заявке и программа разбивает строки по складам. Если не хватает на всех доступных складах с этим товаром, она просто в строке не заполняет размещение. А теперь представим, что таких строк около 100. Сколько же править нужно такой документ?

Я тут еще рассматривал такую штуку как Группы доступности складов. но корректной работы так и не добился...

Можно подробнее?
1. Каким образом фиксируется в системе факт реальной отгрузки товара? Склад автоматизирован?
2. Какая необходимость вводить документ реализации вместо заказа?

1. склад не автоматизирован. В системе пока это не фиксируется. Факт реальной отгрузки планирую фиксировать в виде присвоения даты свойству ДатаПоставки документу реализации
2. документ реализации напрямую влияет на актуальность остатков, в отличие от документа заказа

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

Ордерная система, не?

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

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

Моделируем типичную хронологию:

Заказ-Резерв-День_отгрузки-Реализация-Реальная_поставка

Так вот, предположим, что мы отправляем клиенту товар почтой, вроде как интернет-магазины.
От дня выписки РН (Реализация) до момента получения легко может пройти 3-4 дня. Отсюда вопрос - зачем лишние телодвижения с заявками-резервами?

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

П.С.
Кстати, мельком видел УТ для Укр. 3 версии - там есть статусы документов, возможно и дебиторка считается от статуса "доставлен" - не слыхали?

У вас проблемы, причем явно не с программой.

Вот с таких примерно слов бардак и начинается. Документ - эквивалент события в реальности. Все остальное - от лукавого.
У Вас док Реализация используется там, где место ЗаказуПокупателя.
О каких фактических остатках речь, если товар находится на складе неделю после выписки РН?
Не боитесь, что привезете товар в "пустой склад" - а его туда впихнуть некуда будет?
"Задвоениея резерва" - вообще страшилка какая-то резервируйте Заказом, нпр

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

Та ладно, неужели так часто товар в "0" распродается??? Это, все-таки, дистрибьютор или просто оптовая торговля "чем получится"?
Похоже, Вы просто защищаете "статус кво" - потому и доступность складов тестировали, чтобы отвергнуть.
У Вас в системе заказа покупателя либо нет вообще либо он уже выполнен. Пока не приведете "картинку" в соответствие с реальностью - вас будет трясти то так то этак.
...

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

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