Розничная торговля.

Есть 2 категории товаров.

1 категория - буквально 10 позиций, усиленный контроль и оперативный учет
2 категория - десятки тысяч позиций (из-за бардака в локальных точках, унификация товаров не требуется), контроль что бы было, данные нужны не оперативной


Есть идея сделать отдельные системы учета в рамках одной конфигурации для каждой категории товаров. Однозначно отдельные отчеты. Скорее всего отдельные справочники товаров. И возможно отдельные документы для каждого вида товаров (возможно сам документ один, но в один документ товары из разных категорий не пихать)


Что думаете?

(105)ну так это же большие деньги.
А 7-ка самописка летает

(105)+ Стоимость железа и сервера 1С/SQL дешевле, быстрее и надежней найма прогов

(107)Угу, а еще адаптация учета.

Нет не выгоднее в моем случае

(106) Да не летает она! Она нихрена не может и не умеет
Т.е. там нет функционала разного вот и кажется что быстро работает
А по факту опс и этого нет упс и обновлений нет (разработчик ушел) и привет

(108) Вы можете по прежнему взять счеты и арифмометр и радоваться дешевизне учета

(109)Это ты мне рассказываешь - как разработчику  и главному пользователю

Еще раз. Я двумя руками за типовые БП 3,0, но это невозможно в моем случае

(110)И это тоже не вариант

(+111)Точнее тоже вариант. Не может сейчас АЗС позволить такие траты

Что ж такого наваяли в бп3.0 что она перестала подходить для таких мелких доработок?

(113)Что же как узко вы мыслите. Дело не в мелких доработках

(102) идеального решения не существуют у любого есть "+" и "-" и только тебе решать с какими "-" ты готов мериться, не забывай и про третий вариант, взять и навести порядок в учете.... может так случиться, что по трудозатратам он будет сравним с твоим вариантом, но в дальнейшей работе будет намного легче...

(103) в (100) нет ни слова про типовую ))

(115)Вот я как раз порядок в учете и навожу. И пытаюсь снизить трудоемкость.

ОК. Я не вижу сложности в реализации алгоритма - Если Товар.Вид="Товар" - пишем данные в регистр Товары, если Товар.Вид="НП" пишем данные в регистр Нефтепродукты

(119) а надо как? Повысить трудоемкость и сделать выбор оператору азс в какой регистр писать и из какого списывать?

Знаете, когда на товарах закончилось, взять с нефтепродуктов...

(117)Ну сколько можно. Оператор АЗС сидит на АЗС и работает с готовым купленным фронтом.
Я спрашиваю про бэк. Большая часть документов грузится автоматом. Для остальных - реквизит Товар неопределенного типа, и при выборе значения - программа спрашивает - вид номенклатуры - Товар или Нефтепродукт

А чего бензин так отличается от всего остального,я о хаосе и его автоматизации?

(120)да, отличается

(121) по кол-ву или суммовой?

(122)по количеству

(119) и вы предлагаете включить контроль отрицательных остатков при загрузке данных?
Типа одну подлодку продали пепси, хотели продать вторую а она на складе закончилось?

(123) Та может с учета количества начать,до 1с?

(124)Опять вы чего-то домысливаете. Ну не писал я про контроль остатков - не нужен он в принципе, даже на фронте
(125)ничего не понял. Учет продаж ведется в фронте, все остальное в оперативно в бэке

Я понял так,что физически нихрена не можете понять сколько у вас продано и сколько стырено.Даже с учетом нормативов потерь при переливании и прочем

(127)И вы домысливаете. Не нужен учет потерь по нормативам. Расхождения на АЗС - это норма и точка
Сколько продано мы знаем из фронта - сертифицированной ПТК

(128) Зевая уже,ну раздели на топливо и не,в чем тогда беда,поставь условие на контроль за сопуткой и убери за топливом.

