[ОБУЧАЛОВКА] Про сети (Ашан, Метро) и их заморочки...
Учетные задачи - Розничная торговля
Итак, задача ясна. Как говорил Петька: "Чапай думать будет!"
По хорошему, конечно, надо навернуть кучу изменений для реализации ввода в карточку номенклатуры артикулов для сетей. Возможных вариантов три (если по быстрому):
1. для номенклатуры артикул сети пихаем в подчиненный справочник Аналоги;
2. артикулы пишем в свойства номенклатуры;
3. аналоги делаем доп.реквизитами в карточке товара.
Вариант 1 - самый "правильный", но неудобный для ручного ввода (товаров не сильно много, клиент согласился вводить ручками), + к этому - достаточно "непрозрачное" решение для клиента, особенно когда понадобится отображать артикулы в карточке клиента (доп.код придется писать) и в формах накладных(тоже придется писать доп.код) - уже будет труднее с обновлениями в последующем;
Вариант 2 - похуже, чем вариант 1, но тоже можно использовать. Трудности - аналогичные предыдущему варианту, + нужна дисциплина "манипуляции" с такими свойствами (что выльется в дополнительный код работы со свойствами);
Вариант 3 - самый легкий, конечно, но... негламурненький... ;-) основная проблема - необходимость править структуру данных конфигурации при появлении новых "сетей", + не забывать при обновлениях.
Подумали - и выбрали вариант 3. С учетом того, что это ПРОЩЕ всего, займет минимум времени у меня и недорого обойдется клиенту. Итак, делаем - как в варианте 3 (т.е. добавляем под каждую сеть отдельный реквизит для артикула сети, благо сетей немного - у клиента их всего 4 штуки...).
Тем более, что внятных 1Сников, которые умеют НОРМАЛЬНО РАБОТАТЬ на программном и идейном уровне со справочниками свойств и аналогов - я давненько не встречал... (плюс к этому попутно: франч, обновлявший конфигу клиенту, умудрился "потерять" внесенный по другой доработке новый код в глобальный модуль - хотя ему был перед добавлением выдан "протокол" изменений - что уж тут говорить о более серьезных доработках кода... - при очередном обновлении - все рухнет... франчи - они такие...)
Для тех, кто начал уже плевать в мою сторону - отвечаю просто - на себя посмотри, собака бешенная! ;-)
Под каждыую сеть сделаем отдельный реквизит для артикула сети. Реквизит будем именовать по такому шаблону: ПРЕФИКС_АртикулNN, где
ПРЕФИКС - отличительный признак добавленного реквизита;
NN - числовой код клиента в справочнике контрагентов.
Для тех, кто начал плевать в мою сторону во второй раз - отвечаю просто - ничего не знаю, клиент - мой, как хочу - так и делаю! ;-)
Итак получились следующие реквизиты (строка, 10):
БВК_Артикул19, БВК_Артикул35, БВК_Артикул58...
Да, привязываться к коду контрагента в наименованиях реквизитов конфигуратора может показаться на первый взгляд некомильфово... Но тут есть ряд соображений, которые мне помогут обойти матюги так называемых "специалистов 1С" в мой адрес:
1. Это всяко лучше, чем называть БВК_АртикулАшан или БВК_АртикулМосмарт (такие названия - исключительно для удобства специалистов с короткой памятью, более никакого функционала полезного такие наименования В ДАННОМ СЛУЧАЕ не несут... а я, не то чтобы злопамятный, просто я злой и память у меня хорошая.. ;-) ...тем более что оправданность наименования реквизитов в ивде БВК_АртикулNN будет показана дальше).
2. Что произойдет, например, если коды клиентов в справочнике изменятся? А ничего страшного не произойдет - при первой же сделке на сеть - отсутствие(или неверный артикул) в колонке "код" в ТОРГ12 нужного артикула будет отловлен сразу же... Если не самим продавцом (моим клиентом), то как минимум - сеть заругается... А если сеть не заругается - так ничего страшного, значит, и не произошло... А если какой-то код В ТОРГ12 будет печататься для совершенно другого покупателя - тоже ничего страшного... даже полезно, так покупателю и скажем - мы тут вам заодно еще артикулы сети печатаем, чтоб вам в своем городе легче с сетями работать было... $-)
Итак, выше показано совершенно оправданное применение для каждой сети отдельного реквизита с наименованием по особому правилу. Сортировку и отбор на артикулы сетей ставить не будем - неактуально.
Теперича сделаем интерфейс для ввода артикулов в карточки товаров. С учетом того, что карточка товара и так уже забита под завязку всякой инфой - вынесем все добавленные артикулы на отдельную закладку - обойдется нам это в одну строчку кода в модуле формы элемента номенклатуры.
Итак, в форму добавляем один слой с идентификатором "ДопАртикулы", в модуль элемента добавляем следующую строчку кода:
Форма.ИспользоватьЗакладки(1); Форма.Закладки.ДобавитьЗначение("Общий, Основной, Кнопки", "Основные"); Форма.Закладки.ДобавитьЗначение("Общий, Дополнительный, Кнопки", "Дополнительные"); //ДОБАВЛЕНО НЕТИПОВОЕ Форма.Закладки.ДобавитьЗначение("Общий, ДопАртикулы, Кнопки", "Артикулы сетей"); //КОНЕЦ ДОБАВЛЕНО НЕТИПОВОЕ
На форме на слой "ДопАртикулы" кидаем наши дополнительные реквизиты (артикулы сетей) как поля ввода с соответствующими текстовыми заголовками - что тривиально, так что обойдемся без картинки...
Теперь лезем во все печатные формы ТОРГ12 (а их у нас может быть несколько - встроенная таблица, внешние печатные формы) и в колонку код (под номером 3 в типовой форме) вписываем ПечКод (тип = Выражение).
В модуле печати ищем где у нас определяется ПечЕдиница и вставляем там определение выводимой на печать переменной ПечКод:
ПечЕдиница = СокрЛП(Докум.Единица.ОКЕИ.Наименование); ПечОКЕИ = СокрЛП(Докум.Единица.ОКЕИ.Код); //ДОБАВЛЕНО НЕТИПОВОЕ Попытка ПечКод = Докум.Номенклатура.ПолучитьАтрибут("БВК_Артикул"+Число(Докум.Контрагент)); Исключение ПечКод = ""; КонецПопытки; //КОНЕЦ ДОБАВЛЕНО НЕТИПОВОЕ
Вот, собственно, и вся доработка (для встроенной печатной формы префикс докум. должен быть опущен в приведенном выше программном коде). Вся фишка - в имени реквизита для артикула сети и использовании конструкции ПОПЫТКА. При этом - мы нигде не привязываемся ни к каким наименованиям, никаких доп.проверок и всякого ненужного программно-мусорного кода...
По времени заняло порядка 20 минут, клиент - удовлетворен...
Кому сия история понравилась - плюсуем рейтинг и оставляем комменты, а то обижусь!
На очереди - сага о быстром подсчете мест и коробок в ТОРГ12 у "замороченных" клиентов - оставляйте в комментах заявки!
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Оптовая торговля Розничная торговля ККМ ЭДО и ОФД Обмен с ГосИС НДС 22% Системный администратор Разработчик Оперативный учет 7.7 Бухгалтерский учет 7.7 1С:Бухгалтерия 7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Россия Платные (руб)
Подключение фискального регистратора к 1С 7.7 в режиме онлайн-кассы в соответствии с 54-ФЗ для Атол, Штрих-М / Торговый баланс М (PosCenter). Поддержка операторов ЭДО: Сбис (Тензор), Контур.Диадок, ЭДО лайт, Калуга Астрал, Такском и пр. Поддержка оптовой и розничной продажи маркированной продукции (алкоголь, табак, обувь, лекарства, шины, одежда, белье, парфюмерия, молочная продукция, вода, пиво, автозапчасти, моторное масло и пр.). Поддержка онлайн и офлайн (через Локальный Модуль ЧЗ) проверки маркировки в разрешительном режиме (РР) и через ТС ПИоТ.
20000 руб.
28.03.2017 585998 5315 3840
Бюджетирование и планирование Оптовая торговля Розничная торговля Логистика, склад и ТМЦ Анализ продаж Пользователь 1С:Предприятие 7.7 1С:Предприятие 8 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 1.х 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 1С:Управление торговлей 10 1С:Управление торговлей 11 1С:Розница 2 1С:Розница 3.0 Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Беларусь Украина Россия Казахстан Управленческий учет Платные (руб)
Автоматизация заказа поставщику через 1С. Загрузка прайсов, анализ цен, управление заказами в УТ 10.3, УТ 11, КА2, УНФ, УПП, ERP, Розница 2
39141 руб.
21.04.2017 113591 213 44
Учет доходов и расходов Розничная торговля Бухгалтер Пользователь 1С:Предприятие 7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Бытовые услуги, сервис Розничная и сетевая торговля (FMCG) Россия Налоговый учет ПСН (патентная система налогообложения) Абонемент ($m)
Отчет позволяет сформировать книгу учета доходов для патентной системы налогообложения (ПСН), используя данные из проведенных документов по выбранной фирме и за выбранный период. По умолчанию используются документы вида "Отчет ККМ" и "Реализация Розница". Можно подключить другие виды документов. Отчет предназначен для использования с конфигурациях "1С:Торговля и Склад 7.7, редакция 9.2" (релиз 932 и выше) и "1С:Комплексная, редакция 4.5" (релиз 446 и выше). Можно легко адаптировать под другие конфигурации, т.к. код открыт. Выкладывается как инструмент для разработки с целью реализации в собственных конфигурациях. Отчет предоставляется в виде внешней обработки, внесения изменений в конфигурацию не требует.
1 стартмани
27.01.2021 12209 21 victuan 2
Розничная торговля Ценообразование, анализ цен Маркетплейсы Разработчик Оперативный учет 7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Россия Управленческий учет Абонемент ($m)
Внешняя обработка для 1С 7.7 конфигураций ТиС и Комплексная конфигурация. Подходит для Windows, которые поддерживают работу с WinHttpRequest.
2 стартмани
10.11.2020 13240 28 user1479046 11
Розничная торговля Обмен с ГосИС Пользователь 1С:Предприятие 7.7 1C77 Розничная и сетевая торговля (FMCG) Россия Абонемент ($m)
Разагрегация (получение кодов маркировки, товаров, входящих в "агрегатированные" поставщиком упаковки) для табачной продукции по коду маркировки коробки - получаем коды всех блоков, входящих в эту коробку, по коду любого блока из нее получить список кодов пачек в блоке. Позволяет запросить в виде дерева содержимое (коды маркировки) табачной продукции. Отсканировав или вставив в строку ШтрихКод упаковки, можно запросить из ЦРПТ вложенные коды Требует наличия ЭЦП(КриптоПро или VipNet, ЕГАИС РуТокен ЭЦП 2.0 не подойдет! ) и регистрации в системе МОТП "Честного знака".
2 стартмани
27.05.2020 23028 55 M_W_W 19
Розничная торговля Бухгалтер Пользователь Оперативный учет 7.7 1С:Торговля и склад 7.7 Россия Управленческий учет Абонемент ($m)
Конфигурация позволяет продавать обувь в соответствии с новыми законами, причем сохранена возможность работы как со старыми штрих кодами, так и с новыми. Т.е., сканируя DataMatrix, программа извлекает EAN13 и позволяет осуществлять подбор товаров по EAN13. Конфигурация на базе Торговля и Склад 7.7.8.7. В архиве только свои модули, и инструкция по обновлению.
7 стартмани
14.02.2020 10357 11 zoeh 10
Розничная торговля Рабочее место Пользователь 1С:Предприятие 7.7 1С:Предприятие 8 1C:Бухгалтерия 1C77 Рестораны, кафе и фаст-фуд Россия Абонемент ($m)
Рабочее РМК на 7.7. Можно работать с принтером чеков, можно с кассой АТОЛ, а можно и одновременно. В качестве бэк используется стандартная Розница 2.2.
1 стартмани
08.01.2020 11860 8 toll 2
Загрузка и выгрузка в Excel Оптовая торговля Розничная торговля Перенос данных 1C Разработчик 1С:Предприятие 7.7 1С:Предприятие 8 1С:Управление торговлей 10 1С:Комплексная 7.7 1С:ERP Управление предприятием 2 Управленческий учет Абонемент ($m)
Описание практического опыта переноса данных из двух устаревших учетных систем в одну современную с обобщением справочников (например номенклатуры, контрагентов, партнеров) и объединением учетных данных устаревших систем в единую новую УС применяя комбинацию стандартной загрузки из Эксель и КД2. Данная публикация является примером переноса данных из сильно устаревших и сильно переписанных конфигураций 1С:Предприятия 7.7 и 8 в современную 1С 8.3 своими силами при условии невозможности или нежелания пользоваться обновлением релизов и типовой функциональностью универсального обмена данными типовых мастеров переноса данных. Отличительной особенностью публикации является устранение зависимости от версий релиза конфигураций, отказ от обновлений устаревших конфигураций.
1 стартмани
29.07.2019 24986 24 ksnik 5
> конфигуратора может показаться на первый взгляд некомильфово
Продожение.
Я бы предложила другое решение:
В справочнике контрагентов добавить реквизит: "КодСети" (типа строка(2)). В справочнике Номенклатура, нужно добавить реквизиты "БВК_АртикулХХ", где ХХ = от 00 до 15 (или 20, или другое число).
В коде пишем:
| Код |
|---|
ПечКод = "";
ИмяРеквизита = "БВК_Артикул"+Докум.Контрагент.КодСети;
Если глЕстьРеквизитШапки(ИмяРеквизита, Докум.Вид()) = 1 Тогда ПечКод = Докум.Номенклатура.ПолучитьАтрибут(ИмяРеквизита);
КонецЕсли;
Показать полностью |
В рассмотренном варианте мы можем "привязать" несколько контрагентов к одному коду номенклатуры.
Вероятность появления у клиента новых сетей в течение года - весьма мала... так что
NN - числовой код клиента в справочнике контрагентов - В ДАННОМ СЛУЧАЕ - практически оптимальное решение... особенно, если клиенту завтра припрет вставить колонку артикула Ашана в ТЧ документа реализации - это я смогу и по телефону разрулить... а вот при выборе идеологически верного Варианта 1 - придется телепаться на другой конец москвы...
Естественно, к выбору варианта решения надо подходить обоснованно... Ясен пень, что при первой же возможности следует переделать под Вариант 1, но работы там будет - раз в пять больше... потому что внешне для клиента - все должно быть максимально просто...
.
> а что будет когда количество подобных клиентов станет расти?
сразу видно, что народу лень думать... БОЛЬШИНСТВО клиентов, которые работают с сетями - имеют СВОЕГО программиста 1С. Поэтому - ничего не будет...
..
> решение на коленке долго не проживет
Согласен... Только предложенное выше как выразились "решение на коленке" - встраивается в систему за 15 минут... и уж поверьте - грамотные "коленчатые" решения - живут вполне себе успешно...
Сапсем больной, да? ;-)
Обмен в электронном виде не исключает необходимости предоставления твердых копий документов. Пока я еще не встречал, чтобы налоговая принимала для проверки логи/электронные документы.
Низачот.
-1
Ставим задачу:
- решить сабж
- уложиться в общем случае в 10 строк кода.
- избежать программирования при вставке артикула сети в табличную часть документа.
...
критиканские высказывания без обоснования будут приравниваться к флуду... ;-)
imaster'у: а ты, что, никогда структуру данных конфиги не модифицировал?
Сам работал с сетями, и знаю, что это такое, более придирчивого покупателя не найти, но это сеть, и она диктует условия.
Добавления нового реквизита в карточку номенклатуры самое простое и грамотное решение. Многие программисты не понимают, что 1С дала прекрасный инструмент, чтобы решать именно такие задачи. Создал реквизит, добавил на форму и все. Больше ничего делать не надо. А создание сложных систем по вводу дополнительных артикулов только усложняет процесс ввода, вывода и т.д. Потом научить оператора создавать такой артикул сложнее, чем научить создавать дополнительный реквизит в справочнике. :)
И еще, сетей, которые кодируют сами, в России можно пересчитать по пальцам, все остальные используют коды поставщиков. Создавать сложную систему для максимум десяти клиентов просто глупо.
Плюсы данное решения.
- Дополнительный артикул легко выводится в форму списка справочника (опять же заложено 1С), соответственно оператор может искать по нему.
- В любом универсальном отчете можно легко вывести код сети, т.к. это просто реквизит справочника.
- Добавить реквизит в табличную часть документа так же просто, как в форму списка.
- Можно осуществлять упорядочивание 1С запроса по данному реквизиту.
- Можно осуществлять поиск по реквизиту, отбор и т.д.
| Код |
|---|
ПечКод = "";
Если глЕстьРеквизитШапки("БВК_Артикул"+Число(Докум.Контрагент.Код), Докум.Вид()) = 1 Тогда
ПечКод = Докум.Номенклатура.ПолучитьАтрибут("БВК_Артикул"+Число(Докум.Контрагент.Код));
КонецЕсли;Показать полностью |
Цитата
"(плюс к этому попутно: франч, обновлявший конфигу клиенту, умудрился "потерять" внесенный по другой доработке новый код в глобальный модуль - хотя ему был перед добавлением выдан "протокол" изменений - что уж тут говорить о более серьезных доработках кода... - при очередном обновлении - все рухнет... франчи - они такие...)"
ни один из способов не является оптимальным.
Реализованный вариант 3 при подобном обновлении пострадает также, как и остальные варианты!!
Наиболее правилен все-таки вариант 1, пусть он клиенту и обойдется дороже :)
Только я бы не использовал встроенный справочник Аналоги, а сделал бы спец. подчиненный справочник, который не пострадает. Объем клиентского кода, в принципе, примерно тот же :) Необходимо только написать пару методов для работы с подчиненным справочником :)
При "плохом" обновлении/объединении в этом случае по крайней мере данные клиента (коды) не будут потеряны, как при использовании варианта 3 :(
Также 100% твой доп. слой будет потерян :)
ЗЫ а вообще подобная схема у меня лично давно реализована с помощью классов 1С++.
И подобные фичи легко добавляются в спец. подчиненный справочник, в котором соответствие один-один к справочнику-хозяину.
Для клиентского кода все прозрачно, только вместо
Спр = СоздатьОбъект("Справочник.Номенклатура");
используется
Спр = СоздатьОбъект("Общие.СправочникСДополнительнымиРеквизитами");
Спр.НазначитьВид("Номенклатура");
Хотелось бы узнать - чем неустроил справочник "Аналоги" - чисто интересно.
То, что при обновлении потеряется доп.слой - это да... но его по тлф. "внедрить" легче, чем большой кусок программного кода по вар.1. Понятно, что по варианту 3 код тоже потеряется - но его всего вообщем-то 3 строчки ;-)
...
> При "плохом" обновлении/объединении в этом случае по крайней мере данные клиента (коды) не будут потеряны,
// ну это надо так постараться, чтобы доп.реквизиты убить - это только если загрузить обновление.... ;-) хотя и такое могут отчудить... ;-)
..
> с помощью классов 1С++.
... отдавая дань возможностям 1С++ на широкое масштабное применение 1С++ не иду ввиду отсутствия внятной целной документации - и не надо давать ссылки на "обрывки", которые лежат на известных ресурсах... - это нельзя назвать документацией... ну и не надо экскаватором копать ямки для заборныз столбиков... ;-)
Нет геммора с обновлением и с печ.формой.
Букавак больше, но строчек = меньше. ;)
Использование конструкции "Попытка" для определения наличия атрибута смахивает на почерк программистов из Раруса. Не буду разводить здесь антирекламу, но такой почерк вызывает у меня рвотные рефлексы.
Ты сам утверждал, что учился кодить у одноэсовых программистов ( ). Видать, плохо учился...
Немного покритикую.
По вопросу обновления и франчей.
Не думаю, что мы доживем до 950 релиза. Если и доживем, то не скоро.
ИМХО очередные релизы пишут какие-то "студенты". Они вносят больше ошибок, чем исправляют. Поэтому, новый релиз + неумелый франч = взрывная смесь.
Если уж "решение" создает Че, то клиенту выгоднее обратиться к нему же за обновлением. Другое дело, что мотаться по Москве, выпоняя обновления = неблагодарное дело.
Как вариант: автор решения готовит очередное обновление, но обновление конкретной базы выполняет ближайший франч.
> конфигуратора может показаться на первый взгляд некомильфово
Не то слово. Очень большое ФИ по этому вопросу.
В восьмерке, например, есть преопределенные элементы, но в серемерке, иногда, приходится принимать непопулярные решения.
ну это - ваще отстой...
лучше уж как сделано в статье.. или на налогах/свойствах...
а вот почему Попытка - рвет на родину - непонятно...
Я считаю использование такой конструкции РАЗУМНО ТАМ где срабатывание по ветке "исключение" - не приводит к каким-либо траблам - как в примере вывода печатной формы... Другое дело, что при вычислительном каком-нить алгоритме применение Попытки не есть хорошо - так как БЕЗ ДОЛЖНОЙ ОТРАБОТКИ ИСКЛЮЧЕНИЯ приводит к иллюзии что все есть гуд...
А то, что 950 релиза ххз когда дождемся - это да... я у себя в конторе до сих пор на 933 сижу (книги продаж/покупок только из 941 подтянулл в всое время...)
> решение автора простое, но не универсальное...
именно, речь ведь не шла о написании мегаконфиги для работы с сетями...
> Я бы сделал справочник "Товарная матрица", подчиненный справочнику "Контрагенты", в котором для каждой розничной сети вёл бы свой список товаров с их названиями, артикулами, возможно ценами и проч. реквизитами.
я бы не стал плодить излишеств и по максимум воспользовался бы "Аналогами" - тем боле что туда вполне можно впихнуть и артикул, и наименования, цены для каждой сети свои - тоже нормально реализуется штатными возможностями... доп.реквизиты - в свойства - все это, конечно, если работа с сетями не составляет ОСНОВНОЙ доли деятельности. Тогда имхо точить конфигу надо именно под автоматизацию работы с сетями...
смысл именно такой и был - прсо, без заморочек... суть уловлена верно.
> ну это - ваще отстой...
Не отстойнее, чем исходное решение... ИМХО ;)
Я даже не осуждаю то, что автор в своей статье многочисленно оправдывается за принятое решение.
> В любом случае - все предложенные решения (кроме описанного в статье) являются
> существенно БОЛЕЕ ЗАТРАТНЫМИ.. имхо...
Не существенно и не БОЛЕЕ.
Бюджет моего решения соизмерим с исходным. А если учесть перспективу "разруливания" ситуации по телефону, то значительно ниже как для заказчика так и для исполнителя.
Мое решение является более универсальным. В частности:
- у разных магазинов одной сети могут быть разные реквизиты. В этом случае разным контрагентам можно назначить одинаковые коды товаров;
- при появлении новых магазинов (сетей) пользователь добавляет данные в привычном для него интефейсе в т.ч. и без консультации по телефону.
В развитии решения можно добавить следующее.
Создать справочник "Сети". Тип реквизита КодСети справочника Контргаенты установить этот справочник. В форме элемента справочника Номенклатура показывать только те реквизиты, ХХ которых совпадает с кодом одного из элементов справочника Сети. Надписи для них брать из нового справочника.
"Коленчатые" решения действительно иногда жывут "успешно" и долго. Но в большинстве случаев из-за того, что уйти от них бывает дороже, чем выполнять разовые доработки.
Складывется впечатление, что заказчик и автор решения не знакомы с известным правилом: Я не настолько богат, что-бы покупать дешевые вещи.
Единственный плюс исходного решения отмечаю использование иднтификаторов реквизитов ПРЕФИКС_АртикулNN вместо БВК_АртикулАшан.
Потому что в аналогичных ситуациях эту конструкцию используют программисты из известной большой франчайзинговой фирмы.
Конфигурации от них у меня ассоциируются с неработающими поделками.
Складывается впечатление, что свои решения они создают на "коленках", распостраняя их потом на всю страну. Вот и рвет на родину.
Я не против использования конструкции Попытка в целом и в рассматриваемой ситуации в частности.
Кстати, если бы такое решение (Вариант 3) предложил какой-нибудь новичок, что Чебур первый бы его зачморил ИМХО.
Как я понял автор хочет защититься от дурака-обновляльщика.
Думаю что добавленный реквизит с точки зрения обновляльщика мало отличается от добавленного справочника.
Можно использовать префиксы для добавляемых объектов матаданных. Например, реквизит назвать ЧЕБУР_КодыСетей или назвать справочник ЧЕБУР_АналогиСетей.
Вариант2 наиболее защищён от дурака-обновляльщика, поскольку на первый взгляд требует меньше изменений в коде.
Вариант1 vs Вариант3
Трудоёмкость написания кода для разбора строк не меньше чем трудоёмкость написания кода для работы с подчинённым справочником. Кроме того для облегчения обновления форму элемента лучше трогать поменьше. Я бы навесил на неё только кнопку с вызовом справочника аналогов или формы обработки по заполнению аналогов. Получается что разница в объёме кода между первым и третьим вариантом исчезающе мала, а вот разница в ссылочной целостности и лёгкости доработки - значительная.
Вариант2 vs Вариант3 vs Вариант1
До сраки как сделать, главное чтобы работало и чтобы пришедший после тебя не сильно матюкался.
Любителям универсальных решений - в сад. Лучше неуниверсально и просто, чем универсально на сложно и с множественными переломами мозгов при попытке использовать где-то ещё.
Касательно комментариев. Лучше писатьтак
а так
//(( Чебурашка 07.07.2007
//)) Чебурашка 07.07.2007
Автору плюс за поднятую тему.
> то разница в объёме кода между первым и третьим вариантом исчезающе мала,
- на мой взгляд разница в коде - весьма существенна... хотя кто как считает...
> ЧЕБУР_КодыСетей
ну так и названо - БВК_Артикул...
Но ведь нравится пользователю. Мне как пользователю - это удобно. Это комфортно.
Мало того, я знаю, что если вдруг возникнет проблема, мне её сразу решат. Серёжа, спасибо, с тобой очень комфортно работать!
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 16979
Создание 21.06.07 00:00
Обновление 30.06.09 04:26
Просмотры 24279
Загрузки 0
Рейтинг
18
Комментарии 47
Код открыт Не указано
Рубрики Розничная торговля
Кому Разработчик
Тип файла Нет файла
Платформа Оперативный учет 7.7
Конфигурация 1С:Торговля и склад 7.7
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Управленческий учет
Доступ к файлу Бесплатно (free)