Жизнь подталкивает к тому, чтобы выстроить бухгалтерский и налоговый учет на 1C, а управленческий и работу бизнесов (склады, закупки, продажи, частично производство, частично ТОРО) на SAP.
Естественно возникает вопрос по взаимодействию двух систем, причем скорее не технический (если ошибся веткой -- направьте в правильную) вопрос, а бизнесовый: какие проводки выгружаем, что вгружаем назад, как сворачиваем (или разворачиваем) и т.д., т.д.

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

Есть может быть у кого ссылки/доки на общие схемы/принципы выстраивания такого взаимодействия? Поиск по интернету дает технически детали как гонять данные, но не дает ответа _какие_ данные в такой ситуации гонять. Не хотелось бы изобретать велосипед (да еще может быть и малограмотный).

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

Спасибо.

Книга знаний: Перепроведение документов только по одному из учетов УУ, БУ, НУ

Имхо проще спросить на форуме саперов, есть ли опыт интеграции с 1С.
Саперов, работающих с 1С наверняка больше, чем адинэсников, работающих с сапом.

Как правило БУ - это часть УУ, поэтому в SAP придется выгружать ВСЮ информацию.
Разве что налоги не нужно будет выгружать.

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

Что выгружал я:
1C -> SAP: ОС, НМА, Материалы, Товары, Затраты, Взаиморасчеты с контрагентами и сотрами, Выручка.
SAP -> 1С: Банк и Касса.
Но направления обменом данными зависит от постановщиков задач (финансы, бухия). Программист не может определить "как должно быть".
Например банк с кассой можно было бы вести в 1С и выгружать в SAP.

2JustBeFree: ну то что всю (или почти всю) -- тут понятно. И скорее всего обмен будет двухсторонним (бизнеса работают в САПе, бухгалтерская первичка вводится в 1С, но и в САП она должна вернуться, чтобы сформировать УУ). Тут основной вопрос как выстроена логика таких гоняний. Потому что например в САПе корреспонденции счетов нет. Т.е. гонять тупо проводки наверное нельзя.

Вот например вы пишите, что гоняли 1с -> сап взаиморасчеты с контрагентами. Вы проводки выгоняли или в САПе генерили фактуры и выгоняли из 1С оплаты под эти фактуры?

(3) а налоги в УУ разве не нужно учитывать - те же самые затраты

2ASU: налоги в УУ безусловно надо учитывать. это одна из статей учета и финансовой модели. С налогами, кстати, наибольшая непонятка. Но тут скорее со стороны САПа. В САПе от хозяйственной деятельности в финансовом блоке генерятся проводки, в том числе и проводки по налогам. Но правильно (т.е. те, которые были уплачены) налоги расчитываются в 1С. И я что-то даже не представляю пока как правильные налоги вернуть потом в САП.

(4)
Это у них как подростковый онанизм - все это хоть раз делали, но никто не признается.

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

(6) если первичка будет вводиться в 1С, то гоняй из 1С в САП эту первичку.
обратно то для БУ ничего не нужно будет

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

(11) ну вот если взять конкретную цепочку прихода/выдачи материалов со склада.
В САПе логика процесса такая:
- завели заказ на поставку (делает закупщик)
- по заказу на поставку оприходовали _количественно_ на склад (делает кладовщик). Причем у САПа используется схема с транзитными счетами
Дебет-ПриходМатериала/ПриходСчета-Кредит. Т.е. просто оприходование на склад кредиторской задолжености не вызывает (Дебет закрывается на транзитный ПриходМатериала)
- по первичному бух.документу (делает бухгалтер) генерируется фактура (и происходит закрытие ПриходСчета - Кредит). Т.е. генерируется кредиторская задолженность
- затем вводится документ платежка, которая закрывает фактуру и соответственно кредиторскую задолженность.

Теперь мы подставляем в эту схему 1С и говорим, что с бух.первичкой у нас работают из него. Правильно ли я понимаю, что схема будет такая:
- все что до бух.документа по прежнему происходит в САПе, в 1Се не отражается и в бухучете нас не интересует (т.е. заказали у поставщика, оприходовали количественно и может быть даже выдали -- до бух.документа из 1С не видно)
- бухгалтер получает первичный документ и вводит его в 1С. в 1С появляется кредиторская задолженность перед поставщиком и появляется что-то на складе
- 1С через некую интеграцию отдаем первичный бух.документ в САП, в результате чего в САПе автоматически генерируется фактура к заказу на поставку
- бухгалтер в 1С производит оплату, чем закрывает кредиторскую задолженность
- факт оплаты транслируется из 1С в САП и в САПе этой оплатой закрывается ранее сгенерированная фактура
- состояние по бухгалтерии (1с) соответственно никогда не соответствует реальной жизни, но реальное состояние (САП) корректно закрывается фактическими оплатами

Так? Или я что-то упускаю, не правильно понимаю со стороны 1С?

