Tanya,

I have to admit, I was not aware of that limitation but now that I think of it, it does make sense based on how the program stores the foreign currencies by vendor/customer. I just tried to adjust the A/P account and it gave me a message about having to be in home currency just as it did for you.

At this point there is not much else we can help with...unless you are willing to let us know what the entry was and why you need to post it. I don't do a lot of foreign currency entries but I have yet to post one that does not need to affect the Canadian equivalent. Last week I did fix a bank account that was off by in CAD by over $100K when compared to the USD but the USD was accurate according to the bank statement (so not the same issue). Normally you would only need to post to a control account if the control account balance vs. the subjournal were not the same.

Maybe you could give us more information and then we can help a little more.

Sorry to hear you have problems with support but it does not surprise me. When I first started at the company I am presently working at, I was brand new in the world of Sage. I had bookkeeping background but didn't know much about how it worked in the background. Since I had to fix things the previous girl did I went to support for help. Let me say that I did not get any help from them. It seemed that all they do is read from a script. I had to argue with them!! What a bad experience. I finally found this group and posted my issue here. The answer I got here was EXACTLY what I wanted to hear! I knew what I wanted to do was correct, I just didn't know HOW to do it. You guys are AWESOME and gave me the answer I needed! I never called support again. This is where I turn from now on.

Two entries from the sub-ledger got messed up and so did not post their entries to the control accounts. My general and my sub did not match by those 2 entries. The how it happened, moot point, restoring from a backup, not an option as it had happened sometime in the previous 'month' so not an option. I know what happened and am trying to ensure it doesn't happen again, but the resolve to it is having to post to the control accounts to fix the problem so that the general and the sub's match due to these missing entries. 1 we could post, as it was Cdn, but the US would not. Even with the exchange, if everything is dated the same day, the exchange rate would match up, so the US entry posting 'should' be enabled as the G/L entry would match the subledger amount, just seems to be overlooked or something, and definitely should be something the support staff are aware of to avoid someone else's frustration. I will have to get creative to fix this at this point as the entry 'has' to be made to bring things into balance. (Thought I had sent this reply in already, but day has been hectic lol)

It sounds like your data integrity is out on your Accounts "something" account. Is it possible that your Debits do not equal Credits as well?

These are the types of entries I don't think can be fixed directly with the user interface but I can't tell from the information provided.

Sorry I feel like I am in the same situation as your consultant who tried to help you out before but couldn't. Maybe someone else has an idea.

Database checks out ok, debits/credits are ok, I'm literally missing the debit/credit of the entire entry, so that's why everything 'balances' to a point, but if I check my A/P and A/R subledger, I was missing the debit payable/credit bank on the Cdn side (which has been remedied) and I was missing the debit A/R, credit sales on the A/R side, (which was where the problem posting to the US account became an issue) There are some, in my opinion, programming issues that allowed for this scenario, as if you are going to allow certain transactions to take place, there should be safeguards then built in place to prevent these issues, and barring that, allow someone to be able to post to fix them. Restrict it to the sysadmin or 'something' but to not allow that either, has people in positions where it's broke and they say it can't be fixed. That's what I was told, that I wouldn't be able to fix it, so essentially, I was told to live with my G/L and subledgers being out of balance. Hmmmmm, pay a lot of money for something that I'm being told can't be fixed when it breaks.....*shrug* Like I said, I'll have to get creative.

.. I was missing the debit A/R, credit sales on the A/R side..
who is the customer ? is it a US sales ? why can't you create an invoice ?

Because the invoice 'is' in the subledger, it's not in the general ledger, that's the problem. I create an invoice, and all it does is posted it to the subledger again, and now to the G/L, but I'm still out my original entry, so now twice in the sub, once in the G/L. The customer shows the invoice. It didn't come through to the G/L. It's US sales, further compounded by Sage not allowing for US G/L entries even with the Accountants edition.

so you create an invoice, and the GL is not updated, and the ar subledger shows an increase in the customer's balance
are you setup for multi currency ? is the customer setup for US currency ? what is the exchange rate being used ?
if you retrieve the invoice and type control-J to display the journal entry is it properly recorded ?
if you display the transactions for the 'us sales account', is the entry there ?

I've done all my research, I spent days scouring the entire system. I know what is broke and isn't broke, the subledger is fine, the g/l is not. The g/l is missing the entries, I can't post them directly even with an Accountants version because of either a programming oversight, or 'something' The support staff argued with me on this point, they need to be enlightened on the limitations of the program to avoid other people becoming frustrated and losing so much time, as it is, I will be getting a rather large bill for using up so much of a CA's time (not by choice) to try to do what they said it could do for something that should have taken 2 minutes, tops, as we struggled to get it to do something they said it could but in reality, couldn't. They need to implement better safeguards when allowing certain transactions to take place to prevent this problem from occurring. I have better safeguards in place as well now because to err is human and someone made a mistake that caused this, however, doesn't change the fact there are, in my opinion, some design flaws that allowed this problem to happen to begin with. As stated in my original post, it's a US entry, that is perfectly fine in the subledger, the control accounts are not updated to reflect it.

