Здравствуйте!
3 числа мы нашему региональному дилеру отправили письмо об ошибках в загрузке товарных отчетов с касс форматами ATL и FRN, 4 числа отправили базу и сами отчеты.
За это время сами уже выяснили, что отчет не принимается только по секциям (кассам) №2, по номеру 1 проходит без ошибок (т.е. явно баг внутри самого Бэст-а). Также смогли вернуть загрузку на кассы банальным возвратом файлов в папку SCLAD файлов до обновления.
За это же время, у меня из базы пропало товара на неподсчетную сумму, потому что при заходе отчета с ошибкой, часть позиций просто превратилась в 0.
Нетрудно подсчитать фактическое выбытие 9 штук, но программа считает что ушло 10. Понятно, что теперь я не смогу все эти позиции (а сколько их я даже считать не буду) вернуть назад (пробовали пересчетом остатков - бесполезно, также как советы вернуться назад через бэкап ,только представьте кол-во накладных и так далее), а это отражение на сумму в районе 250 000 только не зашедшими товарными отчетами на ревизии (остальные сумели затащить вручную, порядка 150 000), ну и понятно, что теперь мы не сможем из-за Вашей ошибки выяснить сколько у нас товара убыло на пересортах и ошибках в продажах.
: Хоть что то сделано с этой ошибкой, мы уже замучались работать на недокассовом приложении Бэст-5.Кассир.
Сколько писали о банальных ошибках, разработчики плевать хотели, начиная от расположенных где то глубоко внизу последних продажах (откуда такой алгоритм,кто Вам его посоветовал) и заканчивая отвратительно наплевательским отношением к небанальным вещам: сколько раз говорили: от нас банк требует два слипа, это первичный банковский документ- один покупателю, второй нам (кстати по закону мы его обязаны хранить 5 лет). Дальше, продажи как смотреть, где эта функция??? Как первостольникам дефектуру формировать, на память или глазок??? Мы же и об этом сколько раз писали. Я не говорю про неотрезку слипов и какой то суперзамудреный процесс печати товарного чека (который кстати почему то называется копией кассового, а такового кстати нет).
3 числа мы нашему региональному дилеру отправили письмо об ошибках в загрузке товарных отчетов с касс форматами ATL и FRN, 4 числа отправили базу и сами отчеты.
За это время сами уже выяснили, что отчет не принимается только по секциям (кассам) №2, по номеру 1 проходит без ошибок (т.е. явно баг внутри самого Бэст-а). Также смогли вернуть загрузку на кассы банальным возвратом файлов в папку SCLAD файлов до обновления.
За это же время, у меня из базы пропало товара на неподсчетную сумму, потому что при заходе отчета с ошибкой, часть позиций просто превратилась в 0.
Нетрудно подсчитать фактическое выбытие 9 штук, но программа считает что ушло 10. Понятно, что теперь я не смогу все эти позиции (а сколько их я даже считать не буду) вернуть назад (пробовали пересчетом остатков - бесполезно, также как советы вернуться назад через бэкап ,только представьте кол-во накладных и так далее), а это отражение на сумму в районе 250 000 только не зашедшими товарными отчетами на ревизии (остальные сумели затащить вручную, порядка 150 000), ну и понятно, что теперь мы не сможем из-за Вашей ошибки выяснить сколько у нас товара убыло на пересортах и ошибках в продажах.

Сколько писали о банальных ошибках, разработчики плевать хотели, начиная от расположенных где то глубоко внизу последних продажах (откуда такой алгоритм,кто Вам его посоветовал) и заканчивая отвратительно наплевательским отношением к небанальным вещам: сколько раз говорили: от нас банк требует два слипа, это первичный банковский документ- один покупателю, второй нам (кстати по закону мы его обязаны хранить 5 лет). Дальше, продажи как смотреть, где эта функция??? Как первостольникам дефектуру формировать, на память или глазок??? Мы же и об этом сколько раз писали. Я не говорю про неотрезку слипов и какой то суперзамудреный процесс печати товарного чека (который кстати почему то называется копией кассового, а такового кстати нет).