Добрый день!

На постоянное сотрудничество ищем веб-разработчика.
Кому интересно и актуально?

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

Это комментарий оставленный в shop.1c.php

Я себе всю башку сломал, это как должно выглядеть?
Может быть я что-то упускаю, но в моем понимании в предложении это

Это то что в скобках в наименовании типа цены?


Вообще, проблема больше в том, что в у меня пусто...
А какие там вообще параметры должны быть и как они должны выглядеть в приходящей xml'ке? Дайте, пожалуйста, хоть один пример такого файла.
Суть вообще в том, что я ни черта до сих пор понять не могу, как посадить несколько типов цен из этой XML'ки в диафан, что за входящие параметры такие должны быть, чтобы CMS сама, из коробки, проставила товару две цены?

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

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

Или убрать остаток из коробки вообще, и писать кол-во в свойство товара? Пусть будет параметр с типом число

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

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

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

Со скидками не работал, не знаю, даже трогать их не приходилось.

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

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

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

Правильно ли я понимаю следующее?!...

Чтобы диафан начал принимать несколько цен, нужно в 1С настроить товары таким образом, чтобы они выгружались как бы отдельными дополнениями-предложениями к товару, т.е. являлись вариациями того самого искомого товара, а эта вариация в ИД товара в файле выгрузки обозначается через решетку #?
Т.е.,

Имеем две вариации товара в предложении:
1) <Ид>dee6e178-55bc-11d9-848a-00112f43529a#3df1947e-7886-11df-b33a-0011955cba6b</Ид>
2) <Ид>dee6e178-55bc-11d9-848a-00112f43529a#3df1947d-7886-11df-b33a-0011955cba6b</Ид>
И у каждой вариации имеется общая характеристика "Тип цены", но у первой значение "Оптовая", у второй "Розница", а цену для такой сборки товара он берет из <цены>?

Пример


Такая вот конструкция файла XML мне в итоге выгрузила нормально - ниже скрин



Одно но...Как бы, на каждую такую модификацию, т.е. вариацию товара, идет отдельный учет кол-ва, к примеру, у нас 5 синих футболок, и 3 зеленых.
А как быть, если нужно, чтобы кол-во товара было одно на все эти вариации, и при покупке не минусовалась одна синяя или одна зеленая, а минусовалась общее кол-во?

Я, видимо, что-то фундаментальное упускаю, может быть в выгрузке 1С'ник у клиента что-то не учел, но в пришедшем XML 2 цены, и видимо, как то можно тогда без тотальной переделки методов цены это загрузить?

РЕШЕНО КОММЕНТОМ НИЖЕ


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

Вот там говорится, что цена без параметров удаляется, я так понимаю, при условии, что если цен больше, чем 1.
А что это за параметры цены вообще, как они описаны в xml?
Это <ХарактеристикиТовара> ?
Если это характеристика товара, например

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


Что мне непонятно, как должен выглядеть XML файл, чтобы создалась характеристика "Тип цены", чтобы в нем было 2 поля с ценой и чтобы им можно было задать свои значения. Я уже хрен знает сколько сижу с этой задачей, не понимаю, что аж полез в сам 1с разбираться

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

Не доходит до меня один момент, а именно (поправьте меня, если не так шаги расписал):
Выгрузка происходит в папку сайта, разбирается xml, все это рассовывается по своим таблицам в БД, получаем стандартный реузльтирующий массив, как с обычным товаром, и пользуемся на здоровье?
Вот тут меня напрягает один момент, который я никак не вдуплю:

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

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

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

Добрый день.
Порыскал поиск, может не так искал, но пока ничего не попалось.

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

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

Скажем сразу, не профаны.
Само собой, заходим через модуль админа.

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

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

Наврал, не там правил, как оказалось.

Изменение названия папки с исходного userfiles на userfls помогло

Ответил человечку выше

Там userfls, которого по сути в скаченном дистре нету, userfiles - да, плюс - что на хостинге, что на локале.

Название папки менял - толку 0. в инсталл файле названия с userfls на userfiles менял - тоже нету толку

Только что скачали, горит проект.
Собственно, косяк с userfiles.
Как исправить?

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

От Вас – стоимость и сроки выполнения.