тут еще возникают и технические моменты. а найду ли я какие-то поля в первичных документах 1С, чтобы там осадить информацию, какие первичные документы были сгенерированы на их основе потом в САПе (чтоб цепочку дальше правильно закрывать)

(14) dragonLight, здесь тебе детально никто ничего не напишет. Тебе нужно тесно работать с консультантом-сапером.

(15) мы тут получается сами себе консультанты :) со стороны САПа я вобщем-то картинку достаточно внятно представляю. Со стороны 1С не очень.

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

(15)
>Тебе нужно тесно работать с консультантом-сапером

Скорее уж, с двумя консультантами: и по SAP, и по 1С.


(16)
>со стороны САПа я вобщем-то картинку достаточно внятно представляю.
>Со стороны 1С не очень.

Здесь народ в основной массе наоборот: 1С "внятно представляет", а SAP - "не очень". Но в любом случае, как я уже сказал выше, надо садиться вдвоём и общаться.

>Возможно у кого есть общего характера схемки/диаграмки/доки по выстраиванию
>такого взаимодействия.

Наверное, надо всё-таки начать не с названия компаний (1C и SAP), а с используемых модулей и конфигураций. Тогда разговор был бы более предметный.

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


со стороны САП работают модуля MM (закупки, склады), ТОРО (еденицы оборудования, технические места, монтаж/демонтаж, сквозной учет серийных и инвентарных номеров), PS (система проектов), очень частично SD (сбыт) + завершается цепочка SD- сервисные заказы (ТОРО; у нас по сути некий эквивалент позаказного производства). На данных от PS и ТОРО работает планирование потребности материалов. Есть CO (контроллинг, по сути управленческая отчетность), но недовыстроенный. И FI + FI-AA (основные средства, причем в нашей реализации они опираются в том числе на данные из ТОРО; очень фондоемкое предприятие с адресами установки ОСов несколько тысяч (или даже десятков тысяч)) -- как бы есть, но бухгалтера на этот блок так и не перешли, ведут работу в другой системе (не 1С). Настроено в рамках одного юр.лица порядка 30 заводов, под каждым заводом с десяток складов и свой рабочий стафф. Бизнесовая деятельность ведется в рамках завода (и внутренний материальный поток между центральным и региональными), отчетность сводится как для всего юр.лица (соизмеримой заводу сущности со стороны 1С я как-то даже не понимаю что может быть). Юзеров по ERP-шному контуру (не включая бухгалтеров) около 70, будет более 150. По сбытовому -- плюс еще около двухсот.

Со стороны 1С однозначно видится модуль 1C:Зарплата + Кадры. А далее возможны варианты. Мне видится что еще нужен 1C:Бухгалтерия, предлагают рассмотреть 1С:УПП (все восьмерка). Вроде УПП уже умеет многое из того что мы наваяли на САПе. Но есть сомнения и количество пользователей откровенно не маленькое.

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

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


>Со стороны 1С однозначно видится модуль 1C:Зарплата + Кадры.

Абсолютно верно!


>А далее возможны варианты. Мне видится что еще нужен 1C:Бухгалтерия,

Опять-таки верно!

У 1С, по отношению к SAP, есть одно заведомое преимущество: игра на своём поле, а именно РОССИЙСКИЙ бухгалтерский и налоговый учет. Причем под "налоговым" учетом я имею ввиду не только Главу 25 НК, а вообще учет всех налогов по законодательству РФ: на прибыль, НДС, имущество, НДФЛ, ЕСН и пр.


>предлагают рассмотреть 1С:УПП (все восьмерка). Вроде УПП уже умеет многое из
>того что мы наваяли на САПе. Но есть сомнения и количество пользователей
>откровенно не маленькое.

Если оперативный учет в SAP, то не вижу смысла дублировать то же самое в УПП.

Я бы сделал шаг №1 такой: определил, что нужно вести изначально в 1С, и что туда перегружать из SAP для целей российского учета в соответствиями с требованиями законодательства. Как только контур нарисуется, выяснится, что УПП обладает избыточностью, и вам вполне хватит зарплаты и бухгалтерии.

Поле этого Шаг №2: определение тех данных, которые первоначально вводятся в 1С и, чтобы исключить двойной ручной ввод, подлежат пергрузке в SAP. Многие вещи наверняка можно будет "авизовками" перегрузить.

(19) Поговорили и направление в котором рассеивать туман становится понятным. Попробуем таким путем. Thanx

(20) Удачи! :)

P.S. А вообще задача интересная. В случае чего, стучись в аську - покумекаем вместе.

Пардон. А на кой хрен SAP, если все есть на 1С? Ну чего нельзя сделать в 1С из того, что как то колбасится, громоздко и тяжело в SAPе?
"Жизнь подталкивает"? Спецы, блин.
Если уж взяли SAP, зачем еще костыли приделывать.
(19,20)Похвалили друг друга прилюдно, повеселили.

Что интересно. Приобретают SAP и декларируют, что у них "SAP работает". Если копнуть не очень глубоко даже, можно увидеть, что SAP без костылей не может никак. Зачем тогда кормить, причем, очень даже недешево немцев и торгашей от SAP?

