Linha Microsiga Protheus

Árvore de páginas

Versões comparadas

Versão antiga 81

changes.mady.by.user Paulo Henrique Santos de Moura

Gravado em

comparado com

Nova versão 82

changes.mady.by.user Rafael Tenorio da Costa

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Aviso
titleObservações
  1. Para vendas NFCE com desconto NO TOTAL, a integração considerará sempre como desconto NO ITEM, pois o xml no NFCE-Sefaz sempre considera o desconto no item , independente da forma como foi praticado o desconto no PDV. Para evitar impactos de base de cálculos nos impostos , não será realizada nenhuma conversão de valores.
  2. Campo: D2_CSOSN Não é gravado em uma venda pelo venda assistida, porem via integração é, após analise identificamos que o campo é utilizado somente no NFESEFAZ para envio de uma mensagem nas observações da nota, portanto não foi encontrado nenhum impacto no processo de venda.
  3. Os campos TOTFED/TOTEST/TOTMUN da SL1/SL2 não são gravados na venda integrada do PDVSync por não existirem estes campos nas tabelas da base do PDV, e conforme verificado e alinhado com o PO, os campos no PROTHEUS não geram impacto nos livros fiscais. 
  4. Na venda PDVOMNI os cálculos para informativo da lei da transparência são arredondados, já no Protheus os campos TOTFED/TOTEST/TOTMUN não são arredondados.
  5. Campos L2_DESC\D2_DESC de percentual de desconto não são gravados na integração, porem não interferem nos cálculos, porque os valores de desconto estão OK.
  6. Campo L2_PICM não grava no registro do PROTHEUS, porem no registro da integração grava o que esta correto. SF2, SD2 e para frente grava corretamente.
  7. Quando algum item estiver com o CST 60 ou CSOSN 500 em venda com SAT, ficou definido que os campos abaixo terão seu conteúdo calculado diretamente pela MATXFIS, porque pelo XML SEFAZ não é possível chegar nestes valores.
    1. F2_VALICM, F2_ICMSRET, F2_BRICMS
    2. D2_VALICM, D2_ICMSRET, D2_BRICMS, D2_ALIQSOL
    3. F3_VALICM, F3_ICMSRET, F3_BASERET
    4. FT_VALICM, FT_ICMSRET, FT_BASERET
    5. Campos da SL1 e SL2 não serão atualizados.
  8. Para retenção de ICMS com base reduzida, alguns cálculos são necessários arredondamento para o valor do ICMS ficar correto nos livros fiscais, com isso os parâmetros abaixo são necessários:
    1. https://centraldeatendimento.totvs.com/hc/pt-br/articles/360023920652-CROSS-Segmentos-TOTVS-Backoffice-Linha-Protheus-FIS-Arredondamento-de-Impostos
    2. https://centraldeatendimento.totvs.com/hc/pt-br/articles/235534847-Como-evitar-diferen%C3%A7a-de-centavos-no-arredondamento-dos-ambientes-SIGALOJA-e-SIGAFRT-
    3. Encontrado diferença de 0,01 centavo na base de calculo de ICMS reduzido entre PDVOMNI e Protheus. Estamos acatando o valor enviado via xml pelo PDVOMNI.
  9. Para PIS COFINS Via Apuração a configuração do cliente deve ser, A1_RECPIS = "N" e A1_RECCOFI = "N". Com isso serão gravados os campos abaixo na venda:
    1. L2_VALPS2, L2_BASEPS2, L2_ALIQPS2, L2_VALCF2, L2_BASECF2, L2_ALIQCF2
  10. Para PIS Cofins via Retenção a configuração do cliente deve ser A1_RECPIS = "S" e A1_RECCOFI = "S". Com isso serão gravados os campos abaixo na venda:
    1. L2_VALPIS, L2_BASEPIS, L2_ALIQPIS, L2_ALIQCOF, L2_BASECOF, L2_VALCOFI
  11. Os acréscimos contidos na venda integrada serão informados no campo L2_DESPESA, pois a venda do PDVOmni realiza os acréscimos das vendas destacando os valores de despesa na tag vOutro do XML.
    1. Para soma de acréscimo/despesa na base de calculo acionar o parâmetro MV_FRTBASE e campos na tes usada no produto, conforme documentação do parâmetro: IMP0030_Despesas_acessórias_( seguro_e_frete)_para_base_dos_impostos_PIS/COFINS_(Apuração)
  12. Em caso de reintegração de venda cancelada no Protheus deverá ter intervenção manual, deletando a Tabela (MEP- em caso de venda parcelada) e as tabelas SFT , SF3 para ajuste de livro fiscal.
  13. PDV OMNI não atende ICMS90, mais detalhes:
    Jira
    serverJIRA
    serverId0c783de1-186e-383b-975c-a1acd7d76cb5
    keyDVARLOJ1-7453
  14. MV_PSHMOV - Parâmetro que habilita a geração de NCC movimentação financeira. = .T. - Quando a NCC é online via API, como por exemplo é utilizado no PdvSync o conteúdo do parâmetro deverá ser igual a .F. → Falso. 
  15. A gravação do campo L4_NSUTEF não terá nenhum tipo de tratamento, será exatamente o conteúdo do campo NsuHost (Nsu do host autorizador) retornado pelo PDVOmni. Atualmente o PDVOmni não tem a informação do TEF de Nsu do SiTef e vimos que esta informação só é utilizada pelo Sitef.
    1. Para qualquer alteração no conteudo do campo deve-se fazer via customização utilizando os pontos de entrada no MVC do fonte RetailSales.
  16. Para manter o legado (compatibilidade com TotvsPDV), os campos do cabeçalho: L1_VENDTEF, L1_DATATEF, L1_HORATEF, L1_DOCTEF, L1_AUTORIZ, L1_INSTITU, L1_NSUTEF, L1_TIPCART e L1_PARCTEF, serão salvos com os dados do ultimo pagamento de alguma destas formas de pagamento CC|CD|PD|PX.
  17. Para vendas onde foi utilizado como pagamento NCC (Crédito de Devolução), em caso de cancelamento, o valor na NCC/Crédito não é estornado, deve ser realizado processo manual no ERP para estorno da baixa ou geração de novo crédito. 


Cadastrando o Processo de VENDA

Para integrarmos o processo VENDA com o PdvSync primeiramente é necessário acessar o cadastro do Processo para verificar se o processo VENDA foi criado automaticamente no Protheus.

...

Tabela: SL1

Chave: L1_FILIAL+L1_NUM

Vinculando o Processo de VENDA ao Assinante PdvSync

1- No módulo 12 (Controle de Lojas), acesse Atualizações/ RMI/ Cadastros/ Assinantes.

...