большая номенклатура и 1С

[Govorun]

В оптовой торговой фирме большая номенклатура ( порядка 20000 наименований) товаров. До сих пор складской учет велся в самописной программе, бухгалтерский - в Инфо-бухгалтере. Сложно, неудобно, медленно. Решили перейти на 1С.
Оптимальным вариантом было бы сочетание ТИС и бухгалтерии 7.7. Но...
С ТИС сама я серьезно не работала, программист утверждает, что при такой номенклатуре 1С будет работать медленнее черепахи, и рвется написать программу на основе 1С.
Вот у меня, чайника, и возникает ряд вопросов:
1. Прав ли программист в отношении скорости работы ТИС?
2. Возможен ли перенос в 1С Бухгалтерию не проводок, а самих документов (накладные, счета-фактуры) и экспорт из Бухгалтерии 7.7. проводок в ТИС либо в программу, созданную на платформе 1С бухгалтерии?
3. Как отразится большая номенклатура на скорости работы 1С Бухгалтерский учет? Ведь, по идее, скорость также резко снизится? А если да - то как этого избежать? Возможно ли вести только суммовой учет в бухгалтерии, если складской учет ведется полноценно??

Столько вопросов....
Может, я не совсем точно смогла их сформулировать...
ЛЮДИ, кто работает сбольшой номенклатурой - отзовитесь! Как вы выходите из положения?!

[Эльза]

Сталкивалась что с тем, что при большой номенклатуре в бухгалтерии ведется только суммовой учет.Если складской уче отлажен, то проблем быть не должно.Наверное это наилучший выход.

[training1C]

Исходное сообщение Govorun
В оптовой торговой фирме большая номенклатура ( порядка 20000 наименований) товаров. До сих пор складской учет велся в самописной программе, бухгалтерский - в Инфо-бухгалтере. Сложно, неудобно, медленно. Решили перейти на 1С.
Оптимальным вариантом было бы сочетание ТИС и бухгалтерии 7.7. Но...
С ТИС сама я серьезно не работала, программист утверждает, что при такой номенклатуре 1С будет работать медленнее черепахи, и рвется написать программу на основе 1С.
Вот у меня, чайника, и возникает ряд вопросов:
1. Прав ли программист в отношении скорости работы ТИС?

В отношении типовой ТиС программист прав. Дело в том, что в ТиС используется везде где только можно вывод остатков в списке по всем товарам, а можно и нужно внести некоторые изменения с тем, чтобы остаток выводился (вычислялся) только по текущей позиции. Это один момент. А вот кроме количества позиций в номенклатуре есть еще другие важные параметры, по которым можно в чем то определиться:
- Сколько пользователей будет в торговой базе одновременно колотить документы? сколько людей будут использовать данную базу для получения отчетов?
- сколько примерно в день вводится новых документов? 1-20; 50-100; 200-300; или под 500 и более?
-

2. Возможен ли перенос в 1С Бухгалтерию не проводок, а самих документов (накладные, счета-фактуры) и экспорт из Бухгалтерии 7.7. проводок в ТИС либо в программу, созданную на платформе 1С бухгалтерии?

Да возможен перенос документов, а не проводок, но в типовой этого нет, но можно сделать. Это не очень сложно.
А зачем из Бухгалтерии проводки кидать в Торговлю? Не совсем понятно. И кидать их именно в виде проводок нельзя, в торговле нет понятия "Проводка".

3. Как отразится большая номенклатура на скорости работы 1С Бухгалтерский учет? Ведь, по идее, скорость также резко снизится? А если да - то как этого избежать? Возможно ли вести только суммовой учет в бухгалтерии, если складской учет ведется полноценно??

