Можно ли каким то образом отобразить на самом обычном сайте статусы заказов из 1с ?

База УТП

можно

Можно

(0) А в чём проблема-то?

а как это можно сделать? есть какая то последовательность действий или готовый механизм?

(4) CMS какая на сайте скажи хотя бы для начала.

(4)
1. Подписаться на событие изменения статуса.
2. Отгрузить это на сайт любым удобным способом.

Что именно вызывает затруднения?

(0) Что же это за "самый обычный" сайт?
ТП создал интригу.

веб сервис - запрашиваем статус заказа с сайта

sorry, ТС

(5) CMS самописная... сайт делал знакомый верстальщик-вебпрограммист с нуля

(8) Надо наоборот, на стороне сайта тогда.

Тогда нужно смотреть, как сделал и как статусы на сайте отображаются.

(12) дело в том что это обычный корпоративный сайт, и на нем инфа о заказах и рядом не валялась. я понимаю был бы это интернет магазин
сам сайт кому интересно - versialux.com.ua

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

1) Настроить отображение статуса через вебсервис и обработать скриптом на стороне сайта;
2) Выгружать в csv/xml/txt и скриптом и обрабатывать скриптом на стороне сайта;
3) Писать напрямую в базу сайта из 1с.
Тебе какой?

(14) Мда...

(14) начальству нужны)

2) Выгружать в csv/xml/txt и скриптом и обрабатывать скриптом на стороне сайта;
кажется самым логичным...

(18) обычный GET/POST-запрос не рассматривается? зачем это куда-то выгружать если это можно все в теле обычного HTTP-запроса отправить?

(18) Да тут ещё сам сайт сначала доработать нужно. Не вижу, куда выгружать статусы можно.

(19) Забыл про этот вариант...

(19) Респонс еще нужен. Если удастся в GET-запросе получать результат от сайта об успешной его обработке - то да. Иначе надежней через файлы.

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

(22) спасибо, кэп.

(13) И где там заказы, статус которых надо отображать?

(23) А Вы не пробовали обратиться к упомянутому в (10) знакомому веб-верстальщику, по совместительству - программисту?
Вдруг он знает, как он писал сайт и что ему нужно, чтобы отобразить статус заказов?

(23) присоединяюсь к (25). сначала может решить как оно будет храниться и где отображаться на сайте?

что-то мне подсказывает, что в базе данных этого сайта никаких заказов не предусмотрено, соответственно хранить инфу об их статусах пока негде. я не прав?

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

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

ответ в (26), не забудь свой интерес добавить в оплату :)

(26) к нему конечно и будем обращаться)

(28) постараюсь выразиться дипломатично: это неоптимальное решение.

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

(32) сейчас главное что бы работало, а на оптимальность дело наживное

(34) я же предупредил что сильно смягчаю:)

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

1. Как часто должна обновляться информация и насколько критична ее актуальность.
2. Должен ли обмен быть полностью автоматическим? Допустим ручной труд? Полностью ручной вариант?
3. Насколько критична скорость, производительность?
4. Насколько критична возможность последующей доработки?
5. Каковы временные рамки реализации? Бюджет?

имея ответы хотя бы на эти вопросы можно посоветовать конкретные пути.

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

(36) ключевое из сказанного "выгрузка конечно должна быть автоматической".

это подразумевает определенный уровень реализации и контроля ошибок.

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

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

это вариант хранения статусов в файлах html, не в базе

(38) нет сэр, это не допотопный способ, это бред сивой кобылы.

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

(38) И что эта хрень будет делать на сайте, кроме как лежать мёртвым грузом?

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

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

(28) 1. Создаешь подписку на событие, в ней регистрируешь изменение заказов в плане обмена.
2. Шедулером собираешь данные из плана обмена, формируешь csv-файлы об измиененных заказах и по ftp выкладываешь на сайт, при успешном выкладывании чистишь план обмена - удаляешь записи об изменении.
3. Шедулером на сайте обрабатываешь полученные файлы, если данные по файлу удачно загружены - удаляешь его.
4. Можно дергать сайт через http-соединение, чтобы там не запускать шедулер а скрип загрузки заказов работал сразу после выгрузки файлов на сайт.
Работает безотказно, проверено.

(40) возраст не видно ваш, может 86-год советует :) но все нынешние "мега спецы" очень любят делать все на базах данных, сайт без cms уже не сайт.
аргументируй в чем плохо?
1) выгружаются файлы на хост в в цикле по заказам в  папку.
забудь про бредятину кто скзал про "inodes" здесь тупо html файлы, база не засоряется. чел не в теме и не понял идеи.
те заказа которых нет - файлы с хоста удаляются
2) обычная страничка - хочешь в базе ее оду сделаь. хочешь в статичной html  сполем и кнопкой, по кнопке - открывается динамическая ссыль из поля текстового.

