Вы во многом правы, но часто передергивпете. К примеру транзакции все отдаются. И у меня мой отчёт в один один сходиться с озоновским отчётом из раздела финансы.
Вот по мне идеология linq будет лишним в 1с. Хотя она там в каком зачаточном виде есть. Почти прямой sql запрос, только на русском читается гораздо легче, чем вот такие тяжёлые соединения таблмц лепить через linq. Но это дело привычки.
Раз такая пьянка. Можно тоже высказать пару пожеланий. Хочется новый метод в перфоманс api. Суть методика такова. Получить список рекламных компаний по которым были начисления за указанный период. А то приходиться по всем компаниям заказывать отчёт, что явно нагружает процесс. . Когда тусуете колонки в csv отчётах, тоже бы предупреждали об этом. И в отчёте по товарам в оплате по заказ добавить возможность группировки по дням. А то приходиться за каждый день отдельно заказывать. Чтобы скачать месяц уходить как минимум час и 30 запросов, а можно было бы одним обойтись.
Да, я знаком с такими задачами, более того, сам ежедневно использую интеграцию с внешними системами. Однако моя задача решена другим способом — данные из внешних источников загружаются в 1С. На мой взгляд, для моих целей этот способ предпочтительнее по следующим причинам:
База 1С содержит более полный и оперативный объем информации. Если бы данные выгружались из 1С во внешние системы, пришлось бы решать проблему синхронизации, особенно при работе задним числом: отслеживать, с какой даты нужно произвести выгрузку. В моём же случае данные в 1С остаются основным и наиболее консистентным источником.
В вашем сценарии для настройки выгрузки из 1С всё равно потребуется программист 1С. Но ключевое отличие в том, что для построения отчёта во внешней системе мне пришлось бы дополнительно разбираться в её интерфейсе. В моей же схеме все необходимые отчёты настраивает тот же программист 1С в привычной среде, да и без программиста можно что то поменять самому,
Разумеется, в определённых ситуациях ваш подход может быть более предпочтителен. Как раз такие случаи я и хотел обсудить своим первым вопросом.
В статье расписано как вытянут данные из 1с. Но в примерах показаны дашборды, которые в 1с, на скд делаются за 5 минут, без всяких танцев с импортом данных. Так и з
Написано то хорошо, но как селлер озон, знаю что все эти алерты не всегда работают, или работают не на ползовптелей сервиса. Последний пример, у нас единственный канал обращений, это техподдержка. Пишу им, что вы обещали что заказы сделанные после 16.07 в кластер Красноярск не должны попадать в расчёт среднего времени. Тех поддержка как обычно изголяется как может, доказывает что озон безупречен, и не допускает ошибок, а я читать в школе не научился. Заместо простой вещи передать проблему в тех отдел, тебя говорят, больше нам добавить не чего, и закрывают тикет в общем со стороны все выглядит иначе чем вы рисуете.
Отвечу за автора, и на примере озона и собственного опыта. Озон такая площадка, где даже с платной внутренней аналитикой, тебе показывается только хорошее, чтобы селлер витал в облаках, и думал как у него все хорошо. Поэтому те данные что дает API, могут дать более глубокое понимание процесса. Если пробежаться по воронке продаж: 1)К примеру у вас отличный CTR, но конверсия в корзину/заказы ни какая, значит у вас к примеру "кликбейтная" фото, а дальше описание карточки или там отзывы плохие. И да именно это вы можете увидеть и штатной аналитикой, а сравнить разные периоды, чтобы выявить возможную причину уже не совсем можете. 2) Вы можете увидеть % выкупа, и если он низкий, опять же задуматься о причинах "покатушек", устранить их по возможности, тем самым снизив расходы на логистику. 3) Оценить в динамике эффективность рекламы и цены. Например эту неделю мы торгуем, по завышенной цене, и завышенной рекламе, какая маржинальность по итогу выше. И что нам надо от этого товара, высокая оборачиваемость с низкой ценой или высокая маржинальность.
Немного сумбурно, и не все варианты описаны. Но польза от аналитики получаемой по API есть.
Спасибо за приглашение. Но я из Новосибирска, поэтому в таком формате не могу принять ваше предложение. Но мы же в 21 веке живем, поэтому ни кто не отменял онлайн общение, ну это если у вас видимо есть интерес, по интеграции с 1С. У меня есть интерес услышать мнение и потребности крупного игрока, а то все мои знакомые селлеры отмахиваются, да зачем мне это, это тяжело, прибыль есть, а что там в разрезе каждого товара.... да нет на это времени.
Я как начинающий селлер на озоне, себе сразу сделал подобные отчёты, правда в 1с затягивал себе данные. Кто бы что ни говорил про 1с, но строить отчеты через СКД там очень удобно., и на самом деле почти все что вы тянете оттуда, оно в принципе и так рассчитывается заранее, но для этого сначала надо посчитать процент выкупа, процент оборачиваемости . Мне же по факту был интересен процент дрр, так как у начинающего селлера с новыми и небрендированными товарами, это основная и непредсказуемая статья расходов. У вас с этим проще, и товар брендированный и и карточки кже прокаченные. По факту пришёл к выводу, да я знаю, и даже почти в онлайне знаю, свою прибыль или убыток от продаж. Но толку от этого для меня мало. 80 % продавцов, там торгуют, и не догадываются, что торгуют в минус, и поэтому спать спокойно, а я знаю, и не сплю спокойно.
Я не спец в этой области. Но я правильно понимаю проблему? Мы имея всего 200 методов api , запутались в том какой сервис api должен отвечать на тот или иной запрос конечного пользователя, и поэтому изобретаем велосипед, заместо того чтобы проанализировать свой код, и понять кто и на что отвечает? Героически. Но я повторюсь, я не спец. Но думаю что только один сервис должен отвечать на конкретный запрос, и таблицу маршрутизации надо иметь на этапе тз, а не по факту разбираться, что мы там накодили.
Вы во многом правы, но часто передергивпете. К примеру транзакции все отдаются. И у меня мой отчёт в один один сходиться с озоновским отчётом из раздела финансы.
Вот по мне идеология linq будет лишним в 1с. Хотя она там в каком зачаточном виде есть. Почти прямой sql запрос, только на русском читается гораздо легче, чем вот такие тяжёлые соединения таблмц лепить через linq. Но это дело привычки.
Раз такая пьянка. Можно тоже высказать пару пожеланий. Хочется новый метод в перфоманс api. Суть методика такова. Получить список рекламных компаний по которым были начисления за указанный период. А то приходиться по всем компаниям заказывать отчёт, что явно нагружает процесс. . Когда тусуете колонки в csv отчётах, тоже бы предупреждали об этом. И в отчёте по товарам в оплате по заказ добавить возможность группировки по дням. А то приходиться за каждый день отдельно заказывать. Чтобы скачать месяц уходить как минимум час и 30 запросов, а можно было бы одним обойтись.
Да, я знаком с такими задачами, более того, сам ежедневно использую интеграцию с внешними системами. Однако моя задача решена другим способом — данные из внешних источников загружаются в 1С. На мой взгляд, для моих целей этот способ предпочтительнее по следующим причинам:
База 1С содержит более полный и оперативный объем информации. Если бы данные выгружались из 1С во внешние системы, пришлось бы решать проблему синхронизации, особенно при работе задним числом: отслеживать, с какой даты нужно произвести выгрузку. В моём же случае данные в 1С остаются основным и наиболее консистентным источником.
В вашем сценарии для настройки выгрузки из 1С всё равно потребуется программист 1С. Но ключевое отличие в том, что для построения отчёта во внешней системе мне пришлось бы дополнительно разбираться в её интерфейсе. В моей же схеме все необходимые отчёты настраивает тот же программист 1С в привычной среде, да и без программиста можно что то поменять самому,
Разумеется, в определённых ситуациях ваш подход может быть более предпочтителен. Как раз такие случаи я и хотел обсудить своим первым вопросом.
В статье расписано как вытянут данные из 1с. Но в примерах показаны дашборды, которые в 1с, на скд делаются за 5 минут, без всяких танцев с импортом данных. Так и з
ачем ваш сервис, можно подробней узнать?
Написано то хорошо, но как селлер озон, знаю что все эти алерты не всегда работают, или работают не на ползовптелей сервиса. Последний пример, у нас единственный канал обращений, это техподдержка. Пишу им, что вы обещали что заказы сделанные после 16.07 в кластер Красноярск не должны попадать в расчёт среднего времени. Тех поддержка как обычно изголяется как может, доказывает что озон безупречен, и не допускает ошибок, а я читать в школе не научился. Заместо простой вещи передать проблему в тех отдел, тебя говорят, больше нам добавить не чего, и закрывают тикет в общем со стороны все выглядит иначе чем вы рисуете.
Отвечу за автора, и на примере озона и собственного опыта. Озон такая площадка, где даже с платной внутренней аналитикой, тебе показывается только хорошее, чтобы селлер витал в облаках, и думал как у него все хорошо.
Поэтому те данные что дает API, могут дать более глубокое понимание процесса. Если пробежаться по воронке продаж:
1)К примеру у вас отличный CTR, но конверсия в корзину/заказы ни какая, значит у вас к примеру "кликбейтная" фото, а дальше описание карточки или там отзывы плохие. И да именно это вы можете увидеть и штатной аналитикой, а сравнить разные периоды, чтобы выявить возможную причину уже не совсем можете.
2) Вы можете увидеть % выкупа, и если он низкий, опять же задуматься о причинах "покатушек", устранить их по возможности, тем самым снизив расходы на логистику.
3) Оценить в динамике эффективность рекламы и цены. Например эту неделю мы торгуем, по завышенной цене, и завышенной рекламе, какая маржинальность по итогу выше. И что нам надо от этого товара, высокая оборачиваемость с низкой ценой или высокая маржинальность.
Немного сумбурно, и не все варианты описаны. Но польза от аналитики получаемой по API есть.
Спасибо за приглашение. Но я из Новосибирска, поэтому в таком формате не могу принять ваше предложение. Но мы же в 21 веке живем, поэтому ни кто не отменял онлайн общение, ну это если у вас видимо есть интерес, по интеграции с 1С. У меня есть интерес услышать мнение и потребности крупного игрока, а то все мои знакомые селлеры отмахиваются, да зачем мне это, это тяжело, прибыль есть, а что там в разрезе каждого товара.... да нет на это времени.
Я как начинающий селлер на озоне, себе сразу сделал подобные отчёты, правда в 1с затягивал себе данные. Кто бы что ни говорил про 1с, но строить отчеты через СКД там очень удобно., и на самом деле почти все что вы тянете оттуда, оно в принципе и так рассчитывается заранее, но для этого сначала надо посчитать процент выкупа, процент оборачиваемости . Мне же по факту был интересен процент дрр, так как у начинающего селлера с новыми и небрендированными товарами, это основная и непредсказуемая статья расходов. У вас с этим проще, и товар брендированный и и карточки кже прокаченные. По факту пришёл к выводу, да я знаю, и даже почти в онлайне знаю, свою прибыль или убыток от продаж. Но толку от этого для меня мало. 80 % продавцов, там торгуют, и не догадываются, что торгуют в минус, и поэтому спать спокойно, а я знаю, и не сплю спокойно.
Я не спец в этой области. Но я правильно понимаю проблему? Мы имея всего 200 методов api , запутались в том какой сервис api должен отвечать на тот или иной запрос конечного пользователя, и поэтому изобретаем велосипед, заместо того чтобы проанализировать свой код, и понять кто и на что отвечает? Героически. Но я повторюсь, я не спец. Но думаю что только один сервис должен отвечать на конкретный запрос, и таблицу маршрутизации надо иметь на этапе тз, а не по факту разбираться, что мы там накодили.