При изменении множества ячеек в каждой книге очень ускорят процесс следующие команды:
Отключаем «прорисовку» всего происходящего на экране (данные будут меняться, но Excel не будет тратить ресурсы, чтобы показать изменения пользователю): Application.ScreenUpdating = False
Выключаем автоматический пересчет формул на листе (представьте, что вы меняете значение 1000 ячеек, которые задействованы в формулах. При каждом изменении Excel будет пересчитывать формулу, ссылающаяся на данную ячейку. Гораздо продуктивнее сделать это в конце, разом). Отключаем пересчет формул перед обновлением ячеек: Application.Calculation = xlCalculateManual
После выполнения кода возвращаем пересчет формул и прорисовку обратно:
Забавно, что удалил мой комментарий, где я подробно расписал про низкую эффективность данного решения и возможные грубые наружешия договора маркировки с ЦРПТ, с которыми вас просто отключат от системы маркировки.
Я извиняюсь, но никакая это не автоматизация.
Объясняю почему. Сканером рабочий считывает штрих-код EAN13 на упаковке, в котором уже есть вся информация о модели, цвете, размере и тд., а ваше «решение» только вытаскивает из БД клиента (с заранее сгенерированными кодами DataMatrix) первый попавшийся с подходящим EAN13 (gtin) и печатает его на принтере. При этом кто наносит EAN13 на упаковки? Кто контролирует, верно ли нанесен EAN13? На ту ли модель, на тот ли цвет и размер?
Вы, возможно, скажете, что линия выпускает один продукт и такой контроль не обязателен. В таком случае заказчик в РФ может отправить в Китай количество этикеток в соответствии с ожидаемой партией товара, и на фабрике еще быстрее и проще наклеят их на коробки, ничего не сканируя. А в вашем случае просто у китайцев тройная работа — первый раз наклеить EAN13, второй — считать EAN13 и распечатать DataMatrix, третий — считать DataMatrix и агрегировать их в коробку. При этом ваше «решение» работает с готовыми кодами DataMatrix, то есть: лезет в базу, где они хранятся (и может теоретически там что угодно наделать), и плюс клиенту эту базу нужно обновлять каждый раз при выпуске новых DataMatrix. И еще интересно, как в БД хранятся выпущенные клиентом DataMatrix: если в картинках — то вы просто психи гонять такой объем данных из РФ в Китай, учитывая качество соединения и количество блокировок в Китае, а если в тексте — то это грубое нарушение правил маркировки и договора с ЦРПТ, и с вами могут расторгнуть договор в любой момент.
Лично я для нужд нашей компании написал мобильное решение, которое считывает и агрегирует DataMatrix в транспортные упаковки. Клиент просто отправляет тучу этикеток на фабрику, те в свою очередь наклеивают на изделия при производстве. Затем на выходе линии ставится контролёр — он считывает своим смартфоном с моим решением DataMatrix-коды и агрегирует в коробку.
Плюсы такого решения:
1. В БД моего ПО нет DataMatrix-кодов, а это значит, что клиенту не нужно такую базу постоянно обновлять, и мое ПО не нарушает правил договора с ЦРПТ
2. Не нужно гонять большие объемы информации по всему миру => высокая производительность
3. Мое решение легко и бесплатно масштабируется. Если завтра ваша линия втрое увеличит темп или откроется еще пара линий, что делать? Срочно докупать еще + ТСД по 30к рублей + принтеры? А если это нужно всего на неделю? В моем случае решение ставится на любой смартфон с Android или iOS, сегодня один контролер, а завтра ставь хоть 10 дополнительно со своими смартфонами. Смартфоны легко бьются и ломаются? Гораздо реже, чем ТСД, особенно если смартфон — свой) А сейчас он есть у каждого.
4. Хотите доп. проверку? Легко! Загружаем в БД описание для gtin из Excel, и при сканировании DataMatrix контролер будет видеть фото, модель, цвет, размер — и сразу может отбраковать неверно нанесенные коды.
5. Три языка: русский, английский, китайский. Добавить новый язык — не проблема.
Вообще, честно, я удивляюсь над вами, ребята) В 2016, когда началась маркировка меха, попробовал ваше «Мягкое золото». Весело поиграться, когда у тебя до 1000 единиц номенклатуры, куча свободного времени и есть стойкое желание кликать мышкой до мазолей на пальцах. А когда номенклатура переваливает за 10 тыс позиций (сейчас у нас больше 30 тыс), и объемы растут — программа просто висит, глючит, про трудозатраты на маркировку я вообще молчу. В итоге через два месяца плюнул и написал своё десктопное ПО, в котором сейчас одновременно работают с нашей БД в РФ, Турции и Китае, маркируют мех и теперь еще и обувь и одежду в разы быстрее и проще. При этом я в компании один разработчик от слова совсем.
Ладно бы мы были одни такие уникальные со своими «запросами», так и другие к нам обращаются периодически — эти просят метки эмитировать, те просят на КИЗ RFID-метки запись осуществить. Работают с «Мягким золотом» и слёзы крокодильи льют.
Ни в коем случае не набиваю себе цену, но мой вам совет — кто там у вас отвечает за бизнес логику ПО и за UI — гоните ссаными тряпками, ну серьезно)
Полностью согласен. Добавлю еще свои 5 копеек.
При изменении множества ячеек в каждой книге очень ускорят процесс следующие команды:
Отключаем «прорисовку» всего происходящего на экране (данные будут меняться, но Excel не будет тратить ресурсы, чтобы показать изменения пользователю): Application.ScreenUpdating = False
Выключаем автоматический пересчет формул на листе (представьте, что вы меняете значение 1000 ячеек, которые задействованы в формулах. При каждом изменении Excel будет пересчитывать формулу, ссылающаяся на данную ячейку. Гораздо продуктивнее сделать это в конце, разом). Отключаем пересчет формул перед обновлением ячеек: Application.Calculation = xlCalculateManual
После выполнения кода возвращаем пересчет формул и прорисовку обратно:
Application.Calculation = xlAutomatic
Application.ScreenUpdating = True
Объясняю почему. Сканером рабочий считывает штрих-код EAN13 на упаковке, в котором уже есть вся информация о модели, цвете, размере и тд., а ваше «решение» только вытаскивает из БД клиента (с заранее сгенерированными кодами DataMatrix) первый попавшийся с подходящим EAN13 (gtin) и печатает его на принтере. При этом кто наносит EAN13 на упаковки? Кто контролирует, верно ли нанесен EAN13? На ту ли модель, на тот ли цвет и размер?
Вы, возможно, скажете, что линия выпускает один продукт и такой контроль не обязателен. В таком случае заказчик в РФ может отправить в Китай количество этикеток в соответствии с ожидаемой партией товара, и на фабрике еще быстрее и проще наклеят их на коробки, ничего не сканируя. А в вашем случае просто у китайцев тройная работа — первый раз наклеить EAN13, второй — считать EAN13 и распечатать DataMatrix, третий — считать DataMatrix и агрегировать их в коробку. При этом ваше «решение» работает с готовыми кодами DataMatrix, то есть: лезет в базу, где они хранятся (и может теоретически там что угодно наделать), и плюс клиенту эту базу нужно обновлять каждый раз при выпуске новых DataMatrix. И еще интересно, как в БД хранятся выпущенные клиентом DataMatrix: если в картинках — то вы просто психи гонять такой объем данных из РФ в Китай, учитывая качество соединения и количество блокировок в Китае, а если в тексте — то это грубое нарушение правил маркировки и договора с ЦРПТ, и с вами могут расторгнуть договор в любой момент.
Лично я для нужд нашей компании написал мобильное решение, которое считывает и агрегирует DataMatrix в транспортные упаковки. Клиент просто отправляет тучу этикеток на фабрику, те в свою очередь наклеивают на изделия при производстве. Затем на выходе линии ставится контролёр — он считывает своим смартфоном с моим решением DataMatrix-коды и агрегирует в коробку.
Плюсы такого решения:
1. В БД моего ПО нет DataMatrix-кодов, а это значит, что клиенту не нужно такую базу постоянно обновлять, и мое ПО не нарушает правил договора с ЦРПТ
2. Не нужно гонять большие объемы информации по всему миру => высокая производительность
3. Мое решение легко и бесплатно масштабируется. Если завтра ваша линия втрое увеличит темп или откроется еще пара линий, что делать? Срочно докупать еще + ТСД по 30к рублей + принтеры? А если это нужно всего на неделю? В моем случае решение ставится на любой смартфон с Android или iOS, сегодня один контролер, а завтра ставь хоть 10 дополнительно со своими смартфонами. Смартфоны легко бьются и ломаются? Гораздо реже, чем ТСД, особенно если смартфон — свой) А сейчас он есть у каждого.
4. Хотите доп. проверку? Легко! Загружаем в БД описание для gtin из Excel, и при сканировании DataMatrix контролер будет видеть фото, модель, цвет, размер — и сразу может отбраковать неверно нанесенные коды.
5. Три языка: русский, английский, китайский. Добавить новый язык — не проблема.
Вообще, честно, я удивляюсь над вами, ребята) В 2016, когда началась маркировка меха, попробовал ваше «Мягкое золото». Весело поиграться, когда у тебя до 1000 единиц номенклатуры, куча свободного времени и есть стойкое желание кликать мышкой до мазолей на пальцах. А когда номенклатура переваливает за 10 тыс позиций (сейчас у нас больше 30 тыс), и объемы растут — программа просто висит, глючит, про трудозатраты на маркировку я вообще молчу. В итоге через два месяца плюнул и написал своё десктопное ПО, в котором сейчас одновременно работают с нашей БД в РФ, Турции и Китае, маркируют мех и теперь еще и обувь и одежду в разы быстрее и проще. При этом я в компании один разработчик от слова совсем.
Ладно бы мы были одни такие уникальные со своими «запросами», так и другие к нам обращаются периодически — эти просят метки эмитировать, те просят на КИЗ RFID-метки запись осуществить. Работают с «Мягким золотом» и слёзы крокодильи льют.
Ни в коем случае не набиваю себе цену, но мой вам совет — кто там у вас отвечает за бизнес логику ПО и за UI — гоните ссаными тряпками, ну серьезно)