ша будет холивар.
(23) в 1С.Бухгалтерия есть ТОРО??

(24)Да, есть кофигурация, суть которой - всраивается в стандартную конфу БП. Чуток защищена. Но, сдается мне, реализация ТОРО своими силами не потребует и сотой доли того, что потребует SAP. Я имею ввиду, только модуль ТОРО.

(22)
>(19,20)Похвалили друг друга прилюдно, повеселили

Это к чему было? На предмет схамить или схохмить?


>А на кой хрен SAP, если все есть на 1С?

Вопрос, как я понял, вовсе не в том, что есть в 1С, и чего нет. Вопрос совсем в другом - в интеграции 1С и SAP, причем на условиях, что 1С можно покупать или не покупать, а SAP уже куплен и отказаться от него невозможно.

(26) ну вот, начинается.. "чуть чуть подкрутим, чуть чуть подправим")).. а если номенклатура 100 000 000 позиций, и количество пользователе от 1000 чел?..

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

(26)Пардон. Не сердись. Наболело. Действительно, у вас никуда не деться от костылей. Вы уже попали на гвозди. Просто получается, что для очередных пользователей будут лохотрон устраивать, что все в SAP есть и работает. Только гоните бабло вагонами.
По поводу "ша будет холивар". Хотел бы я поменять мнение в отношении SAP. Ну работал я с ним. Даже был у них в самой конторе в Германии SAP AG.  Кое что знаю не по наслышке.

(29) можно небольшое резюме по 29? т.е, все, кто покупает SAP - лохи в принципе??
PS интересно, если человек хочей майбах, а ему навязывают ваз (а мы салон поменяет, движок подкрутим, двери подкрасим) - какая будет реакция?..
При этом, ваз сам по себе, в своем сегмента очень даже хорош..

(29) Ну если "был в самой конторе", то твое заключение явно на экспертное тянет :)

Ок. Для начала, вопрос - Ты принимал решение? Или кто?

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

>Действительно, у вас никуда не деться от костылей. Вы уже попали на гвозди.

У кого у "вас"? Я лично с SAP никогда не работал. Клиенты мои - да. Но абсолютно все мои клиенты запретили интеграцию с 1С, мотивируя это стандартами корпоративной безопасности. Мне же лично задача интересна с точки зрения постановки - просто люблю нетривиальные задачи... будь то ИТ, психология или что-то ещё.

Что касается "попадания на бабло", то пару недель назад мне звонила одна западная контора и спрашивала, чем можно заменить R/3, т.к. поддержка во времена кризиса очень дорога. Некоторые, видимо, действительно, попали.

(31)Я к тому, что ничего интересного, кроме того, что работает очень головастая команда по впариванию этого продукта, ничего от спецов, разрабатывающих модули(а, скорее всего, наводящих в модулях рюшечки и фантики на софт, написанный боле 40 лет назад) не увидел.

Я, почему-то всегда думал, что те кто используют связку SAP + 1С бухгалтерия - просто перегружают в 1С проводки ручными операциями. И используют в 1С регламентную отчётность. В обратном направлении ничего не перегружают.

(35)А каким образом тогда синхронизировать данные в сап и 1С, если не перегружать туда-сюда-обратно?

ну, для 35 никакой синхронизации не нужно.. направление всегда в одну сторону

(36) в САП - всегда то что на самом деле, в 1С - то, что сдаётся в налоговую.
Синхронизация противопоказана

(37) Это тебе так кажется, что "направление всегда в одну сторону". Красиво жить захочется, придется подумать об синхронизации и обратно.
(33)Не некоторые "действительно, попали", а смею утверждать, многие.

(38)Так! Тогда, если "Синхронизация противопоказана", придется вести параллельно. Иногда, это надоедает. Начинают синхронизировать

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

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

Данные заведомо будут разными.

