Форум OlegON > Программы и оборудование для автоматизации торговли > ЕГАИС в опте и рознице

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

23.11.2024 2:14


01.07.2022 18:51
Цитата:
_R2D2_ Но вернемся к теме форума - по ЕГАИС пока встреченный мной рекорд - это остатки в 72МБ (более 1 млн бутылок на оптовом регистре). Там ни УТМ, ни наше ПО такие файлы переварить нормально не может. И да, легенькая Derby, используемая в УТМ (сравнима с вашей БД) такие документы нормально не переваривает. А их в БД может накопиться не один и не два - остатки запрашиваются довольно часто.
Согласен, что к словам Моцарта нужно относиться с огромной осторожностью... Сейчас взглянул по удаленке в небольшой магазин... и как пример одна из табличек проги ЕГАИС = 31mb, где только храниться содержимое когда либо проходящее через регистр №3





… а общий размер БД накопленный с октября.2015 только ЕГАИС 198мб. Конечно можно покритиковать структуру, но ЕГАИС так часто изменялся, что не было много времени на её постоянную оптимизацию

Код:
PULL_AKM.DBF 	Ведущийся в фоновом режиме пул акцизных марок подразделения с текущим id

codIs		C	150	0	// ШК АМ из пула - основное и ключевое поле
regId		C	19	0	// Код АП в системе ЕГАИС
name		C	200	0	// Наименование АП, может отсутствовать. Обновляется
opDate		D	8	0	// Дата первого внесения инфы в пул
opTime		C	8	0	// Время с точность до секунды
tip		C	1	0	// Источник: 1-Инвент,2-Серв АМ, 3-Приходы, 4-чек, 5-баланс склада, 6-списание, 7-расходная ТТН, 8-фиксация ШК на рег№3, 9-запрос остатков рег№3, иначе ошибка
dat		D	8	0	// Дата приходной ТТН. Атрибуты для типа 3
number		C	50	0	// номер приходной ТТН
client		C	15	0	// код поставщика в ЕГАИС
numbb		C	25	0	// код справки Б для ведения виртуального регистра 3 по v3
active		N	1	0	// Статус остатка: 1-Списано/продано, 2-наличие, х-неопределенно
status 	        L 	1	0	// Истина, если поставлено на баланс регистра №3
dGr 	        L 	1	0	// Не визуальное рабочее поле – признак вер. 18.06.2018 

PA_CODIS		INTO codIs			TO (cPath+”Pull_akm.nxt”)
PA_REGID_NUMBB		INTO regId+numbb		TO (cPath+”Pull_akb.ntx”)
01.07.2022 19:23
Ну, это либо у тебя движок такой, либо алгоритм в программе. С какого перепуга *4 ?
01.07.2022 19:25
Может, только по размерам бд и т.п. в другую ветку перенести?
02.07.2022 07:29
Цитата:
FinSoft Ну, это либо у тебя движок такой, либо алгоритм в программе. С какого перепуга *4 ?
Мои утверждения не описаны в документации и нельзя считать абсолютной истиной. Они получены эмпирическим путем... На пике популярности системы, когда было много пользователей с условно большими БД, большим парком ПК и закупались идентичные компы, было обнаружено, что на одном ПК программа работает быстрее на 20%-40% чем на другом, как бы абсолютно идентичном...

Начался цикл тестирований, благо были помощники… и выявилось, что отличия у ПК в размере ОЗУ. Когда память делали одинаковой скорость на этих ПК, так же выравнивалась. Затем подбирая размер памяти выявили, что скорость программы заведомо возрастала, когда объем RAM делали большим, чем размер_БД*4... Конечно задавал вопросы на спец.форуме, искал объяснения в интернет... и было, что-то типа: инструмент в процессе работы с БД создаёт множество временных вспомогательных объектов, ведёт клоны объектов и т.д.... и всё размещает в RAM
02.07.2022 09:22
У нас такого нет. Программа (точнее, менеджер памяти рантайм библиотеки системы разработки) запрашивает память у операционки блоками. Например, при создании структуры данных в памяти или открытии нового окна. Когда очищаем структуру данных или закрываем окно, память операционной системе не возвращается, но будет использована при последующей работе программы. Следующая порция памяти у операционной системы запросится, когда не будет хватать запрошенной ранее. Порция составляет примерно 1-2 мб. Так сделано потому, что запрос блока памяти у операционки не самая быстрая операция.
Если я формирую тяжелый отчет по большой выборке данных, используя промежуточные временные структуры данных, то программа отгрызет у операционки определенный объем памяти. С размером базы это особо не коррелирует, зависит от того, сколько мы держим промежуточных или итоговых данных в памяти. Скриншоты свои в эту тему кидать не очень корректно, на словах на базе ~800 - 900 мб при построении тяжелого отчета за полгода с большой результирующей выборкой в разрезе товар+поставщик, программа отъела ~30 мб. Если я закрою окно и сформирую этот же отчет заново, память останется примерно такая же. Если не закрывая отчет, сформирую такой же еще раз (или другой), то программа откусит еще память, но уже не 30 мб, а значительно меньше.
Максимальное значение захваченной памяти, которое я наблюдал у пользователей, было порядка 300 мб, не считая самой программы.
02.07.2022 11:54
Глянул ради любопытства самую большую базу, которая не файловая, а action zen (btrieve). Самый большой размер памяти, захваченной одним из пользователей порядка 700 мб. Сама база 45 гб (без лога, конечно), в справочнике товаров 51 тыс позиций, база за 6 лет, с активным ростом.
03.07.2022 03:15
Цитата:
raidex Есть такое понятие, как, коэффициент автобуса
При покупке программы нужно задумываться, чему приблизительно равен busfactor, и уж точно не покупать её, если
Код:
busfactor = 1
До читал ветку пока только до этого места, и тоже хотел задать нашему герою вопрос (учитывая что он пилот) - а что будет с торговой сетью и клиентами, "если вдруг что" ?
03.07.2022 05:22
Цитата:
Downkey До читал ветку пока только до этого места, и тоже хотел задать нашему герою вопрос (учитывая что он пилот) - а что будет с торговой сетью и клиентами, "если вдруг что" ?
Дочитал ветку до конца, понял. Герою пох. Даже если для владельца магазина это смерть бизнеса. Да, гении они такие. (( Но читать было прикольно ))

