IronMann

Совершенно согласен, что водяные знаки нужно накладывать только на большие изображения.

На счет накладывания водяных, надо высказаться проще - либо накладывание водяных знаков является функцией модуля, либо не является.  Функционал сторонних модулей заметно выше и что не маловажно - в процессе деятельности магазина можно водяной знак менять. Модуль, по логике работы, физически не сможет менять водяной для товаров в магазине без сеанса полной выгрузки. По совокупности факторов, я больше склоняюсь, что накладывание водяного знака следует в модуле отключить.

2 часа назад, Kirillove сказал:

Не вырезал еще связанные опции, но убрал склады, водные знаки..

Исправил несколько ошибок....

Пока выложу вдруг кто протестирует, и выявит еще ошибки, 

Модуль остается бетой, не осилил я все почистить, завтра продолжу...

На счет водяных знаков, вопрос спорный.  Если функцию наложения водяного знака по уму доделать, в сети даже на этот счет материалы были, она вовсе не будет ненужной. С другой стороны, если сейчас реально мешает, то лучше будет убрать. Обратно вернуть всегда будет можно.

Сейчас нет времени, но я хочу написать довольно содержательный пост по сценарному подходу к составу настроек и их интерфейсу.

3 часа назад, pasha2203 сказал:

а я думаю что на оборот

Цитирование большого поста СРАЗУ под сами постом, есть некоторое компьютерное дурновкусие.

Цитировать весь мой пост было не обязательно.

Насколько я понял, вам сняли с замка вашу типовую конфигурацию и дописали какие-то ваши хотелки, которые сейчас вызывают у вас эйфорию. Могу сказать, что будет дальше. А дальше, за одной хотелкой будет другая, третья, пятая и т.д. А потом, будет какое-нибудь масштабное обновление типовой конфигурации, которую вы у себя уже доведете до несовместимости с обновлением. И тогда, ваша эйфория сменится отчаянием. Если вы к тому моменту дорастете до больших денег, то вы будете вынуждены нанять штат программистов, которые будут постоянно вам что-то дописывать и прилаживать. Кажущаяся нужность, полезность и легкость ваших действий на первом этапе, закончится вечным головняком спустя какое-то время, не очень долгое. Не вы первый и не вы последний, кто на эти грабли наступил. В одной из организаций, где я работал, было создано целое технологическое управление, которое чистило авгиевы конюшни внутренней информационной системы от многоярусных наслоений всевозможных хотелок. И кто порой чего и в какой год хотел, а главное - зачем, порой было уже невозможно вспомнить. И прежде чем бросаться писать код к очередной хотелке, она проходила глубокое изучение её реальной нужности с точки зрения бизнес-процессов организации. В 80% случаев, выяснялось, что хотелка не нужна, т.к. "новый сотрудник просто не разобралась, что это уже есть".

Далее, Виталий как бы и не скрывает особо, что модуль станет платным, когда выйдет в релиз. Только вот в релиз, по моему глубокому убеждению, модуль не выйдет, пока будет идти тем путем, которым он идет. Это на самом деле очень правильно, что он сейчас не в релизе, т.к. если его сейчас зарелизить, то ваше огромное человеческое спасибо очень быстро сменится на раздражение и претензии к разработчику. Которые приведут к репутационным потерям разработчика и финансовым потерям, как прямым, так и косвенным - вашим.

По времени, модуль пишется уже долго, очень долго. И как мне видится, сейчас он на такой ступени, когда ему необходим глубокий рефакторинг.

Ну и в заключении, обозначу, что мой корыстный интерес в происходящем - это получение надежного и стабильного инструмента для связи УНФ и ocStore. У меня тоже есть хотелки, главная из которых - чтобы весь типовой функционал УНФ был по максимуму использован в типовом ocStore 2.3.2.3. Чтобы был полностью двунаправленный обмен заказами, с доставкой. И в этом плане, я готов предложить свой опыт профессиональной разработки информационных систем Виталию, включая опыт управления требованиями. Делаю это безвозмездно. Я не владею хорошо тонкостями программирования на PHP в разрезе Опенкарта и методикой написания модулей в нем, иначе бы все давно уже сделал сам. Но вот в плане сопряжения информационных систем и баз данных, требований к интерфейсу, пользовательских сценариев - разбираюсь более чем хорошо. И с SQL дружу. Если Виталию мой опыт будет полезен, хорошо. Нет, значит нет.

