О системах планирования ресурсов предприятия Scala, iScala
“ Начну с того, что широко разрекламированная "стандартность" учёта - это миф! Никакой "стандартности" нет. Да, у нас есть стандартизованный план счетов с рекомендованными счетами и субсчетами. Однако, вы должны будете либо отказаться от всех подробностей ваших расчётов, особенно, если у вас под 500 различных начислений и удержаний (мало ли что у вас на вашем предприятии "нажито непосильным трудом") или понять, что никакая "стандартность" в новой программе, которой вы зачем-то хотите заменить модуль заработной платы вашей iScala, вам не светит и без программистов она всё равно не будет работать, как вам хочется
  • Главная
    • О проекте
      • Разъяснение о проекте и его участниках
      • Заявление / Memorandum
    • Новости проекта
    • Список опубликованных материалов основного раздела
    • Информация, перенесённая из старых форумов
    • Подписаться на новостную рассылку
  • Статьи
    • Статьи
    • Избранное
    • Мысли вслух
  • Процедуры
  • Доходчиво о сложном
    • Обучение
    • Как сделать?
    • iScala «для чайников»
    • Оч.умелые ручки
  • Структура таблиц
    • Scala 5.1 SR13
    • iScala 2.2 HF 2.3318
    • Tables structure changes history from iScala 2.2 SR2 to iScala 3.0 FSP4
    • Epicor iScala 2.3 — 2.03.3363
    • Epicor iScala 2.3 SR1
    • Epicor iScala 2.3 SR2
    • Epicor iScala 2.3 SR3
    • Epicor iScala 3.00 FSP 2 — 3.00.02254
    • Epicor iScala 3.0 FSP4 — 3.0.4267
    • Изменение структуры таблиц iScala 3.1 по сравнению с iScala 3.0 FSP4 / Table structure changes between iScala 3.0 FSP4 and iScala 3.1
    • Epicor iScala 3.1 — 3.1.0511
    • Epicor iScala 3.2 — 3.2.0317
    • Epicor iScala 3.3 — 3.3.0419
    • Epicor iScala 3.4 — 3.4.0399
    • Epicor iScala 3.5 — 3.5.0.0429
    • Изменение полей в таблицах БД iScala 3.4 по сравнению с iScala 3.2 / Difference between DB structure of iScala 3.4 and iScala 3.2
    • Изменение полей в таблицах БД iScala 3.5 по сравнению с iScala 2.2 / Difference between DB structure of iScala 3.5 and iScala 2.2
  • Материалы по модулям iScala
    • Главная Книга
    • Основные Средства
    • Книга Закупок
    • Книга Продаж
    • Заказы на Закупку
      • Требования
    • Заказы на Продажу
    • Управление Запасами
    • Установка, Администрирование
      • Настройка определений документов MSRS
    • Заработная плата
    • Структура базы данных
    • Отчётность SSRS
    • Отчётность AFR
    • Примеры отчётов
    • Примеры отчётов AFR
    • Интеграция с другими системами
    • Epicor Service Connect
  • English
  • Контакты
  • Поиск
Главная  »»»  IT & ERP  »»»  Только вы можете принять решение, какой программой пользоваться. Но желательно принять его с «открытыми» глазами

Только вы можете принять решение, какой программой пользоваться. Но желательно принять его с «открытыми» глазами

17.08.2020 Автор Алексей Васильев

Шаблон отчёта "Справка о сумме заработной платы" для печати через канал MSRSВчера я разговаривал со своим коллегой по поводу одного нашего общего клиента. Они хотят перестать использовать модуль «Заработная плата» iScala и начать использовать программу, название которой я принципиально здесь не называю, дабы меня не обвинили в её рекламе или, наоборот, очернении. Что тут сказать? Я уже писал ранее, что вы и только вы имеете право решать, чем пользоваться. Что, однако не помешает мне высказать отношение к вашему решению.

Начну с того, что широко разрекламированная «стандартность» учёта — это миф! Никакой «стандартности» нет. Да, у нас есть стандартизованный план счетов с рекомендованными счетами и субсчетами. Я сам пользую одну из «стандартных» программ для сдачи отчётности, всё-таки, согласитесь, вести учёт в Скале для компании, где работают от 1 до 4-х человек (состав и численность периодически меняются), это несколько неразумно, ведь вы же не будете держать многофункциональный деревообрабатывающий станок, чтобы раз в месяц заточить пару карандашей. Вот и я не собираюсь это делать. Но однажды я решил добавить в этой самой «стандартной» программе один субсчёт. Ну, добавил и добавил. Проводки сделал. А потом стал сводить баланс и увидел, что мой стандартный счёт и «нестандартный» субсчёт никуда не попадает. Нужно вносить изменения во все отчёты и стандартные алгоритмы, в них не предусмотрена возможность брать диапазон субсчетов или счетов «по маске». И пришлось мне отказаться от моего «нестандартного» субсчёта, упростить, так сказать.

Вот и вы должны будете либо отказаться от всех подробностей ваших расчётов, особенно, если у вас в iScala под 500 различных начислений и удержаний вроде компенсаций за вредность, за совмещение, за работу на разных участках и т.п. (мало ли что у вас на вашем предприятии «нажито непосильным трудом») или понять, что никакая «стандартность» в новой программе вам не светит и без программистов всё равно не обойтись. Я не специалист именно по модулю «Заработная плата», однако помню, как в своё имя Игорь Голиков рассказывал грустную историю о своём бывшем клиенте, который перешёл на широко известную российскую программу и теперь не может жить без приходящих программистов, которые оказались не дешевле, как предполагалось (что тоже ещё один миф), а дороже чем поддержка скальского модуля «Зарплата»

Рубрика: IT & ERP, Заработная плата Метки: iScala, заработная плата, стандартность
VK Telegram

Copyright © 2023 О системах планирования ресурсов предприятия Scala, iScala.

Gammapolis WordPress Theme by ERP & Business Consulting

Прокрутка вверх