УС Лэнд:ЕГАИС - Программа, обсуждения, предложения, обновления : КИС Lack & УС Land

Пока - так, но только программа должна еще и слипы с QR-кодом печатать... Пока вроде небыло требований, что-бы слип с кассовым чеком "одно целое" был, можно печатать и на отдельном принтере...

PS Пока я из таких программ только j-pos видел... Там как раз такой функционал, поищите, я здесь описывал...

Что здесь "смущает"?
Есть три алкогольных "заморочки": декларация, журнал учета реализации, ЕГАИС. Все они должны быть взаимоувязаны хотя и используются лишь частично пересекаемые товарные атрибуты. В принципе, если на точках исключительно только операции продажи, то возможно и достаточно будет лишь "кассовой программы" с небольшими "плюшками" на точке... в остальном работать, как прежде... Однако и в этом случае новшества ФСРАР нельзя предугадать. Кроме того, где-то всё товародвижение должно быть учтено.

Что по "ключникам"? - Вопрос "мутный": на сейчас нет официальных "бумаг" запрещающих данную технологию, да и если будет такое, то нет даже идей у ФСРАР о наказании за это... но всё течет и изменяется...

Вы правы! По крайней мере сам в возможно будущем развитии программы предполагаю идти по такому пути, но с интеграцией с головной учетной системой.

По честному! Сам систему разрабатывал и отлаживал под "ключникам" в тестовом контуре ЕГАИС, а в "боевом", если введут ЕГАИС начну внедрять после 11.01.16... а что получится ХЗ? Вроде бы кто-то и пытается так работать, но у меня нет с ними "обратной связи".

Теоретически!!! Без разницы количество ключей, но физически в один момент времени в ПК должен быть включен единственный ключ JaCarta, т.е. для сотни КПП на одном ПК врятли получится работать. Теоретически! и отлаживалось УС Лэнд:ЕГАИС допускает многопользовательскую работу в сети, где на рабочих станциях будут "перетыкать" ключи, т.е. внутренняя база "разрешает" сетевую обработку, но УТМ стоят на рабочих станциях.

Техника работы описана выше, но кратко: под каждый ключ программа создает подкаталоги "мастер каталогов" DATA и REPORT с именем равным коду ФСРАР_ИД. При выборе ключа для работы программа работает, как бы в другой файловой среде. В самих DATA и REPORT ведется работа с "мастер ключем" (заданном при настройке программы) и общими для всех ключей справочниками контрагентов и "ключевых фраз". Так же там находится файл списка ключей и конфигурации программы.

Не по программе, но все же. Заметил, что утм склонен терять доки, при больших пакетах обработки. Исходящий есть, а входящих нет. Следующая партия обрабатывается нормально, но если доков тоже много - может часть и опять не ответить.
Заметил на запросах справок А и Б. Например, запрошено 50 справок Б, отвечено только 30. Остальные так и висят в исходящих.

Это понятно. Требований того что слип был в фискальном чеке - действительно нет. Я уточнял это на конференции. Просто в связи с грядущим 54-ФЗ и электронными эклз, как бы не получилось дважды за одну корову платить. Хотя не удивлюсь, что именно так и получится. Просто рассматриваю вариант связки какой-то кассовой программы + принтер чеков. В этом случае уже получается экономия чуть ли не в 2 раза. Но тут пока много непонятного, но есть надежда, что за 6 месяцев что-то кто-то выпустит толковое. По идее была очень большая надежда на АТОЛ HUB, но как-то слишком они все это дело тянут. VGA интерфейса пока нет, обещают только в 1 квартале. Система на никсах. Короче много слишком вопросов. Вот смотрю, у Штрихов появилась коробочка, альтернатива АТОЛовскому ХАБу - "Штрих-УТМ". С предустановленной виндой. Пока по ней слишком мало инфы и сдается мне ее в руках то никто еще не держал, кроме опытного образца. Но есть надежда, что из этого что-то получится. Будем ждать. Про j-pos спасибо - погляжу обязательно.

Все верно. Но реально нереализуемо, по-крайней мере для моих данных. Ну невозможно автоматизировать каждую точку в количестве сотни штук в деревнях, где в качестве продавцов обычные деревенские бабушки, которые компьютер то стороной обходят. Их бы научить как этот алкоголь правильно продать - уже хорошо будет, а учитывая реальности нашей большой и необъятной, где эти точки печкой отапливаются и регулярные перебои с электропитанием - в пору хвататься за голову. Надо что-то автономное и простое Учет уж как нибудь в центральной базе, в том числе и по данным журнала учета продаж, стыренного с ЕГАИСа.

А по ключам я имел ввиду на одном ПК, просто их перетыкая. Это возможно?

Теоретически!!! Смотрите описание техники: УС Лэнд:ЕГАИС - финальные версии, инструкции, полезные замечания

По поводу зависания ответов - ответы пришли, через два дня :)

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

Хорошая штука - ЕГАИС, не будет мне скучно никогда.

Посмотрите ответы Гущанского от 28.12.2016г Там есть этот вопрос-ответ. Может Ваш?

[ ➜ ]

Смотрел, слышал эту его фразу, что не обращайте внимания.
А на что тогда вообще обращать внимание? Нафига тогда вся эта возня со справками?

У нас проблема стоит в том, что у нас одна из точек идет как транзитная, то есть мы её используем как склад, и с неё делаем внутреннее перемещение по другим точкам.
Я изначально для поиска товара на складе хотел ориентироваться на связку:
№регистрации в ЕГАИС+Дата регистрации в ЕГАИС+номер справки Б. А теперь придется думать что-то еще.

Да и все же бред это все. Зачем эту систему делать, если в итоге данные не будут совпадать? Контролирующие органы будут инфу брать из ЕГАИСа и с нас требовать такие же справки. А позиция Гущанского, не подкрепленная официальной бумагой - является говорильней, не более.

Будем копаться дальше.
Всех с новым годом!

прошу прощения, не могу разобраться(
можно с помощью этой программы отправлять данные о продажах, если можно то как?
Спасибо!