Вы о чем? Адрес контрагента?

Не надо его ни к чему привязывать. В 1С он может передаваться из модуля как строка, т.н. "адрес в свободной форме". А если есть огромное желание его причесать, то делать это надо либо на этапе ввода заказа в интернет-магазине, либо на этапе записи заказа в базу данных интернет-магазина. После определенных исканий я в и тоге пришел к тому, что в интернет-магазине нужно использовать сервис dadata.ru

Уже есть модули, которые используют этот сервис в режиме "подсказки", т.е. предлагая варианты ввода правильных значений на этапе ввода адреса. Это процентов на 70% решает вопросы с адресом.  В планах есть написать ТЗ на Fraud модуль, который помимо функций первичной фильтрации мутных заказов и отсечки по Black List заказов от неадекватов, будет выправлять адреса во всех проходящих через него заказах, при помощи того же dadata.ru

Ваш модуль с адресом ничего делать не должен, это не его задача. Не надо никаких ФИАСов 1Совских, адрес должен быть правильным в базе интернет-магазина и будучи уже правильным экспортироваться в 1С.

7 часов назад, rassigor сказал:

надо сделать мораторий на новые хотелки,  все новые хотелки только платно,  а вам сосредоточиться только на отладке функционала

Здесь есть огромный соблазн заниматься только платными докрутками "любой каприз за ваши" как говориться, но в этом случае, лучше сразу объявить общественности - юзайте бесплатно что есть, заказывайте за деньги что хотите или дописывайте сами.

Или, если все таки есть цель вывести модуль в релиз, добиться от его работы такого состояния, чтобы установленный на голый опенкарт/оцстор и присоединенный к типовой конфигурации без самодопилов, модуль работал как часы. Это отправная точка, только с которой вообще можно говорить о релизе и последующей техподдержке.

Тут надо отметить, что даже к типовой конфигурации должен быть четкий мануал, как организовывать и вести справочники. Немного позабавила недавняя ситуация, когда чел объявил, что нашел баг в создании контрагента, а потом выяснилось, что он просто не разобрался, как они вообще заводятся, т.к. УНФ поставил недавно и вообще не завел ещё ни одного контрагента сам, руками.

В модуле доставку надо сделать другим образом. Дело в том, что Опенкарт не хранит доставку как товарную позицию, которую напрямую можно связать со справочником товаров и услуг 1С. Список модулей доставки получается Опенкартом динамически, как это делается, можно посмотреть в штатном модуле "chekout", который вызывается при оформлении заказа. Функционал получения актуальных типов доставки прописан там. В самом заказе прописывается вычисленная выбранным модулем доставки стоимость доставки, название доставки и название модуля доставки, в текстовом виде. Все это вполне решаемая задача. Надо просто держать таблицу соответствия, в которой в левой колонке будут названия актуальных доставок, а в правой - соответствующие услуги из справочника 1С. Если соблюсти отношение 1 к 1, то это будет прекрасно шлюзоваться в обе стороны. Из Опенкарта в 1С по названию модуля будет в заказ подставляться соответствующая ей в таблице услуга и её цена, в обратную сторону - по названию услуги находится названия соответствующего модуля доставки и типа доставки и записываться цена.

Именно так сделано в лучших платных подсистемах работы 1С и Опенкарта. Эти подсистемы вшиваются в конфигурацию, но дополнительно на Опенкарте устанавливается небольшой модуль. У него много функций, одной из которых является стение из Опенкарта названия модулей доставки и типов доставки. Иначе просто не сделать. Потом, эта информация помещается в таблицу соответствия типов доставки и услуг.