Как отразится? Если будете вести количественный учет, то это отразится только на медленном (относительно0 построение оборотно-сальдовой ведомости по 41 счету и все.

Столько вопросов....
Может, я не совсем точно смогла их сформулировать...
ЛЮДИ, кто работает сбольшой номенклатурой - отзовитесь! Как вы выходите из положения?!

Стандратная связка: ТиС для количественного учета, выгрузка проводок из ТиС в Бухгалтерию и плюс Бухгалтерия от 1С.

[Fosihas]

Исходное сообщение Govorun
В оптовой торговой фирме большая номенклатура ( порядка 20000 наименований) товаров.

Вероятнее всего ваша номенклатура сократится.

С ТИС сама я серьезно не работала, программист утверждает, что при такой номенклатуре 1С будет работать медленнее черепахи, и рвется написать программу на основе 1С.

Если большой объем начинайте работать на SQL.

2. Возможен ли перенос в 1С Бухгалтерию не проводок, а самих документов (накладные, счета-фактуры) и экспорт из Бухгалтерии 7.7. проводок в ТИС либо в программу, созданную на платформе 1С бухгалтерии?

В нашей фирме торговля осуществляется из конфигурации, которая начала свое существование еще с 1С 7.5.
А бухгалтерия - это типовая, текущая, конфигурация.
В торговле осуществляются все продажи и ведется полный учет товаров(белый/черный) далее в конце месяца делается выгрузка, по определенным правилам. В Бухгалтерии создаются документ Операция. С данными кому и на какую сумму проданно.
В бухгалтерию заносятся официальные накладные, они очень часто отличаются от тех что приходят с товаром.
Всеже есть одно отличие от типовой созданы документы для списания товаром и материалов в конце месяца, сразу скопом и на определенную сумму.
И номенклатура торговли и бухгалтерии рознятся. И она в бухгалтерии в раза 6 меньше.

[Govorun]

training1C !

- Сколько пользователей будет в торговой базе одновременно колотить документы? сколько людей будут использовать данную базу для получения отчетов?
- сколько примерно в день вводится новых документов? 1-20; 50-100; 200-300; или под 500 и более?

Количество пользователей 5. Количество людей (в смысле - получающих отчеты) 2.

А зачем из Бухгалтерии проводки кидать в Торговлю? Не совсем понятно

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

Fosihas!
SQL, к сожалению, для меня нечто из области непостижимого и непознанного...
Но мне показалось, что у вас давно решена та проблема, которую я пока и сформулировать-то толком не в состоянии.
Не могли бы Вы поподробнее рассказать о решениях?
Как уменьшить номенклатуру в бухгалтерии? Объединить товары по определенным признакам? А в документе Операция присутствует ли признак количества?

[training1C]

Исходное сообщение Govorun
training1C !

Количество пользователей 5. Количество людей (в смысле - получающих отчеты) 2.

Ну если так мало - то никаких проблем.

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

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

Fosihas!
SQL, к сожалению, для меня нечто из области непостижимого и непознанного...
Но мне показалось, что у вас давно решена та проблема, которую я пока и сформулировать-то толком не в состоянии.
Не могли бы Вы поподробнее рассказать о решениях?
Как уменьшить номенклатуру в бухгалтерии? Объединить товары по определенным признакам? А в документе Операция присутствует ли признак количества? [/B]

Нет так страшен черт (SQL), как его малюют.
Правда SQL-версия дороже. Для вас, как для пользователя никакой разницы, голова пусть болит у программера.
А номенклатура сократится по естественной причине - у вас 20000 позиций на данный момент - из-за истории работы вашей организации, то есть там множество "мертвых" позиций, которыми вы например торговали последний раз в 1998 году :-). Возможно, что активных позиций то у вас всего 10000? А то еще и меньше. А может еще причина такого количества в том, что раньше если хотели вести ФИФО или ЛИФО, то на каждую новую партию товара по новой учетной цене заводили новую катрочку товара в программу. Может быть у вас такой случай?
ПРо количество документов не ответили. Дело в том, что если документов не много, то и все ваши сомнения и страхи - абсолютно напрасны.
Кстати чем торгуете? Есть ли черно-белый учет?

[Кира]

Рекомендую Вам перейти на БЭСТ4. Замечательно продуман блок учета товаров (аналогично с материалами). (!!!Существуют глюки FoxProшные и еще Клипперовские со старых времен, но это поправимо при корректной работе с программой). Рекомендую вести партионный учет по учетным ценам. Немного неудобно при оприходовании товаров, зато на выходе актуальная информация по себестоимости в реальном времени. Мои знакомые работают с БЭСТ4 много лет, а номенклатура у них поболе (парфюмерия, косметика и бытовая химия).

А вообще Вам стоит хорошенько продумать справочник групп товаров, чтобы было удобно и Вам и клиентам. Может, действительно, незачем так мельчить?

[Rustam]