Вполне себе можно опустить, что чувак написал софтину, отвечающую минимальным требованиям маленьких магазинов. Речи о торговых сетях, или магазинах с десятком касс не идёт. Ввиду того, что крупные ИТ-компании по каким-то причинам не зашли в его регион, гению удалось заполнить нишу своим продуктом. За долгие годы доработки своей программы, вполне себе можно было реализовать многие полезные фишки. Так-то все просто. Нет смысла спорить и искать изъяны. Они наверняка есть. Но признать факт, что софтина существует и работает, думаю можно. Может даже из читателей форуме есть кто-то из Краснодарского края и может даже видел эту реализацию в магазах.

Другой вопрос в том, что автор не приемлет переход на современные технологии, т.к. это повлечет полную переработку софта, чего конечно не хочется, т.к. подразумевает глобальные затраты ресурсов человеческих и временных. Потому и ратует за бесспорное удобство и гениальность разработки. На мой взгляд, (если всё принят за истину) гениальность лишь в том, как удалось в_одного покрыть такую географию. НО. Найти девочку-продажника и студента-сеошника, для нормального продвижения достойного продукта - это задача для гения оказалась непосильной. Подача материала, прямо таки скажем, сразу вызывает здоровый скепсис. Вас, товарищ Моцарт, просто не воспринимают всерьез. Вам что-то надо менять в отношении к Миру.
И как уже писали выше, действительно, я уж лучше куплю для маленького магазина базовую 1с за 3600р с достаточным функционалом, чем за 9000р. сомнительную разработку эгоцентричного персонажа, который в любой момент может гикнуться с параплана, с риском угробить учет в магазе.

Не раскрытым остался момент использования rdp из Майами. Для реализации нужно, либо чтоб в каждом сельпо был белый ip (что маловероятно, т.к. несет дополнительные неоправданные расходы для владельца), либо нужно уходить в vpn (что накладывает уже определенные сложности технической реализации).

И еще вот осталось не понятным. Про десятки дилерских центров по всей России было сказано. А техническую (в смысле - физическую) поддержку, на всей сети своих клиентов, наш гений тоже осуществляет в одного? А то глядишь, там этим "Моцартом" подпольная мега-ИТ-компания... Но это секрет! Т.к. ни названия торговой сети, ни названий дилеров озвучено не было (может быть в рамках правил форума)
03.07.2022 08:54
Если маэстро гикнется с параплана, то пользователи спокойно перейдут на другой софт. Тут не надо драматизировать, в один день все не встанет. Вопрос только в том, чтобы найти вменяемого специалиста и некоторые средства. Если сравнить стоимость доработок в 1с и уровень квалификации тех, кто их делает, наш маэстро может быть более чем конкурентен. Дело в первую очередь не в софте, а в людях.
Сложности с переходом на другой софт есть только у более крупных компаний. Точнее, это может оказаться довольно дорого. Но тоже не смертельно. Обычно, чем более критично программное обеспечение для бизнеса, тем больше у него средств в распоряжении. Для бизнеса в первую очередь важны деньги и связи, остальное все покупается.
03.07.2022 15:55
Цитата:
Downkey я уж лучше куплю для маленького магазина базовую 1с за 3600р с достаточным функционалом
Правда, что ложь повторенная десятки тысяч раз становится абсолютной истиной? Всю жизнь хотел увидеть живьём, а не тирадах пиарастов от "1ц" розницу, где её программа на платформе "1С" с настройкой и поддержкой вписалась бы хотя бы в 30.000...
Часовой пояс GMT +3, время: 02:14.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.