В ‎12‎.‎05‎.‎2018 в 05:21, Kirillove сказал:

Перечислите, пожалуйста, основные базовые функции, я их реализую после 14 числа последовательно.

Сделайте уже наконец Доставку...

Возможно, в вашей теме никто не пишет про доставку именно потому, что кому это нужно, давно махнули рукой и ушли в сторону других решений. Сейчас, ваш модуль годится в полном объем исключительно для владельцев торговых залов, которые используют Опенкарт в качестве торгового электронного терминала и оптовиков, которые за услуги доставки со своими клиентами расчитываются вообще отдельно от Опенкарта либо вообще отправляют грузы с оплатой за доставку на месте компании-перевозчику.

Розничным интернет магазинам, работающим с учитываемой доставкой в заказе для каждого клиента, без доставки модуль годится только в ознакомительных целях. При этом, я хочу заметить, это будет основной контингент покупателей вашего модуля, если вы собираетесь выводить его в релиз и продавать.

В ‎12‎.‎05‎.‎2018 в 05:12, Kirillove сказал:

А про правила или как Вы сказали "макро язык" намного увеличивает возможности штатных функций, что увеличивает гибкость настроек.

Я даже скажу большее, что можно при загрузке значения из тега изменить при определенном условии другое значение. Я позже приведу пример и список переменных которые можно затрагивать.

 

Перечислите, пожалуйста, основные базовые функции, я их реализую после 14 числа последовательно.

Но сначала к 14 числу хотелось убрать все то что сейчас криво работает, чтобы модуль мог, в штатные возможности opencart загружать данные.

Вы увеличиваете гибкость настроек, пытаясь охватить в рамках функциональности вашего решения все на свете хаотично поступающие вам хотелки и все на свете доработки штатного функционала систем 1С, разной степени полезности и разного качества исполнения. Попробую предположить, что с таким подходом, ваш модуль никогда не выйдет в релиз. Вы просто сами запутаетесь в потоке разномастных и противоречивых требований, который не иссякнет никогда и будет только расти.

Уже сейчас, модуль обрастает довольно странными функциями, типа: "Удаляет "ненужный" текст в скобках в конце названия опции, например "Размер (Женская обувь (Для характеристик))", здесь будет удален текст "(Женская обувь (Для характеристик))" и останется только "Размер"" - которые понятны только вам и тому парню, который эту функцию возжелал. Огромная часть лезет снимать с замка конфигурации и накрячивать какие-то новые функции, а потом требовать от вас отразить свои наработки в вашем модуле просто от того, что не разобрались, как это сделать штатными средствами. И потребительская ценность решения, забитого кучей непонятных настроек под 1,2,3-го парня и желание такое решение купить и поставить на рабочий сайт, будет прямо пропорционально снижаться от количества подобных настроек.

Решение должно ориентироваться в первую очередь на штатный функционал систем 1С и как часы отрабатывать взаимодействие именно с официально поставляемыми решениями. Если вы с этим не согласны, представьте, что у вас тысяча клиентов, каждый обкрячил свою конфу, модифицировав штатные справочники своими додумками, порой несовместимыми друг с другом, и каждому такому доработчику вы будете должны предоставить необходимую помощь в рамках техподдержки. И чтобы все это работало.

По поводу шлюзования данных, к которым вы написали макро-язык. Ряд полей из 1С имеют прямую логическую связь с полями Опенкарт и шлюзуются без необходимости написания для этого макросов. Недостающие атомарные поля, которые есть в Опенкарте и которые желательно заводит и передавать из 1С, можно сделать в 1С через механизм дополнительных реквизитов и сведений. Простая четкая и понятная любому пользователю таблица, где в левой части будет название штатного поля или дополнительного реквизита/сведения 1с, а в правой - соответствующих ему атомарных полей оперкарта, будет лучшим решением, чем макросы. У вас это уже сделано, в разделе "Запись свойств товара определяемыми пользователем из торговой системы". Что вам мешает сделать заполнение всех атомарных полей Опенкарта по подобному принципу? Я вам в свое время предлагал сделать заполнение полей товарного справочника подобным образом и чтобы эта таблица была изначально не пустой, а заполнена набором предустановленных значений, типа Описани, Артикул и т.п. чтобы пользователю даже просто было понятно, как изменить/дополнить эту таблицу связей по своему усмотрению.

