Идеи и методы для доработок стандартного механизма коменклатуры контрагентов УТ 10.3
Возникла задача продумать подобный механизм загрузки из файлов Екселя (прочих источников) хорошо еще только номенклатуры поставщиков (про конкурентную разведку в УТ 10.3 уже молчу, хотя сейчас с учетом кризиса она стала актуальной). Просматриваю справку и возможности типового механизма. Необходимо хотя бы по-минимуму формировать документы заявок поставщика в ИХ системе учета (по их кодам-артикулам-наименованиям и, может, их отгрузочных единицах измерения). Вернее обеспечить двусторонюю связь с десятком поставщиков с периодической подгонкой-сопоставлением номенклатуры.
Понимаю, что на подобные механизмы и доработки (все стандартное знать и посмотреть конечно нужно, чтоб выжать все по-максимуму без изменения конфигурации, но все-таки.
Что можно в данной схеме предумать с методологической точки зрения. Какие пользователям (которые совмещают в себе несколько профессий) нужны функции по данной подсистеме?
Понимаю, что на подобные механизмы и доработки (все стандартное знать и посмотреть конечно нужно, чтоб выжать все по-максимуму без изменения конфигурации, но все-таки.
Что можно в данной схеме предумать с методологической точки зрения. Какие пользователям (которые совмещают в себе несколько профессий) нужны функции по данной подсистеме?
Найденные решения
(2) kostyaomsk,
Тихо-тихо-тихо! не надо паники )) нифига это не "своя", это вполне себе ваша номенклатура) а вот в ресурсах да, как раз указания на реквизиты номенклатуры контрагента.
Основной подводный камень - это когда контрагент вдруг изменит ранее зафиксированную в вашем регистре номенклатуру или две номенклатуры контрагента - для вас будут являться одной. Тут как раз методологию и поменять! Но начнем строить велосипед сначала:
Методология (бюджетом на 10 часов, простая, а значит эффективная):
условия внешние:
1. Контрагенты предоставляют накладные и желательно прайсы в электронном виде (ексель однако, куда без него)
Условия внутренние:
1. Обработка загрузки накладных в документ поступления с конвертацией номенклатур: из номенклатуры контрагента в вашу.
Обработка позволяет помимо автоподстановки еще и вручную проставлять соответствия
2. Регистр сведений: измерения - контрагент, НаименованиеНоменклатурыКонтрагента, ПрочиеРеквизитыНоменклатурыКонтрагента(артикул, его код, характеристики и тд)
ресурсы - ВашаНоменклатура, ЕеХарактеристика, ЕслиНадоТоЕщеЧеНить
3. Обработка печати заказа поставщику в его номенклатуре
4. Обработка загрузки прайсов в регистр
Работать велосипед будет так:
пришел прайс - грузим в регистр.
пришла накладная - грузим в ТЧ обработки, проверяем автоподстановку из регистра, отсутствующие соответствия проставляем лапами операторов и тут же регистрируем соответствия в регистре. Все сбацали - тащим в документ поступления из ТЧ обработки нашу номенклатуру
Нада заказывать - Собираем заказ в нашей номенклатуре, печатаем в номенклатуре поставщика, отправляем ему.
Финита однако) кажись даже меньше чем на 10 получилось))
ЗЫ. Собрано на коленке) Сильно не ругаться! это не финальное решение и даже не Бета версия)))
И, главное, подводный камень то в том, что в нем измерение номенклатура это СВОЯ номенклатура.
Тихо-тихо-тихо! не надо паники )) нифига это не "своя", это вполне себе ваша номенклатура) а вот в ресурсах да, как раз указания на реквизиты номенклатуры контрагента.
Основной подводный камень - это когда контрагент вдруг изменит ранее зафиксированную в вашем регистре номенклатуру или две номенклатуры контрагента - для вас будут являться одной. Тут как раз методологию и поменять! Но начнем строить велосипед сначала:
Методология (бюджетом на 10 часов, простая, а значит эффективная):
условия внешние:
1. Контрагенты предоставляют накладные и желательно прайсы в электронном виде (ексель однако, куда без него)
Условия внутренние:
1. Обработка загрузки накладных в документ поступления с конвертацией номенклатур: из номенклатуры контрагента в вашу.
Обработка позволяет помимо автоподстановки еще и вручную проставлять соответствия
2. Регистр сведений: измерения - контрагент, НаименованиеНоменклатурыКонтрагента, ПрочиеРеквизитыНоменклатурыКонтрагента(артикул, его код, характеристики и тд)
ресурсы - ВашаНоменклатура, ЕеХарактеристика, ЕслиНадоТоЕщеЧеНить
3. Обработка печати заказа поставщику в его номенклатуре
4. Обработка загрузки прайсов в регистр
Работать велосипед будет так:
пришел прайс - грузим в регистр.
пришла накладная - грузим в ТЧ обработки, проверяем автоподстановку из регистра, отсутствующие соответствия проставляем лапами операторов и тут же регистрируем соответствия в регистре. Все сбацали - тащим в документ поступления из ТЧ обработки нашу номенклатуру
Нада заказывать - Собираем заказ в нашей номенклатуре, печатаем в номенклатуре поставщика, отправляем ему.
Финита однако) кажись даже меньше чем на 10 получилось))
ЗЫ. Собрано на коленке) Сильно не ругаться! это не финальное решение и даже не Бета версия)))
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Детальный анализ Стандартной УТ 10.3 готоврит что:
1. Регистр НоменклатураКонтрагентов используется в:
Объект "РегистрСведений.НоменклатураКонтрагентов" использован в:
Подсистема.УправлениеЗакупками.Состав
ПланОбмена.ОбменУправлениеПредприятиемУправлениеТорговлей.Состав
ПланОбмена.ОбменУправлениеПредприятиемУправлениеТорговлейФоновый.Состав
ПланОбмена.Полный.Состав
Справочник.Номенклатура.Справка
Справочник.Номенклатура.Форма.ФормаЭлемента.Форма
Справочник.Номенклатура.Форма.ФормаВыбора.Форма
Обработка.ЗагрузкаДанныхCommerceML.Справка
Обработка.КалендарныйПланЗакупок.Справка
Скудное описание встроенной справки по данному регистру:
Регистр сведений «Номенклатура контрагентов»
Регистр предназначен для хранения списков номенклатуры поставщиков, возможных для поставки.
Данные регистра используются:
в помощнике заполнения календарного плана закупок обработки «Календарный план закупок» для определения доступных номенклатурных позиций поставщиков
в форме выбора справочника номенклатура, при выборе номенклатуры из документов «Поступление товаров, услуг», «Заказ поставщику» и прочие приходных документов
в обработке подбора номенклатуры, вызываемой из торговых документов
И, главное, подводный камень то в том, что в нем измерение номенклатура это СВОЯ номенклатура. Конечно, новый регистр и справочник не проблема. Как и чтение из Екселя и поиск соответствий по артикулам-свойствам и прочим признакам "похожести".
Программировать то все мастера. Вопрос что бы пригодилось из методологии. Что предложить пользователям в достаточно скромный бюджет часов на 10 работы чтоб было максимально эффективно?
1. Регистр НоменклатураКонтрагентов используется в:
Объект "РегистрСведений.НоменклатураКонтрагентов" использован в:
Подсистема.УправлениеЗакупками.Состав
ПланОбмена.ОбменУправлениеПредприятиемУправлениеТорговлей.Состав
ПланОбмена.ОбменУправлениеПредприятиемУправлениеТорговлейФоновый.Состав
ПланОбмена.Полный.Состав
Справочник.Номенклатура.Справка
Справочник.Номенклатура.Форма.ФормаЭлемента.Форма
Справочник.Номенклатура.Форма.ФормаВыбора.Форма
Обработка.ЗагрузкаДанныхCommerceML.Справка
Обработка.КалендарныйПланЗакупок.Справка
Скудное описание встроенной справки по данному регистру:
Регистр сведений «Номенклатура контрагентов»
Регистр предназначен для хранения списков номенклатуры поставщиков, возможных для поставки.
Данные регистра используются:
в помощнике заполнения календарного плана закупок обработки «Календарный план закупок» для определения доступных номенклатурных позиций поставщиков
в форме выбора справочника номенклатура, при выборе номенклатуры из документов «Поступление товаров, услуг», «Заказ поставщику» и прочие приходных документов
в обработке подбора номенклатуры, вызываемой из торговых документов
И, главное, подводный камень то в том, что в нем измерение номенклатура это СВОЯ номенклатура. Конечно, новый регистр и справочник не проблема. Как и чтение из Екселя и поиск соответствий по артикулам-свойствам и прочим признакам "похожести".
Программировать то все мастера. Вопрос что бы пригодилось из методологии. Что предложить пользователям в достаточно скромный бюджет часов на 10 работы чтоб было максимально эффективно?
(2) kostyaomsk,
Тихо-тихо-тихо! не надо паники )) нифига это не "своя", это вполне себе ваша номенклатура) а вот в ресурсах да, как раз указания на реквизиты номенклатуры контрагента.
Основной подводный камень - это когда контрагент вдруг изменит ранее зафиксированную в вашем регистре номенклатуру или две номенклатуры контрагента - для вас будут являться одной. Тут как раз методологию и поменять! Но начнем строить велосипед сначала:
Методология (бюджетом на 10 часов, простая, а значит эффективная):
условия внешние:
1. Контрагенты предоставляют накладные и желательно прайсы в электронном виде (ексель однако, куда без него)
Условия внутренние:
1. Обработка загрузки накладных в документ поступления с конвертацией номенклатур: из номенклатуры контрагента в вашу.
Обработка позволяет помимо автоподстановки еще и вручную проставлять соответствия
2. Регистр сведений: измерения - контрагент, НаименованиеНоменклатурыКонтрагента, ПрочиеРеквизитыНоменклатурыКонтрагента(артикул, его код, характеристики и тд)
ресурсы - ВашаНоменклатура, ЕеХарактеристика, ЕслиНадоТоЕщеЧеНить
3. Обработка печати заказа поставщику в его номенклатуре
4. Обработка загрузки прайсов в регистр
Работать велосипед будет так:
пришел прайс - грузим в регистр.
пришла накладная - грузим в ТЧ обработки, проверяем автоподстановку из регистра, отсутствующие соответствия проставляем лапами операторов и тут же регистрируем соответствия в регистре. Все сбацали - тащим в документ поступления из ТЧ обработки нашу номенклатуру
Нада заказывать - Собираем заказ в нашей номенклатуре, печатаем в номенклатуре поставщика, отправляем ему.
Финита однако) кажись даже меньше чем на 10 получилось))
ЗЫ. Собрано на коленке) Сильно не ругаться! это не финальное решение и даже не Бета версия)))
И, главное, подводный камень то в том, что в нем измерение номенклатура это СВОЯ номенклатура.
Тихо-тихо-тихо! не надо паники )) нифига это не "своя", это вполне себе ваша номенклатура) а вот в ресурсах да, как раз указания на реквизиты номенклатуры контрагента.
Основной подводный камень - это когда контрагент вдруг изменит ранее зафиксированную в вашем регистре номенклатуру или две номенклатуры контрагента - для вас будут являться одной. Тут как раз методологию и поменять! Но начнем строить велосипед сначала:
Методология (бюджетом на 10 часов, простая, а значит эффективная):
условия внешние:
1. Контрагенты предоставляют накладные и желательно прайсы в электронном виде (ексель однако, куда без него)
Условия внутренние:
1. Обработка загрузки накладных в документ поступления с конвертацией номенклатур: из номенклатуры контрагента в вашу.
Обработка позволяет помимо автоподстановки еще и вручную проставлять соответствия
2. Регистр сведений: измерения - контрагент, НаименованиеНоменклатурыКонтрагента, ПрочиеРеквизитыНоменклатурыКонтрагента(артикул, его код, характеристики и тд)
ресурсы - ВашаНоменклатура, ЕеХарактеристика, ЕслиНадоТоЕщеЧеНить
3. Обработка печати заказа поставщику в его номенклатуре
4. Обработка загрузки прайсов в регистр
Работать велосипед будет так:
пришел прайс - грузим в регистр.
пришла накладная - грузим в ТЧ обработки, проверяем автоподстановку из регистра, отсутствующие соответствия проставляем лапами операторов и тут же регистрируем соответствия в регистре. Все сбацали - тащим в документ поступления из ТЧ обработки нашу номенклатуру
Нада заказывать - Собираем заказ в нашей номенклатуре, печатаем в номенклатуре поставщика, отправляем ему.
Финита однако) кажись даже меньше чем на 10 получилось))
ЗЫ. Собрано на коленке) Сильно не ругаться! это не финальное решение и даже не Бета версия)))
(8) Пан, спасибо большое за идею
Технически я так и думал про этот подводный камень (как в УТ 11.1 по номенклатуре поставщиков) - нужно сделать копию регистра НоменклатураКонрганетов в конфигурации (чтоб не было проблем при обновлениях и прочих - все новые механизмы сделать. Создать хоть 1 дополнительное изменение - НоменклатураКонтрагентов (справочник создать в конфигурации). И дальше уже грузим, сопоставляем. Я по методологии зачем это нужно и спрашивал. Хорошо что Вы подсказали насчет накладных по почте. Обычно только прайсы.
По вознаграждению сейчас напишу в техподдержку. Не переводится
Основной подводный камень - это когда контрагент вдруг изменит ранее зафиксированную в вашем регистре номенклатуру или две номенклатуры контрагента - для вас будут являться одной. Тут как раз методологию и поменять
Технически я так и думал про этот подводный камень (как в УТ 11.1 по номенклатуре поставщиков) - нужно сделать копию регистра НоменклатураКонрганетов в конфигурации (чтоб не было проблем при обновлениях и прочих - все новые механизмы сделать. Создать хоть 1 дополнительное изменение - НоменклатураКонтрагентов (справочник создать в конфигурации). И дальше уже грузим, сопоставляем. Я по методологии зачем это нужно и спрашивал. Хорошо что Вы подсказали насчет накладных по почте. Обычно только прайсы.
По вознаграждению сейчас напишу в техподдержку. Не переводится
(8) Пан, Ваша цитата "Работать велосипед будет так:
пришел прайс - грузим в регистр."
Вот как вы себе представляете это?
В регистре же должно быть и СВОЯ номенклатура и ПОСТАВЩИКА.
Вот если руками - согласен.
А обработкой-то как?
Поясните, пожалуйста. Я, видать, что-то не понимаю.
пришел прайс - грузим в регистр."
Вот как вы себе представляете это?
В регистре же должно быть и СВОЯ номенклатура и ПОСТАВЩИКА.
Вот если руками - согласен.
А обработкой-то как?
Поясните, пожалуйста. Я, видать, что-то не понимаю.
(14) NE_ZNAIY, не нужна мне номенклатура поставщика, мне нужны поля синхронизации(вполне текстовых хватает) и цена (дабы потом заказы формировать в наименованиях поставщика например). Грузим прайс - как раз на форме обработки расставляем отсутствующие соответствия (ибо что то мы уже синхронизировали при поступлениях и ранних прайсах), сохраняем в регистр.
Обработка не исключает подключения головы исполнителя)) хотя если новых или измененных по полям синхронизации позиций в прайсе нет, то голову можно и отключить)
Обработка не исключает подключения головы исполнителя)) хотя если новых или измененных по полям синхронизации позиций в прайсе нет, то голову можно и отключить)
(14) NE_ZNAIY и (16) Пан,
Насчет
И вот это, слава богу тоже будет
Нафиг тогда программисты 1С нужны. Это есть такие места где если еще хуже работает больше денег получаешь. И еще кое-чего непрятного впридачу.
В общем, всем спасибо за умные мысли.
В регистре же должно быть и СВОЯ номенклатура и ПОСТАВЩИКА.
Вот если руками - согласен.
А обработкой-то как?
не придется руками. Иначе тему бы не создавал. До сих пор думаю как по-человечески сделать.
Вот если руками - согласен.
А обработкой-то как?
Насчет
Грузим прайс - как раз на форме обработки расставляем отсутствующие соответствия (ибо что то мы уже синхронизировали при поступлениях и ранних прайсах), сохраняем в регистр
так и будет.
И вот это, слава богу тоже будет
Обработка не исключает подключения головы исполнителя
не бюджет ведь.
Нафиг тогда программисты 1С нужны. Это есть такие места где если еще хуже работает больше денег получаешь. И еще кое-чего непрятного впридачу.
В общем, всем спасибо за умные мысли.
(3) kostyaomsk, если вы собираетесь грузить из экселя, то вам понадобится таблица соответствия. Естественно такой таблицы в УТ нету. Такие задачи решает обработка мегапрайс(платная). А вот по поводу инструмента: таблица соответствий. Это будет регистр содержащий поставщика его коды и соответствие его кодов кодам вашей базы.
Если условие совпало, то можно автоматически сопоставить, а если нет попросить юзера выбрать соответствие. Таким образом, будет загрузка из экселя на автомате практически от любого поставщика.
Если условие совпало, то можно автоматически сопоставить, а если нет попросить юзера выбрать соответствие. Таким образом, будет загрузка из экселя на автомате практически от любого поставщика.
(4) Xershi, Вам тоже спасибо за метод технической реализации, но
если вы собираетесь грузить из экселя, то вам понадобится таблица соответствия. Естественно такой таблицы в УТ нету. Такие задачи решает обработка мегапрайс(платная)
я же сам разработчик. Тут товарищ был по данным решениям его даже забанили за некорректное общение (конкуренция то жеская!). Это если от кого попало что попало может придти и то большую часть работы автоматизировать, а тут работа на несколько часов (10 часов уже много получается) Интересно по трудозатратам 1-2 часа на загрузку и сопоставление таблица соответствий. Это будет регистр содержащий поставщика его коды и соответствие его кодов кодам вашей базы.
Если условие совпало, то можно автоматически сопоставить, а если нет попросить юзера выбрать соответствие. Таким образом, будет загрузка из экселя на автомате практически от любого поставщика
Если условие совпало, то можно автоматически сопоставить, а если нет попросить юзера выбрать соответствие. Таким образом, будет загрузка из экселя на автомате практически от любого поставщика
какая-то она тяжелая обработка. Имею ввиду в части настроек.
Хотя, вероятно, есть что почерпнуть из нее.
Скачал на днях - чуть не запутался в настройках и пока отложил ее рассмотрение.
Но не будь у меня ее сейчас - все равно бы скачал.
Хотя, вероятно, есть что почерпнуть из нее.
Скачал на днях - чуть не запутался в настройках и пока отложил ее рассмотрение.
Но не будь у меня ее сейчас - все равно бы скачал.
Цель то собрать идеи и методы уже не "как сделать", а методология работы с номенклатурой контрагентов. Чтоб понять что еще может понадобится пользователям. И какие подводные камни в методологии, а не программной реализации.
Можно завести свойства, для каждого поставщика свое. И использовать их значения как таблицу соответствия при загрузке.
(12) Dem1urg, спасибо. Тоже дельная мысль. Только вот может быть путанница если у кого-то будут еще и свои свойства контрагентов (маловероятно).
Вообще главное это хранение наименования номенклатуры поставщика и ее артикула. Дальше уже у каждого свои вспомогательные свойства, зависящие от предприятия и от продукции. Особенно актуален вопрос у тех, кто работает по перепродажи с многомиллионными оборотами по НДС на экспорт и импорт. Там во всей цепочке требуется точно соответствие наименования и страны происхождения для формирования пакета документов (налоговая тут будет все смотреть от и до). В таких схемах выяснял просто приходится работать с номенклатурой поставщика. Недостаток - разрастаются базы и путаница у операторов.
Другое дело если нет такого жесткого контроля. Например ИП. Там требуется работа с собственной номенклатурой и удобство работы самое главное (сам и оператор и бухгалтер и директор и...).
Вообще главное это хранение наименования номенклатуры поставщика и ее артикула. Дальше уже у каждого свои вспомогательные свойства, зависящие от предприятия и от продукции. Особенно актуален вопрос у тех, кто работает по перепродажи с многомиллионными оборотами по НДС на экспорт и импорт. Там во всей цепочке требуется точно соответствие наименования и страны происхождения для формирования пакета документов (налоговая тут будет все смотреть от и до). В таких схемах выяснял просто приходится работать с номенклатурой поставщика. Недостаток - разрастаются базы и путаница у операторов.
Другое дело если нет такого жесткого контроля. Например ИП. Там требуется работа с собственной номенклатурой и удобство работы самое главное (сам и оператор и бухгалтер и директор и...).
Регистр я новый создал на всякий случай дабы не завязываться на типовые. Даже думаю как первый раз облегчить сопоставление всех прайсов.
Интересно было бы посмотреть примеры кривых внедрений этой технологии и к чему это привело. Все ведь молчат...Только хорошее или не обсуждается :)
Интересно было бы посмотреть примеры кривых внедрений этой технологии и к чему это привело. Все ведь молчат...Только хорошее или не обсуждается :)
(19) kostyaomsk, кривые и дюже сложные же не взлетают, чего их обсуждать?)) даже если занесет куда то далеко в разработке - при внедрении сразу видно где сокращать и упрощать нужно) юзер, слава богу, не дает размечтаться и наделать глупостей)
Пан, интересно у вас получется
"Грузим прайс - как раз на форме обработки расставляем отсутствующие соответствия (ибо что то мы уже синхронизировали при поступлениях и ранних прайсах), сохраняем в регистр"
А если это всё впервые.
Сначала надо это сделать ВПЕРВЫЕ.
Я об этом.
А если соответствие задано... тогда понятно.
"Грузим прайс - как раз на форме обработки расставляем отсутствующие соответствия (ибо что то мы уже синхронизировали при поступлениях и ранних прайсах), сохраняем в регистр"
А если это всё впервые.
Сначала надо это сделать ВПЕРВЫЕ.
Я об этом.
А если соответствие задано... тогда понятно.
Я приспособился грузить в регистр НоменклатураПоставщика так.
Первый раз приходную накладную делаем руками.
Затем сохраняю табличную часть этой накладной в эксель.
Соритировку по количеству.
Также сортирую по количеству в эксельке в приходной накладной поставщика.
Соединяю. Что-то (не много) приходиться подправить руками.
И обработкой ЗагрузкаДанныхИзТабличногоДокумента гружу в регистр.
Первый раз приходную накладную делаем руками.
Затем сохраняю табличную часть этой накладной в эксель.
Соритировку по количеству.
Также сортирую по количеству в эксельке в приходной накладной поставщика.
Соединяю. Что-то (не много) приходиться подправить руками.
И обработкой ЗагрузкаДанныхИзТабличногоДокумента гружу в регистр.
(22) NE_ZNAIY, ну а я это самое соединение предлагаю делать на форме обработки) можно еще нечеткий поиск по наименованиям (или другим реквизитам) замутить, если не нашлось соответствие и выделять цветом найденные нечеткости для ручного контроля и обработки. И поступление делать уже после сохранения соответствий, и делать его программно)
(24) NE_ZNAIY, "лично в пояс" конечно весьма почетно, но как мотивация - слабовато))
и таки вопрос! а идеи, по вашему, ничего не стоят?)) что такого невообразимого для программиста 1с я нафантазировал?))
ЗЫ. По мотивам этого поста создана и работает в УНФ система синхронизации номенклатуры заказчика(клиента) и нашей номенклатуры, ленивая, простенькая и эффективная)
и таки вопрос! а идеи, по вашему, ничего не стоят?)) что такого невообразимого для программиста 1с я нафантазировал?))
ЗЫ. По мотивам этого поста создана и работает в УНФ система синхронизации номенклатуры заказчика(клиента) и нашей номенклатуры, ленивая, простенькая и эффективная)
Я не программист.
Я могу только скопировать и вставить.
И возраст уже не тот, что бы начинать изучение языка. Поэтому я преклоеняюсь перед теми, кто может писАть код.
И это уже без шуток.
И вот представте, поставили задачу в Распределенной базе ограничить права пользователей на доступ к документам по складам.
Чтоб в центральном офисе оператор не мог видеть документы удаленного магазина. И наоборот.
Хорошо, ччто есть такой форум. И здесь таким как я помогают.
P.S. Что такое УНФ я не знаю. И вообще я очень не люблю абвеатуры и сокращения.
Я могу только скопировать и вставить.
И возраст уже не тот, что бы начинать изучение языка. Поэтому я преклоеняюсь перед теми, кто может писАть код.
И это уже без шуток.
И вот представте, поставили задачу в Распределенной базе ограничить права пользователей на доступ к документам по складам.
Чтоб в центральном офисе оператор не мог видеть документы удаленного магазина. И наоборот.
Хорошо, ччто есть такой форум. И здесь таким как я помогают.
P.S. Что такое УНФ я не знаю. И вообще я очень не люблю абвеатуры и сокращения.
Переговорил по интересующему меня вопросу с пользователем NE_ZNAIY. Действительно, человек не программист 1С, но разбираться приходится. Отправил Вам консоль. Был правда случай когда даже бухгалтеров научили в конструкторе запросы делать для поиска ошибок. С одной стороны руководитель франча сначала ругал с вопросом "зачем?", а потом все-таки это сняло часть ненужной работы. Но тут не тот случай. Важен сам факт научиться пользоваться запросами и видеть результат. Благо есть конструктор запросов в платформе 1С 8.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот