нежные какие)). у меня например шока не было, было не обычно отсутствие привичных проводок дебет-кредит, дебет-кредит.... дебет-кредит, так как в SAP двойная запись бух.учете реализуются на уровне документа. Вот и получается при отражении реализации 10позиций товара с НДС в 1С по Дб.62сч пройдет 20строк, по счету выручки 10 и по НДС 10. А в SAP более логично, документ один, и задолженность у покупателя одна строка, НДС тоже один итоговый, выручка 10позиций со сбытовой аналитикой. По мне так красиво и удобней в SAP))
У меня по тем проектам где довелось участвовать сложилось впечатление, что как только что то выходит за рамки модулей SAP все сразу начинают натягивать сову на глобус метаться и искать к чему бы прицепить функционал, поскольку Z подсистемы писать очень не хочется. ABAP не тянет на rapid application development
Ну так и 1С из коробки будет работать только на типовых процессах, а если что то уникальное то разработка. По скорости разработки тут как посмотреть, если "херак херак и в продакшен" то да, с 1С не сравнить, в SAP так не принято, используют трехуровневую среду - и DEV в Тест, и только если пользователь дал отмашку изменение полетело в Прод. Полетело опять же только изменение (Транспортная система), не нужно выгонять всех пользователей чтобы конфигурацию обновить. Что касаемо скорости разработки, то тут от квалификации исполнителей зависит. И опять же, в 1С принято что разработчик сам "и жнец и жрец и на дуде игрец" (программист и бизнас-аналитик и тестер в одном лице) контактирует с пользователем-заказчиком напрямую. А в SAP как то сложилось разделение. Хотя отдельных тестировщиков могут позволить себе лишь очень жирные клиенты)) то разработчик отделен от аналитика в 99% Если забить на бюрократию, и разработчик-аналитик в одном лице, то на ABAP можно сделать Z побыстрее чем в 1С)))
Я имею ввиду конкретно итоги по аналитике. Итоги по счетам конечно в SAP будут, и возможно по подмодулям (типа ос нма) . А если Вы добавили Z_справочник откуда им взяться? В Sap появилась универсальная система хранения итогов на уровне платформы?
в древних версиях до SAP ERP никак не возьмется, а c выходом SAP ERP появилась ГИБКАЯ Главная книга, включаешь в блок контировки три новых поля ZSUBKONTO1, ZSUBKONTO2, ZSUBKONTO3 и получаешь 1С ))) Будут итоги в комбинации с тем что прогнули)) в этой Гибкой книге.
С появлением HANA(поколоночное хранение) и S/4 действительно появился УНИВЕРСАЛЬНЫЙ журнал ACDOCА.
В 1С хранение итогов по любым субконто решено на уровне платформы, равно как и по любым регистрам которые изобретут по ходу проекта
Ну вот и в S/4 тоже на уровне платформы. Баланс дергается по любой комбинации признаков.
И добавлю, субконто в 1С это более универсальный объект туда можно легко прицепить любой справочник или вид документа или даже составной тип.
Потому что идеология разная. 1С пляшет от бух.проводки. А в SAP со стороны хоз.операций. 1С - проводка по 10сч., и к ней цепляем материал, склад, а SAP - движение по материалу(завод, склад,стелаж, полка и т.д), а в бух.учет(FI) пападает только то что нужно, например запись по 10сч, причем может быть свернуто итогом. Ну и типичный пример - учет основных средств, тысячи(сотни тысяч) объектов ОС, амортизация - расчеты с аналитикой в FI-AA, а по бух.счету в кредит 02сч будет одна единственная итоговая запись. Забыл про паралельный учет - будет по документу в каждую книгу( локальный бух.учет, МСФО, еще книгу налогового учета незабываем). и в каждой свои суммы.
также дебиторка и кредиторка должны быть в разрезе VIN .
Обычно в разрезе договоров, но не суть, в SAP для этого есть поле Присвоение, которое будет заполнено как надо, договор/VIN/Фрахт/что угодно. Ну и для реформации запуск раз в месяц одной программы, чтобы в балансе прошла реклассификация.
Но клиенты не знают, что при объемах по паре миллионов транзакций в день, на эту таблицу не будет распространятся подсистема хранения промежуточных итогов
Почему не будет? Будет. В старых версиях нужны были некоторые танцы с бубном, в S/4 с этим проще. Другое дело что не всегда это нужно, смотреть нужно какая цель преследуется. Возможно глупо пихать в финансы доп. аналитику, которая более логична в закупках\производтстве или сбыте. Потому как SAP это не поставил коробку и работай с тремя субконто как хочешь, а нормальное проектирование и реализация процессов бизнеса.
каким боком реформация баланса к аналитическим признакам? Разный порядок признания расходов это паралельные ФУ, а не УУ. В SAP для этого дела отдельные регистры ФУ предусмотрены - в локальной книге не будет движения, а по МФСО например отразят Accrual на то же СО-заказ (VIN) раз авто уже вот вот гарантировано(мамой клянусь) приедет, хотя никаких формальных документов на это нет.
HANA это база данных, придумали её чтобы быстро делать выборки по произвольным наборам признаков.
Мало того что есть в коробке? ну создайте Z-таблицу и настройте чтобы значение отражалось/выбиралось в бух.документе. Будет 100% аналог 1Совского субконто (таблица и возможность впихнуть значение ключа из неё в бух.проводку)
вот в этом у SAP существенное приемущество - наличие транспортной системы, обновляются только те объекты какие указаны в транспортном запросе. нет такого понятие как конфигурация, которая несется целиком, обновляется целиком. Ну и второй существенный плюс - система полномочий/авторизаций, когда посторонный бухгалтер физически не сможет открыть документы и отчеты по начислению зарплаты. Проводка по 70сч. будет вообще одной строкой, но и её не покажут, ибо нефик)) Сотрудники кроме зарплаты в командировки ездят, тоже будет ограничение, хоть движение по 71сч идет с аналитикой по сотруднику, но видеть ее будет только тот кому позволено.
Именно в ОПЭ полезут все тараканы, и Вы узнаете все что клиенты не рассказали на AS IS,
То что не расказали на AS IS должно вылезти на TO BE и на функциональном тестировании. В крайнем случае на интеграционном. На каждом этапе ключевые пользователи от клиента ставят свою подпись, да сейчас работает так(AS IS), да согласен будет так(TO BE), проверили действительно так (функциональный и интеграционный тест). Вылезло на ОПЭ? - нет проблем, это доп.работы, какая то часть реализуется в рамках бюджета данного этапа(если некорректно работает то что на тестах было норм), а сверх хотелки фиксируются как доп.работы. Это как со стройкой, построили, и если что то криво получилось, то переделывают за свой счет, а если у клиента появилось желание доп.окно в стену прорубить, или наоборот замуровать, то любой каприз за отдельные деньги.
В 1С всё вылезает на ОПЭ? ну логично - коробку типовую поставили, а далее в продуктиве напильником)))
управленческий учет это и есть аналитика фин.учета. фин.учет - баланс и опу, то что требует законодательство, а детализация прибыли по VIN или еще по каким признакам это управленческий учет, чтобы принять управленческое решение - этими корчами торгуем, а этими прекращаем. СО-заказ - это один из объектов, который можно представить как аналог субконто в 1C, а есть еще СПП-элементы, если нужен учет чего либо с древовидной структурой, например какой либо проект детализируется по элементам. Т.е. тоже вполне себе субконто из коробки без Z))
Ну это возможно если вообще не рассчитывать на обновления текущей версии SAP
Это никак не связано. В данном случае судя по описанию скопировали стандартное приложение WorkManager и навешали на свой Z доп.пожелания пользователей. Обновления если придут, то затронут стандартный WorkManager, а свое как работало так и будет работать, изменяясь своими разработчиками под новые потребности своего бизнеса, а не то как SAP решил обновить. Как будто в 1С не так? есть защищенная вендором конфигурация, а есть собственные обработки...
Но вот если клиент захочет чтото нетрадиционное например. Учет по ценным бумагам а там ISIN 12 символов, Вы ему модуль CFM предложите. А если он охренеет от цены лицензий на него, тогда какой выход? В эксель
Ну хорошо, а если автодилер захочет по VIN аналитику вести, а у них только так
Или трейдеры горючего по судам фрахт отслеживать со всеми затратами на фрахт
Нету модуля в SAP? Что тогда к плану счетов прикручивать?
Тогда прикручивается к примеру CO-заказ. И там тебе хватит и символов и VIN аналитика и прочие хотелки.
Ну все верно, на то и консультанты, чтобы консультировать на базе собственного опыта. А внутренняя команда (как от IT, так и от бизнеса ключевые) будет обучаться ими, только не в конце, чтобы формально передать систему и свалить, а первым этапом - "Обучение", месяц-два за глаза. Затем совместное проектирование, консультаны подсказывают как лучше. Затем совместные настройки с протоколированием сделанного, консультанты подсказывают что и как, IT делают, key-юзеры сами готовят сценарии тестирования(они лучше знаю что нужно проверить для покрытия требований бизнеса) сами же и гоняют функционаьные тесты, сразу видя возможные косяки, не откладывая на потом. К итеграционному тестированию не должно остаться никаких критичных недоделок, а к ОПЭ могут остаться только "бантики", не затрагивающие функционал. Да, обучение пользователей перед ОПЭ тоже должны делать ключевые внутренней команды, а не консультанты. ОПЭ - как говориться - "поехали", и это не опытный тест, это опытноПРОДУКТИВНАЯ - основная нагрузка на внутреннюю команду поддержки, консультанты в помощь на второй линии. Период закрыли, отчетность, инвентаризация... всё норм? - подписали акт пошли в прод без слова опыт. Консультанты? - на 3 линии поддержки, проект завершен, остались гарантийные обязательства + отдельный договор сопровождения на 3лини.
в SAP для этой цели есть такой обязательный признак как вид документа. Всего два символа и сразу понятно где задолженность поставщику, а где начисленная зряплата. Ну и костыль не отменён, кто то всё еще пользуется. Причем работает не так - если шаблон не введен, то корреспонденция не сформируется АВТОМАТИЧЕСКИ и будет список документов для анализа причины, может действительно новая операция, а может накосячил кто. Да, ошибка по корреспонденции сразу прилетит на почту ответсвенному за неё, не дожидаясь времени подготовки отчетности. Вводи новый шаблон, чтобы не повторялось в будущем, либо разбери ВРУЧНУЮ как считаешь правильным. Это к тому что вы ошибаетесь в утверждении "не смог ввести".
Ключевое - Сегежа не отказывается от SAP, а лишь недовольна реализацией - халтурой в конце проекта. По суду деньги на "финишную отделку" не доплатили, посчитали не за что, и пустили на доработку недостатков собственными силами. Ну а моё имхо, и изначально нужно было внедрять самостоятельно, с обучения внутренней проектной команды, и привлечения при необходимости со стороны действительно КОНСУЛЬТАНТОВ, а не внедренцев.
все верно, в РФ есть рекомендованный план счетов, вот SAP и сдалал в исходной коробке CARU и настроил под него все типовые операции. Так жи и с МСФО, обязательности нет, тем более в коробке предлагается то что есть. Хочешь добавить что то своё, нет проблем. У кого-то зоопарк екселей? ну так кто то просто "не умеет готовить". Что касаемо своего плана счетов, так повторюсь - причина в том что 1Совские субконто в SAP это часть GL-счета, вот и получается у каждого свой план счетов под конкретный бизнес компании, изначально выкидвают лишнее и вставляют своё. Далее всё отличие от 1С - одни при необходимости новое субконто вводят, вторые новый счет, 10значный, где первые 4 цифры - рекомендованный в РФ счет.субсчет, а остальные 6 - аналитика(аля субконто)
такого никто не делает, потому что это тупо выделять на HR/PY отдельный мандант в той же системе, так как цель секретности не выполняется, вернее под такой же угрозой, как если бы всё крутилось в одном манданте(разграничивается полномочиями на доступ). Реальная практика - выделение HCМ в отдельной системе, куда в принципе у посторонних доступа нет. Посторонние, это масса админов, разработчиков, консультантов, которые "знаючи" могут похулюганить и подсмотреть то что им не положено видеть, имея просто легальный доступ в систему, даже в другой мандант. Но это детали, смысл был в различии понятия модулей - в 1С ЗиК это изначально отдельная система и в ней невозможен бух.учет, производство, торговля, а в SAP же это искуственное выделение с целью секретности, а по сути это будут физически две идентичных системы.
И он кардинально разный, а про стандарты МСФО я вообще молчу
И что не так с МСФО в SAP? вполне нормально проводятся документы параллельно как в книгу локального учета так и в МФСО, в одну по счетам и правилам российской бухгалтерии, во вторую по IFRS...валюты учета могут быть так же разные, c разными переоценками по разным курсам, учет ОСов аналогично, где то это актив с последующей амортизацией, а где то сразу ушли на косвенные расходы. Accruals тоже без проблем ведутся в IFRS книге, не пугая локальных бухгалтеров, они их даже не видят.
Ой ужас ужас, отдельный GL-счет, нет бы как в 1С лепить комбинацией счет.субсчет.субконто. Ой нету корреспонденции счетов, ага и соответсвенно журнал-ордерной формы тоже нет, ужас ужас. Но работают рос.компании в SAP как то, давно уже забив на саповский костыль по реализации этой дурости прошлого века, когда учет велся в "амбарных книгах" ввиду отсутствия автоматизации.
модуля? вы ошибаетесь со смыслом определения модулей. Бухгалтерия(FI), Управленческий учет(СО), Закупки/Склад(ММ), Сбыт(SD), Производство(PP), ТОРО(PM), ЗарплатаКадры(НСМ) это всё единая система, модули не живут отдельно. Можно конечно HCМ сделать на отдельном сервере, спрятать в бронированной комнате, что бы никто посторонний не подсмотрел размер зарплаты у коллеги, но это опция, т.к весь функционал в одной коробке. Как отдельные модули можно считать разные BW и прочее, живущее как правило отдельно.
По поводу можно ли использовать сразу лишь сменив название и адрес организации? - МОЖНО, если у вас организация с одним заводом и складом)), но такие не покупают SAP. Это все же система для корпораций, иерархическую оргструктуру нужно создавать... А так да, ну будет с кодом RU01 реальная компания, план счетов преднастроенный CARU, один завод RU01 c одним складом 0001. Вводи начальные остатки, и поехали - закупай, производи, продавай, по счетам бух.учета проводится, НДС считается, нормативная отчетность в ACR попадает. ОСы тоже пренднастроены.
Почему так не делают уже написал - потому что у корпорации несколько компаний, в разных странах, где валюты учета разные, план счетов бухгалтерии разный, а задача построить корпоративную отчетность по единым корпоративным правилам, чтобы это все работало онлайн в единой системе. Тут без проектирования и тщательной ОПЭ никуда. Санкции? SAP ушел? ну были лицензии на юр.лице из РФ, стали на юр.лице из Казахстана и нет санкций. А можно и вообще забить на вендора, ушел и ладно, экономия на лицензионных отчислениях, платить эти деньги местным за локализацию, тому же ЛАБ СП. Чем не импортозамещение?)))
именно так вражеский спираченный == трофейный и после кидкаь сапов и прочих ораклов нужен был указ не только об импортозамещении, то и об этом трофейном софте. легальное каперство)))
нежные какие)). у меня например шока не было, было не обычно отсутствие привичных проводок дебет-кредит, дебет-кредит.... дебет-кредит, так как в SAP двойная запись бух.учете реализуются на уровне документа. Вот и получается при отражении реализации 10позиций товара с НДС в 1С по Дб.62сч пройдет 20строк, по счету выручки 10 и по НДС 10.
А в SAP более логично, документ один, и задолженность у покупателя одна строка, НДС тоже один итоговый, выручка 10позиций со сбытовой аналитикой.
По мне так красиво и удобней в SAP))
Ну так и 1С из коробки будет работать только на типовых процессах, а если что то уникальное то разработка.
По скорости разработки тут как посмотреть, если "херак херак и в продакшен" то да, с 1С не сравнить, в SAP так не принято, используют трехуровневую среду - и DEV в Тест, и только если пользователь дал отмашку изменение полетело в Прод. Полетело опять же только изменение (Транспортная система), не нужно выгонять всех пользователей чтобы конфигурацию обновить.
Что касаемо скорости разработки, то тут от квалификации исполнителей зависит. И опять же, в 1С принято что разработчик сам "и жнец и жрец и на дуде игрец" (программист и бизнас-аналитик и тестер в одном лице) контактирует с пользователем-заказчиком напрямую. А в SAP как то сложилось разделение. Хотя отдельных тестировщиков могут позволить себе лишь очень жирные клиенты)) то разработчик отделен от аналитика в 99%
Если забить на бюрократию, и разработчик-аналитик в одном лице, то на ABAP можно сделать Z побыстрее чем в 1С)))
в древних версиях до SAP ERP никак не возьмется, а c выходом SAP ERP появилась ГИБКАЯ Главная книга, включаешь в блок контировки три новых поля ZSUBKONTO1, ZSUBKONTO2, ZSUBKONTO3 и получаешь 1С ))) Будут итоги в комбинации с тем что прогнули)) в этой Гибкой книге.
С появлением HANA(поколоночное хранение) и S/4 действительно появился УНИВЕРСАЛЬНЫЙ журнал ACDOCА.
Ну вот и в S/4 тоже на уровне платформы. Баланс дергается по любой комбинации признаков.
Потому что идеология разная. 1С пляшет от бух.проводки. А в SAP со стороны хоз.операций. 1С - проводка по 10сч., и к ней цепляем материал, склад, а SAP - движение по материалу(завод, склад,стелаж, полка и т.д), а в бух.учет(FI) пападает только то что нужно, например запись по 10сч, причем может быть свернуто итогом. Ну и типичный пример - учет основных средств, тысячи(сотни тысяч) объектов ОС, амортизация - расчеты с аналитикой в FI-AA, а по бух.счету в кредит 02сч будет одна единственная итоговая запись. Забыл про паралельный учет - будет по документу в каждую книгу( локальный бух.учет, МСФО, еще книгу налогового учета незабываем). и в каждой свои суммы.
Обычно в разрезе договоров, но не суть, в SAP для этого есть поле Присвоение, которое будет заполнено как надо, договор/VIN/Фрахт/что угодно. Ну и для реформации запуск раз в месяц одной программы, чтобы в балансе прошла реклассификация.
Почему не будет? Будет. В старых версиях нужны были некоторые танцы с бубном, в S/4 с этим проще. Другое дело что не всегда это нужно, смотреть нужно какая цель преследуется. Возможно глупо пихать в финансы доп. аналитику, которая более логична в закупках\производтстве или сбыте. Потому как SAP это не поставил коробку и работай с тремя субконто как хочешь, а нормальное проектирование и реализация процессов бизнеса.
каким боком реформация баланса к аналитическим признакам?
Разный порядок признания расходов это паралельные ФУ, а не УУ. В SAP для этого дела отдельные регистры ФУ предусмотрены - в локальной книге не будет движения, а по МФСО например отразят Accrual на то же СО-заказ (VIN) раз авто уже вот вот гарантировано(мамой клянусь) приедет, хотя никаких формальных документов на это нет.
HANA это база данных, придумали её чтобы быстро делать выборки по произвольным наборам признаков.
Мало того что есть в коробке? ну создайте Z-таблицу и настройте чтобы значение отражалось/выбиралось в бух.документе. Будет 100% аналог 1Совского субконто (таблица и возможность впихнуть значение ключа из неё в бух.проводку)
вот в этом у SAP существенное приемущество - наличие транспортной системы, обновляются только те объекты какие указаны в транспортном запросе. нет такого понятие как конфигурация, которая несется целиком, обновляется целиком.
Ну и второй существенный плюс - система полномочий/авторизаций, когда посторонный бухгалтер физически не сможет открыть документы и отчеты по начислению зарплаты. Проводка по 70сч. будет вообще одной строкой, но и её не покажут, ибо нефик))
Сотрудники кроме зарплаты в командировки ездят, тоже будет ограничение, хоть движение по 71сч идет с аналитикой по сотруднику, но видеть ее будет только тот кому позволено.
То что не расказали на AS IS должно вылезти на TO BE и на функциональном тестировании. В крайнем случае на интеграционном. На каждом этапе ключевые пользователи от клиента ставят свою подпись, да сейчас работает так(AS IS), да согласен будет так(TO BE), проверили действительно так (функциональный и интеграционный тест).
Вылезло на ОПЭ? - нет проблем, это доп.работы, какая то часть реализуется в рамках бюджета данного этапа(если некорректно работает то что на тестах было норм), а сверх хотелки фиксируются как доп.работы. Это как со стройкой, построили, и если что то криво получилось, то переделывают за свой счет, а если у клиента появилось желание доп.окно в стену прорубить, или наоборот замуровать, то любой каприз за отдельные деньги.
В 1С всё вылезает на ОПЭ? ну логично - коробку типовую поставили, а далее в продуктиве напильником)))
управленческий учет это и есть аналитика фин.учета.
фин.учет - баланс и опу, то что требует законодательство, а детализация прибыли по VIN или еще по каким признакам это управленческий учет, чтобы принять управленческое решение - этими корчами торгуем, а этими прекращаем.
СО-заказ - это один из объектов, который можно представить как аналог субконто в 1C, а есть еще СПП-элементы, если нужен учет чего либо с древовидной структурой, например какой либо проект детализируется по элементам. Т.е. тоже вполне себе субконто из коробки без Z))
Это никак не связано. В данном случае судя по описанию скопировали стандартное приложение WorkManager и навешали на свой Z доп.пожелания пользователей. Обновления если придут, то затронут стандартный WorkManager, а свое как работало так и будет работать, изменяясь своими разработчиками под новые потребности своего бизнеса, а не то как SAP решил обновить.
Как будто в 1С не так? есть защищенная вендором конфигурация, а есть собственные обработки...
Тогда прикручивается к примеру CO-заказ. И там тебе хватит и символов и VIN аналитика и прочие хотелки.
Ну все верно, на то и консультанты, чтобы консультировать на базе собственного опыта. А внутренняя команда (как от IT, так и от бизнеса ключевые) будет обучаться ими, только не в конце, чтобы формально передать систему и свалить, а первым этапом - "Обучение", месяц-два за глаза. Затем совместное проектирование, консультаны подсказывают как лучше. Затем совместные настройки с протоколированием сделанного, консультанты подсказывают что и как, IT делают, key-юзеры сами готовят сценарии тестирования(они лучше знаю что нужно проверить для покрытия требований бизнеса) сами же и гоняют функционаьные тесты, сразу видя возможные косяки, не откладывая на потом.
К итеграционному тестированию не должно остаться никаких критичных недоделок, а к ОПЭ могут остаться только "бантики", не затрагивающие функционал. Да, обучение пользователей перед ОПЭ тоже должны делать ключевые внутренней команды, а не консультанты. ОПЭ - как говориться - "поехали", и это не опытный тест, это опытноПРОДУКТИВНАЯ - основная нагрузка на внутреннюю команду поддержки, консультанты в помощь на второй линии. Период закрыли, отчетность, инвентаризация... всё норм? - подписали акт пошли в прод без слова опыт. Консультанты? - на 3 линии поддержки, проект завершен, остались гарантийные обязательства + отдельный договор сопровождения на 3лини.
в SAP для этой цели есть такой обязательный признак как вид документа. Всего два символа и сразу понятно где задолженность поставщику, а где начисленная зряплата.
Ну и костыль не отменён, кто то всё еще пользуется. Причем работает не так - если шаблон не введен, то корреспонденция не сформируется АВТОМАТИЧЕСКИ и будет список документов для анализа причины, может действительно новая операция, а может накосячил кто. Да, ошибка по корреспонденции сразу прилетит на почту ответсвенному за неё, не дожидаясь времени подготовки отчетности. Вводи новый шаблон, чтобы не повторялось в будущем, либо разбери ВРУЧНУЮ как считаешь правильным. Это к тому что вы ошибаетесь в утверждении "не смог ввести".
Ключевое - Сегежа не отказывается от SAP, а лишь недовольна реализацией - халтурой в конце проекта. По суду деньги на "финишную отделку" не доплатили, посчитали не за что, и пустили на доработку недостатков собственными силами.
Ну а моё имхо, и изначально нужно было внедрять самостоятельно, с обучения внутренней проектной команды, и привлечения при необходимости со стороны действительно КОНСУЛЬТАНТОВ, а не внедренцев.
все верно, в РФ есть рекомендованный план счетов, вот SAP и сдалал в исходной коробке CARU и настроил под него все типовые операции. Так жи и с МСФО, обязательности нет, тем более в коробке предлагается то что есть. Хочешь добавить что то своё, нет проблем.
У кого-то зоопарк екселей? ну так кто то просто "не умеет готовить".
Что касаемо своего плана счетов, так повторюсь - причина в том что 1Совские субконто в SAP это часть GL-счета, вот и получается у каждого свой план счетов под конкретный бизнес компании, изначально выкидвают лишнее и вставляют своё. Далее всё отличие от 1С - одни при необходимости новое субконто вводят, вторые новый счет, 10значный, где первые 4 цифры - рекомендованный в РФ счет.субсчет, а остальные 6 - аналитика(аля субконто)
такого никто не делает, потому что это тупо выделять на HR/PY отдельный мандант в той же системе, так как цель секретности не выполняется, вернее под такой же угрозой, как если бы всё крутилось в одном манданте(разграничивается полномочиями на доступ). Реальная практика - выделение HCМ в отдельной системе, куда в принципе у посторонних доступа нет. Посторонние, это масса админов, разработчиков, консультантов, которые "знаючи" могут похулюганить и подсмотреть то что им не положено видеть, имея просто легальный доступ в систему, даже в другой мандант.
Но это детали, смысл был в различии понятия модулей - в 1С ЗиК это изначально отдельная система и в ней невозможен бух.учет, производство, торговля, а в SAP же это искуственное выделение с целью секретности, а по сути это будут физически две идентичных системы.
И что не так с МСФО в SAP? вполне нормально проводятся документы параллельно как в книгу локального учета так и в МФСО, в одну по счетам и правилам российской бухгалтерии, во вторую по IFRS...валюты учета могут быть так же разные, c разными переоценками по разным курсам, учет ОСов аналогично, где то это актив с последующей амортизацией, а где то сразу ушли на косвенные расходы.
Accruals тоже без проблем ведутся в IFRS книге, не пугая локальных бухгалтеров, они их даже не видят.
Ой ужас ужас, отдельный GL-счет, нет бы как в 1С лепить комбинацией счет.субсчет.субконто. Ой нету корреспонденции счетов, ага и соответсвенно журнал-ордерной формы тоже нет, ужас ужас. Но работают рос.компании в SAP как то, давно уже забив на саповский костыль по реализации этой дурости прошлого века, когда учет велся в "амбарных книгах" ввиду отсутствия автоматизации.
модуля? вы ошибаетесь со смыслом определения модулей. Бухгалтерия(FI), Управленческий учет(СО), Закупки/Склад(ММ), Сбыт(SD), Производство(PP), ТОРО(PM), ЗарплатаКадры(НСМ) это всё единая система, модули не живут отдельно. Можно конечно HCМ сделать на отдельном сервере, спрятать в бронированной комнате, что бы никто посторонний не подсмотрел размер зарплаты у коллеги, но это опция, т.к весь функционал в одной коробке. Как отдельные модули можно считать разные BW и прочее, живущее как правило отдельно.
По поводу можно ли использовать сразу лишь сменив название и адрес организации? - МОЖНО, если у вас организация с одним заводом и складом)), но такие не покупают SAP. Это все же система для корпораций, иерархическую оргструктуру нужно создавать...
А так да, ну будет с кодом RU01 реальная компания, план счетов преднастроенный CARU, один завод RU01 c одним складом 0001. Вводи начальные остатки, и поехали - закупай, производи, продавай, по счетам бух.учета проводится, НДС считается, нормативная отчетность в ACR попадает. ОСы тоже пренднастроены.
Почему так не делают уже написал - потому что у корпорации несколько компаний, в разных странах, где валюты учета разные, план счетов бухгалтерии разный, а задача построить корпоративную отчетность по единым корпоративным правилам, чтобы это все работало онлайн в единой системе. Тут без проектирования и тщательной ОПЭ никуда.
Санкции? SAP ушел? ну были лицензии на юр.лице из РФ, стали на юр.лице из Казахстана и нет санкций. А можно и вообще забить на вендора, ушел и ладно, экономия на лицензионных отчислениях, платить эти деньги местным за локализацию, тому же ЛАБ СП. Чем не импортозамещение?)))
именно так вражеский спираченный == трофейный
и после кидкаь сапов и прочих ораклов нужен был указ не только об импортозамещении, то и об этом трофейном софте. легальное каперство)))