Павел

можно предположить, что это массив, где разделитель 'x'. Это даст 71 число.
большинство начинается с "2004", но каждое 9-е — с "2005". Эти 2005-е все одинаковы: 20056745.
Итого 8 групп по 8, и 7 разделителей между ними. 64 + 7 = 71

Многие значения после префикса"2004" повторяются:

7155 7155 7155 7155 7155 7155 7155 7155
6881 6881 6881 6881 6881 6881 6881 6881
6881 6881 6881 6881 6881 6881 6881 6881
7429 7566 7429 7429 7566 7429 7429 7429
8114 7018 8114 7840 6881 7840 7840 8114
7703 7703 7840 7018 6881 7018 7155 7703
7155 7840 7566 7566 7292 7566 8114 7155
7018 7703 7977 7566 7155 7566 7155 7018

Причём, уникальных значений там всего 10:

7155, 6881, 7429, 8114, 7703,
7018, 7566, 7840, 7977, 7292

так укажите в пробросе новый адрес и всё...

Какие задачи на данном сервере будут решаться (от этого зависит конфигурация железа) и приблизительный бюджет. Конфигурацию подберу.

Проблема № 1 - квалификация программиста.
Тут на стыке - тех, кто разбирается и в вебе и в 1С - единицы.

На самом деле могут 2 программиста делать - со стороны сайта один, со стороны 1С другой.
Им был только способ взаимодействия по данным согласовать.

Но фактически работа ничем особенным не сложная, типовая вполне себе.
Делал я такую интеграцию неоднократно...

Проблема № 2 - стоимость работ.
Что бы я там не писал, что работа "обычная".

Это не означает, что обойдется она в копейки.

Это или 2 программиста - один с веба, другой с 1С.

Или 1 программист, но более квалифицированный.

Проблема №3

Возникают дополнительно еще некоторые админовские задачи - ведь если список товаров с ценами вы еще легко передадите практически любым способом (да хоть POST-запрос), то с картинками все не так просто.

В моем случае использовалась кастомная синхронизация в облако по протоколам S3, OpenSwift. Это не столько администрирование, сколько просто создать аккаунт.
И есть вариант с синхронизацией по Syncthing. А это нужно установить и настроить Syncthing на двух серверах (на веб-сервере и на сервере 1С).

Проблема № 4. Нужно четко представлять а что вы вообще собираетесь делать?

Нужна ли синхронизация в одном направлении (на сайт из 1С товары и цены)?
Или и обратно тоже (с сайта в 1С заказы)
Разовая ли эта синхронизация или на постоянной основе? Насколько оперативно должно происходить? Как уведомлять одну систему, что другая отправила ей данные?
Соответствует ли каталог товаров в 1С тому, что будет на сайте (часто фирмы упрощают под себя список товаров в 1С - все равно клиенту по барабану, а менеджерам фирмы работать с таким список удобно). Но если будет выгружаться "один-в-один" на сайт, то невнятная иерархия товаров и/или невнятные названия товаров - большая проблема. Захотят ли переделать в 1С так чтобы на сайте было удобно? В моем случае сочли более эффективным оставить для внутренней работы иерархию как она была в 1С и делать вторую альтернативную иерархию для веб-сайта. Хорошо хоть названия товаров нормальные.
А как будет отрабатывать веб сайт массовую загрузку товаров (ну например, каждые полчаса весь прайс-лист с товарами заново загружать, чтобы остатки и цены были оперативны), не будет ли это влиять на обычных посетителей сайта? Мы это специально решали - товары и цены выгружаются редко, а остатки другим файлом (компактным) - быстро. Что позволило обновлять остатки хоть раз в 5 минут. Полный прайс лист с названиями и ценами на сотни тысяч товаров загружать так часто затруднительно. Да и не нужно.
А что будет если приедет из 1С на сайт товар А, Б, В, но после этого всегда будет приезжать товар Б, В. Из 1С информация о товаре А никогда не будет поступать более (так как товар А более не закупают). Товар А будет болтаться на сайте вечно? В каком состоянии, с остатками или без, с какой ценой?
Будут ли бонусы покупателям на сайте? А как сделать так чтобы использовав свои бонусы в на сайте их нельзя было повторно использовать на сайте. И наоборот.
Как идентифицировать покупателя на сайте (для бонусов это важно), чтобы он был однозначно связан с покупателем в 1С. Тут отдельная проблема - товар, как правило создается только в 1 месте, в 1С. И едет всегда только в одном направлении - на сайт. А вот новые покупатели могут создаваться и там и там. Как эти две системы поймут, что речь идет об одном и том же покупателе при двойной его регистрации?
Будут ли вручную после загрузки корректировать товар на веб-сайте и не будет ли новые загрузки эти изменения перетерать? Или все корректировки будут делаться только в 1С?
Готовы ли для этого в 1С внести структуры хранения данных которые нужны только для сайта?
А что если нужно организовать очень оперативную выгрузку обновлений, но каталог огромен? Значит нужна выгрузка частичная. А чтобы 1С могла отслеживать что выгружено из уже измененного, а что нет - нужны дополнительные структуры данных в БД 1С.
Есть отдельная организационная проблема, когда все структуры внутри 1С хотят оставить без изменений. Тогда все нужны поля нужно хранить в очень неудобных вспомогательных структурах данных. Это решаемо, хоть и неудобно. Если вы делаете не под конкретное предприятие, а универсальную систему с целью многократной продажи и внедрения на разные предприятия - придется идти этим путем.

И т.п. и пр.

