Здравствуйте, специалисты 1С.
Ко мне обратились с одной интересной проблемой, в конфигурации 1с 7.7 Аптека.
Стали замечать, что по номенклатуре появляются партии с отрицательным остатком.
При продаже товаров клиент пользуется сканером штрих-кода.
Я стал разбираться и обратил внимание, что если на конкретной партии есть положительный остаток, то по этой партии можно сделать продажу на любое количество!
Документ проводится!!!
Конечно, программа, "молча", ругается, проводки формирует не полностью, но факт остается фактом, отрицательный остаток появляется.
Данная ситуация может возникнуть в следующем случае:
При поступлении конкретного товара формируется партия и ей присваивается штрих-код, таких партий по одному товару может быть много. (Например за разные даты поступления)
Кассир пробивает сканером первый товар, в программе меняет количество на необходимое для покупателя, отсчитывает это количество товара и проводит документ!
В реале:
Товар, который отсканировали, может оказаться единственным, из конкретной партии, в программе указали необходимое количество (скажем 20), взяли со склада ещё 19 штук этого товара, которые будут относиться к другим партиям (!), в программе учет прошел по одной партии!!! (А цены в разных партиях так же могут быть разными.)
Вопрос:
Как можно избежать такой путаницы в партиях (не пробивая каждый товар отдельно сканером), ведь бывает берут и по 50-100 шт одного товара!
Заранее благодарен!
Подскажите, пожалуйста
Ко мне обратились с одной интересной проблемой, в конфигурации 1с 7.7 Аптека.
Стали замечать, что по номенклатуре появляются партии с отрицательным остатком.
При продаже товаров клиент пользуется сканером штрих-кода.
Я стал разбираться и обратил внимание, что если на конкретной партии есть положительный остаток, то по этой партии можно сделать продажу на любое количество!
Документ проводится!!!
Конечно, программа, "молча", ругается, проводки формирует не полностью, но факт остается фактом, отрицательный остаток появляется.
Данная ситуация может возникнуть в следующем случае:
При поступлении конкретного товара формируется партия и ей присваивается штрих-код, таких партий по одному товару может быть много. (Например за разные даты поступления)
Кассир пробивает сканером первый товар, в программе меняет количество на необходимое для покупателя, отсчитывает это количество товара и проводит документ!
В реале:
Товар, который отсканировали, может оказаться единственным, из конкретной партии, в программе указали необходимое количество (скажем 20), взяли со склада ещё 19 штук этого товара, которые будут относиться к другим партиям (!), в программе учет прошел по одной партии!!! (А цены в разных партиях так же могут быть разными.)
Вопрос:
Как можно избежать такой путаницы в партиях (не пробивая каждый товар отдельно сканером), ведь бывает берут и по 50-100 шт одного товара!
Заранее благодарен!
Подскажите, пожалуйста
По теме из базы знаний
- Продажа с двух касс ККМ в 1С:Розница 2.2, Розница2.3, Розница Аптека 2.3. Выбор, по какой кассе пробить чек
- Исправление некорректной загрузки приходных накладных "1С:Розница 8. Аптека"
- Интеграция "Библиотеки интеграции МДЛП 1.1.2.7" с типовой конфигурацией
- Выгрузка признака лекарственного средства и срока годности. 1С:Розница Аптека
- Заполнение уведомления об агрегировании номерами транспортных упаковок из уведомления о приемке в 1С:Медицина. Больничная Аптека
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) Дело в том, что не каждый раз позволяет проводить в минус, проверка стоит, но иногда не срабатывает, пока я не нашел в каких случаях. (Программа стоит на кассе и сложно постоянно работать в ней, попытаюсь поставить дома эмулятор).
Разрешения продавать в минус нет.
Разрешения продавать в минус нет.
(18) Проблема в том ,что я вижу, каким документом появляется минус.
И что самое интересное, после проведения нескольки раз "Загрузка из кассы + Выгрузка в кассу" остатки могут выровняться по некоторым товарам, а могут и не выровняться! (Зависимость, пока, не нашел)
И что самое интересное, после проведения нескольки раз "Загрузка из кассы + Выгрузка в кассу" остатки могут выровняться по некоторым товарам, а могут и не выровняться! (Зависимость, пока, не нашел)
(25) Нет, это обработки!
"Загрузка из кассы" берёт из кассы чеки с движением товаров и Z-отчёты (загружает их в основную базу еФарма и формирует документы Чек и Z-Отчет)
"Выгрузка в кассу" отправляет текущие остатки товаров на складе, из основной базы, а так же новые товары, которые появились в справочнике.
Как таковых документов в "Кассмр Штрих-М" я не нашел, похоже, что вся инфа хранится только в регистрах или как-то иначе!
"Загрузка из кассы" берёт из кассы чеки с движением товаров и Z-отчёты (загружает их в основную базу еФарма и формирует документы Чек и Z-Отчет)
"Выгрузка в кассу" отправляет текущие остатки товаров на складе, из основной базы, а так же новые товары, которые появились в справочнике.
Как таковых документов в "Кассмр Штрих-М" я не нашел, похоже, что вся инфа хранится только в регистрах или как-то иначе!
Переоценивайте весь товар и в одну партию ) Интересна реакция клиента, дайте мне аскорбинку - 20 шт. Конечно, только 1 шт будет 10 руб, а 19 по 12 руб.
Честно говоря шибко не сталкивался с партионным учетом, слабо понимаю его механизм... Разве только для возврата поставщику по разным приходным ценам.
Честно говоря шибко не сталкивался с партионным учетом, слабо понимаю его механизм... Разве только для возврата поставщику по разным приходным ценам.
(12) Да, это какр аз и есть еФарма 1.
В этом большая проблема?
Постоянно вылезают проблемы с пересортицей, товары продают, а в основной базе это не отображается!
Либо может через пару дней отобразиться, либо совсем нет.
Сегодня новая проблема!
В основной базе пропали все остатки, осталисть только некоторые отрицательные!
При этом последние приходные накладные показывают поступление товара, а на остатке ничего!!!
По отчёту есть оборот за день (поступление), а остаток не меняется!
Кто знает, в чём косяк?
Сейчас тестирую базу из конфигуратора. База большая, жду долго...
В этом большая проблема?
Постоянно вылезают проблемы с пересортицей, товары продают, а в основной базе это не отображается!
Либо может через пару дней отобразиться, либо совсем нет.
Сегодня новая проблема!
В основной базе пропали все остатки, осталисть только некоторые отрицательные!
При этом последние приходные накладные показывают поступление товара, а на остатке ничего!!!
По отчёту есть оборот за день (поступление), а остаток не меняется!
Кто знает, в чём косяк?
Сейчас тестирую базу из конфигуратора. База большая, жду долго...
(19) Принцип работы системы, это "Основная база" + кассы.
Обмен проходит через текстовые файлы.
В основной базе последовательно (вручную) запускается "Получить данные из кассы" (Загрузить из кассы), а затем "Отправить данные в кассы" (Выгрузить в кассу).
Ьаким образом синхронизируются данные по продажам (чеки из кассы) и поступлениям (текущие остатки + цены + справочники из основной базы)
Обмен проходит через текстовые файлы.
В основной базе последовательно (вручную) запускается "Получить данные из кассы" (Загрузить из кассы), а затем "Отправить данные в кассы" (Выгрузить в кассу).
Ьаким образом синхронизируются данные по продажам (чеки из кассы) и поступлениям (текущие остатки + цены + справочники из основной базы)
Ещё я не понял, зачем так сложно сделали обмен кассы с базой?
Через текстовый файл выгружается инфа о продаже из кассы, через конфигурацию-синхронизатор постоянно читают данные из этого файла.
Что бы получить данные из кассы или отправить остатки в кассу, надо запустить приём данных из кассы и отправку данных обратно в кассу, через тот же текстовый файл.
И на сколько я понял на кассе (Кассир Штрих-М) тоже вся инфа хранится в текстовом файле а не в dbf.
Если я что-то напутал, прошу меня поправить!
Через текстовый файл выгружается инфа о продаже из кассы, через конфигурацию-синхронизатор постоянно читают данные из этого файла.
Что бы получить данные из кассы или отправить остатки в кассу, надо запустить приём данных из кассы и отправку данных обратно в кассу, через тот же текстовый файл.
И на сколько я понял на кассе (Кассир Штрих-М) тоже вся инфа хранится в текстовом файле а не в dbf.
Если я что-то напутал, прошу меня поправить!
(24)
у тебя не так много вариантов (в порядке адекватности):
1. найти специалиста заплатить ему денег и озадачить его своими проблемами.
2. самому изучить 1С, можно с помощью форума, и сделать все самому.
3. поменять систему на ту, которая будет удовлетворять твоим требованиям (тоже нужны будут деньги).
из этих трех вариантов, второй - самый дешевый и самый долгий... ты его выбираешь?
Кассир Штрих-М"
у тебя не так много вариантов (в порядке адекватности):
1. найти специалиста заплатить ему денег и озадачить его своими проблемами.
2. самому изучить 1С, можно с помощью форума, и сделать все самому.
3. поменять систему на ту, которая будет удовлетворять твоим требованиям (тоже нужны будут деньги).
из этих трех вариантов, второй - самый дешевый и самый долгий... ты его выбираешь?
если вы не пробиваете каждый товар по сканеру - то как вы будете указывать программе, что из 20 упаковок - 8 разных партий? ручками перевыбирать? ну-ну... все что ручками - все криво...
Выяснил ещё несколько моментов...
Самый главный это то, что программа, практически вся, самописная!!!
Соответственно тяжко будет искать инфу по ней в инете, точнее - совсем бесполезно!..
Остаётся только изучать и править.
Самый главный это то, что программа, практически вся, самописная!!!
Соответственно тяжко будет искать инфу по ней в инете, точнее - совсем бесполезно!..
Остаётся только изучать и править.
Андрей, выкладывайте, посмотрим, что за зверь такой. Но подозреваю что там ведь еще и ключи защиты нужны? Помимо стандартных :)
(41) ну и?
как и ожидалось... никаких там журналов операций нет..
обработка "Загрузка продаж из касс" берет файл и на его основе создает документы:
- Чек
- Z-отчет
- Закрытие смены.
каждый из них в свою очередь двигает регистры, как ты документы не можешь найти - тут уже без комментариев, должны быть в журнале "Общий жур."
регистр Партии из этих трех, двигает только Чек, соответственно и все твои минуса рождаются оттуда...
партии находятся по штрихкоду, при проведении чека - никаких проверок по остатку партии не делается....
криворукие писатели идиоты....
вот тебе и минуса твои.... фактически продали два препарата с разных партий, а отсканировали два раза один и тот-же штрих код....
дальше смотреть лениво.... тем более без данных
как и ожидалось... никаких там журналов операций нет..
обработка "Загрузка продаж из касс" берет файл и на его основе создает документы:
- Чек
- Z-отчет
- Закрытие смены.
каждый из них в свою очередь двигает регистры, как ты документы не можешь найти - тут уже без комментариев, должны быть в журнале "Общий жур."
регистр Партии из этих трех, двигает только Чек, соответственно и все твои минуса рождаются оттуда...
партии находятся по штрихкоду, при проведении чека - никаких проверок по остатку партии не делается....
криворукие писатели идиоты....
вот тебе и минуса твои.... фактически продали два препарата с разных партий, а отсканировали два раза один и тот-же штрих код....
дальше смотреть лениво.... тем более без данных
(47) Тогда почему остатки плывут?
В основном бывает зависание остатков но некоторым номенклатурам-партиям.
Причем ПОСЛЕ НЕСКОЛЬКИХ выгрузок-загрузок "Из кассы"-"В кассу" остатки частично или полностью исправляются! (Одного раза мало бывает)
Исправится может сразу или через неделю, а может и совсем не исправиться! (Хотя продажи по кассе проходят!)
В кассе все товары пробиваются сканером штрих-кода. Соответственно ошибка исключена.
Я понимаю, если "пикнули" мелочевки и отдали 50 шт. таблеток (Не пропикивали каждую, а указали количество и отдали не из той партии). Но такое бывает и с дорогими лекарствами, которых 1-2 шт всего! Тут уж точно не должно быть ошибки!
Вот я и думаю, куда копать?..
В основном бывает зависание остатков но некоторым номенклатурам-партиям.
Причем ПОСЛЕ НЕСКОЛЬКИХ выгрузок-загрузок "Из кассы"-"В кассу" остатки частично или полностью исправляются! (Одного раза мало бывает)
Исправится может сразу или через неделю, а может и совсем не исправиться! (Хотя продажи по кассе проходят!)
В кассе все товары пробиваются сканером штрих-кода. Соответственно ошибка исключена.
Я понимаю, если "пикнули" мелочевки и отдали 50 шт. таблеток (Не пропикивали каждую, а указали количество и отдали не из той партии). Но такое бывает и с дорогими лекарствами, которых 1-2 шт всего! Тут уж точно не должно быть ошибки!
Вот я и думаю, куда копать?..
(43) Спасибо, покопаю ещё в этом направлении.
>вот тебе и минуса твои.... фактически продали два препарата с разных партий, а отсканировали два раза один и тот-же штрих код....
Проверка идёт на кассе, в момент пробития товара.
Но, похоже, в этом и проблема, что повторно не проверяется при проведении чеков в основной базе.
>вот тебе и минуса твои.... фактически продали два препарата с разных партий, а отсканировали два раза один и тот-же штрих код....
Проверка идёт на кассе, в момент пробития товара.
Но, похоже, в этом и проблема, что повторно не проверяется при проведении чеков в основной базе.
(46) Вроде разобрался со встроенной обработкой.
Она самописная и для XML есть ,но недоделанная (т.к. всё вертелось на DBF)
Неделя разборов и доделок и всё заработало!
Всем спасибо за помощь.
Загрузка через XML заработала!
Осталась "малочь" - избавиться от минусов при продаже товаров ;)
Она самописная и для XML есть ,но недоделанная (т.к. всё вертелось на DBF)
Неделя разборов и доделок и всё заработало!
Всем спасибо за помощь.
Загрузка через XML заработала!
Осталась "малочь" - избавиться от минусов при продаже товаров ;)
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот