пропагандировали работу через Эдо, спустя год после запуска это не рабочий процесс. После подтверждения УПД в Эдо может пройти от 1 часа до одной недели до отражения этой операции в ЧЗ.
задержка поставок от крупных поставщиков по причине неполадок с ЧЗ на этапе таможни до сих пор носит систематический характер. Причем товар уже на складе а коды маркировки "задерживаются"
непонятные изменения статусов кодов маркировки, без всяких операций в чз, техподдержка реагирует "… до 10 рабочих дней"
Всё звучит хорошо. Но странная функциональность, которая приводит к появлению ошибок на клиенте «Обратитесь к администратору для решения вопросов приобретения и установки лицензий уровня КОРП», при этом в интерфейсе администрирования и настройки кластера эта функциональность никак отдельно не выделена. Это явно не «лёгкость настройки».
Весь пример это статьи как не надо подходить к новой задаче.
Для всего что описано, достаточно одного 1С Битрикса стоимостью от 5к. Но и к этому нужно подходить обдуманно — может здесь нужна совсем другая CMS.
Зачем здесь конфигурация 1С Розница, СУБД, Сервер приложений 1С?
Как написано выше нужно все таки отталкиваться от ТЗ, а не заказывать банкет на всю катушку.
Так он говорит, необязательно 1С, просто у виртуализации всегда есть накладные расходы на неё саму. К этому примешиваеться наличие «подводных камней» в не очевидных параметрах виртуальных серверов, которые существенно влияют на производительность. Всегда есть выбор — либо высокая производительность (аппаратные сервера), либо удобство администрирования (виртуализация).
Это конечно не отменяет ситуации когда правильно настроенный виртуальный сервер будет производительней, установленного «из коробки», виртуального.
Проблема только в том, что выгрузка в DT не является средством резервного копирования.
Не всегда можно восстановить базу из данного файла.
Это также официальная позиция 1С — бекап делать средствами субд или копированием файла 1CD, для файловой базы.
Чем чаще обмен, тем меньше порции — обычно несколько КБ при ежеминутном обмене.
Очистка стандартная после подтверждения от источника об успешной загрузке.
И первый и второй поток выбирают изменения для сообщения 51 — в моем случае распаралеливалась выборка данных. Удаление регистрации в данном случае никаких конфликтов не вызывало.
Спорное ограничение, которое противоречит действующему законодательству. Также есть коммерческие инструменты которые используют в своей основе прямой доступ к базе 1С ( 1С QlikView connector например), если у фирмы 1С не возникает к ним вопросов, то про остальных и речи нет.
У меня есть реализованный обмен где выгрузка была распаралелена через выполнение фоновых заданий. Алгоритм в кратце:
Разбиваем обмен по сущностям — xml строка по выгрузке каждого объекта метаданных формируется отдельно.
Выборку изменений используем только для присвоения номера сообщений текущим записям в таблицах изменений.
Выгрузку проводим по каждому объекту метаданных запуском отдельного фонового задания с указанием номера сообщений для выборки.
Возвращенные строки XML склеиваем в результирующий файл обмена.
Тому номеру который требуется исходя из логики конкретного решения.
Также удаление регистрации изменений можно выполнять не только по номерам сообщений, но и по массиву данных, по которым требуется удалить регистрацию. И, с учетом корректно сформированного массива, для этого также потребуется всего одна строчка кода. Таблицы изменений, номера сообщений, регистрация изменений это абстракция платформы которая упрощает работу с механизмом, но если эта реализация вас не устраивает всегда можно реализовать свой механизм обмена, не используя типовые механизмы или используя их частично.
Также, для высоконагруженных систем или если производительность работы объектов платформы недостаточна для нужного процесса, всегда можно спуститься до уровня базы данных и решить задачу прямой записью в СУБД — это позволяет решить все возникающие проблемы с производительностью обмена.
Для меня, средств программного комплекса 1С-SQL, достаточно для решения любых вопросов с обменом.
А что не так с обменом, точнее где проблема которую нельзя решить?
Выборка изменений тормозит — выбирайте изменения по таблицам изменений.
С записью изменений проблем не видел.
С транспортом проблема? Есть отдельные системы для обеспечения гарантированного транспорта.
На мой взгляд это замечательно когда компания проводит открытые форумы по своим продуктам. А уж цена диктуется спросом — на Infostart Event было немалое количество участников VIP с ценой по 30к руб.
Интересно сравнение результатов Relex Smile и Fempto Super Lasik. В каких случаях он более предпочтительный.
Где-то читал что сейчас по методу Relex Smile менее гарантированный результат операции получается и больший процент осложнений.
А такое же под windows возможно?
Из своих наблюдений :
Хабр превратился в рекламу средств с недоказанной эффективностью…
Куда мир катится?
Для всего что описано, достаточно одного 1С Битрикса стоимостью от 5к. Но и к этому нужно подходить обдуманно — может здесь нужна совсем другая CMS.
Зачем здесь конфигурация 1С Розница, СУБД, Сервер приложений 1С?
Как написано выше нужно все таки отталкиваться от ТЗ, а не заказывать банкет на всю катушку.
Это конечно не отменяет ситуации когда правильно настроенный виртуальный сервер будет производительней, установленного «из коробки», виртуального.
Не всегда можно восстановить базу из данного файла.
Это также официальная позиция 1С — бекап делать средствами субд или копированием файла 1CD, для файловой базы.
Чем чаще обмен, тем меньше порции — обычно несколько КБ при ежеминутном обмене.
Очистка стандартная после подтверждения от источника об успешной загрузке.
И первый и второй поток выбирают изменения для сообщения 51 — в моем случае распаралеливалась выборка данных. Удаление регистрации в данном случае никаких конфликтов не вызывало.
Компания софтпоинт использует решения с прямой записью в базу — также коммерческое решение давно присутствует на рынке.
Разбиваем обмен по сущностям — xml строка по выгрузке каждого объекта метаданных формируется отдельно.
Выборку изменений используем только для присвоения номера сообщений текущим записям в таблицах изменений.
Выгрузку проводим по каждому объекту метаданных запуском отдельного фонового задания с указанием номера сообщений для выборки.
Возвращенные строки XML склеиваем в результирующий файл обмена.
Также удаление регистрации изменений можно выполнять не только по номерам сообщений, но и по массиву данных, по которым требуется удалить регистрацию. И, с учетом корректно сформированного массива, для этого также потребуется всего одна строчка кода. Таблицы изменений, номера сообщений, регистрация изменений это абстракция платформы которая упрощает работу с механизмом, но если эта реализация вас не устраивает всегда можно реализовать свой механизм обмена, не используя типовые механизмы или используя их частично.
Также, для высоконагруженных систем или если производительность работы объектов платформы недостаточна для нужного процесса, всегда можно спуститься до уровня базы данных и решить задачу прямой записью в СУБД — это позволяет решить все возникающие проблемы с производительностью обмена.
Для меня, средств программного комплекса 1С-SQL, достаточно для решения любых вопросов с обменом.
Выборка изменений тормозит — выбирайте изменения по таблицам изменений.
С записью изменений проблем не видел.
С транспортом проблема? Есть отдельные системы для обеспечения гарантированного транспорта.
Где-то читал что сейчас по методу Relex Smile менее гарантированный результат операции получается и больший процент осложнений.