Добрый день всем.
Есть ли у кого-то опыт внедрения программы УНФ 8.2. Есть ряд вопросов по реализации некоторых производственных процессов, ответы на которые не удалось найти на он-лайн демонстрации. Если кто-то хорошо знает принцип работы данной программы отзовитесь, я задам свои вопросы.
Спасибо, всем
Есть ли у кого-то опыт внедрения программы УНФ 8.2. Есть ряд вопросов по реализации некоторых производственных процессов, ответы на которые не удалось найти на он-лайн демонстрации. Если кто-то хорошо знает принцип работы данной программы отзовитесь, я задам свои вопросы.
Спасибо, всем
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(99) Убедили потратить время, посмотреть. Посмотрел. Ничего не изменилось в конфигурации. Оперативного учета валовой прибыли по FIFO как не было, так и нет. Есть только корректировка по итогам периода.
Может кто-то предложить реальную альтернативу текущему настроенному отчету, в котором в разрезе номенклатуры и документов выведены движения, остатки и цены партий, текущая маржа по каждому покупателю, документу. По этой "простыне", заказанной менеджерами, им удобно принимать решения как в переговорах с поставщиками, так и при торге с покупателями. На что бы ее заменить? Заменить менеджеров не предлагать :)
Кстати, кто копался, расчет корректировки по FIFO в конце месяца в УНФ проходит по упрощенной схеме (на остаток) или по полной (на каждое движение)?
Может кто-то предложить реальную альтернативу текущему настроенному отчету, в котором в разрезе номенклатуры и документов выведены движения, остатки и цены партий, текущая маржа по каждому покупателю, документу. По этой "простыне", заказанной менеджерами, им удобно принимать решения как в переговорах с поставщиками, так и при торге с покупателями. На что бы ее заменить? Заменить менеджеров не предлагать :)
Кстати, кто копался, расчет корректировки по FIFO в конце месяца в УНФ проходит по упрощенной схеме (на остаток) или по полной (на каждое движение)?
Та же хрень, что и в Beagle. У клиента низкомаржинальный товар (производство), и ему прям после каждого Производственного документа надо точно знать, сколько продукт на выходе стоит (ОПЗ почти нет, все затраты вводятся 1 раз в день на всю продукцию, выпущенную в этот день).
Чтобы не городить огород с полнеценным партионным учетом, думаю автоматически создавать партию товара (создавать элемент справочника Партии) при поступлении товара на склад, и автоматически заполнять свободную партию в расходных документах. Как еще можно сделать, чтобы потом можно было бы с горем пополам обновиться?
Чтобы не городить огород с полнеценным партионным учетом, думаю автоматически создавать партию товара (создавать элемент справочника Партии) при поступлении товара на склад, и автоматически заполнять свободную партию в расходных документах. Как еще можно сделать, чтобы потом можно было бы с горем пополам обновиться?
(101) svarog, У клиента позаказное производство. И партии ввели, чтобы не создавать дополнительные элементы в справочнике номенклатура. Партии добавил в "Заказ на производство". Заказ покупателя - Заказ на производство - Производство. Везде партии. До введения партии в "Заказ на производство" с обновлением все нормально.
Эх, классно, когда все делать через заказы. В УПП и УТ, чтобы красиво учитывать продажи, во всех доках обязательно указывать Заказ покупателя.
Здесь же производство идет на склад, и в течении недели продается клиентам или перерабатывается дальше.
Здесь же производство идет на склад, и в течении недели продается клиентам или перерабатывается дальше.
Добрый день.
Внедрял УНФ на фирме, которая занимается производством и продажи мебели. Производство как под заказ так и про запас.
До этого они работали в СКАТ.
Версия УНФ - 1.4.4.10.
Что пришлось дорабатывать:
1. Расчет потребностей производства - текущий функционал не позволял по многоуровневой спецификации нормально понять, что требуется закупить, произвести.
2. Не было блока коммерческих предложений - пришлось создать с нуля.
3. Не было нормально функционала по исполнению заказов покупателей - что из заказа нужно купить, что произвести.
4. Отчет переработчика не позволял за раз изготавливать сразу несколько позиций.
Что не понравилось:
1. Настройка прав
2. Отчеты - после обмена баз они все слетают из пункта "Отчеты" во всех подсистемах.
3. Обмен - не был нормально реализован, допиливал программист франчайзи.
4. не реализованы аналоги
Внедрял УНФ на фирме, которая занимается производством и продажи мебели. Производство как под заказ так и про запас.
До этого они работали в СКАТ.
Версия УНФ - 1.4.4.10.
Что пришлось дорабатывать:
1. Расчет потребностей производства - текущий функционал не позволял по многоуровневой спецификации нормально понять, что требуется закупить, произвести.
2. Не было блока коммерческих предложений - пришлось создать с нуля.
3. Не было нормально функционала по исполнению заказов покупателей - что из заказа нужно купить, что произвести.
4. Отчет переработчика не позволял за раз изготавливать сразу несколько позиций.
Что не понравилось:
1. Настройка прав
2. Отчеты - после обмена баз они все слетают из пункта "Отчеты" во всех подсистемах.
3. Обмен - не был нормально реализован, допиливал программист франчайзи.
4. не реализованы аналоги
Само внедрение - 10 тысяч, это был перенос остатков из другой базы.
Все остальное это уже было сопровождение текущего функционала, а точнее: сделать уменьшить время пользователей на оформления заказов, автоматизировать расчет производственных нужд, и новый функционал под специфику организации.
Все это вышло в несколько раз дороже внедрения
Все остальное это уже было сопровождение текущего функционала, а точнее: сделать уменьшить время пользователей на оформления заказов, автоматизировать расчет производственных нужд, и новый функционал под специфику организации.
Все это вышло в несколько раз дороже внедрения
Начал сейчас работать с УНФ
Странно. Почему сделали регистр ЦеныНоменклатуры без регистратора?
Каждую позицию заполнять ручками?
При поступлении в обработке вижу, что делает записи в регистр сведений Цены номенклатуры контрагентов если установлено регистрировать цены поставщика.
Не понятно потом из каких "побуждений" стоит та или иная цена.
Странно. Почему сделали регистр ЦеныНоменклатуры без регистратора?
Каждую позицию заполнять ручками?
При поступлении в обработке вижу, что делает записи в регистр сведений Цены номенклатуры контрагентов если установлено регистрировать цены поставщика.
Не понятно потом из каких "побуждений" стоит та или иная цена.
(111)Я видел обработку "Формирование цен". Действительно,"уменьшить ручной труд по заполнению цен". Но я имел ввиду то, что не видны причины(или алгоритмы), которые привели к тому или иному решению установки цен.
И еще.
Решили снять с торговых точек конфигурацию "Розница 2" и поставить на всех УНФ. Франчи сказали, что в УНФ торговля в розницу тоже реализована. Правда, они "забыли" сказать в какой степени функциональности там это реализовано. Продавцы в шоке. Там нет учета скидок по дисконтным картам и многое другое, что необходимо для розницы. Сейчас возвращаем все взад. Главбух в восторге. Она против УНФ и, вообще, хотела бы на все рабочие места поставить только БП и пусть народ вносит первичку в БП. Кроме нее она ничего не хочет видеть. На предприятии есть небольшое производство(заявки, заказы на производство и т.д.) и торговля, в том числе, розничная. Поэтому выбор пал на УНФ. Теперь вопрос по ситуации.
Кто-нибудь использовал для реализации функционала связку УНФ+БП? Как можно в этой связи отражать операции по рознице и прочим функциям, сопровождающих розницу? Насколько работоспособна будет конфигурация учета, если построить ее на УНФ+Розница+БП?
И еще.
Решили снять с торговых точек конфигурацию "Розница 2" и поставить на всех УНФ. Франчи сказали, что в УНФ торговля в розницу тоже реализована. Правда, они "забыли" сказать в какой степени функциональности там это реализовано. Продавцы в шоке. Там нет учета скидок по дисконтным картам и многое другое, что необходимо для розницы. Сейчас возвращаем все взад. Главбух в восторге. Она против УНФ и, вообще, хотела бы на все рабочие места поставить только БП и пусть народ вносит первичку в БП. Кроме нее она ничего не хочет видеть. На предприятии есть небольшое производство(заявки, заказы на производство и т.д.) и торговля, в том числе, розничная. Поэтому выбор пал на УНФ. Теперь вопрос по ситуации.
Кто-нибудь использовал для реализации функционала связку УНФ+БП? Как можно в этой связи отражать операции по рознице и прочим функциям, сопровождающих розницу? Насколько работоспособна будет конфигурация учета, если построить ее на УНФ+Розница+БП?
Сейчас смотрю версию УНФ 1.4.7.42
Обработка "Закупка товаров"
Выдает сообщение об ошибке
Ошибка инициализации модуля: Справочник.Контрагенты.МодульМенеджера
по причине:
{Справочник.Контрагенты.МодульМенеджера(182,20)}: Переменная не определена (ПрисоединенныеФайлы)
ДанныеКартинки = <<?>>ПрисоединенныеФайлы.ПолучитьДвоичныеДанныеФайла(ОрганизацияПоУмолчанию.ФайлЛоготип);
{Справочник.Контрагенты.МодульМенеджера(302,54)}: Переменная не определена (УправлениеПечатью)
СтруктураОбластей = ЗаполнитьСтрутуруОбластейМакета(<<?>>УправлениеПечатью.ПолучитьМакет("Справочник.Контрагенты.ПФ_MXL_ПрайсЛист"));
{Справочник.Контрагенты.МодульМенеджера(324,2)}: Переменная не определена (УправлениеПечатью)
<<?>>УправлениеПечатью.ЗадатьОбластьПечатиДокумента(ТабличныйДокумент, НомерСтрокиНачало, ОбъектыПечати, МассивОбъектов.Ссылка);
{Справочник.Контрагенты.МодульМенеджера(363,7)}: Переменная не определена (УправлениеПечатью)
Если <<?>>УправлениеПечатью.НужноПечататьМакет(КоллекцияПечатныхФорм, "ПрайсЛист") Тогда
{Справочник.Контрагенты.МодульМенеджера(365,3)}: Переменная не определена (УправлениеПечатью)
<<?>>УправлениеПечатью.ВывестиТабличныйДокументВКоллекцию(
Причем, ошибка 100 процентная, при любом раскладе. Как можно было выпустить не тестированную конфигурацию?
Точно такая же ошибка при создании документа "Доверенность"
Обработка "Закупка товаров"
Выдает сообщение об ошибке
Ошибка инициализации модуля: Справочник.Контрагенты.МодульМенеджера
по причине:
{Справочник.Контрагенты.МодульМенеджера(182,20)}: Переменная не определена (ПрисоединенныеФайлы)
ДанныеКартинки = <<?>>ПрисоединенныеФайлы.ПолучитьДвоичныеДанныеФайла(ОрганизацияПоУмолчанию.ФайлЛоготип);
{Справочник.Контрагенты.МодульМенеджера(302,54)}: Переменная не определена (УправлениеПечатью)
СтруктураОбластей = ЗаполнитьСтрутуруОбластейМакета(<<?>>УправлениеПечатью.ПолучитьМакет("Справочник.Контрагенты.ПФ_MXL_ПрайсЛист"));
{Справочник.Контрагенты.МодульМенеджера(324,2)}: Переменная не определена (УправлениеПечатью)
<<?>>УправлениеПечатью.ЗадатьОбластьПечатиДокумента(ТабличныйДокумент, НомерСтрокиНачало, ОбъектыПечати, МассивОбъектов.Ссылка);
{Справочник.Контрагенты.МодульМенеджера(363,7)}: Переменная не определена (УправлениеПечатью)
Если <<?>>УправлениеПечатью.НужноПечататьМакет(КоллекцияПечатныхФорм, "ПрайсЛист") Тогда
{Справочник.Контрагенты.МодульМенеджера(365,3)}: Переменная не определена (УправлениеПечатью)
<<?>>УправлениеПечатью.ВывестиТабличныйДокументВКоллекцию(
Причем, ошибка 100 процентная, при любом раскладе. Как можно было выпустить не тестированную конфигурацию?
Точно такая же ошибка при создании документа "Доверенность"
Подскажите, пожалуйста, 3 вопроса:
1. По производству. У нас заказное производство. Есть несколько тысяч образцов (номенклатура), которые могут производиться с набором доп. характеристик (почти бесконечность вариантов). Спецификация по сути одна (ну или набор из нескольких, но не тысяч и не даже не десятков). Спецификация в УНФ привязывается к номенклатуре и характеристикам (кстати, характеристики в отчётах почти нигде не видны). Под каждую номенклатуру и характеристику заводить спецификацию - это неподъёмная задача. Если отвязать от характеристик, всё равно много записей получится. Либо отвязывать и от номенклатуры (а к чему тогда привязывать?), либо в номенклатуре писать «Изделие», а конкретный артикул переносить в характеристики тоже. Получается не совсем хорошо… Нужно что-то придумать.
2. Есть ли возможность сделать холдинги (головные организации), как в УТ?
3. Почему так мало отчётов по торговле? У нас опт и розницы немного. Неужели всё с нуля писать?
1. По производству. У нас заказное производство. Есть несколько тысяч образцов (номенклатура), которые могут производиться с набором доп. характеристик (почти бесконечность вариантов). Спецификация по сути одна (ну или набор из нескольких, но не тысяч и не даже не десятков). Спецификация в УНФ привязывается к номенклатуре и характеристикам (кстати, характеристики в отчётах почти нигде не видны). Под каждую номенклатуру и характеристику заводить спецификацию - это неподъёмная задача. Если отвязать от характеристик, всё равно много записей получится. Либо отвязывать и от номенклатуры (а к чему тогда привязывать?), либо в номенклатуре писать «Изделие», а конкретный артикул переносить в характеристики тоже. Получается не совсем хорошо… Нужно что-то придумать.
2. Есть ли возможность сделать холдинги (головные организации), как в УТ?
3. Почему так мало отчётов по торговле? У нас опт и розницы немного. Неужели всё с нуля писать?
(116)
1. У Вас необычное производство. Обычно спецификаций больше чем номенклатуры с набором характеристик и точно больше, чем номенклатуры. Т.е. по логике программы при производстве на каждую позицию номенклатуры должна быть хотя бы одна спецификация. Не думаю, что в типовой конфигурации можно от этого избавиться. Можно попробовать упростить себе жизнь: сделать фиктивную номенклатуру, скажем, "Изделие" с Вашей спецификацией, а для каждой номенклатуры создавать свою спецификацию с одной строчкой Узел-"Изделие".
2. Не знаю, что такое холдинги в УТ. Посмотрите Настройка учета по организациям (компании) - возможно это аналог.
3. Сложно сказать, не зная какие отчеты Вам нужны. Часть отчетов по торговле перенесли в "Анализ-Отчеты для анализа". И многие отчеты можно настроить под себя своими силами.
1. У Вас необычное производство. Обычно спецификаций больше чем номенклатуры с набором характеристик и точно больше, чем номенклатуры. Т.е. по логике программы при производстве на каждую позицию номенклатуры должна быть хотя бы одна спецификация. Не думаю, что в типовой конфигурации можно от этого избавиться. Можно попробовать упростить себе жизнь: сделать фиктивную номенклатуру, скажем, "Изделие" с Вашей спецификацией, а для каждой номенклатуры создавать свою спецификацию с одной строчкой Узел-"Изделие".
2. Не знаю, что такое холдинги в УТ. Посмотрите Настройка учета по организациям (компании) - возможно это аналог.
3. Сложно сказать, не зная какие отчеты Вам нужны. Часть отчетов по торговле перенесли в "Анализ-Отчеты для анализа". И многие отчеты можно настроить под себя своими силами.
УНФ - управление НЕБОЛЬШОЙ фирмой. И, скорее всего, простой. И это не торговая конфигурация.
Так что, если холдинги или более-менее сложные процессы, конечно "все с нуля писать".
Для того чтобы все с нуля писать, самое подходящее, брать за основу бухгалтерию предприятия.
Или посмотреть в сторону объединения нескольких конфигураций через обмен.
Так что, если холдинги или более-менее сложные процессы, конечно "все с нуля писать".
Для того чтобы все с нуля писать, самое подходящее, брать за основу бухгалтерию предприятия.
Или посмотреть в сторону объединения нескольких конфигураций через обмен.
При начале работы в УНФ возник следующий вопрос: Делаем заказ поставщику на определенное количество номенклатуры, которой недостаточно на складе. Например, 2.5 метра доски. Поставщик привозит не 2.5, а 3 метра. При создании на основании заказа приходной накладной программа не дает записать, т.к. количество в приходной и в заказе разное. Менять количество в заказе на фактическое и потом делать на основании приходную - слишком долго. Этот вариант даже не рассматривают. Подскажите, пожалуйста, как быть в такой ситуации? Как мне сделать заказ на определенное количество товара, а потом приходную нкладную на фактическое количество, которое пришло от поставщика. И при этом, чтобы по заказу поставщику была отгрузка ион закрылся.
(120)Действительно, странно. Ситуация довольно распространенная в жизни. А релиз какой?
Я попробовал в демо. Там, вроде, без проблем можно менять фактическое поступление.
Причем, поступление можно оформлять по нескольким заказам, настроив возможность указания
заказа в табличной части.
Я попробовал в демо. Там, вроде, без проблем можно менять фактическое поступление.
Причем, поступление можно оформлять по нескольким заказам, настроив возможность указания
заказа в табличной части.
(121)
Релиз 1.4.7.42. В Демо базе проверил, тоже ошибка при проведении приходной накладной. "Ошибка:
Оформлено больше, чем указано в заказе поставщику.
Номенклатура: Кондиционер "Самсунг",
остаток по заказу 10 шт,
превышает на 95 шт
Заказ поставщику ТД00-000002 от 17.12.2011 0:00:00"
Релиз 1.4.7.42. В Демо базе проверил, тоже ошибка при проведении приходной накладной. "Ошибка:
Оформлено больше, чем указано в заказе поставщику.
Номенклатура: Кондиционер "Самсунг",
остаток по заказу 10 шт,
превышает на 95 шт
Заказ поставщику ТД00-000002 от 17.12.2011 0:00:00"
(120) Не очень понимаю, почему не поправить заказ поставщику, 3-4 лишних клика мышкой - не очень затратно. Или у Вас еще какие-то нюансы есть?
Возможно, что можно пойти и Вашим путем, но тогда придется пожертвовать частью аналитики, например, анализом взаиморасчетов по заказам поставщику.
Возможно, что можно пойти и Вашим путем, но тогда придется пожертвовать частью аналитики, например, анализом взаиморасчетов по заказам поставщику.
(123) Там идет проверка по регистру "Заказы поставщикам", чтобы не было отрицательного остатка. И если в документе "Заказ поставщику" будет значение 100 штук, то в регистре будет приход на 100 штук. Соответственно, если в приходной указать 200 штук, то будет расход 200 и образуется отрицательный остаток по регистру. Можно отключить контроль остатков, тогда будет проводиться. Но тогда в отчетах все не красиво:(
(123)Я глубоко не лажу, но ощущение, что такого не должно быть. Мало ли какой заказ был.
Вообще, заказ можно считать планом. А отклонения от плана еще никто не отменял.
Иначе, это не план, а закон. Где-то не дорабатываете. Ну не может быть такая реализация
быть. Что-то не верится. Надо посмотреть доку.
"Документ предназначен для оформления намерений организации приобрести товары и услуги у поставщика"
(126)По моему, исправление первичных данных нежелательно. Так теряется история.
И, вообще, теряется смысл заказа.
Вообще, заказ можно считать планом. А отклонения от плана еще никто не отменял.
Иначе, это не план, а закон. Где-то не дорабатываете. Ну не может быть такая реализация
быть. Что-то не верится. Надо посмотреть доку.
"Документ предназначен для оформления намерений организации приобрести товары и услуги у поставщика"
(126)По моему, исправление первичных данных нежелательно. Так теряется история.
И, вообще, теряется смысл заказа.
(127)"Процесс переговоров с поставщиками можно регистрировать в программе с помощью документа Событие." (с) книжка Клепцовой.
Это если история нужна.
Если заказ поставщику не будет совпадать с поступлениями, посыплется аналитика. Посмотрите различные отчеты по анализу, особенно расчет потребностей (думаю, им пользоваться вообще не получится).
Почитайте книжку Клепцовой, может быть поймете идеологию.
Это если история нужна.
Если заказ поставщику не будет совпадать с поступлениями, посыплется аналитика. Посмотрите различные отчеты по анализу, особенно расчет потребностей (думаю, им пользоваться вообще не получится).
Почитайте книжку Клепцовой, может быть поймете идеологию.
(129)Идеология Заказа поставщику схожа с идеологией Заказа покупателя. Мне она кажется правильной. Она позволяет отслеживать и анализировать выполнение заказа. Если покупатель/поставщик изменил свое намерение, то нужно изменить заказ, чтобы правильно анализировать его выполнение.
Или не согласится с его желаниями и отказаться от заказа =)
Или не согласится с его желаниями и отказаться от заказа =)
(135)Якобы, простой принцип подхода "по прототипу" не всегда правильный. Особенно к таким вещам надо осторожно относиться к идеологии.
В противном случае, все увязнет в так называемых нюансах, которые придется реализовывать, как в (133), причем, каждый по своему.
При таком подходе, мы теряем смысл системы как источника анализа. Ведь причин отклонений не будет видно. Я делал много чего в автоматизации учета и знаю не понаслышке, как важно оставлять первичку в состоянии "как есть".
Если уж пошла такая пьянка то, на мой взгляд, правильнее вводить дополнительный заказ, а не трогать заказ первоначальный.
Возвращаясь к решению(на мой взгляд, в кодировании замечательном) в (133).
Правильнее дать возможность вносить заказы с отрицательным количеством. И тут уже отслеживать отрицательные остатки в регистре.
Причем, на каждой строке заказа возможны комментарии.
Ведь пример в (133) не очень красиво обыгрывает ситуацию, типа, "уменьшили(или сняли, или, наоборот, увеличили) заказ на какую то позицию, добавили некоторые другие позиции". Где вы потом увидите причины "не согласится с его желаниями и отказаться от заказа"? А ведь это может быть потом важным, при последующих решениях выбора того или иного поставщика.
Я думаю в предложенном в (133) есть более изящное и универсальное решение проблемы без создания виртуальных документов.
Жаль, что этого нет в штатном решении.
В противном случае, все увязнет в так называемых нюансах, которые придется реализовывать, как в (133), причем, каждый по своему.
При таком подходе, мы теряем смысл системы как источника анализа. Ведь причин отклонений не будет видно. Я делал много чего в автоматизации учета и знаю не понаслышке, как важно оставлять первичку в состоянии "как есть".
Если уж пошла такая пьянка то, на мой взгляд, правильнее вводить дополнительный заказ, а не трогать заказ первоначальный.
Возвращаясь к решению(на мой взгляд, в кодировании замечательном) в (133).
Правильнее дать возможность вносить заказы с отрицательным количеством. И тут уже отслеживать отрицательные остатки в регистре.
Причем, на каждой строке заказа возможны комментарии.
Ведь пример в (133) не очень красиво обыгрывает ситуацию, типа, "уменьшили(или сняли, или, наоборот, увеличили) заказ на какую то позицию, добавили некоторые другие позиции". Где вы потом увидите причины "не согласится с его желаниями и отказаться от заказа"? А ведь это может быть потом важным, при последующих решениях выбора того или иного поставщика.
Я думаю в предложенном в (133) есть более изящное и универсальное решение проблемы без создания виртуальных документов.
Жаль, что этого нет в штатном решении.
Еще столкнулся с ситуацией. Помогите решить, пожалуйста:) Приходит покупатель и делает заказ на 2000 руб, оператор принимает заказ и создает документ "Заказ-наряд" в статусе "в работе". Покупатель вносит предоплату наличными 50% от суммы заказа, т.е. 1000р. Оператор на основании "заказ-наряда" создает документ "поступление в кассу", там указывает, что это "аванс" и сумму 1000 руб. Вопросы следующие:
1) Как этот аванс зачесть, пока статус документа "Заказ-наряд" "в работе"? Оператор должен сразу распечатать печатную форму из заказ-наряда, в которой должно быть указано сколько покупатель внес предоплаты. А зачесть авансы до того как заказ-наряд не будет "выполнен" нельзя. Печатная форма внешняя и не могу понять как в нее вытащить сумму предоплаты. Вариант только если программно искать документ "Поступление в кассу", который связан с этим заказом и если признак "аванс" , то брать из него сумму. Почему зачесть аванс можно только тогда, когда заказ выполнен?
2) Когда заказ готов и покупатель пришел забирать его, оператор заходит в этот заказ-наряд и создает на основании документ поступление в кассу. Но туда подставляется полная сумма без учета предоплаты. Так вот я не смог найти как быстро сделать еще одно поступление в кассу от покупателя, но чтобы сумма была уже с учетом предоплаты, которую внесли ранее.
1) Как этот аванс зачесть, пока статус документа "Заказ-наряд" "в работе"? Оператор должен сразу распечатать печатную форму из заказ-наряда, в которой должно быть указано сколько покупатель внес предоплаты. А зачесть авансы до того как заказ-наряд не будет "выполнен" нельзя. Печатная форма внешняя и не могу понять как в нее вытащить сумму предоплаты. Вариант только если программно искать документ "Поступление в кассу", который связан с этим заказом и если признак "аванс" , то брать из него сумму. Почему зачесть аванс можно только тогда, когда заказ выполнен?
2) Когда заказ готов и покупатель пришел забирать его, оператор заходит в этот заказ-наряд и создает на основании документ поступление в кассу. Но туда подставляется полная сумма без учета предоплаты. Так вот я не смог найти как быстро сделать еще одно поступление в кассу от покупателя, но чтобы сумма была уже с учетом предоплаты, которую внесли ранее.
(131) Нет. Пользователи сказали, что не хотят заказ делать, т.к. работают в УТ 10.3 без заказов и делают просто ПТиУ по факту. Так же и хотят делать в УНФ. Просто по факту бить приходную, а заказы делать уже сколько хотят и как хотят (по телефону, на сайте поставщика и др.). Просто будут после того, как забьют приход смотреть для каких заказов покупателей хвтает товаров и ставить товары в резерв для этого заказа. Потом смотреть чего не хватает еще и заказывать. Я конечно против такого решения и буду еще чт-то придумывать. Т.к. в такой ситуации можно по ошибке заказать несколько раз одно и то же. Не видно, что в пути.
Приходилось внедрять в Зоомагазине. Нужно было получать реальные данные по себестоимости и валовой прибыли. Животные до момента продажи требуют дополнительных расходов на питание, лечение и т.д. Нужно было все эти дополнительные материалы списывать на заказ покупателя и составлять дополнительную фиктивную расходную накладную по нулевым ценам. Вот ссылка на видеоролик с решением задачи . Может быть, еще кому-нибудь пригодится. Клиент за полгода пока не жаловался.
(133)Замечательно все по исполнению. Как говорится, респект.
Но все эти "фиктивные накладные по нулевым ценам".
Я не понимаю, почему так "железобетонно" реализована ситуация того, что нельзя получать больше того, чем в заказе.
Это нормальная ситуация. А если будет меньше, чем в заказе? Что тогда? Ситуация считается правильной?
Тогда "невыполнение" условий заказа с недопоставкой, системой заложено как правильное.
Может тогда, вообще, отказаться от заказов?
И потом, про кодирование в конфигураторе. Что будет если выйдет новая версия и изменится методология?
Вызывать снова программиста?
Получилось вопросов больше, чем ответов.
Но все эти "фиктивные накладные по нулевым ценам".
Я не понимаю, почему так "железобетонно" реализована ситуация того, что нельзя получать больше того, чем в заказе.
Это нормальная ситуация. А если будет меньше, чем в заказе? Что тогда? Ситуация считается правильной?
Тогда "невыполнение" условий заказа с недопоставкой, системой заложено как правильное.
Может тогда, вообще, отказаться от заказов?
И потом, про кодирование в конфигураторе. Что будет если выйдет новая версия и изменится методология?
Вызывать снова программиста?
Получилось вопросов больше, чем ответов.
(137)Я не думаю, что заказчик сам предлагал схему с созданием несуществующего документа. Скорее всего, на этапе реализации, чтобы "клиент был доволен", было предложено не самое гибкое решение, с использованием "дополнительной фиктивной расходной накладной по нулевым ценам".
Кстати, возможно, "нулевые цены" будут поддавать неправильные средние и другие цены, если, вдруг, захочется без извращений получить средние, минимальные, максимальные или какие-либо еще цены и другие анализы.
Кстати, возможно, "нулевые цены" будут поддавать неправильные средние и другие цены, если, вдруг, захочется без извращений получить средние, минимальные, максимальные или какие-либо еще цены и другие анализы.
(138) OBEH, Добрый день! Просто заказчик сначала довольно долго пытался решить проблему самостоятельно, без использования средств конфигурирования, но именно таким путем. Поэтому и попросил допилить в конфигураторе то, что они сами пытались реализовать. Они сначала надеялись, что с помощью каких-нибудь простых настроек система сама позволит это сделать. Ничего мы не навязывали. Их такой вариант вполне устраивал.
УНФ зачастую покупает народ не очень богатый и на глобальные переработки не рассчитывает. Многие вообще не понимают, зачем нужно что-то до- или перепрограммировать, по их мнению, все должно решаться настройками. Думаю, во многом они правы.
Клиент считал, что в таком виде для него все будет более понятно и прозрачно. На что именно израсходован товар (продан или использован на животных). Какова реальная себестоимость заказа покупателя и насколько рентабельны разные заказы. Обеспечиваются именно те движения в регистрах, которых им не хватало для управленческого учета. А если потребуются какие-то другие отчеты без учета нулевых цен по реализации, то это всегда можно сделать, используя в запросе требуемых данных дополнительные условия отбора. А при списании себестоимости товаров учитываются цены, по которым были поставки, а не реализации. Одним словом, если клиенту понадобится еще что-то увидеть в другом представлении, тогда и будем решать.
Дело в том, что я тоже послушал франчей и предложил "небогатой конторе" взять УНФ. Там небольшое производство и торговля. Причем, торговля оптом и в розницу. Сейчас понимаю, что в УНФ очень много чего нет даже для небольшой фирмы. Это очередная коробка с примером, как можно начать программировать под задачу. Розница, как и, возможно другое, там почти на нуле. И хочется как-то выправить ситуацию.
(143) Я правильно понимаю, что можно было бы решить эту проблему без использования, виртуальных документов и нулевых цен?
По крайней мере я думал, что это как-то должно было быть реализовано штатно. И если методология запрещает превышение, почему тогда не запрещает меньше? Методологически, это палка о двух концах.
И еще.
Коль там нет нормальной розницы, может быть, стоит приобрести конфигурацию Розница и наладить обмен между ними, чтобы не рисовать свой функционал?
(143) Я правильно понимаю, что можно было бы решить эту проблему без использования, виртуальных документов и нулевых цен?
По крайней мере я думал, что это как-то должно было быть реализовано штатно. И если методология запрещает превышение, почему тогда не запрещает меньше? Методологически, это палка о двух концах.
И еще.
Коль там нет нормальной розницы, может быть, стоит приобрести конфигурацию Розница и наладить обмен между ними, чтобы не рисовать свой функционал?
В данном конкретном случае, чтобы было меньше недопонимания, в дополнение к ранее осуществленному можно было сделать копию документа "Расходная накладная", назвать его более адекватно для данной ситуации, нулевую цену реализации просто не отображать визуально, чтобы не пугать народ, и этот документ формировался бы тоже на основании заказа покупателя. Но это еще + небольшие расходы со стороны заказчика, ему и так все понятно. Что касается Розницы, концептуально там функционал на данный момент очень богатый. Но, к сожалению, кое-что из того, что задекларировано, реально просто задекларировано. Пока еще присутствует и кривой код. Но на самом деле, конфигурация активно развивается. Есть надежда и есть основания надеяться (пока умолчу почему), что в ближайшем будущем конфигурация должна стать востребованной. Надеюсь, что интерес к ней возрастет как из вне(со стороны клиентов), так и изнутри (со стороны самой фирмы 1С). Вообще эта конфигурация с некоторых пор тянется по функционалу за УТ11, а стоит значительно дешевле.
Розница будет штатно обмениваться с новой конфигурацией Управление производством (далеко не дешевая). Насчет штатного обмена с УНФ, думаю, что вряд ли дождемся. Проше и дешевле давить в письмах на разработчиков УНФ, чтобы доработали необходимый функционал по розничной торговле или, если есть основания, просто сменить конфигурацию. Разработчики ведут статистику пожеланий клиентов. Самое востребованное рано или поздно добавляют.
То, что УНФ сделали довольно большой шаг вперед, по сравнению с годичной давности "примером", я заметил.
Использование дисконтных карт, накопительных скидок и все такое в УНФ отсутствует. И я подозреваю, что развивать в этом направлении УНФ фирма не будет. Не всем, кому подойдет УНФ понадобится такой функционал. И тут, мне кажется, правильно будет(если это нужно) делать связку УНФ+Розница.
По моему, где-то на сайте 1С я видел, что делают обмен УНФ <-> Розница.
Использование дисконтных карт, накопительных скидок и все такое в УНФ отсутствует. И я подозреваю, что развивать в этом направлении УНФ фирма не будет. Не всем, кому подойдет УНФ понадобится такой функционал. И тут, мне кажется, правильно будет(если это нужно) делать связку УНФ+Розница.
По моему, где-то на сайте 1С я видел, что делают обмен УНФ <-> Розница.
(147) OBEH, по крайней мере, год назад в моем присутствии один из клиентов именно такой вопрос задавал "маме" конфигурации Розница (не исключаю, что это были именно Вы). Ответ был (см. выше). Но пожелания клиентов включают в себя не только доработки конфигураций. Пожелание обмена, такое же пожелание и тоже может быть услышанным. В любом случае, решение через обмен лично мне видится не проще. Если Вы относитесь к числу клиентов, то лучше найдите единомышленников и просите доработки УНФ. Каждый со своей стороны. Все конфигурации без исключения развиваются. Будет вас много, допроситесь любого функционала, даже если изначально он не предполагался.
Нет, это был не я. Я год назад не интересовался УНФ в плане использования.
Теперь по поводу "Розница будет штатно обмениваться с новой конфигурацией Управление производством".
Если будет штатно с УПП, то в чем проблемы так-же обмениваться с УНФ? Думаю, это будет даже гораздо проще.
Теперь по поводу "Розница будет штатно обмениваться с новой конфигурацией Управление производством".
Если будет штатно с УПП, то в чем проблемы так-же обмениваться с УНФ? Думаю, это будет даже гораздо проще.
В плане обмена, конечно, это возможно. Но все-таки УП (новая конфигурация будет называться не УПП) и УНФ разные конфигурации. Если будет обмен между УНФ и Розницей, то план обмена может потребоваться обновлять при каждом обновлении УНФ и при каждом обновлении Розницы (не факт, что именно при каждом, но периодически вместе с обновлением одной из конфигураций потребуется менять план обмена, если где-то поменялась структура данных). Лучше и надежнее, когда все в одной конфигурации. Т.е. это дополнительное слабое место, если обслуживающая франчайзи теоретически может момент обновления плана обмена упустить. Точно сказать не могу, что проще для фирмы 1С: поддерживать еще один обмен или усовершенствовать УНФ. Но для клиента выгоднее и надежнее усовершенствование УНФ. Даже штатные обмены иногда бывают кривыми, а если еще франчайзи вовремя не заменит план обмена - зачем дополнительные слабые места. Ведь нужно будет четко следить за обновлениями двух конфигураций и вовремя, при необходимости, менять планы обмена. Надежность системы падает.
Да и дешевле. Обновить одну конфигурацию вы можете самостоятельно. И фирма 1С стремится предоставить полные возможности по обновлению отдельно взятой конфигурации самостоятельно, без услуг франчайзи. При наличии обменов и своевременном синхронном обновлении конфигураций в ряде случаев проблем у вас тоже не будет. Но, скорее всего, когда-то вы столкнетесь с ситуацией, что ваш план обмена будет неактуален.
На сколько мне известно, сейчас и плана обменов нет. Если просить, то просить то, что нужнее. УНФ обменивается только с Бухгалтерией. Розница пока только с Бухгалтерией (2.0, 3.0) и УТ (11.0, 11.1). Если я неправ, то, думаю, найдется тот, кто сможет возразить.
(153)Версия 1.4.8.3 Новое в версии, Совместное использование с конфигурацией Розница Ред. 2.1 "Добавлена возможность совместного использования конфигураций «Управление небольшой фирмой» и «Розница». Функционал позволяет обеспечить автоматизацию бизнес-процессов розничных торговых точек (магазинов), работающих в рамках распределенной розничной сети торгового предприятия."
(154)Я тоже где-то такое видел.
В принципе, если у конторы есть Розница, УНФ и Бухгалтерия, то можно наладить обмен штатный
Розница <-> Бухгалтерия,
УНФ <-> Бухгалтерия
С появлением "...совместного использования конфигураций «Управление небольшой фирмой» и «Розница»", эти возможности становятся более гибкими, причем, все в рамках штатных функций.
Теперь, в свете некоторых представлений об УНФ, есть такой вопрос.
Не стоит-ли, вместо всех этих конфигураций, взять одну 1С:"Комплексная автоматизация 8"?
Или, может быть, в ней нет чего-то того, что дают все эти три конфигурации по отдельности?
Как я сам это себе представляю.
Это, например, фирма, имеющая небольшое производство. Продает свою продукцию в розницу и оптом.
Вопросы производства, более-менее в УНФ вести, в том числе, планирование и его исполнение. Как пример, одним исполнителем в (133) была небольшая доработка исправления отдельного "косяка" по заказу клиента.
Вопросы оптовой торговли тоже вполне в УНФ обрабатываются.
Вопросы розницы решаются в Рознице.
Вроде, для конторы с распределенной географически вопросы решать можно, особенно, при слабой связи между подразделениями(производство, опт, торговые точки)
И вся налоговая отчетность, естественно, в БП 3.0. Это не требует большой оперативности.
Кстати, скачал последнюю версию УНФ 1.4.8.3. Судя по протоколу обновления, довольно много внесли изменений в объекты конфигурации, по сравнению с предыдущей версией.
Мда. Я фигею с этих русских.
Обновил версию. Сразу, наугад, начал по кнопочкам. И в первом же документе "Отчет по переработке" в печати ТОРГ-12 ошибка, типа, "Повторяющийся псевдоним Основание". Они тестируют свои поделки?
В принципе, если у конторы есть Розница, УНФ и Бухгалтерия, то можно наладить обмен штатный
Розница <-> Бухгалтерия,
УНФ <-> Бухгалтерия
С появлением "...совместного использования конфигураций «Управление небольшой фирмой» и «Розница»", эти возможности становятся более гибкими, причем, все в рамках штатных функций.
Теперь, в свете некоторых представлений об УНФ, есть такой вопрос.
Не стоит-ли, вместо всех этих конфигураций, взять одну 1С:"Комплексная автоматизация 8"?
Или, может быть, в ней нет чего-то того, что дают все эти три конфигурации по отдельности?
Как я сам это себе представляю.
Это, например, фирма, имеющая небольшое производство. Продает свою продукцию в розницу и оптом.
Вопросы производства, более-менее в УНФ вести, в том числе, планирование и его исполнение. Как пример, одним исполнителем в (133) была небольшая доработка исправления отдельного "косяка" по заказу клиента.
Вопросы оптовой торговли тоже вполне в УНФ обрабатываются.
Вопросы розницы решаются в Рознице.
Вроде, для конторы с распределенной географически вопросы решать можно, особенно, при слабой связи между подразделениями(производство, опт, торговые точки)
И вся налоговая отчетность, естественно, в БП 3.0. Это не требует большой оперативности.
Кстати, скачал последнюю версию УНФ 1.4.8.3. Судя по протоколу обновления, довольно много внесли изменений в объекты конфигурации, по сравнению с предыдущей версией.
Мда. Я фигею с этих русских.
Обновил версию. Сразу, наугад, начал по кнопочкам. И в первом же документе "Отчет по переработке" в печати ТОРГ-12 ошибка, типа, "Повторяющийся псевдоним Основание". Они тестируют свои поделки?
(157) zlakizla, в УНФ такой возможности нет. Как указывает в описании продукта фирма 1С, раздел зарплаты в УНФ предназначен для начисления зарплаты и подоходного налога с неё. Отчисления в фонды начисляем в других специализированных программах и переносим в УНФ, в случае необходимости. Т.е. серую зарплату начислить в УНФ можно, и всё. Авансы можно начислить через ведомости. Впрочем, для небольшой фирмы, этого вполне достаточно.
После обновления на унф 1.4.8 появилась странная ситуация: во всех расходных накладных стоят резервы, хотя галочка использования резервов вообще не стояла. Причем товара может быть в отгрузке 5 штук, а резерв стоять 8 штук. Никто не сталкивался?
Всем привет
Внедряю УНФ в небольшой производственной конторе.
Плюсы данной программы:
- ПростатА. Интерфейс пользователю понятен. Пользователь быстро привыкает
- Построение простых цепочек взаиморасчетов . Просто супер.
- Построение простых операций по производству. И даже подсчет себестоимости показывает нужные цифры
- Гибкость управленческого плана счетов
Минусы (самое вкусное)
- Без доработок, из коробки, работает разве что , работа с поставщиками.Поясню, при выписке документов на реализацию , убивается просто куча время на внесение разной инфы во всякие ТТН. Ужас...
- Вечные маленькие недочеты. тут не подтягивает, там не печатает. Вроде бы не существенно, но в целом отнимает кучу времени
- Постоянные проблемы с обменом в БП. В последних релизах нарушен обмен с 3.0
- Отчеты...отдельная песня.Нужны навыки и опыт
На текущий момент я не сделал ни одной доработки по базе. Это с одной стороны хорошо, но и компания очень маленькая, а запросы будут расти со временем
Вывод:
на мой взгляд, данная конфигурация подходит для компании не более 5 человек, 100 позиций номенклатуры.
Внедряю УНФ в небольшой производственной конторе.
Плюсы данной программы:
- ПростатА. Интерфейс пользователю понятен. Пользователь быстро привыкает
- Построение простых цепочек взаиморасчетов . Просто супер.
- Построение простых операций по производству. И даже подсчет себестоимости показывает нужные цифры
- Гибкость управленческого плана счетов
Минусы (самое вкусное)
- Без доработок, из коробки, работает разве что , работа с поставщиками.Поясню, при выписке документов на реализацию , убивается просто куча время на внесение разной инфы во всякие ТТН. Ужас...
- Вечные маленькие недочеты. тут не подтягивает, там не печатает. Вроде бы не существенно, но в целом отнимает кучу времени
- Постоянные проблемы с обменом в БП. В последних релизах нарушен обмен с 3.0
- Отчеты...отдельная песня.Нужны навыки и опыт
На текущий момент я не сделал ни одной доработки по базе. Это с одной стороны хорошо, но и компания очень маленькая, а запросы будут расти со временем
Вывод:
на мой взгляд, данная конфигурация подходит для компании не более 5 человек, 100 позиций номенклатуры.
(165) Milanick,
У нас в базе УНФ :10 000 позиций номенклатуры, из них 4 000 позиций активно используются. С обновлениями за январь - февраль 2014г. несколько изменился интерфейс поиска номенклатуры из форм заказа, накладной... Он стал эффективным и привычным, как в ТиС и как в поисковике gooogle, можно одновременно вводить часть артикула, по 1-2-3 буквы из любого слова непопорядку наименования и при этом номенклатура находится моментально. Это очень приятно. В базе одновременно сидит пять человек и она летает. УНФ и 10 рабочих мест потянет легко.
на мой взгляд, данная конфигурация подходит для компании не более 5 человек, 100 позиций номенклатуры.
У нас в базе УНФ :10 000 позиций номенклатуры, из них 4 000 позиций активно используются. С обновлениями за январь - февраль 2014г. несколько изменился интерфейс поиска номенклатуры из форм заказа, накладной... Он стал эффективным и привычным, как в ТиС и как в поисковике gooogle, можно одновременно вводить часть артикула, по 1-2-3 буквы из любого слова непопорядку наименования и при этом номенклатура находится моментально. Это очень приятно. В базе одновременно сидит пять человек и она летает. УНФ и 10 рабочих мест потянет легко.
Работа логиста в УНФ.
Есть возможность указывать для каждой позиции номенклатуры минимальный и максимальный остаток. Но приходится делать это вручную, заходить для каждой позиции номенклатуры отдельно в карточку (Управление запасами).
При этом имеется хорошая форма "Расчет потребностей", где можно выяснить, каких позиций и сколько (даже с учетом поставщиков), на какую сумму не хватает запасов на складе, а также сформировать и заказ поставщику, что очень удобно. Не удобно то, что нет простого отчета, где выведены позиции номенклатуры с установленными минимальными и максимальными остатками, хотя бы для быстрого контроля за установленными уровнями запасов на складе. Кстати, уровни запасов на складе нужно прописывать по каждому отдельному предприятию.
Работа бухгалтеров по вводу первички.
Ну тут УНФ точно создавалась в первую очередь под ввод первички, т.к. в УНФ увидеть план счетов, бухгалтерскую проводку не реально. Видимо, от бухгалтеров поступало очень много жалоб на то, что они повсюду встречают в рабочих программах дебит и кредит, что портило их настроение и аппетит)) Таким образом, работать в УНФ на первичку можно посадить практически любого человека с улицы, который через полчаса уже войдет во вкус и начнет вбивать первичку, если вы ему один раз покажите, как такой документ вводить. И он у вас никогда не испугается, не увидит изумительного количества проводок, обрамляющих первичный бухгалтерский документ.
Про кассу. ПКО, РКО, ведомости по выдаче зарплаты и т.п. конечно же в УНФ есть. Но нету в УНФ отчета кассовой книги, придется искать на ИнфоСтарте.
По внешнему виду, так сказать, интерфейсу программы УНФ. Внешне похожа на красивую конфетку. Если же вы не любите слащавости, картинки можно отключить. Но, есть то, что у УНФ не отнять. В интерфейсе (кроме формирования отчетов) отсутствует избыточность информации, ненужные цифры, надписи, субконто и т.п.. Так же, можно для удобства отключить/подключить отдельные поля у документов в реестрах, либо в формах документов, что особенно удобно, когда бухгалтерия "крыжит" документы. Поэтому, даже в конце рабочего дня, от УНФ не устаешь, и ты это как то даже осознаёшь, когда выходишь на улицу из офиса))
Есть возможность указывать для каждой позиции номенклатуры минимальный и максимальный остаток. Но приходится делать это вручную, заходить для каждой позиции номенклатуры отдельно в карточку (Управление запасами).
При этом имеется хорошая форма "Расчет потребностей", где можно выяснить, каких позиций и сколько (даже с учетом поставщиков), на какую сумму не хватает запасов на складе, а также сформировать и заказ поставщику, что очень удобно. Не удобно то, что нет простого отчета, где выведены позиции номенклатуры с установленными минимальными и максимальными остатками, хотя бы для быстрого контроля за установленными уровнями запасов на складе. Кстати, уровни запасов на складе нужно прописывать по каждому отдельному предприятию.
Работа бухгалтеров по вводу первички.
Ну тут УНФ точно создавалась в первую очередь под ввод первички, т.к. в УНФ увидеть план счетов, бухгалтерскую проводку не реально. Видимо, от бухгалтеров поступало очень много жалоб на то, что они повсюду встречают в рабочих программах дебит и кредит, что портило их настроение и аппетит)) Таким образом, работать в УНФ на первичку можно посадить практически любого человека с улицы, который через полчаса уже войдет во вкус и начнет вбивать первичку, если вы ему один раз покажите, как такой документ вводить. И он у вас никогда не испугается, не увидит изумительного количества проводок, обрамляющих первичный бухгалтерский документ.
Про кассу. ПКО, РКО, ведомости по выдаче зарплаты и т.п. конечно же в УНФ есть. Но нету в УНФ отчета кассовой книги, придется искать на ИнфоСтарте.
По внешнему виду, так сказать, интерфейсу программы УНФ. Внешне похожа на красивую конфетку. Если же вы не любите слащавости, картинки можно отключить. Но, есть то, что у УНФ не отнять. В интерфейсе (кроме формирования отчетов) отсутствует избыточность информации, ненужные цифры, надписи, субконто и т.п.. Так же, можно для удобства отключить/подключить отдельные поля у документов в реестрах, либо в формах документов, что особенно удобно, когда бухгалтерия "крыжит" документы. Поэтому, даже в конце рабочего дня, от УНФ не устаешь, и ты это как то даже осознаёшь, когда выходишь на улицу из офиса))
(172) OBEH, Т.Е ФИРМЕ ЛЕГЧЕ ЗАПЛАТИТЬ ЗА ДОПОЛНИТЕЛЬНУЮ КОНФИГУРАЦИЮ, ЗА ЕЕ ПОДДЕРЖКУ И ОБНОВЛЕНИЕ? А в УНФ у меня формируются отчеты по УСН и где брать данные по начисленной зарплате или их потом доработать в ЗУП? А так данная конфигурация достаточна для ведения учета организациям использующих УСН.
salus , данная конфигурация является управленченской. Вести в ней регламентированны учет (читать сдавать регламентированную отчетность) нельзя. Блок кадрового учета в ней очень скуден. Так что для адекватного кадрового учета (среднего заработка, больничных, северных) лучще базовый ЗУП взять.
Работаю с БП, УТ, УНФ. Проблем с бухучетом нет. Сам ИП и на упрощенке более 20 лет. А городить огород с n-количеством баз я не собираюсь, т.к. время имеет ценность. Мне достаточно в УНФ добавить необходимые выходные формы и, по необходимости, документы и регистры. Экономлю время и деньги. А спорить о чем? Это моя точка зрения проверенная временем. Утверждение НЕЛЬЗЯ, но это ваше право.
(178) мне кажется огород это когда доработанная конфигурация обновляется вручную специалистом, вместо того, чтобы обновлять 2 (да хоть 3) конфигурации парой кликов мыши в автоматическом режиме. Да и опять же, про экономию времени - оценили свои трудозатраты для обновления доработанного УНФ с каждым новым релизом, вместо того, чтобы просто просто тыцнуть в автоматическое обновление?
Для вас может это нормально, простому же пользователю, тем более руководителю такой ерунды совсем не нужно. Особенно учитывая, что, скорее всего, в базе по кадрам будут работать одни люди, а в базе УНФ другие (если вся фирма не состоит из 2-3 человек, один из которых - программист 1с, который ее допиливает до кадрового учета :-D ).
Для вас может это нормально, простому же пользователю, тем более руководителю такой ерунды совсем не нужно. Особенно учитывая, что, скорее всего, в базе по кадрам будут работать одни люди, а в базе УНФ другие (если вся фирма не состоит из 2-3 человек, один из которых - программист 1с, который ее допиливает до кадрового учета :-D ).
(179) Мне кажется, что у ВАС опыта реальной работы с УНФ не было. На то она и типовая, что решает типовые вопросы, а у каждого клиента они свои и их нужно решать, а если он будет делать это ручками, то ВЫ ему не нужны, а достаточно продвинутый юзер и он обновит. Клиенту нет никакого дела до ВАШИХ обновлений, но он хочет свои повседневные вопросы решать полнее и меньшим телодвижением. Моя задача и добавить удобный функционал для клиента, и обновлять конфигурацию.
А что разве в одной конфигурации не могут работать разные пользователи? Что им это мешает?
Еще раз обращаю внимание, что сам ИП и сам пользуюсь своей доработанной конфигурацией и учет и отчетность занимает минимальное количество времени. Единственно что хотелось доработать мобильное приложение под свои задачи. А вести первичку в одной базе, а потом выгружать в другую для отчетности это ли не гемор? Увольте...
А что разве в одной конфигурации не могут работать разные пользователи? Что им это мешает?
Еще раз обращаю внимание, что сам ИП и сам пользуюсь своей доработанной конфигурацией и учет и отчетность занимает минимальное количество времени. Единственно что хотелось доработать мобильное приложение под свои задачи. А вести первичку в одной базе, а потом выгружать в другую для отчетности это ли не гемор? Увольте...
(180) ну тогда, наверное, правильнее будет говорить только за себя, не находите? вы себе доработали, вам удобнее, вы пользуетесь. А теперь пойдите объясните руководителю фирмы чуть покрупнее двух с половиной землекопов, что он должен платить деньги специалисту (вам), который все это будет склеивать в конфигурации, которая для этого совершенно не предназначено, платить этому же специалисту деньги за каждое обновление (а в регламентированном учете они выходят часто и довольно критичны - букву в форме отчетности поменяли и налоговая у вас уже ничего не примет), платить этому же специалисту деньги за исправление чего-либо что его не устраивает в доработке или в итоге работает не так как ему хочется, платить все тому же специалисту деньги за то что тот будет каждый раз объяснять девочкам-бухгалтерам-кадровикам как это все работает (а такие вопросы будут и будут постоянно).
да, еще, желательно бы, чтобы этот специалист был в любой момент доступен - не был в отпуске, на больничном, занят с другим клиентом и т.д.
а теперь поставьте себя на место такого руководителя, который не вы и не разбирается в 1С и, может быть, поймете, что каждому свое.
вам удобно - пользуйтесь.
ключевой момент в вашем посте видимо "а если он будет делать это ручками, то ВЫ ему не нужны", правильно?
ведь действительно, если все это не делать, а пользоваться готовыми решениями, то ВЫ ему действительно будете не нужны и все будет просто и понятно.
"Клиенту нет никакого дела до ВАШИХ обновлений, но он хочет свои повседневные вопросы решать полнее и меньшим телодвижением."
Когда дело касается управленческого учета - клиенту действительно нет дела до обновлений. Когда дело касается регламентированного учета и изменений в законодательстве - клиент первый будет кричать "где же, где же мои обновления с изменениями?!".
По поводу опыта реальной работы с УНФ - такими предположениями и я могу разбрасываться по отношению к вам:
"Мне кажется, что у ВАС опыта реальной работы с УНФ не было, кроме использования своей доработанной конфигурации".
да, еще, желательно бы, чтобы этот специалист был в любой момент доступен - не был в отпуске, на больничном, занят с другим клиентом и т.д.
а теперь поставьте себя на место такого руководителя, который не вы и не разбирается в 1С и, может быть, поймете, что каждому свое.
вам удобно - пользуйтесь.
ключевой момент в вашем посте видимо "а если он будет делать это ручками, то ВЫ ему не нужны", правильно?
ведь действительно, если все это не делать, а пользоваться готовыми решениями, то ВЫ ему действительно будете не нужны и все будет просто и понятно.
"Клиенту нет никакого дела до ВАШИХ обновлений, но он хочет свои повседневные вопросы решать полнее и меньшим телодвижением."
Когда дело касается управленческого учета - клиенту действительно нет дела до обновлений. Когда дело касается регламентированного учета и изменений в законодательстве - клиент первый будет кричать "где же, где же мои обновления с изменениями?!".
По поводу опыта реальной работы с УНФ - такими предположениями и я могу разбрасываться по отношению к вам:
"Мне кажется, что у ВАС опыта реальной работы с УНФ не было, кроме использования своей доработанной конфигурации".
(181) zuxelzz,
И еще.
Если нужно дописывать конфигурацию, то это новая подсистема, которая работает автономно. И если клиенту не нужно, то он и не пользуется. Это обновление не затрагивает, не считая случая отказа от модальных форм, но такие изменения не так часто бывают.
Изменение конфигурации основных объектов провожу по очень большой необходимости с документированием всех своих действий. На данный момент проблем с обновлением нет. С описанием обновление выполнит и другой специалист.
И еще.
Если нужно дописывать конфигурацию, то это новая подсистема, которая работает автономно. И если клиенту не нужно, то он и не пользуется. Это обновление не затрагивает, не считая случая отказа от модальных форм, но такие изменения не так часто бывают.
Изменение конфигурации основных объектов провожу по очень большой необходимости с документированием всех своих действий. На данный момент проблем с обновлением нет. С описанием обновление выполнит и другой специалист.
(183) Это все понятно. Я тоже позиционирую коробки от 1с, как примеры написания того или иного функционала на платформе.
Но, дело в том, что не все хозяева бизнеса имеют квалификацию дописывать/переделывать эти примеры под себя.
EXCEL тоже, своего рода, инструмент. Я видел просто умопомрачительные реализации учета "под себя" на нем. Но, опять-же, такое может позволить себе человек очень прилично владеющий этим инструментом.
Но, дело в том, что не все хозяева бизнеса имеют квалификацию дописывать/переделывать эти примеры под себя.
EXCEL тоже, своего рода, инструмент. Я видел просто умопомрачительные реализации учета "под себя" на нем. Но, опять-же, такое может позволить себе человек очень прилично владеющий этим инструментом.
(184) OBEH, На то оно и типовое решение, чтобы иметь возможность и обновлять ее, и дописывать хотелки клиента. И я ничего не изобрел, а лишь корректно дописываю. А если я скажу клиенту, что нельзя изменить и доработать типовое решение, так как это (181), то придет другой и сделает. Вроде так.
"Но, дело в том, что не все хозяева бизнеса имеют квалификацию дописывать/переделывать эти примеры под себя."
Хозяева не должны дописывать, а иметь возможность и желание платить за это.
"Но, дело в том, что не все хозяева бизнеса имеют квалификацию дописывать/переделывать эти примеры под себя."
Хозяева не должны дописывать, а иметь возможность и желание платить за это.
В УНФ "регламентированного учета"? В об УНФ или бухгалтерии? Если ВАМ нужно, чтобы клиент работал на типовых конфигурациях, то флаг ВАМ в руки. У меня же задача доработать конфигурацию, чтобы с ней было удобно в работе клиенту.
ВСем рекомендую УНФ. как перешёл не нарадуюсь. исопльзую банальную модель, весь управленческий учет веду в УНФ, а бухгалтерую выгружаю типовой выгрузкой для официального регламентированного учета в БУХ 3.0 просто данные ежемесячно. и проблем не знаю.
главное преимущество это построение универсальных отчетов без программистов
главное преимущество это построение универсальных отчетов без программистов
52 часа - это типовая бух+зуп+годовой ИТС, и это только один месяц. Вот тут я и говорю о целесообразности для клиента настолько доработанной конфигурации.
А главное, если завтра вы решите заняться чем то другим - кто будет обеспечивать стабильность ИС для бизнеса? Никто.
А главное, если завтра вы решите заняться чем то другим - кто будет обеспечивать стабильность ИС для бизнеса? Никто.
Мне нравится рассуждение человека за чужой бизнес. Для этого клиента, если я этого не сделаю, то он найдет СПЕЦИАЛИСТА. И я дешевле человека на ставке. Моя позиция проста. Делай то, что просят и не создавай проблем бизнесу. И всех это устроит. А РАЗГОВОРЫ ПРО ВОЗДУХ ПОЗВОЛЬТЕ ДЕЛАТЬ ФАНТАСТАМ. У меня есть опыт работы со связкой бух+ зуп + унф + подписка и видел реакции пользователей. Если ВЫ не делаете доработок конфигурации, то грузите клиента о дешевом варианте ВАШЕГО обслуживания и все будут счастливы, может быть.
Какое то у вас уязвленное чувство самолюбия. Вы на самом деле считаете, что доработка на 50 часов это верх мастерства? Я как раз смотрю на это, как на свой бизнес. ) Есть всегда два способа - как правильно, и как сказал клиент (и он не обязательно правильный). Если вы хороший специалист, то вы спросите зачем, предложите варианты использования схемы работы клиента на типовом функционале, потому что там на самом деле лучше для его бизнеса, а если вы просто хороший программист - то конечно вы честно будете программировать все то, что скажет клиент, считая, что делаете его бизнес лучше. Потом, когда вам надоест или у вас не будет хватать времени клиент придет к нам, и будет долго ругаться на то, что сейчас он работает через опу. Понимание таких вещей к вам придет после того, как будете реализовывать проекты, трудозатраты по которым начинаются от 1000 часов по доработке типового решения и ожидания по управлению рисками на таких проектах соответствующие. Давайте не будем спорить, у каждого свой опыт. И с точки зрения жизненного цикла компаний Адизеса, на каждом из этапов роста есть не только проблемы этапа, но и определенное восприятие "мира вокруг". Вые пока в одном месте, а мы прошли это лет 10 назад. :)
P.S. Конечно же мы говорим о работе специалистов с подтвержденными знаниями, у которых работают и типовые решения, и их связка между собой, а в случае необходимости эти же люди могут спроектировать и реализовать любой требуемый заказчику функционал.
P.S. Конечно же мы говорим о работе специалистов с подтвержденными знаниями, у которых работают и типовые решения, и их связка между собой, а в случае необходимости эти же люди могут спроектировать и реализовать любой требуемый заказчику функционал.
Чувство самолюбия в норме. С этим клиентом я работаю очень давно. На УНФ я его перевел с моей самописки на 7.7, где были выполнены все его хотелки. Вот на сомописках риски велики, согласен. Что такое 1000 часов доработок я знаю. А на 8 самописку писать не буду, а вот доработать функционал, но не превратить в самописку, а чтобы можно было обновлять - обязательно. Насчет "спросите и предложите", то это приходит с опытом, а его достаточно и я его использую. Если доработки правильно документировать, то и обновлять проблем нет. Последнее обновление на 1.5 прошло на ять, а вот предыдущее, с модальными формами, нужно было попотеть. Без проблем работал в связке БП + ЗУП. Для специалиста настроить обмен выполнимая задача, а вот когда это делает бухгалтер, то проблемы были. И доработки я делаю, когда не могу решить существующим функционалом. Поэтому первое требование для любого программиста хорошее знание конфигурации.
"Потом, когда вам надоест или у вас не будет хватать времени клиент придет к нам, и будет долго ругаться на то, что сейчас он работает через опу." - это про мальчика пришедшего с улицы и решившего заработать кучу бабок.
В УНФ доработок много. С точки зрения управления рисками критична подсистема "Зарплата"(из-за большого функционала). Но кто мешает ее просто не использовать, а пользоваться связкой с ЗУП?
P.S. Некоторое несоответствие ваших высказываний. Говорите о стандартном функционале и вдруг про доработки? Опыт имею с 2.0. Помните, что это было такое?
"Потом, когда вам надоест или у вас не будет хватать времени клиент придет к нам, и будет долго ругаться на то, что сейчас он работает через опу." - это про мальчика пришедшего с улицы и решившего заработать кучу бабок.
В УНФ доработок много. С точки зрения управления рисками критична подсистема "Зарплата"(из-за большого функционала). Но кто мешает ее просто не использовать, а пользоваться связкой с ЗУП?
P.S. Некоторое несоответствие ваших высказываний. Говорите о стандартном функционале и вдруг про доработки? Опыт имею с 2.0. Помните, что это было такое?
Где ВЫ увидели, что я это не делаю? Но если клиенту нужно, чтобы первичные документы готовились быстро, то моя задача это сделать. А я сделаю так, что если придется изменять функционал, то в крайнем случае и менее затрагивая конфигурацию. Подписка на события, внешние формы и т.д. А если затрагивает функционал, то с описанием.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот