انجمن‌ها

امکان جدید برای ابزار ارسال رخدادهای مالی به سامانه دفاتر تجاری الکترونیکی: ارسال سرجمع رخدادهای مالی به سامانه‌ی دفاتر تجاری الکترونیکی

امکاناتی برای ارائه‌ی گزارش مبنای ایجاد فایل قابل ارسال به سامانه‌ی دفاتر تجاری الکترونیکی پیاده‌سازی شده‌اند. در محاوره‌ی ابتدایی این گزارش یک صفحه جدید با عنوان "سرجمع" قرار داده شده است که در شکل زیر مشاهده می‌شود:

در این صفحه می‌توان از سیستم درخواست کرد که داده‌ها را به صورت سرجمع بازنمایی (و صادر) کند. دو نکته‌ی مهم در این عملیات وجود دارد: ردیف و تاریخ. سرجمع داده‌ها به صورت تعدادی شبه سند ارائه می‌شوند یعنی سطرهایی هم ردیف و هم تاریخ که حاوی حساب‌ها و مبالغ هستند و جمع بدهکار و بستانکار سطرهای هم‌ردیف مساوی است. اگر قرار باشد، به هر صورت، سرجمع محاسبه شود، حتما لازم است تا ردیف نخستین شبه سند توسط کاربر داده شود. مسئولیت صحت این ردیف و اینکه با عملیات قبلی تناقض نداشته باشد برعهده‌ی کاربر خواهد بود.

دو روش محاسبه‌ی سرجمع داریم: برحسب تاریخ و به صورت کلی – دریچه‌ای برای انتخاب یکی از این دو روش در محاوره تعبیه شده است. در روش اول، عملیات هر تاریخ به صورت یک ردیف جداگانه لحاظ می‌شوند. این می‌تواند به میزان زیادی از حجم داده‌هایی که باید بارگزاری شوند بکاهد و درضمن تاریخ شبه سندها را هم به صورت خودکار حاصل کند. در مقابل، در روش دوم، همه‌ی رخدادهایی که در گزارش احضار شده باشند به صورت یک شبه سند لحاظ خواهند شد. این برای سرجمع ماهانه، دو ماهانه یا هر نوع سرجمع دلخواه کاربرد خواهد داشت. در این روش فقط یک شبه سند خواهیم داشت و ردیفی که پیش از این عنوان شده بود به همین تک شبه سند داده خواهد شد.

در مقابل لازم است تا تاریخ توسط کاربر داده شود. مثلا کاربر می‌تواند یک صدور از سند(های) افتتاحیه داشته باشد با ردیف 1 و تاریخ مناسب + 12 صدور از اسناد ماه‌های سال با ردیف‌های 2 تا 13 و تاریخ انتهای هر ماه + یک صدور از سند(های) سود و زیان با ردیف 14 و تاریخ مناسب و یک صدور از سند(های) اختتامیه با ردیف 15 و تاریخ مناسب. در این روش شرایطی که کاربر در گزارش تعیین می‌کند مشخص‌کننده‌ی محدوده خواهند بود (درست همانند صدور بدون سرجمع) ولی داده‌ها سرجمع می‌شوند و ردیف و تاریخی که کاربر تعیین کرده است به آنها داده می‌شود.

همه‌ی سطرهای سرجمع یک شرح یکسان خواهند داشت. این شرح در محاوره‌ی فوق توسط کاربر قابل تعیین است. شرح اختیاری است.

امکانات جدید ارائه شده در نسخه 15.02: افزایش تعداد برچسب‌های قابل تعریف برای رخدادهای مالی از 15 به 20

در این نسخه برچسب‌های رخداد از 15 به 20 در حسابداری مدل T می باشد. این افزایش، علاوه بر اینکه در حین تعریف برچسب‌های رخداد (قابل اجرا در منوی حساب) تاثیر داشته است، در بخش‌های متنوعی از سیستم نیز تاثیرات مهمی را به همراه خواهد داشت. به صورت کلی چنین است که برچسب‌های تعریف شده به صورت فیلدهای قابل استفاده از اسناد خودنمایی می‌کنند. این فیلدها در فرم‌های ویرایش (مثلا محاوره‌ی اصلاح یک سطر سند) قابل احضار خواهند بود. سه پارامتر اساسی در مورد این برچسب‌ها در سیستم قابل تعیین هستند که همگی در الگوهای عملیات حساب تعیین می‌شوند: برچسب‌های رخداد اختیاری و اجباری و برچسب‌های موثر در کنترل مانده‌ی حساب‌ها. در صورت استفاده از برچسب‌ها در فرم‌های ویرایش سطرهای اسناد، برحسب حساب انتخاب شده در سطر، برچسب‌هایی که اختیاری یا اجباری نباشند به صورت غیرفعال (غیر قابل ویرایش) دیده خواهند شد. به جز این برچسب‌های اجباری در بررسی درستی سند در هنگام ذخیره‌ی سند عملیاتی بررسی می‌شوند که وضعیت طبیعی و واضحی است. کنترل مانده‌ی حساب‌ها با توجه به ترکیبی از عملیات حساب و برخی از تفصیلی‌ها و برچسب‌ها انجام می‌شود. تفصیلی‌ها و برچسب‌های موثر در کنترل مانده نیز در الگوی عملیات حساب تعیین می‌شوند.