за что здесь оторвать голову?

где здесь мертвый груз? инфа лежит либо в файлах ли бо в базах, но это одна и таже инфа - в чем мертвенность груз-а-то?

"это подразумевает определенный уровень реализации и контроля ошибок."
контроль ошибок? :) здесь еще надо умудриться сделать ошибку, ни разу не делали задачу найти различия между двумя наборами данных?

запросы отменили уже?

(41) эта хрень будет выдавать статус заказа

(45) Гланды... через .опу... автогеном... Это - жестоко!

вот скока сижу на форуме, а как 1с -ники при выходе задачи за пределы 1с не могли ничего сделать  так и не могут...
мало программистов, одни операторы конфигуратора...

(50) Сделать - как раз могут. То, что в (38) - это, кроме как (49), трудно иначе охарактеризовать.

(45) сэр, вы таки продолжаете бредить.

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

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

P.S.:  я в курсе что такое html-файл, спасибо. а вот вы не улавливаете что такое inodes и чем чревато исчерпание свободных.

(51) отец :) - аргументируй плиз, метод рабочий, знаний сайтостроения автору не нужно, может реализовать задачу сам - все будет работать. сама простота реализации покая "спецам" не дает
по возрасту застал же статичный html?

(52) минусы в студию, жду....
это еще надо умудриться "живыми заказами" забить inodes

(53) Застал, конечно.
Вот только это и называется - "через .опу". Тем более, что Вы, уважаемый, даже не потрудились выяснить - какая задача стоит перед ТС, а предлагаете "решение".

(45) что здесь не подходит под задачу?
в моей идее:
выгрузка на хост всех нужных заказов со статусами: можно ручками, можно в регл. процедуру по расписанию.
результат: на сайте вбив номер заказа - увидем его статус.

(56) Не... Скучно... Давайте помедитируем над тем, как у человека на сайте .htaccess настроен (перед тем, как проверим работоспособность Вашего решения со "статическим html") :-)
Затем поинтересуемся, будут ли посетители сайта рады тому, что их заказы может просматривать любой желающий.
Ну о таких мелочах, как дизайн сайта, требуемая функциональность и т.п. - Вы ведь даже говорить не желаете.
А всякая эффективность - её вообще... через ту самую .опу. Тем самым автогеном.

(54) что есть "живые" заказы?

файлы старых закрытых заказов предлагается чистить по крону я полагаю? или все же историю храним?

если храним историю то файловая система забьется на раз-два.

даже если оставить за кадром бессмысленное хранение данных и представлений в отдельных файлах на каждый набор, каким образом веб-мастер должен это все хозяйство встраивать в текущую системы макетов сайта? надеюсь не нужно напоминать что сайт УЖЕ существует?
а если там смена дизайна грянет? представляю к тому времени пара тысяч html-файлов и их все нужно будет переписать?

работать с этими наборами как? в один прекрасный момент понадобится отбор заказов по датам или контрагентам прямо на сайте. и что тогда? find, grep?

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

Да ерунда всё это! По той простой причине, что на любом сервере, на любом сайте настроены так или иначе права доступа. В том числе и на запись. О чём в (45) доблестно забыто.

(59) ну на vps или на дедике оно принципиально реализуемо. отгружать это куда-то туда по ftp в директорию с правами 644.

но зачем?.. :)

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

(60) Так о том и спич, что решается никем не поставленная толком задача для неизвестно как написанного неизвестно на чём размещённого сайта :-)

(60)+

был не прав. HTTP Basic Authentication же.

(61) задача-то толком не поставлена, но это проблема скорее ТС.

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

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

зачем тут какие-то велосипеды изобретать ума не приложу.

(61) да обсуждаем сами не знаем что :)
дизайн тут ваще не причем, инфа одельно, дизайн отдельно, в наших страничках мы будум юзать либо существующие стили либо свои
(58) выгрузка автоматом же делается, будет новый дизай - поменяй css вот тебе новый, если сайт (что мало вероятно) кривой и в каждой страничке дизайн прописан - так же в автомате новый и пропишется

(61) путем нехитрых манипуляций удалось выяснить что сайт написан на php.

(65) + а также что сайт слегка дыряв:)

(0) у вас на сайте в футере неверно прописывается ссылка на новости

<a href="http://versialux.com.uarus/news/">Новости</a>;

очевидно там после .ua отсутствует слэш

(65) Спасибо. Я, видимо, те же манипуляции проделал :-)