Начну с того, что термин «отчёты «сальдового» типа» придумал я. Под этим я понимаю отчёты, которые запрашивают данные в таблицах сальдо: сальдо по бухгалтерским счетам, сальдо по покупателям, поставщикам, сальдо по запасам, по складам или по партиям. Эти данные всегда актуальны по состоянию на «сейчас». Через 5 минут они могут обновиться, как если бы в Excel’е заменили старое значение в ячейке новым, что было в этих таблицах «вчера» понять невозможно
В iScala 3.1 поменялось название объекта, в версиях до 3.1. объект, к которому обращается отчёт, назывался SfwIII (Scala for Windows III), мои коллеги называли его «Эс Эф Вэ ай-яй-яй». В версиях, начиная с 3.1. он называется iScala. Из-за этого встроенный в отчёт VBA код и перестал работать. Возможно, то, что отчёт перестал работать, это благо, повод отказаться от устаревших подходов и технологий, которые тянутся «в светлое будущее» только из-за того, что никто не изучает новых возможностей
Иногда я прошу прислать текст хранимой процедуры SQL сервера. Не все знают, как это сделать, поэтому я приготовил краткую инструкцию с картинками 🙂
Иногда необходимо делать расчёт значения в столбце зависимым от того, что находится в строке отчёта
Sometimes it is necessary to calculate the value in a column depending on what is in the report line
Нужен лог о действиях пользователей за определенное число. Точнее есть 1 транзакция под определенным номером и нужно определить какой из пользователей ее провел. Как это сделать?
Очень часто пользователи говорят: «DDF файлы, фу! Устаревшая технология!». Не буду спорить, однако, когда вы используете DDF, вы получаете набор данных, который сама Scala/iScala строит по своим внутренним алгоритмам с использованием многих десятков настроек, с анализом различных правил и параметров. Если использовать альтернативный вариант в виде «внешнего» отчёта, вам придётся самостоятельно запрограммировать всю логику системы или сделать допущение относительно тех или иных параметров, что они в Вашей компании являются конкретными величинами и не будут изменены в дальнейшем
В 90-е годы, когда Scala только появилась в России, все, кто её использовал, знали, что такое «консолидация», сейчас почти никто не знает и вот почему: можно сказать, что именно функциональность «непрерывная консолидация» обеспечила ERP системе Scala продвижение в России. В то время было очень важно вести учёт по российским и западным стандартам одновременно, причём в разных валютах…
Этот вопрос был задан в кулуарах конференции клиентов компании Эпикор в Москве 12.09.2017. Ответ найти очень легко на странице, описывающей изменения структуры базы данных iScala разных версий
Хотелось бы на конкретном примере описать один из возможных вариантов «клонирования» существующих настроек при открытии новой компании.
Различные варианты «клонирования» компаний:
1. Создание резервной копии системной базы данных и базы данных компании и их восстановление на новом сервере
2. Установка iScala «с нуля» и импорт меню, настроек безопасности в системной БД, восстановление резервной копии данных компании, сделанной стандартными средствами iScala
Дано: имеется файл с экспортированными отчётами AFR.
Требуется: развернуть их на другом сервере
Приводится пошаговое описание действий
Разумеется, в разных компаниях пользователи iScala работают по-разному, я попытаюсь описать лишь один из возможных вариантов. Операции прихода обычно делаются в модуле «Заказ на Закупку», там же делаются операции ввода дополнительных затрат и т.п. Операции расхода обычно делаются в модуле «Заказы на Продажу» (если он используется) и/или в модуле «Requisition Management» (Требования). Операции перемещения между […]
В отличие от модулей Книга Закупок или Книга Продаж в модуле «Управление Запасами» проводки Главной Книги не создаются в момент движения запасов. Их создание происходит при входе в меню «Журнал Главной Книги» модуля «Управление Запасами»