Итак, мы имеем при загрузке из одного файла по каждой строке проверку на вид товара и деление на несколько накладных. Предположим, это типовая БП 3. Документ чек загружаем как есть в файле весь. Фоновым заданием обрабатываем на столько отчетов о продаже, сколько требуется по видам товаров.

(129)и за сопуткой контроль не нужен

Моя идея в том что бы разделить справочники Номенклатура на НП и Товары и регистры Остатков/Продажи.

И засирай Товары как хочешь, а вот НП - должен быть быстрый и красивый

(130)"из одного файла по каждой строке проверку на вид товара и деление на несколько накладных. " - само ПТК выдает разные файлы на НП и Товары

Меня просто бесит когда справочник Номенклатура засирается и разрастается

(131) Хм,а когда общее посчитать или по азс итог

Тем более, в любимой бп3, чек грузит на, чек1 товары. Чтобы литры со штуками не складывать.

(132)А общий итог НП+Товары он редко нужен

А так идея простая - в регистр НП_Продажи пишем сводный итог по продажам товаров - на один элемент Товары АЗС.

(133)не понял. Вообще в БП3 грузим Отчет о розничных продажах, а не Чеки. От чеков БП помрет

(+134)А уж продажи по Товарам вообще считай не нужны

Чеки на фронте это чеки, чеки в бп это отчет о розничных продажах азс, а отчет о розничных продажах в бп списывает остатки. Товары хотите проводить как продажу с нтт?

На каждую азс розничный магазин для НП и НТТ для товаров?

(137)не получается совместить официальный учет с управленческим. А так грузим в БП3 продажи - а вот какая там точка не помню. Но все товары грузятся одной строкой Товары

(138)Даже не уверен что на каждую АЗС заведен свой магазин - не нужно это деклараций и бухотчетности

Теоретически достаточно кассы на каждую Азс. Но обычно именно кассы и не разделяют.

(141)Это все не относится к моему вопросу. В БП3 не получить общую себестоимость по нескольким организациям

А когда в бп на счете 30 нет ни аналитики ни субсчетов, все точки заведены как не автоматизированные, учет существует только управленческий.

Что мешает вместо организации в отчеты добавить выбор списка или группы организаций?

(143)А толку то. Регламентированный все равно нужен

(144)Себестоимость как общую посчитать

Общую себестоимость для регламентного учета на одном юрлице?

(146)для управленческого учета для всех юрлиц

Теоретически розничный магазин спишет НП без учета складов по фифо (но можно настроить и по каждой азс и по среднему), а нтт товары по реализованной  торговой наценке как на калькуляторе.

Не вижу причин заводить ут если можно держать копию бп только для того чтобы посчитать себестоимость с другими настройками в константах.

(148)так нам надо без учета организаций

(149)и опять двойной паралелльный учет

(150) в отчете поле организация обязательно для заполнения?

(151) в управленческом организации не важны

То есть фифо или по среднему должно быть не только без учета складов, но и без учета организаций.

когда то давно порядка 20 лет назад у нас был подобный бардак с номенклатурами.
и проблемы с обменами всего этого бардака.
переделали номенклатуру на глобальную локальную и временную.
глобальная рулилась в центре, в нее администратор справочника номенклатуры мог добавлять из времянок то что в филиалах добавляли.
в локальную каждый добавлял себе из глобала только нужное и работал потом с сокращенным списком в пару сотен а не 50+ тысяч позиций.
и мог добавить во временные то что ему понадобилось, чтобы админ затем в центре добавил или отклонил, указав ссылку на существующий элемент в глобальном.
примерно 2 месяца ушло затем на причесывание.
в итоге глобальный справочник уменьшился примерно вчетверо, поток времянок упал до комфортного для администратора номенклатуры уровня.
удобство работы в филиалах выросло на порядок, количество ошибок аналогично на порядок снизилось.

(154)Глобальный справочник не самоцель. Какой то выгоды, кроме потенциального сокращения количества позиций он не даст.

Если рассматривать каждую АЗС отдельно - то там более менее порядок в т.ч. с удобством

Перемещения между АЗС - редкость, анализ продажа товаров по АЗС не нужен


Ну и существующий фронт не имеет функционала с центральным каталогом товаров

Поэтому и хочется под товары сделать отдельный справочник - и пусть в нем будет бардак с товарами

Если я правильно понимаю, предлагается иметь глобальный справочник номенклатуры в отдельной базе по типу ИНН или маркировки, на веб сервисе, доступном с любой АЗС.
Но поскольку товары это мелочевка, вероятность что у вас дойдет до такого сценария невелика.

Топы просто не могут дать такое ТЗ, которое бы позволило потратить человеко-часы на удобство админа, а у тех кто имеет проблемы нет полномочий.

(156)Нет технической возможности даже использовать веб сервисы и прочее на АЗС. И слава богу. Существующая ПТК - даже до 1С v7.0 не дотягивает
(157)топам товары это вообще фиолетово. Что-то там продается, на полках товар стоит, сами АЗС товар заказывают, что-то продают. Один бухгалтер худо бедно это отслеживает - инвентаризации периодически делают

(0) У нас работает подобная система. Уже лет 7.
Сделали так.
В справочнике Номенклатура добавили реквизит "Аналог БУ". Каждой позиции присваивается "Аналог БУ".
Аналог БУ это тоже справочник Номенклатура, хранятся просто в отдельной папке.
Аналогов БУ у нас много около 1000, но при ассортименте 500 000 товаров это кажется немного.
Примеры Аналогов БУ:
*Свеча
*Сервировка
*Сувенирное изделие
*Товары для туризма и отдыха
*Товары для школы
*Хлопушка
*Шар воздушный
*Шар воздушный латексный
*Шар воздушный фольга


Все товары у нас со штрихкодами. Соответственно на каждую реализацию с полным перечнем товаров делаем всегда вторую реализацию свернутую по Аналогам. Есть специальная кнопка для этого, встаем на нужную Реализацию и формируем Реализацию БУ.
Так же для поступлений есть 2 документа.
Весь учет ведем в одной базе в типовых регистрах.
Аналоги БУ в основном нужны для бухгалтерии. Так как столкнулись с проблемой, что из-за огромного ассортимента бухи не могли справится с бардаком. А с 1000 позиции легко справляются.
Так же из плюсов, что у нас много складов и подразделений, а бухгалтерия вёдет все свои Аналоги на одном складе и подразделении.
Есть конечно и подводные камни и подобного подхода, мы эту систему допиливали несколько лет.

(149)Администрирование и поддержание в актуальном состоянии этой системы думаю весьма трудоемко

Почему АналогиБУ не в подчиненный справочник вынесли?

То есть ка/упп/ерп. В документах для бухучета тип операции только регламентный учет есть типоаой. Допилить требуется только с создание документа с заменой склада/подразделения/товаров на бухгалтерский анеалог.

(160) Поначалу было трудоемко, сейчас уже отточены бизнес-процессы. Но когда нам государство подкидывает новые правила такие как ведение учета на виртуальном складе (Казахстан), тут да много сложностей.
Выбрали справочник номенклатура, чтобы вести учет типовыми средствами.

И еще у нас разделитель это Организация. Весь обычный ассортимент ведем в условной организации "Упр". А реализации с аналогами ведем уже в нужной организации.
2 учета одновременно ведем в одной системе.

Можно было сделать 2 базы, как многие делают. В одной весь зоопарк товаров, в другую выгружаются свернутые товары. Но оперативность теряется.

(161)Была мысль взять для УУ типовую конфигурацию. Но этой этого костыля отказался. По трудоемкости это сопоставимо с дописыванием своей самописки. Но в самописке - будет весь необходимый удобный функционал, а в типовой можно на каком то этапе в тупике оказаться

(162)Я так понял реализации с АналогомБУ не проводятся? А при выборе позиций - сразу идет фильтр по Организации - или все и аналог и не аналоги вылезают?

(163) Проводятся все.
Ведем учет по разным организациям и складам.
В отчете просто фильтрами разделяем.
Это как вести несколько организаций в одной базе.

(164)
И на быстродействие и объем базы - учет по АналогоБУ наверное влияет отрицательно? И перепроведение документов наверное очень долгое

На а как оператор работает - вот набирает он Шар воздушный - там же куча номенклатура сразу выпадет наверное - поди разбери где аналог, а где нет

(165) Размер базы 84Гб.
Так как 500 000 товаров, то поиск по номенклатуре пришлось допилить, а то типовой очень медленно работал.
Нормально работает по быстродействию.

У нас у Аналогов БУ префикс впереди (159) я там примеры выложил, для праздничных товаров префикс впереди "*". Поэтому не спутают.
Шары Аналога БУ "*Шар воздушный", например такие:
\ШДМ 160/EV Стандарт фэшн ассорти (100шт) Малайзия 1107-0480
\ШДМ 160/Gm D2/00 макарунс Ассорти Assorted (100шт) Италия 1107-0524
\ШДМ 160/Gm D2/00 макарунс Ассорти Assorted (100шт) Италия 929317
\ШДМ 160/Gm D2/00 пастель ассорти Assorted (100шт) Италия 218015
\ШДМ 160/Gm D2/01 пастель Белый White (100шт) Италия 210118
\ШДМ 160/Gm D2/02 пастель Желтый Yellow (100шт) Италия 210217
\ШДМ 160/Gm D2/04 пастель Оранжевый Orange (100шт) Италия 210415
\ШДМ 160/Gm D2/07 пастель Фуксия Fuchsia (100шт) Италия 210712
\ШДМ 160/Gm D2/08 пастель Фиолетовый Purple (100шт) Италия 210811

У нас у каждого отдела ещё свой префикс, а то пересекаются мешают.

(166)Ну и отчет наверное с проведение документов не быстро работают - все же в одной таблице храниться

(167) Да вроде нормально работает. Любой небольшой документ в пределах секунды проводится. Расчет партии при проведении отключен. По ночам пересчитывается.
Отчет по продажам за март, по всем подразделения, без разреза номенклатуры строится около секунды.
Отчет за март по подразделению книги, с разрезом по номенклатуре, в отчет попало 3715 строк. Тоже 1-2 секунды построился.

Префиксы в наименовании печатаются в чеках или наименование формируется автоматически из полного наименования и кода пользователя?

Когда в начале деятельности мы применяли 1С Комплексная 7.7

Наелись с ней проблем, в т.ч. с партионным учетом. И 10 лет назад перешли на самописку. Проще оказалось один раз самописку написать, чем вечно с типовой бороться

(170) >> Проще оказалось один раз самописку написать, чем вечно с типовой бороться

Неужели борьба прекратилась?

(169) Да печатается с префиксами.

(154) Так сделано в сетях

(0) Твоя самописка живет до ввода 1-й маркировки, далее вас как грушу начинают трусить различные службы проверок, а бабки у вас есть

Опять же, зачем вводить 2 контура учета, если просто дописывается регистр сведений с булевым значением "контролировать", и вводится глобальная процедура контроля остатков, и запихивается во все документы связанные с товарооборотом

Как люди считают маржинальность, какие сроки годности у товаров, и прочая фигня, вообще никого не интересует?

верно?

Судя по ситуации, каждый пытается вынести из компании- максимум, кто-то товарами, кто-то обслуживанием инфраструктуры. На качество оказания услуг - вообще всем фиолетово

(174)ну на сигареты маркировка уже есть. На фронте все равботает
(175)нет задачи Контролировать
(176)Это все на откуп АЗС отдано - общая маржинальность по товарам есть - этого достаточно
(178)не верно

(179) Есть 2 категории товаров.

1 категория - буквально 10 позиций, усиленный контроль и оперативный учет

Во втором предложении ты уже начал вводить нас в заблуждение?

(180)а где тут написано что контроль именно в программе

Тут имеется ввиду 1 категорию - смотрят каждый день не по разу. А по второй категории - раз в месяц

(181)В справочник номенклатуры булево значение или подчинненный справочник значений, и всЁ. Работы на час, и вся инфраструктура с отчетностью в 8-ке работала бы из коробки

(181) Я правильно понимаю что  "оперативный учет" тоже ведется не в программе?

(182)Не получается из коробки. По причинам не связанным Номенклатурой

(183)В программе ведется

(184) Ну тогда под сменой платформы, перепиши архитектуру "правильно", установи новое оборудование и сиди в этой конторе еще 20-тку лет

Ну не вызывает в "типовых" введение дополнительного реквизита в номенклатуру проблем

Я уже понял что в современных реалиях сотни тысяч номенклатуры и отчеты по ним - проблем с производительностью не вызывают

(188) Вызывает, но есть для этого 64битный клиент

(95) Без подробностей вы не сможете получить ответ. Никто не знает - сколько в вашей самописке видов документов и регистров придется дублировать в двух контурах.
Если есть общие отчеты по этим контурам - будет неудобно собирать данные по разным источникам.

"кто не знает - сколько в вашей самописке видов документов и регистров придется дублировать в двух контурах." - 2 регистра - Остатки и Продажи
"Если есть общие отчеты по этим контурам - будет неудобно собирать данные по разным источникам." - Отчеты не пересекаются. Есть сводный отчет - но там из 2-го контура данные одной строкой проходят сводно

(191) А цель-то какая? Если фронт остается специализированным, что не устраивает в текущей системе?

(191) Ну так перепеши свой фронт на 8-ке и не парься

(192)Отделить важное от второстепенного. И пусть второстепенное засирается

"что не устраивает в текущей системе?"

Текущая система работает с 2012 года - причем полностью дублирует учет, куча костылей за годы развития. Счас пришло понимание - что есть некоторые вещи которые можно сделать более оптимально и просто (нет нужных отчетов, себестоимость считается непрозрачно). Кроме того хочется уйти от полного дублирования учета на частичное. А там может и на БП8 можно переползти будет


(192)перепиши - там программно-АППАРАТНОЕ решение

(194) Т.е. проблема в том, что себ-сть топлива и прочих товаров считается одинаковыми алгоритмами и криво?

(195)Там комплекс проблем - которые не нравится

Сейчас себестоимость считается на документ - восстановление последовательности и прочие прелести.
Планируется сделать себестоимость раз в месяц - регламентным документом

(196) Непонятно, как решению этих проблем поможет выделение несчастных 10 позиций топлива в отдельный контур.

(196) Аппаратный комплекс же кем-то сертифицирован, интеграция такая же задача, как и учетные

(197)Ну заодно это сделать для большего порядка в базе
(198)еще раз комплекс ПРОГРАММНО-АППАРАТНЫЙ - отдельно аппаратный не купишь. Да и не принято это в отрасли. Опасный производственный объект как никак

Можно просто отдельный справочник наименований товаров без привязки к учету как шаблоны (когда ваша азс начнет торговать огурцами, молочкой или шаурмой). Авторизация пользователя и даты создания в справочнике номенклатура (который в упр.учете) и автоматически заполнять поле аналог ссылкой на товары. Или у вас азс полностью самостоятельно закупает товары (например пару вагонов овса или кукурузы)?

(199) У программно-аппаратного комплекса есть апи для интеграции? или нет?

(201)нет. Там и выгрузки то нормальной нет

(200)ДА, вот именно что самостоятельно. И приходует в свой фронт тоже сама

Программно-аппаратный комплекс работает с нп или с товарами тоже?

(204)вы когда-нибудь заправлялись на АЗС? Конечно все вместе и с НП и Товарами - чек то вам один выдают

Там еще и фронт работает как мини SCADA - на экране надо в онлайне видеть - какой пистолет снят на какой колонке, идет ли отлив