MYOB ODBC (Invoice generation with correct Tax calculation) - odbc

We are connecting to MYOB AccountRight Enterprise v19 with ODBC direct v10.
We are creating Invoices in MYOB using the same.
We sent only the tax code i.e. GW in the ODBC call to MYOB, however, in that case no tax got calculated in the Invoice created in MYOB, probably the TransPost didnt work when the code was sent through ODBC
Then we sent the total tax (GST+WET) in the GSTAmount field as there wasn't any separate field for WET. In that case, Total tax was reflected coorectly in the Invoice generated in MYOB but the GST and WET split up was incorrect
The aim is to generate the Invoice in MYOB with correct total amount, including tax component values (GST and WET)
Please advise ASAP
Thanks

Consolidated tax can be tricky to get right. Without more details I am unable to comment on precisely what you might be doing wrong; there are many possibilities, ranging from your construction of import records to the way the items and/or services you are importing are set up in the target system.
You can however test the import behaviour to find out what works best for you. The ODBC driver does not connect directly to the (ISAM) database, but invokes the import/export facility of the MYOB executable. Look at the import/export data menu option in the UI. Export sales first so you can work out the file format. You can then see what happens when you vary the data you submit.
Good luck.

Related

Ingesting Google Analytics data into S3 or Redshift

I am looking for options to ingest Google Analytics data(historical data as well) into Redshift. Any suggestions regarding tools, API's are welcomed. I searched online and found out Stitch as one of the ETL tools, help me know better about this option and other options if you have.
Google Analytics has an API (Core Reporting API). This is good for getting the occasional KPIs, but due to API limits it's not great for exporting great amounts of historical data.
For big data dumps it's better to use the Link to BigQuery ("Link" because I want to avoid the word "integration" which implies a larger level of control than you actually have).
Setting up the link to BigQuery is fairly easy - you create a project in the Google Cloud Console, enable billing (BigQuery comes with a fee, it's not part of the GA360 contract), add your email address as BigQuery Owner in the "IAM&Admin" section, go to your GA account and enter the BigQuery Project ID in the GA Admin section, "Property Settings/Product Linking/All Products/BigQuery Link". The process is described here: https://support.google.com/analytics/answer/3416092
You can select between standard updates and streaming updated - the latter comes with an extra fee, but gives you near realtime data. The former updates data in BigQuery three times a day every eight hours.
The exported data is not raw data, this is already sessionized (i.e. while you will get one row per hit things like the traffic attribution for that hit will be session based).
You will pay three different kinds of fees - one for the export to BigQuery, one for storage, and one for the actual querying. Pricing is documented here: https://cloud.google.com/bigquery/pricing.
Pricing depends on region, among other things. The region where the data is stored might also important be important when it comes to legal matters - e.g. if you have to comply with the GDPR your data should be stored in the EU. Make sure you get the region right, because moving data between regions is cumbersome (you need to export the tables to Google Cloud storage and re-import them in the proper region) and kind of expensive.
You cannot just delete data and do a new export - on your first export BigQuery will backfill the data for the last 13 months, however it will do this only once per view. So if you need historical data better get this right, because if you delete data in BQ you won't get it back.
I don't actually know much about Redshift, but as per your comment you want to display data in Tableau, and Tableau directly connects to BigQuery.
We use custom SQL queries to get the data into Tableau (Google Analytics data is stored in daily tables, and custom SQL seems the easiest way to query data over many tables). BigQuery has a user-based cache that lasts 24 hours as long as the query does not change, so you won't pay for the query every time the report is opened. It still is a good idea to keep an eye on the cost - cost is not based on the result size, but on the amount of data that has to be searched to produce the wanted result, so if you query over a long timeframe and maybe do a few joins a single query can run into the dozens of euros (multiplied by the number of users who use the query).
scitylana.com has a service that can deliver Google Analytics Free data to S3.
You can get 3 years or more.
The extraction is done through the API. The schema is hit level and has 100+ dimensions/metrics.
Depending on the amount of data in your view, I think this could be done with GA360 too.
Another option is to use Stitch's own specfication singer.io and related open source packages:
https://github.com/singer-io/tap-google-analytics
https://github.com/transferwise/pipelinewise-target-redshift
The way you'd use them is piping data from into the other:
tap-google-analytics -c ga.json | target-redshift -c redshift.json
I like Skyvia tool: https://skyvia.com/data-integration/integrate-google-analytics-redshift. It doesn't require coding. With Skyvia, I can create a copy of Google Analytics report data in Amazon Redshift and keep it up-to-date with little to no configuration efforts. I don't even need to prepare the schema — Skyvia can automatically create a table for report data. You can load 10000 records per month for free — this is enough for me.

Issue exists in auto generation of number sequence AX

I have been trying to import customer master through data management tool in AX7 using "Customers" standard data entity, I have marked "Auto-Generate" for customer account field. And I am facing a number sequence error while the data gets inserted into staging. When I check the execution log I see the below error.
"Issue exists in auto generation of number sequence
Issue exist in generate staging data
'4' 'Customers' record(s) inserted in staging"
I checked number sequence setup for Customer account and it is proper it is as below:
Note:
Gives the same error irrespective of Continuous is marked or not for the number sequence code.
Any quick inputs would be appreciated!
Thanks Fh-Inway!
I have figured out the issue, and it's an issue with standard AX. An application hot fix (Metadata) is available for this which can be found in the LCS as a part of AX update2. I have installed it, tested it to be working fine.
Not sure whether I can share the Hotfix KB Article number here for the same.
Note: That hotfix has a common fix that addresses auto-generation of number sequences across all the data entities.

How can we understand the accounting entries in oracle applications or Oracle EBS?

I need to understand the accounting entries that are created in Oracle ebs. For example, when we talk about a standard P2P cycle, there are certain accounting entries created right from the moment a purchase order is created, approved and received.
I have basic knowledge of debit and credit entries. But when it comes to making debit and credit entries in Oracle apps, when I look at the accounts being used, I can not apply the basic dr cr entry rules to the accounts.
Please advise on this. Kindly also suggest some resources from where I can obtain this information.
This isn't a simple answer as the DR and CR entries are all driven by the accounting setup. To use your example, when a PO is created, very little accounting is done. It isn't until the line is received and Create Accounting is run that debits and credits are really applied based on how the accounting rules are set. If you were to open a PO, click "All Distributions", select a line and then click Tools > View Accounting Events, you'll see the detailed debits and credits that the accounting setup has created.
I'm not sure what your role is (developer, analyst, accountant etc.) or your experience level, but I would suggest you familiarize yourself with the accounting setup of your organization to be able to truly understand it. My suggestion is to get a Financial Super User responsibility in your development environment and ask one of your Financial Analysts to show you the basics of your account setup.
If you really want a deep dive, login to your My Oracle Support account and start looking at the documentation (Doc 1597048.1). The user guides are exhaustive but very helpful when you get the right one.
The debit and credit depends on the accounting rule setup.
In simple terms:
Inv Validated:___Dr-------Cr
Inv Exp...............100
Liability...........................100
Inv Paid:________Dr-------Cr
Liability........100
Cash................................100
There can be several steps in between depending on the Accounting rules, like Encumbrance accounting.

Vendor Invoices - Charges Code & Vendor Ledger Dimension

I have a charge code called FREIGHT set up with the following configurations. Under Credit, I've specified a ledger account of 4800.
I now create a Purchase Order, confirm and go through the whole process, and then try to invoice / post it.
I'm presented the following error:
"The combination 4800- is not valid for the account structure MYACCOUNTSTRUCTURE"
So it's been identified that AX is attempting to use 4800 from the aforementioned charges code field MarkupTable.VendorLedgerDimension.
In the code, it crashes in the PurchFormLetter.run() method, and if I did further it goes into the SysOperationController\pack super(); class before it crashes.
Now, if I were to change my account from 4800 to for example 2100, then the invoice goes through fine, which is good.
My question, and what I need is to find out what class / where in the code is this happening during the invoice post process that AX is trying to use this MarkupTable.VendorLedgerDimension field. I need to access that part of the process and modify that value (obviously 4800 is just the display value) to be something else.
If anyone needs more information for background, I need to keep the account for FREIGHT at 4800, while setting the actual financial dimension to the financial dimension on the line item. I've been debugging and looking all over the place for where this process occurs, but have had no luck so far.
If anyone can point me in the right direction, it would be very greatly appreciated.
Thank you.
Check what dimensions are mandatory on this account. Then set financial dimension on invoce lines.

Database relations query

I have two database tables
this is a sample database of a Ticketing system.
Figure 1: Sample table of air ticket.
Figure 2: Sample table of tax.
Requirement:
When ticket is made from the interface, it has multiple taxes of different names every time.
How can I store this information i.e. 'n' number of taxes for each ticket with different names every time.
I have tried to make many to many relationship but the problem is:
For each ticket if the tax is not setup, then need to add the tax first.
Any optimal solution for this?
"the problem is: For each ticket if the tax is not setup, then need to
add the tax first."
This is not a real-life problem. In real life governments declare taxes well in advance of collecting them, This gives organizations sufficient time to amend their systems which need to handle taxes. Tax is never a surprise.
"But this is very tiring solution for the end user.... to make bunch
of tax setup for each ticket"
This sort of thing is reference data, and is the duty of the system developer (hint: that's you) to populate the reference data tables. Or at least provide a screen where the user can create or amend various taxes. This is a different function from defining a ticket type.
The Ticket Creation screen should have a drop-down list (or similar widget) displaying all the existing taxes, which allows the user to pick the relevant one(s). If you reall think it's necessary you can include a link to the Create Tax screen, but that really is a very confusing workflow.
If the commentators are correct, and this is a ticket purchasing function, then your design is seriously wrong. Sales taxes must be included automatically to the cost of the purcahse as part of the transaction. Otherwise nobody would pay any tax.

Resources