Платформа 1С v8.x (все механизмы)
Управляемые формы
Платформа 1С v7.7 (все механизмы)
Конфигурации 1cv8
Конфигурации 1cv7
FR_Atol_Shtrih.exe печать чеков для ККМ АТОЛ и ШТРИХ на основании текстового файла, где содержится описание товаров, цен, НДС (все требования 54ФЗ поддержка изменений от 01/07/19). Для 1С (7.7 и:8 УФ, Обычных Формы) есть готовые обработки
Это программа печати чеков, которая читает обычный текстовый файл, где перечислено, что надо распечатать на ФР - описание содержимого чека. Такой механизм позволяет использовать комплект для WEB сайтов, для не типовых или сильно измененных 1с7 или 1с8. Для любых программ которые умеют работать с текстовыми файлами (будь то CLIPPER,FOXPRO,JAVA, WSH, VBS итд). Внутри комплекта лежат готовые внешние печатные формы для печати из документов Реализация товаров и услуг 1с8 УТ10, БП2, БП2Базовая, БП2Корп, УТ11, БП3, БП3Базовая, БП3Корп,
Для 1с:ТиС 7.7 Реализация ТМЦ, Бух4.5, Бух1.3 и Печать из ПКО
Подключать ФР к 1С не надо! Не надо открывать смену. Подходит для любой конфигурации, для любого документа.
Более 300 внедрений на ккм Штрих-Мини-ФР-К, Штрих ОнЛайн Атол 11Ф, 55Ф, 30.
Возможна пробитие оплаты наличным или VISA (Электронные деньги). Поддерживает передачу в ОФД имени кассира, телефон или email покупателя. Для каждого чека можно поменять ОСН (ЕНВД, Доходы-расходы итд). Возможна печать чека с выровненными колонками, Наименование,Количество Цена, Сумма, в этом случае фискализация будет одной строкой с общей суммой. Можно пробить не фискальный чек. (чек будет, но в налоговую не уйдет). Добавлена расшифровка длинных наименований, что актуально для Штрих (программа сама переносит длинные наименования на след строку). Есть внесение и выплата денег. 29.06.17 добавлено пробитие 2 видов оплат в одном чеке.
Для 1с:ТиС 7.7 Реализация ТМЦ, Бух4.5, Бух1.3 и Печать из ПКО
Подключать ФР к 1С не надо! Не надо открывать смену. Подходит для любой конфигурации, для любого документа.
Более 300 внедрений на ккм Штрих-Мини-ФР-К, Штрих ОнЛайн Атол 11Ф, 55Ф, 30.
Возможна пробитие оплаты наличным или VISA (Электронные деньги). Поддерживает передачу в ОФД имени кассира, телефон или email покупателя. Для каждого чека можно поменять ОСН (ЕНВД, Доходы-расходы итд). Возможна печать чека с выровненными колонками, Наименование,Количество Цена, Сумма, в этом случае фискализация будет одной строкой с общей суммой. Можно пробить не фискальный чек. (чек будет, но в налоговую не уйдет). Добавлена расшифровка длинных наименований, что актуально для Штрих (программа сама переносит длинные наименования на след строку). Есть внесение и выплата денег. 29.06.17 добавлено пробитие 2 видов оплат в одном чеке.
Лучшие комментарии
Остальные комментарии
Избранное
Подписка
Сортировка:
Древо
(3)
(5)
Кратко: Создается Заказ покупателя, на основании заказа - РТУ и ПКО. В ПКО с реквизите "Основание" указывается "Счет на оплату покупателю". Именно Счет - РТУ не подтягивается! Из ПКО печатаем чек ККМ. В чеке - наименования товаров из счета. Если в ПКО основание для платежа не заполнено (сам ПКО создавался на основании счета), то печатается контрагент, пустое основание и сумма.
Возможно подобная схема работает и в УТ.
С моей точки зрения - это косяк 1С. В ПКО основанием должны быть как счет на оплату, так и РТУ.
ЗЫ: Кстати, чек печатается со всеми реквизитами по 54 ФЗ.
Не совсем так, реализация не является основанием для оплаты, им является счет на оплату, так что с точки зрения логики все корректно.
(5)
Кратко: Создается Заказ покупателя, на основании заказа - РТУ и ПКО. В ПКО с реквизите "Основание" указывается "Счет на оплату покупателю". Именно Счет - РТУ не подтягивается! Из ПКО печатаем чек ККМ. В чеке - наименования товаров из счета. Если в ПКО основание для платежа не заполнено (сам ПКО создавался на основании счета), то печатается контрагент, пустое основание и сумма.
Возможно подобная схема работает и в УТ.
С моей точки зрения - это косяк 1С. В ПКО основанием должны быть как счет на оплату, так и РТУ.
ЗЫ: Кстати, чек печатается со всеми реквизитами по 54 ФЗ.
Не совсем так, реализация не является основанием для оплаты, им является счет на оплату, так что с точки зрения логики все корректно.
На основании РТУ должен создаваться ПКО, а из него печататься чек ККМ.
На днях занимался настройкой печати чека ККМ с наименованиями товаров, согласно 54 ФЗ, из БП 3.0. Тестировал на трех фискальниках: Атол 22Ф, Атол 30Ф и Атол 55Ф. Везде печатается нормально, с наименованиями.
Кратко: Создается Заказ покупателя, на основании заказа - РТУ и ПКО. В ПКО с реквизите "Основание" указывается "Счет на оплату покупателю". Именно Счет - РТУ не подтягивается! Из ПКО печатаем чек ККМ. В чеке - наименования товаров из счета. Если в ПКО основание для платежа не заполнено (сам ПКО создавался на основании счета), то печатается контрагент, пустое основание и сумма.
Возможно подобная схема работает и в УТ.
С моей точки зрения - это косяк 1С. В ПКО основанием должны быть как счет на оплату, так и РТУ.
ЗЫ: Кстати, чек печатается со всеми реквизитами по 54 ФЗ.
На днях занимался настройкой печати чека ККМ с наименованиями товаров, согласно 54 ФЗ, из БП 3.0. Тестировал на трех фискальниках: Атол 22Ф, Атол 30Ф и Атол 55Ф. Везде печатается нормально, с наименованиями.
Кратко: Создается Заказ покупателя, на основании заказа - РТУ и ПКО. В ПКО с реквизите "Основание" указывается "Счет на оплату покупателю". Именно Счет - РТУ не подтягивается! Из ПКО печатаем чек ККМ. В чеке - наименования товаров из счета. Если в ПКО основание для платежа не заполнено (сам ПКО создавался на основании счета), то печатается контрагент, пустое основание и сумма.
Возможно подобная схема работает и в УТ.
С моей точки зрения - это косяк 1С. В ПКО основанием должны быть как счет на оплату, так и РТУ.
ЗЫ: Кстати, чек печатается со всеми реквизитами по 54 ФЗ.
Спасибо! У меня почти такой же на Атоле. 55Ф. А на штрихе другой! Сейчас пробовал с УТ10 сделать печать через ЗН и ПКО - блин замучался. Пишет что смена открыта, а закрыть ее не может - потому что смены в программе нет! замкнутый круг. Через свою обработку я вообще печатаю что хочу без всяких закрытий смен и др подобного гемора.
(10) Я к УТ 10.3 подключал Штрих-М 02Ф (доработанный). Там есть некоторые глюки, но пока не понял с чем связано: с конкретным экземпляром фискальника, с УМ, с прошивкой или с УТ. С безналом беда. У клиента магазин отделочных материалов. Торгуют как в розницу, так и оптом (имеется ввиду схема: РТУ -> ПКО -> Чек ККМ). Пока не было вопросов. Завтра, вроде, намечается встреча - проверю полный цикл у них, самому интересно.
Александр, а какая версия УТ?
Александр, а какая версия УТ?
Я пробовал стандартный механизм на 10.3 самой последней. Я завтра тоже попробую с 10.3 разобраться до конца. У меня на ФР оказалась открыта смена.1c видит открытую смену и не дает закрыть, т.к. продаж не было (база чистая) Я снял Z-отчет, не помогает.
А для моей прогр все равно! я ее поставил и все сделал! Даже не надо подкл ФР к 1с, Не надо смену в 1с открывать, закрывать. Люди работают как и раньше только в добавок к печт форме с РасхНакл, сф (или УПД) и пко добавляется чекККМ на ФР. все!
Отпишись пож-та как получилось с УТ10
А для моей прогр все равно! я ее поставил и все сделал! Даже не надо подкл ФР к 1с, Не надо смену в 1с открывать, закрывать. Люди работают как и раньше только в добавок к печт форме с РасхНакл, сф (или УПД) и пко добавляется чекККМ на ФР. все!
Отпишись пож-та как получилось с УТ10
Внедрение ккт предполагает четкий регламент работы. т.е. каждый день должна открываться смена и каждый день она должна закрываться. Плюс уже есть обработки, которые не формируют документ кассовой смены, а открывают смену при первой печати чека, плюс печатают список номенклатуры из документа Приходный кассовый ордер и расходный кассовый ордер. Но за оригинальную реализацию +
(14) Согласен. В последних версиях добавлен функционал "Управление фискальным устройством" (или регистратором). Там присутствует открытие и закрытие кассовой смены. В предыдущих версиях открытие было при пробитии первого чека. При открытии и закрытии смены на фискальнике в 1С данные операции не будут отражены. Соответственно рушится вся цепочка: Открытие смены -> Чеки ККМ -> Закрытие смены -> Отчет о розничных продажах -> Выемка ДС из кассы ККМ -> ПКО с видом "Выемка" (или "Прием розничной выручки") с оприходованием в основную кассу организации. Если клиента интересует только печать чека и отправка в ОФД, то открытие и закрытие на ФР прокатит. Но возникает вопрос: как 1С отреагирует на открытую смену на ФР, если в самой 1С нет открытых смен? У меня даже при печати из ПКО, если идет рассинхрон смен в 1С и ФР, возникает ошибка. С другой стороны, РТУ подразумевает просто отгрузку покупателю, не более того. Соответственно печатать чек ККМ из реализации неразумно, т.к. в 1С, в данном случае, отсутствует поступление ДС. Поступление оформляется ПКО. Таким образом напрашиваются два варианта работы:
1. РТУ -> ПКО -> Чек ККМ. Чек заполняется данными из РТУ.
2. РТУ -> Чек ККМ -> ПКО. При пробитии чека из РТУ автоматически создается соответствующий ПКО.
Но у Александра обработка не привязана к 1С. Соответственно, нужно использовать первый вариант с небольшими правками конфы. Но конфу править нежелательно. Тогда нужно использовать типовые механизмы. Про БП 3.0 я уже писал выше - там все работает, только пляшется от счета на оплату, а не от РТУ. Сегодня посмотрю, как данный механизм реализовали в УТ 10.3. Но что-то мне подсказывает, что в УТ-шке он не будет работать...
Возвращаемся к обработке Александра. :)
1. РТУ -> ПКО -> Чек ККМ. Чек заполняется данными из РТУ.
2. РТУ -> Чек ККМ -> ПКО. При пробитии чека из РТУ автоматически создается соответствующий ПКО.
Но у Александра обработка не привязана к 1С. Соответственно, нужно использовать первый вариант с небольшими правками конфы. Но конфу править нежелательно. Тогда нужно использовать типовые механизмы. Про БП 3.0 я уже писал выше - там все работает, только пляшется от счета на оплату, а не от РТУ. Сегодня посмотрю, как данный механизм реализовали в УТ 10.3. Но что-то мне подсказывает, что в УТ-шке он не будет работать...
Возвращаемся к обработке Александра. :)
(17) в последней версии торговли при печати из приходника, если операция "Оплата от покупателя", то выполняется запрос к документам взаиморасчета или сделке, и из них получается номенклатура, документ основания не используется. В моей обработке выполнено похоже, только еще добавлен документа основания и форма, показывающая распечатываемую номенклатуру. Поэтому для операций не связанных с розничной торговлей достаточно иметь связку "реализация" - "Приходник" и все. Такой перехват больше подошел бы для старых фискальников, где не требуется вводить email или номер телефона.
(18) Я эксперементировал с приходником только в БП 3.0. В ней реализовано именно так, как я описал: Если в ПКО поле "Основание" не заполнено, то на чеке печатается контрагент, пустое основание и сумма. Если заполнено, то печатается чек с номенклатурой из счета на оплату. РТУ в качестве документа-основания в ПКО почему-то не подтягивается. Нужно плясать именно от счета, что не совсем удобно ИМХО.
С QR кодом я не заморачиваюсь он сам печатается без моего участия. А передача в налоговую будет по проводам. это сам ФР делает. У Штриха например пришлось прописывать IP у нас сеть в кафе защищенная. А так только регистрация в личн каб нужна и все.
Я с ФР уже 10 лет работаю. у меня свой софт стоит в ресторанах, никакого открытия смены и тд. Это делает ФР при первом пробитом чеке. Смена закрывается в конце дня z-отчетом на ФР.
В своей софтине я сделал тоже самое. Не нужно открытие смены и закрытие. все просто! 1с любит все усложнять!
ЗЫ: ага Тюмень!
В своей софтине я сделал тоже самое. Не нужно открытие смены и закрытие. все просто! 1с любит все усложнять!
ЗЫ: ага Тюмень!
Не, ребята не согласен. В моем механизме ничего в конфигурации менять не надо! Выписываем РТУ, Печатаем ЧекККМ, делаем на осн РТУ ПКО. Вот и все. все как в прежние времена - просто. Сколько товаров и денег пробито в РТУ столько и напечатает ЧекКММ.
(21) Александр, твой механизм, как я понял, работает следующим образом: открывается кассовая смена на ФР, создается РТУ, печатается чек, из РТУ создается ПКО. Т.е. 1С "не знает" о ФР ничего. Как будет работать твоя связка при розничной торговле?
Я же просто хотел донести мысль, что, в принципе, в 1С печать чеков из ПКО работает, но не совсем корректно. Люди же привыкли как работать? Есть РТУ, создаем ПКО и печатаем чек. Или, в твоем случае, РТУ, чек, ПКО. Но штатно, оказывается, для отражения номенклатуры в чеке первым доком должен быть счет, что для клиента неудобно. Если из счета создается ПКО, то "Основание" заполняется автоматически. Если ПКО делать из РТУ, то счет, в качестве основания, нужно подтягивать руками. Причем предлагается выбрать из всех счетов, созданных в системе, без фильтров. Я считаю, что счет на оплату - это лишнее.
Далее, я предпочитаю максимально использовать механизмы, заложенные в типовой конфигурации. При необходимости - правим конфу, используем механизм расширений или внешние обработки. Плюсы такого подхода очевидны: все крутится в едином информационном пространстве. В твоем случае - фискальник сам по себе, 1С - сама по себе. Да, ты используешь инфу из 1С для печати чека, но это все. Как быть с розничной торговлей? Ведь там четкий алгоритм действий. При закрытии КС, чеки ККМ архивируются или удаляются, формируется отчет о розничных продажах и т.д. Т.е. 1С очень тесно взаимодействует с ФР.
Я же просто хотел донести мысль, что, в принципе, в 1С печать чеков из ПКО работает, но не совсем корректно. Люди же привыкли как работать? Есть РТУ, создаем ПКО и печатаем чек. Или, в твоем случае, РТУ, чек, ПКО. Но штатно, оказывается, для отражения номенклатуры в чеке первым доком должен быть счет, что для клиента неудобно. Если из счета создается ПКО, то "Основание" заполняется автоматически. Если ПКО делать из РТУ, то счет, в качестве основания, нужно подтягивать руками. Причем предлагается выбрать из всех счетов, созданных в системе, без фильтров. Я считаю, что счет на оплату - это лишнее.
Далее, я предпочитаю максимально использовать механизмы, заложенные в типовой конфигурации. При необходимости - правим конфу, используем механизм расширений или внешние обработки. Плюсы такого подхода очевидны: все крутится в едином информационном пространстве. В твоем случае - фискальник сам по себе, 1С - сама по себе. Да, ты используешь инфу из 1С для печати чека, но это все. Как быть с розничной торговлей? Ведь там четкий алгоритм действий. При закрытии КС, чеки ККМ архивируются или удаляются, формируется отчет о розничных продажах и т.д. Т.е. 1С очень тесно взаимодействует с ФР.
В ней выбирается тип оплаты, остальное она делает сама. Может мне выложить документацию за 0 стартмани?
Прикрепленные файлы:
Документация.docx
(34) в оптовой торговле это же не "продавец", а менеджер по продажам и у него может быть не одна реализация, а десяток, а может и сотня, и отдается чек не сразу, а прикрепляется к документам, поэтому тут не мудрено запутаться. ну в принципе конечно можно и наказывать за двойную фискализацию, но чек то все равно прошел, и не на маленькую сумму.
На штрихе снят Z-отчет и смена открыта через их драйвер
При печати чека из ПКО выдает что Кассовая смена не открыта, а при открытии смены, пишет что команда не поддерживается. Это со Штрихом, с Атолом была подобная же ситуация.
При печати чека из ПКО выдает что Кассовая смена не открыта, а при открытии смены, пишет что команда не поддерживается. Это со Штрихом, с Атолом была подобная же ситуация.
Дмитрий лови. Высылаю всю папку.
я обновил публикацию, добавил картинки, как все работает. и обновил документацию она доступна по ссылке в публикации. Если что не понятно - пишите. Лучше в почту или viber +79129291010
я обновил публикацию, добавил картинки, как все работает. и обновил документацию она доступна по ссылке в публикации. Если что не понятно - пишите. Лучше в почту или viber +79129291010
Прикрепленные файлы:
УТ10_11_ФР_Комплект_примеры.rar
папка должна называться C:\1c_ShtrihFR\ если будете использовать обработки из комплекта.
Если правильно установили дрова от ФР то при запуске из папки батника atol.bat или shtrih.bat у вас должен вылезти чек.
после того как чек вылез FR_Atol_Shtrih.exe убъет файл cmd.ini и будет ждать следующий с новой командой
Если правильно установили дрова от ФР то при запуске из папки батника atol.bat или shtrih.bat у вас должен вылезти чек.
после того как чек вылез FR_Atol_Shtrih.exe убъет файл cmd.ini и будет ждать следующий с новой командой
Никак. 10 лет работы этого софта, только немного в другом обличии, показали что без этого вполне можно обойтись. Ошибочно пробитый чек прикалывается к объяснительной и уходит в бух.
Если будет необходимость такую опцию можно реализовать
Если будет необходимость такую опцию можно реализовать
1) как в чеке указать скидки?
2) как в чеке указать НДС (10% или 18% в зависимости от позиции товара)?
3) согласно 54-ФЗ в чеке должно печататься ФИО текущего кассира. Предусмотрена ли автоматическая передача в чек ФИО кассира из 1С при окончании смены предыдущего кассира?
4) в чеке должна указываться система налогообложения. Организация может использовать разные системы налогообложения одновременно.
Предусмотрена ли переключение на ФР режимов налогообложения? Например, оптовому покупателю печатаем чек с указанием НДС для каждой позиции товар, при этом в чеке указывается ОСН. Розничному покупателю печатаем на этом же ФР чек без НДС, в чеке указывается ЕНВД.
5) при большом потоке покупателей большое значение имеет устойчивая связь между учетной системой и оборудованием. При печати чека в случае сбоя ФР (закончилась бумага или пр.) возвращается ли в 1С событие об этом? Это нужно например, если 1С отправляет чек не только на ФР, но и в ЕГАИС. В случае сбоя на ФР, нужно автоматически отправить отменяющий чек в ЕГАИС.
6) Как без доработки конфигурации (у вас это заявлено) проставляется в документах 1С признак пробития чека на ФР (напр. в документе 1с 7.7 ЧекККМ), для того чтобы при закрытии кассовой смены автоматически создавался отчет кассовой смены? Учитываются ли при этом автоматически чеки, которые в 1С провелись, но из-за сбоя ФР, не были пробиты?
7) как вы обеспечиваете передачу в ОФД правильной суммы чека, в случае ошибок округления из-за скидок? Например, в документе 1С кол=2, цена=390,07, скидка 5%, сумма= 741.13. Как вы обеспечите передачу в ОФД данных без искажения суммы чека? Если передать в чек цену с учетом скидки, то получится 2*370.57 = 741.14 (искажение на 1 коп). А нужно передать как на фото (см. вложение)
PS остальные вопросы задам после получения ответов на эти.
2) как в чеке указать НДС (10% или 18% в зависимости от позиции товара)?
3) согласно 54-ФЗ в чеке должно печататься ФИО текущего кассира. Предусмотрена ли автоматическая передача в чек ФИО кассира из 1С при окончании смены предыдущего кассира?
4) в чеке должна указываться система налогообложения. Организация может использовать разные системы налогообложения одновременно.
Предусмотрена ли переключение на ФР режимов налогообложения? Например, оптовому покупателю печатаем чек с указанием НДС для каждой позиции товар, при этом в чеке указывается ОСН. Розничному покупателю печатаем на этом же ФР чек без НДС, в чеке указывается ЕНВД.
5) при большом потоке покупателей большое значение имеет устойчивая связь между учетной системой и оборудованием. При печати чека в случае сбоя ФР (закончилась бумага или пр.) возвращается ли в 1С событие об этом? Это нужно например, если 1С отправляет чек не только на ФР, но и в ЕГАИС. В случае сбоя на ФР, нужно автоматически отправить отменяющий чек в ЕГАИС.
6) Как без доработки конфигурации (у вас это заявлено) проставляется в документах 1С признак пробития чека на ФР (напр. в документе 1с 7.7 ЧекККМ), для того чтобы при закрытии кассовой смены автоматически создавался отчет кассовой смены? Учитываются ли при этом автоматически чеки, которые в 1С провелись, но из-за сбоя ФР, не были пробиты?
7) как вы обеспечиваете передачу в ОФД правильной суммы чека, в случае ошибок округления из-за скидок? Например, в документе 1С кол=2, цена=390,07, скидка 5%, сумма= 741.13. Как вы обеспечите передачу в ОФД данных без искажения суммы чека? Если передать в чек цену с учетом скидки, то получится 2*370.57 = 741.14 (искажение на 1 коп). А нужно передать как на фото (см. вложение)
PS остальные вопросы задам после получения ответов на эти.
Прикрепленные файлы:
основанием для оплаты может являться реализация. так как она выполняет роль договора, в котором детализируются цены. суммы. количества. сроки (ничто не мешает в трог12 или упд вписать срок оплаты). Счет на оплату выполняет роль такого же договора/спецификации к договору, по счету выполняется не оплата, а предоплата. при этом еще следует учесть что существует неоднозначные трактовки и для минимизации рисков предоплата не прото по непонятному "договору". где ни цнен, ни сроков ни прочих атрибутов договора, а при получении предоплаты рекомендуется оформлять вполне конкретную спецификацию как приложение к договору (по стуи тот же самый счет)
Добрый день!
У нас 4 юр. лица в одной базе 7.7. Соответственно 4 принтера в разных концах города подключены к этой базе по удалённому доступу. Можно ли применить Вашу разработку чтобы из документа, принадлежащего определённой фирме шла печать на нужный принтер?
У нас 4 юр. лица в одной базе 7.7. Соответственно 4 принтера в разных концах города подключены к этой базе по удалённому доступу. Можно ли применить Вашу разработку чтобы из документа, принадлежащего определённой фирме шла печать на нужный принтер?
Поддерживаю пред идущего оратора:
"1) как в чеке указать скидки?
2) как в чеке указать НДС (10% или 18% в зависимости от позиции товара)?
3) согласно 54-ФЗ в чеке должно печататься ФИО текущего кассира. Предусмотрена ли автоматическая передача в чек ФИО кассира из 1С при окончании смены предыдущего кассира? "
Причем НДС должен быть указан для каждой позиции.
+ должен быть тип операции "Приход", "Возврат прихода" и т.п.
Я так понимаю, это не реализовано? Будет ли реализовано?
"1) как в чеке указать скидки?
2) как в чеке указать НДС (10% или 18% в зависимости от позиции товара)?
3) согласно 54-ФЗ в чеке должно печататься ФИО текущего кассира. Предусмотрена ли автоматическая передача в чек ФИО кассира из 1С при окончании смены предыдущего кассира? "
Причем НДС должен быть указан для каждой позиции.
+ должен быть тип операции "Приход", "Возврат прихода" и т.п.
Я так понимаю, это не реализовано? Будет ли реализовано?
Вот и меня озадачили.
За старания конечно плюс.
Видимый главный минус - можно напечатать один ПКО разными чеками. Используйте стандартный механизм хранения, он по крайней мере есть в ПКО в КА 1.1.
Другие минусы всплывают позже...
Не вижу возможности нашего случая:
Оптовики. Все ПКО создаются на основание Заказа покупателя, ПКО может быть один. Реализаций может быть несколько. Заранее может быть не известно какая номенклатура поедет. ПКО может быть несколько, реализаций может быть несколько, а заказ один. Иногда иделаьно известно, что чек полностью соответствует реализации, но так не всегда. В рознице проще, реализация = чеку.
Сам планирую подчерпнуть идею и вашу и того товарища , реализовать с использованием стандартных механизмов, конечно не факт что будет обработка универсальной, но по крайней мере будет работать в Комплексной автоматизации 1.1.
Правда пока писал ответ, за три часа всё переиграли и задание приостановили)))
За старания конечно плюс.
Видимый главный минус - можно напечатать один ПКО разными чеками. Используйте стандартный механизм хранения, он по крайней мере есть в ПКО в КА 1.1.
Другие минусы всплывают позже...
Не вижу возможности нашего случая:
Оптовики. Все ПКО создаются на основание Заказа покупателя, ПКО может быть один. Реализаций может быть несколько. Заранее может быть не известно какая номенклатура поедет. ПКО может быть несколько, реализаций может быть несколько, а заказ один. Иногда иделаьно известно, что чек полностью соответствует реализации, но так не всегда. В рознице проще, реализация = чеку.
Сам планирую подчерпнуть идею и вашу и того товарища , реализовать с использованием стандартных механизмов, конечно не факт что будет обработка универсальной, но по крайней мере будет работать в Комплексной автоматизации 1.1.
Правда пока писал ответ, за три часа всё переиграли и задание приостановили)))
(78) Тогда поставлю вопрос, по-другому, наименования переносятся или обрезаются? Длинные - комплектующие пластиковых окон, там для клиентов нужен цвет и типоразмер и бренд, иначе не поймут. И что со ставкой НДС на единицу номенклатуры, конкатенировать к наименованию или будет доработка? С 01.02.17 это обязательный реквизит, к сожалению, видно для торговцев продтоваров 18 или 10 %, но обязывают всех, даже ООО на УСН без НДС.
(80) Вот в том-то и беда - постоянно изменяющиеся требования налоговой к обязательным реквизитам онлайн чека. Сейчас по ссылкам из (77), кстати ссылки открыты для всех и пароля на электронный ИТС не требуют, цитирую:
наименование товаров, работ, услуг, платежа, выплаты, их количество, цена за единицу с учетом скидок и наценок, стоимость с учетом скидок и наценок, с указанием ставки НДС
Думал сконкатенировать ставку в конец намиенования, теперь похоже придется в начало, интересно, как на такие наименования отреагирует налоговая :) Короче, пожелание - ставку желательно бы выделить при печати цены и суммы товара отдельным полем. Про НДС внизу чека разговора нет - там и ставка и сумма.
Тоже из ссылки (77)
порядковый номер за смену;
сейчас похоже (еще не смотрел, аналогично командировка), это номер РТУ, а надо 1,2,3.... и.т.д.. каждую смену? Или я что-то не понял? Горе небольшое - создать справочник с единственной записью - дата и текущий номер чека, что-то регистр сведений городить не хочется, смысл в нем, все данные будут в ФН, надо налоговой - прочтет. И простейший алгоритм - перед формирование чека НачалоДня(ТекущаяДата()) и то же самое для поля справочника, не совпало - №1, и поменяли дату и номер чека в справочнике, совпало - прибавили 1, записали в справочник, передали на печать чека. Были у Вас вопросы от налоговой по номеру чека?
наименование товаров, работ, услуг, платежа, выплаты, их количество, цена за единицу с учетом скидок и наценок, стоимость с учетом скидок и наценок, с указанием ставки НДС
Думал сконкатенировать ставку в конец намиенования, теперь похоже придется в начало, интересно, как на такие наименования отреагирует налоговая :) Короче, пожелание - ставку желательно бы выделить при печати цены и суммы товара отдельным полем. Про НДС внизу чека разговора нет - там и ставка и сумма.
Тоже из ссылки (77)
порядковый номер за смену;
сейчас похоже (еще не смотрел, аналогично командировка), это номер РТУ, а надо 1,2,3.... и.т.д.. каждую смену? Или я что-то не понял? Горе небольшое - создать справочник с единственной записью - дата и текущий номер чека, что-то регистр сведений городить не хочется, смысл в нем, все данные будут в ФН, надо налоговой - прочтет. И простейший алгоритм - перед формирование чека НачалоДня(ТекущаяДата()) и то же самое для поля справочника, не совпало - №1, и поменяли дату и номер чека в справочнике, совпало - прибавили 1, записали в справочник, передали на печать чека. Были у Вас вопросы от налоговой по номеру чека?
(85) Спасибо, все прояснилось, в качестве минимального замечания: в скачиваемом архиве с обработками документации нет, скорее так и задумано, чтобы посмотреть без стартмани, но в свежей документации - (52) пост указано, что надо только проверить параметр запуска - Штрих или Атол во внешней печатной форме, не написано, что далее надо заменить кассира Петрова и ООО "Ромашка" :))) (Это ВПФ под 8.2)
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
|
|
Обмен с системой ЦРПТ (Универсальная конфигурация ХамелеонЦРПТ + маркировка табака, обуви, лекарств, света, молока, духов(парфюма) и шин
Открыть
Вакансии
Технический лидер, архитектор 1С, руководитель проектов
Санкт-Петербург
зарплата от 150 000 руб.
Полный день
Санкт-Петербург
зарплата от 150 000 руб.
Полный день
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
Открыть