Заказчик попросил написать обработку по объединению документов "Реализация товаров услуг" в один итоговый документ, в процессе выполнения получилось 2 обработки.
Файлы
ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
0% комиссии — оплата напрямую исполнителю;
Исполнители любого масштаба — от отдельных специалистов до команд под проект;
Прямой обмен контактами между заказчиком и исполнителем;
Безопасная сделка — при необходимости;
Рейтинги, кейсы и прозрачная система откликов.
Заказчик попросил написать обработку по объединению документов "Реализация товаров услуг" в один итоговый документ, предложение о том, что можно выписать на все документы реализации Счет-Фактуру и ее печатать как итоговый УПД, развития не получило. Как говорится, "Хозяин -> Барин", получилась обычная обработка для интеграции в подсистему "Дополнительные отчеты и обработки" с видом "ВидОбработкиДополнительнаяОбработка" командой "ТипКомандыОткрытиеФормы", попутно родилась еще обработка с видом "ВидОбработкиЗаполнениеОбъекта" командой "ТипКомандыВызовКлиентскогоМетода".
Несмотря на то, что код модуля обработок идентичен, за исключением функции "СведенияОВнешнейОбработке", для себя с удивлением обнаружил, что 2-ая обработка проще в реализации (для программиста меньше кода), более логична и понятна. Понятно, что там и там есть плюсы и минусы (для пользователя, администратора и т.д.), а каково Ваше мнение на этот счет?
Проверено на следующих конфигурациях и релизах:
Управление торговлей, редакция 11, релизы 11.5.12.195, 11.5.12.167
Infostart MagicInput улучшает подбор в полях ввода 1С: ищет по любой части названия и по нескольким ключевым фрагментам, распознаёт ввод в другой раскладке и показывает иконки/статусы объектов прямо в списке. Поддерживает вставку навигационной ссылки/представления документа для автоподбора; для разработчиков доступны поиск по GUID и полному имени предопределённого. Работает в управляемых формах и подключается в большинстве конфигураций 1С 8.3/8.5. Работает на возможностях платформы, внешние компоненты не используются.
1.обработка позволяет автоматически вычислить дубли и привести их к единому наименованию во всех документах.
2.так же есть возможность в документах поменять счета учета для номенклатуры. Например разные бухгалтера оформляют поступление одного и того же товара - один занес на 10.01, второй на 41.01 в результате в ОСВ у нас минусы. В обработке есть возможность наглядно увидеть такие ошибки и тут же их поправить не бегая по всем документам. Достаточно поставить галочку у номенклатуры и указать счет учета который надо найти и счет учета на который надо его заменить. Обработка сама вычислит документы в которых номенклатура с галочкой была задействована и заменит счета учета. Что бы не было излишнего изменения документов, в обработке указываются типы документов, где операция замены счета разрешена (например Поступление ТМЦ, Реализация, Отчет о розничных продажах, возврат покупателю итд.)
Данная обработка предлагается для случаев, когда бывает необходимо изменить какой-либо реквизит в группе проводок, отобранных по определенному набору полей, за определенный период, с определенным типом документа-регистратора. Предлагается четыре варианта обработки для конфигураций: БП 2.0, БП 3.0, БГУ 1.0, БГУ 2.0.
Обработка «Сравнение документов» — это мощный инструмент для синхронизации и контроля данных между базами 1С:УНФ – 1С:БП, 1С:УТ – 1С:БП. Она позволяет сравнивать документы в двух базах, выявлять расхождения и загружать недостающие документы из одной базы в другую.
Данная обработка может быть полезна тем, кто хочет сделать более точечную замену объектов, когда заказчику необходимо заменить что-то только в определенном виде документа (справочника) с определенным отбором по реквизитам.
Поиск номенклатуры при сопоставлении в ЭДО не интуитивный, не настраиваемый и просто неудобный. Данное решение - это альтернативный вариант расширенного поиска и сопоставления номенклатуры для 1С, который подключается в качестве расширения и решает эту проблему.
а Заказы, как будут выглядить ? если было два Заказа и документы "Реализация товаров услуг" объединены, то кому, какому Заказу будет подчинен финальный документ.
(1) В дополнение к написанному:
1. Обработка корректно отрабатывает ситуацию с группами складов, т.е. если документ назначение имеет склад-группу то возможен подбор из реализаций с складов входящих в эту группу
2. Должны корректно переноситься все строки с отгрузкой по заказам из исходных документов (в т.ч. если заказы закрываются то при объединении документов они также должны закрываться.)
3. Должно корректно переноситься все что связано с номенклатурой (т.е. характеристики серии и т.д.)
Во всяком случае при тестировании проблем не видел.
Хуже дело обстоит если в базе используется RLS, таких тестов не проводилось задачи не стояло, да как представляется маловероятно, что может возникнуть потребность в таких обработках. В общем что есть то есть.
(1) В объединенном документе будет столько заказов по скольким сделаны исходные документы, сами обработанные документы реализации будут помечены на удаление, (если разрешено их редактирование и не сформирована счет-фактура, иначе обрабатываться не будут)
хорошо, а на примере можно показать, что два документа перед объединением имеют разные Заказы, а при создании объединеного в табличнойчасти видно эти Заказы.