(22) Ну давайте я вам вопросов задам, возможно совершенно идиотских (т.к. 1С я знаю очень поверхностно.

1. Учет серийных и инвентарных номеров на протяжении всего жизненного цикла: купили - оприходовали с серийником + навесили инвентарник - выдали в монтаж - собрали нечто, сделали основное средство - что-то поломалось -- произвели замену в ОСе на работающую компоненту - неработующую вернули на склад - вернули поставщику - получили из ремонта - поставили в другое ОС - опять поломалось - вернули поставщику со словами "больше нам этого не надо" - поставщик вместо нового прислал отремонтированное старое. в 1С любых версий возможно?

2. Партионный учет и раздельная оценка. Причем под партией мы подразумеваем не документ поставки, а какие-то совершенно другие признаки. Банальный пример: по одной поставке закупили 20 барабанов медного кабеля. Каждый барабан -- это отдельная партия. Выдача в производство идет путем отмотки определенной длины кабеля с конкретного барабана (в себистоимость уходит по какой цене закупался вот этот конкретный барабан), из производства могут вернуться остатки, из которых на складе формируют новый барабан=новую партию. В складском учете мне надо видеть не просто что у меня есть 10 км кабеля, а что эти 10 км состоят из надцати партий-кусков по столько-то метров (вполне может оказаться, что будут куски по 200-300 метров, которые толком никуда не годные и которые проще списать на лом, чем держать на складе). Я умышленно не коснулся других признаков, которые могут быть у партии (а могут; типа срока годности)

3. Возможно ли передача материального потока с одного регионального склада на склад другого региона в два шага: отгрузили (стало в пути), приняли. Здесь прогон внутренний, меняются материальные запасы на складах, но не суммы по бухгалтерии. Я так предполагаю, что документ "внутренняя транспортировка" наваять можно и гонять через него. Но не уверен. Хочется видеть в отчетах что находится на складах, что находится в пути между ними

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

5. Возможно ли формирование особых запасов под что-то? Т.е. не просто резерв к складскому запасу. А жесткий резерв. Когда выдача на что-либо другое в принципе системой не допускается

6. На каком уровне блокируются работа с конкретным материалом при паралельной работе кучи сотрудников? У нас более 30 регионов, в каждом более 10 складов. В САПе блокируется только Завод-склад-материал-партия. Т.е. на другом заводе (или складе или даже другой партии) работа с отпуском и т.д. может продолжаться
6.1. Сколько юзеров система вобще тянет? (реально работающих юзеров)

7. Возможно ли в предлагаемом вами ТОРО на 1С вести сложную структуру технических мест? (ну как минимум иерархическую. на горизонтальные связи в принципе можно забить). Можно ли на тех.места и еденицы оборудования навешивать счетчкики (сколько часов отработало, сколько километров проехало). Можно ли увязать Основные Средсва и инфу, лежащую на ТОРО? Насколько вобще неразрывна цепочка Закупки-Склад-выдали на монтаж - получили ОС - демонтировали ОС - вернули в склад по документальному потоку и по цене, которая двигается вдоль цепочки? (даже то, что САПовские консультанты _обычно_ делают)

8. ППМ. Он реально рабочий? Можно ли на нем строить разные стратегии? Например, для одного региона выстроить стратегию: снабжать потребности с такого-то конкретного склада, если не хватает -- заказать на центральном складе; на центральном регионе сделать "снабжать с такого-то склада, если не хватает -- закупать". Сделать для какой-то группы материалов другую стратегию (все закупать локально). Полный ППМ, дельта-ППМ?

9. Можно ли описывать конфигурируемые материалы/продукты? Например, компьютер. А у него в свойствах: процессор (варианты выбора), память (объем), жесткий диск?

10. Есть ли штатные конфигурации, которые раздают наряды на работы, закрывают нормативные или фактические рабочие часы?

Вопросы не на пустом месте. Я на самом деле рассматриваю вариант съехать на УПП полностью. Но пока найденные ответы что-то не очень к этому вдохновляют

(39) Когда-то давно я оценивал статистику завершенных внедрений R/3 по СНГ. Где-то 5% получилось. Не думаю, что сейчас что-то сильно изменилось. По крайней мере, росссийский учет все в 1С ведут.

(41)К сожалению, не "все зависит от поставноки". Если бы все было так, SAP бы уже давно в заднице был.

(38)
(37) В САПе проводки не могут болтаться в воздухе. Чтобы в контроллинге правильно сформировалась управленческая отчетность, цепочка по FI должна быть завершена (хотя возможно именно в этом моменте я ошибаюсь)
Соответственно банальные вещи: заплатили поставщику -- надо закрыть кредиторскую задолженность и в 1С, и в САПе. Причем в САПе она таки может быть реальная (с учетом рибейтов, откатов то есть по нашему :), а в 1С нет, но правильная бухгалтерски.

(43)Есть постановка? Ну, или, хотя бы описалово того, чего хотите?

(43)
>Вопросы не на пустом месте. Я на самом деле рассматриваю вариант съехать на
>УПП полностью. Но пока найденные ответы что-то не очень к этому вдохновляют

Часть функционала в УПП есть. А часть однозначно придётся с нуля писать. Любой 1С-ник тебе скажет: "сделать можно", но не каждый реально сделает, т.к. постановка грамотная будет нужна. Кстати, провальных проектов УПП (именно без грамотной постановки) тоже хватает.

(43) хорошие вопросы.. хотя, хочеться сказать "не мешай холливару"))) частично есть в в типовых перечисленное
(44) а что такое "завершенное внедрение"?? в метологии сап вообще нету понятия "завершено", потому как после опытной эксплуатации наступает фаза "сопровождение".. т.е, в принципе проект не закрывается.

(49) "частично есть в в типовых перечисленное"
Я бы сказал - наночастично.

(49) Поймал на терминологии. :)

Я понимал под "завершением" стадию имплементации по первоначальному ТЗ, включая опытную эксплуатацию, за которой уже последует "сопровождение".

(47) Да. Она собственно исходным постингом крупными мазками обозначена