Правильно считаете.
Виртуальный комп никак не сможет получить доступ к хосту (только к файловой системе если такой доступ разрешить)
Но и сотрудник СБ будет знать что программа установлена не на компе, а на виртуалке (Стахан точно узнает)
Если СБ это устроит - то проблем не вижу
Второй вариант - завести для работы отдельный комп (ноут) - купить на авито или алиэкспресс что-нибудь недорогое.
Третий вариант (странно что работодатель его не использует) - предоставление к рабочему месту по RDP

оно того не стоит.
яндекс маил гугол и мс предлагают корпоративные ящики зачастую бесплатно.
в пачку входит веб интерфейс интеграция с календарями файло помойкой и прочими их сервисами.
Я бы с нуля оценил настройку почты от 200 тр.
Причем не факт что письма не будут падать в спэм, монополия это все таки круто

Ваш подход к задаче неверен. Зачем вытаскивать все записи из базы и затем фильтровать, когда можно получить только нужные выполнив правильный запрос:

$favorites = [103, 105];

$favorite_ids = implode(',', $favorites);

$query = sprintf('SELECT * FROM employees WHERE employee_id IN (%s)', $favorite_ids);

run php online

Это подойдет?

Я нашел ответ на этот вопрос еще 11 лет назад, и он не изменился, это программа:
https://www.voidtools.com/ru-ru/support/everything/ - Everything – программа для мгновенного поиска в Windows файлов и папок по их именам.
Преимущества Everything перед другими поисковыми программами
- Маленький установочный файл
- Простой и понятный интерфейс
- Быстрое индексирование
- Мгновенный поиск по именам
- Быстрый запуск
- Минимальное потребление ресурсов
- Малый размер базы данных на диске
- Обновление в реальном времени
// Кряк не нужен - она полностью Бесплатна, Русский язык в наличии, как и много других, перевод - мне не кчему было придраться //

Вот о ней и о ее альтернативах, но она мне удобнее и приятнее всех альтернатив, ее даже тупые офисные пользователи осваивают без жалоб на сложность, но и пользуются не всеми возможностями. )

- https://www.white-windows.ru/everything-bystraya-a... - Everything — быстрая альтернатива штатному поиску Windows
- https://progsoft.net/ru/software/everything - Everything альтернативы и похожие программы
- https://ruprogi.ru/software/everything - Аналоги Everything - 10 похожих программ и сервисов для замены

Новая версия Everything v1.5 - ссылка на форуме (еще бета, так как происходит добавление функций), добавила индекс для мгновенного полнотекстового поиска с учетом формата файлов, и много ошеломительно мощных функций - теперь это не что-то просто простое а невероятно мощное под тем же не перегруженным интерфейсом.

До нее я пользовался лет десять для целей поиска, как уже советовали FAR Manager и Total Commander попеременно - но они отдыхают по сравнению с ней в целях поиска и упорядочения размещения файлов.

Кстати, у Everything - очень приятная возможность группового переименования множества файлов!

Есть движок docuwiki гляньте, может понравится . Сам использовал - очень удобно.

Пароли - в хранилке паролей, например Keepass.
Остальное - в OneNote\Evernote, потом переносить в документацию.

Правильно так, как удобно именно тебе.
Я, сейчас, держу в экселе. Раньше в ворде заполнял.
разницы нет, в чём держать. Разница в том, что бы они были "под рукой".
Или в облаке держи (тот же гугл-докс), или бекапь на флешку после каждого изменения.

Советую пользоваться гугл доками (https://docs.google.com/)
В Exel удобно хранить всё что связано с паролями и просто ссылками
В Word удобно хранить полезную информацию по типу кусков конфигураций, просто длинных текстах о проблемах и их решении, вести какие то свои списки, как пример добавлю скрин лишнее замажу, лично для меня удобно.
По мимо этого на основном пк удобно держать Notepad++ где тоже куча информации, зачастую той которую будешь (у коллег встречается по 20-50к+ строк).
Для паролей к примеру своим подданным можешь использовать syspass, если не ошибаюсь на бесплатной основе, там можно разделять пользователей на группы и они будут видеть только те пароли которые им необходимы.

Как пример самой простой exel таблицы, 10 принтеров к каждому несколько колонок, его ip локальный, модель, расположение и всё в таком духе

Сори скрин на скорую руку шакально замазал

XWiki, Redmine
Если вести в вики то лучше конечно полноценный вики-движок типа xwiki, потому что в redmine он довольно скромный.
Но в redmine я обычно сам себе "ставлю" задачи и сам их "решаю".

Прикинуть допустимые затраты, купить оборудования, провести сеть, включить, настроить.

Прежде всего есть важно понимать семантическое версионирование https://semver.org/lang/ru/
Патчи накатываются обязательно, так решается проблема с дырами и багами.
Минорная версия обновляется не часто и нужно быть аккуратным и посматривать на деприкейты.
Мажорная версия изменяется очень редко и на работе вам могут встречаться гораздо более древние версии.
Плюс есть LTS версии https://laravel.com/docs/master/releases#support-policy у них длительная поддержка и проекты стараются делать на ней

Но в принципе со времён 5й версии Laravel концептуально не менялся и разобраться будет не проблема, но будут отсутствовать всякие приятные фичи.

Уроки зло - там вырезки из документации с плохим качеством кода. Да и про саму доку надо помнить, что примеры лишь для демонстрации функциональности, но это не обязательно правила хорошего кода. Например, в примерах для краткости используются фасады, но на проекте лучше использовать инъекции зависимостей.