А SEO поля, можно собирать из паттернов, на основе атомарных полей опенкарта, их для этого более чем достаточно.

И важно принять, что если в штатных системах 1С НЕТ сейчас описания и фотографий категорий номенклатуры, значит их НЕТ и не надо мудрить, пытаясь нагененрирвать это какими-то макросами. Наверняка, все это будет в следующих версиях 1С программ, т.к. они сейчас все более и более будут ориентированы на интернет-магазины. А сейчас, все это можно сделать руками в самом опенкарте и просто иметь в активе модуля настройку, которая не позволит просто удалить категорию, если у нее в Опенарте есть картинка и описание.

Я хочу вам сказать, что чем больше вопросов решается на основании простых и четких правил, тем лучше это автоматизируется и сопровождается. И наоборот, если начинать автоматизировать хаос, бредятину и разного рода непонятки, получается в итоге автоматизированный бред.

2 часа назад, Kirillove сказал:

А про правила или как Вы сказали "макро язык" намного увеличивает возможности штатных функций, что увеличивает гибкость настроек.

Я даже скажу большее, что можно при загрузке значения из тега изменить при определенном условии другое значение. Я позже приведу пример и список переменных которые можно затрагивать.

 

Перечислите, пожалуйста, основные базовые функции, я их реализую после 14 числа последовательно.

Но сначала к 14 числу хотелось убрать все то что сейчас криво работает, чтобы модуль мог, в штатные возможности opencart загружать данные.

Хорошо, я это сделаю. Я найду некоторое количество своего времени, чтобы коротко и сжато вам показать, что вы сейчас двигаетесь в довольно странные стороны, сами себе придумывая ненужные сложности. Главное, чтобы вы попытались понять, почему это именно так.

Заодно, это объяснит, почему ваш коллега-конкурент, поднял цену на свой платный модуль с 1800 до 5000 рублей, т.е. почти в три раза, и вопросом конкуренции с вашим модулем даже не парится. При том, что его модуль, по заявленной функциональности уступает вашему в разы. 

В ‎10‎.‎05‎.‎2018 в 23:19, Kirillove сказал:

В 1.6.4.5 будет добавлены правила загрузки, как в товаре было сделано:

 

В модуле начал появляться свой макро-язык, о-ла-ла!

Большинство нововведений в последних версиях имеют сомнительную ценность, имхо. При этом, некоторых базовых функций, представленных в подобных модулях, до сих пор нет.

Никогда. Берите последнюю стабильную рабочую версию и дорабатывайте сами. Получите нужный результат быстрее, чем на этот калейдоскоп смотреть будете.

Здравствуйте!

Кто-нибудь использует модули доставки у себя в интернет-магазине? Как вы решаете вопрос отсутствия интеграции используемых в интернет-магазине модулей доставки в данном модуле при передаче заказов в 1С?

Здравствуйте!

Кто-нибудь использует модули доставки у себя в интернет-магазине? Как вы решаете вопрос отсутствия интеграции используемых модулей доставки в модуле при передаче заказов в 1С?

2 часа назад, KLM сказал:

Нет, услугу доставки в заказ клиента мы не включаем, т.к. отгружаем после оплаты заказа и нет понимания, как можно вести автоматический расчёт доставки. Окончательную упаковку заказа мы проводим после оплаты, до этого он лежит в ячейке хранения. Клиент может сделать ещё несколько дозаказов к основному заказу в течение, скажем, недели. И тогда мы формируем единый заказ на отправку.