برچسب‌ها در همه‌ی گزارش‌های مبتنی بر ریز عملیات مالی قابل احضار هستند. همچنین در بسیاری از گزارش‌های سرجمع امکان تفکیک بیشتر مبالغ گزارش شده برحسب این برچسب‌ها نیز وجود دارد. در تبدیل سطرهای اسناد حسابداری از جزیی به سرجمع نیز به این برچسب‌ها توجه می‌شود؛ فقط سطرهایی که برچسب‌های یکسانی داشته باشند سرجمع می‌شوند. در تنظیم خودکار اسناد اختتامیه، سود و زیان و انتقال مانده، این امکان وجود دارد که عملیات برحسب برخی یا تمامی برچسب‌های رخدادها سرجمع شده و در سند بازنمایی شوند. در ویرایش سند، در اصلاح یکباره‌ی سطرهای علامت‌گذاری شده نیز امکان اصلاح یکباره‌ی برچسب‌ها وجود دارد. همه‌ی اینها تحت تاثیر افزایش تعداد برچسب‌ها قرار می‌گیرند.

در ادامه، به برخی قسمتها و گزارش‌هایی از سیستم که برچسب‌های رخداد در آنها نقش دارند اشاره می‌شود

• تعریف برچسب‌های رخداد در منوی حساب
• تعریف الگوهای عملیات حساب در منوی حساب
• ویرایش برچسب‌ها در سند
• کنترل برچسب‌های اجباری و اختیاری در اسناد (اینکه برچسب‌ها غیرفعال شوند و حتما درج شده باشند)
• تاثیر برچسب‌ها در مکانیزم کنترل مانده حساب‌ها
• اصلاح برچسب‌ها در اصلاح یکباره‌ی سطرهای اسناد
• تبدیل سطرهای سند از جزیی به سرجمع و برعکس – تاثیر در تجمیع و تفکیک به برچسب‌ها قابل اشاره است.
• در کپی اسناد با تعداد سطرهای کمتر از 600 (کپی در کلاینت) – برچسب ها نیز کپی خواهند شد
• کپی اسناد با تعداد سطرهای بیشتر از 600 (کپی در سرور) – برچسب‌ها نیز کپی خواهند شد
• در تنظیم اسناد اختتامیه یا سود و زیان در منوی سند – هم تفکیک به برچسب‌ها و هم تشکیل اسناد بدون تفکیک به آنها امکان پذیر است.
• صدور و فراخوانی اسناد حاوی برچسب رخدادها در فایل XML
• امکان احضار برچسب‌های رخداد در انواع گزارش‌های ناشی از رخدادهای مالی – مثل ریزعملیات‌ها – برای موضوعات مختلف (حساب، تفصیلی، نهاد، مجموعه...)
• امکان احضار برچسب‌ها در صورت‌حساب فروش یک تفصیلی
• امکان تفکیک بیشتر گزارش‌های سرجمع زیر برحسب برچسب‌ها
  • تراز گروه‌بندی شده‌ی کلان
  • تراز آزمایشی جامع
  • تراز مبتنی بر الگوهای عملیات حساب – در این گزارش، تفکیک مستقل از خواست کاربر و مبتنی بر برچسب‌های موثر در کنترل مانده‌ی حساب انجام می‌شود.
  • تفکیک عملیات حساب به یک شماره‌ی تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به یک شماره‌ی تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به حساب‌ها (سرجمع)
  • تفکیک عملیات حساب به طبقات تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به طبقات تفصیلی (سرجمع)
• تاثیر برچسب‌ها در ارائه‌ی جزییات سطر تحت مکان‌نما در گزارش‌های سرجمع زیر
  • تراز گروه‌بندی شده‌ی کلان
  • تراز آزمایشی جامع
  • تراز مبتنی بر الگوهای عملیات حساب – در این گزارش، تفکیک مستقل از خواست کاربر و مبتنی بر برچسب‌های موثر در کنترل مانده‌ی حساب انجام می‌شود.
  • تفکیک عملیات حساب به یک شماره‌ی تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به یک شماره‌ی تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به حساب‌ها (سرجمع)
  • تفکیک عملیات حساب به طبقات تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به طبقات تفصیلی (سرجمع)
• امکان احضار برچسب‌ها در فرم‌های گزارش‌های سرجمع زیر
  • تراز گروه‌بندی شده‌ی کلان
  • تراز آزمایشی جامع
  • تراز مبتنی بر الگوهای عملیات حساب – در این گزارش، تفکیک مستقل از خواست کاربر و مبتنی بر برچسب‌های موثر در کنترل مانده‌ی حساب انجام می‌شود.
  • تفکیک عملیات حساب به یک شماره‌ی تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به یک شماره‌ی تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به حساب‌ها (سرجمع)
  • تفکیک عملیات حساب به طبقات تفصیلی (سرجمع)
  • تفکیک عملیات تفصیلی به طبقات تفصیلی (سرجمع)
  • گزارش محوری جامع مالی – تفکیک عملیات برحسب برچسب‌ها در این گزارش به صورت عادی و همانند سایر سطوح سرجمع انجام می‌شود.