Есть САП, в котором работают бизнеса, т.е. осуществляется обычная операционная деятельность. Он реально есть с количеством пользователей более 200

Есть потребность формировать для акционеров и менеджмента управленческую отчетность по финансовой модели. Причем есть очень жесткая вводная, что управленческая отчетность должна формироваться так, чтобы не быть подверженой манипуляциям и корректировкам. Т.е. требуют аудиторский след (что САП обеспечивает, а 1С, насколько я знаю нет)

есть блок FI в САПе, с которым бухгалтерия не работает и скорее всего работать в силу реальности не будет. Есть задача перенести с существующей системы бух.учета (не САП, и не 1С) бух. и налоговый учет на 1С, где бухгалтерам будет дана воля поступать как им нужно для правильной отчетности.

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

Соответственно на сейчас надо на уровне логики понять что мы будем гонять между 1С и САПом, чтобы эти задачи были решены. Я знаю, что в этой задаче мы не одиноки и многие ее решали. Возможно есть какие-то общие соображения, известные грабли, схемы.

Вот насчет того, что "постановка грамотная будет нужна" совершенно согласен. И реализация грамотной постановки, на платформе 1С вполне реальная вещь.

(43) блин. Всё это есть в САПе ? Каким-то неполноценным себя чувствуешь ;)

>>7. Возможно ли в предлагаемом вами ТОРО на 1С вести сложную структуру
>>технических мест?

В качестве TOPO от 1С могла бы работать связка "Бизнес-плюс:Оборудование" и Рарус-Управление автотранспортом. Всё это можно поставить сверху на УПП.

>>(ну как минимум иерархическую. на горизонтальные связи в принципе можно забить).

в Бизнес-плюс это есть

>> Можно ли на тех.места и еденицы оборудования навешивать счетчкики (сколько
>>часов отработало, сколько километров проехало).

это есть в Рарус-УАТ

>>Можно ли увязать Основные Средсва и инфу, лежащую на ТОРО?

нет ((

>>Насколько вобще неразрывна цепочка Закупки-Склад-выдали на монтаж - получили
>>ОС - демонтировали ОС - вернули в склад по документальному потоку и по цене,
>>которая двигается вдоль цепочки? (даже то, что САПовские консультанты _обычно_
>>делают)

ничего такого не выйдет ((

(43) >>9. Можно ли описывать конфигурируемые материалы/продукты? Например,
>>компьютер. А у него в свойствах: процессор (варианты выбора), память (объем),
>>жесткий диск?

это есть в APPIUS-PDM. Тоже ставится сверху на УПП.

иех... все то есть у нас в 1С... если "чуть чуть" допилит, докрасить, донастроить.. но это чуть чуть.. а так все есть..

(56) Я тебя расстрою. В САПе тоже надо допилить, покрасить. Может быть не так низкоуровневно (там преднастроенного функционала тоже хватает). Но без АБАПа не обходимся. А кое-где и утыкается в ограничения по логике.

Все же, не советовал бы я делать ставку на УПП.
(56)К сожалению, все так и поступают - допилить, докрасить, донастроить. Инструмент 1С в этом плане развращает программеров. О постановке не думают

(54) есть. есть и больше. но финансы для наших реалий там реально плохо.

(43)
>>6.1. Сколько юзеров система вобще тянет? (реально работающих юзеров)

ну 200. Ну 500 (уже из области фантастики.)

В принципе, вероятно, на этом беседу можно закончить ? ))

(60) не. заканчивать рано :) я слышал, что делают распределенную БД. Центральную в центре и по своей инстанции на каждый филиал. А затем ночами гоняют репликации. Чем, я так понимаю, ограничения на объем обойти можно. Но насколько такие схемы жизнеспособны и есть ли практические реализации?

(57)В SAPe не только ограничения по логике))) Мы писали на нем. Синхронизация, млин, и все такое...Языку АБАП уже сто лет в обед

(43)

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

Касательно материалов - точно есть такое

(57) а я вот возьму,и не расстроюсь, потому как знаю))
(58) ну, постановка то не поможет, если нужно внедрять типовой, потому как постановку будет как раз таки базироваться на типовом решении, а не реалиях клиента (ну, этим не только 1С грешит.. это общий грех)
(61) органичения по числу подключений можно обойти, а вот террабайти инфы 1С вряд ли потянет..

(47)

>Т.е. требуют аудиторский след (что САП обеспечивает, а 1С, насколько я знаю
>нет)

Это всего лишь организационный вопрос.

>Соответственно на сейчас надо на уровне логики понять что мы будем гонять
>между 1С и САПом, чтобы эти задачи были решены. Я знаю, что в этой задаче мы
>не одиноки и многие ее решали. Возможно есть какие-то общие соображения,
>известные грабли, схемы.

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

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

(60)
>А затем ночами гоняют репликации. Но насколько такие схемы жизнеспособны и
>есть ли практические реализации?

Репликации с помощью "планов обмена" 1С - весьма ненадёжная вещь.

