█ 14.06.2013 14:36
Добрый день!
Сегодня "загрузили" занятной задачкой, как всегда которую нужно было сделать "вчера" и "очень надо"! Скажу сразу она решилась, но вспомнил, что иногда такого рода "сюрпризы" возникают, как правило "разрешаются", но они весьма занятны с точки зрения разрешимости потенциальных вопросов малого бизнеса в "УС Land" без модификации кода программы.
Поискал куда "воткнуть" сообщения - некуда... и решил завести новую тему куда буду "складировать" методики решения данного рода задачек.
Задача I. Фирма "А" поставила физически товар фирме "Б" и предоставила сопроводительную документацию от фирмы "А" на фирму "П", предполагая, что фирма "П" по документам отгрузит весь данный товар фирме "Б" :connie_eatfishy:
Всё ещё "ничего", но часть описания товара, например штрихкод берётся непосредственно с этикеток товаров и спецификации, которую отдади фирме "Б"... Фирмы "Б" и "П" пользователи "УС Land"... таскать документы и товар "не вариант" - около 600 наименований и (или) "камаз", да и территориально слишком удалены.
"Дело сделали", а потом мне поставили задачу: выкручивайся! - ЛЕГКО!
1. Фирма "Б" вводит товар, как приход от поставщика - фирмы "П", заполняя все атрибуты товара с этикеток и сопроводительной спецификации.
2. Оприходует товар на склад, параллельно делая "отгрузку" на фирму "П" - операция: распределение накладной и автосоздание отгрузки.
3. По отгрузочной накладной делает электронную посылку на фирму "П", содержащую все атрибуты товаров, цены и количества.
4. Удаляется данная "липовая" отгрузка в базе фирмы "Б".
5. В фирме "П" автоматически приходуется данная электронная посылка, как бы пришедшая от поставщика "А".
6. В "П" оприходывается данная накладная и автоматически делается отгрузка уже на фирму "Б"... Печатается документ и оформляется вся необходимая первичка.
Сегодня "загрузили" занятной задачкой, как всегда которую нужно было сделать "вчера" и "очень надо"! Скажу сразу она решилась, но вспомнил, что иногда такого рода "сюрпризы" возникают, как правило "разрешаются", но они весьма занятны с точки зрения разрешимости потенциальных вопросов малого бизнеса в "УС Land" без модификации кода программы.
Поискал куда "воткнуть" сообщения - некуда... и решил завести новую тему куда буду "складировать" методики решения данного рода задачек.
Задача I. Фирма "А" поставила физически товар фирме "Б" и предоставила сопроводительную документацию от фирмы "А" на фирму "П", предполагая, что фирма "П" по документам отгрузит весь данный товар фирме "Б" :connie_eatfishy:
Всё ещё "ничего", но часть описания товара, например штрихкод берётся непосредственно с этикеток товаров и спецификации, которую отдади фирме "Б"... Фирмы "Б" и "П" пользователи "УС Land"... таскать документы и товар "не вариант" - около 600 наименований и (или) "камаз", да и территориально слишком удалены.
"Дело сделали", а потом мне поставили задачу: выкручивайся! - ЛЕГКО!
1. Фирма "Б" вводит товар, как приход от поставщика - фирмы "П", заполняя все атрибуты товара с этикеток и сопроводительной спецификации.
2. Оприходует товар на склад, параллельно делая "отгрузку" на фирму "П" - операция: распределение накладной и автосоздание отгрузки.
3. По отгрузочной накладной делает электронную посылку на фирму "П", содержащую все атрибуты товаров, цены и количества.
4. Удаляется данная "липовая" отгрузка в базе фирмы "Б".
5. В фирме "П" автоматически приходуется данная электронная посылка, как бы пришедшая от поставщика "А".
6. В "П" оприходывается данная накладная и автоматически делается отгрузка уже на фирму "Б"... Печатается документ и оформляется вся необходимая первичка.
█ 16.06.2013 14:34
Доброго дня!
Вспомнилась ещё одна, правда не совсем "свежая" "неожиданность" - учет УСЛУГ. В принципе в системе "УС Land" нет такого объекта - УСЛУГА и как следствие нет контролируемых механизмов его ведения, а так же ведения первичной документации по сопровождению данного объекта в хозяйственном документообороте. Услуга может быть, как оказываемая нами, так и оказываемая нам.
"Раньше" просто учитывались платежи по услугам относя их к неким статьям "расходов", т.е. данный объект был доступен для анализа. Но это неудобно: нет ведения счетов фактур по ним, невозможно реально контролировать услуги, оказываемые по предоплате, нет возможности построения бухгалтерской отчетности, в частности по расчетам НДС... пока ряд пользователей не "изобрел" полностью "корректный" механизм их учета. Затем мной этот механизм "вылизался" и был "описан":
Услуга, как товар. Услуги нам вводим, как поступление товаров на склад, например услуг, а наши услуги приходуем, например по инвентаризации, а затем продаём. Расмотрим учет услуг "для нас":
1. Приходуем данный товар, в карточке: поставщик (реальный для услуги), единица измерения штука, раздел прайса "услуги", цены закупа и продажи 1 рубль. Количество единиц равно сумме услуги.
2. Через F2 распределяем на склад "услуг" и сразу списываем на затраты статьи "услуги" (операция списания товаров делается автоматически).
3. Счета фактуры привязываем к приходной накладной, а с финансами работаем, как по обычным поставщикам.
Так как "услуга - товар", то их можно перепродавать, инвентаризировать, пускать в "производство" и соответственно "по разному" анализировать.
Вспомнилась ещё одна, правда не совсем "свежая" "неожиданность" - учет УСЛУГ. В принципе в системе "УС Land" нет такого объекта - УСЛУГА и как следствие нет контролируемых механизмов его ведения, а так же ведения первичной документации по сопровождению данного объекта в хозяйственном документообороте. Услуга может быть, как оказываемая нами, так и оказываемая нам.
"Раньше" просто учитывались платежи по услугам относя их к неким статьям "расходов", т.е. данный объект был доступен для анализа. Но это неудобно: нет ведения счетов фактур по ним, невозможно реально контролировать услуги, оказываемые по предоплате, нет возможности построения бухгалтерской отчетности, в частности по расчетам НДС... пока ряд пользователей не "изобрел" полностью "корректный" механизм их учета. Затем мной этот механизм "вылизался" и был "описан":
Услуга, как товар. Услуги нам вводим, как поступление товаров на склад, например услуг, а наши услуги приходуем, например по инвентаризации, а затем продаём. Расмотрим учет услуг "для нас":
1. Приходуем данный товар, в карточке: поставщик (реальный для услуги), единица измерения штука, раздел прайса "услуги", цены закупа и продажи 1 рубль. Количество единиц равно сумме услуги.
2. Через F2 распределяем на склад "услуг" и сразу списываем на затраты статьи "услуги" (операция списания товаров делается автоматически).
3. Счета фактуры привязываем к приходной накладной, а с финансами работаем, как по обычным поставщикам.
Так как "услуга - товар", то их можно перепродавать, инвентаризировать, пускать в "производство" и соответственно "по разному" анализировать.
█ 07.12.2013 11:24
Мне почему-то казалось, что это самоочевидные элементарные вещи в любой програмуле для розницы, но ещё страннее, что их сейчас нужно отдельно "выделять" в рекламных сообщениях... Ну и ладно: данный нюанс где-то 3% возможностей програмки "Ценников" и извините скопипастю сообщение других разработчиков.
Программа ценников, в том числе предназначена для создания и отпечатывания этикеток со штрих-кодом, работающая как на стандартных лазерных и струйных принтерах, так и на специализированных термопринтерах этикеток, такие как Datecs EP-50, Datecs LP-50, Zebra и другие. Программа может работать самостоятельно, а также как расширение стандартное графическое расширение УС Лэнд.
УС Лэнд поддерживает стандарты штрихкодов ЕАN13. В программу ценников включено много шаблонов для этикеток. Также предусмотрена возможность печати этикеток товаров данного документа (приход, продажа, заказ и т.д.), товаров данной группы или товаров, отвечающих данному фильтру по имени или по коду. На этикетке можно расположить различные атрибуты товаров, например, имя, цена, учетный номер, штрих-код, единица измерения и др. Можно также расположить произвольный текст или изображение (например фирменный знак), встроенные в программе стандартные знаки для маркировки как СЕ, Со, символы для переработки, транспортировки и др.
УС Land позволяет, как печатать только этикетки с Bar кодами на всю партию товаров (на каждый товар по его количеству), так и настраиваемые ценники, где дополнительно отражается штрих код.
Программа может формировать и печатать локальные ШК, на товары не имеющие данных реквизитов с четким соблюдением правил "контрольных сумм", т.е. ШК считываемые любыми сканерами и любой программой.
Программа ценников, в том числе предназначена для создания и отпечатывания этикеток со штрих-кодом, работающая как на стандартных лазерных и струйных принтерах, так и на специализированных термопринтерах этикеток, такие как Datecs EP-50, Datecs LP-50, Zebra и другие. Программа может работать самостоятельно, а также как расширение стандартное графическое расширение УС Лэнд.
УС Лэнд поддерживает стандарты штрихкодов ЕАN13. В программу ценников включено много шаблонов для этикеток. Также предусмотрена возможность печати этикеток товаров данного документа (приход, продажа, заказ и т.д.), товаров данной группы или товаров, отвечающих данному фильтру по имени или по коду. На этикетке можно расположить различные атрибуты товаров, например, имя, цена, учетный номер, штрих-код, единица измерения и др. Можно также расположить произвольный текст или изображение (например фирменный знак), встроенные в программе стандартные знаки для маркировки как СЕ, Со, символы для переработки, транспортировки и др.
УС Land позволяет, как печатать только этикетки с Bar кодами на всю партию товаров (на каждый товар по его количеству), так и настраиваемые ценники, где дополнительно отражается штрих код.
Программа может формировать и печатать локальные ШК, на товары не имеющие данных реквизитов с четким соблюдением правил "контрольных сумм", т.е. ШК считываемые любыми сканерами и любой программой.
█ 29.09.2014 19:20
Интеграция с продуктами на "1С" или переход с УС Лэнд на "1С"
Что же и такое бывает... В УС Land встроена подсистема и есть описание технологии выгрузки первичной документации любого типа и описание выгрузок долгов и остатков в сторонние программы, но было только различные программы на платформе от ЗАО "1С".
Когда возникала необходимость:
1. Перенос проводимых документов в 1С:Бухгалтерию;
2. Выгрузка документов в различные конфы в случаях когда руководители удачно обманутые продажниками от "1С" полагали, что им удобнее некоторые процедуры, например интеграцию с EDI делать через обещанные бесплатные механизмы в "1С". Уже лет 10, как начинают, доходят до "моих запросов" и отказываются от 1С:обманщиков;
3. Фирма заканчивает работу с УС Лэнд и переходит на поделки от ЗАО 1С. Было 2 случая поглощения фирм, использующих УС более крупными предприятиями работающих на "1С".
.... в среду должен узнать, какой из случаев случиться, а посему вспомнил о возможностях системы ....
В программе администратор/бухгалтерия/экспорт документов L в 1С бухгалтерия. Вызываем режим и заполняем форму:
В головном каталоге программы появляется файл формата dBaseIII (866) - один из форматов хорошо воспринимаемых 1С:платформой с некоторыми обязательными атрибутами документов и товаров. В интернете полно внешних обработок импортирующие данные файлы или заказывают программу 1с:программистам для "индивидуальной" обработке - примитивная задачка - при мне девочка её слепила для приходов за 40 минут.
Ниже приложена инструкция по импорту долгов и остатков, а так же подробное описание файла экспорта для документов различных типов.
Что же и такое бывает... В УС Land встроена подсистема и есть описание технологии выгрузки первичной документации любого типа и описание выгрузок долгов и остатков в сторонние программы, но было только различные программы на платформе от ЗАО "1С".
Когда возникала необходимость:
1. Перенос проводимых документов в 1С:Бухгалтерию;
2. Выгрузка документов в различные конфы в случаях когда руководители удачно обманутые продажниками от "1С" полагали, что им удобнее некоторые процедуры, например интеграцию с EDI делать через обещанные бесплатные механизмы в "1С". Уже лет 10, как начинают, доходят до "моих запросов" и отказываются от 1С:обманщиков;
3. Фирма заканчивает работу с УС Лэнд и переходит на поделки от ЗАО 1С. Было 2 случая поглощения фирм, использующих УС более крупными предприятиями работающих на "1С".
.... в среду должен узнать, какой из случаев случиться, а посему вспомнил о возможностях системы ....
В программе администратор/бухгалтерия/экспорт документов L в 1С бухгалтерия. Вызываем режим и заполняем форму:
В головном каталоге программы появляется файл формата dBaseIII (866) - один из форматов хорошо воспринимаемых 1С:платформой с некоторыми обязательными атрибутами документов и товаров. В интернете полно внешних обработок импортирующие данные файлы или заказывают программу 1с:программистам для "индивидуальной" обработке - примитивная задачка - при мне девочка её слепила для приходов за 40 минут.
Ниже приложена инструкция по импорту долгов и остатков, а так же подробное описание файла экспорта для документов различных типов.
█ 03.10.2014 09:29
Был! Обсуждали вопросы - выгрузка первички в 1С:Бухгалтерия. Пришли ко мнению, что автоматизируя бардак, в частности в бухгалтерии кроме автоматизированного бардака ничего не получим, но будут пробовать... Первичный созвон с франчами по цене вопроса (итого) от 80 тыр - будут думать! Главное, что УС Лэнд предоставляет всю необходимую одноэсникам информацию в необходимом формате и требуемым уровнем полноты 
█ 25.02.2015 15:29
М....дааа... Только, что почитал статью по гипервозможностям 1-ц... на самом деле знал о данной недоработке "платформы 1с" ещё десять лет назад, но не думал, что эта фигня до сих пор нереализуема 
Как в УТ 10.3 установить общую сумму скидки по счету, выраженную в рублях (не в процентах)?
Задача. Компания проводит акцию, в рамках которой каждому покупателю дается скидка в размере 1000 рублей к сумме каждого счета. Можно ли решить данную задачу и какими средствами?
Первое, что приходит в голову клиентам, обычно, – завести товар «Скидка» и выбивать его в счете с отрицательной ценой равной 1000 рублей. Но этот план не осуществим, т.к. ввод товаров с отрицательной ценой запрещен разработчиками. С точки зрения здравого смысла, это абсолютно оправдано, т.к. считать НДС товара с отрицательной ценой является абсурдом, и потом, кто будет оприходовать на склад товар «Скидка», по какой цене и у кого его покупать, и зачем он вообще нам нужен на складе? Но что же делать обычному пользователю в этой ситуации?
Вариант решения 1. Вычесть 1000 рублей из стоимости какого-то товара в счете.
Например, в счете есть товар «Телевизор» в количестве 1 шт. и ценой 30 000 рублей. Мы вручную уменьшаем цену до 29 000 рублей и, таким образом, покупатель получает скидку.
Минусы этого способа очевидны:
Ручное изменение цены.
Покупатель не видит в счете, что ему сделали скидку. Даже если у нас, на самом деле, телевизор стоит 30 000 рублей, то покупатель может посчитать уменьшение цены фикцией.
В счете может не оказаться товара стоимостью более 1000 рублей. При этом общая сумма счета вполне может быть больше.
Не всегда возможно вычесть 1000 рублей без погрешности в округлении цены товара. Например, если мы продаем 3 телевизора по цене 10 000 рублей каждый, то их общая стоимость составляет 30 000 рублей. Чтобы получить новую цену одного телевизора надо вычислить: (30 000 – 1000) / 3 = 9 666,67 результат округлен до двух знаков. Проблема возникает, когда мы подставляем новую цену в программу и получаем общую стоимость товаров = 3 * 9 666,67 = 29 000, 01 рубль. Таким образом, мы предоставили покупателю скидку не 1000 рублей, как обещали, а 999 рублей и 99 копеек.
В некоторых случаях погрешности в округлении могут быть гораздо больше!
Вариант решения 2. Этот вариант уже чуть более продвинут, чем вариант 1, но имеет с ним общий недостаток.
В этом варианте нам нужно нажать кнопку «Изменить», находящуюся в панели действий над табличной частью документа, где мы подбираем товары и услуги.
После описанных действий, все цены в документе пересчитаются таким образом, чтобы общая сумма документа уменьшилась на 1000 рублей.
При этом никаких погрешностей не будет, а цены товара изменятся пропорционально суммам автоматически.
Минус этого способа в том, что клиент также не увидит в счете величины данной ему скидки.
Так можно ли сделать так, чтобы клиент увидел скидку в счете?
Теоретически можно. Для этого в конфигурации «Управление торговлей» ред. 10.3 существует механизм ручных и автоматических скидок.
Практически же, проблема заключается в том, что:
Величина скидки задается в процентном отношении.
Скидка дается не на счет в целом, а на каждую позицию товара.
Таким образом, чтобы воспользоваться данным механизмом под нашу задачу, когда величина скидки выражена абсолютной величиной в 1000 рублей, у нас есть 2 варианта:
Взять товар из счета общей стоимостью более 1000 рублей, вычислить какую величину в процентах составит 1000 рублей от этой стоимости и ввести полученный процент в графу «Ручная скидка» напротив этого товара.
Вычислить процент можно следующим образом: 1000 / Стоимость товара * 100. Недостаток этого способа также таится в погрешности округления. Так, если стоимость нашего товара составляет 30 000 рублей, то величина процента составит 1000 / 30 000 * 100 = 3,33. Если мы введем это значение в графу «Ручная скидка», то получим сумму товара с учетом скидки равную 29 001,00 рублей, что также является для нас не приемлемым.
Второй вариант – это попробовать распределить скидку по всем товарам равномерно, выразив ее в процентах от каждой позиции. Данный вариант, в связи со сложностью вычислений и большой вероятности погрешностей и обилием ручной работы, даже не будем рассматривать. При оформлении счетов с большим объемом различной номенклатуры он вообще не приемлем.
Как видно из приведенных примеров, каждый из вариантов содержит свои недостатки и, в полной мере, не может считаться автоматизируемым хотя бы на «удовлетворительно».
Автоматизировать ввод фиксированной скидки в абсолютном выражении можно, сделав некоторые доработки в вашей конфигурации. Запрос на данный вид работ можно сделать по телефону, электронной почте или через форму обратной связи на нашем сайте.
----------------------------------------------------------
Ссылку на эту крайне полезную (огромное число спасибок за неё) для пользователей продукции ЗАО "1С" не привожу, т.к. она на стороннем форуме, но обращу внимание и на последний выделенный фрагмент - непроработанность стандартных конфигураций вынуждает обычных пользователей обращаться к изменению стандартных конф и как следствие переводить своё чудо приобретение в обычную самописку, которая уже не может быть обновлена "дешевыми" 1С:"программистами".
Почему привел статью?
Во первых она полезна для 80% всех бизнесменов и бухгалтеров, использующих продукцию ЗАО "1С".
Во вторых уже очень давно считаю это самоочевидным моментом, который должен быть доступен при оформлении товароучетных документов, например уже 18 лет в системе "УС Лэнд" для любых товарных режимов (документов) при их создании программа спрашивает:
Какой вид (суммовой или процентный) вид скидки/наценки желает иметь пользователь. Это настолько очевидно, что мной никогда и не упоминается, а "для мышей любящих кушать кактус" приведена в начале статья, которая им поможет "меньше колоться".
З.Ы. Извините за упоминание уже набившей оскомину поговорки про пользователей "1С" - мыши рыдали, кололись, ругались, но продолжали кушать кактус... приятного аппетита!
Как в УТ 10.3 установить общую сумму скидки по счету, выраженную в рублях (не в процентах)?
Задача. Компания проводит акцию, в рамках которой каждому покупателю дается скидка в размере 1000 рублей к сумме каждого счета. Можно ли решить данную задачу и какими средствами?
Первое, что приходит в голову клиентам, обычно, – завести товар «Скидка» и выбивать его в счете с отрицательной ценой равной 1000 рублей. Но этот план не осуществим, т.к. ввод товаров с отрицательной ценой запрещен разработчиками. С точки зрения здравого смысла, это абсолютно оправдано, т.к. считать НДС товара с отрицательной ценой является абсурдом, и потом, кто будет оприходовать на склад товар «Скидка», по какой цене и у кого его покупать, и зачем он вообще нам нужен на складе? Но что же делать обычному пользователю в этой ситуации?
Вариант решения 1. Вычесть 1000 рублей из стоимости какого-то товара в счете.
Например, в счете есть товар «Телевизор» в количестве 1 шт. и ценой 30 000 рублей. Мы вручную уменьшаем цену до 29 000 рублей и, таким образом, покупатель получает скидку.
Минусы этого способа очевидны:
Ручное изменение цены.
Покупатель не видит в счете, что ему сделали скидку. Даже если у нас, на самом деле, телевизор стоит 30 000 рублей, то покупатель может посчитать уменьшение цены фикцией.
В счете может не оказаться товара стоимостью более 1000 рублей. При этом общая сумма счета вполне может быть больше.
Не всегда возможно вычесть 1000 рублей без погрешности в округлении цены товара. Например, если мы продаем 3 телевизора по цене 10 000 рублей каждый, то их общая стоимость составляет 30 000 рублей. Чтобы получить новую цену одного телевизора надо вычислить: (30 000 – 1000) / 3 = 9 666,67 результат округлен до двух знаков. Проблема возникает, когда мы подставляем новую цену в программу и получаем общую стоимость товаров = 3 * 9 666,67 = 29 000, 01 рубль. Таким образом, мы предоставили покупателю скидку не 1000 рублей, как обещали, а 999 рублей и 99 копеек.
В некоторых случаях погрешности в округлении могут быть гораздо больше!
Вариант решения 2. Этот вариант уже чуть более продвинут, чем вариант 1, но имеет с ним общий недостаток.
В этом варианте нам нужно нажать кнопку «Изменить», находящуюся в панели действий над табличной частью документа, где мы подбираем товары и услуги.
После описанных действий, все цены в документе пересчитаются таким образом, чтобы общая сумма документа уменьшилась на 1000 рублей.
При этом никаких погрешностей не будет, а цены товара изменятся пропорционально суммам автоматически.
Минус этого способа в том, что клиент также не увидит в счете величины данной ему скидки.
Так можно ли сделать так, чтобы клиент увидел скидку в счете?
Теоретически можно. Для этого в конфигурации «Управление торговлей» ред. 10.3 существует механизм ручных и автоматических скидок.
Практически же, проблема заключается в том, что:
Величина скидки задается в процентном отношении.
Скидка дается не на счет в целом, а на каждую позицию товара.
Таким образом, чтобы воспользоваться данным механизмом под нашу задачу, когда величина скидки выражена абсолютной величиной в 1000 рублей, у нас есть 2 варианта:
Взять товар из счета общей стоимостью более 1000 рублей, вычислить какую величину в процентах составит 1000 рублей от этой стоимости и ввести полученный процент в графу «Ручная скидка» напротив этого товара.
Вычислить процент можно следующим образом: 1000 / Стоимость товара * 100. Недостаток этого способа также таится в погрешности округления. Так, если стоимость нашего товара составляет 30 000 рублей, то величина процента составит 1000 / 30 000 * 100 = 3,33. Если мы введем это значение в графу «Ручная скидка», то получим сумму товара с учетом скидки равную 29 001,00 рублей, что также является для нас не приемлемым.
Второй вариант – это попробовать распределить скидку по всем товарам равномерно, выразив ее в процентах от каждой позиции. Данный вариант, в связи со сложностью вычислений и большой вероятности погрешностей и обилием ручной работы, даже не будем рассматривать. При оформлении счетов с большим объемом различной номенклатуры он вообще не приемлем.
Как видно из приведенных примеров, каждый из вариантов содержит свои недостатки и, в полной мере, не может считаться автоматизируемым хотя бы на «удовлетворительно».
Автоматизировать ввод фиксированной скидки в абсолютном выражении можно, сделав некоторые доработки в вашей конфигурации. Запрос на данный вид работ можно сделать по телефону, электронной почте или через форму обратной связи на нашем сайте.
----------------------------------------------------------
Ссылку на эту крайне полезную (огромное число спасибок за неё) для пользователей продукции ЗАО "1С" не привожу, т.к. она на стороннем форуме, но обращу внимание и на последний выделенный фрагмент - непроработанность стандартных конфигураций вынуждает обычных пользователей обращаться к изменению стандартных конф и как следствие переводить своё чудо приобретение в обычную самописку, которая уже не может быть обновлена "дешевыми" 1С:"программистами".
Почему привел статью?
Во первых она полезна для 80% всех бизнесменов и бухгалтеров, использующих продукцию ЗАО "1С".
Во вторых уже очень давно считаю это самоочевидным моментом, который должен быть доступен при оформлении товароучетных документов, например уже 18 лет в системе "УС Лэнд" для любых товарных режимов (документов) при их создании программа спрашивает:
Какой вид (суммовой или процентный) вид скидки/наценки желает иметь пользователь. Это настолько очевидно, что мной никогда и не упоминается, а "для мышей любящих кушать кактус" приведена в начале статья, которая им поможет "меньше колоться".
З.Ы. Извините за упоминание уже набившей оскомину поговорки про пользователей "1С" - мыши рыдали, кололись, ругались, но продолжали кушать кактус... приятного аппетита!
█ 13.11.2015 11:50
Вчера наконец решил и описал для персонала решение задачки:
Живет и развивается фирма, но когда-то "некто" придумал, что нужно перевести бизнес на другое юридическое лицо и убедил в этом хозяина - была оформлена и открыта новая контора. Об этом знал, т.к. нужно было создать БД и наладить процессы передачи информации... было это 3-4 месяца назад.
Как вдруг и "ещё вчера" нужно было начать отгрузки с новой конторы, но товар перемещать по необходимости со старой... Всё бы ничего - "плавали-знаем", но эта обычная задача усложнена рядом моментов:
1. Довольно большим количеством документов - примерно 400-900 отгрузок в сутки;
2. Максимально оптимизированным процессом. (1.) делается 2 операторами-кассирами;
3. Кучей автопроцедур, работающих вообще без участия персонала обмена с бухгалтерий (1С:Бух) и рядом поставщиков по EDI;
4. Кучка бизнес технологий типа электронной сертификации;
5. Небольшой (12-30) толпой торговиков и etc... и вся эта (две, а возможно более фирм) бизнес конструкция должна работать параллельно от 2 до 6 месяцев
О том, как мне "делали нервы" или тупили все лица, управляющие процессом торговли промолчу, но мне надо было разрешить эту задачу. Сам не сообразил, но в истерике один из персонажей ляпнул - "шло бы всё, да ведите всё в одной базе" (о возможности создания и печати документов от лица разных фирм и в разных ценах "товарищ" знал ) ... и это натолкнуло на решение!
Всё элементарно:
1. Для документов одной фирмы ставим признак - проводится, а для другой убираем его;
2. Для документов нужных бухгалтерии ставим номера документов, а ненужных убираем...
и тогда, как выяснил, потому-что забыл все автоматы, разделение информации для всех имеют возможность регулироваться данными реквизитами всех документов... и это не затрагивает ни одного из "роботов". Единственно небольшой гемор для бухов - вводить 1 приходный и 1 расходный документ по данным о продажах от лица новой фирмы в месяц... что впрочем тоже вызвало недовольство... хорошо хоть премию пообещали за это решение - ждём`с
Живет и развивается фирма, но когда-то "некто" придумал, что нужно перевести бизнес на другое юридическое лицо и убедил в этом хозяина - была оформлена и открыта новая контора. Об этом знал, т.к. нужно было создать БД и наладить процессы передачи информации... было это 3-4 месяца назад.
Как вдруг и "ещё вчера" нужно было начать отгрузки с новой конторы, но товар перемещать по необходимости со старой... Всё бы ничего - "плавали-знаем", но эта обычная задача усложнена рядом моментов:
1. Довольно большим количеством документов - примерно 400-900 отгрузок в сутки;
2. Максимально оптимизированным процессом. (1.) делается 2 операторами-кассирами;
3. Кучей автопроцедур, работающих вообще без участия персонала обмена с бухгалтерий (1С:Бух) и рядом поставщиков по EDI;
4. Кучка бизнес технологий типа электронной сертификации;
5. Небольшой (12-30) толпой торговиков и etc... и вся эта (две, а возможно более фирм) бизнес конструкция должна работать параллельно от 2 до 6 месяцев
О том, как мне "делали нервы" или тупили все лица, управляющие процессом торговли промолчу, но мне надо было разрешить эту задачу. Сам не сообразил, но в истерике один из персонажей ляпнул - "шло бы всё, да ведите всё в одной базе" (о возможности создания и печати документов от лица разных фирм и в разных ценах "товарищ" знал ) ... и это натолкнуло на решение!
Всё элементарно:
1. Для документов одной фирмы ставим признак - проводится, а для другой убираем его;
2. Для документов нужных бухгалтерии ставим номера документов, а ненужных убираем...
и тогда, как выяснил, потому-что забыл все автоматы, разделение информации для всех имеют возможность регулироваться данными реквизитами всех документов... и это не затрагивает ни одного из "роботов". Единственно небольшой гемор для бухов - вводить 1 приходный и 1 расходный документ по данным о продажах от лица новой фирмы в месяц... что впрочем тоже вызвало недовольство... хорошо хоть премию пообещали за это решение - ждём`с
█ 08.02.2019 12:08
Вчера… Продавец ошибается со сканированием бутылки и "УСЕга" его предупреждает, так совпало, что попытка продажи через МРЦ - версию поставил, но новшества толком не объяснил...
Объяснил о внедрении контроля, поиска, анализа по МРЦ и МОЦ в "УС Лэнд:ЕГАИС", о новых "ценах" с 01.01.2019: https://olegon.ru/showthread.php?t=31065 и сходу получил "детский" вопрос - а почему в "УС Land" этого нет?
Формально:
1. Ни когда и не ставилась сия задача;
2. Нет дешевого алкоголя;
3. "УС Land" не является кассовой программой;
4. Да и вообще, как-то вопрос стал неожиданным.
Подумав, что хотя-бы в плане переоценок, контроля цен при создании продаж, поверхностного анализа, благо техника для "УСЕга" уже создана... Нужно, что-то по данному вопросу внести в систему?
На сей момент пока сделано, а по остальным "нужностям" буду думать:
1. Функции для работы с МРЦ и МОЦ перенесены в общую библиотеку систем "УС Лэнд". Соответственно переписал "УСЕга" и включил закачку данных в "УС Land";
2. Переписал общие модули, что-бы они стали более "защищенными" и универсальными для любых программ "УС Лэнд";
3. При просмотре справочников товаров, в том числе склада добавил отражение МРЦ.
!!! Если файла Schema.mc не будет в каталогах программ, то это отключает данную технологию во всех режимах, всех программ.
P.S. Вот теперь нужно думать, где эту технику внедрить в программу, что-бы она не "раздражала" основных пользователей "УС Land" - производство и оптовая торговля?
Объяснил о внедрении контроля, поиска, анализа по МРЦ и МОЦ в "УС Лэнд:ЕГАИС", о новых "ценах" с 01.01.2019: https://olegon.ru/showthread.php?t=31065 и сходу получил "детский" вопрос - а почему в "УС Land" этого нет?
Формально:
1. Ни когда и не ставилась сия задача;
2. Нет дешевого алкоголя;
3. "УС Land" не является кассовой программой;
4. Да и вообще, как-то вопрос стал неожиданным.
Подумав, что хотя-бы в плане переоценок, контроля цен при создании продаж, поверхностного анализа, благо техника для "УСЕга" уже создана... Нужно, что-то по данному вопросу внести в систему?
На сей момент пока сделано, а по остальным "нужностям" буду думать:
1. Функции для работы с МРЦ и МОЦ перенесены в общую библиотеку систем "УС Лэнд". Соответственно переписал "УСЕга" и включил закачку данных в "УС Land";
2. Переписал общие модули, что-бы они стали более "защищенными" и универсальными для любых программ "УС Лэнд";
3. При просмотре справочников товаров, в том числе склада добавил отражение МРЦ.
!!! Если файла Schema.mc не будет в каталогах программ, то это отключает данную технологию во всех режимах, всех программ.
P.S. Вот теперь нужно думать, где эту технику внедрить в программу, что-бы она не "раздражала" основных пользователей "УС Land" - производство и оптовая торговля?
█ 11.05.2019 17:39
Сегодня пришлось прервать майские праздники, проводимые с лопатой и топором в руке для решения, как обычно "срочной" и "неожиданной" задачи. Конечно, сама по себе - это моя "внутренняя", мало кому интересная проблемка, однако решил поделиться ей в силу её "многогранности":
Есть жестко стандартизированная система система EDI (ЭДО) в которой поставщики обмениваются электронными документами с покупателями, где я "потихоньку" ковыряюсь. Есть программа вне комплекса "УС Land", закачивающая заявки в план производства, которую, как сегодня увидел сделал в 2016 году и больше не дорабатывал. Как оказалось с момента её создания через неё подключилось уже пяток торговых сетей - инструкция есть, "настройка" новых подключений элементарна, проблем у диспетчеров не возникало....
Каждый объект EDI имеет уникальный в международном масштабе идентификатор: контрагента и их магазины GLN, товары GTIN... и тут 08.05 всплыла "загадка"
В одной очень крупной сетке кто-то перепутал GTINы по разным товарам, в частности по одному (А) относится к другому (Б). (А) и (Б) есть в БД кодов, а посему документы проводятся через провайдеров. Однако ВСЕ сети присылают заказы с правильным (Б), а "эта" с (А)... и менять его у себя на правильный (Б) так же отказываются по причине, что (Б) у них так же ошибочно внесен в БД для другого товара.
Конечно и здесь "УС Land" не "сломалась" - просто дамы перед закачкой той сети "подсовывали" программе GTIN (А). Сегодня (успешно) придумывал и реализовывал универсальный механизм обработки таких косяков "великих" сетей, исключающий "человеческий фактор" при работе системы с ошибочными данными в БД международного документооборота.
Суть решения, ежели интересно: ввел внешний файл содержащий правило подсовывания кривых GTIN для конкретных (GLN) контрагентов и заменяющий их неправильные GTIN на правильные в процессе обработки заказов... Это набор строк:
GLN клиента, GTIN у него, GTIN правильный
Так же обрабатывается ситуация, если вдруг они (сеть) всё таки поменяют свои кривые GTIN на стандартные, что, в принципе "обещают" в течении нескольких месяцев
Есть жестко стандартизированная система система EDI (ЭДО) в которой поставщики обмениваются электронными документами с покупателями, где я "потихоньку" ковыряюсь. Есть программа вне комплекса "УС Land", закачивающая заявки в план производства, которую, как сегодня увидел сделал в 2016 году и больше не дорабатывал. Как оказалось с момента её создания через неё подключилось уже пяток торговых сетей - инструкция есть, "настройка" новых подключений элементарна, проблем у диспетчеров не возникало....
Каждый объект EDI имеет уникальный в международном масштабе идентификатор: контрагента и их магазины GLN, товары GTIN... и тут 08.05 всплыла "загадка"
В одной очень крупной сетке кто-то перепутал GTINы по разным товарам, в частности по одному (А) относится к другому (Б). (А) и (Б) есть в БД кодов, а посему документы проводятся через провайдеров. Однако ВСЕ сети присылают заказы с правильным (Б), а "эта" с (А)... и менять его у себя на правильный (Б) так же отказываются по причине, что (Б) у них так же ошибочно внесен в БД для другого товара.
Конечно и здесь "УС Land" не "сломалась" - просто дамы перед закачкой той сети "подсовывали" программе GTIN (А). Сегодня (успешно) придумывал и реализовывал универсальный механизм обработки таких косяков "великих" сетей, исключающий "человеческий фактор" при работе системы с ошибочными данными в БД международного документооборота.
Суть решения, ежели интересно: ввел внешний файл содержащий правило подсовывания кривых GTIN для конкретных (GLN) контрагентов и заменяющий их неправильные GTIN на правильные в процессе обработки заказов... Это набор строк:
GLN клиента, GTIN у него, GTIN правильный
Так же обрабатывается ситуация, если вдруг они (сеть) всё таки поменяют свои кривые GTIN на стандартные, что, в принципе "обещают" в течении нескольких месяцев
█ 07.04.2020 16:11
Происходящее сейчас иначе, как нервным бардаком назвать не могу 
Карантин, уходы в неоплачиваемый отпуск персонала, непонимание руководства бизнеса "камо грядеши", сдача отчетностей, фонтанирование абсолютно ненужными сей момент идеями и попытки, до кучи загрузить их "срочной" реализацией... так по всем фирмам, где как-то работаю... Неожиданно возникла одна из "срочных!!!" задач:
Для понимания. "Моя" фирма А выступает региональным партнером завода Б по сопутствующему низкорентабельному товару (5%-10% оборота), по поводу чего у них идут постоянные "тёрки". Клиенты, товары, деньги в общей куче (БД), но выделяем операции по товарам Б виртуальными метками. Постоянно делаются отчеты, выделяя деятельность по товарам Б (или без них)… Получаем, что товаром Б торгуют чуть ли не с убытками, что не нравится фирме Б... и основная их "предъява" - программа у А кривая и нужно им переходить на "1ц", тогда будет всё правильно и с огромной прибылью.
Сей момент всеобщего бардака они посчитали разумным, наконец у себя силами своих программистов в "1ц" вести учет по нашей "деревни"... и меня начали активно доставать ихние программисты - оказалось контур и данные выгрузки оборотов в "1С:Бухгалтерию" (описание технологии: https://olegon.ru/showpost.php?p=186962&postcount=4) их вполне устаивает, но в нём не выделялись "обороты по виртуальным объектам" (знакам из основания всех первичных документов)... Сегодня срочно доделал, установил версию по удалёнке… Будем ждать, что "у нас ещё считает неправильно"?
Карантин, уходы в неоплачиваемый отпуск персонала, непонимание руководства бизнеса "камо грядеши", сдача отчетностей, фонтанирование абсолютно ненужными сей момент идеями и попытки, до кучи загрузить их "срочной" реализацией... так по всем фирмам, где как-то работаю... Неожиданно возникла одна из "срочных!!!" задач:Для понимания. "Моя" фирма А выступает региональным партнером завода Б по сопутствующему низкорентабельному товару (5%-10% оборота), по поводу чего у них идут постоянные "тёрки". Клиенты, товары, деньги в общей куче (БД), но выделяем операции по товарам Б виртуальными метками. Постоянно делаются отчеты, выделяя деятельность по товарам Б (или без них)… Получаем, что товаром Б торгуют чуть ли не с убытками, что не нравится фирме Б... и основная их "предъява" - программа у А кривая и нужно им переходить на "1ц", тогда будет всё правильно и с огромной прибылью.
Сей момент всеобщего бардака они посчитали разумным, наконец у себя силами своих программистов в "1ц" вести учет по нашей "деревни"... и меня начали активно доставать ихние программисты - оказалось контур и данные выгрузки оборотов в "1С:Бухгалтерию" (описание технологии: https://olegon.ru/showpost.php?p=186962&postcount=4) их вполне устаивает, но в нём не выделялись "обороты по виртуальным объектам" (знакам из основания всех первичных документов)... Сегодня срочно доделал, установил версию по удалёнке… Будем ждать, что "у нас ещё считает неправильно"?
Часовой пояс GMT +3, время: 22:30.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.