• ارائه‌ی گزارش های ریزعملیات و خلاصه عملیات از ترکیب حساب، تفصیلی و برچسب‌های سطر تحت مکان‌نما در گزارش‌های زیر
  • ملاحظه‌ی اسناد
  • گزارش خلاصه اسناد
  • تفکیک عملیات حساب به یک شماره‌ی تفصیلی (گروه‌بندی شده)
  • تفکیک عملیات تفصیلی به یک شماره‌ی تفصیلی (گروه‌بندی شده)
  • تفکیک عملیات تفصیلی به حساب‌ها (گروه‌بندی شده)
  • تفکیک عملیات حساب به طبقات تفصیلی (گروه‌بندی شده)
  • تفکیک عملیات تفصیلی به طبقات تفصیلی (گروه‌بندی شده)
  • گزارش از حاصل عملیات تصفیه
  • ریزعملیات یک مدرک دریافت و پرداخت
  • کاربرگ تسویه
  • ریز عملیات – حساب، تفصیلی، نهاد، مجموعه حساب و مجموعه تفصیلی
  • دفتر – حساب، تفصیلی و نهاد
  • تفکیک عملیات برحسب تاریخ سررسید – حساب، تفصیلی و نهاد
  • تفکیک عملیات به مدارک دریافت و پرداخت (گروه‌بندی شده) – حساب، تفصیلی و نهاد
• استفاده از برچسب‌ها در در شرایط ستون‌ها در تعریف فرم‌های زیر
  • تفکیک اسناد به اجزاء
  • تفکیک حساب‌های یک مجموعه به تفصیلی‌ها
  • تفکیک تفصیلی‌های یک مجموعه به حساب‌ها
  • تراز گروه‌بندی شده کلان
  • تراز آزمایشی جامع
  • تراز مبتنی بر الگوهای عملیات حساب

امکانات جدید ارائه شده در نسخه 15.02: ارائه‌ی مشخصات «مرجع برگشت سامانه مودیان» در گزارش‌های فروش

منظور از گزارش‌های فروش در اینجا همه‌ی گزارش‌هایی هستند که از فهرست رخدادها و برگه‌های فروش ناشی می‌شوند. اینها گزارش‌های متنوعی هستند که از مشخصات برگه‌های فروش، سطرهای اصلی جنبی، کسور و اضافات و پورسانت‌ها، به صورت فهرست، آماده می‌شوند. فهرست‌های مزبور در منوی فروش در اختیار قرار دارند و به جز آنها، انواع ریز عملیات را در منوی گزارش‌های فروش نیز در اختیار داریم.

ارتباط برگشت از فروش با فروش همیشه به صورت مستقیم وجود ندارد. تنها مواردی که می‌توانیم مطمئن باشیم که این ارتباط برقرار است، صورت‌حساب‌های برگشت از فروشی هستند که به سامانه‌ی مودیان ارسال شده‌اند. در این صورت‌حساب‌ها، احکام سامانه باعث می‌شوند که اولا به ازای هر سطر از صورت‌حساب حتما سطری از یک فاکتور فروش ابتدایی قابل تشخیص باشد و ثانیا این سطرها همگی مربوط به یک فاکتور فروش باشند. به این ترتیب آنچه در فیلدهای جدید ارائه می‌شوند مشخصات مرجع برگشت صورت‌حساب برگشت از فروش مطابق آنچه به سامانه‌ی مودیان ارسال شده است خواهند بود. به بیان دیگر این مشخصات فقط برای صورت‌حساب‌های برگشت از فروشی که به سامانه‌ی مودیان ارسال شده‌اند قابل ارائه خواهد بود.

نکته‌ی دیگر این است که مطابق احکام سامانه‌ی مودیان، مرجع برگشت لزوما یک فاکتور فروش نیست! اگر از قبل برای یک فاکتور فروش صورت‌حساب برگشت از فروش دیگری به سامانه ارسال شده باشد، مرجع برگشت صورت‌حساب فروش دوم، صورت حساب فروش اول خواهد بود. طبیعتا، مشخصات همان برگه در اینجا مورد توجه قرار می‌گیرند. فیلدهایی تحت عنوان کلی «مرجع برگشت سامانه مودیان» برای استفاده در این گزارش‌ها پیاده‌سازی شده‌اند شامل: شماره / سری، نوع برگه، کد و نام نوع فروش، شماره سند (در تمام بخش‌ها و در بخش مربوط)، تاریخ.

امکانات جدید ارائه شده در نسخه 15.02: امکان الحاق قرارداد به قراردادهای مربوط به سالهای مالی گذشته

با توجه به اینکه مرجع پیش‌فاکتور، قرارداد یا قرارداد الحاقی برای درخواست‌های کالا و خدمات از قبل می‌توانستند متعلق به سال‌های مالی قبل باشند، راه‌حل قبلی ما برای این وضعیت این بود که قرارداد الحاقی را نیز در همان سال مالی قرارداد مرجع درج کنند و پس از آن می‌توانند در درخواست‌های سال مالی جدید یا در فرآیند تنظیم خودکار برگه‌های درخواست و تحویل همزمان با تنظیم فاکتور فروش از آن استفاده کنند. نکته‌هایی که در زمان صدور چنین احکامی در نظر می‌گیریم، پیش از هر چیز، به ساده شدن مسیر عملیات مختلف سیستم متوجه هستند. کنترل تاریخ قراردادهای مرجع و الحاقی در 1) تنظیم قرارداد الحاقی جدید 2) اصلاح تاریخ یک قرارداد الحاقی موجود 3) اصلاح تاریخ یک قرارداد (که به عنوان مرجع برای یک قرارداد الحاقی لحاظ شده است) 4) تغییر تاریخ شروع عملیات پایگاه اطلاعاتی انجام میشود.

اما این کنترل‌ها در دو جا به ما کمک می‌کردند. 1) صدور و فراخوانی داده‌ها از مسیر فایل xml و 2) حذف اسناد و عملیات یک یا چند سال مالی در نرم‌افزار admin. مورد اول را تلاش کردیم با دقت زیاد مدیریت شود. در مورد دوم وضعیتی را تصور کنید که در سال n یک قرارداد «الف» تنظیم شده است و در سال n + 1 برای آن قرارداد الحاقی «ب» تنظیم شده است. قرارداد الف ممکن است در هر دو سال n و n + 1 (و حتی سال‌های پس از آن) به عنوان مرجع درخواست و فروش لحاظ شده باشد. قرارداد ب ممکن است در سال n + 1 همین وضعیت را داشته باشد. حال چه می‌شود اگر بخواهیم اسناد و عملیات سال n را در admin حذف کنیم. قرارداد ب فاقد مرجع خواهد شد و همانطور که می‌دانیم، طبیعتا، قرارداد الحاقی بدون مرجع قابل قبول نیست. این دلیل اصلی صدور حکمی بود که طی آن قراردادهای مرجع و الحاقی باید در یک سال مالی باشند.

کاری که در این موارد برای حفظ یکپارچگی داده‌های سیستم می‌توان انجام داد این است: 1) قراردادهای الحاقی با مرجع قراردادهایی که قرار است حذف شوند، خود باید حذف شوند. 2) از آنجا که این قراردادهای الحاقی ممکن است مرجع درخواست و فروش واقع شده باشند لازم است تا پیش از آن ارتباط درخواست‌ها با قرارداد الحاقی حذف شود. در واقع گام دوم باید پیش از گام اول انجام شود.

افزودن متد جدید WS_GetArtInf در سرور API حسابداری نوسا نسخه 15.02 جهت اخذ مشخصات سند از نرم‌افزارهای دیگر

این متد جدید WS_GetArtInf نام دارد. همانند تمام سایر متدهای API نوسا، این متد نیز نام پایگاه و XML ورودی را دریافت می‌کند و حاصل آن نیز یک رشته‌ی حرفی حاوی XML خروجی است. در مورد ساختار XMLهای ورودی و خروجی در ادامه توضیح خواهیم داد.

کاربر Web Service، در اجرای این متد همانند کاربری است که قصد دارد یک سند را «ملاحظه» نماید و به همین دلیل باید امکان ملاحظه‌ی سند را داشته باشد. اخذ مشخصات سند از نرم‌افزارهای مختلف (حسابداری، دریافت و پرداخت، انبار...) توسط این متد میسر است و طبیعی است که کاربر Web Service باید اختیار ملاحظه‌ی سند در نرم‌افزار مزبور را داشته باشد. به جز این، اگر سند مربوط به بخشی متفاوت از بخش(های) کاربر باشد، وجود اختیار «ملاحظه سند (سایر بخش‌ها)» هم بسته به نرم‌افزار سند ضروری خواهد بود.

موارد فوق شامل اختیارات مشترک بین کاربران عادی و کاربر Web Service بودند. به جز آنها، اختیارات اختصاصی برای اجرای عملیات از طریق Web Service هم پیش‌بینی شده‌اند که عملا مشخص کننده‌ی این هستند که کاربر اصلا حق دارد به عنوان کلاینت Web Service ایفای نقش نماید یا خیر. برای استفاده از متد اخذ مشخصات سند، کاربر باید اختیار زیر را داشته باشد:

امکانات / سیستم / مدیریت (Admin) / اخذ مشخصات سند از طريق Web Service

XML ورودی در این متد صرفا حاوی یک node به نام Params_ است – مثلا شبیه متدهایی که پیش از این برای دریافت اطلاعات از سرور داشتیم. در اینجا باید سند مورد نظر را با مشخصاتی که در این node درج می‌کنیم مشخص نماییم. این شبیه است به آنچه قبلا در متدهای حذف یا لغو درخواست‌ها یا اصلاح طرف حساب‌های برگه‌ی فروش داشتیم. شمای کلی XML ورودی این متد را در ادامه مشاهده می‌کنید:

<_Params Key... or BaseNum... or ImpId... />

شناسایی سند دقیقا شبیه شناسایی اسناد و برگه‌ها در متدهایی است که پیش از این داشتیم. در اینجا نیز شناسایی یک سند با استفاده از شماره توالی سند (Key)، یا شماری‌ مبنای سند (BaseNum) یا ImpId میسر است. شماره توالی سند، که در Client نیز بازنمایی می‌شود، همان کلید سند است که یعنی فیلد art_Key در جدول Arts_ در پایگاه داده‌های سیستم است. در کاربردهایی که مبتنی بر داده‌های سیستم نوسا طرح شده باشند یا به هر صورت، اگر کلید سند قابل شناسایی باشد می‌توان از شماره‌ی توالی برای مشخص کردن سند مورد نظر استفاده کرد. شماره‌ی مبنای سند نیز روش دیگری برای مشخص کردن سند است. تعیین ImpId نیز روش سوم برای مشخص کردن سند مورد نظر است. این سه روش را در نمونه‌های زیر مشاهده می‌کنید:

<_Params Key=”45682” />

<_Params BaseNum=”980456325” />

<_Params ImpId=”123980” />

در صورتی که قبلا از همین Web Service برای افزودن سند به سیستم استفاده شده باشد، هر سه مشخصه‌ی فوق به عنوان بخشی از نتیجه‌ی عملیات افزودن سند بازگردانده می‌شوند. توجه کنید که در این متد فقط یکی از سه مشخصه‌ی فوق را در Params_ انتظار داریم (و مشخصه‌ی دیگری، حتی مثلا Id هم در اینجا مطرح نیست). مشخصه‌ها به ترتیب و اولویت فوق مورد توجه قرار می‌گیرند – یعنی مثلا اگر Key ذکر شده باشد به دو مشخصه‌ی دیگر توجه نمی‌شود و سند از مسیر شماره‌ی توالی یافته و پردازش می‌شود. همانند سایر متدها، حاصل این متد نیز یک رشته حرفی حاوی یک XML به صورت زیر است.

<_RSLT ErrNo=".." ErrStr=".." ...attribute مشخصات سند به صورت... />

ErrNo همیشه وجود دارد که مقدار صفر آن یعنی اجرای موفقیت‌آمیز و مقدار مخالف صفر ErrNo به معنی خطا است. در این وضعیت عبارت توصیف‌کننده‌ی خطا در ErrStr داده خواهد شد. مشخصات سند در attributeهایی به صورت زیر ارائه می‌شوند:

خطاهای زیر در رابطه با این متد جدید به API اضافه شده‌اند:

افزودن متد جدید WS_ModifyDetAB در API نسخه 15.02 جهت اصلاح دفتر تلفن و نشانی یک تفصیلی یا تعریف رکورد تلفن و نشانی جدید برای تفصیلی

این متد جدید WS_ModifyDetAB نام دارد – Modify Detail Address Book. همانند تمام سایر متدهای API نوسا، این متد نیز نام پایگاه و XML ورودی را دریافت می‌کند و حاصل آن نیز یک رشته‌ی حرفی حاوی XML خروجی است. در مورد ساختار XMLهای ورودی و خروجی در ادامه توضیح خواهیم داد.

پیش از این در متد WS_AddDet، که برای تعریف همزمان تفصیلی، مرکز و اطلاعات تلفن و نشانی به‌کار می‌رفت، دیده بودیم که یک Node به نام ABRec_ در XML وجود داشت که مشخصات رکورد تلفن و نشانی «جدید» را در خود داشت. در WS_AddDet یک رکورد تلفن و نشانی با همان مشخصات تعریف می‌شد و به تفصیلی جدیدی، که آن هم در WS_AddRec تعریف می‌شد، مرتبط می‌گردید. در اینجا از همان ساختار و Node با همان نام ABRec_ استفاده می‌شود. همچنین کد تفصیلی مورد نظر به صورت یک attribute مشخص می‌شود. اگر تفصیلی از قبل مرتبط با یک رکورد تلفن و نشانی نبوده باشد یک رکورد جدید تلفن و نشانی تعریف شده و به آن تفصیلی ارتباط داده می‌شود. اما اگر تفصیلی مزبور از قبل مرتبط با یک رکورد تلفن و نشانی باشد، مشخصات همان رکورد تلفن و نشانی مبتنی بر attributeهایی که در ABRec_ درج شده‌اند اصلاح خواهد شد. در این حین فقط فیلدهایی اصلاح می‌شوند که در ABRec_ آورده شده باشند. به این ترتیب ساختار XML ورودی به صورت زیر خواهد بود:

  <_ABRec ... attrubite فیلدها به صورت... />

واضح است که تفصیلی مورد نظر باید از قبل وجود داشته باشد. کاربر Web Service، در اجرای این متد همواره مشغول «اصلاح یک تفصیلی» است و به همین دلیل باید اختیار مربوط را داشته باشد. به علاوه، اگر تفصیلی مستقل از بخش باشد، کاربر باید اختیار «تعریف یا اصلاح تفصیلی (غیروابسته به بخش)» را نیز داشته باشد. در مقابل، اگر تفصیلی مربوط به بخشی به جز بخش‌های کاربر باشد، کاربر Web Service باید اختیار «تعریف یا اصلاح تفصیلی (سایر بخش‌ها)» را نیز داشته باشد. اگر تفصیلی از قبل دارای رکورد تلفن و نشانی باشد، کاربر Web Service عملا مشغول اصلاح همان رکورد است و به همین دلیل باید اختیار «اصلاح دفتر تلفن و نشانی» را داشته باشد و در مقابل اگر تفصیلی فاقد رکورد تلفن و نشانی باشد، کاربر عملا مشغول درج رکورد تلفن و نشانی جدید است و باید اختیار «افزودن تلفن و نشانی جدید» را داشته باشد.

موارد فوق شامل اختیارات مشترک بین کاربران عادی و کاربر Web Service بودند. به جز آنها، اختیارات اختصاصی برای اجرای عملیات از طریق Web Service هم پیش‌بینی شده‌اند که عملا مشخص کننده‌ی این هستند که کاربر اصلا حق دارد به عنوان کلاینت Web Service ایفای نقش نماید یا خیر. برای استفاده از متد اصلاح تلفن و نشانی یک تفصیلی، کاربر باید اختیار زیر را داشته باشد:

امکانات / سیستم / مدیریت (Admin) / اصلاح تلفن و نشانی یک تفصیلی از طريق Web Service

یادآوری می‌کنیم که محتویات ABRec_ به صورت زیر تعریف شده‌اند:

همچنین گفتیم که اگر از این متد برای اصلاح یک رکورد تلفن و نشانی که از قبل موجود بوده است استفاده شود، فقط فیلدهایی که attribute متناظر با آنها در ABRec_ درج شده باشند اصلاح خواهند شد. مثلا XML زیر منجر به اصلاح «نام خانوادگی یا نام شرکت» در تلفن و نشانی مرتبط با تفصیلی “05/03/078” خواهد شد:

  <_ABRec Surname=”نام شرکت اصلاح شده” />

همانند سایر متدها، حاصل این متد نیز یک رشته حرفی حاوی یک XML به صورت زیر است.

<_RSLT ErrNo=".." ErrStr=".." />

ErrNo همیشه وجود دارد که مقدار صفر آن یعنی اجرای موفقیت‌آمیز و مقدار مخالف صفر ErrNo به معنی خطا است. در این وضعیت عبارت توصیف‌کننده‌ی خطا در ErrStr داده خواهد شد. خطاهای زیر قبلا در Web Service تعریف شده بودند و در این متد نیز ممکن است داده شوند:

همچنین خطاهای جدید زیر نیز به صورت اختصاصی برای این متد تعریف شده‌اند:

گسترش متد WS_AddDet در API نسخه 15.02 جهت افزودن سند دریافت و پرداخت بدون مدرک
 

متد مزبور پیش از این فقط برای تعریف سند حسابداری قابل استفاده بود. از بین سایر گونه‌های سند در سیستم، سند دریافت و پرداخت نیز توسط کاربر تنظیم می‌شود (سایر گونه‌های سند از قبیل انبار، فروش... توسط سیستم و مبتنی بر داده‌های سایر نرم‌افزارها ایجاد می‌شوند). اگر از ارتباط بین سطرهای سند دریافت و پرداخت و مدارک دریافت و پرداخت صرف‌نظر کنیم بقیه‌ی عملیات دقیقا همانند تنظیم سند حسابداری خواهد بود. به همین دلیل از این پس برای افزودن سند دریافت و پرداختی که فاقد مدارک دریافت و پرداخت باشد می‌توانیم از همین متد استفاده کنیم. به این منظور باید یک مشخصه به نام OSW (مخفف Owner Software) در مشخصات عمومی سند درج شود. اگر این مشخصه داده نشده باشد یا صفر باشد، همانند رویه‌ی قبل، سند حسابداری درج خواهد شد. برای درج سند دریافت و پرداخت این مشخصه باید با مقدار یک (به صورت OSW=”1&rdquo) در xml ورودی و در مشخصات عمومی سند داده شود.

خطاهای زیر در رابطه با تغییرات این متد به API اضافه شده‌اند:

خطای آخر در حالتی گرفته می‌شود که OSW مقداری به جز صفر یا یک داشته باشد.

گسترش متد WS_AddDet در Webservice در نسخه 15.02: گسترش متد WS_AddDet جهت تعریف تفصیلی یا مرکز سرگروه (غیرعملیاتی) جدید

این متد عملا برای تعریف «شخص» و به صورت ترکیب تفصیلی، مرکز و رکورد تلفن و نشانی بکار می‌رود. در این حین تفصیلی به مرکز و رکورد تلفن و نشانی نیز به تفصیلی مرتبط می‌شود. به یاد داریم که داده‌ها در Nodeهای مستقل از هم در XML دریافت می‌شوند:

  <_ABRec ... attrubite فیلدها به صورت... />

  <_DetL  ... attrubite فیلدها به صورت... />

  <_ICL   ... attrubite فیلدها به صورت... />

وجود nodeها اختیاری است و داده‌ها حسب مورد منجر به درج رکوردهای جدید در سیستم می‌شوند. به این ترتیب از همین متد می‌توانیم فقط برای تعریف تفصیلی یا مرکز نیز استفاده کنیم – نکته اینجا است که اگر ترکیبی از داده‌ها در XML ورودی تامین شوند، ارتباط بین آنها نیز توسط سیستم برقرار می‌گردد. تا پیش از این تفصیلی و مرکز در این متد حتما باید عملیاتی (Leaf – برگ درخت) می‌بودند. از این پس با تعیین اختیاری دو مشخصه در DetL_ و ICL_ می‌توان از همین متد برای تعریف تفصیلی یا مرکز سرگروه (غیرعملیاتی) نیز استفاده شود.

قاعدتا نام Nodeها دیگر نمی‌بایست DetL(eaf)_ یا ICL_ می‌بودند اما برای اینکه تغییرات ما تاثیری در کدهایی که تا پیش از این با این متد نوشته شده است نشوند آنها را به همان صورت حفظ کردیم. همچنین هر دو مشخصه‌ی پیش‌گفته، همانطور که پیش از این اشاره کردیم، اختیاری هستند و اگر درج نشوند رفتار سیستم دقیقا همانند ویرایش‌های قبلی خواهد بود؛ یعنی تفصیلی و یا مرکز عملیاتی تعریف خواهد شد.

در ایجاد داده‌های جدید به محدودیت‌ها (و آزادی عمل‌ها)ی موجود در خود سیستم توجه شده است: یک تفصیلی سرگروه می‌تواند به یک رکورد تلفن و نشانی مربوط باشد + یک مرکز سرگروه می‌تواند به یک تفصیلی مربوط باشد + مرکز نمی‌تواند به یک تفصیلی غیرعملیاتی مربوط باشد. با توجه به این نکات کماکان می‌توانیم ارتباط بین رکوردها را برای تفصیلی یا مرکز سرگروه نیز ایجاد کنیم؛ یعنی همزمان به تعریف هر سه رکورد در یک اجرای متد بپردازیم – هر چند احتمالا کاربرد اندکی دارد و در بیشتر مواقع از امکانات جدید این متد برای تعریف یک تفصیلی یا مرکز سرگروه، بدون ارتباط، استفاده خواهد شد. تنها خطای جدیدی که ممکن است پیش بیاید در زمانی است که ترکیبی از تفصیلی و مرکز داشته باشیم و تفصیلی داده شده غیرعملیاتی باشد. مرکز نمی‌تواند به تفصیلی غیرعملیاتی متصل شود و این خطا است:

برخی دیگر از امکانات پیاده‌سازی شده یا بروز شده در نسخه 15.02 نرم‌افزار مالی یکپارچه نوسا به تفکیک نرم‌افزار زیر مجموعه

• عمومی: تعریف یک فیلد اختصاصی تنظیم کننده صرفا برای استفاده در صدور اطلاعات اسناد از پایگاه داده مبدا به مقصد و فراهم نمودن قابلیت استفاده از شریط بر مبنای تنظیم کننده طی آن.

• حسابداری: از این پس در ایجاد رخدادهای مالی با استفاده از تکنیک Drag / Drop، برچسب‌های رخدادها در مدل T این نرم‌افزار نیز کپی می‌شوند.

• انبار: در برگه‌های درخواست کالا، محل کالا در انبار به فیلدهای قابل استفاده در فرم برگه اضافه شده است.

• انبار: از این پس می‌توان از فیلدهای شماره‌ی عطف سند، شماره‌ی ارجاع برگه و شماره‌ی پیگیری برگه نیز در موارد زیر استفاده کرد:
  • در قوانین شرح رخدادهای انبار
  • در تعریف شرح در قوانین طرف حساب در الگوی عملیات مالی کالاها (انبار)
  •  در تعریف شرح در قوانین طرف حساب عمومی برگه‌های انبار

• انبار: در همه‌ی گزارش‌های مبتنی بر رخدادهای انبار از این پس فیلدهایی تحت عنوان کلی «پیش‌فاکتور یا قرارداد مرجع» ارائه می‌شوند. این فیلدها در تعریف فرم‌ها قابل استفاده خواهند بود و عبارتند از شماره/سری، تاریخ، تاریخ خاتمه‌ی اعتبار و تاریخ سررسید تحویل.

برخی  تغییرات و اشکالات رفع شده در نسخه 15.02 نرم‌افزار مالی یکپارچه نوسا به تفکیک نرم‌افزار زیر مجموعه

• عمومی: برای پشتیبان‌های تهیه شده از سیستم، همواره نرم‌افزار یک شرح برای بازنمایی عنوان پشتیبان، نام شرکت و سایر اطلاعات آماری و اضافه (تاریخ، وضعیت و تعداد اسناد به تفکیک نرم‌افزارها) آماده می‌کند. SQL Server برای این شرح محدودیت 255 حرفی قائل شده است که در مواردی منجر به یک اخطار (غیرمخرب) در حین تهیه پشتیبان می‌شد. برای ممانعت از بروز این خطا ترتیبی دادیم که اولا فقط 40 حرف ابتدای نام شرکت در شرح پشتیبان درج شود و ثانیا اطلاعات آماری تا جایی که اندازه‌ی شرح به 255 حرف نرسیده باشد به شرح اضافه شوند.

• عمومی: اگر یک کاربر به عنوان آخرین اصلاح کننده در سطرها یا رخدادهای پیش‌فاکتور یا قرارداد، درخواست کالا، درخواست خدمات، انجام خدمات ایفای نقش کرده باشد، طبیعتا، امکان حذف کاربر از سیستم وجود ندارد. صرفا پیغام خطای مربوطه تا این نسخه به صورت نادرست و با کدهای داخلی SQL Server نمایش داده می‌شد، اعلام خطای فارسی اضافه شد.

• حسابداری: در تراز گروه‌بندی شده‌ی کلان، در نسخه کلاینت Win64، در صورت زیاد شدن تعداد سطوح گروه‌بندی (ترکیب سطوح تعریف شده و برچسب‌های انتخاب شده) با خطا مواجه می‌شدیم، این خطا رفع گردید.

• دریافت و پرداخت: در روال‌های دریافت و پرداخت، وقتی طرف فرعی روال «همان نهاد و حساب‌های طرف اصلی» باشد، امکان کار با مدرک دریافت و پرداخت در طرف فرعی وجود نداشت و خطای "نهاد یافت نشد" داده می‌شد، این مشکل برطرف شد.

• انبار: در فراخوانی برگه‌های رسید موقت از فایل صادره، فیلد "سریال" فراخوانی نمی‌شد، این فیلد اضافه شد.

• انبار: در ذخیره‌ی برگه‌ی رسید موقت در فایل وارده‌ XP، سریال رخدادها ذخیره (و فراخوانی) نمی‌شد، این سریال‌های اضافه شد.

• انبار: در کپی برگه‌ی رسید موقت، سریال رخدادها کپی نمی‌شد، این اطلاعات اظافه شد.

• انبار: در فرم‌های برگه‌های ورود انبار، اگر از مولفه‌ی ناحیه استفاده می‌شد و تعیین می‌شد که این ناحیه "فقط در صورت وجود سطرهای انتخاب (علامت‌گذاری) شده بازنمایی شود"، ناحیه‌ی مزبور با انتخاب تعدادی از سطرهای برگه‌ی ورود بازنمایی نمی‌شد، این مشکل برطرف گردید.

• فروش: در ویرایش پیش‌فاکتورها و قراردادها، با حذف سطر، مکان‌نمای برگه به اولین سطر برگه منتقل می‌شد، تغییر رفتار انجام شد تا به اولین شطر نرود.

• فروش: تعریف فرم‌های برگه‌های درخواست کالا برای کاربرانی که فقط مجاز به استفاده از نرم‌افزار فروش بودند میسر نبود. یعنی امکان واگذاری اختیار انجام آنها به آن کاربران وجود نداشت، هر چند این رفتار طی تعریف بود، ولیکن بنا به نیاز کاربران، این امکان بصورت محدود به کاربران فروش ارائه شد.

• فروش: در چاپ فهرست رخدادهای انجام خدمات، پارامترهای الگوی کد انجام‌دهنده‌ی خدمات و کد انجام‌دهنده‌ی خدمات شروع محدوده، در محاوره‌ی ابتدایی چاپ جا به جا شده بودند، این مورد اصلاح شد.

• فروش: در گزارش اعتبار یک مرکز (طرف بدهکار)، در فهرست کالاهای فاکتور نشده، فقط برگه‌های پیش‌نویس بازنمایی می‌شدند، این شرایط بروز شد.

• فروش: در فهرست پورسانت‌های برگه‌های فروش، در صورت انتخاب گزینه‌ی "سرجمع برحسب قانون و انجام‌دهنده‌ی خدمت" در دریچه‌ "رخداد / نحوه‌ی بازنمایی فهرست" با خطا مواجه می‌شدیم، این خطا برطرف شد.

• فروش: در تنظیم فاکتور فروش جدید، کاربری که اختیار تنظیم فاکتور برای سایر بخش‌ها را داشته باشد می‌تواند بخش سند فاکتور فروش را تغییر دهد. این تغییر اگر از محاوره‌ی حافظه‌ی مالیاتی انجام نشود (مستقیما برای سند انجام شود) منجر به تغییر "کد شعبه فروشنده" پیش‌فرض حاصل از ترکیب حافظه‌ی مالیاتی و بخش نمی‌گردید. توجه کنید که تغییر خودکار این کد پیش‌فرض همواره فقط در صورتی انجام می‌شود که کاربر خودش آنرا تغییر نداده باشد.

پایان

-- گروه توسعه نرم‌افزارهای مالی نوسا
   تیر ماه سال 1405