Exportar lançamentos para o contador

في إعدادات الشركة ▸ المحاسبة: (1) نظام مكتبك المحاسبي — Domínio أو Alterdata أو Questor؛ (2) رمز شركتك داخله، الذي يزوّدك به المحاسب؛ (3) رمز البيان الافتراضي، الذي تشترطه التنسيقات الثلاثة إضافة إلى النص. من دون اختيار النظام يرفض التوليد ويذكر ما الناقص — عمدًا: فاختيار تنسيق نيابةً عنك سينتج ملفًا معقولًا لكنه خاطئ، لن يكتشفه إلا المحاسب.

تتوقع التنسيقات الثلاثة رمز الحساب في دليل حسابات المكتب (رقم مختصر)، لا الرمز الهرمي لـ Tenka (1.1.01). هذا الرقم موجود في حقل "الرمز الخارجي" في دليل الحسابات. الحساب الذي يفتقده يخرج برمز Tenka وسيرفض المستورد ذلك السطر — وتسرد الشاشة هذه الحسابات بالاسم. الرفض الظاهر أفضل من رقم مشابه يُستورد إلى حساب آخر.

مركز التكلفة (السجل 6110 في Domínio، والعمودان H وI في Alterdata) يخرج فارغًا، لأنه لا توجد مطابقة بين مركز التكلفة في Tenka ورمز المركز في نظام المكتب — وإرسال رقم Tenka سيوزّع على المركز الذي يصادف أن له تلك القيمة هناك. وللسبب نفسه يخرج حقل "القيد التلقائي" في Alterdata فارغًا: فهو يشير إلى نموذج مسجل داخل Alterdata، والنموذج هو الذي يحدد الحسابات.

الإعداد لكل شركة، وهذه هي الحالة الشائعة: في مجموعة متعددة CNPJ تكون كل شركة عادةً لدى مكتب محاسبي مختلف، والتنسيق يتبع المكتب لا المجموعة. من لديه مكتب واحد للمجموعة كلها يملؤه على مستوى الـ tenant: وقيمة الـ tenant تسري على جميع الشركات التي لا تستبدلها.

كل قيد تلقائي في Tenka يولد بفترة في اليوم الأول من الشهر. لميزان المراجعة لا فرق؛ أما لـ Domínio وAlterdata ففرق، لأنهما يطلبان تاريخ القيد. لذا يُعاد بناء التاريخ: التحصيل والدفع يستخدمان تاريخ تسوية السند، والفوترة تستخدم تاريخ الاستحقاق. وحين لا يوجد سند وراءه — الرواتب، والضرائب، والإهلاك — يصبح التاريخ آخر يوم في الشهر، وهو التاريخ المحاسبي الصحيح لمخصص الإقفال. تعدّ الشاشة كم سطرًا في هذه الحالة، ويُحفظ العدد مع الملف. التقريب المعلن تقريب؛ والتقريب المسكوت عنه خطأ.

كشف رواتب الشهر قيد واحد بثلاثة أطراف: مدين في مصروفات الموظفين، ودائن في الرواتب المستحقة الدفع، ودائن في الضرائب المستحقة التوريد. لا تقبل التنسيقات الثلاثة إلا أسطر الأزواج (حساب مدين وحساب دائن). يقسم Tenka هذا القيد إلى سطرين مجموعهما مطابق لمجموع القيد الأصلي — وهو ما كان المحاسب سيفعله يدويًا. ما لا يفعله هو إرسال الزوج الأول فقط: فذلك سيضيّع مالًا دون أي خطأ.

إذا لم يتساوَ مجموع المدين مع مجموع الدائن في أي قيد، فإنه يبقى خارج الملف ويظهر في قائمة المرفوضات مع الرقم والفرق. لسببين: Questor يرفض الملف كله حين يجد فرقًا بين المدين والدائن، وDomínio سيقبل الدفعة المختلة دون اعتراض — والثاني أسوأ. الفرق عيب في التسجيل المحاسبي، ومكان إصلاحه هو المحاسبة ▸ الترحيل المحاسبي.

لأن المستوردين الثلاثة برامج Windows قديمة تقرأ بترميز CP1252. ملف UTF-8 لا يسبب خطأ: بل يُستورد ويسجّل "PROVISÃO" بعلامات مشوّهة في دفتر الأستاذ لدى العميل — عيب لا يظهر إلا بعد أسابيع، في تقرير مطبوع. معامل الترميز موجود لحالة تأكيد مكتبك أنه يقرأ UTF-8؛ وإن تُرك فارغًا يخرج بالترميز الافتراضي للتنسيق. ويُنزَّل الملف دائمًا بالترميز الذي خُتم به، حتى لو تغيّر المعامل لاحقًا: وإلا لما تطابق الـ hash.

لا. الحفظ متماثل الأثر لكل شركة + تنسيق + فترة: إعادة التوليد تستبدل ملف ذلك الشهر بذلك التنسيق بدلًا من تكديس النسخ. ولأن الأسطر تخرج دائمًا بالترتيب نفسه، فإن إعادة توليد الفترة نفسها تنتج الملف نفسه — وهذا ما يجعل hash SHA-256 مفيدًا للتحقق مع المحاسب من أن ما تلقاه هو ما أرسلته.