Collecting local functionalities

Miklos_HollenderMiklos_Hollender Member Posts: 1,597
edited 2006-06-27 in General Chat
Dear friends,

I'd like to collect a short list of (important) local functionalities, because what's developed in one country, might be useful in another one as well. Please post yours.

Hungarian:

- Handling VAT Fulfillment Date - if you Credit Memo an Invoice from an earlier VAT reporting perioud, you must be able to Post it to the Credit Memo date but report VAT to the original date

- Deducting VAT you did not yet pay to your vendors, because you cannot claim that back. Basically it's a whole new report, VAT Analytics, instead of using VAT Statements. Kinda sucks, it's better to customize the Statements.

- Advance Payments. Basically, an Advance Payment Document is similar to an invoice. You can "import" available Adv. P.-s to Invoices as a negative line. You can see the balance of Adv. P.-s on the Customer Card.

- Corrective Invoice. Very important. It's an invoice that corrects a previous one instead of Credit Memoing it, in an "original line", "corrected line", "difference" fashion. Very important requirement.

- Exporting Intrastat to CSV to send to the statistics bureau

- Calculate discounted unit price from line/inv. discount and showing it on the invoice. Very hand for those customers who never managed to grasp the sophisticated concept of percentages...

- Storing shipment method in the Intrastat Journal (shouldn't it become a general feature everywhere in the EU?)

- Central bank exchange rate for Currencies - for Intrastat

- Default unit of measure for Intrastat

- Depreciation for 365 days instead of 360

- Reports: Customer/Vendor Open Entries (a simple entry list, for those users who can't read on the screen)

Features not implement, but we generally add as a mandatory customization:

- No. Series date order for Invoices based on Document Date instead of Posting Date. Basically, a Document Date represents when an invoice has been issued, and we use Posting Date as fulfillment date (when the product or service was shipped or fulfilled).

- We typically disable invoicing from an order, because if you try it, and it stops due to an error, and invoice it from an invoice, then there will be a hole in the numbering series and tax inspectors here get very upset by that, they think you have deleted an invoice to "save" on tax.

Please post your local features.

Comments

  • kinekine Member Posts: 12,562
    May be, if you ask Microsoft, they will send you the list of local changes... :-) There are documentations about the local changes.
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,597
    Yeah, but the whole point would be to pick what we need from others, and then start to bug MS three times a week to have them put it in ours too :)
  • kinekine Member Posts: 12,562
    But you can ask Microsoft "Hey, can you send me list of all local modules for all country versions?" ;-)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • HalMdyHalMdy Member Posts: 429
    kine wrote:
    But you can ask Microsoft "Hey, can you send me list of all local modules for all country versions?" ;-)

    I've received this kind of document in the past, and it was not very explicit about dev. As Miklos, I think that everybody here could give some feedback about his "locals" , no ?

    For example, at this moment I am very interested to have this kind of information concerning US version ... Of course, I could find my way in the DB or ask Crosoft to help me, but feedback from people "in the real life" should be better ...
  • Marije_BrummelMarije_Brummel OlstMember, Moderators Design Patterns Posts: 4,262
    Navision is localised for 30+ contries, imagine the length of this topic :o

    dynamicsusers.org has localy forums for some countries, if you want to know something, ask there.
  • kinekine Member Posts: 12,562
    HalMdy wrote:
    I've received this kind of document in the past, and it was not very explicit about dev. As Miklos, I think that everybody here could give some feedback about his "locals" , no ?

    I am not against it. I just wanted to know, if he tried this way... People are not used asking Microsoft for informations... ;-)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,597
    30+ posts. Wow! Maybe we should buy Luc a mainframe to store that... :D
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,597
    But you can ask Microsoft "Hey, can you send me list of all local modules for all country versions?"

    <sneaking on> Maybe if an MVP tried it, wouldn't it be more effective? :D <sneaking off>
  • kinekine Member Posts: 12,562
    May be yes... :-) but I need more info about what others tried to be able to support why I am using non-standard ways to dig the info... ;-)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • Marije_BrummelMarije_Brummel OlstMember, Moderators Design Patterns Posts: 4,262
    OK. ok. I'll forward a link to this topic to a friend of me who is working at localisation for EMEA. Just that, nothing more.

    You should know that some localisations are historic features that were implemented when localisation was not done centraly.

    For example in GB they have extended all Description fields to 50. I imaginge this is a horrible job for these guys to do every release.

    But in belgium the primairy key of the G/L account table is a text field because of sorting problems, you don;t want that in all datases either.
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,597
    For example in GB they have extended all Description fields to 50. I imaginge this is a horrible job for these guys to do every release.

    You mean exporting all tables in text and writing probably 3 lines of Perl/PHP/Python/Ruby whatever to write a regex that matches *Name* OR *Description* AND *Text30* and changing the later to Text50? And running it at each release? Or doing it even without coding, just using a regex-search-replace-capable editor, like EMACS? Must be a horrible job, indeed :D
  • kinekine Member Posts: 12,562
    For example in GB they have extended all Description fields to 50. I imaginge this is a horrible job for these guys to do every release.

    You mean exporting all tables in text and writing probably 3 lines of Perl/PHP/Python/Ruby whatever to write a regex that matches *Name* OR *Description* AND *Text30* and changing the later to Text50? And running it at each release? Or doing it even without coding, just using a regex-search-replace-capable editor, like EMACS? Must be a horrible job, indeed :D

    And what about all parameters in all functions where you are passing the description as parameter and the parameter is Text30 and has name like Descr, Text, etc.??? :-)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,597
    Are you sure they exist? I only saw it passed through record variables.
  • kinekine Member Posts: 12,562
    And are you sure that they do not exist??? 8)

    I never saw God but I believe... ;-)
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,597
    Fairly sure, because the standard way is to push stuff through record vars either the usual way or with TRANSFERFIELDS. But that also can be figured out with a regex that matches something.Description := or something.VALIDATE(Description ... :)
  • krikikriki Member, Moderator Posts: 9,043
    They exist.
    Years ago, a colleague has done it for a customer and even months after the change, errors came up about putting txt80 in txt30.
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!

Sign In or Register to comment.