Метод доставки: клиент просто выбирает транспортную компанию из списка при формировании заказа, а оплачивает при получении его в ТК. Единственная сложность с Почтой России - там требуется оплата при отправке (наложенный платёж не используем). В этом случае используем сторонний онлайн-калькулятор для расчёта после фактической сборки у полной упаковки заказа. Т.е. клиент платит в 2 приёма, что неудобно ни ему ни нам.

 

Возможно, я и другие присутствующие что-то изменили бы в плане доставки, если вы поделитесь своим опытом.

Если данная функция будет востребована, можно с большей вероятностью надеяться на появление её в модуле обмена.

Ясно. Т.е. если сказать в сухом остатке: вы либо доставку не учитываете (отправляете ТК с оплатой клиентом услуг ТК), либо выставляете дополнительный счет отдельно, чисто на услуги доставки. Ясное дело, что опенкарт тут вообще никаким боком не участвует, ни в первом ни во втором случае.

Далее, ваш нюанс состоит в том, что вы оптовик. Для розницы, такой метод, какой используете вы, не приемлем никак. Особенно, если расчет за заказ с доставкой осуществляется клиентом путем предоплаты и сразу, например, путем предоплаты банковской картой. Но тогда вопрос - здесь все оптовики? Розничных интернет-магазинов, торгующих с доставкой, в числе пользователей модуля, здесь нет? Или розничники с доставкой есть, а просто понимания как надо сделать - нет?

Когда я смотрел код модуля, я понял, что автор модуля использует опенкарт как терминал-витрину в торговом зале. Т.е. доставки, как таковой, у него тоже попросту нет. Зайдите сами на www.tesla-chita.ru и убедитесь сами. А раз нет, то и внимание к этому вопросу соответствующее.

Теперь, как оно должно быть. Не как оно есть сейчас с модулем (потому, что оно сейчас вообще никак), а именно - как оно может/должно быть.

Для розничников актуально в первую очередь.

Вариант 1, упрощенный. Сойдет, до поры до времени и можно настроить быстро. Первым делом, подключается самый простейший модуль доставки, по типу MultiFlat https://opencartforum.com/topic/19535-multidostavka-free/ и там настраивается несколько типовых методов доставки - почта, ЕМС, СДЭК и т.п.. Я, как бывалый розничник, за много лет работы, уже примерно знаю, сколько у меня в среднем стоит типовая посылка отправляемая тем или иным способом, по этому, в качестве стоимости доставки, просто проставляю среднюю базовую стоимость. Заказ экспортируется в 1С, там ему должна автоматически сопоставится услуга. Стоимость этой услуги я меняю на окончательную уже в 1С, на основании своего огромного опыта. Из 1С я же и отправляю клиенту калькуляцию заказа электронным письмом. А в заказ в опенкарте, эта измененная стоимость попадет обратно тоже, при последующем сеансе обмена, т.к. обмен данным заказов двухсторонний. Недостаток данного метода в том, что я не могу сразу принять оплату заказа, т.к. конечная стоимость доставки не ясна, пока он не экспортирован в 1С и не был там обработан.

Вариант 2, когда всё уже хорошо и уровень зрелости процессов автоматизации на нужном уровне - товарный справочник причесан, стоят все необходимые логистические значения - габаритные параметры брутто и вес брутто. Брутто, если кто не знает, это товар в упаковке. В опенкарте подключаются уже продвинутые модули доставки, со встроенными калькуляторами, имеющими доступ к API поставщиков услуг доставки. Эти модули, на основании логистических параметров груза из товарного справочника и адресных данных заказа, могут достаточно точно посчитать стоимость доставки. Соответственно, заказ в опенкарте получается полностью рассчитан - можно спокойно принимать предоплату непосредственно в опенкарте, через соответствующие модули оплаты. Далее, заказ экспортируется в 1С. Услуга доставки, уже полностью рассчитанная, сопоставляется модулем с соответствующей услугой в 1С и с этим заказом, по сути, уже ничего не надо делать, кроме как менять его статусы, по мере поступления информации об оплате и отгрузке.

От варианта один, по мере облагораживания справочника номенклатуры, можно перейти к варианту два и далее уже просто наслаждаться процессом правильной автоматизации.

