Разорвалось соединение с интернетом и часть проводки попала в Главную книгу, а часть осталась в дневном журнале и проводка в нём теперь не балансируется? Увы, иногда, хоть и очень редко, такое до сих пор может происходить. Один из вариантов действий кратко описан здесь
Начнём с того, что ничего просто так удалять нельзя. Ну, нельзя залезть в таблицу платежей по поставщикам в базе данных iScala и удалить платёж. При этом будет нарушено соответствие с информацией по счёту-фактуре, по которому был произведён платеж, соответствие с сальдо по поставщику, ведь там этот платёж учтён и так далее. Поэтому нужно не удалять … [Подробнее…]
После рассылки новостей проекта и размещения ссылки в социальных сетях я получил 6 ответов на вопрос «Что это? Угадайте». 3 из них правильно определили что я собираюсь сделать, но никто не угадал зачем 🙂
В 90-е годы, когда Scala только появилась в России, все, кто её использовал, знали, что такое «консолидация», сейчас почти никто не знает и вот почему: можно сказать, что именно функциональность «непрерывная консолидация» обеспечила ERP системе Scala продвижение в России. В то время было очень важно вести учёт по российским и западным стандартам одновременно, причём в разных валютах…
Главный бухгалтер прекрасно работал с Главной Книгой, захотелось ему посмотреть подробности по складу и ему добавили роль кладовщика. Раз, и пропал доступ в Главную Книгу. Всё из-за неграмотного назначения ролей кладовщику. Вот такие случаются неприятности, когда невозможно проанализировать права доступа для различных ролей. 🙂
Значение поля GL06012 (таблицы GL06 — Проводки Главной Книги) :: Value of GL06012 field (of GL06 table — General Ledger Transactions)
Для ежедневного контроля очень удобно использовать отчёты с возможностью перехода по ссылке и просмотра подробностей. Такие отчёты можно сделать под требования пользователя. Один из возможных вариантов я привожу ниже на данных тестовой компании 2005 финансового года. Первый отчёт — это сальдо по счетам/учетному измерению «Департамент» и (при наличии информации) кодам покупателей/поставщиков для соответствующих счетов При … [Подробнее…]
Этот отчёт показывает проводки ГК в таблице истории модуля «Управление Запасами» (SCGL), которым нет соответствия в таблице аналитических проводок модуля (SC07). Такая ситуация, разумеется, штатным образом возникнуть не может, и возможна только в том случае, если для каких-то аналитических проводок кто-то «вручную» обнулил флаг создания проводок ГК и создал их повторно. В этом случае ранее … [Подробнее…]
Пример отчёта «Несоответствие истории проводок ГК модуля УЗ текущим настройкам автоучёта» Этот отчёт показывает несоответствие между проводкой, которая была бы создана при текущих настройках таблицы автоучёта и той проводкой, которая реально была отправлена в Главную Книгу (включая «ручные» пользовательские исправления) Другие страницы данной темы:
Ниже приводится пример отчёта, показывающего проводки по счетам учёта запасов, попавшие в Главную Книгу не из модуля «Управление Запасами» Отчёт имеет многозначный параметр «Выберите счёта для проверки», значения в который попадают из таблицы автоучёта модуля «Управление Запасами» для позиций «Полученные Запасы» и «Выданные Запасы». Пользователь, в свою очередь, может отметить требуемые ему позиции: Другие страницы … [Подробнее…]
Следующий отчёт показывает строки проводок из истории журнала Главной Книги модуля «Управление Запасами», даты которых находятся за пределами того периода, в который была отправлена соответствующая проводка Главной Книги. Отчёт имеет 2 варианта группировки: По номеру проводки в журнале: и по учётной строке: Другие страницы данной темы:
Иногда следует удостовериться, не залезли ли чьи-то «очумелые ручки» в таблицу складских проводок и не поудаляли ли чего. Разумеется в обычной ситуации такого быть не должно, но при наличии «очумелых ручек» очень даже вероятно: Jugulator писал(а): При создании процедур сверки складских проводок необходимо также учитывать, что возможна не только обычная схема создания проводок «одна строка … [Подробнее…]
|
|