Для параллельного ведения оперативного и бухгалтерского учета, мы объединили ТИС от ШтрихМ с текущей бухгалтерией.
Все документы по товару остались из ТиС, а касса и банк бухгалтерские. Соответственно в торговые документы добавили проводки, а в финансовые регистры.
Теперь можно получать отчеты как суммовые так и количественные.
Тут главное правильно написать проводки для торговых документов.
Конфигурация была создана для сети магазинов розничной продуктовой торговли.
Все рады все довольны.

[Govorun]

Количество вводимых документов порядка 100 ежедневно.
"Мертвых" позиций, как таковых, практически нет - все наименования вполне живые. Но бывает, что одно наименование проскочит в январе, а потом только в декабре. И черно-белый учет, разумеется, есть.
Товар - куча всяких разных микросхем, радиодеталей, инструментов и прочей пакости, названия которой я даже и не знаю. В прайсах они идут под жуткими названиями из десятков букв и цифр, но даже в одной группе разница цен значительна . Партионный учет не ведется, ведется только сортовой, потому что, как правило, товар не залеживается (в основном работа ведется по транзитной схеме). Да и списание в связи с этим происходит по себестоимости каждой единицы.
Предположим, я объединю их ... назову микросхемы... инструменты... Тогда как - приходовать по средней цене? А при возврате что тогда делать?

Ох, что-то я совсем запуталась...

[Аноним]

20000 - это не очень большая номенклатура, при небольшом количестве пользователей ТИС реально использовать в обычной DBF-версии, лучше с использовании серверной ОС Win 2000 Server вкупе c терминальными службами. Перенос проводок хороший специалист может настроить за небольшой срок. Переделывать ТИС особенно не придется, текущие остатки в формах документов и справочников получаются мгновенно, для отчетов же скорость не является критичным показателем, да и при ведении нормального учета, без зависших "минусов" и хронологически верным вводом первички, отчеты тоже не будут сильно "тормозить".

[Dracosha Andrew]

ОС Win 2000 Server вкупе c терминальными службами

Вот эта фраза говорит о НЕДОПУСТИМОСТИ использования 1С для данной задачи. Хотя бы потому, что это нестандартное решение. И отсутствия возможностей наращивания.

Мой совет - откажитесь от 1С и используйте полее продвинутые решения. Обязательно построенный по клиент-серверной технологии. Иначе через год почувствуете, что я был прав.

Доказательства:
20000 наименований и 100 документов в день (по 5-10 строк) плюс счета-фактуры и прочее плюс аналитика породят где-то 3-5 тыс изменений строк в день во внутренних таблицах, что для DBF структуры опасно. Это просто очень большой объем. А если изменение задним числом??
Так что как-минимум клиент-серверная версия нужна.

Кстати, бухгатерию на 1С можете оставить Она уже итогами пользуется, так что тут не так все критично.

[Тот]

Странное какое-то обсуждение... 20.000...
У Wintera в Питере вроде уж за 1.000.000 перевалило...
Единственное - хочу поддержать training1c и добавить - пригласите хорошего консультанта и на месте разберитесь.
Задача не относится к "супер" - типа описанной выше. Ничего особенного.

[training1C]

Исходное сообщение Тот
Странное какое-то обсуждение... 20.000...
У Wintera в Питере вроде уж за 1.000.000 перевалило...
Единственное - хочу поддержать training1c и добавить - пригласите хорошего консультанта и на месте разберитесь.
Задача не относится к "супер" - типа описанной выше. Ничего особенного.

Так у них вроде бы программист есть. Просто Govorun сомневается и решила дополнительно информацию собрать.

К Дракоше: Терминальное решение - один из самых оптимальных путей для масштабирования. ПО поводу стандратности или нет. Так к терминальному решению это никакого отношения не имеет - 1С работает полностью в штатном режиме, только на более продвинутой технологии.
Получаетяс если 1С придумали во времена 10Мб/с, то ей всю жизнь на такой сети работать?

[Dracosha Andrew]

Терминальное решение - один из самых оптимальных путей для масштабирования

Только не от M$, дяди Билла и компании.
Не спорю Terminal Server штука хорошая, но для устойчивой работы одновременно 7 пользователей потребуется (под 1С) железяка как на 30-100 пользователей, например под нормальное решение MS SQL (клиент - серверное). Моё мнение - современный "стандартный" софт не соответствует требованиям действительности. Если бы автомобилестроение развивалось бы таки образом, то сейчас БМВ был бы на паровом двигателе с ядерным реактором

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