Во всей этой благодати не хватает малого - связать названия способов доставки в опенкарте с названиями услуг из 1С и передать в 1С их стоимость. Именно этому и было посвящено мое ТЗ, а самому вопросу уже два года как скоро исполнится. Рано или поздно, а скорее очень поздно, думаю, что-то подобное все таки будет сделано. В качественных платных решениях интеграции все это, разумеется, есть.

Вы просили поделится опытом - я поделился.

Давайте предельно упростим понимание вопроса, чтобы было ясно, о чем идет речь.

Вы в 1С (именно в 1С) услугу доставки в заказ клиента (счет клиенту) включаете?

Если НЕТ - тогда вопрос снимается вообще, т.к. доставку вы не учитываете и предмета обсуждения просто нет.

Если ДА, тогда вопрос - каким образом вы формируете информацию о доставке в заказе в опенкарте и формируете ли эту информацию вообще? Как я понял, в опенкарте вы не используете никаких модулей доставки, а просто передаете в 1С чисто список номенклатуры. Может, вы потом клиенту звоните и обсуждаете с ним вид доставки по телефону, а потом забиваете руками нужную услугу в 1С, не знаю.

7 часов назад, Sfeotable сказал:

Уважаемый автор, без Вас в этой проблемме не разобраться. Прошу не проигнорируйте, пожалуйста!

Автор немного закопался в растущей и в ширь и вкось функциональности модуля.... Боюсь, и в этой проблеме тоже, как и во многих других, вам надо будет или разбираться полностью самостоятельно или забыть и забыть про модуль, на полгодика примерно.

Чтобы мой пост не был простым брюзжанием, хотелось бы искренне надеется, что раз уж модуль в процессе своей эволюции так размахнулся, то уже неплохо бы соразмерно его размаху, ввести хоть какую-нибудь минимальную систему управления требованиями - создать структурированный список пожеланий, актуальный лист текущих багов, простой и понятный план ближайшего развития, включающий реализацию пожеланий и устранение выявленных багов.

Можно подключить к этому необходимое количество энтузиастов, если сил одного разработчика на это совсем не хватает. Наверняка найдутся желающие.

Я сильно извиняюсь, оно конечно хорошо, когда много чего есть в программе, но еще лучше, если это работает как часы.

-------

P.S. Виталий, можете не читать мое ТЗ на реализацию доставки - я уже ответа от вас не жду! Устал уже месяц ждать, забил!  И вы тоже забейте, не беспокойтесь, пусть вас на этот счет неудобства никакие не тревожат! 

Наверное, либо вообще никто доставкой в интернет-магазинах никогда не пользуется и никуда заказы не доставляет, хотя странно очень, либо как то для себя вопрос с доставкой путем кривых костылей к вашему модулю решили.  Ну или на фоне других масштабных проблем с интеграцией, просто еще к этому даже близко не подошли. Можно с имеющейся функциональностью жалкое подобие доставки соорудить. Выглядеть это будет крайне рукожопо, но тут не до жиру, видимо.

P.S.S. Да, Виталий, уже скоро, совсем скоро, исполнится ДВА ГОДА, когда я впервые поднял тему доставки и связанной с этим кривизной работы с адресами в модуле. Можете посмотреть сами, на первой странице данной темы. Скоро отпразднуем!  Подумать только, как быстро время пролетело... Только вот воз и ныне там!

Сообщите название счастливого шаблона.

9 часов назад, MRvagrant сказал:

Работаю с УНФ недавно, завожу контрагента примерно следующим образом: Продажи -- Покупатели -- Создать -- Заполняю данные -- записать и закрыть

Поправьте буду признателен 

Начнем с того, что пользоваться нужно релизом не ниже 1.6.13, а лучше вообще самым свежим 1.6.14.

Во первых, создавать клиента лучше из самого заказа, а не заранее, через справочник контрагентов - банально экономите время на лишних кликах. К тому же, система будет вам предлагать по ходу ввода ФИО разные варианты уже имеющихся клиентов, что позволит процентов на 70 избежать создание дублей. Вот вы набили нового клиента, система не нашла похожих и предложила создать. Нажали "создать" - вбитые вами в заказе ФИО автоматом прописались в новой карточке контрагента поля в разделах "Компания" и "Представление в программе" - тоже сэкономили на кликах.

Теперь главное - не обращайте внимание на слово "Компания". Тип клиента задается в раскрывающемся ниже списке "Юридические данные", в одном из предлагаемых вариантах выбора: "Юрлицо", "ИП", "Физлицо", "Гос. орган". Вам нужно выбрать "Физлицо".

В общем, осваивайте УНФ как следует. Обменами заниматься реально рано.

А глюк обмена выражается в следующем:

1) Из опенкарта импортируется новый клиент новую карточку контрагента. Там ФИО, телефон, адрес, емейл.

2) Заходите в карточку свежеимпортированного контрагента, просто нажимаете "сохранить", либо чего-нибудь делаете и нажимаете "сохранить" и выходите.

3) Заходите снова - опа, куда-то пропали данные емейла и телефона! Просто исчезли из карточки.

Чтобы этого глюка не было, надо использовать другой набор тегов при передаче данных контрагента в 1С. Этот глюк был выявлен и пофиксен мной еще полтора года назад, но до сих пор информацию к сведению не принята.

Разумеется, тот набор тегов, с которым данный глюк не проявляется, был взят мной не с потолка, а путем изучения обмена UMI-CMS с УНФ. Было как-то странно, что работая с модулем глюк был, а когда делал тоже самое через UMI - глюка не было. Пришлось "ловить" отладчиком точку передачи данных из UMI в УНФ и смотреть, какие теги там использовались для создания контрагента. И если UMI, интернет-движок которых активно продвигает 1С в своих решениях используют определенные теги, думается, что это не просто так делается.

Вы давно работаете с УНФ? То, что у вас на скриншоте - это не проблема, а похоже, некоторое недопонимание вами специфики работы в УНФ.

Если не трудно, объясните, как вы заводите контрагента "руками" (без модуля, а просто в работе), я скажу, как это сделано у меня. Я работаю в УНФ с 2012 года.

Но вас на самом деле ждет и проблема с модулем. Давайте, разберем в начале вопрос номер один, который я выше поднял, а потом, проверим вместе и решим два.

Типовые задачи, надо пытаться самому решать. Сделать нормально отборы номенклатуры, участвующей в обмене, проверить и заполнить корректно все позиции в этих отборах. Проверить прочие связные справочники (виды цен, например). Картинки у товаров должны быть в формате, который воспринимает опенкарт, размеры изображений тоже желательно подбирать адекватные. Грубо говоря, чтобы обмен строился на полностью корректном и целостном наборе данных. Лихо с кондачка на исторически накопленной каше, как правило, ничего не получится. Там артикулы забыли прописать, здесь их задублировали и т.п.  - оно все вылезет в итоге в ошибках обмена. Лучше вообще начать с группы из 1-3 наименований, чтобы добиться положительного результата, а дальше уже делать по образу и подобию.

В ‎29‎.‎04‎.‎2018 в 14:43, Vamirus сказал:

Доброго времени Вам и трудам Вашим!

Пытаюсь сочленить ОС 2.3.0.2.3 и УНФ 1.6. при помощи Вашего Труда.

Не загружаются на сайт цены и количество. Пробовал выгружать в файловом режиме, получаются 2 файла. В файле offers.xml есть и цены и количество...

Подскажите, как восстановить справедливость...

Заранее благодарен и огромное спасибо за Ваш труд!

Такие вопросы здесь разбирают сугубо самостоятельно, либо сразу предлагают решить задачу "под ключ" на возмездной основе, если своей квалификации не хватает или просто лень копаться.

Коллеги, никто вообще не использует в своем интернет-магазине модули доставки?

Или использует?

Можно вопрос, отличный от конвертации валюты? Вы торгуете с доставкой?