(65) правильно докладывали
(47) я не понимаю как организационно можно решить тот факт, что в САПе проведеные документы нельзя ни удалить, ни исправить. А только сторнировать. А в 1С можно и то, и другое. И если удалить еще можно на уровне прав запретить, то исправить? Особенно если 1С рассматривается именно ради такой возможности? Или в управленческом контуре можно запретить, а в бух. разрешить?

(61) 30 баз УПП, сливающихся в центральную - всё же, на грани фантастики.
Очень большие объёмы выгрузок, часто падать будет, много персонала для обслуживания потребует
А планы обмена к блокировкам приводят

(66) Тебе правильно докладывали. Но в 1С это можно организовать без проблем.

(64)Для типовой, мне кажется, постановка нужна еще больше. Мы, например, внедрили типовую, предварительно поработав над постановкой. Покувыркались. Но, работает. Другие уже месяцев 8 не могут внедрить.

(70) дарагой, я знаю, что можно организовать в 1с.. и знаю, что директор позовет и "попросит"  снять это самое ограничение. т.е, есть реальная возможность нае..ть собственников и инвесторов..

А вот 30 отдельно стоящих баз УПП, обменивающихся со своими близнецами в центре, которые уже каким-то образом консолидируются в другом продукте - уже немного более жизнеспособно.

Но.. потеря единой базы это такой шаг назад...

(73) межрегионгаз анонсировал вроде такую схему..

(72) Именно поэтому я не говорю, что это вопрос не технический или методологический, а именно организационный.

Мне кажется, терминал вполне нормально решает проблему, чтобы не заниматься синхронизацией.

(57) это правильно и в более маштабных размерах нужно дописывать, т.к. в иностранных прогах заложена совершенно другая логика. Нужно все модули переписывать или писать свои.

А про связь: я не понимаю зачем из бухи что-то переносить (ОС, НМА). Это чистая бухгалтерия. Торгуйте и закупайте и именно это переносите в бухню.

(76) у меня нет проблем с каналами связи (совсем нет). Но я опасаюсь, что на 200+ пользователей один 1С с сиквеловской базой тупо ляжет из-за блокировок.

(78)А что эти 200 пользователей будут делать? И будет ли это стандартная конфа?
Я, например, думаю, что у меня 400-450 пользователей выдержит. Конфа своя предполагается.

а вообще в одной базе 400 юзверов бывает? и они занимаются одним и тем же?

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

(79) мне нравиться, совершенно замечательная сейловая позиция)) "моя выдержит" и сразу "Конфа предполагается"))))...

(81) а зачем закуп тем кто будет заниматься ОС?

(82)Дело в том, что я знаю, что будет делаться в конфе. Поэтому такая уверенность.

(78)
(80), (81) вобще вопрос достаточно интересный. С одной стороны у меня ежемесячно более 60 тысяч счетов выписывается. С другой стороны готовятся они совершенно третьей программой и работа юзеров по ролям и функционально действительно разделена.

Задумался

(77) Ну ОС, например, например должен быть не только в бух.учете. В управленческом он тоже должен появиться. Потому что  по нему начисляется управленческая аммортизация. И эта аммортизация отличается от буховской как в способе/сумме, так и во времени с которого начинает считаться

Мда. В общем с распределёнкой непонятно, она может как снять проблему блокировок, так и усугубить её.

(85) да не думай особо. Если б ты планировал УПП без бухучёта - ещё были бы шансы, а если всё вместе - план счетов и регистр бухгалтерии это большой источник блокировок.

(84) не объять необъятное... в более менее серьезной конфигурации предвидеть все подводные камни и успешно их обойти в преемлемое время сложно, или же будет очень дорого.. отсюда: в какой то момент будет выбран компромиссный вариант тип "ладно, сегодня быстро и некачественно, а завтра исправлю". К сожалению, это завтра может и не наступить.. или перестанет быть актуальным..

(86) а зачем?

(89) А затем, что учетная политика по УУ может быть другая и более точно отражать суть вопроса, чем среднепотолочные нормы ПБУ.

(89) Зачем что? Аммортизация разная?
Затем что бух.учет требует вполне конкретных цифр и сроков в зависимости от типа ОС. А акционеры требуют совершенно других цифр. Им виднее зачем.
Более того, акционеры хотят начислять управленческую с момент когда куплено (даже еще не введено с точки зрения бизнеса). А бух.учет начинает как минимум с момента когда ОС сделано, а чаще с того момента, когда бухгалтеру лучше по другим соображениям

(90) да что вы. Амортизация она и в Африке амортизация.
(91) а то что вы говорите это все равно не в общем виде, а что-то свое. Дак и пишите свое тогда

а я, кстати, вообще не понимаю зачем в УПП есть управленческий учёт ОС. Если вспомнить, что в УПП нет управленческого финансового учёта. Нет баланса, отчёта о прибылях и убытках и вообще двойной записи.

(92) даже в регламентированном различаются: амортизация по БУ и НУ...

(92) Ага. Но в Африке СПИ отличается от СПИ, принятого Минфином.

(93) в УПП нет баланса и двойной записи? вот это неожиданная новость для меня. Т.е. если УПП и рассматривать, то только УПП + Бухгалтерия?

(96) Управленческого баланса нет.

(96) для управленческого учета нет.. для

(92) аммортизация имеет вполне конкретный управленческий смысл. Это потом она имеет бухгалтерский и налоговый смыл. То что я говорю не является чем-то не в общем виде. Оно как раз очень даже в общем. В САПе кстати на ОС то ли три, то ли четыре амортизации вести можно. Т.е. по ОСам задача как устроить взаимодействие 1С и САП как раз более менее понятна. Я привел как пример, что из 1с в САП тоже кое-чего возвращать придется

(хороший форум. кругом с таким же вопросом полное болото. тут же уже куча идей нарисовалась на проработать)

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

Так что надо ещё подумать о том, чтоб рядом поставить ещё одну УПП, в которой считать баланс на плане счетов БУ, или поставить сверху УПП Инталев:КФ или ИТАН:УБ.

Но тогда она точно умрёт от нагрузки. Га-ран-тировано !!! ))))

вах...

инталев не потянет и 10-ток пользователей...

но суть то остается на одной из территорий.
(94) да что вы.
(96) нет
(98) а вот это уже как я говорил "СВОЕ"
(99) а по закупу и продаже вообще проблем нет тогда.

(99) не, не надо возвращать. Щас ещё по стаканчику и мы откажемся от САП вообще )))


Кстати, вспомнил я одну вещь. Внезапно.

Я тут упомянул уже БизнесПлюс:Оборудование, Рарус:УАТ, Инталев:КФ и Аппиус:PDM

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

Такое приложение как нужно топикстартеру желательно разбить на три контура
1 товарный снабжение до ввода в эксплуатацию
2 эксплуатация и ремонты
3 регламентированный учет
причем вести разными базами. Такое деление позволяет вести учет в стандартных модулях. Типа 1 УТ с доделками. Под 2 есть несколько "отраслевых" (скорее специальных)
3 бух контур требует доработки БП или КОРП т.к. в учете связанном с ОС и инвентарем много заморочек осбенно если учет по нескольким ЮЛ сразу.
При переходе в учете из 1 в 2 производится сериализация в учете т.е. уровень уникальности повышается до серии. В 1 торговом контуре проще оперировать товаром даже без серийников т.е. серийники только по приходу расходу как в УТ 10.3
Речь не идет об интеграции 1с (регламентированный учет) и операционных баз а о постановке учета в целом как он построен по модулям.
Подобную задачу приходилось решать, там совсем не просто совместиться с регламентированным учетом.

(105) про 1С:Машиностроение я что-то слышал/читал. Помнится сплошной негатив. Но посмотрю еще. Хотя у нас и не машиностроение, просто некоторые процессы и особенности сходны

(0) v8: Интеграция САП и 1С  

Да масса вариантов. txt,xml,xls,ado. Что нравиться ? :)

+(108) Есть живой пример интреграции через обычный  ёхель по учету зарплаты. Как вариант ? :)

(106) а где формируется УУ в такой схеме?

(93) +1

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

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

(110) управленческий учет в 1 и 2 т.е. торговом и эксплуатационном контуре в 3 только итоги, без аналитики
деление на модули также показывает этапность внедрения от логистики к эксплуатации и потом уже в бухию
Решения одним куском в такой предметной области нет

(113) самое смешное, это единственное реально 100% работоспособное решение которое может предложить 1С.

А смешное - потому что чел в (43) заявил уровень, УЖЕ имеющийся в SAP.
или грустное...

(114) такая схеме НЕ реализована в сап, как минимум потому что
1.в эксплуатации много специфического
2.регламентированного учета под это в сап нет в готовом виде
ремонты в сап должны как то сочетаться с логистикой, фактически они независимы, да и отображение на фин бухгалтерию тоже независимое.
т.е. там тоже деление только в ОДНОЙ БД благо технология позволяет однако ТАМ СЛОЖНО (ДОРОГО) ВНОСИТЬ ИЗМЕНЕНИЯ

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

(115)
такая система _реализована_
регламентированный учет готовый есть, но он не удовлетворяет реалиям окружающего мира. Есть несколько банальных вещей, с которыми можно жить, но заставить с ними жить бухгалтеров можно только подписавшись, что от них перестанут требовать удерживать налоги на заданном уровне. Например, в САПе открыто только два периода. в то время как бухгалтера любят шаманить в конце квартала, т.е. им нужно три периода. Или желание придержать ввод ОСа по бухгалтерии, в то время как он реально в жизни произошел.
Так как никто (включая консультантов) не может посчитать на какой уровень налогов выйдет контора, если согласиться на особенности САПа, то никто (включая акционеров) тупо не рискнет переламывать бухгалтеров.

