А есть ведь еще и словари. Но это, мой маленький дружок, уже совсем другая сказка.
Re: Есть такая вещь.
Извините, что побеспокоила Вас, такого большого и серьезного, хотя Вы мне и не дружок, уважаемый сказочник.
Одной ссылки мне показалось недостаточно, а вот словари в интернете нашли 0 вариантов.
А такое?
Может, второй будет достаточно?
«клиринг — механизм, включающий сбор, сортировку, реконсиляцию и проведение взаимозачета встречных требований членов платежной системы. «
Re: А такое?
Право слово, мне лестнА Ваша помощь, учитывая, что о клиринге я не спрашивала.
Впрочем, в одной из найденных Вами ссылок действительно есть некое определение реконсиляции. Надеюсь, Вы не слишком утомились, помагая найти нужный «тык»?
О чем речь!
Не, коллега, вовсе не утомился ))) Опять же, и сам размялся. Вот. К тому же, чуть было доброе дело не сделал.
совсем плоско: выверка платежей организации, которую производит бухгалтер. например поставщикам. за день набегает определенная сумма которую надо сверить с оплатами договоров и проставить галочки.
План счетов бухгалтерского учета : что это и для чего?
Да просто «сверка» одним словом..
Сдается мне это калька с английского reconcile. Соответственно, означает — сверять, сводить, проверять заново.
До чего же люди ленивые.. Убиться.
Нет, Вы так не убьетесть!
На всякий случай, прежде чем кого-либо упрекать в следующий раз, не поленитесь, посмотрите в инфо сообщества, для чего оно создано.
И не лень же Вам было здесь не в тему.
Источник: pishu-pravilno.livejournal.com
Реконсиляция счетов бухгалтерского учета что это
- Вы здесь:
- Другие услуги и программные решения
- Кейсы
- Как мы настроили сверку данных между SAP и 1С (счета продаж, склада, прибылей и убытков)
Как мы настроили сверку данных между SAP и 1С (счета продаж, склада, прибылей и убытков)
Отрасль бизнеса: — Любая — Подразделение: Финансы, бухгалтерия, аудит, Закупки, снабжение, Продажи, Логистика, складской учет, транспорт, Информационные технологии, связь ERP-система: SAP ERP, 1С:Предприятие
Учетные системы SAP и 1С, казалось бы, имеют мало общего. Но, если спуститься в учёте до конкретных операций, — это не совсем так. Однотипные операции и соответствующие данные из систем SAP и 1С вполне можно сопоставить автоматически даже при помощи такого простого средства как MS Excel. Как мы настроили сверку данных из SAP и из 1С с помощью Excel — читайте далее.
Предыстория и задачи проекта
К нам обратился наш постоянный клиент, российский филиал известной транснациональной компании, с проблемой сверки данных между SAP и 1С. Решение этой проблемы было необходимо по требованиям прошедшего в компании аудита. В компании учет ведется параллельно, силами разных сотрудников, одновременно в системах SAP и 1С. SAP используется как корпоративная глобальная система, а 1С используется как система российского учета для расчета налогов и сдачи российской отчетности только в российском филиале компании.
ПЛАН СЧЕТОВ БУХГАЛТЕРСКОГО УЧЕТА | Бухучет для чайников | Бухгалтерский учет для начинающих | Счета
Система SAP для российского подразделения была установлена по результатам проекта Roll-out на удаленных серверах, данные из SAP можно получать только отдельными выгрузками.
Наша задача состояла в том, чтобы, используя текущие возможности и предпочтительно простой Excel, реализовать автоматизированную сверку данных по группам счетов между SAP и 1С.
Экономическая эффективность и результаты выполненного проекта
Благодаря выполненному проекту Заказчик получил решение нетривиальной задачи автоматизированной сверки разнородных по структуре данных из SAP и из 1С.
Экономический эффект для Заказчика от выполненного проекта обуславливается:
- кардинальной экономией трудозатрат своих сотрудников на сверку данных;
- быстрой идентификацией ошибок в учете и минимизацией ошибок в учете;
- соответствием требованиям аудита.
Ручное выполнение такой задачи было бы экономически неэффективно, т.к. требовало бы как минимум полной занятости одного сотрудника. Теоретически, задача могла быть решена при помощи специальных программных продуктов, но это означало бы серьезные затраты компании на лицензирование, развертывание и внедрение такого решения. Кроме того, внедрение такого отдельного программного продукта вряд ли было бы согласовано со стороны головной компании.
В текущих условиях задача не могла быть реализована другими способами, но была необходима Заказчику.
Средства реализации
Исходя из требований задачи, технических ограничений в компании, невозможности реализации решения с использованием баз данных (даже MS Access), для решения нужно было использовать очевидный доступный инструмент — Excel. В нём мы решили разрабатывать инструмент сверки данных между SAP и 1C, который бы читал файлы данных, предварительно полученные из SAP и из 1C, а затем выполнял бы сопоставление имеющихся данных.
Обратиться с похожей задачей
Детали и шаги реализации
Готовое Excel-решение для пользователей выглядит так — на одном листе последовательно по колонкам приведены общие для обоих систем данные, данные из 1С, данные из SAP, и далее — результаты сопоставления по строкам. В первых колонках приведена общая для обоих систем часть — фактически это ключи сопоставления. В качестве таких ключей связки (сопоставления) данных мы используем 2 поля, которые приводим к кодам SAP — это код контрагента и номер документа.
В уменьшенном масштабе видно, что перед блоком данных из 1С мы добавили блок данных «1С для сверки (в разрезе счета)». Это связано с тем, что операции, выгруженные из 1С, имеют нескольку иную структуру данных, чем в SAP.
В SAP мы видим движения по каждому счету с разными знаками, а в 1С — мы видим проводку, содержащую всегда 2 корреспондирующих счета, т.е. как дебетовую, так и кредитовую сторону операции. Соответственно каждой нашей операции из SAP может соответствовать только одна из «половинок» проводки из 1С (или дебетовая или кредитовая сторона). Вот для того, чтобы перейти к единому сопоставлению данных по движениям в рамках конкретного счета, нам и потребовался этот дополнительный блок данных, в котором данные из 1С преобразованы в вид, подобный структуре наших данных из SAP.
Исходными для сверки являются данные, загруженные «как получено» из систем SAP и 1C на листы «SAP» и «1С» соответственно. Из 1С выгрузка осуществляется через Журнал проводок. В нашем примере из SAP выгрузка осуществляется через Trial Balance. Загрузка данных в Excel-шаблон выполняется из этих согласованных форматов, но с идентификацией конкретных колонок по названиям. Таким образом, если в исходных данных поменяется порядок полей или какое-то несущественное по данным поле исчезнет из исходных данных или появится — проблемы при загрузке этих данных в Excel-шаблон сверки не возникнет.
В шаблоне также реализован мэппинг контрагентов между кодами и названиями контрагентов в САП и между контрагентами в 1С. Данные на листе «Client_Mapping» необходимо дополнять при появлении в учете новых контрагентов.
На основном листе отчета записи при выводе группируются и в разрезе контрагентов, и в разрезе документов. Используя стандартную группировку записей в Excel можно получить данные в развернутом виде с подитогами по контрагентам и входящим документам, данные в свернутом виде с подитогами по контрагентам и входящим документам, данные в свернутом виде только по контрагентам с подитогами.
Также существует еще первая колонка «SAP/1C», с помощью фильтра по которой в полученных данных легко можно увидеть блок записей из SAP, имеющий соответствие в 1С; блок записей из SAP, не имеющий соответствие в 1С; блок записей из 1С, не имеющий соответствие в SAP. Эта же колонка «SAP/1C» даёт альтернативный вариант просмотра итогов в отчете-сверке, имея для фильтра значения «= итоги по сделкам» и «== итоги по контрагентам».
Самой интеллектуальной частью нашего решения является блок настроек для сопоставления данных между системами. Здесь приведены настройки конкретных кодов счетов или масок по ним, соответствующих друг другу в системах SAP и 1С, коды полей, означающих номер документа в той и в другой системе, полярность операции из 1С (Debet или Credit), названия полей, из которых брать суммы и т.п.
По одному алгоритму могут обрабатываться несколько вариантов транзакций. Например, контрагент в 1С может находиться и в поле «Субконто1 Дт» и в поле «Субконто1 Кт». А номер документа в SAP может в каких-то случаях быть в поле «Text», в каких-то случаях в поле «Reference Key 3», а в каких-то случаях даже обрабатываться с использованием дополнительного мэппинга. Всё это здесь прописывается.
В Excel-шаблоне сопоставление данных выполняется по совпадению (относительному совпадению) референсов операций (оснований операций, номеров документов), причем поле-референс, по которому выполняется сопоставление — разное для разных типов операций, и мы вывели его указание в настройки Excel-шаблона. Так, для счетов продаж и склада в качестве номера документа из SAP мы берем поле «Reference Key 3», а для счетов затрат в качестве номера документа из SAP мы берем поле «Text».
Всего в решении было настроено 3 алгоритма сверки — для счетов продаж, для счетов склада, для счетов затрат. Конкретный алгоритм сверки для формирования отчета-сверки выбирается фильтром в шапке отчета.
Сначала решение нами было сделано для счетов продаж, затем — для счетов склада, и на последнем этапе — для счетов затрат. На этапе «подключения» счетов затрат нам пришлось несколько доработать и расширить варианты настройки, чтобы обеспечить применимость решения для более широкого спектра счетов и данных по ним. Это связано с тем, что данные на счетах затрат в SAP могут быть как с положительным, так и с отрицательным знаком, и в 1С соответствующие данные оказываются на разных сторонах проводки (может быть по дебету, может быть по кредиту) — следовательно для сверки нам требуется обрабатывать и дебетовую и кредитовую часть данных из 1С.
На последнем этапе, для еще большей минимизации ручного труда для Заказчика был добавлен механизм проверки типовых ситуаций расхождения (автоматическая верификация отдельных расхождений). В частности, если сумма по валюте совпадает, но не совпадает по рублям, то это различие комментируется в отчете-сверке как курсовые разницы. Если операция находится на стыке кварталов с учетом временного сдвига по вводу данных в системах, то вероятно, что в парной системе она отражена в соседнем квартале, о чём также добавляется комментарий в сформированном отчёте-сверке.
Сложности и решения
Основной сложностью в ходе проекта стало объединение разных групп счетов в одну логику настройки. По факту нам после первоначально сделанного решения пришлось расширять логику настройки для того, чтобы решение покрыло новую группу счетов, в частности — затратные счета. Расширение логики настройки потребовалось также и потому, что сопоставляемые ключи данных (код контрагента и номер документа) хранятся для разных типов операций в различных полях как в рамках SAP, так и в рамках 1С.
Не сложностью, а особенностью проекта было то, что в SAP и в 1С разная структура исходных данных (в SAP — это движения по конкретным счетам, а в 1С — проводки, представляющие собой движение Debet-Credit всегда по двум счетам). Поэтому мы применили «хитрость» с приведением операций из 1С к виду операций из SAP.
Сейчас также мы понимаем, что в результате проекта мы создали достаточно сложную логику настройки алгоритмов сверок, которая не совсем очевидна конечным пользователям. И, вероятно, пользователям будет сложно сделать дополнительные настройки на листе «Setup», если потребуется расширение этого решения на другие группы счетов. Но как сделать её более понятной, но при этом сохранить существующую вариативность и универсальность такой настройки, мы пока не придумали.
Результат проекта
В результате нашей работы Заказчик получил удобный инструмент сопоставления различных групп счетов и типов операций между 1С и SAP, автоматической проверки типовых ситуаций расхождения. С помощью этого Excel-решения все расхождения в сверяемых данных можно оперативно увидеть и исправить, если необходимо.
Готовое Excel-решение имеет потенциал расширения на другие группы счетов только при помощи настроек соответствий между данными в системе SAP и между данными в системе 1С.
Стоимость проекта
Стоимость проекта для Заказчика составила 162’000 руб. включая НДС 20%
Примечание
В целях конфиденциальности все упоминания о компании-Заказчике и все исходные данные на скриншотах изменены.
Источник: bi-cons.ru
Реконсиляция — проверка целостности данных в распределенных системах
При разработке и использовании распределенных систем перед нами возникает задача контроля целостности и идентичности данных между системами — задача реконсиляции.
Требования, которые выставляет заказчик — минимальное время данной операции, поскольку чем раньше расхождение будет найдено, тем легче будет устранить его последствия. Задача заметно усложняется тем, что системы находятся в постоянном движении (~ 100 000 транзакций в час) и добиться 0% расхождений не получится.
Основная идея
Основную идею решения можно описать следующей диаграммой.
Рассмотрим каждый из элементов отдельно.
Адаптеры данных
Каждая из систем создана для своей предметной области и как следствие описания объектов могут существенно различаться. Нам же требуется сравнить только определенный набор полей из этих объектов.
Для упрощения процедуры сравнения, приведем объекты к единому формату, написав для каждого источника данных свой адаптер. Приведение объектов к единому формату, позволяет заметно сократить объем используемой памяти, поскольку хранить мы будем только сравниваемые поля.
Под капотом у адаптера может быть любой источник данных: HttpClient, SqlClient, DynamoDbClient и т.д.
Ниже представлен интерфейс IAdapter, который требуется реализовать:
public interface IAdapter where T : IModel < int Id < get; >Task GetItemsAsync(ISearchModel searchModel); > public interface IModel < Guid Id < get; >int GetHash(); >
Хранилище
Реконсиляцию данных можно начинать только после того как все данные прочитаны, поскольку адаптеры могут возвращать их в произвольном порядке.
В таком случае объема оперативной памяти может не хватить, особенно если вы запускаете несколько реконсиляций одновременно, указывая большие временные интервалы.
Рассмотрим интерфейс IStorage
public interface IStorage < int SourceAdapterId < get; >int TargetAdapterId < get; >int MaxWriteCapacity < get; >Task InitializeAsync(); Task WriteItemsAsync(IEnumerable items, int adapterId); Task> GetDifferenceAsync(ISearchDifferenceModel model); > public interface ISearchDifferenceModel < int Offset < get; >int Limit < get; >>