"Создание на основании" для 1С: Бухгалтерии 3.0

0. 3 15.07.22 17:48 Сейчас в теме
Обработка для 1С: Бухгалтерии 3.0 позволяет создать новый документ, копируя выбранные данные из любого документа базы, не внося изменений в типовой код конфигурации. При отсутствии программного соответствия между реквизитами одного документа-источника и документа-приемника, вы можете подобрать их сами или поставить в поле нужное значение.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. RustIG 03.08.22 09:46 Сейчас в теме
как узнать, что док уже создан на основании другого ?
2. the1 1125 03.08.22 11:26 Сейчас в теме
(1) Структура подчиненности? Хотя мне кажется, обработка не для этого
3. RustIG 03.08.22 12:10 Сейчас в теме
(2) да, она самая.
как тогда избежать дублирования документов? бухгалтер как будет понимать - какие документы уже созданы на основании других?
4. the1 1125 03.08.22 12:31 Сейчас в теме
(3) Я бы сделал так: сначала
НовыйДокумент.Заполнить(ДокументОснование)
, а потом переносил бы реквизиты из основания обработкой. Но беда в том, что не все документы могут быть основанием друг друга
5. RustIG 03.08.22 12:55 Сейчас в теме
(4) да у меня решен этот вопрос...
прикладываю скрин - это Бп 3.0
через расширения доработал списки документов - добавил структуру подчиненности в списки, плюс в нужные документы добавил поле ДокОснование, доработал процедуру Заполнения... Даже если в документах разные организации и разные табличные части...
Прикрепленные файлы:
6. the1 1125 03.08.22 15:45 Сейчас в теме
(5) Это хорошо) Но просто обработкой такого не сделаешь, увы
7. RustIG 03.08.22 15:47 Сейчас в теме
(6) обработка - это наполовину решенная задача, я задал вопрос-направление для решения второй половины...
9. the1 1125 03.08.22 15:58 Сейчас в теме
(7) Просто я тоже решал подобную задачу, но как и у ТС у меня она не решена. Пока на паузу поставил, может с развитием платформы можно будет обойтись без расширений, чтобы отслеживать структуру подчиненности.
10. RustIG 03.08.22 16:14 Сейчас в теме
(9) до внедрения расширений я использовал уникальный идентификатор, записывал его в Комментарий - по нему определял соответствие Источника и Приемника - в некоторых работах до сих пор использую такой способ.
Через уник.идент. источника можно выводить структуру подчиненности документов.
11. RustIG 03.08.22 16:29 Сейчас в теме
(9) вот пример использования уникального идентификатора https://infostart.ru/public/1014031/

пример построения и использования дополнительной связи в структуре подчиненности для требований-накладных вот тут https://infostart.ru/public/1238873/

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

не знаю,но хотел бы знать, насколько это интересно пользователям?!
12. the1 1125 03.08.22 22:55 Сейчас в теме
(11) Думаю, это перспективно. Хорошая мысль)

П.С. Возьму на вооружение )
13. the1 1125 03.08.22 22:57 Сейчас в теме
(11) А как из ГУИДа получить ссылку не зная ее типа? Не перебором же?
14. RustIG 04.08.22 10:14 Сейчас в теме
(13) вы задали хороший вопрос!

мне придется очень много написать , чтобы высказать пару мыслей:
1) когда мы получаем Гуид документа или справочника (Да-да, справочники тоже можно в структуре подчиненности отображать, да и любые объекты - которые по смыслу подходят вам), у нас имеется две единицы информации: тип документа и ссылка на документ. Чтобы информация не потерялась, нам по уму надо хранить тип документа и полученный гуид.
Вариантов много как это хранить. Самый первый, который приходит в голову: "Гуид, ТипДокумента" - через запятую строкой в комментарии.
При обратной операции раскладываем в массив строку - тип берем из второго элемента, гуид из первого элемента массива...
Когда вы программируете отображение структуры подчиненности для определенного Источника и Приемника (не для универсальных комбинаций), вы заранее уже знаете, что согласно вашему бизнес-процессу Источник связан с Приемником, то есть вы заранее знаете какие типы документов участвуют в связях - тогда в таком случае, хранить ТипДокумента не надо - в моих обработках как раз используется такой сценарий - я программно ищу в нужных типах нужную ссылку.
2) По поводу "Не перебором же?" - ничего плохого в полном переборе нет, аргументы ниже:
во-первых, вы могли бы использовать полный перебор реквизитов и реквизитов табличных частей для получения точных связей между реквизитами Источника и Приемника - я полный перебор реквизитов использую в своих работах https://infostart.ru/public/1316682/ и https://infostart.ru/public/1610508/
во-вторых, полный перебор метаданных использован в следующей моей работе по анализу прав и ролей https://infostart.ru/public/1565697/
полный перебор узлов для построения json-структуры дерева https://infostart.ru/public/1573208/
полный перебор всех ячеек склада для построения карты склада https://infostart.ru/public/1551346/
Но полный перебор всех типов документов для универсального окна структуры подчиненности - думаю, делать не нужно - это будет "перебор" не только в программном смысле, но и в бытовом.
Для этой задачи нужно использовать дополнительные средства: предварительный анализ взаимосвязей типов реквизитов подстройка под конкретный известный ваш бизнес-процесс (типовой или ваш нетиповой), хранение вспомогательной информации в допреквизитах (которые заполняются при записи документа)...
Для меня "универсальный" - это всегда компромисс между допущениями и ограничениями. Даже сейчас типовая структура подчиненности использует объект КритерийОтбора - который заранее прошит определенными типами документов, поэтому типовая структура подчиненности не может считаться и использоваться как "универсальная" - надо дорабатывать в сторону своих известных бизнес-процессов. Я это вижу примерно так: вы знаете что у вас на основании Источника создается Приемник. В окне структуры подчиненности вставляем два поля сверху Источник слева, Приемник справа.
Снизу список документов Источника.
Теперь система знает, что кроме стандартной структуры подчиненности надо проверять и искать среди Приемников нужный документ, соответствующий Гуиду из комментария... как-то так...
15. the1 1125 04.08.22 12:39 Сейчас в теме
(14) Спасибо, будет над чем подумать)
8. RustIG 03.08.22 15:49 Сейчас в теме
(6) до внедрения расширений я использовал уникальный идентификатор, записывал его в Комментарий - по нему определял соответствие Источника и Приемника - в некоторых работах до сих пор использую такой способ
Оставьте свое сообщение
Вакансии
Программист 1С
Екатеринбург
зарплата до 150 000 руб.
Полный день

Разработчик 1С
Новосибирск
зарплата от 200 000 руб.
Полный день

Разработчик 1С
Санкт-Петербург
зарплата от 130 000 руб. до 170 000 руб.
Временный (на проект)

Программист, аналитик, эксперт 1С
Санкт-Петербург
По совместительству

Ведущий разработчик 1С (техлид внутреннего учета)
Новосибирск
зарплата от 230 000 руб.
Полный день