Ограничители систем: дебиторки, договора, сроки годности : КИС Lack & УС Land

С этим полностью согласен и хотя разбираюсь с маркировками сроков годности при посещении сетевых магазинов всегда обязательно возьму какую-нибудь тухлятину... Уже не возмущаюсь когда жена придирчиво перебирает/выбирает товары по прямым и косвенным признакам "свежести". Возврат гав.а в сетях - нервотрёпка и может быть драконовские штрафы улучшат ситуацию.

С позиции компьютерщика контроль сроков, в том числе будущих периодов - элементарная задача, которую первоочерёдно внедряю... Хотя в моих "прилавках", где продавец своей з/пл отвечает, в том числе за это данная задачка не является шибко актуальной... Сейчас посмотрел, что "по срокам" списано на 20 000 из 793 000 (действительно 1.33% оборота по себестоимости) общих списаний, в основном "обрезки", компенсируемые поставщиками.

Чую оправданный сарказм в Вашем вопросе, отвечая "забыл", что "товар" в 1С и возможно СМ - это одноименная совокупность приходом с динамично, изменяющейся себестоимостью. В данной ситуации действительно проблематично связать товар конкретного прихода со сроком хранения. В 1Ц проблема частично решается "меньшим" объектом - ПАРТИЯ (у которой может и быть срок хранения).

У "мню" есть жесткое правило минимальной единицы - "при изменении поставщика, цены закупа" или других актуальных для фирм атрибутов заводится новая карточка товара, т.е. для строки с товаром можно однозначно определить, в частности срок хранения. Есть более "крупная" единица учета АССОРТИМЕНТ == в частности товар в терминах 1Ц с которой производятся автоматические работы (авто перевод в мои термины товаров) и постороения отчетов.

Таким образом в единственном отчете на отчетную (у кого on-line, а у кого неделя) строятся остатки товаров просроченных или которые будут просрочены в требуемое (указываемое) время по отделам магазина и продавцы "бегом" начинают искать данный товар... При налаженном порядке его 10-20 наименований из 2000-5000 позиций.

1. Через "извращение" - печать пользовательских карточек товара можно сделать свои ценники в RTF формате
2. Ценники со штрих кодами в режиме отчетов программы CST и делаются по остатку.
3. Штрих коды, в том числе локальные (генерируемые программой) ведутся в системе.

Поездка на Базарно-Карабулакский консервный завод - 90 км. от Саратова (близко - пару песен спеть). Выпускает овощные консервы под маркой "Карабуэль" (Икра кабачковая, Соус Краснодарский, Солянки, Тыква/яблоки протёртые и т.д.), одно из самых крупных областных производителей консервов (поставщик "кремля"). Телефон: (884591) - 221-81.

Стали использовать "КИС Lack" в 2007 году, как временное ПО для комплексной автоматизации производства... Катаюсь на завод раз в квартал - сейчас у босса были замечания, но как оказалось всё уже реализовано в системе.

Теперь позвольте по вопросам:

Для генерации локального (собственного) ШК - встаём в программе в полном справочнике на товар -> клавиша HOME -> вводим цифру 2 и нажимаем Enter. Локальный ШК формируется с учётом "контрольной суммы" в форме EAN-13 и читается любой программой, в частности на базе платформы 1ц.



Для печати ценников, наклеек, постоения отчетов сложных структур используется программа "Ценников". На рисунке отражена "главная форма" с основными режимами. Обведено: инфа по текущей строке, пометки для печати ценников, режимы установок пометок и три формата "ценников":

1. Просто наклейки со ШК на товары. Печатается если есть ШК в количестве (остаток+1).
2. Ценники со ШК, если его нет, то ШК заменяется "пользовательской картинкой". Печатается в количестве (остаток+1). (1,2) в режиме (отчеты). Обычно используют для одежды/обуви на каждую единицу товара.
3. До кучи. "Стелажки" (крупный формат, есть и мелкий) для аптек - государством, установленная форма. Печатается из режима (печать) по одному на каждое помеченное наименование.

Собственные форматы ценников (карточки справочного объекта). Для любого справочника можно создать свой шаблон документа в формате RTF, задать ему имя и вывести запись справочника в данный шаблон посредством встроенного генератора отчетов. В частности делали "договора поставки" по клиентам и можно создать свои форматы ценников для "товаров". Технология "не пошла" - зачем мучиться пользователям, "когда есть программист"?

