Как я писал собственную ERP систему, ver. 2.0

Вот теперь думаю, что с ней делать. Выбросить – жалко. Но рынок очень узкий и достаточно закрытый.

Идти в мир 1С, если нравится работа с такого рода задачами, и там, вы можете стать очень хорошим и востребованным профи.
Так как типичные кодеры 1С в основном знают только 1С, и кричат что им этого достаточно и они гуру.
Настоящие профи — знают более чем 1 язык программирования, а реальные профи — минимум 3-4. Да, может не на 100%, но это и не надо.
У меня в 1С сейчас возникают схожие задачи, например, если контора, там есть торговые и курьеры, и служба доставки, и прочие прелести.
Так вот, со времени внедрения мы задали клиенту всего один вопрос:
«Как курьер решает — куда ехать в первую очередь?».
Это все переросло в громадный проект, где:
1. Гео позиции взятых заказов, с анализом того, заказ был взят около клиента, или хз где.
2. Решение задач коммивояжера
3. GPS трек в машинах
4. Вывод карт с реальным и оптимальным маршрутом, рассчет себестоимости доставки вплоть до конкретного клиента (а это еще та задачка)
5. Вывод и наложение маршрутов, с расчетом расстояния и простоев
6. Служебные поездки и оптимизация ГСМ
И куча куча всего другого.
Тут пришлось кодить карты, причем иногда это Яндекс, иногда опенстрит, так как нужны графики пирогов по особому алгоритму, которые ни гугл, ни яндекс не дает делать нормально.
Тут же мобильные прилоежения (в том числе на 1С), и службы сбора текущих координат (это уже нативное)
Тут и вывод карт, сохранение скринов карт с анализом дальнейшим
Тут же интеграция с гуглом, яндексом, свои приблуды, с GPS трекерами и т.д.
И увы, большенству 1Сников такие задачи не поднять, в силу ограниченности знаний только 1С, и чаще всего не умением вкурить в английские мануалы, та и вообще в английский. А чаще всего — они даже не знают что так вообще можно.
А вот вы, с вашим опытом и знанием, и уже даже пониманием предметной области, можете очень не хило зарабатывать тут, и заниматься чуть ли не сразу интересными проектами, начиная с того, что помогать 1Сникам в написании вот таких приблуд как я описал.
Так как и 1Сникам не легко веб программисту объяснить многие тонкости учета бизнеса, и почему это надо именно так, большенство из них (веб программистов) думает, что это 1С такая тупая и не может по другому, а по факту — это требование бизнеса, и тут не выкрутиться.
Плюс, 1С умеет в oData и rest full api, причем для работы с ними — не надо лицензии (если память не изменяет), так что если вы свою приблуду сделаете как сверхлегкий клиент, который будет только описывать интерфейс, то и тут тоже вам рынок будет.
Короче — подумайте :)

а не надо было никакого курьерского приложения. Надо было создать веб интерфейс и было бы и кросплатформенно и в реалтайм и ничего не надо нигде кешировать. Проблемы с интернетом ща могут быть разве что в лесу далеко за городом. Да и вообще ERP в виде десктопа (хоть и сам писал раньше такое на старом добром делфи) — имхо вчерашний день.

Ну чтож, повторюсь…
Когда читал статью, был в шоке.
Сам в основном занимаюсь разработкой ERP, CRM.

Очень рад за клиента, что он отказался и надеюсь не заплатил.
Автор, когда клиент к тебе обращается — он ждет что-то хорошее.
А ты с момента выбора технологии и реализации начал клиенту свинью подкладывать.

ERP такая штука, которая всегда подвержена доработкам и изменениям, притом доработкам, порой очень нелогичным (которые не укладываются в логику).
Такие системы должны быть:
1. Очень гибкие — чтоб можно было менять и дорабатывать все что угодно, особо при этом не ломая другие модули
2. Написаны на популярных и простых технологиях — если вдруг за такой код, как вы делали, вас в лес увезут, чтоб другой программист мог дальше работать. Ваш код легче выкинуть, чем копаться в ваших изобретениях.

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