so you posted a US sales invoice, the AR is correct, the GL is not - correct ?
can you retrieve the invoice ? if so, can you alter it by 1.00 and post it ? does that fix the problem?
you seem to know how the problem was created (design flaw), can you it explain the process, to see if it can be duplicated ?

Sage allows for importing of entries, what it does not do is prevent the same 'journal entry number' from being used when this is going on. In other words, while entries are importing, nobody else can post 'anything' or risk merging of the entries as the same journal entry will get used. This can and would be able to happen again quite easily if not very very careful. It hasn't been an issue in a long time, but new employees tend to make mistakes.......this is what I feel should have better back end preventative programming. If allowing for importing of entries, better safeguards/programming to ensure the same journal entry can't be used. So the new employee accidentally posted a payment while A/R invoices were importing, resulting in the merging of a payment and a sales invoice. The end result is you are missing some sides to the equation, usually the GL side of things. When you originally look at the journal entry of each of the entries in the subledger, you see both merging entries in there, IE, you look up the sales invoice and look at the journal entry, you can also see the debits/credits of the AP payment. To straighten that out, you pretend to 'adjust' the subledger entry but do nothing except post it. That removes those extra sides of duplication that were created. The end result is however, because they merged, you are left missing some 'sides' of debits/credits that didn't make it through to the control accounts. We had this happen once before years ago except were lucky enough that it was Cdn/Cdn and so could post the fix using an Accountants version, in this case however, because the sale was US, they didn't program the Accountants version to allow for a US posting to the control accounts which would have been a real easy fix. I have taken steps to make sure the system will be in single user mode going forward lest someone 'forget' again, but as I said previously to err is human. But to not enable to be fixed? That's bad design.

Tanya B said:

Sage allows for importing of entries, what it does not do is prevent the same 'journal entry number' from being used when this is going on.

Were you importing sales invoices from a formatted .IMP file?  I thought those could only be imported in 'Single User Mode'.

Tanya,

If you go to select from the Home Windows, File, Import/Export..., you will notice you cannot Import Transactions when you are in multi-user mode, only single-user mode. The last time I ran one, I believe once you start an import, you can't do anything else, but I have never tried to get around it because I don't multi-task when doing mass updates.

If you are using some other method to import, then it sounds like the programmer who did that other method did not program it to validate properly and therefore, this is not a Sage issue, it is a corruption issue with the people who did your third party programming or as you said, caused by the new employee who may not have been following the prescribed procedure.

I hate to say it but based on this new information, the cause of the problem does not appear to be Sage's programming or the Sage 50 program itself. However, as I said before, I am surprised a foreign currency entry could not be posted in the General Journal by the Accountant's Edition.

It would be worth going to Help, Contact Sage, Give us your feedback and putting in a request to have this changed for the future. I have recently spoken with the product manager about putting new features into the Accountant's Edition but because I was not aware of this at the time, I did not mention it. If I get a chance to talk with him again, I will try to remember to bring it up. He does look at that list under Give us your feedback, so please post there.

All I can say is this set up was in place long before I ever got here (almost 8 years ago) so it's all I know of to be 'correct'. We can import in multi-user mode, that's never been an issue, as it can be a problem when you have others logged in and they aren't around to get logged out, (another way to fix that would be to have a handy dandy, 'kick user' button if they go to lunch and forget to log out) it's when someone forgets after you send notice to 'not do this' and boom, there is an oopsies, but it hasn't happened in years, like I said, new employee, forgot, problem created. Restoring from a backup wasn't an option because it had happened sometime over the previous month when the problem was discovered, that just wasn't feasible. The importing is done using an approved utility that maps the information into a excel or text document perhaps? (without going and looking and digging as it's really a moot point) from one program and into the other. And I never said Sage's programming was the cause, it's what is preventing me from fixing the problem, or perhaps better safeguards, I know the 'cause' just wish there was something better in the b/g to stop the problem or a little more foresight to allow the problem to be fixed. I will put in the suggestion on the feedback as you suggested, my original post on this forum was to provide insight into an unknown limitation to hopefully prevent others from experiencing the frustration I felt and wasted time and to make people aware (including sage support staff) of the problem so they aren't getting incorrect advice like I got. Like I said before, I am going to have to get creative to fix this due to the restrictions and limitations of the current programming.

Tanya B said:

The importing is done using an approved utility that maps the information into a excel or text document perhaps? (without going and looking and digging as it's really a moot point) from one program and into the other.

I won't ask you to name the developer of the product, it may not be locking the right tables, or the transaction is recorded as a series of data changes, instead of one change.

In the SDK information, in the current edition of dev-progref:

"Logical transactions start via wSDBTransBegin and end via wSDBTransCommit or wSDBTransRollback.

• All database updates (insert/update/delete) must occur within a transaction."

I would think that since incrementing the next journal number is part of the transaction, it should be possible to make a reliable utility that will import transactions in multi-user mode.  Feedback from Sage on why they require Single User Mode is that there can be performance issues - other users could think that the system had hung up.

My $.02 on allowing the Accountants' Edition to post entries to linked multicurrency accounts is that while there is a small potential for good, there is a large potential for harm.  If the utility that you use can be fixed, there is no need for these other entries - and being able to correct the G/L balance would not correct a broken, double-linked entry that was caused by this third-party utility.