Надеюсь ответил на все вопросы, в том числе уважаемой Mtirt?

ОДИН! Но отмечу, что "у меня" понятие "товар" в терминах (если не ошибаюсь?) СуперМаг - более похоже на "партия". То есть в системе КИС/УС может быть множество одноименных товаров, а объединяются они понятием "ассортимент".

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

Супер пример!!! На его основе, правда там был "хлеб" мне удалось "классно" постебаться на 1ц! История стёба:

Оноэсник хвалился, что его номенклатура (как выяснилось пишется новая запись на каждый приход от любого "источника") 15 млн.позиций. Тогда начали считать какую номенклатуру (они демонстрировали его, как справочник товаров) породит "хлебный киоск" - пусть 100 наименований с приходом дважды в день за пару лет == 146 000 Это они объявляли "крутизной 1ц", а ИМХО - это тупость платформы.

Сколько записей в справочниках и других базах будет в КИС Lack/УС Land при этом?

В начале несколько терминов, а точнее соответствия понятий между КИС и 1ц.

Товар (КИС Lack). Минимальный "товарный объект", содержащий все характеристики товара (около сотни). Программной накладывается только одно ограничение на "размножение" строк - при изменении цены закупа или поставщика вводится новая строка и это контролируется подсистемой контроля логической целостности и необходимо для точных расчетов себестоимости/дохода/прибылы и расчетов/операций с поставщиками. Более мелко - пожалуйста! Это используется для анализа вложений в закуп, системы эл. сертификации (разный набор справок), серийного хранения для аптек и т.д. "Лишние" "товарные" строки автоматически убираются в архив и не отражаются в оперативной работе. В терминах 1ц - это партия, определяемая пользователем.

Товар на складе (КИС). Справочник, используемый при отпусках покупателям и показывающий ненулевые позиции. Очищается при архивации товаров. В терминах 1ц - номенклатура.

Ассортимент (КИС). Объединенный товар (критерии объединения определяет пользователь), измеряемый в количестве единиц и суммах. Для торговли обычно объединяет одноименные товары и понятие используется при построении отчетов и некоторых оперативных режимах, например интеграции с КПК или контуре производства. В терминах 1ц - товар.

Таким образом для "хлебного киоска" или "молока", исходя, что штрих код неизменный, товар продаётся за пару дней и цены меняются раз в месяц за два года накопим (в терминах УС):

1. Товаров - 200 (300) записей.
2. Архив - 2000 (2500) записей
3. Товаров склада - 300 (500) записей.
4. Ассортименты - 100 записей.

"Предчувствие его не обмануло" - вот и не "поймали"! Всё отлично работает и даже при реальном самообслуживании когда для автоматического контроля сроков годности генерируются свои локальные ШК. Рассмотрим статистику в срезе "хлебного киоска", полагая, что новые карточки товров нужно заводить ежедневно, хотя все хлебные отделы "у меня" работают по прилавочной схеме торговли и пояснял, как там решаются вопросы по срокам.

Таким образом для "хлебного киоска" или "молока", исходя, что штрих код меняется ежедневно, товар продаётся за пару дней и цены меняются раз в месяц за два года накопим (в терминах УС):

1. Товаров - 200 (300) записей.
2. Архив - 130 000 (146 000) записей
3. Товаров склада - 300 (500) записей.
4. Ассортименты - 100 записей.

Статистика у меня не очень большая, но те что есть - не матеряться, наверное по причине малого ассортимента из Вашего примера. Только десяток сортов сыра, колбаса и чуток по-мелочи.

Но по моим расчетам для самообслуживания - две кассы... Это минимум от 200 кв.м. торговой площади и оперативный ассортимент от 1000 наименований и от 2000 чеков в день. Для таких магазинов (уже был прецендент) предлагал СуперМаг (испугала цена - "рыбку сьесть и ..."), т.к. системы КИС Lack/УС Land не потянут в силу ограничений файл-серверной архитектуры и на "разумный" размер рабочих таблиц (до 1 млн. записей).

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

