Всем привет.
1С:Управление торговлей (11.4.6.188) + 1С:CRM (3.0.14.11)
Есть документ заказ поставщику. Заказ имеет статус "Подтвержден" и уже закрыт.
На основании заказа создано Приобретение товаров и услуг. Оба документа проведенные. Но в регистре сведений ГрафикПоступленияТоваров запись по приобретению все еще висит.
Как удалить эту самую запись? Я так понимаю что она должна удаляться при проведении приобретения, но такого не происходит. Поиск в гугле ни к чему толковому не привел. Прошу помощи.
1С:Управление торговлей (11.4.6.188) + 1С:CRM (3.0.14.11)
Есть документ заказ поставщику. Заказ имеет статус "Подтвержден" и уже закрыт.
На основании заказа создано Приобретение товаров и услуг. Оба документа проведенные. Но в регистре сведений ГрафикПоступленияТоваров запись по приобретению все еще висит.
Как удалить эту самую запись? Я так понимаю что она должна удаляться при проведении приобретения, но такого не происходит. Поиск в гугле ни к чему толковому не привел. Прошу помощи.
Прикрепленные файлы:
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Столкнулись с аналогичной проблемой документы прихода с 10.2019 у нас:
1. Приобретение товаров и услуг,
2. Заказ поставщику,
3. Заказ на сборку (разборку)
Думаю и другие регистраторы по регистру накопления "ГрафикПоступленияТоваров".
Примерно тогда мы обновились на УТ+CRM для РБ 3.0.11.19.
Аналог УТ 11.4.1.
Как итог движения документами сделали остатки. А остатки не покрыты.
1. Приобретение товаров и услуг,
2. Заказ поставщику,
3. Заказ на сборку (разборку)
Думаю и другие регистраторы по регистру накопления "ГрафикПоступленияТоваров".
Примерно тогда мы обновились на УТ+CRM для РБ 3.0.11.19.
Аналог УТ 11.4.1.
Как итог движения документами сделали остатки. А остатки не покрыты.
Похоже нашли визуально в чем проблема.
1. Склад не сделал ордер на что пришло по приобретении.
2. По заказу поставщика товар еще не весь оформили в приобретении.
3. Не указали соглашение в документах.
У нас в основном 3 пункт. Создадим соглашение и перепроведем.
Отпишу по результатам.
1. Склад не сделал ордер на что пришло по приобретении.
2. По заказу поставщика товар еще не весь оформили в приобретении.
3. Не указали соглашение в документах.
У нас в основном 3 пункт. Создадим соглашение и перепроведем.
Отпишу по результатам.
Вот решение проблемы:
1. Подтвердить ордером, что товар пришел. Если товар потеряли, то до оформить и составить недостачу.
2. Если товар еще не пришел, то пропускаем. Если товар не придет, то уменьшить количество в заказе и провести заказ.
3. Создать соглашение для поставщика и указать его во всех документах.
4. Указать назначение в заказе поставщика и перепровести документы.
1. Подтвердить ордером, что товар пришел. Если товар потеряли, то до оформить и составить недостачу.
2. Если товар еще не пришел, то пропускаем. Если товар не придет, то уменьшить количество в заказе и провести заказ.
3. Создать соглашение для поставщика и указать его во всех документах.
4. Указать назначение в заказе поставщика и перепровести документы.
По 3 пункту у нас возникли проблемы.
1. Меняем соглашение в заказе поставщика групповой обработкой, руками слетают реквизиты, приходится многое менять.
2. Меняем соглашение в приобретении товаров и услуг групповой обработкой, руками слетают реквизиты, приходится многое менять.
3. Меняем признак "ЗакрыватьГрафикПоступления" в приходных ордерах на документ из п. 2 групповой обработкой, но лучше перевыбрать руками распоряжением, главное указать корректное, т.к. выполняется такой код:
1. Меняем соглашение в заказе поставщика групповой обработкой, руками слетают реквизиты, приходится многое менять.
2. Меняем соглашение в приобретении товаров и услуг групповой обработкой, руками слетают реквизиты, приходится многое менять.
3. Меняем признак "ЗакрыватьГрафикПоступления" в приходных ордерах на документ из п. 2 групповой обработкой, но лучше перевыбрать руками распоряжением, главное указать корректное, т.к. выполняется такой код:
&НаСервере
Процедура РаспоряжениеВыборСервер(СкладскаяОперация)
Если СкладскаяОперация <> Объект.СкладскаяОперация Тогда
Объект.СкладскаяОперация = СкладскаяОперация;
ПодготовитьЗаполнитьУстановитьВидимостьСерий();
КонецЕсли;
Если ЗначениеЗаполнено(Объект.Распоряжение) Тогда
Если ТипЗнч(Объект.Распоряжение) = Тип("СправочникСсылка.СоглашенияСКлиентами")
Или ТипЗнч(Объект.Распоряжение) = Тип("СправочникСсылка.ДоговорыКонтрагентов") Тогда
Объект.ЗакрыватьГрафикПоступления = Истина;
Иначе
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| ДвижениеТоваров.Распоряжение КАК Распоряжение
|ИЗ
| РегистрНакопления.ДвижениеТоваров КАК ДвижениеТоваров
|ГДЕ
| ДвижениеТоваров.Распоряжение = &Распоряжение";
Запрос.УстановитьПараметр("Распоряжение", Объект.Распоряжение);
Объект.ЗакрыватьГрафикПоступления = Не Запрос.Выполнить().Пустой();
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Показать
(9) вначале я перевыбрал не то распоряжением и запрос приходного ордера не формировал движений по "РегистрНакопления.ДвижениеТоваров".
После того как указал верное распоряжение признак "ЗакрыватьГрафикПоступления" стал истина, движения сформировались.
И тогда регистр накопления "ГрафикПоступленияТоваров" очистился по записям указанным в ордере.
Если несколько ордеров, нужно повторить для каждого.
После того как указал верное распоряжение признак "ЗакрыватьГрафикПоступления" стал истина, движения сформировались.
И тогда регистр накопления "ГрафикПоступленияТоваров" очистился по записям указанным в ордере.
Если несколько ордеров, нужно повторить для каждого.
Сегодня наткнулся на эту фишку в УТ 11. Хотелось бы спросить у фирмы 1С, но скорее всего ответа не получу, поэтому вопрос сообществу:
При отмене проведения одного документа появляются движения по регистру у другого документа.
Это теперь считается хорошим стилем в программировании? Нужно опять перестраивать перестраивать своё сознание?
На прежних версиях был определенный шаблон изучения поведения системы. Провел документ - посмотрел какие движения появились, отменил проведение - посмотрел какие исчезли. Теперь при проведении может произойти всё что угодно.
При отмене проведения одного документа появляются движения по регистру у другого документа.
Это теперь считается хорошим стилем в программировании? Нужно опять перестраивать перестраивать своё сознание?
На прежних версиях был определенный шаблон изучения поведения системы. Провел документ - посмотрел какие движения появились, отменил проведение - посмотрел какие исчезли. Теперь при проведении может произойти всё что угодно.
(11)
Вы подняли очень больной, и к сожалению, практически риторический вопрос (учитывая то, как в 1С поставлен вопрос обратной связи)...
На мой взгляд БСП - это вообще пример нехорошего стиля в программировании, а ERP - худшая конфигурация за всю историю 1С.
Теперь при проведении может произойти всё что угодно.
Вы подняли очень больной, и к сожалению, практически риторический вопрос (учитывая то, как в 1С поставлен вопрос обратной связи)...
На мой взгляд БСП - это вообще пример нехорошего стиля в программировании, а ERP - худшая конфигурация за всю историю 1С.
Коллеги вот решение (суть его уже описана выше, я предлагаю развернутое решение):
Система обеспечения товарами в ERP подобных конфигурациях сложна и запутана. Разораться в ней - тема для диссертации. Стремясь сделать ее универсальной, компания 1С сделала ее практически не употребимой.
Один 100500 регистров в этом страшном оркестре - регистр накопления ГрафикПоступленияТоваров.
В моей организации используется:
- соглашения и договора;
- клиенты и контрагенты;
- несколько складов;
- два из них ордерные;
- используются статусы заказов (всех: Покупателей, Поставщикам, Перемещения);
- порядок ввода документов установлен "Заказ - Ордер - Накладная";
- ордер создается Менеджером.
При таких настройках логика проведения грубо следующая (подчеркиваю, именно при таких. За другие сказать не могу):
1 При проведении Заказа поставщику в регистр накопления ГрафикПоступленияТоваров делаются приходные движения;
2 При проведении Приходного ордера по этому заказу движения сделанные заказом удаляются;
п. 2 выполняется только в случае, если в Приходном ордере включен скрытый (его нет на форме) флаг ЗакрыватьГрафикПоступления. Флаг выставляется в Истину при перевыборе распоряжения, в процедуре РаспоряжениеВыборСервер(СкладскаяОперация) модуля формы Приходного ордера.
Проблема в том, что эта процедура не вызывается при создании нового документа (что является очередной ошибкой в EPR), поэтому для нового документа флаг всегда по умолчанию Ложь, что и вызывает симптомы описанные выше.
Решение следующее:
1 Если у Вас конфигурация находится на поддержке - после создания ордера перевыбирать распоряжение (заказ поставщику) (это решение описано выше)
2 Если конфигурация снята с поддержки, то в модуль формы необходимо добавить процедуру
и вызвать ее в процедуре ПриСозданииНаСервере
Напоследок руки чешутся поглумиться над разработчиками ERP:
В конфигурации распоряжением называется документ-основание Расходного или Приходного ордера (Заказ поставщику в данном случае).
Но суть ордерного учета заключается в том, что офис создает Расходные или Приходные ордера на склад, а склад отгружает или принимает товары, указанные в ордерах.
Вот выдержка из вики:
"Распоряжение - это акт или приказ, имеющий обязательную силу для лиц, которым оно адресовано".
т.е Офис создаёт "Распоряжения" складу принят или отгрузить что то, а склад эти распоряжения выполняет.
Таким образом гораздо логичнее было бы распоряжением назвать Ордер, а заказ покупателя (в контексте ордера) - основанием этого ордера.
Но как я у же говорил, с логикой в ERP не густо...
Система обеспечения товарами в ERP подобных конфигурациях сложна и запутана. Разораться в ней - тема для диссертации. Стремясь сделать ее универсальной, компания 1С сделала ее практически не употребимой.
Один 100500 регистров в этом страшном оркестре - регистр накопления ГрафикПоступленияТоваров.
В моей организации используется:
- соглашения и договора;
- клиенты и контрагенты;
- несколько складов;
- два из них ордерные;
- используются статусы заказов (всех: Покупателей, Поставщикам, Перемещения);
- порядок ввода документов установлен "Заказ - Ордер - Накладная";
- ордер создается Менеджером.
При таких настройках логика проведения грубо следующая (подчеркиваю, именно при таких. За другие сказать не могу):
1 При проведении Заказа поставщику в регистр накопления ГрафикПоступленияТоваров делаются приходные движения;
2 При проведении Приходного ордера по этому заказу движения сделанные заказом удаляются;
п. 2 выполняется только в случае, если в Приходном ордере включен скрытый (его нет на форме) флаг ЗакрыватьГрафикПоступления. Флаг выставляется в Истину при перевыборе распоряжения, в процедуре РаспоряжениеВыборСервер(СкладскаяОперация) модуля формы Приходного ордера.
Проблема в том, что эта процедура не вызывается при создании нового документа (что является очередной ошибкой в EPR), поэтому для нового документа флаг всегда по умолчанию Ложь, что и вызывает симптомы описанные выше.
Решение следующее:
1 Если у Вас конфигурация находится на поддержке - после создания ордера перевыбирать распоряжение (заказ поставщику) (это решение описано выше)
2 Если конфигурация снята с поддержки, то в модуль формы необходимо добавить процедуру
&НаСервере
Процедура УстановитьЗакрыватьГрафикПоступления()
Если ЗначениеЗаполнено(Объект.Распоряжение) Тогда
Если ТипЗнч(Объект.Распоряжение) = Тип("СправочникСсылка.СоглашенияСКлиентами")
Или ТипЗнч(Объект.Распоряжение) = Тип("СправочникСсылка.ДоговорыКонтрагентов") Тогда
Объект.ЗакрыватьГрафикПоступления = Истина;
Иначе
УстановитьПривилегированныйРежим(Истина);
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| ДвижениеТоваров.Распоряжение КАК Распоряжение
|ИЗ
| РегистрНакопления.ДвижениеТоваров КАК ДвижениеТоваров
|ГДЕ
| ДвижениеТоваров.Распоряжение = &Распоряжение";
Запрос.УстановитьПараметр("Распоряжение", Объект.Распоряжение);
Объект.ЗакрыватьГрафикПоступления = Не Запрос.Выполнить().Пустой();
КонецЕсли;
КонецЕсли;
КонецПроцедуры Показатьи вызвать ее в процедуре ПриСозданииНаСервере
Напоследок руки чешутся поглумиться над разработчиками ERP:
В конфигурации распоряжением называется документ-основание Расходного или Приходного ордера (Заказ поставщику в данном случае).
Но суть ордерного учета заключается в том, что офис создает Расходные или Приходные ордера на склад, а склад отгружает или принимает товары, указанные в ордерах.
Вот выдержка из вики:
"Распоряжение - это акт или приказ, имеющий обязательную силу для лиц, которым оно адресовано".
т.е Офис создаёт "Распоряжения" складу принят или отгрузить что то, а склад эти распоряжения выполняет.
Таким образом гораздо логичнее было бы распоряжением назвать Ордер, а заказ покупателя (в контексте ордера) - основанием этого ордера.
Но как я у же говорил, с логикой в ERP не густо...
Если кто будет искать. В модуле менеджера, регистра ДвижениеТоваров. Процедура: РассчитатьИтогиРегистраОстаткиТоваровПоГрафику
Очень тугой механизм. У меня ордера старые, еще до включения ячеистого склада. В ордерах нет помещения и перепроводить их, возможности нет. Удалил записи регистра и заплатку написал, чтобы движение не записывалось в график, по старым документам.
Очень тугой механизм. У меня ордера старые, еще до включения ячеистого склада. В ордерах нет помещения и перепроводить их, возможности нет. Удалил записи регистра и заплатку написал, чтобы движение не записывалось в график, по старым документам.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот