Т.е. Вы, как ответственный программист, еще и баланс им сведете ?
Задача человека к которому обращаются за услугой дать то чего от него ожидают. В данном случае клиент ожидает новую рабочую базу данных, а не рабочий механизм синхронизации данных. Сам механизм ему как таковой не нужен, в силу того что он потребуется один раз. Конечно же я ничего сводить не буду, это должен сделать клиент (если не оговорена эта работа). Но перед выгрузкой остатков я сделаю анализ данных и предоставлю клиенту максимум информации для исправления. Потом
Цитата(Batchir @ 20.03.17, 10:16)
2. Согласовал бы остатки которые необходимо перенести и выгрузил бы в эксель эти данные. 3. Утвердил данные (письменное подтверждение того что в экселе данные корректны), так потом спокойнее (не забываем про 5 фирм!!!).
Вот Вы бы взяли за работу, например, 20 чел.час и выдали свой результат клиенту. Я бы взял, например, 80 чел. час и выдал свой результат. В каком виде клиенту нужен этот результат и сколько он готов за это заплатить - решение самого клиента, мы с Вами можем лишь ему предложить решение его задачи. Одно могу сказать с моим подходом к задачам я работаю на проектах с бюджетом от 1 млн. грн. И в этих проектах выступаю и бизнес-аналитиком, и архитектором, и ведущим разработчиком. И до момента начала разработки по проекту треть бюджета уходит на "поговорить, согласовать, проанализировать".
оптимистично ))) по факту потратите намного больше. ... перенос из двух разных баз с "практически одинаковым" набором данных по 5 организациям ... ... из личного опыта, как правило в базах источниках бардак с данными, который приходится решать какими-то костылями в этих базах ...
Нет, может версию правил для переноса и напишете за это время, но что делать с тем что будет до и после написания правил? У вас ведь не заказывают написание правил конвертации, у вас заказывают результат, который заключается в том что появляется новая база с корректными данными.
Я бы наверно пошел по следующему пути: 1. Слил справочную информацию (конвертацией) 2. Согласовал бы остатки которые необходимо перенести и выгрузил бы в эксель эти данные. 3. Утвердил данные (письменное подтверждение того что в экселе данные корректны), так потом спокойнее (не забываем про 5 фирм!!!). 4. Загрузил бы из экселя остатки в документы. 5. Перенес оговоренный список документов без движений (конвертацией). 6. Перепровел загруженные документы. 7. Проконтролировал данные в базах источниках и УТП, не забываем что они должны совпасть.
И в оценку вложил бы все эти пункты, потому что какой смысл браться за работу в 15-20 часов если в итоге будет потрачено на неё, например 2 недели.
Нет, не связан. По факту телефон может быть как программный, так и мобильный (бинотел позволяет такую структуру). Вся логика работы и настройки телефонии находится в облаках. Вот эти облака и посылают все данные о звонке на веб-сервер, которые и нужно обработать. Плюсы: Вы можете находиться не за компом, принять звонок на мобильный. В 1С при этом зарегистрируется событие, которое вы потом сможете обработать (описать его и пустить дальше по бизнес процессам компании). Минусы: Телефонный звонок это также событие, которое нужно что бы отразилось моментально на рабочем столе 1С того кто принимает звонок, т.е. если к Вам поступает звонок, то сразу должна отобразиться на экране вся информация по клиенту ещё до момента поднятия трубки. Если научить сервер генерировать внешнее событие для конкретного клиента, то эта проблема не есть проблемой.
Большая часть проблем производительности 1С лежит в неоптимальных запросах. Даже многие блокировки — лишь следствие избыточного сканирования данных неоптимальными запросами. Поэтому основная задача оптимизации всегда будет в том числе в оптимизации наиболее используемых запросов. Команда Gilev.ru представляет вашему вниманию новый уникальный инструмент быстрого автоматического анализа неоптимальности запросов, позволяющий разработчику получить возможность оперативно проанализировать свой запрос и исправить в нём ошибки, не привлекая для этого 1С Экспертов.
Инструмент позволяет автоматически проанализировать структуру выполняемого запроса, план его выполнения на MS SQL и в облачном сервисе показать рекомендации, позволяющие программисту оптимизировать исходный запрос.
За основу взята обработка версии 1.5.19. Сделал несколько украшательств чисто для себя: 1. Переместил закладку плана запроса, так что б она показывала план на весь экран
2. Реализовал вывод признака наличия SCAN и SEEK...WHERE что б визуально сразу бросалось в глаза
3. "Причесал" вывод описания оператора + исправил вывод этого описания в метаданных 1С (использую 8.3.9.1818 и покрайней мере в ней не все данные отображались)
Так для информации))) В консоли не обнаружил возможности построения плана запроса. Кому как а для меня это важная фича. Я лично пользуюсь консолью гилева http://www.gilev.ru/console_setup/(скачать) На сервис не выгружаю, т.к. каждый разбор запроса стоит денег, но в консоли очень удобно представлен план запроса. Я по своему опыту это представление "причесал" и оно мне выделяет цветами все проблемные (на мой взгляд) операторы плана запроса.
Добавлю что-то новенькое в обсуждении универсальности решения: 1. В базе удаленного сервера разрабатываем web-сервис (http-сервис) 2. Разворачиваем (если не развернут) web-сервер и публикуем этот сервис. 3. В торговой конфе пишем обращение к веб-сервису: передаем/получаем необходимые данные.
Что имеем (первое что в голову пришло): 1. Никакого впн нет. Доступ к веб-серверу дело рук администратора веб-сервера. 2. Универсальность решения на стороне сервера. Операции можно вызывать из любой конфигурации, правда нужно писать работу с ними в каждой новой конфигурации-клиенте. 3. Онлайн обмен. Результат выполнения можно сразу узнать. Сервер вернет всю необходимую информацию. 4. Нет никаких фоновых 1С-ок. Обмен только по необходимости. 5. Ваша схема перерастает в более простую с меньшим количеством узлов: 1с база (касса) <> web-сервер <> 1с база (центральная)
Можете ещё показать структуру регистра ОстаткиТоваровКомпании?
т.к. база файловая, то единицей блокировки данных при записи является вся таблица целиком. Если в этот момент в базе идет "интенсивная" запись в таблицу ОстаткиТоваровКомпании, то работа с этой таблицей может быть проблемной. Нет ли случайно запросов в транзакции на чтение этой таблицы?
Попробуйте проанализировать код документов, которые пишут в этот регистр. Предполагаю что там выполняется контроль остатков перед записью, что в свою очередь вызывает тормоза из-за ожиданий на блокировках.
ИМХО тут действительно нужно проанализировать конфу как предлагают в ДЦ. Можно попробовать увеличить скорость записи данных, возможно там выполняется какой-то код, который неоправданно увеличивает время транзакции записи. Вообще решением так же может быть переход на SQL (возможно есть возможность использования какой-то бесплатной lite версии в ДЦ), тогда единицей блокировки данных будет уже запись, а не таблица и проверить что все запросы попадают в индекс при выполнении.
Правила: 13. Нельзя просить/раздавать программные продукты (ссылки, файлы по почте или ЛС, и. т.п.) от фирмы 1С (конфигурации, диски ИТС, и т.п.) и других компаний, если это запрещено лицензионным соглашением либо может нарушать чьи-то авторские права. Также запрещается обсуждать обход защиты лицензионного ПО. Подобные просьбы и обсуждения будут удаляться, а авторы наказываться;
В правилах вроде прописано что нельзя. Если с ПО понятно, то к тексту думаю нужно относиться так: Администрация не в силах выполнять проверки на авторство, это же форум где могут писать кто угодно и что угодно. Если автор опубликованного текста объявится и потребует убрать, то так и сделаем (в принципе так и делали)
Ну система позволяет к одному рабочему месту подключать N количество фискальных регистраторов. Именно поэтому он и предлагает выбор, если подключено больше 1. И именно этот алгоритм является штатным. То что хотите Вы для УТП является не штатным механизмом.
Имеем: 1. Программа 1С. 2. Бизнес-процессы компании и люди их исполняющие.
Необходимо: Оценить и дать результат насколько возможности п.1 покрывают требования п.2.
Если в точку, то нужно: 1. Сделать исследование (бизнес-аналитики изучают бизнес-процессы компании так как они есть). 2. Построить логическую модель (документирование бизнес-процессов в виде понятном для разработчиков) 3. Построить функциональную модель (наложить текущие возможности 1С на логическую модель и описать необходимые доработки для того чтобы покрытие функциональной модели стремилось к 100%). 4. Сформировать техническое задание на доработку системы (если в этом есть необходимость).
Подобным образом стоит заблокировать и другие элементы формы, которыми можно менять данные табличной части, например кнопки "Подбор", "Изменить", "Заполнить ...", если такие есть.
Попробуйте в форме документа в процедуре ПриОткрытии в конец добавить код, и свой комментарий добавьте, что б было видно что это не типовой код.
// добавлено для запрета редактирования табличной части товаров. Доступно только полным правам Если Не РольДоступна("ПолныеПрава") Тогда ЭлементыФормы.Товары.ТолькоПросмотр = Истина; КонецЕсли;
Доступность редактирования табличной части будет только у пользователей с полными правами
Насколько помню в рознице вроде можно использовать один из имеющихся ФР, у какого-то можно настройку сделать что печать ведется не на ФР и на аля чековый принтер.
Inkognito, мы поддерживаем такого рода информацию. И вообще предлагаю вынести тему из рамки новостей в другое более достойное место. З.Ы. тему в избранное
Чеки "архивируются" безвозвратно, они трансформируются в документ "отчет о розничных продажах". Как написал Егор Динин, необходимо дорабатывать УТ для того что бы чеки оставались в системе в виде архивных документов. По сути нужно дописать УТ так как сделано в Рознице.
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!