Просмотр полной версии : Как RK7 хранит данные
Доброго времени суток.
Подскажите где RK7 хранит данные?
Стоит SQL сервер - в нем висит БД, но как выяснил есть еще файлы с расширением udb. Какую роль в хранении данных играют они?
Хочу попробовать экспортировать данные из 1С7 в SQL - базу r-keeper. Кто-нибудь делал подобное? Какие есть еще варианты переноса данных из 1С в R-keeper?
Заранее спасибо за ответы.
VampireKB
29.12.2014, 21:22
Эмм,если ты хотябы глазком заходил в БД РК7 ,то ты увидел бы ответы на все свои вопросы....
Что тебе поомешало проанализировать структуру БД ?
Если Вы имеете ввиду раздел "Таблицы" - я смотрел его. В принципе из названий можно разобраться какая таблица за что отвечает (вытягивал данные из них в 1С).
Вопрос возник при попытке создать копию БД r-keeper:
- в SQL создал копию БД
- зашел в R-keeper (станция менеджера) - Сервис - экспорт данных - Настройки внешних БД
- выбрал Microsoft SQL Server 2008
- в строке соединения изменил Catalog=RK7 на Catalog=RK7_test
- перезапустил сервер справочников
- опять зашел в R-keeper (станция менеджера) - меню - создал элемент с названием TEST
- в обратном порядке подключил начальную БД
и в ней присутствует созданный мной в тестовой базе элемент.
Почему так?
справочники хранятся в rk7.udb и выгружаются в SQL. Но не наоборот.
Расскажите, что хотите выгрузить и зачем.
SQL - продажи и справочники. Продажи попадают из check.udb, справочники из rk7.udb. Использование SQL исключительно для быстрой постройки отчетов. РК7 может работать и без SQL.
Если Вы хотите заводить меню в 1Се и импортировать в РК7, как можно было делать с РК6 до версий 6.9Х, где ввели закрытую базу, то с 7кой такой фокус не пройдет =(
Продажи в SQL попадают, вроде, после пересчета любого куба.
Спасибо за ответы.
lEEFT - то, что хотел узнать. К сожалению ответ не порадовал :(
Если Вы хотите заводить меню в 1Се и импортировать в РК7, как можно было делать с РК6 до версий 6.9Х, где ввели закрытую базу, то с 7кой такой фокус не пройдет =(
А есть какие-нибудь другие варианты экспорта из 1С в R-keeper с помощью которых можно реализовать перегрузку справочников?
VampireKB
30.12.2014, 12:31
А есть какие-нибудь другие варианты экспорта из 1С в R-keeper с помощью которых можно реализовать перегрузку справочников?
через их программу iXML (или как-то так) . Кажись общение(запись данных) с манагером там бесплатное.
А есть какие-нибудь другие варианты экспорта из 1С в R-keeper с помощью которых можно реализовать перегрузку справочников?
Да, было что то XML-ное
Другой вопрос: зачем?
Если речь про разовую загрузку (допустим меняется ПО на RK7), то проще (быстрее, дешевле) руками заколбасить, или ч/з импорт из текстового файла.
А если постоянно так делать - вообще смысла не вижу. Только чья то прихоть... Но тогда эта прихоть будет стоить очень не дешево...
А если постоянно так делать - вообще смысла не вижу. Только чья то прихоть... Но тогда эта прихоть будет стоить очень не дешево...
Нет, это очень удобно для бухов, если все интегрированно с 1С. работал в компании, где редактор не открывался, СХ использовали для перекачки продаж в 1С. Все накладные регионы заводили в 1С. Штат уменьшается, а КПД бухов возрастает.
Другой вопрос: зачем?
В некоторых чеках выбирается контрагент (допустим поел владелец ресторана, или гостя покормили). В конце месяца владелец хочет видеть отчет во сколько ему обошлось покормить того или другого. Контрагенты соответственно могут добавляться в любой момент времени. Хотел сделать чтобы они автоматом выгружались из 1С в r-keeper.
Но если не разберусь с XML, прйдется наверно делать наоборот из r-keeper-а тянуть в 1С.
А если постоянно так делать - вообще смысла не вижу. Только чья то прихоть... Но тогда эта прихоть будет стоить очень не дешево...
Нет, это очень удобно для бухов, если все интегрированно с 1С. работал в компании, где редактор не открывался, СХ использовали для перекачки продаж в 1С. Все накладные регионы заводили в 1С. Штат и КПД бухов возрастает.
Но тогда эта прихоть будет стоить очень не дешево...
Все зависит от программиста 1Са, если он дешевый, то и редакция Ваша будет страдать. Есть печальное наблюдение, где контора тратит деньги на СХ, выгрузку, да еще и ЗП программиста, которые не может адекватно переписать импорт от юсиков. При наличие нормального специалиста можно экономить деньга на софте, кол-ве ЗП бухов, которых нужно больше из-за объема работ. Или платить одному или отделу + м2 в офисе. Тут выбор чисто экономический: или тратить больше или жестко экономить.
В некоторых чеках выбирается контрагент (допустим поел владелец ресторана, или гостя покормили). В конце месяца владелец хочет видеть отчет во сколько ему обошлось покормить того или другого. Контрагенты соответственно могут добавляться в любой момент времени. Хотел сделать чтобы они автоматом выгружались из 1С в r-keeper.
Но если не разберусь с XML, прйдется наверно делать наоборот из r-keeper-а тянуть в 1С.
Это можно делать через не фискальные валюты, которые автоматически и реалтайм передаются на кассу (в зависимости от настроек редактора). Далее в Кипере делать отчет с разрезом по валютам и у Вас все будет, что хочет видеть директор.
Штат уменьшается, а КПД бухов возрастает.
Штат и КПД бухов возрастает.
Второй вариант мне кажется ближе к истине :)
Кесарю - кесарево...
Если говорить о 6-ке, то там было множество вариантов альтернативных редакторов и отчетов (и на базе 1С, и просто написанные с нуля). Структура (и возможности) 6-ой версии были элементарны, по сравнению с 7-кой.
Писать (пусть даже в 1С) с нуля функционал для редактирования справочников RK7 - глупая затея.
Если делать только необходимый минимум (номенклатура + цена), то смысла нет. Если пилить весь функционал, то ценник выйдет космический, плюс баги, плюс катастрофа когда программист 1С уйдет и на его место придет новый, который, по обыкновению, авторитетно заявит что все что было написано ранее - это хрень и не правильно, поэтому он сейчас быстренько (за пару месяцев) и не дорого (за пару сотен) сделает все как надо!
Контрагенты соответственно могут добавляться в любой момент времени. Хотел сделать чтобы они автоматом выгружались из 1С в r-keeper.
Ну допустим вы это сделаете, получите следующую цепочку: 1С - Справочники RK - Касса.
прйдется наверно делать наоборот из r-keeper-а тянуть в 1С.
На выходе: Справочники RK - Касса (в этот момент уже получили результат и смогли на кассе закрыть чек на нужного контрагента) - 1С (потом, в любое удобное время).
Ну допустим вы боитесь что в Кипере заведут контрагента как то не так, как хочется видеть его в 1С - ну сделайте справочник соответствия. В Кипера это будет "Зицпредседатель Фунт", а в 1С "ООО Рога и Копыта".
При наличие нормального специалиста можно экономить деньга на софте, кол-ве ЗП бухов, которых нужно больше из-за объема работ. Или платить одному или отделу + м2 в офисе. Тут выбор чисто экономический: или тратить больше или жестко экономить.
Вот категорически не соглашусь с этой позицией!
Чем хорош Кипер + Стор? Это законченный, готовый, документированный продукт. Да, можно сейчас начать рассуждать о том что он не законченный и не документированный, и что там не хватает того или иного... Но, База, на 95% удовлетворяющая потребности любого объекта - там есть.
Отсюда получаем легкую заменяемость как внутренних сотрудников, так и внешней, обслуживающей Кипер, организации.
Что имеем в случае 1С: "нормального специалиста", который уникален и в единственном числе. Его уход (а рано или поздно он уйдет, или его "уйдут", т.к. аппетиты у таких спецов растут быстро), если не обрушит работу предприятия, то как минимум, поставит крест на дальнейшем развитии, на продолжительное время.
Пример, который постоянно перед глазами: те кто сидят на типовых конфах 1С (я говорю именно про бухгалтерию), не имеют особых проблем с тем что бы сменить программиста 1С. Те у кого навороченные, самописные конфы либо не хило башляют своему 1С-нику, либо раз в 2-3 года имеют кучу головняков с тем что начинают все с нуля в новыми людьми.
ИМНО.
Согласен с тем, что продукты закончены для типовых и мелких организаций, но большие организации в редких случаях работают с типовой конфигурацией.
Скажу так, что аппетиты автоматизаторов тоже не маленькие, а судя по форуму порой зашкаливают. Ладно, не будем оф-топить дальше.
В некоторых чеках выбирается контрагент (допустим поел владелец ресторана, или гостя покормили). В конце месяца владелец хочет видеть отчет во сколько ему обошлось покормить того или другого. Контрагенты соответственно могут добавляться в любой момент времени. Хотел сделать чтобы они автоматом выгружались из 1С в r-keeper.
Через XML нет проблем. В справочники добавляется бесплатно.
---------- Добавлено в 16:28 ---------- Предыдущее сообщение было размещено в 14:49 ----------
Скажу так, что аппетиты автоматизаторов тоже не маленькие, а судя по форуму порой зашкаливают.
Мы, в отличие от 1с-ников, предлагаем законченные решения, которые не надо в 99% случаев потом допиливать.
большие организации в редких случаях работают с типовой конфигурацией.
Строго говоря, 1С не очень предназначен для больших организаций. Либо там надо держать штат (не одного человека, а штат) программистов. Обычно, так и есть, вне зависимости от используемой системы.
---------- Добавлено в 16:29 ---------- Предыдущее сообщение было размещено в 16:28 ----------
прйдется наверно делать наоборот из r-keeper-а тянуть в 1С
Все равно ж через XML.
Все равно ж через XML.
Подскажите, где можно найти информацию о настройке механизма импорта/экспорта через XML?
Какова должна быть структура XML-файла?
Доброго времени суток, всем.
После некоторого изучения вопроса нашел каталог XMLInterface.
По подсказкам настроил интерфейс в r-keeper-е.
Попробовал получать данные с помощью утилиты XMLTest.exe.
Получилось вытянуть справочник CATEGLIST.
А вот при попытке записи элемента в результирующем файле появляется ошибка:
<RK7QueryResult ServerVersion="7.5.2.289" XmlVersion="104" Status="Query Executing Error" Processed="0" ErrorText="Unknown command SetRefData">
<CommandResult CMD="SetRefData" Status="Query Executing Error" ErrorText="Unknown command SetRefData" DateTime="2015-01-05T12:22:24" WorkTime="0"/>
</RK7QueryResult>
В чем причина?
Unknown command SetRefData
Утверждает, что такой команды не знает.
подскажите, а где можно почитать про доступный список команд?
SetRefData доступна только на сервере справочников. На кассовом сервере такой команды нет. Лучше использовать ветку 7.5.3, там решены все вопросы с безопасностью и есть возможность использовать XML API через HTTP.
Мы, в отличие от 1с-ников, предлагаем законченные решения, которые не надо в 99% случаев потом допиливать.
Посмею не согласиться с вами, т.к. нам просто, видимо, патологически повезло оказаться в этом 1%.
Нужные нам отчеты (сеть ресторанов быстрого питания) наш дилер не может прикрутить/сделать, а политика UCS не позволяет прыгать выше головы нашего дилера.
В итоге директора ресторанов уже который год составляют эти отчеты в Excel.
Ну, тут уж я просто обязан полюбопытствовать, что это за отчеты. Можно пример?
Ну, тут уж я просто обязан полюбопытствовать, что это за отчеты. Можно пример?
1. План поставок - он хоть и называется "план", там есть отчетные данные, которые сейчас вручную собират, а именно - последняя цена закупа и объем последнего закупа.
2. Отчет "Микс" - там гадость в том, что себестоимость выбрать нужно без бумаги. Девченки открывают каждую калькуляцию на последний день месяца и на калькуляторе считают каждую позицию.
Да - там себестоимость на дату нужна, а не за период, в этом тоже тонкость. Меню анализируем. В 1С Общепит такой отчет есть, а в SH нет.
3. Свод P&L - мы вручную собираем из SH.
4. Есть ещё ежедневные отчеты, которые можно было бы из Р-Кипера формировать, но их нет. Например, Joint Venture (форму скинуть не могу без разрешения начальства)
Все реализуемо, причем не обязательно через дилера или через UCS. Мы можем.
Отличие от 1С тут в том, что при апгрейде (в рамках основных версий) не надо будет потом все перепиливать.
Если вопрос в том, "почему это не сделал дилер", то скорее всего, ответ кроется в том, что эти задачи не были поставлены на этапе внедрения автоматизации. И, предполагаю, внедрение как таковое вообще не было запланировано и оплачено, скорее всего, оплатили традиционную пуско-наладку.
Brambrulet
12.01.2015, 19:36
Ну ... имхо - это не для дилера работа. Для реализации ваших запросов придется попрограммить, а дилеры ставят, настраивают ... ну, могут пару отчетов под вас заточить.
Ну ... имхо - это не для дилера работа. Для реализации ваших запросов придется попрограммить, а дилеры ставят, настраивают ... ну, могут пару отчетов под вас заточить.
Так мы готовы заплатить деньги за работу, но ведь сказали, что "невозможно, а в UCS занимаются типовым решением".
---------- Добавлено в 21:59 ---------- Предыдущее сообщение было размещено в 21:55 ----------
Все реализуемо, причем не обязательно через дилера или через UCS. Мы можем.
Отличие от 1С тут в том, что при апгрейде (в рамках основных версий) не надо будет потом все перепиливать.
Если вопрос в том, "почему это не сделал дилер", то скорее всего, ответ кроется в том, что эти задачи не были поставлены на этапе внедрения автоматизации. И, предполагаю, внедрение как таковое вообще не было запланировано и оплачено, скорее всего, оплатили традиционную пуско-наладку.
Я не работал в этой компании с момента открытия и не могу сказать как проходило внедрение. Знаю, что у новых клиентов обучение проводят, а мы когда новый ресторан открываем, то сами обучаем новых сотрудников.
Так мы готовы заплатить деньги за работу
За деньги - все возможно. Пишите в личку.
Brambrulet
12.01.2015, 22:25
Так мы готовы заплатить деньги за работу, но ведь сказали, что "невозможно, а в UCS занимаются типовым решением".А вот такой подход мне очень даже знаком - некоторые дилеры предпочитают не заморачиваться на тему того, чего не могут сделать сами (продать сами).
А вот такой подход мне очень даже знаком - некоторые дилеры предпочитают не заморачиваться на тему того, чего не могут сделать сами (продать сами).
И я считаю что это абсолютно правильный подход - поэтапно: расчет, установка, настройка, сопровождение - это относится к большинству проектов автоматизации. Но приходит клиент которого не устраивает типовое решение - ему нужно скрестить ужа с ежом (и желательно за небольшие деньги или в рамках бюджета типового проекта). Региональные дилеры не любят таких клиентов по стандартным причинам:
1. Платят мало а требования очень большие.
2. Нет квалифицированного персонала.
3. На такого заказчика уходит большое количество нормочасов.
4. Сотрудникам заказчика это не особо надо, а тому кому надо нет времени или уделяется времени недостаточно.
И уходят такие клиенты в инет крича о безрукости дилеров и неповоротливости ucs, рассказывая сказки о золотых горах которые могли бы быть потрачены на реализацию их простых и неприхотливых хотелок.
В Москве с этим немножко проще некоторые инсталяторы/дилеры/автоматизаторы делают - реальную сумму реализации данных хотелок умножают на 5 и выделяют время и грамотного спеца. Многие заказчики забывают о нетиповых конфигурациях на стадии просчета реализации - те кто соглашаются платить получают полную реализацию своих идей.
Brambrulet
12.01.2015, 22:53
Я с тобой полностью соглашусь, если ещё один пункт в список добавишь - частенько дилеры боятся, что клиент уйдет к тому, кто будет реализовывать "хотелку", и поэтому предпочитают внушить клиенту, что эта самая хотелка не реализуема в принципе.
Brambrulet
поправка принята
Rkeeperman
11.07.2017, 18:20
Добрый день, всем! А может кто выслать ссылку на утилиту XMLtest? (помимо ftp.ucs.ru)
А может кто выслать ссылку на утилиту XMLtest? (помимо ftp.ucs.ru)
Закинул в хранилище (https://yadi.sk/d/dzI12sjw3Kz9TD)
Rkeeperman
14.07.2017, 12:37
Закинул в хранилище (https://yadi.sk/d/dzI12sjw3Kz9TD)
Огромнейшее спасибо!
Powered by vBulletin® Version 4.2.6 LTS Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot