Программа "Амадей Моцарт" для работы в ЕГАИС : ЕГАИС в опте и рознице

Удивительное дело, но в 90х компания, в которой я работаю, то же сделала классное решение для полноценного учета (ERP-систему), клевое решение для общепитов и магазинов. Оно было чем-то похоже на ваше, только не зеленый цвет превалировал, а синенький, но чет дальше своей области распространить его не смогли, достигли потолка в ~1000 копий программы, а дальше стало понятно, что для рентабельности надо либо увеличивать число копий на пару порядков, либо уменьшать амбициозность планов и переходить в реальный.
В итоге, с 2013 основной продукт - облачный. И только сейчас появились ресурсы для полноценного перезапуска тех идей с 90-х, но с очеловеченным интерфейсом и на новых технологиях.

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

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

Как программа узнает что другой отсканировал ту же единицу товара. Программа должна просто прибавить +1 штуку к ведомости фактических остатков. Я не понял вашей идеи.
В крупных супермаркетах на ночь выезжает бригада из 6 сканирующих съемщиков остатков. У меня можно и с ТСД сливать остатки в единую ведомость остатков. Но ТСД дорогие для магазинов и они придумали обходиться дешевыми способами когда на 2-3 кассах открывается эта ведомость остатков и 2-3 кассира штатрыми сканерами - проводными или беспроводными сканируют каждый свой угол торгового зала по стеллажам. А что касается импорта ТТН прихода от поставщика чтобы не набивать ее - ОНО у меня есть в программе, только неправильно это. Сканируя всю партию, мы тем самым проверяем что нам фактически привез поставщик, и именно это набираем во входящую ТТН, а не принимаем заведомый пересорт от поставщика. Если импортировать ТТН , то потом нужно более мучительно глазами сверять факт, смотреть на мелкие названия, концовки штрих-кодов.... мучительно и долго все это. Самый верный способ всегда мой - это сканирование прихода сканерами. Это максимально правильно и точно безошибочно. Совпала сумма ТТН набранная сканерами и с бумажкой - отлично. Не совпала - ищем по суммам итого позиций - в какой расхождение.
Несколько документов и слияние у меня тоже можно сделать. Но зачем. Если кто то накосячил - все равно не проведем пока сумма ИТОГО ТТН не совпадет. Даже если накосячил - исправим, не штрафовать же человека. Поэтому по большому счету неважно кто накосячил из троих, нет же цели штрафануть сразу. А слияние - это дополнительная потеря минут. Зачем? Нет. Я всегда прав во всем. Спорить со мной нельзя. Опыт автоматизации и собственной торговой сети 29 лет. Я знаю ВСЁ. Я прочувствовал все возможные проблемы и написал программу так, как мне , хозяину торговой сети, удобно эти проблемы решать. А беда программистов других учетных программ в том, что они эти 1ЭСЫ пишут не для себя а по заказу других. Поэтому получается неудобно, неправильно, долго, трудозатратно, напряженно и с усталостью потом работать. Я же писал для себя, и это грандиозное преимущество моей программы.

2-3 буквы из середины названия. Хотим найти пиво очаковское. Если начнем вводить пиво - вылезет 300 марок пива. Если ввести ЧА - останутся только товары со слово ОЧАКОВСКОЕ.

Я садился в самолет, летел в типичный "Иркутск", снимал квартиру на месяц, выписывал список из 10-15 кассовых фирм и шел к ним на переговоры, предлагал мою программу, вручал буклетики, наклейки, и из 15 фирм одна соглашалась подписать договор и выкупить у меня 30 копий программы. Потом когда я улетал через 10 дней, они их успешно продавали и докупали еще 20 копий впоследствии...
Потом я садился на машину и ехал по России заезжая во все города, оставаясь в каждом на 3 дня. Из поездки привозил несколько договоров и кучу наличных денег.
А сейчас я уже не молодой и флужу тут вместо марш бросков через всю страну.

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

так и мы примерно так развивались. А потом пришла грамотная девочка-продажник, сказала, что это все фигня ваша возня, ща я все сделаю. Ей дали картбланш. В результате стало открываться по 2-3 офиса в месяц, через 3 года мы покрыли Россию и сейчас у нас более 100 офисов своих и более 3000 точек партнеров.

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

присоединяюсь. Управление заказами - многогранный вопрос. Единого стандарта не существует, нужна гибкость, набор инструментов и относительная простота интерфейса. Ну и всякие EDI со всей требухой с ними связанной

А по нескольким фрагментам можете? Например, сыр твор выдаст все сырки творожные, твородные сырки, сырки с добавлением творога? А если сыр -твор, то все сырки, которые не творожные? Если да, то будет фильтрация как у нас.