ТОРО с логистикой в САПе связано напрямую. Сервисный заказ (на ремонт например) -- имеет спеку что надо, генерирует потребность на склад. Если складского запаса недостаточно, ППМ сделает заявку. Далее закупка. Со склада списывается на конкретный сервисный заказ. В учете при списании на заказ пошло по соответствующим статьям. Я не вижу в чем там оно не связано.

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

(86) А что мешает покупать ОС в САПе, и выгружать потом это в бухгалтерию?

(119) ничего. С ОСами я примерно так и планирую поступать

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

(121) Хотя не, я еще забыл про налоги. Все налоги, очевидно, тоже в 1С считаться будут.

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

(122) угу.. а ПБУ 18 хде??

(123) тут правильнее сказать, что создать такой гиммор всем офисным работникам, чтоб вешались. потому что иначе что им в офисе делать? :)

(117) хе хе например комп сотрудника А предали сотруднику Б и они в разных ЮЛ интересно как это отразится в БУ
Или в составе АРМов может присутствовать оборудование списанное по БУ как обязательная составная часть.
Характеристики объетов при определении потребностей в эксплуатации могут отличаться от характеристик в торговом контуре. Понятно что связь объектов торгового контура востанавливается НО тут критерий простой Можно ли объект ОС со всей требухой сдать на склад и переместить в складском контуре как один девайс средствами модуля логистики. Думаю что нет

(124) Да, если для упр. отчетности это надо, то и его ...

это для БУ нужно)))...

(126) Во первых (и это мы уже прошли на собственном опыте) плохая идея объединять несколько юр.лиц в одну балансовую еденицу. В САПе настрогать столько балансовых едениц сколько нужно не составляет проблем. Управленческая отчетность сводится по контроллинговой еденицей (под одной КЕ столько БЕ сколько надо. Кстати, с устранением внутренних оборотов)

Т.е. передача от А Юрлицо1 на Б Юрлицо2 должно выглядеть как возврат компа от А на склад, продажа на ЮрЛицо2, выдача там сотруднику Б.

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

Можно ли объект ОС со всей требухой сдать на склад как один девайс -- сильно зависит от того, а делали ли вы до этого один девайс. Если вы вначале выдали кучу требухи (корпус, процессор, мат. плату), затем отработал производственный процесс сборки, в результате которого из требухи появился новый технический объект (компьютер в сборе), а затем на ОС вы поставили именно объект. То да. Сдать потом один объект можно. Если ОС у вас состоял из десяти объектов, то сдавать придется десять объектов. Хотя тут легким абаперством можно сделать и по другому (абаперство заключается в сокрытии от пользователя надцати фактических сдач и проведения их одним движениям). У нас такого вопроса исходя из учетной политики не возникало. Но решение на него есть

(97), (98) для бюджетирования вроде как есть план счетов, проводки и баланс.

(129) ну если поставить бизнес-плюс:оборудование, и добавить в карточку ОС ссылку на эту "ТОРОвскую инфо-структуру" (там это будет "Конфигурационная единица, которая включает в себя другие конфигурационные единицы"), то поведение 1С будет точно таким же.
На 08 счёте соберём из комплектухи одно ОС, в карточке ОС проставим ссылку на конфигурационную единицу и из требухи появится одно ОС, которое и примем к учёту на 01. При этом заглянув в конфигурационную единицу, увидем детали и на каком рабочем месте они стоят.

лёгким "одинэсерством" так же засовываем наполнение из накладной в конфигурационную единицу )) Кстати, если речь о компах, то оно может и само по сети подтянуть через WMI реальную конфигурацию

(130) Бюджетирование в УПП заточено под Группу компаний в целом (общекорпоративное), а по каждой компании Группы бюджетирования нет. :(

(0) интересно, а кто SAP изначально выбрал

(133) акционеры.

(93) Данная задача в УПП решается в подсистеме бюджетирование будут и баланс и ДДС и Прибыли/убытки

(132) ну... можно, например, проектами пожертвовать и завести организации как проекты.

(136) В 1С всё можно докрутить... или выкрутить. Вопрос-то в другом: как с без докруток или хотя бы с минимальными докрутками вопрос решить. Нам в своё время пришлось сильно УПП перелопачивать, чтобы сделать стандартную схему корпоративного бюджетирования с иерархией: компания -> группа.

Что касается предложенной Вами схемы, она вполне будет работать для девелоперов, у которых каждое "пятно" - отдельное юрлицо. Но даже у них такая схема поплывёт, как только надо будет общекорпоративные затраты распределять по проектам => проекты трогать не рекомендуется.

По большому счету, это вопрос изначальной ошибочной парадигмы, которая приводит к "доставанию правой рукой левого уха". Кстати, мне кажется, что это следствие недостаточности опыта работы 1С на серьёзном корпоративном уровне. А все западные ERP-системы (включая R/3, разумеется) изначально под это заточены - там корпоративная культура уже давным-давно сложилась.

Позвольте поинтересоваться - а почему в части технологии интеграции отдается предпочтение ETL перед ESB?

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