Кстати, с Рождеством!!!!

[БТР]

Сначала ответ по теме.
Во-первых, ничего особенно-критичного в 20000 единиц номенклатуры само по себе нет. При корректной организации групп номенклатуры даже типовая ТиС без единой доработки будет летать. Разумеется, не глядя на ситуацию никаких окончательных выводов делать не буду и вам, категорически, не советую. Объяснюсь. Давайте взвесим цену вопроса.
Сколько человек у вас на фирме зависят от планируемой системы? 3? 5? 7? 10? Сколько денег они получат за три года? Разделим данную цифру на 10 и получим условную стоимость хорошего инструмента для их работы.
Минимальная стоимость SQL+Terminal решения на платформе 1С, с учетом внедрения и обслуживания в течение 3-х лет выльется в 20-50 тысяч долларов. Обычно больше. Для среднего производственно-торгового предприятия, система на 20 пользователей за три года организует прямых и косвенных затрат около 120 тысяч долларов. Это статистика управленческого учета 5 лично мне известных предприятий.
А чтобы в шоке не слишком слушать тех, кто кричит: "ага, я же говорил, берите сразу серьезную систему", замечу, что на аналогичном предприятии за три года использования Scala было в совокупности затрачено немногим больше миллиона долларов.
Может быть стоит подумать о том, чтобы пригласить специалиста с опытом для проведения анализа и постановки задачи? Неделя такого специалиста от фирмы вряд ли вылезет за тысячу долларов, а если он свободный, то и вряд ли большее 300. Достаточно достоверный анализ, на основании которого можно принимать серьезное решение можно сделать уже за одну неделю. А самая серьезная постановка задачи потребует не больше месяца. Есть неплохой способ рассчитать необходимый срок и стоимость обследования.
(24 часа подготовки и согласования документов + 3 часа x количество топ-менеджеров + 1 час х количество менеджеров среднего звена+0,1 час x общее количество прямых пользователей системы + 0,3 час x общее количество косвенных пользователей системы/получателей информации/поставщиков информации) / 25 активных часов в неделю = срок обследования,
срок округленный до календарной недели х стоимость специалиста за одну неделю = затраты на постановку задачи и выработку концепции автоматизации и реинжиниринга.
Иначе все что вы получите - это флейм на форуме. Попробуйте получить рецепт на лекарство от сотни врачей по переписке. От чего вас только не будут лечить...
А теперь, что касается терминальных решений.
Чтобы не было споров, сразу скажу, на основании опыта и неоднократного: обыкновенный однопроцессорный Intel Pentium II 850 МГц сервер с 512 Мб памяти (жесткие диски здесь не имеют значения) выдерживает без больших тормозов 15 сессей 1С: Предприятия 7.7. Это факт.
Реально же работающие системы (правда на базе переделанной конфигурации под заказчика, с очень серьезной оптимизацией как архитектуры, так и отдельных проблемных участков системы) на ферме из трех двухпроцессорных гигагерцовых серверов с 2 Гб памяти на борту (каждый из них терминальный+SQL) тянет 170 пользователей. Возможно, тянет и больше - проверить не удалось. Те же 60 пользователей которые работают в системе постоянно довольны весьма и весьма, при том, что параллельно выполняются всегда порядка 20 "виртуальных" пользователей-роботов, обеспечивающих регламентные процедуры и автоматизацию некоторых рутинных операций.

[Dracosha Andrew]

Чтобы не было споров, сразу скажу, на основании опыта и неоднократного: обыкновенный однопроцессорный Intel Pentium II 850 МГц сервер с 512 Мб памяти (жесткие диски здесь не имеют значения) выдерживает без больших тормозов 15 сессей 1С: Предприятия 7.7. Это факт.

1.К сожалению это все половинчатая информация.
Сколько документов в деньь вводиться? Сколько связей образуется? Каков ежедневный прирост базы?? Ну и так далее.

2.А вообще согласен - бессмысленно обсуждать, т.к. всего нам никто не скажет.

3.Не в обиду - то что у вас реализовано на 1С стоит в 2 раза дороже клиент-серверной системы среднего уровня. Но у вашего решения есть один громаднейший плюс - любая другая система потребует рабочие станции посильнее, чем 486/8MRAM, а в вашем случае этого вполне достаточно.