Средством разработки был выбран Rad Studio. Студия по некоторым причинам не очень популярна, но в данном случае мне, во-первых, хотелось получить единый код на всех устройствах, так как я один и не могу себе позволить несколько раз прописать одну и ту же структуру данных в нескольких средах разработки, а потом при любом изменении править в 10 местах. А во-вторых, я на всех платформах получаю компилированное приложение, которое теоретически всегда должно работать быстро. Но прежде всего меня волновала скорость на рабочем месте оператора.

Ну конечно, если вы слона проглотить решили в одиночку.
Только сделать это на вебе было бы очень даже не плохо и работало бы очень быстро.
Вы в курсе что последние годы это делают на вебе, когда нет возможности и целесообразности писать отдельные приложения.

И код был бы единый, с константами, без хаков и главное Поддерживаемый!!! Это самое главное что нужно клиенту!
Клиенту всегда нужно, чтоб бизнесс работал, а не ваши изобретения. Он всегда хочет знать, что если вы пропадете по любой причине, его бизнес не сдох из-за вашего выбора технологий. И что пару лямов он потратил не привязавшись только к вам как единственному, кто может апдейтить систему.
Вы свинством занимаете, еще и продать теперь хотите кому-то.

Одному мне кажется, что из за проблемы с 4-х секундным стартом курьерского приложения внедрения ERP не отменяют? Не, я все понимаю, но 4-е секунды же… Если исходить из того, что автор написал про свое «ERP», то оно должно было экономить/зарабатывать, но 4-е секунды в приложении, это фигня, полная, по крайней мере, пока доставка выполняется по 40 минут.

но в данном случае мне, во-первых, хотелось получить единый код на всех устройствах

Какой именно код в итоге остался общим? Вы ведь сделали скриптовый язык на сервере.

спасибо, что исходники компонент дельфи доступны и там можно легко поправить заголовок http не заморачиваясь с raw socket

Опишите пожалуйста подробнее, зачем вам было нужно менять исходники стандартных компонентов, в чем была проблема?

их программа раз в минуту опрашивает сервер, и, если есть новый заказ, то печатает pdf

То есть в ответе от сервера возвращался только pdf? Никаких JSON или XML? Решение с парсингом PDF выглядит странно.

Если координат нет, геокодируем

А почему сразу нельзя было геокодировать, без ФИАС? Ответы складывать в кэш, кэш постепенно наполнится, и будет то же самое, только без дополнительной интеграции.

Если данные в нём есть, обратимся сразу, если нет, то придётся подождать, пока сервер отдаст их.

То есть обращения к серверу в процессе работы все же есть? А как данные выгружаются из кэша? Допустим оператор начнет пролистывать все заказы за последние полгода с целью найти какой-то конкретный.

всем подписчикам придёт об этом уведомление с новыми данными

Как решается вопрос когда у одного из клиентов в этот момент сеть недоступна? Он потеряет обновление?

Несколько замечаний в целом.

А во-вторых, я на всех платформах получаю компилированное приложение, которое теоретически всегда должно работать быстро.

Скорость работы таких систем зависит от скорости ввода-вывода, а не от компилированности.

Вдруг такое сочетание «улица-дом» уже встречалось, тогда берём координаты оттуда.

Выглядит как неправильно спроектированная архитектура. Должна быть одна таблица для адресов и координат, чтобы не искать в 10 местах.

но принять данные не возможно ни в какой форме

Сам не пробовал, но то что сходу нашлось: чтение из window, чтение поля формы

CurOrderState := GetNewValueF('Orders','OrderState');
LastOrderState := GetOldValueF('Orders','OrderState');

В современных подходах у вас есть объект класса Order и данные запроса, и вся эта куча кода превращается в order.state и request.state.

Но так как это можно в любой момент переписать, и код совсем не сложный и не большой, я решил пока оставить так.

Ну так сначала сделайте, а потом продавайте. Раз еще не сделали, значит есть сложности.