1. Дата окончания лицензии, ниже срок окончания договора и в справочнике торговых точек покупателя есть "срок аренды" - в настройке программы можно запретить отпуск товаров данному клиенту или на его торговую точку при превышении ограничительных сроков.

2. Максимальное число неоплаченных (не до конца оплаченных) отгрузочных накладных - при превышении данного значения программа запрещает отгрузку.

3. Аналогично 2. - максимальное число дней неоплаты по накладным.

4. Превышении суммы "товарного кредита", установленного для конкретного покупателя.

5. Просто для справки (не относится к вопросу) - можно настроить правила скидок для клиента

P.S. Если придумаете чего нибудь ещё, что еще не сделано в системе, то с удовольствием сделаю. В принципе сообщение иллюстрировалось скринами и если интересно, то смогу их добавить?

Начнем потихоньку разбираться с атрибутами клиентов. Клиент - это несколько более широкое понятие, чем контрагент в 1ц, а именно в данном справочнике ведутся все "программные объекты" с которыми производится обмен "внешними" документами. Например:

1. Поставщики товаров и услуг... Накладные, фин.документы, акты выполненных работ, доверенности, договора и т.п.

2. Покупатели... Накладные, фин.документы, акты выполненных работ, доверенности, договора и т.п.

3. Кредиторы (банки) и должники... Как правило только фин.документы.

4. Подотчётные лица... Как правило только фин.документы и ссылки в накладных, если используется контур работы с подотчетными лицами и всей сопутствующей документацией.

5. Статьи затрат (одна из возможных технологий). Как правило только фин.документы.

6. Прочие фиктивные клиенты... Например для "правильного" оформления документации с "хитрыми" атрибутами. Как где-то упоминалось для ЛукОйл при оформлении накладных ТОРГ-12, 1Т и счетов-фактур задействовано аж ТРИ типа адресов.



Начнем с простого: Строка - "CRM: Договор: Номер ХХХХХ Дата УУУУУУУ Срок окончания дог. ВВВВВВВВ" определяет реквизиты договора поставки товаров в розничные или оптовые торговые точки. Смысл реквизитов в принципе понятен.

Где задействованы: В принципе пишу "на память" и если, что-то полезное упустил спросите - отвечу! Как и везде в системе, если реквизит не ведётся, то программа его игноририрует. Например во всех перечистленных ниже задачах при отсутствии номера договора программа просто "пропускает" данного клиента в "анализе".

1. При просмотре справочника клентов (таблицы выбора клиента) в колонке "Д" таблицы при "просрочке" договора появится буква "К" (кончился)... если конечно определены реквизиты... здесь и везде расшифровку сокращений можно получить нажав комбинацию Shift+F2.

2. Через меню F2/включение-выключение выделения клиентов с ограничениями на отгрузку. В частности при просроченном договоре клиент будет "загашен".

3. В отчете "аналитика/редкие/список клиентов с реквизитами... во всех "туева хуча" форматов" можно получить список по ограничению (будушем или прошлым периодом) на "окончание срока договора". Например - список клиентов с фактическими адресами и телефонами по агенту "пупкину" срок договоров с которыми заканчивает в следующем месяце.

4. При включении атрибута "настройки программы" - "отражать реквизиты договора в накладных" и конечно наличия заполненного реквизита "номер договора"... При печати накладной любого типа (их более 10 форматов) в основании документа автоматически будет добавляться фраза "согласно договору № ХХХХХ от УУУУУУУУ".

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

Где задействованы: В принципе пишу "на память" и если, что-то полезное упустил спросите - отвечу! Как и везде в системе, если реквизит не ведётся, то программа его игноририрует. Например во всех перечистленных ниже задачах при отсутствии номера договора программа просто "пропускает" данного клиента в "анализе".


А что если ставить номера договоров такие же что и код клиента ? накладок или сбоев не возникнет ?

Общение самому с собой когда-нибудь плохо закончится :)

Конечно нет - можно использовать любые знаки....

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

1. В отгрузочных накладных ссылка на договор дополняется в основание
2. Можно запретить (настройка) отпуск при просрочке срока договора
3. В "аналитика/редкие/список клиентов с реквизитами" можно выявить клиентов с просроченными договорами

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

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